«Отключили один сервис, и всё встало, это не технический сбой, а симптом устаревшей архитектуры безопасности. Zero Trust меняет парадигму: вместо единой точки входа, которая становится единой точкой отказа, каждый ресурс сам решает, давать доступ или нет. Это не усложняет жизнь, а делает её устойчивее к сбоям.»
Почему «отвалился один — встало всё», это проблема старых моделей
Корпоративная ИТ-инфраструктура долгое время строилась на принципе «внутри периметра — безопасно». Достаточно один раз пройти аутентификацию на границе сети, и пользователь получает широкие привилегии для перемещения между внутренними системами. Эта модель эффективна до тех пор, пока не выходит из строя один из её центральных компонентов.
Архитектура, где безопасность завязана на монолитные системы, делает их отказ критичным. Контроллер домена Active Directory, центральный шлюз VPN, служба каталогов — их недоступность мгновенно лишает доступа ко всем зависимым ресурсам. Пользователь может быть в сети, но не сможет открыть почтовый клиент, потому что контроллер не отвечает на запросы аутентификации. Система управления взаимоотношениями с клиентами (CRM) не откроется, так как не может проверить членство пользователя в нужной группе. Инфраструктура не различает, какой именно сервис недоступен — она блокирует всё, потому что механизм авторизации остановлен.
Жёсткая привязка сессий через единый вход (SSO) усугубляет проблему. Идея в том, что успешный вход один раз даёт доверие на несколько часов. Но это же доверие становится уязвимостью, когда источник, подтверждающий состояние сессии, перестаёт отвечать. Любой сервис, которому требуется онлайн-проверка токена или статуса пользователя, перестаёт работать, даже если сам по себе полностью исправен. Это не ошибка конфигурации, а прямое следствие архитектурного выбора, где проверка доверия централизована и не имеет гибких обходных путей.
Каскадные блокировки возникают из-за непрозрачных цепочек зависимостей. Плановое обновление службы каталогов может нарушить работу почтового шлюза, который проверяет существование учётной записи перед отправкой письма. Техническое обслуживание федеративного провайдера идентичности (IdP) делает временно недоступным корпоративный облачный диск. При этом ни почтовый сервер, ни облачное хранилище не сломаны — у них просто исчез источник, подтверждающий права доступа. В старых моделях безопасность, это единый конвейер, и остановка на любом этапе парализует всю линию.
На практике это выглядит как многочасовые простои, пока ИТ-команды перезапускают кэши аутентификационных агентов или ждут восстановления центрального сервера. Чем масштабнее и сложнее система, построенная по такой модели, тем масштабнее потенциальный ущерб от отказа одного, казалось бы, второстепенного компонента.
Как Zero Trust перераспределяет «полномочия» при отказе сервиса
Архитектура Zero Trust основана на принципе «никому не доверяй, проверяй каждый запрос». Это не означает, что каждый сервис изобретает свои собственные политики безопасности с нуля. Речь о том, что механизм проверки прав выполняется на уровне самого защищаемого ресурса или через тесно связанный с ним прокси-компонент (шлюз). Такое разделение устраняет зависимость от единого центра принятия решений.
Независимая микросегментация доступа означает, что политики применяются индивидуально к каждому приложению, набору данных или API. Попытка получить доступ к финансовой системе проверяется отдельно от доступа к внутреннему порталу документов или тестовой среде. Даже если оба сервиса используют одного провайдера идентичности, каждый из них самостоятельно оценивает контекст запроса и принимает решение. Отказ одного сервиса не влияет на доступ к другому, потому что их механизмы контроля изолированы.
Динамическое установление доверия строится на агрегации и оценке множества сигналов. Запрос анализируется не только по логину и паролю, но и по контексту: с какого устройства и из какой сети поступает запрос, какое время суток, какова история предыдущих действий пользователя. Если система не может получить ответ от одного из источников данных (например, сервиса геолокации), она не блокирует доступ автоматически. Другие сигналы — использование доверенного устройства, подключение из корпоративной сети, отсутствие подозрительной активности — могут обеспечить достаточный уровень уверенности для продолжения сессии. Система не требует обязательного прохождения всех проверок одновременно, если совокупность альтернативных факторов подтверждает легитимность.
Такой подход позволяет избежать жёстких зависимостей. Например, при временной недоступности сервиса двухфакторной аутентификации по SMS система может увеличить вес других факторов — проверки сертификата на устройстве или анализа поведенческих паттернов. Это не снижение уровня безопасности, а адаптация к текущим условиям работы инфраструктуры. Агрегация данных из разных, часто избыточных, источников позволяет заменить временно недоступный компонент без ручного вмешательства администратора.
Локальные политики как аварийный режим позволяют поддерживать базовую функциональность при потере связи с центром управления. Агент безопасности на конечном устройстве или шлюз приложения может кэшировать актуальные политики доступа. Если соединение с центральным сервером политик (Policy Decision Point, PDP) прервано, агент применяет последнюю известную рабочую конфигурацию. Это режим ограниченной функциональности, но он позволяет продолжать критически важную работу до восстановления связи.
Кэширование работает и для учётных данных: при недоступности центрального сервера аутентификации пользователь может войти в систему с помощью ранее выданного и ещё не истёкшего токена обновления, если контекст устройства и сети не изменился. Механизмы инфраструктуры открытых ключей (PKI) также поддерживают автономную проверку — валидность сертификата можно проверить по локальному списку отозванных сертификатов (CRL) или через протокол OCSP Stapling, не требуя постоянного онлайн-запроса к центру сертификации.
Zero Trust не отменяет централизованное управление политиками. Он делает его не обязательным для сиюминутного функционирования, а поддерживающим. Администратор задаёт правила в центре, но их исполнение распределено и устойчиво к временным сбоям в каналах связи. Распределённость, это проектная особенность, повышающая отказоустойчивость всей системы безопасности.
Конкретный сценарий: отключился корпоративный портал
В классической модели корпоративный портал часто выступает единой точкой входа (SSO Portal) для десятков внутренних сервисов. Его отказ означает, что пользователи не могут получить новый токен аутентификации для доступа к любым системам. Даже если почтовый сервер или CRM технически работают, они будут отвергать запросы, так как не могут проверить валидность сессии через недоступный портал. Работа встаёт.
В архитектуре Zero Trust портал — лишь один из многих ресурсов. Его отключение не затрагивает механизмы доступа к другим системам. Каждое критичное приложение (CRM, ERP, хранилище) имеет собственный шлюз (Application Gateway) или встроенный механизм проверки политик. Эти шлюзы могут использовать реплицированные в другом дата-центре сервисы проверки токенов или работать с кэшированными политиками.
На практике это выглядит так: портал не отвечает, но пользователи, уже работающие в CRM, продолжают свою сессию, так как её валидность проверяется независимо. Доступ к облачному хранилищу продолжается через его собственный защищённый API-шлюз, который синхронизирует политики из резервного источника. Сбой затронул только навигационный узел, но не сами бизнес-процессы. Пользователи могут испытывать неудобства из-за отсутствия единого меню, но доступ к данным и основным инструментам сохраняется.
Конкретный сценарий: перестал отвечать сервис TOTP (одноразовых паролей)
TOTP — популярный метод двухфакторной аутентификации, но его сервер, это единая точка отказа. Если он перегружен или неисправен, все попытки входа с использованием кодов из приложений типа Google Authenticator будут неудачны.
В Zero Trust TOTP — лишь один из возможных факторов в многофакторной схеме. Политика доступа может быть настроена на использование нескольких альтернативных методов. Если сервис TOTP недоступен, система автоматически предлагает резервный вариант:
- Push-уведомление в мобильное приложение компании.
- Аппаратный ключ безопасности (FIDO2/U2F).
- Аутентификация по сертификату на доверенном устройстве.
- Резервный одноразовый код, отправленный на зарегистрированную резервную почту (для менее критичных сценариев).
Переключение происходит автоматически на основе заранее определённых политик, без необходимости вмешательства пользователя или администратора. Для уже активных сессий политики риска могут временно ужесточиться: например, доступ на чтение сохраняется, а операции на выгрузку данных потребуют дополнительного подтверждения через альтернативный канал. Работа не останавливается, но потенциально рискованные действия временно ограничиваются.
Для администраторов должен быть предусмотрен аварийный доступ (break-glass), не зависящий от основной инфраструктуры MFA, например, через аппаратные токены, хранящиеся в сейфе. Это позволяет восстановить контроль над системой даже при полном отказе основных сервисов аутентификации.
Что нужно проверить в архитектуре, чтобы сбои не останавливали работу
Внедрение Zero Trust для повышения отказоустойчивости требует целенаправленной проверки архитектуры на устойчивость к отказам компонентов. Недостаточно просто развернуть шлюзы и политики — нужно убедиться, что система деградирует корректно.
Ключевые точки проверки:
| Элемент архитектуры | Что проверять | Желаемый результат при отказе |
|---|---|---|
| Точки принуждения политик (PEP) | Наличие географически распределённых реплик, настройка автоматического переключения при отказе (failover). | Запросы перенаправляются на рабочую реплику с минимальной задержкой. |
| Сервер политик (PDP) | Механизмы кэширования политик на PEP или агентах. Синхронизация изменений (delta-sync). | При недоступности PDP точки принуждения продолжают работать по последним известным политикам. |
| Провайдер идентичности (IdP) | Поддержка долгоживущих токенов обновления (Refresh Tokens), резервные методы аутентификации, break-glass доступ. | Пользователи могут обновить сессию или аутентифицироваться альтернативным способом. |
| Сервисы контекста (геолокация, MDM) | Поведение системы при недоступности одного или нескольких источников контекстных данных. | Система присваивает фактору «неизвестно» нейтральный или консервативный вес, не блокируя доступ полностью, если другие факторы в норме. |
| Сертификаты и PKI | Настройка проверки статуса отзыва (CRL/OCSP). Поведение при недоступности серверов проверки. | Режим «soft fail»: если сервер проверки недоступен, но сертификат валиден по дате и подписан доверенным УЦ, доступ разрешается. |
Критически важно проводить плановые тесты в режиме «деградированной работы» (degraded operation). Это не абстрактная проверка, а целенаправленное отключение ключевых компонентов в контролируемых условиях:
- Отключить один из дата-центров, где расположены PEP.
- Остановить сервер центра политик.
- Сымитировать недоступность провайдера MFA.
Цель — увидеть, продолжают ли пользователи иметь доступ к критичным бизнес-приложениям, и какие функции ограничены. Такие учения выявляют скрытые зависимости и точки отказа, которые не видны на схеме архитектуры.
Итог: надёжность через избыточность проверок, а не через единую точку входа
Zero Trust перераспределяет ответственность за безопасность. Вместо одного высокого замка на воротах, который при падении открывает всё, создаётся множество независимых постов проверки. Каждый пост способен принимать решение автономно, основываясь на локальных данных и кэшированных правилах. Это защищает от каскадных сбоев, когда отказ одного сервиса парализует всю инфраструктуру.
Отключение одного компонента становится локальным инцидентом, а не общесистемной катастрофой. Не нужно останавливать бизнес-процессы из-за перегруженного портала аутентификации или неработающего SMS-шлюза. Каждый ресурс проверяет доступ независимо, используя доступные в данный момент сигналы и политики.
Конечная цель — не увеличение количества шагов аутентификации, а повышение операционной устойчивости. Система продолжает работать, потому что безопасность встроена не в точку входа, а в каждый запрос и каждое действие, и эта встроенность избыточна и отказоустойчива по своей природе.