Hardening серверов по CIS Benchmark: автоматизация и compliance

CIS Benchmark hardening: где ломается ручная настройка

CIS Benchmark — это не один чек-лист, а набор профилей разной строгости: Level 1 закрывает базовые требования без риска сломать прикладной сервис, Level 2 добавляет жёсткие ограничения — запрет входа под root по паролю, монтирование разделов с noexec, обязательный аудит системных вызовов. Внутри профиля — сотни контрольных точек: от параметров ядра и правил sshd_config до прав на конфигурационные файлы и настроек журналирования. При ручной настройке инженер проходит этот список глазами и руками: часть пунктов откладывается «до окна», часть применяется по-разному на похожих машинах.

Отсюда типовые отклонения конфигурации. На одном узле после отладки остаётся вход под root, на другом висит открытый порт сервиса, который «нужен был на неделю», на третьем ослаблены права на файлы с параметрами подключения. По отдельности каждое расхождение выглядит мелочью, вместе они дают поверхность атаки, которой нет ни в одном отчёте о соответствии.

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

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

Управление конфигурациями: измеримый эффект внедрения

Единый эталон конфигурации — это исполняемое описание, а не документ: состав пакетов, параметры ядра, права на файлы, набор служб и правила доступа к сети лежат в репозитории и применяются на узел автоматически. Проверка соответствия CIS Benchmark перестаёт быть ручной сверкой чек-листа и становится регулярной задачей, возвращающей узел к эталону.

Отклонения и время выката

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

Правка в эталоне раскатывается на весь парк за один проход: типовое изменение, которое руками растягивалось на дни обхода серверов, применяется за десятки минут. Это и есть сокращение окна уязвимости — между выходом исправления и его появлением на всех узлах проходят часы.

Повторяемость среды и восстановление

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

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

Режимы проверки: аудит, автоисправление и принуждение

Режим определяет, что платформа делает с найденным отклонением: только фиксирует, приводит узел к эталону или не даёт отклониться вовсе. Профиль первого уровня собирает базовые требования — лишние службы выключены, права на системные файлы корректны, журналы и правила доступа настроены; он почти не задевает прикладные сервисы, поэтому его включают на всём парке.

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

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

На практике режимы сочетают: принудительное соответствие ставят на сборку образов и выдачу новых узлов, автоисправление — на уже работающие машины, а отчёты по первому и второму уровню собирают в единую картину и сравнивают между контурами — так видно, где эталон разошёлся с реальностью.

Hardening серверов: этапы внедрения эталонных профилей

Порядок работ одинаков и для десятка машин, и для тысячи: сначала инвентаризация, потом схема и настройка, затем проверка. Профиль CIS Benchmark — не разовый скрипт, а версионируемый набор правил, который должен переживать пересборку сервера и обновление системы.

1. Инвентаризация: собираем состав парка, роли машин, версии системы и сервисов, внешние зависимости. От этого зависит уровень профиля и список правил, которые заведомо конфликтуют с прикладным ПО.
2. План внедрения: правила делим на общесистемные, ролевые и прикладные, отмечаем, что применяется автоматически, а что требует согласования с владельцем сервиса.
3. Автоматизация настроек: правила описываем как код, чтобы конфигурация воспроизводилась на новых машинах и не расходилась после пересборки. Ручные правки на серверах после этого не нужны.
4. Стенд проверки: профиль прогоняем на нерабочем контуре, повторяющем реальные роли, сканером снимаем отчёт «выполнено / не выполнено» и разбираем расхождения.
5. Пилотная группа серверов: включаем некритичные сервисы и следим за доступностью и логами отказов. Правила, которые ломают работу, оформляем как обоснованные исключения с датой пересмотра, а не отключаем молча.
6. Приёмка профиля: повторный прогон сканера по всему парку, доля выполненных правил и остаточные отклонения фиксируются в акте.
7. Передача в эксплуатацию: регламент обновления профиля под новые версии стандарта, контроль дрейфа конфигураций и понятная процедура отката.

Так эталонный профиль становится управляемым процессом с измеримым покрытием правил, а не кампанией раз в год.

Конфигурации, политики доступа и документация на выходе

Усиление по эталонному профилю CIS Benchmark даёт результат, только если он воспроизводим. Поэтому каждый настроенный параметр остаётся не галочкой в отчёте «сделано», а описанием, которое можно применить повторно — на новом узле, при пересборке или восстановлении после сбоя. Ниже — комплект, который передаём заказчику вместе с работами.

• Конфигурации узлов в декларативном виде. Параметры ядра, состав служб, права на файлы, правила журналирования и настройки входа — с пометкой, какой пункт профиля закрывает каждое значение.
• Исключения с обоснованием. Всё, что сознательно отступило от эталона ради совместимости с прикладной системой, вынесено отдельно: иначе первая же автоматическая проверка выглядит как авария.
• Политики доступа и роли. Матрица «роль → действия → область действия», разделение привилегий администратора и владельца приложения, вход по ключам вместо долгоживущих паролей, порядок выдачи временного доступа.
• Схема инфраструктуры и границ доверия. Что где размещено, какие узлы считаются эталонными, где точки входа и чем ограничено перемещение между сегментами.
• Регламент реагирования на отклонения. Куда приходит сигнал, какой порог считается допустимым, кто и за какое время разбирает расхождение, как оформляется и снимается временное отступление.
• Документация по эксплуатации. Развёртывание узла с нуля, обновление эталона при выходе новой ветки профиля, откат к предыдущей конфигурации и его последствия.
• Отчёт о состоянии до и после. Доля закрытых пунктов, список принятых исключений, повторяющиеся отклонения — основа для следующего цикла проверки.

