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

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

Лев Федоров, руководитель отдела продаж MULTIFACTOR компании МУЛЬТИФАКТОР, рассказывает, почему аварийный доступ стоит рассматривать как отдельный процесс, какие риски возникают при отсутствии регламента и как практики управления привилегированными доступами помогают ограничивать аварийные права по времени, фиксировать их использование и проверять каждый случай после завершения работ.

На встречах с заказчиками мы чаще обсуждаем штатный доступ: какие группы защищать, куда подключать MFA, как не усложнить работу пользователям. Сценарий «а что делать, если недоступен сам контур доступа» обычно всплывает позже, иногда уже после первого серьёзного сбоя.

В этот момент появляется знакомый аврал: кто-то ищет «главный» пароль, пишет в личный чат, пытается быстро выдать себе права. Проблема не только в простое. Потом сложно понять, кто получил доступ, что сделал в системе и закрыли ли этот доступ после работ.

Зрелые ИТ- и ИБ-команды обычно относятся к аварийному доступу как к отдельному процессу. Они заранее определяют, кто может запустить такой сценарий, какие системы он покрывает, какие права допустимы и что должно попасть в логи. Именно это помогает восстановить сервис быстро, но не превратить исключение в постоянную уязвимость. Практики управления привилегированными доступами также рекомендуют ограничивать аварийные права по времени, фиксировать их использование и проверять каждый случай после завершения работ.

Статистика показывает, насколько критична эта зона риска. По данным команды BI.ZONE TDR, почти 40% киберинцидентов, зафиксированных с января по сентябрь 2025 года, связаны с использованием или компрометацией привилегированных учётных записей. При этом в 57% случаев злоумышленники получали доступ через действующие учётные данные, а 30–40% привилегированных аккаунтов в разных системах используют одинаковые или схожие пароли.

Аварийный доступ не должен быть удобной лазейкой

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

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

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

До инцидента важно договориться о базовых вещах:

• какие события считаются аварией;
• кто может запросить экстренный доступ;
• кто согласует его вечером, ночью и в выходные;
• какие права можно выдать и на какой срок;
• когда после работ нужно сменить пароль, ключ или токен;
• где будут зафиксированы действия.

В этой статье не будем разбирать весь набор PAM-инструментов и восстановление инфраструктуры. Посмотрим на аварийный доступ через призму аутентификации: как дать людям возможность восстановить сервис, но не передавать общие пароли и не терять контроль над действиями пользователей.

Не всегда нужно искать «главный пароль»

В момент сбоя первое решение часто выглядит очевидным: найти пароль от привилегированной учётной записи и передать его тому, кто сможет быстро восстановить сервис. Это действительно может сработать быстро. Но потом появляются неудобные вопросы: кто видел этот пароль, где он сохранился, кому его переслали и сменили ли после.

Поэтому зрелые команды стараются заранее разделить аварийные сценарии, а не сводить все проблемы к одной общей учётной записи.

Не работает второй фактор у конкретного сотрудника, но MFA в целом доступна. Например, администратор потерял телефон, не получает пуш или срочно подключается вне обычного графика. В такой ситуации нет смысла сразу давать ему общий пароль. Безопаснее выдать персональное исключение на ограниченное время, выполнить работы и затем закрыть его.

Недоступен сам контур MFA. Например, есть проблема со связью, недоступна облачная часть, API или адаптер. Здесь заранее должна быть выбрана политика: запретить вход, разрешить его после успешного первого фактора только определённым группам или учётным записям либо, в исключительных случаях, всем пользователям.

Недоступен весь привычный контур доступа. Если одновременно не работают MFA, PAM, служба каталогов или другие критичные компоненты, может понадобиться отдельная аварийная учётная запись. Её пароль, ключ или другой секрет стоит хранить отдельно от основной системы доступа. И заранее определить ограниченный круг людей, которые могут получить к нему доступ.

Главная мысль простая: чем реже приходится вручную передавать постоянные пароли, тем меньше вероятность, что аварийный доступ сам станет проблемой.

Когда пароль действительно надо менять

