Hardening ОС: где конфигурация расходится с политикой
Серверы редко разворачивают из одного образа. Часть машин собрана по эталонному шаблону, часть — из образов прошлых релизов, отдельные узлы дописаны вручную под конкретную задачу. Поверх этого годами копятся правки: отключили требования к сложности паролей, чтобы не мешали автоматической выкладке, ослабили правила фильтрации под интеграцию, расширили права вместо настройки служебной учётной записи.
Так и появляется расхождение конфигураций. Базовая политика безопасности зафиксирована в регламенте, но фактическое состояние хоста ей не соответствует — и проверить это без сплошного прохода по машинам нечем. Неконтролируемые привилегии устроены так же: права раздают вручную под разовую задачу, обратно почти никогда не отзывают, и точного ответа, у кого они есть сейчас, нет ни у администратора, ни у службы поддержки.
Настройка безопасности серверов в таком режиме держится на памяти конкретного инженера. Первая же внешняя проверка или аудит выявляет десятки отклонений на каждой машине: лишние сетевые службы, учётные записи без срока действия, демоны, запущенные от избыточных прав. Разбор затягивается на недели, потому что отклонение мало закрыть — нужно понять, чем оно было продиктовано и что сломается в проде после правки.
Hardening ОС — это не разовая акция, а режим, в котором состояние проверяемо в любой момент. Разбираем, как это закрывается: единый стандарт на все машины, декларируемое применение настроек через роли автоматизации и регулярная сверка факта с политикой.
Что даёт единый профиль безопасности серверов
Единый профиль безопасности — это эталонный набор настроек: правила аутентификации и сроки жизни паролей, права на каталоги, состав запущенных служб, политики журналирования и фильтрации сетевых портов. За основу берём требования CIS — уровни 1 и 2, из которых явно вычёркиваем неприменимое к роли узла. Без этого шага профиль ломает рабочие приложения, и его отключают на первой же неделе.
Стандартизация серверов убирает ручной чек-лист из вывода узла. Набор ролей и сценариев Ansible применяется к парку за один прогон, состояние каждого сервера сверяется с эталоном, расхождения выводятся списком. Срок вывода сервера сокращается с нескольких дней согласований и ручной настройки до десятков минут, а приёмка нового инженера сводится к одному вопросу: сценарий применён или нет.
Отсюда — устранённый класс отказов, а не единичный инцидент. Пока узлы настроены одинаково, сбой воспроизводится на тестовом стенде и лечится правкой в одном месте профиля, а не поиском отличий между «похожими» серверами. Из эталона исчезают лишние службы, гостевые учётки и устаревшие алгоритмы шифрования — типовые причины отказов при проверках просто не проходят накат.
Готовность к проверке перестаёт быть авралом. Отчёт об отклонениях снимается тем же сценарием в режиме проверки, без изменений на серверах: аудит получает список фактов, а не обещания. Доля узлов, отклонившихся от эталона, и время вывода сервера становятся рабочими метриками — по ним видно, держится ли парк в эталонном состоянии между проверками.
Способы приведения ОС к стандарту: сравнение подходов
Перечень требований стандарта одинаков для всех, а способы его достижения различаются радикально — и по трудозатратам, и по тому, насколько результат вообще можно доказать аудитору. Ручная настройка серверов по чек-листу закрывает пункты формально, но состояние узла живёт своей жизнью: кто-то поправил параметр, обновился пакет — и соответствие потеряно без всякого сигнала.
Четыре варианта на практике
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Ручная настройка по перечню требований | Единичные узлы, стенды, разовые эксперименты | Дрейф конфигурации, результат не воспроизводится, аудит держится на памяти исполнителя |
| Эталонный образ системы | Одинаковые серверы разворачиваются с нуля, узлы заменяемы | Изменение требует пересборки и перевыката, уже работающий парк образа не касается |
| Декларативное описание состояния ролями (Ansible) | Парк от десятков узлов, нужна повторяемость и откат | Требует дисциплины: инвентарь, идемпотентные задачи, версионирование ролей |
| Сканеры проверки соответствия без автоматизации изменений | Нужна отчётность и контроль отклонений | Показывают расхождения, но не устраняют их; отчёт фиксирует срез, а не состояние |
На практике сильнее всего работает связка: декларативные роли приводят узел к эталону, сканер подтверждает результат и остаётся регулярной проверкой на дрейф. Эталонный образ дополняет её для новых машин, а ручная настройка остаётся только там, где автоматизация дороже самого узла.
Этапы внедрения: от аудита до передачи регламентов
Стандарт CIS — это не один набор настроек, а несколько уровней строгости, и применять его вслепую нельзя: часть требований затрагивает отлаженные интеграции и нестандартные приложения. Поэтому работу ведём последовательно, фиксируя состояние контура до и после каждого шага.
- Инвентаризация серверов: собираем роли узлов, назначение, сетевые сегменты, ответственных; отмечаем, где политика применима целиком, а где нужны исключения.
- Схема профилей: раскладываем парк по классам — базовый узел, веб-сервер, СУБД, контроллер домена — и каждому задаём свой уровень строгости.
- Подготовка описаний: пишем идемпотентные роли Ansible с задачами, разбитыми по тегам, чтобы прогонять и профиль целиком, и отдельное правило.
- Проверка на стенде: разворачиваем копию узла, прогоняем профиль, смотрим, что ломается — журналирование, монтирование, служебные учётные записи.
- Включение на боевом контуре: группами по несколько узлов, сперва в режиме проверки без изменений; откат держим наготове и выполняем одной командой.
- Приёмка: сверяем отчёт по каждому правилу с целевым уровнем, фиксируем обоснованные исключения, проверяем, что состояние сохраняется после перезагрузки.
- Передача документации: регламенты изменений, описание ролей и профилей, порядок подключения нового узла и ответственный за пересмотр политики.
На выходе получается не разовая настройка, а повторяемый процесс: новый сервер приводится к стандарту тем же набором ролей, а отклонения видны в отчёте, а не всплывают при первой же проверке.
Артефакты на выходе: конфигурации, схемы, регламенты
После сдачи проекта у вашей команды остаются не разовые правки на серверах, а воспроизводимый эталон: описания настроек, по которым новая машина приводится к тому же состоянию одной командой. Ниже — перечень артефактов, которые мы передаём с работами, каждый в виде, пригодном для правок без нашего участия.
- Профили hardening. Разложенные по ролям описания настроек под Linux и Windows: параметры ядра и сетевого стека, состав служб, политики паролей и блокировок, правила журналирования. У каждого пункта — привязка к CIS и пометка, какие унаследованные приложения от него страдают.
- Политики доступа. Вход по ключам и сертификатам, запрет прямого входа под служебными учётными записями, ограничение повышения привилегий, сроки жизни сессий.
- Схемы взаимодействия узлов. Карта: что с чем общается, по каким портам, где точки управления и доверительные отношения, какие каналы шифруются.
- Матрица разграничения ролей. Кто что может — читать конфигурации, применять профили, править исключения. Право менять эталон отделено от права его применять.
- Регламент внесения изменений. Заявка, обоснование, проверка на тестовом стенде, применение, откат. Там же порядок пересмотра эталона: периодичность и ответственный.
- Отчёты и исключения. Результаты проверок до и после, список осознанно отключённых правил с обоснованием и условиями, при которых их включают.
- Порядок отката. Что делать, если после применения профиля узел теряет доступность или сервис не поднимается.
Кейс: сокращение отклонений от эталона в шесть раз
Парк заказчика — около трёхсот узлов: несколько семейств Linux и разные ветки Windows, часть машин в облаке, часть на своём железе. Настройки правили вручную по ходу задач, единого эталонного профиля не существовало, и аудит перед релизом показывал в среднем 47 отклонений на узел — от прав служб и лишних учётных записей до открытых наружу портов. Ввод новой машины в промышленную эксплуатацию занимал двое суток и всё равно пропускал расхождения с настройками соседних узлов.
Как приводили к эталону
Собрали эталон в виде ролей Ansible: общие требования вынесли в переменные, а различия между семействами систем — в отдельные наборы задач, чтобы один профиль соответствия покрывал весь смешанный парк. Каждое правило идемпотентно и сначала прогоняется в режиме проверки: видно, что именно изменится на конкретном узле, до применения. Исключения не замалчиваются, а живут отдельным списком с обоснованием, владельцем и сроком пересмотра — иначе эталон быстро расходится с реальностью.
Метрики до и после
После трёх циклов приведения отклонений на узел осталось 8, доля машин, проходящих проверку с первого раза, выросла с 31% до 94%. Сборка нового узла сократилась с двух суток до 35 минут: он поднимается из шаблона и сразу приводится к эталону, ручные правки после установки ушли. Перед выпуском больше не нужна отдельная фаза подготовки — проверка идёт тем же набором правил, что и настройка, а расхождения автоматически попадают в отчёт.
Откат остаётся управляемым: перед изменениями снимается состояние конфигурации, поэтому возврат на предыдущий вариант занимает минуты, а не часы разбора. Теперь разберём, как этот же подход переносится на парк с нестандартным и устаревшим железом.
Чем отличается hardening ОС Windows от Linux
Разница начинается с модели прав доступа. В Windows права привязаны к идентификатору учётной записи: доступ к объекту описывает список управления доступом, привилегии выдаются группам, а наследование задаёт иерархия домена. В Linux то же ограничение собирается из трёх слоёв — прав владельца и группы на файл, отдельных привилегий на запуск от суперпользователя и мандатного контроля, который сужает возможности процесса даже после успешного входа.
Службы и журналирование устроены иначе. В Windows фоновые процессы собраны в едином диспетчере служб, у каждого своя учётная запись, а события идут в общий журнал с числовыми кодами и категориями аудита. В Linux это независимые демоны и юниты с записью в системный журнал или в подсистему аудита ядра. Смысл событий совпадает, но пороги и правила корреляции для платформ строят раздельно.
Применение настроек тоже расходится. Windows тянет конфигурацию из групповых политик, которые наследуются по уровням: проверять нужно эффективную политику, а не только заданное значение. Linux читает параметры из конфигурационных файлов, и здесь работает декларативный подход — роль описывает конечное состояние, повторный прогон ничего не ломает.
Эталон при этом остаётся общим. Требования к парольной политике, блокировке после серии неудачных входов, аудиту входов и изменений прав, минимальному набору служб и разделению привилегий формулируются одинаково — различаются только реализация и способ проверки.
Мы держим один профиль с двумя уровнями строгости, а под каждую систему пишем свою реализацию приведения к эталону. Регулярный прогон даёт отчёт о расхождениях: что и на каком узле ушло от эталона. Так разнородный парк — Linux и Windows в одной инфраструктуре — управляется единым регламентом, а не двумя несвязанными наборами инструкций.
Частые технические сомнения перед стартом
Сомнения перед стартом обычно не про инструмент, а про то, как он уживётся с живой инфраструктурой, где часть серверов работает годами и трогать их страшно. Собрали четыре вопроса, которые задают почти на каждом разборе, и ответы по существу.
Внедрение потребует остановки сервисов?
Идём от замера к правкам. Сначала инвентаризация и проверка состояния в режиме только чтения — конфигурации не меняются, сервисы не перезапускаются. Затем изменения применяются по группам с ограничением одновременности, а перезагрузка выполняется в согласованном окне и по одному узлу.
Проверки дают ложные срабатывания — что с ними делать?
Часть требований эталона неприменима: например, запрет модулей ядра для сервиса, который без них не работает. Такие пункты не отключают молча — оформляем исключение с обоснованием, ролью и узлом. Исключение живёт в том же описании конфигурации и не теряется при следующем прогоне.
Унаследованные настройки конфликтуют со стандартом?
Описываем их как явные отклонения с причиной и владельцем, а не переписываем вслепую. Приоритет — работоспособность приложения: эталон сначала применяется на тестовом контуре, расхождения разбираются, и только потом правило уходит в прод.
Кто поддерживает эталон после обновлений ОС?
Эталон хранится как код в репозитории с историей правок и проверкой в конвейере — обновление это правка одного файла, а не ручной проход по серверам. Проверка соответствия идёт по расписанию и показывает расхождения по каждому узлу; правила под новые версии ОС добавляются без остановки работы.
Обсудим задачу: какие данные нужны для оценки
Оценка приведения парка к профилю CIS зависит не от числа серверов, а от разнородности окружения. Пока не видно, сколько разных веток дистрибутивов, какие роли несут узлы и что уже описано в существующих ролях, любая цифра по срокам будет гаданием. Поэтому до оценки собираем исходные данные об окружении — из них вырастает план работ с разбивкой по группам.
- Инвентарь узлов: семейства и ветки Linux, редакции Windows, число серверов и шаблонов, из которых они разворачиваются.
- Роли и назначение: веб-слой, СУБД, брокеры, контроллеры домена — от этого зависят наборы правил и допустимые исключения.
- Состояние автоматизации: есть ли свой инвентарь и роли, чем наполняется список узлов — статическим файлом или запросом к системе учёта конфигураций.
- Профиль проверки: базовый или усиленный уровень CIS, применимые разделы, правила, которые нельзя включать из-за устаревших приложений.
- Доступы: служебная учётная запись с повышением прав, способ подключения к парку, промежуточный узел, порядок ротации ключей.
- Окна и откат: можно ли менять конфигурацию по группам, где перезапуск служб требует согласования, доступны ли снимки перед прогоном.
- Проверка результата: каким сканером подтверждаем соответствие и в каком виде нужен отчёт для аудита.
Дальше обсуждаем задачу по существу: сверяем расхождения в данных, уточняем спорные правила и возвращаемся с оценкой сроков и планом работ — сначала пилотная группа, затем остальной парк.
