Эшелонированная защита

Материал проходит ревью.

НовичокФундамент ~34 мин

Границы темы

Scope: как превратить приоритетный сценарий из threat model в несколько независимых, наблюдаемых и восстанавливаемых уровней защиты backend-сервиса.

Не рассматриваем: перечень appliances, обещание абсолютной защиты и накопление controls без анализа стоимости и общего отказа.

Что нужно знать заранее

Нужно уметь назвать нарушаемое свойство CIA и записать угрозу как сценарий с actor, путём, предусловием и влиянием. Эти навыки описаны в статьях «Триада CIA» и «Моделирование угроз».

Результаты обучения

После статьи читатель сможет:

1. отличить независимые слои от копий одной проверки;
2. покрыть сценарий предотвращением, обнаружением, сдерживанием и восстановлением;
3. найти общий failure mode нескольких controls;
4. решить, как сервис ведёт себя при отказе защитной зависимости;
5. проверить каждый слой негативным тестом или операционной процедурой.

Основная модель

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

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

Диаграмма

NIST определяет defense in depth как сочетание capabilities людей, технологий и операций на нескольких уровнях. CISA подчёркивает две причины layered approach: единственной техники, предотвращающей все атаки, не существует, а активность, прошедшая один барьер, должна с большей вероятностью быть обнаружена и локализована.

Основные термины

Термин	Роль	Пример
Preventive control	Не допускает опасное действие	Проверка object-level authorization
Detective control	Создаёт сигнал о подозрительном или запрещённом действии	Audit event и alert на массовые отказы
Containment	Ограничивает blast radius после проникновения	Tenant isolation, отдельные credentials, лимиты
Recovery	Возвращает доверенное состояние и услугу	Restore, key rotation, rollback
Compensating control	Снижает риск, когда основной control пока невозможен	Ручное подтверждение критичной операции
Common-mode failure	Одна причина одновременно выключает несколько мер	Общая неверная библиотека авторизации
Fail-closed	При отказе действие запрещается	Нельзя изменить payout details без policy decision
Fail-open	При отказе действие временно разрешается	Иногда допустимо для публичного чтения с низким риском

Контекст: изменение платёжных реквизитов

Сценарий угрозы:

Злоумышленник получает пользовательскую сессию и меняет payout account.
Обычная авторизация разрешает действие владельцу аккаунта.
Следующая выплата уходит на счёт злоумышленника.
Нарушается целостность финансовой настройки и доступность средств владельцу.

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

Диаграмма

End-to-end разбор слоёв

Этап	Мера	Какое предположение покрывает	Доказательство
Вход	Защищённая session cookie и expiry	Actor не должен подделать обычную сессию	Негативные auth tests
Доступ	Object-level authorization	Валидная сессия не даёт доступ к чужому account	Cross-tenant test
Критичное действие	Step-up authentication	Сессия могла быть украдена	Test без свежего подтверждения
Изменение	Pending period и state machine	Проверки могут ошибиться	Невозможен переход сразу в active
Обнаружение	Audit + уведомление	Предотвращение может пропустить actor	Доставка события и alert test
Сдерживание	Freeze до выплаты	Обнаружение должно успеть до ущерба	Учебный incident drill
Восстановление	Версионирование реквизитов	Нужен доверенный rollback	Проверенный rollback

Это не семь гарантий абсолютной безопасности. Это семь возможностей остановить или уменьшить один причинный сценарий.

Независимость слоёв

Три middleware, вызывающие одну и ту же policy-функцию с одной конфигурацией, — не три слоя. Ошибка в функции обходит их одновременно.

Проверьте независимость по пяти вопросам:

1. Используют ли меры разные сигналы и assumptions?
2. Выполняются ли они в разных компонентах или trust domains?
3. Есть ли у них общий код, config, identity provider или datastore?
4. Может ли один privilege отключить все меры и стереть evidence?
5. Остаётся ли возможность обнаружить и восстановиться после обхода prevention?

Независимость не означает изоляцию любой ценой

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

Минимальный воспроизводимый пример

Возьмите угрозу из предыдущего раздела и заполните control matrix:

threat: stolen session changes payout account
prevent:
  - control: object authorization
    test: another tenant receives 403
  - control: step-up authentication
    test: stale authentication receives step_up_required domain error
detect:
  - control: tamper-evident audit event
    signal: payout_account_change_total
contain:
  - control: 24h pending state
    test: payout worker rejects pending account
recover:
  - control: versioned account settings
    procedure: restore last verified version and rotate sessions
common_dependencies:
  - primary identity provider
owners:
  application: payments-team
  detection: security-operations

Ожидаемый результат

У каждого слоя есть:

• конкретный сценарий, который он меняет;
• owner;
• test, signal или recovery procedure;
• известная общая зависимость;
• поведение при собственном отказе.

Как проверить защиту

Проведите table-top exercise:

1. предположите обход session validation;
2. назовите следующий слой, способный остановить ущерб;
3. предположите обход object authorization;
4. проверьте, создаётся ли независимый audit signal;
5. предположите недоступность audit pipeline;
6. покажите, как pending state ограничивает выплату и как оператор видит деградацию.

Если после отказа одного слоя команда не знает состояние операции и способ восстановления, depth существует только на диаграмме.

