Auto-unseal — secret management tizimi ishga tushganda saqlangan ma’lumotlarni ochish uchun zarur unseal kalitini operatorlar qo‘lda kiritmasdan tashqi ishonchli kriptografik xizmat orqali olish mexanizmidir. HashiCorp Vaultda u cloud KMS, HSM yoki boshqa seal provider yordamida master key materialini himoyalaydi.
Seal holati
Vault storage backendda ma’lumotni shifrlangan ko‘rinishda saqlaydi. Process ishga tushganda yoki qayta boshlanganida seal holatida bo‘ladi va data encryption keyga kira olmaydi. An’anaviy Shamir seal modelida bir nechta operator key share larini taqdim etib thresholdni to‘ldiradi.
Auto-unseal modelida Vault KMS yoki HSMdagi wrapping keydan foydalanib saqlangan root key materialini ochadi. Operator share kiritishi shart emas. Bu autoscaling va unattended restartni osonlashtiradi, lekin tashqi key service yangi muhim dependencyga aylanadi.
Ishonch zanjiri
Vault process KMSga autentifikatsiya qilishi kerak. Cloud instance identity yoki workload identity uzoq muddatli access keyni konfiguratsiyada saqlamaslikka yordam beradi. KMS policy faqat kerakli encrypt/decrypt operation va ayni keyga ruxsat beradi.
KMS administratori Vault data sini bevosita ko‘rmasligi mumkin, ammo keyni o‘chirish yoki policy o‘zgartirish orqali mavjudlikka ta’sir qiladi. Vault administratori esa KMS boshqaruvida to‘liq vakolatga ega bo‘lmasligi kerak. Separation of duties breach radiusni kamaytiradi.
Recovery keys
Auto-unseal yoqilganda Shamir unseal keylar o‘rniga recovery keys hosil bo‘lishi mumkin. Ular odatiy restartda ishlatilmaydi, ammo root token yaratish yoki ayrim recovery amallari uchun threshold talab qiladi. Recovery share lar xavfsiz, ajratilgan saqlash va mashq qilingan runbookka ega bo‘ladi.
Recovery key KMS wrapping keyning nusxasi emas. KMS key butunlay yo‘qolsa recovery shares har doim storage ma’lumotini ochib bera olmaydi. Provider va Vault versiyasining aniq recovery modeli hujjat asosida tushuniladi.
Mavjudlik va failure
KMS vaqtincha ishlamasa allaqachon unseal qilingan Vault node xizmatni davom ettirishi mumkin, lekin yangi yoki restart qilingan node ochilmaydi. Barcha node bir vaqtda qayta ishga tushsa outage cho‘ziladi. KMS region, network route, quota va permission monitoring qilinadi.
Key disabled, scheduled deletion yoki noto‘g‘ri rotation katta ta’sirli hodisadir. Destructive KMS amali MFA, approval va deletion waiting period bilan himoyalanadi. Backup faqat Vault storage nusxasi emas; seal konfiguratsiya va key lifecycle ham recovery rejasiga kiradi.
Migratsiya
Manual seal dan auto-unsealga yoki providerlar orasida o‘tish seal migration jarayonini talab qiladi. Barcha node bir xil konfiguratsiyada bo‘lishi, o‘tish paytida quorum va storage himoyalanishi kerak. Konfiguratsiyani shunchaki almashtirib restart qilish ma’lumotga kira olmaslikka olib kelishi mumkin.
Migratsiya avval test muhitida, keyin backup va rollback rejasi bilan bajariladi. Audit KMS decrypt amallari va Vault seal status o‘zgarishlarini bog‘laydi.
Dependency va tiklanish
Auto-unseal tashqi KMS yoki HSMni yangi critical dependencyga aylantiradi. Network uzilishi ishlayotgan node xotirasidagi master keyni darhol yo‘qotmaydi, lekin restart yoki yangi node ishga tushishini to‘sishi mumkin. KMS quota, region nosozligi, key disable va permission o‘zgarishi alohida monitoring qilinadi. Recovery keylari seal keyning aynan o‘rnini bosmaydi; ular vendor modeliga ko‘ra ma’muriy tiklash uchun ishlatiladi. Disaster recovery sinovi backup bilan birga KMS keyi va IAM siyosati mavjudligini ham tekshiradi.
Bog‘liq tushunchalar
Vault, Seal, KMS, HSM, Shamir Secret Sharing, Recovery key, Workload identity