Налаштування sudo та політик привілеїв (sudoers) для Linux

Чому налаштування sudoers ламає доступ до серверів

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

Налаштування sudoers застосовується одразу й для всіх сесій, включно з вашою поточною, тому перевіряти треба до запису. Найчастіше ламає порядок директив: останнє правило, що збіглося, перемагає, і пізня заборона перекриває наданий раніше дозвіл. Адміністратор мовчки втрачає root-доступ, хоча формально у файлі все дозволено.

Друге джерело збоїв — включення до груп за назвою: одрук у назві групи або в шляху до команди не видає помилки, правило просто ніколи не застосовується. Третє — конфлікт груп, коли користувач входить до кількох, і одна з них забороняє те, що дозволяє інша.

Ціна однакова — втрата root-доступу на бойовій машині в момент, коли він потрібен терміново. Відновлення йде не з консолі, а через однокористувацький режим або правку диска з іншої системи: це простій сервісу й позапланове втручання в роботу.

Розбираємо, як це закривається: перевірка синтаксису до застосування, порядок роботи з файлом і запасний контур аварійного доступу.

Що дають керовані привілеї: менше відмов і простою

Розмежування прав перестає бути набором усних домовленостей, коли політика описана в sudoers-файлі й версіонується разом з рештою конфігурації. Кожне правило задає, кому й яка команда дозволена, — замість видачі повних адміністративних повноважень.

Принцип найменших привілеїв у такому вигляді обходиться дешевше, ніж його відсутність: інженер отримує рівно потрібні операції, а не весь набір адміністратора.

Ефект вимірюваний. Видача доступу перетворюється на одну правку файлу, яка проходить перевірку й потрапляє до репозиторію: час на видачу й відкликання скорочується з годин до хвилин, а ручні правки на проді зникають як клас.

Відкликання прав при зміні ролі — та сама операція, і вона не залежить від того, чи пам’ятає хтось про ще один сервер.

Надлишкові права — джерело тихих інцидентів: під обліковим записом із зайвими повноваженнями випадкова команда або скомпрометований ключ призводять до псування даних і простою. Обмеження за конкретними командами й параметрами знімає значну частину таких сценаріїв заздалегідь.

Аудит дій вбудований у саму механіку: журнал фіксує, хто й коли підвищував повноваження. За ним інцидент розбирається за хвилини, а не за непрямими ознаками, а розбіжності політик між стендами видно при порівнянні з репозиторієм.

Налаштування sudoers і централізовані політики доступу

Команда sudo читає не один файл, а точку входу з директивами включення: базові правила лежать в основному файлі, додаткові каталоги підключаються цілком.

Звідси три способи вести політику привілеїв — локальний файл правил на кожній машині, спільний шаблон конфігурації або централізований каталог облікових записів.

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

Порівняння варіантів

На практиці виграє гібрид: базовий шар приходить із шаблону, а локальні винятки живуть в окремому каталозі включення — оновлення шаблону не затирає ручні правки. Перед викатом синтаксис перевіряється на одній машині: одрук у правилі блокує sudo на всьому парку.

Успадкування прав через групи доступу економить і на відкликанні: доступ закривається зміною одного запису, а не обходом серверів.

Порядок впровадження: від аудиту прав до передачі регламенту

Впровадження починається з інвентаризації серверів і облікових записів: збираємо список машин, позначаємо, де є прямий вхід під root, які облікові записи передаються між людьми й де права видані ширше за задачу.

За результатами проєктуємо схему ролей — задачі (випуск релізу, перезапуск служб, читання журналів) розкладаємо за групами й аліасами команд, щоб доступ видавався ролі, а не людині.

Правки в основному файлі виключаємо: фрагменти кладемо окремими файлами в каталог підключення, так конфігурація залишається перевірюваною й відтворюваною.

