PAM и аварийни акаунти (break-glass) за ISO 27001 през 2026 г.

В 02:14 в неделя сутрин ръководителят на инцидента получава съобщението, от което всеки CISO се опасява: „Удостоверяването в продукционна среда отказва. Административната конзола е недостъпна. Превключването на базата данни към резервен ресурс е блокирало.“

Дежурният облачен инженер вижда проблема, но не може да го отстрани. Нормалната му привилегирована роля зависи от същия доставчик на идентичност, който в момента е с нарушена работоспособност. Оперативният ръководител иска аварийните администраторски удостоверителни данни. Мениджърът по съответствието пита дали аварийният акаунт (break-glass) изобщо е бил тестван. DPO пита дали достъпът до продукционната база данни може да разкрие лични данни. CISO задава въпроса, който определя дали това ще бъде контролирано възстановяване или одитен кошмар:

„Можем ли да докажем кой е използвал аварийния достъп, защо, какво е направил и че акаунтът е бил нулиран след това?“

Друга организация може да се сблъска със същия проблем в по-тиха обстановка. CISO на FinTech компания седи срещу външни одитори след неправилна конфигурация на облачна база данни. Инцидентът е отстранен бързо, но първопричината не е успокояваща. Разработчик от трета страна е имал постоянни административни привилегии. Когато основният администратор не е бил на разположение, разработчикът е използвал авариен акаунт (break-glass), базиран на споделена парола, съхранявана в „сигурна“ бележка, достъпна за DevOps екипа.

Одиторите не се фокусираха само върху неправилната конфигурация. Те попитаха дали достъпът е бил ограничен във времето, дали е имало индивидуална отчетност, дали командите са били журнализирани, дали личните данни са били защитени съгласно GDPR Article 32, дали са били изпълнени задълженията по DORA за ИКТ риск и дали очакванията на NIS2 за киберхигиена могат да бъдат доказани.

Това е реалната точка на натиск за управлението на привилегирован достъп и аварийни акаунти (break-glass) през 2026 г. PAM вече не е нишов проект за сигурност на идентичностите. Това е мястото, където се пресичат ransomware, компрометиране на облачни услуги, риск, свързан с доставчици, защита на данните, оперативна устойчивост и доказателства за одит.

Привилегированият достъп е мястото, където атакуващите се опитват да спечелят. Аварийният достъп (break-glass) е мястото, където защитниците се опитват да възстановят средата. И двата вида достъп разчитат на една и съща опасна възможност: повишен достъп, който може да заобикаля контроли, да променя конфигурации, да чете чувствителни данни, да ротира ключове, да деактивира журнализирането, да възстановява резервни копия, да внедрява код или да унищожава доказателства.

Практическата позиция на Clarysec е проста: аварийният достъп е необходим, но неуправляваният авариен достъп е неуправляван риск. Правилният отговор не е „без аварийни акаунти“. Правилният отговор е управляван модел за управление на привилегирован достъп с инвентар, одобрение, времеви ограничения, силно удостоверяване, журнализиране на сесии, преглед след използване, нулиране на удостоверителни данни и доказателства за одит.

Защо привилегированият достъп е въпрос на съответствие на ниво управителен съвет

В среди с по-ниска зрялост привилегированият достъп често се третира като задача по ИТ администрация. Някой се нуждае от администраторски права, отваря се билет, предоставя се роля и бизнесът продължава. Този модел не издържа на съвременния ransomware, cloud-native инфраструктурата, отчетността по NIS2, оперативната устойчивост по DORA или проверката при нарушения по GDPR.

Директивата NIS2 поставя управлението на киберсигурността в заседателната зала. Article 20 изисква управителните органи на съществените и важните субекти да одобряват мерките за управление на риска за киберсигурността, да упражняват надзор върху внедряването и да преминават обучение по киберсигурност. Article 21 изисква подходящи и пропорционални технически, оперативни и организационни мерки, включително анализ на риска, обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, ефективност на контролите, киберхигиена, сигурност на човешките ресурси, контрол на достъпа, управление на активите и MFA или непрекъснато удостоверяване, когато е приложимо.

За SaaS доставчици, доставчици на управлявани услуги, доставчици на управлявана сигурност, облачни услуги, центрове за данни и други организации за цифрова инфраструктура приложимостта на NIS2 зависи от сектора, размера, ролята, трансграничното въздействие и установяването в ЕС. Оперативният извод е пряк: контролът на достъпа вече не е скрит в техническо приложение. Той е част от базовото ниво на киберхигиена, което ръководството трябва да одобрява, наблюдава и коригира.