Fail-open и fail-closed

Защитная зависимость может сама нарушить доступность. Поведение выбирают по операции, а не один раз для всего сервиса.

Операция	Разумный default при отказе policy-сервиса	Причина
Изменить payout account	Fail-closed	Ошибка создаёт высокий и труднообратимый ущерб
Прочитать публичный каталог	Ограниченный fail-open	Данные публичны, влияние невелико
Прочитать собственный заказ	Часто fail-closed или cached decision с коротким TTL	Нужен баланс confidentiality и availability
Принять telemetry event	Буферизовать с лимитом	Потеря detection ухудшает защиту, бесконечный buffer ломает сервис

Для каждого решения нужны timeout, ограниченный fallback, metric и срок действия degraded mode. «Временно разрешать всё» не является стратегией доступности.

Trade-offs

Решение	Выигрыш	Цена и новый риск
Step-up authentication	Снижает риск украденной сессии	Friction, зависимость от identity provider
Несколько policy engines	Разделение доменов	Drift правил и сложность диагностики
Подробный audit	Detection и расследование	Чувствительные данные в логах, стоимость хранения
Pending state	Время для containment	Задержка бизнес-операции и новая state machine
Автоматический freeze	Быстрое ограничение ущерба	False positive может нарушить доступность

Количество controls не является метрикой. Полезность определяется снижением конкретного риска после учёта новых failure modes.

Failure modes и типичные ошибки

1. Stacking products. WAF, gateway и middleware могут доверять одному и тому же поддельному header.
2. Нет detection. Prevention без сигнала оставляет команду в неведении после обхода.
3. Нет recovery. Backup без проверенного restore — надежда, а не слой.
4. Общий административный доступ. Один credential меняет policy, удаляет audit и отключает alerting.
5. Компенсация вместо исправления. Rate limit не устраняет broken authorization.
6. Неопределённый отказ. Timeout policy-сервиса превращается то в глобальный 500, то в случайный bypass.
7. Слишком много friction. Пользователи и операторы создают обходные процессы, которые становятся новым слабым слоем.

Практическое задание

Задача: выберите одну угрозу из своей threat model и спроектируйте минимальную эшелонированную защиту.

Обязательно включите:

1. preventive control;
2. независимый detection signal;
3. ограничение blast radius;
4. recovery procedure;
5. общий failure mode;
6. fail-open/fail-closed решение;
7. owner и способ проверки каждого слоя.

Критерии готовности: после мысленного отказа любого одного control остаётся либо барьер до полного impact, либо своевременный signal и проверенный recovery path.

Подсказка

Начните не с списка технологий, а с timeline атаки. Поставьте меры до опасного действия, во время него и после него.

Проверка знаний

ИНТЕРАКТИВНАЯ ПРОВЕРКА

Проверка знаний

0 / 4

01Какой набор лучше реализует defense in depth для изменения банковских реквизитов?

Авторизация объекта, подтверждение операции, аудит изменений и процедура откатаТри одинаковых middleware с одной общей конфигурациейТолько WAF перед приложением

02Что нужно определить для отказа внешнего policy-сервиса?

Fail-open или fail-closed для каждой операцииОграниченный timeout и budgetМетрику, alert и журнал решенияИгнорировать отказ: это security-компонент

03Добавление ещё одного control всегда уменьшает риск.

ВерноНеверно

04Восстановите порядок проектирования слоёв защиты.

1. Проверить слой и его отказ
2. Выбрать конкретный сценарий угрозы
3. Найти общий отказ и непокрытые этапы
4. Назначить независимые меры и владельцев

Проверено: 0 из 4

Самопроверка

1. Почему две одинаковые проверки не обязательно дают два слоя?
2. Как detection уменьшает риск, если не предотвращает действие?
3. Когда fail-open допустим?
4. Почему rollback является частью безопасности?

Ответы и критерии

1. Они могут иметь общий код, config и failure mode; один дефект обходит обе.
2. Он сокращает время до containment, уменьшает масштаб и даёт evidence для response.
3. Когда влияние разрешения операции при отказе явно ниже влияния недоступности, fallback ограничен по времени и scope, а деградация наблюдаема.
4. После нарушения целостности или компрометации нужно вернуть доверенное состояние; без recovery ущерб продолжается даже после блокировки actor.

Краткое резюме

• Defense in depth строится вокруг сценария угрозы, а не вокруг списка продуктов.
• Слои должны предотвращать, обнаруживать, ограничивать и восстанавливать.
• Независимость проверяется по assumptions, коду, данным, privileges и operations.
• Security control тоже может отказать и нарушить доступность.
• Каждый слой требует owner и доказательство работы.

Следующие шаги

Примените модель к аутентификации и авторизации: разделите защиту identity, session, object-level access, audit и response вместо одной проверки роли.

Источники

• NIST Glossary: defense in depth — определение стратегии через людей, технологии, операции и несколько слоёв.
• NIST SP 800-53 Rev. 5 — семейства preventive, detective, response и recovery controls и их взаимосвязи.
• CISA, Technical Approaches to Uncovering Malicious Activity — layered approach, detection и response при отсутствии единственной полной защиты.
• OWASP ASVS — проверяемые требования к техническим мерам web-приложений.