1. Інвентаризація серверів, облікових записів і поточних винятків — що й кому дозволено зараз.
2. Схема ролей і аліасів — кожній ролі мінімальний набір команд і запуск від конкретного користувача.
3. Підготовка правил — перевірка синтаксису до застосування, розбір конфліктів: вузьке правило перекриває широке, заборона важливіша за дозвіл.
4. Перевірка на стенді — проганяємо штатні й заборонені сценарії, переконуємося, що зайві команди відхиляються.
5. Поетапне застосування — від менш критичних машин до ядра, з контролем журналів на кожному кроці.
6. План відкату — зберігаємо вихідну конфігурацію й уміємо зняти зміни на одній машині, не зачепивши решту.
7. Передача регламенту — команда отримує опис ролей, порядок запиту доступу й правила додавання нових задач.

Комплект конфігурацій і регламентів щодо привілеїв

Здача — це не архів із файлами, а робочий контур: правила лежать у системі контролю версій, застосовуються повторювано, а будь-яка правка спочатку перевіряється на синтаксис і лише потім потрапляє в бойовий конфіг. Нижче — що саме залишається у вашої команди й як цим користуватися без нашої участі.

• Конфігурації доступу — правила розкладені за окремими файлами в каталозі підключення, а не звалені в один sudoers: видно призначення кожного запису, а правку можна відкотити точково.
• Схема ролей і груп — карта, яка роль через які групи видається й які команди їй доступні; новий співробітник вводиться додаванням до потрібної групи.
• Резервні копії правил — знімок конфіга до й після кожної зміни з датою й автором, плюс перевірка валідності перед застосуванням, щоб одрук не заблокував вхід.
• Регламент видачі й відкликання прав — порядок від запиту до видачі: хто погоджує, на який строк дається підвищений доступ, чим оформлюється тимчасове правило і яким чек-лістом воно знімається при зміні ролі або звільненні.
• Інструкція з відновлення доступу — покроковий сценарій на випадок зламаного конфіга: вхід через консоль, завантаження в аварійному режимі, розкатка останнього валідного знімка.
• Журнал змін — єдиний список правок із зазначенням, хто, коли й навіщо змінював правила, щоб при розборі інциденту було видно джерело рішення.

Комплект перевіряється на вашому стенді: наші інженери показують, що вхід за ролями, відкат правки й відновлення доступу працюють до того, як ми передаємо документацію.

Як ми зняли зайві привілеї у сервісної команди

Сервісна команда зростала швидше, ніж правила доступу: у кожного інженера в каталозі політик лежав запис із повним доступом без пароля, доданий «тимчасово, щоб не заважати черговому».

За півроку таких «тимчасових» рядків стало більше, ніж самих інженерів, а зрозуміти, хто й навіщо отримав права root, можна було лише з історії листування.

Точка відліку

Заміри до змін виглядали так: 27 облікових записів із повним доступом без пароля — більше, ніж інженерів у штаті; понад 60 правок політик за місяць, більше половини — руками прямо на вузлі, без рев’ю й перевірки синтаксису; підключення нового інженера займало три робочі дні, бо доступ видавали через ланцюжок погоджень у чаті.

Що зробили і що стало

Звели привілеї до трьох ролей: черговий, релізний інженер, аудитор. Повний доступ залишився у трьох сервісних облікових записів з окремим ключем і обов’язковим логуванням кожної команди.

Політики переїхали з ручних правок у файли репозиторію й розкатуються Ansible — зміна проходить рев’ю й валідацію до потрапляння на вузол.

Після змін: три облікові записи з повним доступом замість 27; чотири правки на місяць через рев’ю й нуль ручних змін на вузлах; онбординг нового інженера — 40 хвилин за шаблоном ролі замість трьох днів.

У журналі видно, хто запускав команду і в якій ролі, а помилкова дія відкочується повторним прогоном ролі, а не ручним відновленням вузла.

Що робити, якщо доступ уже втрачено і правка не застосовується

Правка «не застосовується» майже завжди означає одне: файл політики не проходить розбір, і sudo відмовляє в привілеях усім, крім уже відкритої root-сесії.

