Закрыли все 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 и специалист по ИБ, отвечающий за комплаенс. А вот подходов три.

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

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

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

Свой стандарт

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

CISO и специалист по ИБ согласовывают требования и сразу фиксируют регламент: кто и как вносит в стандарт изменения и дополнения. Дальше команда проверяет, соответствует ли инфраструктура тому, что написано, разбирается в причинах расхождений, устраняет их и только после этого внедряет стандарт.

Статичным он не остается. Выросло число веб-приложений — усиливаем требования к ним. Больше сотрудников на удаленке — дописываем правила удаленного доступа. После каждой такой правки специалист заново проверяет рабочие станции, серверы, веб-приложения и сетевое оборудование и отдает результаты CISO отчетом. По отчету ИТ-специалист и специалист по комплаенсу договариваются об SLA на устранение каждого несоответствия, а когда его закрывают, проверяют повторно.

Из этого цикла и видно, что комплаенс — процесс, а не разовый отчет о соответствии: результаты измеримы, а каждое несоответствие ведет к конкретному сроку и повторной проверке. Сам процесс чаще всего живет в подразделении ИБ, но исправляют несоответствия и аргументированно спорят с отдельными требованиями ИТ-специалисты, и это правильно: они лучше знают, что переживет их система.

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

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

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

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

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

Тогда compliance-сканирование перестает искать и исправлять, а начинает проверять, не отклонился ли кто от эталона (configuration drift). Это принципиально дешевле и быстрее, чем разбирать накопившиеся несоответствия на живой системе.

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

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

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

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

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

А как у вас?

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

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

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