С таким комплектом ввод нового узла идёт по одному сценарию, а расхождения видны на плановой проверке, а не в момент инцидента.

Кейс: сократили долю отклонений с 38% до 4%

Что было до

Парк из ~400 серверов жил с настройками, которые правили вручную по SSH: кто-то закрывал лишний порт, кто-то нет. Сверка с профилем Level 1 CIS Benchmark показывала 38% узлов с отклонениями — и это не разовая цифра, а состояние, которое воспроизводилось при каждом прогоне. Выкат одного изменения занимал до двух дней: правки шли через заявки, часть узлов выпадала из выборки и расходилась с эталоном. Отдельно накапливался класс отказов — после перезагрузки сервис не поднимался, потому что правило, когда-то добавленное руками, в эталонный профиль так и не попало.

Что изменили и что стало

Настройки перевели в состояние как код: роли Ansible на каждый профиль, шаблоны параметров в репозитории, идемпотентный прогон по парку и сканер, который сравнивает фактическое состояние с эталоном и отдаёт построчную разницу. Каждое изменение проходит проверку и выкатывается одним прогоном — на весь парк это около сорока минут вместо двух дней, откат — возвратом предыдущей версии настроек.

Оставшиеся 4% — не недоделка, а управляемые исключения: старые системы, где параметр ломает приложение. Каждое исключение описано причиной и владельцем и проверяется при каждом прогоне, чтобы список не разрастался. Инциденты из-за настроек ушли из сводки: за квартал после внедрения их ноль против пяти в среднем до.

Что делать, если часть серверов уже настроена вручную?

Ручные настройки — это не хаос, а накопленный контекст: кто-то ослабил требования к шифрам ради старого интеграционного сервиса, кто-то расширил права сервисной учётной записи, чтобы не падал агент мониторинга. Накатить профиль CIS Benchmark поверх такого парка «в лоб» — значит получить отказы рабочих сервисов в первые же сутки. Поэтому первый прогон делаем в режиме только проверки: система управления конфигурацией и сканер политик собирают отчёт о расхождениях, не меняя ни одного параметра на серверах.

Отчёт раскладываем на три группы: реальные пробелы, намеренные отступления и спорные случаи. Первое закрываем штатным изменением через роль, второе и третье переносим в файл исключений профиля — с владельцем, причиной и сроком пересмотра. Исключение без владельца и даты не заводим: иначе эталон за несколько месяцев вырождается в список разрешений и перестаёт что-либо гарантировать.

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

Важный момент: настройки, которые годами правили руками, переносим в код. Иначе они снова разъедутся, и через полгода мы вернёмся к тому же отчёту. Каждое исключение живёт до контрольной даты, после которой либо устраняется причина, либо оно подтверждается заново с обоснованием.

Видимый результат такой работы — доля парка, реально живущая под эталоном, растёт от волны к волне, а число отступлений сокращается, при этом сервисы не останавливаются ни на одной итерации. Эталон становится точкой отсчёта, а не разовым проектом.

Частые сомнения инженеров перед стартом работ

Ужесточение по CIS Benchmark — это сотни контролей в одном чек-листе, и применённый вслепую он действительно ломает боевой контур: запрет монтирования каталога для временных файлов рвёт сборочные сценарии, ограничение числа одновременных процессов роняет очередь обработчиков, отключение старых версий шифрования обрывает связь с внешним сервисом, который обновить нельзя.

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

Как откатывать, если сервис деградировал?

Каждый этап — отдельная роль с повторяемым применением, поэтому откат это либо возврат снимка, либо отключение одной роли. Восстанавливаемся минутами, без ручного разбора журналов и правки конфигураций по памяти.

Кто обновляет профиль, когда стандарт пересматривают?

Профиль живёт в системе контроля версий как код. Обновление — отдельная задача: сверяем новые контроли со списком исключений, прогоняем проверку на копии контура и только потом выпускаем на боевые серверы.

Обсудим задачу: что нужно для точной оценки

Точность оценки в усилении защиты по CIS Benchmark зависит не от толщины документации, а от того, видно ли нам реальное состояние парка. Достаточно инвентаря, доступа на чтение конфигураций и понимания ограничений — этого хватает, чтобы вернуться с планом этапов и прогнозом трудозатрат.

• Перечень серверов с ролями: что за хост, какую задачу решает, где размещён.
• Операционные системы и ветки дистрибутивов по каждому узлу — от этого зависит набор проверок.
• Способ управления конфигурацией: правки руками, скрипты или роли управления — и где лежат исходники.
• Контуры и их связь: продуктивный, предпродуктивный, тестовый, а также окна обслуживания, когда допустимы изменения.
• Доступы: учётная запись с чтением конфигурации и правами повышения для проверочных сценариев, подключение через бастион или защищённый канал.
• Выбранный уровень CIS — базовый или усиленный — и сервисы, которые нельзя отключать без потери работоспособности.
• Требования регулятора или внутреннего стандарта, под которые нужен отчёт, и его форма.
• Точка отката: снимки и резервные копии, время восстановления узла из них.

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