За финансовите субекти Digital Operational Resilience Act променя езика, но не и същинския риск. DORA се прилага от 17 януари 2025 г. и установява единна рамка за управление на ИКТ риска, докладване на съществени инциденти, свързани с ИКТ, тестване на цифровата оперативна устойчивост и управление на риска от трети страни в областта на ИКТ. Article 5 изисква управленски и контролни механизми за ИКТ риска, като управителният орган определя, одобрява, наблюдава и носи отговорност за механизмите за ИКТ риск. Article 6 изисква документирана рамка за управление на ИКТ риска с политики, процедури, протоколи и инструменти за защита на ИКТ активи. Article 17 изисква процес за управление на инциденти, свързани с ИКТ, който открива, записва, класифицира, ескалира и възстановява сигурните операции.

GDPR добавя перспективата на поверителността и отчетността. Article 5(1)(f) изисква личните данни да се обработват при гарантиране на цялостност и поверителност. Article 5(2) изисква отчетност. Article 25 изисква защита на данните още при проектирането и по подразбиране. Article 32 изисква подходящи технически и организационни мерки за сигурност на обработването. Ако привилегирован потребител може да експортира клиентски записи, да има достъп до специални категории данни, да деактивира одитни журнали или да променя настройки за съхранение без преглед, организацията не просто е допуснала IAM грешка. Тя може да не е в състояние да докаже подходяща сигурност.

ISO/IEC 27001:2022 е гръбнакът на системата за управление, който позволява тези задължения да бъдат обработвани чрез една интегрирана програма. Клауза 4.2 изисква организацията да разбира заинтересованите страни и техните изисквания, включително правни, регулаторни и договорни задължения. Клауза 5.1 изисква лидерство и ангажираност. Клауза 6.1.2 изисква оценка на риска за информационната сигурност. Клауза 6.1.3 изисква третиране на риска. Клауза 8 изисква оперативно планиране и контрол.

При привилегирования достъп това измества разговора от „кой PAM инструмент да купим?“ към „кои рискове третираме, кои контроли са избрани, кой е техният собственик, как се изпълняват и какви доказателства показват, че работят?“

PAM не е един контрол, а верига от доказателства

PAM инструмент може да съхранява пароли в сейф, да посредничи при сесии, да записва натискания на клавиши, да ротира удостоверителни данни и да прилага достъп точно навреме. Тези възможности са важни. Но ако организацията не е дефинирала привилегировани роли, не е одобрила авариен достъп, не е съпоставила достъпа с активи, не е прегледала правата, не е защитила журналите и не е обучила администраторите, инструментът се превръща в частичен контрол със слаба одитна защитимост.

Най-полезният начин за управление на привилегирован достъп е да се мисли чрез резултати от контрола, а не чрез имена на инструменти.

Zenith Controls: The Cross-Compliance Guide Zenith Controls разглежда контрол 8.2 по ISO/IEC 27002:2022, Privileged access rights, като център на тежестта за PAM. Той класифицира този контрол като превантивен, поддържащ поверителност, цялостност и наличност, съгласуван с концепцията за киберсигурност Protect, оперативната способност Управление на идентичността и достъпа и домейна на сигурността Protection.

Контрол 8.2 е силен, защото се свързва със съседните контроли, които правят привилегирования достъп проверим при одит:

Затова одиторът рядко спира до въпроса: „Имате ли PAM система?“ По-силните одитни въпроси са: Имате ли инвентар на привилегированите акаунти? Одобрени ли са привилегированите роли? Ограничени ли са правата във времето? Защитени ли са аварийните удостоверителни данни? Можете ли да докажете кой ги е използвал? Журнализират ли се командите? Включени ли са администраторите на доставчици? Преглеждат ли се правата за достъп? Нулирани ли са удостоверителните данни? Приети ли са изключенията като риск?

Съпоставянето на правата за достъп в Zenith Controls посочва това директно: управлението на правата за достъп operationalizes принципите за контрол на достъпа като минимални привилегии, необходимост да се знае и оторизация, докато привилегированите акаунти изискват специално внимание и своевременно отнемане, когато вече не са необходими.

Изисквания на политиката за надежден авариен достъп (break-glass)

