Закрыли все CVE и оставили admin:admin: зачем VM-специалисту комплаенс

📚 Это часть 14 серии “Управление уязвимостями для самых маленьких” - практического руководства по VM с нуля. Главы самостоятельны, но если хочется по порядку - оглавление и все части серии тут.

Комплаенс (compliance) - соблюдение внутренних и внешних требований и норм. Это часть системы управления организацией, связанная с комплаенс-рисками: рисками несоответствия требованиям законодательства, нормативных документов, стандартов надзорных органов и отраслевых регуляторов.

В России комплаенс как понятие начал формироваться в 1999 году: тогда Центробанк издал указание № 603-У - один из первых российских регуляторных актов, где появился термин “комплаенс-контроль”. В информационной безопасности комплаенс стоит особняком: тут он подчиняется множеству законов (187-ФЗ, 152-ФЗ) и регулирующим документам (приказы ФСТЭК, положения ЦБ), и цена несоблюдения измеряется уже не репутацией, а миллионами рублей штрафа. И, как любой процесс в ИБ, комплаенс должен выстраиваться системно.

Мы будем обсуждать комплаенс безопасности инфраструктуры и соблюдения требований регулятора. Это ВАЖНО!

Почему комплаенс в России стал жестче

За последние годы цена несоблюдения требований выросла в разы, и формальное отношение к комплаенсу стало по-настоящему опасным:

• Приказ ФСТЭК № 117 (с 1 марта 2026 года) сделал управление уязвимостями обязательным для госсистем с конкретными сроками: 24 часа на критические уязвимости, 7 дней на высокие [1]. Это уже не рекомендация, а проверяемое требование.

• Оборотные штрафы за утечки персональных данных (с мая 2025 года) - от 3 до 15 млн рублей за первую утечку в зависимости от масштаба (до 20 млн - за утечку биометрии) и 1-3% годовой выручки за повторную [2]. Появилась и уголовная ответственность - статья 272.1 УК РФ.

• Требования ЦБ к финансовым организациям (положения 382-П, 683-П, 684-П, методические рекомендации 2-МР, ГОСТ Р 57580.1) обязывают проводить ежегодные пентесты и анализ уязвимостей, а положение 821-П требует оценивать софт для переводов денежных средств по ОУД4 не ниже [3].

• Указ Президента № 250 от 1 мая 2022 года закрепил персональную ответственность замруководителя за ИБ в органах власти и субъектах КИИ, а с 1 января 2025 года заработал прямой запрет использовать средства защиты из недружественных стран [4].

Комплаенс в ИБ перестал быть “бумажной” дисциплиной: несоответствие оборачивается реальными деньгами, а иногда и уголовным делом.

Основные действующие лица

В построении системы комплаенса участвуют: ИТ-специалист, руководитель информационной безопасности (CISO) и специалист по ИБ, ответственный за комплаенс.

Варианты построения комплаенса

Вариант 1. Ничего не делаем. Организация не предпринимает специальных мер, все держится на исторически сложившихся практиках: установлена какая-то длина пароля, запрещены рутовые учетки. Для современных реалий это путь к проблемам с регулятором.

Вариант 2. Регулятор. Комплаенс строится на требованиях регулирующих органов (ФСТЭК, ЦБ). CISO передает требования специалисту по комплаенсу, формируется стандарт, проходит согласование и проверку соответствия во всех системах, затем устраняются несоответствия. Для большинства российских компаний это базовый и обязательный уровень.

Вариант 3. Международные стандарты. Используются стандарты вроде CIS Benchmarks с обширным перечнем требований. Тут есть подвох масштаба: только для ОС Windows и Microsoft Word суммарно набирается несколько сотен требований. При 1000 узлов это уже сотни тысяч отдельных проверок, что делает полное выполнение практически невозможным, тем более что в самих стандартах встречаются противоречия. По экспертным оценкам, на практике реально достижим уровень около 70% соответствия CIS. Так что международные стандарты стоит использовать не как догму, а как ориентир для постепенного улучшения.

Формирование собственного стандарта

Оптимальный путь - создание индивидуального стандарта, отражающего специфику конкретной организации. Важно учесть собственную модель угроз и характеристики нарушителей, чтобы требования были максимально релевантными.

Взаимодействие и регламентация. CISO и специалист по ИБ вместе согласовывают требования и фиксируют регламент: кто и как вносит изменения и дополнения в стандарт.

Проверка и траблшутинг. Команда проверяет, соответствует ли инфраструктура требованиям. Если находит проблемы - разбирается в причинах, устраняет их и только потом принимает решение о внедрении стандарта.

