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, застосовні розділи, правила, які не можна вмикати через застарілі застосунки.
- Доступи: службовий обліковий запис із підвищенням прав, спосіб підключення до парку, проміжний вузол, порядок ротації ключів.
- Вікна та відкат: чи можна змінювати конфігурацію за групами, де перезапуск служб потребує погодження, чи доступні знімки перед прогоном.
- Перевірка результату: яким сканером підтверджуємо відповідність і в якому вигляді потрібен звіт для аудиту.
Далі обговорюємо задачу по суті: звіряємо розходження в даних, уточнюємо спірні правила й повертаємося з оцінкою строків і планом робіт — спочатку пілотна група, потім решта парку.
