“Любая политика безопасности, это по сути набор правил, написанных людьми. Люди мыслят категориями процессов, ролей и этапов, а машины проверяют строгие логические условия. Противоречие возникает в момент перевода человеческой логики в машинную проверку, и чем раньше ты его обнаружишь, тем меньше будет цена согласования, переделок и оправданий перед проверяющими.”
Противоречия в политиках информационной безопасности — не теоретическая проблема, а ежедневный риск. Формально противоречие, это ситуация, когда один пункт политики разрешает действие, а другой его запрещает, или когда требования невыполнимы в принципе. На практике всё запутаннее: противоречия прячутся между уровнями документов, в формулировках, зависящих от трактовки, и в нестыковках политик с реальной ИТ-инфраструктурой. Пока эти противоречия не зафиксированы в акте проверки, они просто «особенности документации». Как только проверяющие их находят, они превращаются в нарушения, требующие исправления и объяснений.
Почему противоречия появляются даже в хороших политиках
Представьте процесс создания пакета документов по ИБ. Часто это итеративный труд нескольких отделов: юристы пишут общие формулировки, специалисты по безопасности — технические требования, а представители бизнес-подразделений — исключения и поправки. Каждая редакция вносится в отдельный файл, а итоговый документ собирается чуть ли не вручную. В этом и кроется корень проблемы: политика безопасности — не статичный текст, а живой, постоянно меняющийся конструкт.
- Эволюция требований. Требования 152-ФЗ и актов ФСТЭК со временем меняются и дополняются. В политику вносятся правки, но старые, иногда противоречащие новым, пункты могут остаться «по инерции» или из-за боязни что-то удалить.
- Слои абстракции. Общая политика информационной безопасности может декларировать «минимально необходимые права доступа», а локальная инструкция по администрированию серверов прописывает конкретные роли. Если эти роли изначально были заданы с избыточными привилегиями, возникает системное противоречие между декларацией и реализацией.
- Автоматизация проверок. Всё чаще для аттестации используются средства автоматического контроля (СКЗИ, системы анализа защищённости). Они проверяют не текст политики, а её имплементацию в настройках. Если политика говорит «парольная политика определяется отдельным регламентом», а в настройках домена стоит значение по умолчанию, которого нет в регламенте,, это противоречие, которое выявит только машина.
Типичные места, где прячутся противоречия
Есть несколько классических «узлов», где нестыковки возникают с наибольшей вероятностью. Их проверка в первую очередь экономит время.
1. Парольная политика и процессы восстановления
Один раздел требует сложных паролей длиной 12 символов со всеми категориями символов, а другой описывает процедуру восстановления через звонок в службу поддержки, где сотрудник задаёт три стандартных контрольных вопроса. Фактически, строгий пароль нивелируется слабой процедурой восстановления. Проверяющие обращают на это внимание сразу.
2. Разграничение доступа и роли администраторов
Политика разграничения доступов гласит: «принцип наименьших привилегий». В приложении же существует роль «глобальный администратор», которая по умол