Окремої команди «застосувати» у політики немає — файл читається при кожному виклику, тому помилка проявляється миттєво, а не після перезавантаження. Найгірше, коли правка рознесена по кількох підключуваних файлах: збій в одному блокує розбір усього набору.

Перша дія — не перезавантажувати хост, а знайти живу root-сесію: її права не залежать від стану політики, і часто цього достатньо.

Якщо такої сесії немає, аварійний вхід іде через окремий канал — консоль гіпервізора або панель провайдера, однокористувацький режим із монтуванням кореневої файлової системи на запис. Вхід по SSH у цей момент марний: з’єднання підніметься, але привілеїв у сесії вже не буде.

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

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

При частково застосованих змінах порядок зворотний: спочатку фіксуємо блоки, які вже розібрані й працюють, і не чіпаємо їх, потім правимо той, що ламає розбір.

Результат перевіряємо не своїм доступом, а запитом прав для конкретного користувача з-під root — так видно, що повернулося саме потрібне й нічого зайвого.

Резервні копії правил і перевірка на тестовому хості переводять таку аварію з простою на півдня в десять хвилин роботи.

Технічні питання щодо прав і застосування правил

Перед викатом політики в прод сумніви зазвичай ті самі: як переконатися, що правило не відріже доступ, що буде при одруці й як жити із серверами, де права колись налаштовували руками. Нижче — короткі відповіді на те, що найчастіше виринає на прийманні.

Що буде, якщо в правилі помилка?

Синтаксична не збережеться взагалі. Небезпечніша логічна: файл валідний, але видає зайве. Тому набір правил перевіряємо на стенді й тримаємо другий шлях доступу — консольний або через окремого адміністратора.

Чи можна дозволити окремі команди без пароля?

Так, через NOPASSWD — але лише для вузького набору: перезапуск одного сервісу, читання логів. Повний набір прав без пароля перетворює sudo на звичайний обліковий запис root і обнуляє аудит: у журналі залишиться факт запуску, але не підтвердження особи.

Як бути із сервісними обліковими записами?

Сервісам sudo частіше не потрібен узагалі — вистачає прав на свої каталоги. Там, де без нього не обійтися, видаємо одну конкретну команду й забороняємо інтерактивну оболонку, щоб обліковий запис не став точкою входу.

Що робити із серверами, налаштованими вручну?

Їх інвентаризуємо: знімаємо поточні правила, звіряємо з цільовою політикою й переносимо в спільний шаблон. Правило, що живе на одному хості, при перезбиранні втрачається, тому далі файли розкладаються автоматизацією з репозиторію, і ручних правок на серверах не залишається.

Обговоримо схему привілеїв під вашу інфраструктуру

Щоб оцінка була предметною, а не «приблизно», потрібна інвентаризація й кілька ввідних. Чим точніше ви опишете поточний стан, тим менше припущень закладемо в план впровадження.

• Список хостів і груп з їхньою роллю: де справді потрібен повний root, а де достатньо набору конкретних команд.
• Актуальні гілки дистрибутивів: від них залежить синтаксис правил і те, як поводяться каталоги включення.
• Поточні файли політики привілеїв, включно з drop-in каталогами й ручними правками, які живуть поза системою керування конфігураціями.
• Як правила доставляються зараз — руками по ssh, скриптами або конфігураційним менеджером на кшталт Ansible.
• Вимоги до аудиту: чи потрібно фіксувати кожну привілейовану команду й куди збирати журнали.
• Чи потрібна інтеграція з каталогом користувачів, щоб права видавалися групам, а не перелічувалися за людьми.
• Вікно змін, порядок перевірки на тестовому контурі й вимога до відкату на попередню схему.
• Політика паролів і запуск без підтвердження: для яких задач він допустимий, а для яких закритий.

Після обговорення задачі повернемося з оцінкою робіт, планом впровадження за етапами й складом схеми прав: які файли й правила з’являться, як вони перевіряються і що залишається на серверах після нас.

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