Когда всё соответствует требованиям, но защищённость не растёт: ловушки формального контроля
Компания может регулярно проходить проверки, иметь утверждённые политики, настроенные средства защиты информации, собственный SOC и сотни страниц регламентов. На бумаге такая организация выглядит зрелой. Однако первый серьёзный инцидент нередко показывает, что реальный уровень защищённости заметно ниже заявленного.
Типичные примеры:
- у учётной записи была включена многофакторная аутентификация, но злоумышленник использовал уже перехваченную сессию;
- SIEM исправно собирала события, однако расследование затянулось из-за разных идентификаторов одного и того же пользователя в системах;
- доступ сотрудника оперативно закрыли в Active Directory, но забыли удалить его учётную запись в облачном сервисе;
- резервные копии создавались ежедневно, однако критичный сервис невозможно было восстановить в установленный срок RTO.
Возникает закономерный вопрос: нужно ли отказываться от формальных требований и аудитов? Разумеется, нет. Соответствие нормативам необходимо: оно задаёт базовые правила, распределяет ответственность и помогает выстроить управляемую систему информационной безопасности.
Проблема начинается тогда, когда наличие политики принимают за наличие работающего контроля. Регуляторные требования подтверждают, что определённые процедуры существуют и выполняются. Но они не способны описать всю инфраструктуру компании, реальные зависимости между системами, специфику бизнес-процессов и все возможные сценарии атаки.
Поэтому проверять нужно не только наличие документа или настройки, но и то, насколько контроль помогает предотвращать ущерб на практике.
Управление доступом: список ролей не показывает полной картины
Классическая проверка доступа выглядит просто: открыть карточку пользователя и посмотреть назначенные роли. Для современной инфраструктуры такой подход недостаточен.
Полномочия могут поступать из разных источников:
- через прямое назначение роли;
- посредством групп и вложенных групп;
- из Active Directory или другого каталога;
- через роли корпоративного приложения;
- из локальной базы пользователей;
- через облачные сервисы и федеративную авторизацию.
В итоге сотрудник может не иметь явно назначенной привилегированной роли, но фактически обладать широкими полномочиями. Цепочка может выглядеть так: учётная запись - группа А - группа Б - роль приложения - критичный ресурс.
Есть и более сложная проблема: опасным оказывается не отдельное право, а их сочетание. Например, сотрудник имеет доступ к платёжной системе, но не может самостоятельно провести операцию. При этом ему разрешено редактировать данные контрагентов и изменять определённые реквизиты. Каждое полномочие по отдельности выглядит обоснованным, но вместе они позволяют повлиять на финансовую операцию. Это классический конфликт разделения обязанностей - SoD-конфликт.
Зрелая модель управления доступом должна оценивать не только перечень прав, но и возможные комбинации. Для этого необходимо строить эффективную модель доступа: учитывать прямые назначения, группы, наследование, роли приложений, права на конкретные объекты и возможность выполнения критичных операций.
Особое внимание следует уделять:
- привилегированным учётным записям;
- временным доступам, срок действия которых истёк;
- правам уволенных или переведённых сотрудников;
- сервисным аккаунтам без владельца;
- конфликтующим полномочиям;
- доступам, которыми давно никто не пользуется.
В больших компаниях ручная проверка быстро становится непрактичной. Для анализа потребуются выгрузки из IAM, каталогов пользователей, прикладных систем и матриц доступа. Хорошая практика - регулярно сопоставлять эти данные и автоматически выявлять избыточные, сиротские и конфликтующие права.
SIEM: собирать события недостаточно
Наличие SIEM часто воспринимается как доказательство зрелости мониторинга. Но сама по себе платформа не гарантирует ни обнаружения атаки, ни быстрого расследования.
Чтобы SIEM действительно помогала, необходимо обеспечить единое представление о сущностях. Один и тот же сотрудник может фигурировать в системах под разными логинами, табельным номером, адресом электронной почты или внутренним идентификатором. Если эти записи не связаны, аналитик видит не действия одного пользователя, а несколько разрозненных событий.
Критически важны также:
- синхронизация времени на источниках;
- полнота журналирования;
- понятная классификация событий;
- корректная настройка приоритетов;
- сохранение контекста операции;
- наличие связи между учётной записью, устройством, приложением и подразделением.
Полезно проверять SIEM не по числу подключённых источников, а по способности ответить на конкретные вопросы: кто выполнил действие, откуда, каким способом, что изменилось, какие события произошли до и после него.
MFA не устраняет угрозу компрометации сессии
Многофакторная аутентификация существенно снижает риск использования украденного пароля, но не защищает от всех сценариев. Если злоумышленник получил действующий токен, cookie или сессионный ключ, повторный запрос второго фактора может не потребоваться.
Поэтому MFA следует рассматривать как один из уровней защиты, а не как универсальное решение. Дополнительные меры включают:
- ограничение срока жизни сессий;
- повторную аутентификацию при критичных действиях;
- привязку сессии к устройству и контексту;
- анализ необычной географии и поведения;
- защиту конечных устройств;
- отзыв активных сессий при подозрении на компрометацию.
Важно проверять не только факт включения MFA, но и то, какие операции он действительно защищает.
Исключения часто становятся постоянным правилом
Любая организация сталкивается с исключениями: временным доступом подрядчика, отключением контроля для тестирования, разрешением устаревшего протокола или обходом ограничения из-за срочной бизнес-задачи.
Риск появляется тогда, когда исключение не имеет владельца, срока окончания и процедуры повторного согласования. В таком случае временное решение превращается в постоянную уязвимость.
Для каждого исключения должны быть определены:
- причина;
- владелец риска;
- компенсирующие меры;
- дата окончания;
- порядок продления;
- критерии закрытия.
Отдельно стоит анализировать исключения, которые регулярно продлеваются. Частые продления обычно указывают не на временную необходимость, а на системную проблему в архитектуре или процессах.
DLP может фиксировать нарушения, но не предотвращать ущерб
Работающая DLP-система не означает, что конфиденциальные данные невозможно вынести. Правила могут быть слишком общими, исключения - чрезмерными, а реакция - запаздывающей.
Проверять следует не количество политик, а реальные сценарии:
- отправка файлов через корпоративную и личную почту;
- загрузка данных в облачные хранилища;
- копирование на внешние носители;
- печать;
- использование мессенджеров;
- передача информации через браузерные формы;
- фотографирование экрана или работа с неуправляемых устройств.
Важна и точность классификации данных. Если система не понимает, какие сведения являются критичными, она либо пропускает опасные действия, либо создаёт поток ложных срабатываний. В последнем случае сотрудники начинают обходить контроль, а специалисты перестают воспринимать уведомления как действительно значимые.
Время реакции важнее самого факта обнаружения
Даже качественное обнаружение не приносит пользы, если между событием и реакцией проходят часы. В отчётах может быть указано, что инцидент выявлен, но без анализа времени это мало что говорит о защищённости.
Полезно измерять:
- время от события до его поступления в систему мониторинга;
- время до подтверждения инцидента;
- время до начала локализации;
- время отзыва доступа;
- время восстановления сервиса;
- долю событий, по которым не было действий.
Такие показатели позволяют увидеть разрыв между технической возможностью обнаружить угрозу и реальной способностью организации реагировать.
Автоматическое реагирование требует осторожности
Автоматизация помогает быстро блокировать учётные записи, изолировать устройства и отзывать токены. Но некорректное правило способно остановить бизнес-процесс или создать отказ в обслуживании.
Поэтому сценарии автоматического реагирования необходимо тестировать в безопасном режиме. Для каждого действия должны быть предусмотрены:
- понятные условия запуска;
- ограничение области воздействия;
- возможность отката;
- ручное подтверждение для критичных операций;
- журналирование результата;
- регулярная проверка актуальности сценария.
Автоматизация особенно эффективна для повторяемых действий с низким риском ошибки. Там, где возможны серьёзные последствия для бизнеса, лучше использовать многоуровневое подтверждение.
Резервное копирование нужно проверять восстановлением
Наличие ежедневных резервных копий ещё не доказывает, что данные можно вернуть в рабочее состояние. Копия может быть повреждена, неполной, недоступной из-за компрометации основной инфраструктуры или непригодной для восстановления зависимых систем.
Проверка должна включать практические тесты:
- восстановление отдельных файлов;
- запуск критичного сервиса из резервной копии;
- проверку целостности данных;
- оценку фактического времени восстановления;
- контроль последовательности запуска зависимостей;
- проверку доступности резервной инфраструктуры.
Именно такие учения показывают, соответствует ли реальность заявленным RTO и RPO.
Как оценивать зрелость информационной безопасности
Я бы начинал не с перечня внедрённых средств защиты, а с нескольких практических вопросов:
1. Может ли организация быстро определить, кто выполнил подозрительное действие?
2. Видит ли она полный путь доступа пользователя к критичному ресурсу?
3. Способна ли отозвать права во всех системах, а не только в основном каталоге?
4. Проверяла ли она восстановление после отказа или шифрования данных?
5. Есть ли ответственный за каждый контроль?
6. Известно ли, какие исключения действуют прямо сейчас?
7. Проверялись ли защитные механизмы в условиях реальной нагрузки?
Зрелость проявляется не в количестве документов и продуктов, а в воспроизводимости результата. Если один специалист может быстро разобраться с инцидентом только благодаря личному опыту, процесс нельзя считать устойчивым.
Метрики должны показывать риск, а не активность
Число проведённых аудитов, установленных агентов и обработанных событий характеризует объём работы, но не обязательно уровень защищённости.
Более полезны показатели, связанные с риском:
- доля критичных систем с подтверждённым владельцем;
- процент пользователей с избыточными правами;
- количество просроченных временных доступов;
- доля учётных записей с неизвестным происхождением;
- среднее время отзыва доступа;
- среднее время обнаружения и локализации инцидента;
- процент успешных тестов восстановления;
- доля исключений без срока завершения;
- количество неразобранных высокоприоритетных событий.
При этом метрики нельзя рассматривать изолированно. Снижение числа инцидентов может означать как улучшение защиты, так и ухудшение качества мониторинга.
Формальные требования - необходимая основа информационной безопасности, но не её конечная цель. Документ, сертификат или успешно пройденный аудит подтверждают наличие определённого процесса. Они не гарантируют, что организация справится с атакой, быстро восстановит сервис и сможет доказать ход событий.
Поэтому контроль нужно регулярно проверять через реальные сценарии: отзыв доступа, расследование подозрительной активности, выявление конфликтующих прав, восстановление из резервной копии, работу DLP и автоматическое реагирование. Главный вопрос должен звучать не так: "Есть ли у нас нужная политика?", а так: "Сработает ли этот контроль в момент, когда он действительно понадобится?"
Именно переход от формального соответствия к проверяемой эффективности превращает набор требований и средств защиты в работающую систему безопасности.