Политика безопасности ломается не в атаке, а в мелочах на входе

Политика безопасности ломается не в атаке, а в мелочах на входе

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

Проверьте три вещи:
— кто владелец правила и кто отвечает за исключения;
— где прописаны уровни доступа, сроки хранения, порядок ревокации;
— как фиксируются нарушения и кто имеет право их закрывать.
Если в политике нет исполнителя, она существует только на бумаге. Бумага, как известно, атак не отражает.

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

Еще один слабый участок — пересечение с реальными процессами. Если в политике написано одно, а в IAM, DLP и бэкапах другое, система будет следовать не тексту, а фактической конфигурации. Поэтому документ без регулярной сверки с процессами — это архив ошибок.

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