Архитектура нулевого доверия полезна только тогда, когда перестаёт быть лозунгом и становится новой моделью доверия внутри системы.
Глава показывает, как явная проверка идентичности, применение политик, сегментация и поэтапная миграция переводят безопасность из слепой веры в сеть в проверяемые архитектурные решения.
Для ревью дизайна это удобный способ обсуждать архитектуру нулевого доверия не как целевое состояние из презентации, а как последовательность шагов с трением в пользовательском опыте, накладной задержкой и операционной ценой.
Практическая польза главы
Практика проектирования
Проектируйте доступ через идентичность, контекст запроса, точки принятия и применения политик, а не через доверие к сети.
Качество решений
Проверяйте, где проходит граница доверия, как принимается решение по доступу и как быстро можно отозвать права после компрометации.
Аргументация на интервью
Стройте ответ вокруг маршрута: субъект, ресурс, контекст, политика, применение решения и журнал аудита.
Формулировка компромиссов
Явно обсуждайте цену сегментации, взаимной TLS-аутентификации, краткоживущих учётных данных, задержки проверки и сложности эксплуатации.
NIST
SP 800-207
Базовый документ NIST по архитектуре нулевого доверия.
Периметровая модель держится на одном допущении: попал внутрь сети — значит, тебе можно доверять. Стоит этому допущению сломаться один раз, и атакующий ходит по системе свободно. убирает это допущение: безопасность строится не вокруг «внутри/снаружи», а вокруг идентичности, контекста запроса и постоянной проверки доступа.
исходит из того, что само по себе не доказывает доверие. Каждый запрос оценивается заново: кто обращается, к какому ресурсу, с каким контекстом и через какую точку применения политики — и любой из этих ответов может закрыть доступ.
Принципы архитектуры нулевого доверия
Никому не доверять по умолчанию
Доверие не наследуется от предыдущего запроса. Каждый раз проверяется заново: кто субъект, в каком он контексте, к какому ресурсу обращается и какую должен пройти.
Минимально необходимые привилегии
Права выдаются под конкретную задачу и на ограниченное время. Чем шире и дольше живёт доступ, тем больше атакующий получит вместе с одной украденной учёткой — отсюда опора на .
Исходить из возможной компрометации
Вопрос не «пустят ли злоумышленника внутрь», а «что он сможет сделать, когда уже внутри». Отсюда сегментация, наблюдаемость, быстрый и контроль .
База
Identification -> AuthN -> AuthZ
Идентичность и модель авторизации — фундамент, без которого поэтапное внедрение архитектуры нулевого доверия рассыпается.
Референсная архитектура
Идентичность
- Единая модель для пользователей, сервисов, устройств и .
- , жизненный цикл учётных записей, и ключи доступа.
- вместо долгоживущих секретов.
Политики доступа
- : // или .
- Решение учитывает субъект, действие, ресурс и контекст запроса.
- как базовый режим для новых ресурсов.
Применение политик
- в шлюзе API, сервисной сетке и приложениях.
- и для трафика восток-запад.
- для решений по доступу.
Телеметрия и реакция
- через логи, метрики и .
- и динамические ограничения.
- Быстрое и автоматический отзыв доступа.
Контекстные сигналы для решения по доступу
Уверенность в идентичности
Вопрос: Кто запрашивает доступ и насколько надёжна проверка подлинности?
Реализация: , ключи доступа, защита от фишинга и привязка учётных данных к устройству.
Состояние устройства
Вопрос: Соответствует ли устройство базовым требованиям безопасности?
Реализация: : управление устройством, обновления, шифрование диска и признаки взлома.
Идентичность рабочей нагрузки
Вопрос: Как сервис подтверждает свою подлинность при вызове другого сервиса?
Реализация: Сертификаты рабочих нагрузок, SPIFFE/SPIRE и .
Чувствительность данных
Вопрос: Насколько критичен ресурс и требуется ли доступ по запросу?
Реализация: Классификация данных, и режим только для чтения по умолчанию для рискованных сценариев.
Поведенческий контекст
Вопрос: Есть ли отклонение по географии, времени, устройству или паттерну запросов?
Реализация: , , и временное ограничение действий.
Матрица применения политик
| Контур | Точка применения политики | Проверки | Действие при отказе |
|---|---|---|---|
| Внешний API (север-юг) | Шлюз API + межсетевой экран веб-приложений | Аутентификация и авторизация, утверждения в токене, проверка схемы, ограничения частоты. | Блокировать запрос, записать решение в и передать сигнал в центр мониторинга безопасности (SOC). |
| Сервис-сервис (восток-запад) | Сервисная сетка | Взаимная -аутентификация, идентичность сервиса, политика доступа сервиса, сегментация пространства имён. | Разорвать соединение и записать решение вместе с идентификатором трассировки. |
| Контур данных | Прокси БД / слой доступа к данным | Атрибутные правила, правила на основе связей, ограничения на уровне строк и столбцов, ограниченные по времени учётные данные. | Отклонить запрос и запустить для рискованного сценария. |
| Административные операции | Шлюз привилегированного доступа | , , запись сессии. | Не выдавать временный токен повышения прав и уведомить владельцев сервиса. |
| CI/CD и развёртывание | Политики как код + контроль допуска | Подписанные артефакты, и политика окружения. | Остановить развёртывание и автоматически создать задачу безопасности. |
Операционные метрики
Покрытие сильной аутентификацией у привилегированных пользователей
Цель: 100%
Без устойчивой архитектура нулевого доверия быстро превращается в формальность.
Покрытие взаимной -аутентификацией для трафика восток-запад
Цель: >= 95%
Показывает, насколько межсервисные вызовы защищены внутри системы, а не только на внешней границе.
Доля административных операций через доступ по запросу
Цель: >= 90%
Снижает риск постоянного и .
Среднее время отзыва скомпрометированной идентичности
Цель: < 15 минут
Чем быстрее отзыв, тем меньше окно компрометации и .
Покрытие журналированием решений по доступу
Цель: 100%
Без расследования и подтверждение соответствия становятся ненадёжными.
План внедрения
1. Инвентаризация
Соберите карту идентичностей, сервисов, секретов, критичных путей и текущих .
2. Базовая сильная аутентификация
Включите многофакторную аутентификацию и ключи доступа для пользователей, а для сервисов — ; уберите общие учётные данные, чтобы у скомпрометированного секрета не было одного владельца на всех.
3. Централизация политик
Вынесите правила доступа в общий слой политик и включите для новых ресурсов.
4. Сегментация и применение политик
Разделите контуры — промышленную среду и тестовые окружения, уровни данных, административные пути и ключевые точки трафика, — чтобы компрометация одного сегмента не открывала вход в соседние.
5. Непрерывная проверка
Настройте мониторинг , регулярное ревью прав и автоматическую ротацию учётных данных.
Типичные антипаттерны
- Считать продуктом, а не архитектурным подходом и операционной моделью.
- Ограничиться (виртуальной частной сети) без пересмотра идентичности и модели авторизации — снаружи новее, внутри всё то же доверие по умолчанию.
- Разрешать всё внутри кластера и называть это архитектурой нулевого доверия.
- Не иметь процессов отзыва доступа и даже при сильной аутентификации.
- Оставлять постоянный административный доступ без , и явной цепочки согласования.
Быстрый практический критерий: если после компрометации одного сервиса атакующий получает «почти всё», значит архитектура нулевого доверия внедрена только номинально.
Источники
Связанные главы
- Идентификация, аутентификация и авторизация (AuthN/AuthZ) - Фундамент архитектуры нулевого доверия: надёжная идентичность субъекта и проверяемая .
- Модели контроля доступа: список управления доступом (ACL), ролевая (RBAC), атрибутная (ABAC) и модель на основе связей (ReBAC) - Показывает, из каких моделей строится .
- Паттерны управления секретами - Дополняет архитектуру нулевого доверия практикой , ротации и контроля секретов.
- Архитектура сервисной сетки (service mesh) - Показывает техническую реализацию взаимной -аутентификации, идентичности сервиса и применения политик для трафика восток-запад.
- API Security Patterns - Доводит архитектуру нулевого доверия до внешней границы программного интерфейса (API): проверка токенов и защита от злоупотреблений там, где запросы приходят извне.