«Если политика безопасности не работает в пятницу вечером, когда в офисе никого нет, а тикеты сыплются в ServiceDesk — она написана впустую. Самый надёжный индикатор эффективности — твоя собственная готовность ей следовать в условиях стресса и неудобства.»
Бумажный щит и реальная защита
В российском IT, особенно под гнётом 152-ФЗ и ФСТЭК, политики безопасности часто превращаются в обрядовую магию. Их пишут не для защиты, а для галочки в отчёте перед проверяющими. Документ принимается, папка с резолюцией «Утвердить» ложится в SharePoint, и на этом жизнь политики заканчивается.
Но у этой формальности есть обратная сторона. Когда в инфраструктуре происходит реальный инцидент — утечка данных, компрометация учётной записи, несанкционированный доступ — первым делом смотрят не в логи, а в ту самую политику. И если между написанным на бумаге и реально работающими практиками лежит пропасть, это становится юридическим козырем против самой организации. Политика, которой не следуют,, это не нейтральный документ, а доказательство халатности.
Тест на личное доверие
Есть простой способ проверить, работает ли политика. Представь, что прямо сейчас система контроля доступа отключила твою учётную запись из-за «подозрительной активности» — например, попытки подключиться с необычного IP в нерабочее время. Вместо быстрого доступа к служебному порталу или базам данных тебе придётся звонить на круглосуточный номер службы безопасности, подтверждать личность, заполнять форму и ждать, пока инженер вручную проверит лог и разблокирует.
Если мысль об этой процедуре вызывает у тебя раздражение и желание найти обходной путь — «у коллеги же есть пароль от сервисной учётки» или «напишу в личку старшему админу» — значит, политика написана без учёта человеческого фактора. Она создаёт трение там, где должна обеспечивать плавный, но контролируемый поток.
Настоящая политика безопасности не ощущается как препятствие для своих. Она ощущается как защита. Ты знаешь, что если твой аккаунт заблокирован, то это сделала система, а не злоумышленник. И процедура восстановления, даже если она занимает 15 минут,, это не бюрократическая пытка, а понятный и предсказуемый процесс.
Где политики превращаются в фикцию
Разрыв между документом и реальностью чаще всего возникает в нескольких ключевых точках. Их стоит проверять в первую очередь.
Управление паролями
Политика требует сложных паролей из 12 символов, смены каждые 90 дней, без повторения предыдущих 5. Но при этом в Active Directory или другой системе управления учётными записями не настроена блокировка при переборе, не ведётся мониторинг аномальных попыток входа, а для сброса пароля достаточно ответить на контрольный вопрос «Девичья фамилия матери». Формально политика есть, фактически — защита держится на сознательности пользователей, что заведомо проигрышная стратегия.
Разграничение прав
В документе прописаны роли: оператор, администратор, аудитор. На деле 80% сотрудников входят в группу «Domain Admins» или локальных администраторов на своих рабочих станциях «для удобства». Политика есть, но механизм принуждения к её выполнению отсутствует. Системные настройки и GPO не отражают написанное.
Работа с инцидентами
По политике, любой подозрительный файл или письмо нужно отправлять в SOC для анализа. Фактически, чтобы отправить файл, нужно заполнить трёхстраничную форму в Jira, указать кучу полей, которых нет под рукой, и ждать ответа несколько часов. Естественно, сотрудник просто удалит подозрительное письмо и забудет. Процедура настолько неудобна, что сама провоцирует нарушения.
Как оживить документ
Превратить политику из бумажного тигра в рабочий инструмент можно, если сместить фокус с написания на внедрение. Не «что должно быть», а «как это будет работать в наших условиях».
- Автоматизация проверок. Не жди следующей проверки ФСТЭК. Напиши скрипт на PowerShell или Python, который раз в неделю прогоняет ключевые пункты политики: проверяет состав групп привилегированных пользователей, возраст паролей, настройки журналирования на критичных серверах. Отчёт сам ляжет на почту. Если политика требует шифрования съёмных носителей, скрипт может проверять наличие и статус BitLocker на всех ноутбуках.
- Интеграция в рабочие процессы. Процедура из политики не должна быть отдельным действием. Если политика требует согласования выдачи прав, эта кнопка «Запросить доступ» должна быть прямо в интерфейсе той CRM или ERP-системы, к которой нужен доступ. Запрос должен автоматически уходить на согласование владельцу данных и в службу безопасности, а не висеть в отдельном Excel-
файле.
- Метрики и обратная связь. Измеряй не «создана ли политика», а «сколько запросов на доступ было обработано по процедуре», «сколько времени в среднем занимает разблокировка учётной записи», «какой процент сотрудников прошёл ежегодное обучение». Эти цифры покажут, живёт ли документ.
Личный договор с самим собой
В конечном счёте, каждая написанная тобой политика, это публичное обещание. Обещание руководству, что риски под контролем. Обещание коллегам, что их работа защищена. Обещание регулятору, что правила игры соблюдаются.
Но самое главное, это обещание самому себе как специалисту. Если ты пишешь правило, в которое сам не веришь и которому не станешь следовать в критический момент, ты девальвируешь свою собственную экспертизу. Ты превращаешь свою работу из инженерии безопасности в документоведение.
В следующий раз, когда будешь ставить подпись «Разработал» под новой политикой, задай себе неудобный вопрос: «Я готов поставить на то, что эта мера сработает в два часа ночи при реальной атаке?». Если ответ — уверенное «да», документ имеет ценность. Если же где-
то внутри возникает сомнение, лучше остановиться и переработать пункт прямо сейчас. Потому что бумага простит любую нестыковку, а реальная угроза — нет.