Break-glass account — odatiy identifikatsiya yoki privileged access tizimi ishlamay qolgan favqulodda holatda kritik resursga kirish uchun saqlanadigan maxsus hisobdir. Nomi yong‘in signalidagi oynani sindirishga o‘xshatishdan kelgan: undan foydalanish mumkin, ammo bu odatiy va sezilmaydigan harakat emas. Har kirish kuchli signal, audit va keyingi tekshiruvga sabab bo‘ladi.
Qo‘llanish ssenariysi
Identity Provider ishlamay qolishi, MFA xizmati uzilishi, noto‘g‘ri policy barcha administratorni bloklashi yoki PAM mavjud bo‘lmasligi mumkin. Break-glass shu bog‘liqliklardan imkon qadar mustaqil bo‘lib, tiklash ishini boshlashga yetarli vakolat beradi. U biznesdagi har bir nosozlik uchun emas, normal boshqaruv yo‘li ishlamagan kritik hodisa uchun mo‘ljallangan.
Hisobning vakolati tiklash uchun yetarli, lekin cheksiz bo‘lishi shart emas. Alohida tizimlar uchun alohida favqulodda identity blast radiusni kamaytiradi. Cloud tenant, directory va backup boshqaruvi uchun mustaqil reja tuzilishi mumkin.
Credential himoyasi
Credential uzoq, tasodifiy va kundalik operatorga ma’lum bo‘lmagan bo‘ladi. U ikki kishilik nazorat ostidagi fizik seyf, offline password vault yoki bo‘lingan secret shaklida saqlanishi mumkin. Bitta shaxs ham credentialni, ham auditni o‘chirish imkoniga ega bo‘lmasligi kerak.
Hisob federatsiyaga to‘liq bog‘liq bo‘lsa, federatsiya nosozligida foydasiz bo‘ladi. Shu sabab lokal yoki cloud-native emergency identity tanlanishi mumkin. Biroq MFA imkon qadar saqlanadi; uning qurilmasi ham mustaqil va xavfsiz joyda turadi.
Kundalik foydalanishni to‘sish
Break-glass hisob email, oddiy workstation va avtomatlashtirishda ishlatilmaydi. API key yoki service credential sifatida kodga yozilmaydi. Login uchun maxsus manba, boshqaruv stansiyasi yoki tarmoq yo‘li talab qilinishi mumkin. Conditional access siyosati favqulodda hisobni tasodifan bloklamasligi, lekin keraksiz ochiq ham qoldirmasligi kerak.
Har autentifikatsiya urinishiga, hatto muvaffaqiyatsiz bo‘lsa ham, real vaqt alert yaratiladi. Signal IAM tizimining o‘zidan mustaqil kanalda ham yetkazilishi mumkin. Hisob foydalanilmayotgan paytda aktivligi va konfiguratsiyasi muntazam tekshiriladi.
Ishlatish tartibi
Runbook qaysi holatda account ochilishi, kim ruxsat berishi, credential qanday olinishi va qaysi birinchi amallar bajarilishini ko‘rsatadi. Hodisa ticketi va ikki kishilik tasdiq talab qilinishi mumkin, ammo hayotiy favqulodda holatda haddan tashqari byurokratiya tiklashni to‘xtatmasligi kerak.
Kirishdan keyin operator avval oddiy IAM yoki PAM yo‘lini tiklaydi, kundalik barcha ishni emergency sessiyada davom ettirmaydi. Buyruqlar va o‘zgarishlar alohida qayd qilinadi. Sessiya imkon qadar qisqa bo‘ladi va normal access qaytgach yopiladi.
Foydalanishdan keyin
Credential har real foydalanish va mashqdan keyin almashtiriladi. Sessiya, audit va o‘zgargan konfiguratsiya tekshiriladi. Break-glass orqali yaratilgan vaqtinchalik user, token yoki firewall qoidasi olib tashlanadi. Hodisa tahlili normal nazorat nega ishlamaganini va favqulodda jarayon qayerda qiynalganini aniqlaydi.
Credentialni almashtirish saqlash joyidagi nusxa va recovery hujjatini ham yangilashni talab qiladi. Eski nusxa bekor qilingani test qilinadi. Jarayon yakuni vakolatli ikki tomon tomonidan tasdiqlanadi.
Sinov
Sinovsiz emergency account paroli eskirgan, MFA qurilmasi ishlamaydigan yoki noto‘g‘ri rolga ega bo‘lishi mumkin. Rejalashtirilgan mashq productionga zarar bermaydigan nazoratli amal bilan login va audit signalini tekshiradi. Mashqning o‘zi ham real foydalanishdek qayd qilinib, credential rotatsiyasi bilan tugaydi.
Bir vaqtning o‘zida IAM nosozligi va tarmoq cheklovi kabi murakkab ssenariylar ham ko‘rib chiqiladi. Runbook qog‘oz yoki offline nusxada mavjud bo‘ladi, chunki uni saqlagan wiki ham SSOga bog‘langan bo‘lishi mumkin.
Bog‘liq tushunchalar
Privileged Access Management, Just-in-Time access, Disaster recovery, Emergency access, MFA, Credential rotation, Runbook