Аварийният акаунт (break-glass) не е споделена администраторска парола в запечатан плик. През 2026 г. този модел е твърде слаб за облак, финтех, SaaS, здравеопазване, управлявани услуги и регулирани цифрови операции.

Защитимият модел за авариен достъп (break-glass) се нуждае от седем минимални правила в политиката:

1. Акаунтът трябва да бъде документиран.
2. Акаунтът трябва да бъде одобрен.
3. Използването трябва да може да се припише на конкретно лице, когато това е технически възможно.
4. Използването трябва да бъде ограничено до реални аварийни ситуации.
5. Използването трябва да бъде журнализирано и прегледано.
6. Удостоверителните данни или факторите за удостоверяване трябва да бъдат нулирани или ротирани след използване.
7. Акаунтът трябва да бъде тестван и включен в обхвата на одита.

Библиотеката с политики на Clarysec превръща тези принципи в използваем управленски език.

Политика за управление на потребителски акаунти и привилегии-sme Политика за управление на потребителски акаунти и привилегии - SME посочва:

„Аварийният достъп (напр. администраторски break-glass акаунти) трябва да бъде ясно документиран, защитен и използван само когато е абсолютно необходимо.“

От раздел „Третиране на риска и изключения“, клауза 7.3.1 от политиката.

Същата SME политика продължава:

„Такива акаунти трябва да бъдат журнализирани, преглеждани след използване и нулирани след всяко аварийно събитие.“

От раздел „Третиране на риска и изключения“, клауза 7.3.2 от политиката.

За ежедневното повишаване на привилегии SME политиката също изисква:

„Повишените или административните привилегии изискват допълнително одобрение от управителя или ИТ ръководителя и трябва да бъдат документирани, ограничени във времето и подлагани на периодичен преглед.“

От раздел „Изисквания за прилагане на политиката“, клауза 6.2.2 от политиката.

За по-големи организации корпоративният набор от политики навлиза по-дълбоко. Политика за управление на потребителски акаунти и привилегии Политика за управление на потребителски акаунти и привилегии изисква:

„Привилегированите сесии трябва да бъдат изцяло журнализирани, включително издадените команди и извършените действия. Журналите трябва да се преглеждат периодично от определени преглеждащи лица.“

От раздел „Изисквания за прилагане на политиката“, клауза 6.4.2 от политиката.

Същата политика изисква временните или аварийните акаунти с привилегирован достъп да следват документирана процедура за авариен достъп (break-glass) в клауза 6.2.5, докато клауза 7.4 очертава изискванията към тази процедура.

Политика за контрол на достъпа Политика за контрол на достъпа засилва съхранението за целите на одита:

„Решенията за одобрение трябва да бъдат журнализирани и съхранявани за целите на одита за минимум 2 години.“

От раздел „Изисквания за управление“, клауза 5.3.2 от политиката.

Политика за журнализиране и мониторинг-sme Политика за журнализиране и мониторинг - SME определя очакванията за журнализиране на удостоверяването:

„Журнали за удостоверяване: успешни и неуспешни опити за вписване, продължителност на сесията, използване на MFA“

От раздел „Изисквания за управление“, клауза 5.4.2 от политиката.

Заедно тези клаузи превръщат аварийния достъп от героично заобикаляне в контролирано събитие. Акаунтът е изключителен, но управлението му не е.

Подходът на Zenith Blueprint към внедряването на PAM

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint разглежда привилегирования достъп като практически проблем на внедряване, а не като теоретично описание на контрол. Във фазата Controls in Action, Step 19, Technological Controls I, той посочва:

„Във всяка информационна система привилегированият достъп е власт, а с тази власт идва риск.“

От фазата Controls in Action, Step 19: Technological Controls I.

Step 19 изисква организациите да идентифицират привилегировани акаунти в локални, облачни, SaaS, развойни и инфраструктурни среди. Това включва администратори на домейни, root потребители, администратори на облачни tenant-и, суперпотребители на бази данни и контролери на CI/CD пайплайни. Той също така подчертава минимизирането на привилегирования достъп чрез ролеви контрол на достъпа, достъп точно навреме и работни потоци за одобрение.

Това е важно, защото много сериозни инциденти не започват с формалния авариен акаунт (break-glass). Те започват с постоянна привилегия. Облачен инженер запазва права на собственик „за всеки случай“. Администратор на база данни запазва достъп до продукционна среда след преместване в друг екип. Служебен акаунт за CI/CD има широки разрешения в различни среди. Акаунт на доставчик на управлявани услуги е освободен от MFA, защото „им трябва бърз достъп“.

