CIS Benchmark hardening: де ламається ручне налаштування
CIS Benchmark — це не один чек-ліст, а набір профілів різної строгості: Level 1 закриває базові вимоги без ризику зламати прикладний сервіс, Level 2 додає жорсткі обмеження — заборону входу під root за паролем, монтування розділів з noexec, обов’язковий аудит системних викликів.
Усередині профілю — сотні контрольних точок: від параметрів ядра й правил sshd_config до прав на конфігураційні файли та налаштувань журналювання.
Під час ручного налаштування інженер проходить цей список очима й руками: частину пунктів відкладають «до вікна», частину застосовують по-різному на схожих машинах.
Звідси типові відхилення конфігурації. На одному вузлі після відлагодження залишається вхід під root, на іншому висить відкритий порт сервісу, який «був потрібен на тиждень», на третьому послаблено права на файли з параметрами підключення.
Окремо кожне розходження виглядає дрібницею, разом вони дають поверхню атаки, якої немає в жодному звіті про відповідність.
Найдорожче обходиться розходження налаштувань між середовищами. Стенд збирають за одним зразком, прод правлять руками під конкретну задачу, нова нода в кластері піднімається з базового образу й не отримує жодного правила.
Звірити це можна лише за фактичним станом, а на момент перевірки стенд і прод розходяться настільки, що результати сканування не можна порівнювати між собою.
Вікно уразливості росте з того самого кореня. Між виходом оновлення та його застосуванням машини залишаються у відомому уразливому стані, а ручний прогін за чек-лістом фізично не встигає закривати всі вузли з потрібною частотою.
Тому далі розбираємо, як це закривається: профіль описується як код і застосовується однаково на кожній машині.
Керування конфігураціями: вимірюваний ефект впровадження
Єдиний еталон конфігурації — це виконуваний опис, а не документ: склад пакетів, параметри ядра, права на файли, набір служб і правила доступу до мережі лежать у репозиторії та застосовуються на вузол автоматично.
Перевірка відповідності CIS Benchmark перестає бути ручною звіркою чек-ліста й стає регулярною задачею, що повертає вузол до еталона.
Відхилення та час викочування
До впровадження розходження накопичуються непомітно: на частині серверів залишаються зайві облікові записи, послаблені параметри автентифікації, забуті порти.
Ми тримаємо частку відхилень у межах одиниць відсотків — прогін звіряє фактичні налаштування з еталоном і віддає перелік розходжень за кожним вузлом, а не «загалом усе добре».
Правка в еталоні розкочується на весь парк за один прохід: типову зміну, яка руками розтягувалася на дні обходу серверів, застосовують за десятки хвилин. Це і є скорочення вікна уразливості — між виходом виправлення та його появою на всіх вузлах минають години.
Повторюваність середовища та відновлення
Повторюваність означає, що тестовий контур і промисловий збираються з одного опису, а розходження між ними ловиться до релізу, а не в бою.
Час відновлення після збою визначається не розбором журналів, а розгортанням вузла з еталона: години ручного складання стискаються до хвилин, і вузол повертається рівно в той стан, який був під контролем.
Окрема метрика — частка інцидентів, причина яких налаштування, а не код. На керованому парку такі відмови зникають із потоку, і розбір зміщується в прикладний шар. Звіт за кожним вузлом залишається доказом для аудиту: що змінено, чим застосовано й чи збігається з еталоном.
Режими перевірки: аудит, автовиправлення та примус
Режим визначає, що платформа робить із виявленим відхиленням: лише фіксує, приводить вузол до еталона або не дає відхилитися взагалі.
Профіль першого рівня збирає базові вимоги — зайві служби вимкнено, права на системні файли коректні, журнали й правила доступу налаштовані; він майже не зачіпає прикладні сервіси, тому його вмикають на всьому парку.
Профіль другого рівня додає жорсткі обмеження — звуження сумісних механізмів, заборону застарілих способів автентифікації, сегментацію; такий профіль спочатку проганяють на стенді, інакше можна втратити доступ до вузла або завалити складання.
Вибір режиму — це вибір ціни помилки.
Аудит показує реальну картину й не чіпає робочий контур; автовиправлення відхилень приводить вузол до еталона, але на живих сервісах потребує вікна та плану відкату; примусова відповідність перевіряє конфігурацію до її застосування й блокує невідповідний запуск.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Лише звіт (аудит) | Перший прохід по парку, інвентаризація, підготовка до переходу; прод, де зміни допустимі лише у вікно | Нічого не змінює: відхилення залишаються й накопичуються між прогонами |
| Звіт + автовиправлення відхилень | Вузли вже в експлуатації, є вікно обслуговування, потрібен перехід від факту до еталона | Правки йдуть по працюючій системі; частина пунктів профілю другого рівня потребує ручного розбору |
| Примусова відповідність | Складання образів, видача нових машин, середовища з постійним контролем | Зупиняє процес при відхиленні; помилка в профілі блокує випуск цілком |
На практиці режими поєднують: примусову відповідність ставлять на складання образів і видачу нових вузлів, автовиправлення — на вже працюючі машини, а звіти за першим і другим рівнем збирають у єдину картину й порівнюють між контурами — так видно, де еталон розійшовся з реальністю.
Hardening серверів: етапи впровадження еталонних профілів
Порядок робіт однаковий і для десятка машин, і для тисячі: спочатку інвентаризація, потім схема й налаштування, далі перевірка. Профіль CIS Benchmark — не разовий скрипт, а версіонований набір правил, який має переживати перезбирання сервера й оновлення системи.
- Інвентаризація: збираємо склад парку, ролі машин, версії системи й сервісів, зовнішні залежності. Від цього залежить рівень профілю та список правил, які заздалегідь конфліктують із прикладним ПЗ.
- План впровадження: правила ділимо на загальносистемні, рольові та прикладні, позначаємо, що застосовується автоматично, а що потребує погодження з власником сервісу.
- Автоматизація налаштувань: правила описуємо як код, щоб конфігурація відтворювалася на нових машинах і не розходилася після перезбирання. Ручні правки на серверах після цього не потрібні.
- Стенд перевірки: профіль проганяємо на неробочому контурі, що повторює реальні ролі, сканером знімаємо звіт «виконано / не виконано» й розбираємо розходження.
- Пілотна група серверів: вмикаємо некритичні сервіси й стежимо за доступністю та логами відмов. Правила, які ламають роботу, оформлюємо як обґрунтовані винятки з датою перегляду, а не вимикаємо мовчки.
- Приймання профілю: повторний прогін сканера по всьому парку, частка виконаних правил і залишкові відхилення фіксуються в акті.
- Передача в експлуатацію: регламент оновлення профілю під нові версії стандарту, контроль дрейфу конфігурацій і зрозуміла процедура відкату.
Так еталонний профіль стає керованим процесом із вимірюваним покриттям правил, а не кампанією раз на рік.
Конфігурації, політики доступу та документація на виході
Посилення за еталонним профілем CIS Benchmark дає результат, лише якщо він відтворюваний. Тому кожен налаштований параметр залишається не галочкою у звіті «зроблено», а описом, який можна застосувати повторно — на новому вузлі, під час перезбирання або відновлення після збою. Нижче — комплект, який передаємо замовнику разом із роботами.
- Конфігурації вузлів у декларативному вигляді. Параметри ядра, склад служб, права на файли, правила журналювання й налаштування входу — з позначкою, який пункт профілю закриває кожне значення.
- Винятки з обґрунтуванням. Усе, що свідомо відступило від еталона заради сумісності з прикладною системою, винесено окремо: інакше перша ж автоматична перевірка виглядає як аварія.
- Політики доступу та ролі. Матриця «роль → дії → область дії», розділення привілеїв адміністратора й власника застосунку, вхід за ключами замість довгоживучих паролів, порядок видачі тимчасового доступу.
- Схема інфраструктури та меж довіри. Що де розміщено, які вузли вважаються еталонними, де точки входу й чим обмежено переміщення між сегментами.
- Регламент реагування на відхилення. Куди надходить сигнал, який поріг вважається допустимим, хто і за який час розбирає розходження, як оформлюється й знімається тимчасовий відступ.
- Документація з експлуатації. Розгортання вузла з нуля, оновлення еталона при виході нової гілки профілю, відкат до попередньої конфігурації та його наслідки.
- Звіт про стан до та після. Частка закритих пунктів, список ухвалених винятків, повторювані відхилення — основа для наступного циклу перевірки.
Із таким комплектом введення нового вузла йде за одним сценарієм, а розходження видно на плановій перевірці, а не в момент інциденту.
Кейс: скоротили частку відхилень з 38% до 4%
Що було до
Парк із ~400 серверів жив із налаштуваннями, які правили вручну по SSH: хтось закривав зайвий порт, хтось ні. Звірка з профілем Level 1 CIS Benchmark показувала 38% вузлів із відхиленнями — і це не разова цифра, а стан, який відтворювався при кожному прогоні.
Викочування однієї зміни займало до двох днів: правки йшли через заявки, частина вузлів випадала з вибірки й розходилася з еталоном.
Окремо накопичувався клас відмов — після перезавантаження сервіс не піднімався, бо правило, колись додане руками, до еталонного профілю так і не потрапило.
Що змінили і що стало
Налаштування перевели в стан як код: ролі Ansible на кожен профіль, шаблони параметрів у репозиторії, ідемпотентний прогін по парку й сканер, який порівнює фактичний стан з еталоном і віддає різницю по рядках.
Кожна зміна проходить перевірку й викочується одним прогоном — на весь парк це близько сорока хвилин замість двох днів, відкат — поверненням попередньої версії налаштувань.
Ті 4%, що залишилися, — не недоробка, а керовані винятки: старі системи, де параметр ламає застосунок. Кожен виняток описано причиною та власником і перевіряється при кожному прогоні, щоб список не розростався.
Інциденти через налаштування зникли зі зведення: за квартал після впровадження їх нуль проти п’яти в середньому до.
Що робити, якщо частину серверів уже налаштовано вручну?
Ручні налаштування — це не хаос, а накопичений контекст: хтось послабив вимоги до шифрів заради старого інтеграційного сервісу, хтось розширив права сервісного облікового запису, щоб не падав агент моніторингу.
Накотити профіль CIS Benchmark поверх такого парку «в лоб» — означає отримати відмови робочих сервісів у першу ж добу.
Тому перший прогін робимо в режимі лише перевірки: система керування конфігурацією й сканер політик збирають звіт про розходження, не змінюючи жодного параметра на серверах.
Звіт розкладаємо на три групи: реальні прогалини, навмисні відступи та спірні випадки. Перше закриваємо штатною зміною через роль, друге й третє переносимо у файл винятків профілю — з власником, причиною та строком перегляду.
Виняток без власника й дати не заводимо: інакше еталон за кілька місяців вироджується в список дозволів і перестає щось гарантувати.
Далі парк іде хвилями за ролями. Спочатку стенд і невелика група серверів, потім сегменти за призначенням: веб-вузли, бази даних, проміжні сервіси. Нові машини отримують еталон одразу при розгортанні з образу, наявні підтягуються до нього в планові вікна обслуговування.
Між хвилями звіряємо поведінку за метриками й журналами, а будь-яку зміну відкочують із системи керування конфігурацією — вікно повернення залишається відкритим.
Важливий момент: налаштування, які роками правили руками, переносимо в код. Інакше вони знову роз’їдуться, і за пів року ми повернемося до того самого звіту.
Кожен виняток живе до контрольної дати, після якої або усувається причина, або він підтверджується заново з обґрунтуванням.
Видимий результат такої роботи — частка парку, що реально живе під еталоном, зростає від хвилі до хвилі, а кількість відступів скорочується, при цьому сервіси не зупиняються на жодній ітерації. Еталон стає точкою відліку, а не разовим проєктом.
Часті сумніви інженерів перед стартом робіт
Посилення вимог за CIS Benchmark — це сотні контролів в одному чек-лісті, і застосований наосліп він справді ламає бойовий контур: заборона монтування каталогу для тимчасових файлів рве складальні сценарії, обмеження кількості одночасних процесів валить чергу обробників, вимкнення старих версій шифрування обриває зв’язок із зовнішнім сервісом, який оновити неможливо.
Тому профіль не застосовується цілком. Спочатку прогін у режимі лише перевірки — отримуємо карту відповідності: що вже виконано, що розходиться з вимогами застосунку, а що закриється без впливу на сервіси. Далі зміни йдуть етапами, із фіксацією знімка стану перед кожним.
Чи не відваляться застосунки після посилення?
Перед застосуванням контролі з потенційним впливом проганяються на копії контуру під реальним навантаженням. Розходження оформлюються як винятки з обґрунтуванням і строком перегляду — застосунок працює, а непокритими залишаються одиниці пунктів, а не весь профіль.
Як відкочувати, якщо сервіс деградував?
Кожен етап — окрема роль із повторюваним застосуванням, тому відкат це або повернення знімка, або вимкнення однієї ролі. Відновлюємося хвилинами, без ручного розбору журналів і правки конфігурацій із пам’яті.
Хто оновлює профіль, коли стандарт переглядають?
Профіль живе в системі контролю версій як код. Оновлення — окрема задача: звіряємо нові контролі зі списком винятків, проганяємо перевірку на копії контуру і лише потім випускаємо на бойові сервери.
Обговоримо задачу: що потрібно для точної оцінки
Точність оцінки в посиленні захисту за CIS Benchmark залежить не від товщини документації, а від того, чи видно нам реальний стан парку.
Достатньо інвентарю, доступу на читання конфігурацій і розуміння обмежень — цього вистачає, щоб повернутися з планом етапів і прогнозом трудовитрат.
- Перелік серверів із ролями: що за хост, яку задачу вирішує, де розміщений.
- Операційні системи та гілки дистрибутивів за кожним вузлом — від цього залежить набір перевірок.
- Спосіб керування конфігурацією: правки руками, скрипти або ролі керування — і де лежать вихідники.
- Контури та їхній зв’язок: продуктивний, передпродуктивний, тестовий, а також вікна обслуговування, коли допустимі зміни.
- Доступи: обліковий запис із читанням конфігурації та правами підвищення для перевірочних сценаріїв, підключення через бастіон або захищений канал.
- Обраний рівень CIS — базовий або посилений — і сервіси, які не можна вимикати без втрати працездатності.
- Вимоги регулятора або внутрішнього стандарту, під які потрібен звіт, і його форма.
- Точка відкату: знімки та резервні копії, час відновлення вузла з них.
Повний перелік не обов’язковий — почнемо з інвентарю та одного пілотного контуру. Після прогону перевірок за базовим профілем стане видно реальний відсоток відхилень, і ми розкладемо роботи за етапами: від підготовки ролей до звіту про відповідність.
