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

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

Документ выглядит солидно, пока в нём есть общие слова. Но система работает по конкретике: кто имеет доступ, к чему, на каких условиях и кто это проверяет. Если этого нет, политика превращается в декорацию для отчёта.

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

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

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

Если в документе нет владельца, контроля и процедуры исключений, это не политика безопасности. Это текст для успокоения начальства. Читайте документацию. Инцидент исчерпан.