После аварийного доступа пароль часто нужно менять. Но не каждый раз автоматически и не вслепую. Сначала стоит понять: мог ли пароль, ключ или токен попасть к человеку, которому он не должен быть доступен постоянно?

Ротация нужна обязательно, если:

• использовалась общая аварийная учётная запись;
• постоянный пароль или ключ передавали нескольким сотрудникам;
• секрет отправляли через чат, почту или другой неподходящий канал;
• доступ получал внешний подрядчик;
• есть подозрение, что учётные данные могли быть скомпрометированы.

Если же доступ был персональным, ограниченным по времени и общий пароль никому не передавался, сначала нужно закрыть временное исключение, завершить сессию, отозвать права и проверить журналы. Смена пароля зависит от конкретной ситуации и внутреннего регламента.

По наблюдениям из общения с заказчиками, именно общие технические и аварийные учётные записи чаще всего оказываются слабым местом. Они создаются «на всякий случай», используются редко, а потом никто не может уверенно сказать, кому известен пароль и не используется ли он в старой интеграции. Поэтому зрелая практика — относиться к таким секретам как к контролируемому резерву: ограничивать доступ к ним, учитывать использование и ротировать после раскрытия. Такой подход совпадает с рекомендациями по аварийным учётным записям: ограничивать круг пользователей, фиксировать активацию и выполнять смену учётных данных после использования.

Отдельно стоит помнить о технических и сервисных учётных записях. Их пароль может использоваться в интеграциях, поэтому смена «на всякий случай» иногда сама создаёт новый инцидент. Перед ротацией важно понимать, какие сервисы используют этот секрет, кто обновит конфигурации и как проверить, что всё продолжает работать.

MFA и bypass: сценарий нужно настроить заранее

MFA как раз и помогает не сводить любой сбой к передаче общего пароля. Но bypass не должен превращаться в кнопку «выключить второй фактор». Это резервный сценарий на случай, когда штатная проверка MFA недоступна.

На обсуждениях с ИТ- и ИБ-командами мы видим, что единой настройки для всех ресурсов не существует. Для части систем безопаснее не пускать никого до восстановления штатного контура. Для других кратковременный простой может быть критичнее: например, когда небольшой дежурной группе нужно подключиться, чтобы восстановить сервис. Важно принять это решение заранее, а не искать ответ ночью в рабочем чате.

У нас заказчик задаёт политику bypass на уровне адаптера. Для разных ресурсов можно определить разные правила: запретить вход, разрешить его после успешного первого фактора только определённым группам или учётным записям либо, в исключительных случаях, всем пользователям.

MULTIFACTOR работает в гибридной модели: адаптеры устанавливаются в контуре заказчика и интегрируются с защищаемыми ресурсами, а облачная часть отвечает за централизованную работу второго фактора, администрирование и журналирование. Для критичных систем можно развернуть несколько адаптеров в разных зонах, чтобы отказ одного компонента не останавливал проверку доступа. Если облачная часть недоступна, адаптер отрабатывает заранее выбранную политику bypass. Для отдельных адаптеров в документации предусмотрена настройка поведения при недоступности API: запретить вход либо пропустить второй фактор.

Журналы нужны не только после инцидента

Журналирование часто вспоминают уже после того, как сервис восстановили. Но без логов сложно ответить на базовые вопросы: кто запросил доступ, кто согласовал исключение, кто вошёл, как долго работал и закрыли ли доступ после этого.

Зрелая практика — не оставлять аварийный путь за пределами контроля только потому, что он нужен редко. Наоборот, в таких ситуациях особенно важно сохранить след: аварийный вход может обходить часть привычных согласований, а значит, его использование должно быть зафиксировано и затем проверено независимо от исполнителя. Рекомендации по организации аварийного доступа также делают акцент на журналировании активации, обосновании, времени начала и окончания, а также последующем разборе каждого случая.

Для каждого аварийного случая стоит сохранить:

• номер заявки или инцидента и причину;
• какой сервис был затронут;
• кто запросил, выполнил и согласовал доступ;
• какие права и на какой срок были выданы;
• срабатывал ли bypass или другой резервный сценарий;
• успешные и неуспешные попытки входа;
• когда работы завершились, были ли отозваны права и требовалась ли смена пароля.