Непрерывное совершенствование. Стандарт не может оставаться статичным - его приходится обновлять под меняющиеся условия: выросло число веб-приложений - усиливаем требования к ним; больше сотрудников на удаленке - адаптируем стандарт под удаленный доступ. После каждой такой правки специалист заново проверяет инфраструктуру - рабочие станции, серверы, веб-приложения, сетевое оборудование - и фиксирует результаты в отчете для CISO.

Устранение несоответствий. По этому отчету ИТ-специалист и специалист по комплаенсу договариваются о SLA на устранение каждого несоответствия. Закрыли - проверили повторно.

Инструменты контроля соответствия

Проверять соответствие вручную на тысячах узлов невозможно. Для автоматизации используются средства контроля конфигураций (compliance-сканирования). В России это, например, MaxPatrol HCC (Host Compliance Control), RedCheck, бесплатный ScanOVAL от ФСТЭК, модули соответствия в R-Vision и Security Vision, Кауч. Они проверяют настройки систем на соответствие стандартам (CIS, требованиям ФСТЭК, собственным политикам) и автоматически формируют отчеты о несоответствиях. С учетом ухода западных вендоров и требований Указа № 250 отечественные инструменты здесь стали безальтернативными для госсектора и КИИ.

От латания дыр к эталонным образам

Все описанные выше инструменты работают реактивно: система уже развернута, сконфигурирована как получилось, и только потом сканер ищет отклонения от стандарта. Получается замкнутый цикл “нашли - исправили - подождали новую проверку”, и на тысячах узлов этот цикл не заканчивается никогда.

Более зрелый подход - переносить контроль соответствия на этап до развертывания. Требования комплаенса закладываются в эталонный образ, и уже проверенная, гарантированно совместимая конфигурация разворачивается в продакшн через CI/CD.

Эталонный образ (golden image) - заранее подготовленный образ ОС, виртуальной машины или контейнера с уже примененными настройками безопасности и комплаенса. Собирается автоматизированно через Packer, Ansible, Chef или Puppet и используется как единственный разрешенный источник для развертывания новых систем.

При таком подходе задача compliance-сканирования смещается с “найти и исправить” на “убедиться, что никто не отклонился от эталона” (configuration drift) - а это принципиально более дешевая и быстрая проверка, чем разбор накопившихся несоответствий на живой системе.

Для контейнеров и облачных сред это уже фактически стандарт: базовый образ проверяют на соответствие CIS Benchmark для Docker или Kubernetes еще на этапе сборки, до того как контейнер попадет в кластер. Подробнее о специфике таких сред - в главе 18.

Эталонные образы не отменяют регулярные проверки - конфигурация все равно дрейфует: кто-то вручную правит настройку, накатывают патч, донастраивают под конкретную задачу. Поэтому золотой образ и compliance-сканирование - не “или-или”, а связка: первый снижает количество проблем на старте, второй ловит то, что накопилось потом.

Принципы построения комплаенса

• Процессный подход. Комплаенс - непрерывный процесс, а не разовый автоматический отчет о соответствии. Результаты должны быть измеримыми, каждое несоответствие требует немедленного устранения.

• Стандарты как инструмент, а не догма. Международные стандарты (CIS) используются для наполнения собственного комплаенса лучшими практиками с правом переопределения. Например, если CIS для Windows требует минимум 8 символов в пароле, организация может установить 16 для усиления защиты.

Значение комплаенса в управлении уязвимостями

Зачем безопаснику, занятому уязвимостями, вообще думать про комплаенс? Вот наглядный пример. Допустим, на периметре стоит firewall, все известные уязвимости на нем закрыты, критических и средних нет. Казалось бы, идеально. Но если на нем стоят стандартные логин и пароль admin:admin, вся эта чистота обнуляется: устройство легко взломать перебором.

Уязвимости возникают не только из-за технических дефектов кода, но и из-за ошибок конфигурации. Слабые пароли, открытые админ-панели, неправильно настроенные правила доступа - это тоже уязвимости, причем одни из самых эксплуатируемых (вспомним “мисконфиги” из первых глав и категорию Security Misconfiguration в OWASP Top 10). Поэтому контроль конфигураций и управление доступом - неотъемлемая часть процесса VM, а не отдельная бюрократическая дисциплина. Закрыть CVE и оставить admin:admin - все равно что поставить бронированную дверь и не запереть ее.

А как у вас?

Сколько раз вы видели идеально пропатченную систему с паролем admin:admin? И как у вас устроен контроль конфигураций - отдельно от VM или единым процессом?

Навигация по серии: ⬅️ Предыдущая: Гл. 13. VM в нетипичных средах · 📑 Оглавление серии · Следующая: Гл. 15. EASM ➡️

Если у вас в инфраструктуре что-то устроено иначе - расскажите в комментариях. Зашло - подписывайтесь, чтобы не пропустить следующую часть.