Step 20 на Zenith Blueprint разширява същата логика към привилегированите помощни програми. Той инструктира организациите да създадат или актуализират инвентар на привилегированите помощни програми, да ограничат изпълнението им до оторизирани администратори, да проверят, че използването се журнализира и генерира предупреждения, и да обмислят журнализиране на скриптове, например PowerShell журнализиране чрез групови политики. Това е критично, защото привилегированият акаунт често е само входната точка. Щетата настъпва, когато атакуващият стартира инструменти, които деактивират контроли, извличат удостоверителни данни или се придвижват странично.

Step 22 формализира жизнения цикъл на контрола на достъпа. Той изисква структурирано предоставяне и отнемане на достъп, в идеалния случай интегрирани с човешките ресурси и поддържани от работни потоци за заявки за достъп, с документирани тримесечни прегледи на правата за достъп. Step 16 свързва жизнения цикъл с освобождаването на служители чрез изискване за контролен списък при прекратяване на правоотношение, който ЧР и ИТ използват съвместно, включително деактивиране на акаунти, връщане на активи и напомняния за NDA.

Zenith Blueprint превръща PAM в свързан оперативен модел: идентичност, ЧР, привилегировани помощни програми, журнализиране, реагиране при инциденти, прегледи на правата за достъп и доказателства за одит взаимно се подсилват.

Практически модел за управление на авариен достъп (break-glass) през 2026 г.

Добре проектираният процес за авариен достъп (break-glass) трябва да работи по време на отказ. Ако зависи от същия доставчик на идентичност, ticketing платформа и чат услуга, които са недостъпни по време на прекъсването, това е само формалност.

В същото време аварийният достъп не може да се превърне в канал за удобно заобикаляне. Clarysec обичайно проектира управлението на аварийния достъп (break-glass) около четири слоя: превенция, активиране, наблюдение и възстановяване.

За облачни среди включете администратори на ниво tenant, cloud root акаунти, аварийни администратори на доставчика на идентичност, привилегировани служебни акаунти, master потребители на бази данни, Kubernetes cluster-admin роли, CI/CD deploy ключове, администратори на сейфове за тайни и акаунти за поддръжка от трети страни.

За хибридни среди включете администратори на домейни, администратори на резервни копия, администратори на хипервайзори, администратори на защитни стени, администратори на EDR конзоли и потребители на привилегировани помощни програми.

За среди с повишени изисквания за поверителност включете администратори, които могат да достъпват бази данни, съдържащи лични данни, журнали, съдържащи идентификатори, записи на ЧР, биометрични данни за проверка на идентичността, системи за мониторинг на измами или инструменти за клиентска поддръжка.

Целевото състояние е лесно за описание и трудно за имитация: всеки авариен път е известен, одобрен, защитен, наблюдаем, обратим и прегледан.

60-минутно упражнение за доказателства при авариен достъп (break-glass)

CISO или мениджър по съответствието може да проведе полезно упражнение за авариен достъп (break-glass) още тази седмица, без да купува нов инструмент. Целта не е само да се потвърди, че акаунтът работи. Целта е да се докаже, че контролът създава доказателства.

Сценарий

Приемете, че основният доставчик на идентичност е с нарушена работоспособност. Нормалното повишаване на привилегиите точно навреме е недостъпно. Клъстер на продукционна база данни се нуждае от аварийни промени в конфигурацията, за да бъде възстановена услугата. Аварийният акаунт (break-glass) на облачния администратор трябва да бъде активиран.

Step 1: Потвърдете, че акаунтът е в инвентара на привилегированите акаунти

Използвайте Zenith Blueprint, фазата Controls in Action, Step 19, за да валидирате, че акаунтът присъства в инвентара на привилегированите акаунти. Запишете името на акаунта и средата, бизнес собственика, техническия собственик, достъпните системи, въздействието върху личните данни, метода за удостоверяване, местоположението в сейфа, метода за ротация и датата на последния тест.

Ако акаунтът липсва, третирайте това като пропуск в контрола и го добавете в регистъра на риска.

Step 2: Проверете съгласуването с политиките