В MULTIFACTOR журналы ведутся на двух уровнях: в личном кабинете и на адаптерах, которые работают в инфраструктуре заказчика.

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

На уровне адаптера фиксируется работа конкретной интеграции с защищаемой системой, в том числе срабатывание настроенной политики bypass при недоступности облачной части. Логи личного кабинета и адаптеров можно собирать отдельно и передавать в SIEM. Тогда их можно связать с событиями VPN, операционной системы, PAM, базы данных или другого защищаемого ресурса. MULTIFACTOR поддерживает журналирование транзакций аутентификации, API для получения событий журнала и передачу событий адаптеров в Syslog/SIEM.

В гибридной модели журналы хранятся один год. Если заказчик разворачивает облачную часть решения в своём контуре, то есть использует приватное облако, журналы остаются у него. Срок хранения в этом случае он определяет самостоятельно, исходя из внутренних политик и требований регулирования.

При этом одного журнала MFA недостаточно. Он покажет, кто и как проходил аутентификацию и какие изменения вносились в настройки MFA. Но чтобы восстановить полную картину, его нужно сопоставить с карточкой инцидента, системными логами и, если используется PAM, с журналом или записью привилегированной сессии.

Что стоит проверить заранее

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

Перед следующим инцидентом полезно проверить:

1. Есть ли перечень критичных систем, их владельцев и допустимого времени простоя.
2. Понятно ли, кто запрашивает, согласует, использует и проверяет аварийный доступ, включая резервную цепочку на вечер, ночь и выходные.
3. Есть ли для каждой критичной системы политика на случай недоступности MFA: запретить вход, разрешить его после первого фактора ограниченной группе или, при необходимости, всем пользователям.
4. Предусмотрены ли персональные временные исключения вместо передачи общих паролей.
5. Хранятся ли аварийные секреты отдельно от основного контура доступа.
6. Понятно ли, когда после работ нужно менять пароль, ключ или токен.
7. Передаются ли логи аутентификации и административных действий в SIEM и связываются ли они с заявками или инцидентами.
8. Проверяется ли аварийный сценарий до реального сбоя и после изменения критичной инфраструктуры или смены ответственных.

Хорошо организованный аварийный доступ не означает, что безопасность временно отменяется. Его смысл в другом: быстро вернуть сервис в работу и при этом сохранить понимание, кто, зачем и каким способом получил доступ.

Используемые термины

ИБ — информационная безопасность.

VPN (Virtual Private Network) — виртуальная частная сеть. Защищённый канал связи, который позволяет удалённым сотрудникам и администраторам подключаться к внутренней сети организации.

VDI (Virtual Desktop Infrastructure) — виртуальный рабочий стол. Технология, при которой пользователь работает не на локальном ПК, а на виртуальной машине, размещённой в дата-центре организации.

MFA (Multi-Factor Authentication) — многофакторная аутентификация. Механизм проверки личности, при котором для входа требуется более одного фактора.

Токен — средство аутентификации.

PAM-инструменты (Privileged Access Management) — средства управления привилегированным доступом. Класс решений, которые централизованно хранят учётные данные привилегированных аккаунтов, выдают временные права, записывают сессии и контролируют действия администраторов.

Пуш (push) — сообщение, которое приходит на зарегистрированное устройство пользователя.

API (Application Programming Interface) — программный интерфейс приложения. Набор правил и методов, по которым одна программа обращается к функциям другой.

Bypass — заранее настроенный резервный сценарий, который позволяет пройти аутентификацию, когда основной механизм недоступен.

Syslog — системный журнал (протокол сбора и передачи логов). Стандартный механизм, по которому устройства и приложения отправляют события (логи) в централизованное хранилище или SIEM.

SIEM (Security Information and Event Management) — система управления событиями и инцидентами информационной безопасности. Платформа, которая собирает логи из разных источников, коррелирует их и помогает выявлять и расследовать инциденты.

Лев Федоров, руководитель отдела продаж MULTIFACTOR компании МУЛЬТИФАКТОР