Аварийный доступ к критичным системам: как организовать процедуру «Break-Glass» без компромиссов для безопасности

В ИТ-инфраструктуре любой организации существуют ситуации, когда штатные механизмы аутентификации и авторизации недоступны или не работают. Сервер баз данных «упал» в 3 часа ночи в выходной день, система мониторинга ослепла, а штатный администратор недоступен. В такие моменты на сцену выходит процедура аварийного доступа, известная в индустрии как «Break-Glass» («разбить стекло»).

Однако именно аварийный доступ является одной из самых уязвимых зон для инсайдеров и внешних злоумышленников. Как обеспечить непрерывность бизнеса, не превратив при этом систему безопасности в «решето»?

Итак существуют три кита аварийного доступа: санкционирование в нерабочее время, ротацию учетных данных и неотвратимость аудита.

1. Кто санкционирует доступ в нерабочее время?

Главная дилемма ночных инцидентов: бизнес требует немедленного восстановления, а служба безопасности (ИБ) не может выдать права на основе устного звонка. Отсутствие владельца бизнеса или CISO не должно парализовать работу.

Необходимо создать Матрицу эскалации и дежурных смены. В нерабочее время право санкционирования аварийного доступа делегируется на основе заранее утвержденной матрицы.

1) Двухфакторное одобрение: Выдача прав не может быть одобрена одним человеком. Требуется подтверждение от дежурного руководителя ИТ-инфраструктуры (или дежурного менеджера бизнеса) И дежурного офицера ИБ (SOC/L1-L2).

2) Цифровой след вместо слов: Устное разрешение по телефону — это кошмар для аудита. Санкционирование должно происходить через защищенные каналы: создание тикета через мобильное приложение Service Desk, подтверждение через корпоративный мессенджер с интеграцией в PAM-систему или использование SMS/Push-кодов для одобрения запроса.

3) Автоматическое санкционирование на основе риска (ABAC): В современных реалиях 2026 года передовые компании используют контекстный доступ. Если PAM-система видит, что сессия запрашивается с доверенного IP-адреса дежурного инженера, в ответ на алерт от системы мониторинга о падении критичного узла, она может выдать доступ автоматически, но с жестким лимитом по времени (например, 15 минут) и обязательным постфактум-аудитом.

2. Обязательная смена пароля и эфемерные учетные записи

Исторический подход, когда «аварийный пароль» от root-учетки хранился в сейфе или в зашифрованном Excel-файле, сегодня считается грубейшим нарушением комплаенса.

Смена пароля после его использования обязательна! Аварийный пароль считается скомпрометированным. Он мог быть перехвачен при передаче, введен на зараженном домашнем ПК инженера или просто сохранен в буфере обмена.

Правильно выстроена система:

1. Отказ от статических паролей: Аварийный доступ должен предоставляться через PAM-системы (Privileged Access Management). Система генерирует одноразовый пароль или временный SSH-ключ, который действует только на время инцидента.

2. Автоматическая ротация: В момент закрытия тикета инцидента или истечения таймаута сессии PAM-система автоматически меняет пароль целевой учетной записи на критичном сервере/СУБД. Инженер, который только что работал, физически не сможет зайти повторно по стаому паролю.

3. Изоляция сессий: Доступ предоставляется не через прямое знание пароля, а через прокси-шлюз PAM. Инженер подключается к шлюзу, а шлюз «подставляет» актуальные учетные данные к целевой системе. Это исключает перехват пароля кейлоггерами на машине администратора.

3. Фиксирование данных: принцип неотвратимости аудита

Аварийный доступ не означает анонимность. Напротив, уровень фиксирования данных в таких ситуациях должен быть максимальным.

Что и куда должно писаться:

• Кто и когда: Точное время запроса, ФИО инженера, данные его устройства (отпечаток браузера, IP, MAC, статус антивируса).
• Кто разрешил: Учетная запись и метод подтверждения того, кто санкционировал доступ (ID тикета, запись звонка, лог подтверждения в PAM).
• Что делал (Запись сессий): Для критичных систем (серверы, СУБД, сетевое оборудование) обязательно включается видео- и текстовая запись терминальной сессии. Каждая введенная команда должна логироваться в неизменяемое хранилище.
• Независимость логов: Журналы должны передаваться по протоколу syslog в изолированный SIEM-комплекс или SOC в режиме, близком к реальному времени. Инженер, использующий аварийный доступ, не должен иметь прав на остановку логирования или очистку логов на целевой машине.

Постинцидентный разбор

В течение 24 часов после закрытия аварийного инцидента служба ИБ обязана провести разбор записи сессии. Цель — убедиться, что инженер выполнил только те действия, которые были санкционированы для восстановления сервиса, и не воспользовался ситуацией для внесения несанкционированных изменений (так называемый «форс-мажорный инсайд»).

Аварийный доступ — это неизбежное зло, на которое бизнес имеет полное право рассчитывать в экстренной ситуации. Однако безопасность не должна отключаться вместе с рабочим освещением в офисе. Делегирование прав санкционирования на дежурные смены, автоматическая ротация эфемерных паролей и тотальное, независимое журналирование позволяют достичь главного баланса: спасти бизнес от простоя, но оставить злоумышленнику (или нерадивому сотруднику) нулевой шанс на скрытые действия.

P.S.
Чек-лист идеальной процедуры Break-Glass

1. Существует ли локальный «аварийный» регламент, ознакомленный под роспись всеми дежурными инженерами и руководителями?

2. Назначены ли дежурные по ИБ и ИТ на ночное время и выходные дни с четкой матрицей контактов?

3. Исключено ли использование статических аварийных паролей в пользу PAM-систем с генерацией эфемерных сессий?

4. Настроена ли автоматическая ротация учетных данных сразу после завершения сессии?

5. Ведется ли запись командной строки / видеозапись сессий и передаются ли логи в независимый SIEM?

6. Есть ли процесс обязательного аудита записей аварийных сессий в течение суток после инцидента?