Съпоставете събитието с изискванията на Политика за управление на потребителски акаунти и привилегии за документирани процедури за авариен достъп (break-glass) и журнализиране на привилегировани сесии. Ако сте SME, използвайте клаузи 7.3.1 и 7.3.2 на Политика за управление на потребителски акаунти и привилегии-sme като минимален базов набор: документиран, защитен, необходим, журнализиран, прегледан и нулиран.

Съпоставете съхранението на одобренията с клауза 5.3.2 на Политика за контрол на достъпа, която изисква решенията за одобрение да бъдат журнализирани и съхранявани поне 2 години.

Step 3: Отворете запис за авариен достъп

Създайте билет или запис за инцидент преди или при активиране. Включете:

• Причина за аварийния достъп
• Засегната услуга
• Заявен акаунт
• Заявител
• Одобряващ
• Начален час
• Очакван краен час
• Въздействие върху клиенти или регулаторни изисквания
• Въздействие върху лични данни по GDPR
• Флаг за наблюдение на докладване по NIS2 или DORA

Не чакайте до края, за да реконструирате историята. Одитната стойност е най-силна, когато записът започва преди използването на достъпа.

Step 4: Активирайте и наблюдавайте

Активирайте аварийния акаунт (break-glass). Потвърдете, че се използва MFA или компенсиращо удостоверяване, че сесията се записва, че командите или административните действия се журнализират, че журналите се препращат към централизирано журнализиране, че синхронизацията на времето поддържа реконструкция на хронологията и че се генерира предупреждение при използване на аварийния акаунт.

Това е съгласувано със Zenith Controls за 8.15 Журнализиране, който описва журнализирането като основния слой от данни за мониторинг и отбелязва, че привилегированите потребители и изпълнението на привилегировани помощни програми трябва да бъдат журнализирани изчерпателно.

Step 5: Закрийте, нулирайте и прегледайте

След аварийната задача деактивирайте или върнете акаунта в запечатан статус, ротирайте удостоверителните данни или нулирайте фактора за удостоверяване, прегледайте журналите на сесията, документирайте командите и промените в конфигурацията, потвърдете, че не е настъпил ненужен достъп до данни, актуализирайте записа за инцидента, запишете извлечените поуки и решете дали са задействани праговете за уведомяване по NIS2, DORA или GDPR.

Ако са били достъпени лични данни, включете DPO. Ако събитието е причинило прекъсване на услугата или може да причини съществено въздействие, включете собственика на докладването по NIS2 или DORA. Ако аварийният акаунт (break-glass) е отказал, документирайте това като констатация за оперативната устойчивост, а не просто като IAM проблем.

Съпоставяне на съответствието за PAM и контроли за авариен достъп (break-glass)

Най-силният управленски модел не дублира контроли за всяка регулация. Той изгражда една верига от доказателства, която поддържа множество задължения.

NIST CSF 2.0 е особено полезен при превеждане на PAM в Current Profile и Target Profile. Методът с профили започва с обхват, след това събира политики, рискови приоритети, регистри, изисквания, практики и работни роли, преди да създаде приоритизиран план за действие. За привилегирования достъп това означава обхващане на профила около сигурност на идентичността, облачна администрация, устойчивост срещу ransomware, критични финансови системи или достъп на доставчици.

За финансови субекти, обхванати от DORA, DORA функционира като секторно специфичния режим на ЕС за киберустойчивост по отношение на еквивалентните задължения за риск и инциденти по NIS2. Това не прави NIS2 нерелевантна. Това означава, че финансовият субект трябва да използва DORA като водещ режим за изискванията за ИКТ риск и инциденти, като същевременно поддържа координация с национални стратегии за киберсигурност, компетентни органи и CSIRT, когато е приложимо.

Как одиторите тестват доказателствата за привилегирован достъп

Одиторите не оценяват PAM само чрез прочит на политика. Те съпоставят политика, конфигурация, журнали, билети, интервюта и наблюдавана практика.

Одитната методология на Zenith Controls за права за привилегирован достъп се позовава на практиките за одит по ISO/IEC 19011:2018. Одиторите преглеждат политики, които дефинират повишени права, процедури за предоставяне на достъп, мониторинг и отнемане. Те проверяват инвентари на потребителски акаунти, записи за присвояване на привилегии и журнали. Те потвърждават доказателствата чрез интервюта, PAM инструменти, услуги за директории и извадки от журнали.

