در هر سیستم نرمافزاری مجموعهای از «اسرار» (Secrets) وجود دارد: رمز عبور دیتابیس، کلید API سرویسهای خارجی، توکنهای احراز هویت، گواهیهای TLS و کلیدهای رمزنگاری. در معماریهای مدرن که دهها سرویس و صدها کلید در جریان است، نگهداری این اسرار در فایلهای پیکربندی یا متغیرهای محیطی، به یک فاجعهٔ امنیتی خاموش تبدیل میشود.
HashiCorp Vault ابزاری است که دقیقاً برای همین مشکل ساخته شده است. وُلت توسط شرکت HashiCorp توسعه یافته و در سال ۲۰۱۵ به عنوان پروژهٔ متنباز منتشر شد. آخرین نسخهٔ پایدار آن یعنی نسخهٔ ۱.۱۸.۳ علاوه بر نسخهٔ Community، در نسخهٔ Enterprise با قابلیتهایی مثل Replication و Multi-Cluster نیز عرضه میشود.
وُلت چیست؟
Vault یک سیستم مدیریت متمرکز اسرار است که ذخیرهٔ امن، کنترل دسترسی دقیق و چرخهٔ عمر کامل اسرار را در یک ابزار جمع میکند. به جای اینکه هر تیم رمزهای خود را در فایلهای پراکنده نگه دارد، همهٔ اسرار در یک مخزن مرکزی رمزنگاریشده قرار میگیرند و برنامهها از طریق API به آن دسترسی پیدا میکنند.
فلسفهٔ وُلت ساده است: اسرار نباید نزد برنامه بمانند. برنامه در لحظهٔ نیاز، سری را از وُلت میگیرد، استفاده میکند و بعد از انقضا، سری خود به خود باطل میشود. به این ترتیب حتی اگر یک سرور هک شود، هیچ رمز دائمیای در آن وجود ندارد که لو برود.
امکانات اصلی وُلت
Secrets Engines (موتورهای اسرار)
قلب وُلت، Secrets Engines هستند؛ هر موتور یک نوع خاص از اسرار را مدیریت میکند. پرکاربردترین آن kv است که یک Key-Value Store با نسخهبندی فراهم میکند؛ در نسخهٔ kv-v2 امکان برگشت به نسخههای قبلی یک سری هم وجود دارد. موتورهای دیگر شامل database برای رمزهای دیتابیس، pki برای گواهیهای TLS، aws و azure برای اعتبارنامههای ابری و transit برای رمزنگاری هستند.
Dynamic Secrets (اسرار پویا)
تفاوت کلیدی وُلت با یک مخزن ساده، تولید اسرار پویا است. وقتی برنامه به دیتابیس نیاز دارد، وُلت یک رمز عبور موقت میسازد، آن را در اختیار برنامه میگذارد و بعد از انقضای Lease باطلش میکند. دیگر خبری از رمز دائمی در پیکربندی نیست؛ رمز هر بار ساخته و بعد نابود میشود. اگر یک رمز لو برود، فقط برای چند ساعت قابل استفاده است — نه تا همیشه.
Encryption as a Service (رمزنگاری به عنوان سرویس)
با موتور transit، وُلت به عنوان یک سرویس رمزنگاری عمل میکند: برنامهها داده را برای رمزنگاری به وُلت میفرستند و کلیدها هرگز از وُلت خارج نمیشوند. این قابلیت برای رمزنگاری دادههای حساس بدون اینکه کلید در اختیار تیمها باشد بسیار ارزشمند است و چرخش کلید (Key Rotation) را بدون تغییر حتی یک خط کد ممکن میکند.
Lease و Renewal (اجاره و تمدید)
هر سری در وُلت یک Lease با مدتزمان مشخص دارد. برنامه باید قبل از انقضا، Lease را تمدید (Renew) کند وگرنه سری باطل میشود. این مکانیزم تضمین میکند هیچ دسترسیای برای همیشه زنده نماند و همهٔ اسرار به صورت خودکار منقضی شوند.
احراز هویت (Auth Methods)
وُلت از دهها روش احراز هویت پشتیبانی میکند: توکن، userpass، LDAP، GitHub، Kubernetes و OIDC. دسترسی به هر سری با سیاستهای دقیق (Policies) و بر اساس اصل کمترین دسترسی (Least Privilege) کنترل میشود؛ یعنی حتی اگر یک سرویس هک شود، فقط به همان سریهایی دسترسی دارد که واقعاً به آنها نیاز دارد.
Unsealing و High Availability
وُلت دادهها را قبل از ذخیرهسازی رمزنگاری میکند و برای باز شدن در حالت عادی به Unseal Keys نیاز دارد (با مکانیزم Shamir Secret Sharing). در حالت High Availability میتوان کلاستر چندگرهای با raft یا Consul راهاندازی کرد و با Auto Unseal از سرویسهایی مثل KMS بهره برد.
مقایسهٔ وُلت با راهحلهای دیگر
رایجترین مقایسهها با وُلت، مقایسه با AWS Secrets Manager و Kubernetes Secrets است. هر سه ابزار اسرار را ذخیره میکنند، اما عمق و دامنهٔ قابلیتها بسیار متفاوت است:
| ویژگی | HashiCorp Vault | AWS Secrets Manager | Kubernetes Secrets |
|---|---|---|---|
| ماهیت | ابزار مستقل و متنباز | سرویس ابری AWS | منبع داخلی کوبرنتیز |
| اسرار پویا | بله — رمز موقت برای دیتابیس و ابر | چرخش برنامهریزیشده (Rotation) | خیر — کاملاً استاتیک |
| رمزنگاری داده | بله — موتور transit | بله — با KMS | خیر (فقط Base64!) |
| Lease و انقضا | بله — خودکار و اجباری | تا حدی | خیر |
| کنترل دسترسی | Policies پیشرفته و چندلایه | IAM | RBAC پایه |
| وابستگی | مستقل از هر ابر | قفل در AWS | وابسته به کوبرنتیز |
| مناسب برای | سازمانهای چندابر و امنیت بالا | تیمهایی که داخل AWS هستند | پروژههای سادهٔ کوبرنتیزی |
خلاصهٔ انتخاب: اگر فقط داخل AWS هستید و به Dynamic Secrets نیاز ندارید، AWS Secrets Manager سادهترین گزینه است. اگر فقط میخواهید چند متغیر محیطی را در کوبرنتیز نگه دارید، Kubernetes Secrets کافی است. اما اگر به اسرار پویا، رمزنگاری، خروجیهای موقت یا یک مخزن واحد برای همهٔ محیطها نیاز دارید، Vault انتخاب درست است.
موارد استفادهٔ وُلت
- مدیریت متمرکز رمز دیتابیس و API — همهٔ میکروسرویسها رمز خود را از یک نقطه میگیرند
- صدور خودکار گواهی TLS — با موتور
pki، گواهیهای سرویسهای داخلی بدون دخالت انسان صادر و تمدید میشوند - رمزنگاری دادههای حساس — با موتور
transitبدون نگهداری کلید نزد برنامهها - مدیریت اعتبارنامهٔ CI/CD — توکنها و کلیدهای پایپلاینها به جای فایلهای مخفی، از وُلت خوانده میشوند
- اعتبارنامههای ابری برای Terraform — وُلت با Terraform همخانواده است و الگوی استانداردی برای تزریق اعتبارنامه دارد
چه زمانی وُلت انتخاب مناسبی است؟
- چند محیط (توسعه، آزمایش، تولید) با اسرار مشترک دارید که مدیریتشان از کنترل خارج شده است
- به اسرار پویا و موقت نیاز دارید — مثلاً رمز دیتابیسی که هر بار ساخته میشود
- در معماری میکروسرویس یا کوبرنتیز هستید و به یک مخزن مرکزی با سیاست دقیق دسترسی نیاز دارید
- در چند ابر یا زیرساخت ترکیبی کار میکنید و به راهحلی مستقل از فروشنده نیاز دارید
- الزامات امنیتی یا قانونی دارید که ایجاب میکند اسرار به صورت رمزنگاریشده و قابل ممیزی (Audit) ذخیره شوند
چه زمانی وُلت مناسب نیست؟
- پروژههای تکسروری کوچک — برای یک اپلیکیشن ساده، یک متغیر محیطی یا فایل پیکربندی کافی است؛ وُلت پیچیدگی اضافه است
- تیمهای بدون تجربهٔ زیرساخت — مفاهیمی مثل Unseal، Policies و HA منحنی یادگیری دارند و مدیریت نادرست آن خودش خطر میسازد
- اگر فقط AWS استفاده میکنید — AWS Secrets Manager با KMS اغلب سادهتر و ارزانتر جواب میدهد
- اگر سروری برای نگهداری آن ندارید — وُلت خودش یک سرویس است که باید در دسترس، بهروز و پشتیبانگیریشده باشد
وُلت در لکسویا
لکسویا وُلت را به عنوان برنامهٔ آماده (QuickApp) ارائه میدهد — با یک کلیک نمونهٔ تکنمونهای یا کلاستر راه بیندازید.
نتیجهگیری
HashiCorp Vault استاندارد مدیریت اسرار در دنیای زیرساخت مدرن است. اسرار پویا، رمزنگاری به عنوان سرویس، چرخهٔ عمر خودکار و کنترل دسترسی دقیق، آن را به ابزاری ضروری برای سازمانهایی تبدیل کرده که امنیت برایشان اولویت است.
اما وُلت برای همه نیست؛ سادگی راهحلهای ابری مثل AWS Secrets Manager یا حتی Kubernetes Secrets برای تیمهای کوچک کاملاً منطقی است. انتخاب درست به مقیاس، منابع و سطح ریسکی که میپذیرید بستگی دارد.