Провалы, которые никуда не исчезают
Внешняя проверка проходит успешно, все обязательные чекбоксы проставлены, команда получает сертификат о соответствии. Кажется, самое время расслабиться. Но реальность не прощает такого подхода. Существуют инциденты, которые не просто произошли, а случились именно потому, что все внимание было сфокусировано на формальном соответствии требованиям регулятора, а не на реальном состоянии защиты данных. Разница между compliance и security принципиальна, и цена ошибки измеряется не только в рублях штрафов, но и в доверии клиентов, и в репутации компании.
Безопасность как система, а не как список пунктов
Compliance, это обязательный минимум, набор требований, зафиксированных в стандартах вроде 152-ФЗ или приказов ФСТЭК. Эти требования статичны и описывают некий универсальный порог. Безопасность, это живой, непрерывный процесс. Она динамична и адаптируется под конкретные угрозы, архитектуру системы и действия злоумышленников, которые не читали ваши регламенты. Ориентируясь только на compliance, команда начинает работать в парадигме «закрыть требование». Но выполнение требования, это не всегда решение проблемы безопасности.
Например, стандарт предписывает вести журналы событий безопасности. Compliance-подход: настроить сбор логов, обеспечить их хранение, написать процедуру. Security-подход: регулярно анализировать эти журналы, искать в них аномалии, выстраивать триггеры для SOC, понимать, какие события действительно сигнализируют об инциденте, а какие — просто шум. Первый подход формально соответствует, второй — реально снижает риски.
Слепые зоны формального подхода
Соответствие стандартам создает опасное заблуждение о защищенности. Есть несколько классических областей, где разрыв между compliance и security особенно заметен.
«Забытые» активы вне периметра
Требования регулятора часто сосредоточены на централизованных корпоративных системах. Разработчики, тестирующие новый сервис в облаке; маркетологи, использующие сервисы рассылок; бухгалтерия, работающая с внешним онлайн-сервисом — эти активы могут содержать персональные данные, но выпадать из поля зрения формальных процессов аудита. Угроза приходит не через шлюз, а через незаметную учетную запись в стороннем SaaS.
Конфигурационный дрейф
Сертифицированная конфигурация сервера или сетевого оборудования в момент проверки может быть идеальной. Но через полгода, после десятка обновлений, срочных правок и «временных» изменений, она незаметно уходит от эталонной. Compliance-чеклист будет по-прежнему показывать галочку, но реальная безопасность снизится. Без постоянного контроля за конфигурациями (Configuration Management) и автоматизированного сравнения с базовым образом этот дрейф останется незамеченным.
Человеческий фактор и процедуры
На бумаге все процедуры по обработке инцидентов могут существовать и быть одобрены. В реальности, в час ночи при реальной атаке, сотрудник может действовать по наитию, не открывая толстый регламент. Формальное наличие инструкции не означает, что команда готова действовать быстро и слаженно. Без регулярных тренировок (tabletop exercises) эти процедуры — просто макулатура.
Реальные кейсы, когда compliance подвел
Истории этих компаний стали учебным материалом для всей отрасли. Они демонстрируют, что соответствие стандартам само по себе не является щитом.
Взлом через цепочку поставок
Крупный разработчик ПО для управления ИТ-инфраструктурой имел все необходимые сертификаты. Его собственный код был проверен, процессы разработки — задокументированы. Уязвимость проникла в системы клиентов не напрямую, а через обновление сторонней библиотеки, которая использовалась в продукте. Compliance-аудит фокусировался на внутренних процессах компании, но не оценивал риски в цепочке поставок (software supply chain). В результате тысячи организаций, включая государственные, оказались под ударом через доверенный, сертифицированный канал обновлений.
Утечка данных из-за «безопасной» архитектуры
Финансовая организация внедрила строгую сегментацию сети в соответствии с требованиями. Однако доступ к сегменту с персональными данными имел не только ограниченный круг администраторов, но и система мониторинга. Для её работы использовалась стандартная учетная запись с привилегиями. Внутренний злоумышленник, получивший доступ к системе мониторинга, смог беспрепятственно скопировать базу данных. Архитектура формально соответствовала правилам, но логика управления доступом (права системы мониторинга) не была проанализирована с точки зрения реальной угрозы.
Потеря физических носителей
Оператор связи, обрабатывающий огромные объемы персональных данных, проходил регулярные проверки. Шифрование данных на дисках серверов было реализовано. Но процедуры обращения с резервными копиями на лентах или внешних жестких дисках оказались слабым звеном. Сотрудник, ответственный за транспортировку носителей в хранилище, оставил их в общедоступном месте. Compliance-требования по шифрованию данных «при хранении» были выполнены, но целостность процесса физического контроля оказалась нарушена, что привело к масштабной утечке.
Как строить security поверх compliance
Отказ от compliance — путь к санкциям. Задача в другом: использовать требования регулятора как фундамент, но строить на нем полноценную систему безопасности. Вот несколько практических шагов.
- Перевести требования в метрики риска. Вместо галочки «аудит выполняется» измерять количество обнаруженных аномалий и среднее время их расследования. Вместо «антивирус установлен» — отслеживать процент систем с устаревшими сигнатурами или пропущенными угрозами.
- Автоматизировать проверки. Ручные сверки с чек-листами, это история прошлого. Используйте инструменты, которые постоянно сканируют конфигурации, анализируют права доступа, ищут уязвимости и сравнивают состояние с политиками безопасности (CIS Benchmarks, собственные базовые образы).
- Управлять идентификацией и доступом не по должности, а по необходимости. Принцип наименьших привилегий (Principle of Least Privilege) должен стать основой, а не формальностью. Регулярные пересмотры прав доступа (access reviews) важнее, чем первоначальная их выдача.
- Интегрировать безопасность в цикл разработки. Compliance часто проверяет готовый продукт. Security должна быть встроена в процесс с самого начала (DevSecOps): статический и динамический анализ кода (SAST/DAST), анализ зависимостей (SCA), безопасные шаблоны инфраструктуры.
Что в итоге
Compliance, это карта, а security — территория. Можно идеально изучить карту, но все равно заблудиться, если не смотреть по сторонам. Российские требования 152-ФЗ и нормативы ФСТЭК задают необходимый вектор и минимальный уровень защиты. Игнорировать их нельзя.
Однако настоящая безопасность начинается там, где заканчивается формальное соответствие. Она требует мышления, ориентированного на угрозы, постоянной внутренней оценки уязвимостей и готовности к тому, что следующий инцидент будет использовать метод атаки, о котором еще не написали в стандарте. Те, кто понимает эту разницу, строят устойчивые системы. Те, кто её игнорирует, рискуют пополнить список поучительных примеров о том, почему compliance не равно security.