За правата за достъп Zenith Controls отбелязва, че одиторите извадково проверяват заявки за потребителски достъп, проверяват документираните одобрения и потвърждават, че ИТ е предоставил само одобрен достъп. Те също сравняват потребителските роли с реалните права, като проверяват дали се прилагат минимални привилегии. При журнализирането одиторите проверяват обхвата на журнализиране, типовете събития, сроковете за съхранение, защитите и реалните журнални записи. Те оценяват дали неуспешните вписвания, достъпът до чувствителни данни и промените в конфигурацията се улавят и преглеждат.

Добър пакет с доказателства за авариен достъп (break-glass) включва:

• Одобрена заявка за авариен достъп
• Контекст на инцидента или прекъсването
• Идентичност на потребителя, който активира достъпа
• Идентичност на одобряващия
• Начален и краен час
• Доказателства за MFA или удостоверяване
• Запис на сесия или журнал на командите
• Системни журнали и SIEM предупреждение
• Направени промени
• Потвърждение за нулиране на удостоверителните данни
• Преглед след използване
• Оценка на достъпа до данни
• Оценка на необходимостта от регулаторно уведомяване
• Коригиращи действия, ако нещо е отказало

Ако упражнението ви не може да създаде този пакет, контролът не е готов за одит.

Скритият отказ: привилегирован достъп на трети страни

Много организации управляват администраторите служители по-добре от администраторите доставчици. За облачни, SaaS, финтех и управлявани услуги това е обратното на правилния подход.

NIS2 Article 21 включва сигурност на веригата на доставки и отношения с преки доставчици и доставчици на услуги. DORA Articles 28 до 30 отиват по-далеч за финансовите субекти, като изискват стратегия за риск от трети страни в областта на ИКТ, регистри на договорите за ИКТ услуги, надлежна проверка, оценка на риска от концентрация, права на одит, права на прекратяване, стратегии за изход и договорни мерки за сигурност.

Привилегированият достъп на доставчици трябва да бъде в обхвата на PAM, ако доставчикът може да администрира продукционна среда, да поддържа критични или важни функции, да има достъп до лични данни, да изменя конфигурации за сигурност, да управлява резервни копия, да внедрява код или да управлява инструменти за мониторинг.

Clarysec обичайно очаква контролите за привилегирован достъп на доставчици да включват:

• Поименни потребители на доставчика, а не споделени акаунти на доставчика
• Договорни изисквания за сигурност при привилегирован достъп
• MFA и сигурен отдалечен достъп
• Ограничени във времето прозорци за достъп
• Одобрение от клиента за авариен достъп
• Журнализиране на сесии или еквивалентни одитни следи
• Незабавно отнемане при промяна на персонала
• Задължения за сътрудничество при инциденти
• Съхранение на доказателства, съгласувано с одитните нужди на клиента
• План за изход за премахване на достъпа на доставчика

Резултатите на NIST CSF 2.0 за веригата на доставки се съгласуват силно тук. Те изискват роли и отговорности на доставчиците, приоритизация на доставчиците по критичност, изисквания в договорите, надлежна проверка, непрекъснато наблюдение, участие на доставчиците в планиране при инциденти и планове за риска след приключване на договора.

Ако акаунт на доставчик на управлявани услуги е освободен от вътрешния ви PAM работен поток, това не е удобство. Това е високорисково изключение, което принадлежи в регистъра на риска, регистъра на доставчиците и прегледа на достъпа.

Чести констатации за PAM и авариен достъп (break-glass) през 2026 г.

В ангажиментите на Clarysec констатациите рядко са изненадващи. Обикновено те са комбинации от добри намерения, оперативен натиск и непълни доказателства.

Най-честите констатации са:

• Аварийни акаунти (break-glass) съществуват, но не са включени в инвентара на привилегированите акаунти.
• Аварийните акаунти са изключени от нормалните прегледи на правата за достъп.
• Организацията не може да докаже кой е използвал авариен акаунт.
• Акаунтът не е бил нулиран след използване.
• Привилегированите сесии се журнализират, но командите не.
• Журналите съществуват локално, но не са защитени от привилегировани потребители.
• Cloud root акаунтите не се тестват.
• Процесите за възстановяване на MFA не са документирани.
• Привилегированият достъп за CI/CD пайплайни и служебни акаунти се игнорира.
• Достъпът за поддръжка от трети страни заобикаля вътрешното одобрение.
• Одобрение на достъп съществува в чат съобщения, но не се съхранява като доказателство за одит.
• Offboarding премахва електронна поща и VPN, но не и администраторски права в SaaS.
• DPO не се включва, когато привилегированият достъп може да разкрие лични данни.
• Наръчниците за инциденти не включват точки за решение относно уведомяване по NIS2, DORA или GDPR.

Всяка констатация може да бъде обработена чрез третиране на риска по ISO/IEC 27001:2022. Идентифицирайте риска, определете собственик, изберете контроли, актуализирайте Декларацията за приложимост, внедрете плана за третиране и съхранете документирани доказателства. Това е силата на използването на СУИС вместо разпръснат набор от задачи по сигурността.

Как изглежда добрата практика

Зрелият оперативен модел за PAM и авариен достъп (break-glass) има пет повтарящи се рутинни дейности.

Първо, инвентаризирайте привилегирования достъп ежемесечно или непрекъснато. Включете човешки администратори, служебни акаунти, аварийни акаунти, облачни роли, CI/CD идентичности, потребители на бази данни, привилегировани помощни програми и администратори от трети страни.

Второ, прилагайте минимални привилегии чрез роли, повишаване на привилегиите точно навреме и одобрения. Постоянните привилегии трябва да са рядкост, обосновани и преглеждани по-често от стандартния потребителски достъп.

Трето, наблюдавайте привилегированото поведение. Журнализирайте удостоверяване, продължителност на сесията, използване на MFA, команди, промени в конфигурацията, експортиране на данни, неуспешни опити, ескалация на привилегии и изпълнение на привилегировани помощни програми.

Четвърто, тествайте аварийните акаунти (break-glass) преди аварията. Авариен акаунт, който никога не е бил тестван, е допускане, а не контрол.

Пето, докладвайте на ръководството. NIS2 и DORA издигат киберсигурността и ИКТ риска до отговорност на управителния орган. Съветът не се нуждае от всеки журнал на команда, но се нуждае от показатели: брой привилегировани акаунти, просрочени прегледи, аварийни активирания, администраторски акаунти на доставчици, неуспешни тестове, критични изключения и статус на отстраняването.

Тук инструментариумът на Clarysec става практически полезен. Библиотеката с политики дава управленския език. Zenith Blueprint дава последователността за внедряване. Zenith Controls дава съпоставяне на съответствието, връзки между контролите, поддържащи стандарти и одитна методология.

Следващи стъпки: превърнете аварийния достъп в устойчивост, готова за одит

Ако организацията ви не е тествала авариен достъп (break-glass) през последните 90 дни, започнете оттам. Не започвайте с работна среща за избор на инструмент. Започнете с доказателства.

1. Изградете или актуализирайте инвентара си на привилегированите акаунти.
2. Идентифицирайте всеки авариен акаунт (break-glass) и всеки авариен административен път.
3. Съпоставете всеки акаунт с бизнес собственик, собственик на система и въздействие върху данните.
4. Потвърдете покритието на политиките чрез Политика за управление на потребителски акаунти и привилегии Политика за управление на потребителски акаунти и привилегии на Clarysec или Политика за управление на потребителски акаунти и привилегии-sme Политика за управление на потребителски акаунти и привилегии - SME.
5. Използвайте Zenith Blueprint Zenith Blueprint, фазата Controls in Action, Steps 19, 20, 22 и 16, за да свържете привилегирования достъп, привилегированите помощни програми, прегледите на жизнения цикъл и offboarding.
6. Използвайте Zenith Controls Zenith Controls, за да съпоставите контролите 8.2, 5.18 и 8.15 по ISO/IEC 27002:2022 с очакванията за доказателства по NIS2, DORA, GDPR и NIST.
7. Проведете упражнение за доказателства при авариен достъп (break-glass) и запишете резултатите.
8. Добавете пропуските към плана за третиране на риска и проследете отстраняването до приключване.

Привилегированият достъп е власт. Аварийният достъп (break-glass) е аварийна власт. През 2026 г. организациите, които се възстановяват чисто от ransomware, откази на облачни услуги и сривове на идентичността, ще бъдат тези, които могат да докажат, че аварийният достъп е бил контролиран преди, по време на и след кризата.

Clarysec може да ви помогне да изградите това доказване — от политика до съпоставяне на контроли и доказателства, готови за одит. Започнете със Zenith Blueprint, комбинирайте го с Политика за управление на потребителски акаунти и привилегии и Политика за контрол на достъпа, след което използвайте Zenith Controls, за да покажете как вашата PAM програма поддържа ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 и COBIT 2019.