Налаштування користувачів Linux: де ламається розмежування доступу
Спільний обліковий запис на серверах виглядає зручним рівно до першого інциденту.
Усі дії в журналі підписані одним і тим самим uid, і визначити, хто саме перезапустив базу чи поправив конфігурацію, неможливо — розбір розтягується на дні, а виконавця шукають за непрямими ознаками.
Якщо такий запис ще й лежить у нотатках усієї команди, відкликати його швидше, ніж зрозуміти, у кого він є.
Друга типова поломка — права, видані «на час».
Правило в sudo з вимкненим запитом пароля залишається у файлі після закриття задачі, співробітник забутий у групі з правами на контейнери, а публічний ключ того, хто звільнився, продовжує лежати в authorized_keys одразу на десятках хостів.
Відкликання не було частиною процесу, тому зайві привілеї живуть роками й спливають лише під час перевірки або після збою.
Звідси третя проблема: аудит доступу не відповідає на просте питання — хто і коли отримав доступ до сервера.
Числові ідентифікатори перевикористовуються після видалення запису, старі рядки журналів починають указувати на іншу людину, а термін зберігання логів часто коротший за термін життя ключа.
Розмежування прав доступу перестає бути формальністю: без персональних облікових записів розслідування обнуляється.
Розбираємо, як це закривається: персональні облікові записи з ролями через групи, обмежений термін життя привілеїв, регулярне звіряння ключів і правила аудиту, за якими доступ можна підтвердити або спростувати за журналом.
Що дає порядок в облікових записах і правах доступу
Єдина модель доступу — це не про зручність адміністрування, а про передбачувані цифри: скільки часу займає видача й відкликання прав, скільки на парку привілейованих облікових записів і чи можна відновити картину інциденту за журналами входу.
Видача й відкликання прав — одна операція на весь парк
Права роздаються групами, а не руками по серверах — штатний механізм Linux переноситься в єдину модель доступу.
Співробітник потрапляє в потрібну групу й отримує права всюди, де вона оголошена; звільнення або зміна ролі — це вилучення з групи, і доступ зникає на всіх вузлах одночасно.
Частка серверів під спільним регламентом прямує до 100%, а відкликання перестає залежати від того, чи пам'ятає черговий про конкретну машину.
Привілейованих облікових записів — одиниці, термін життя обмежений
Замість спільного облікового запису root на кожному хості — іменні записи й правила sudo за ролями, а для разових робіт — тимчасовий доступ із датою закінчення. Кількість привілейованих облікових записів скорочується до одиниць, і кожен вхід під ними пояснюваний.
Термін життя облікового запису підрядника або стажера задається заздалегідь: запис згасає сам, і нагадувати про нього нікому не потрібно.
Інцидент розбирається за журналами
Журналювання входу, викликів sudo і правок у групах іде до централізованого збору, де запис прив'язаний до людини, а не до адреси машини. Розбір питання «хто і коли отримав доступ до цього вузла» займає хвилини замість дня листування з командою.
Розмежування доступу в Linux: локальні записи, каталог, домен
Схема облікових записів визначається не розміром парку, а тим, де живе джерело істини і хто відповідає за відкликання доступу.
Локальні записи в /etc/passwd і /etc/group працюють, поки машин десятки: звільнення співробітника перетворюється на обхід усіх хостів, ідентифікатори розходяться між стендами, а спадок у sudoers доводиться звіряти вручну.
Нижче — три схеми, між якими реально обирають. У кожної своя ціна в підтримці, і її видно лише на другий рік експлуатації.
| Схема | Коли підходить | Що підтримувати власними силами |
|---|---|---|
| Локальні облікові записи й групи | 1–5 хостів, ізольовані стенди, сервісні записи під конкретну задачу | Синхронізацію ідентифікаторів, ручне відкликання доступу, розбір розбіжностей у правилах підвищення прав, інвентаризацію «хто де заведений» |
| Служба каталогу | 10+ хостів, єдині вимоги до паролів, спільний вхід по SSH для команди | Доступність самої служби, репліки, резервне копіювання та відновлення каталогу, перенесення схеми під час оновлення |
| Доменна автентифікація | Парк уже в домені, потрібні групові політики та єдиний вхід | Зв'язку доменних і локальних облікових записів, кеш даних для роботи без зв'язку з контролером, налагодження зіставлення груп |
На практиці майже завжди виходить гібридна схема: домен відповідає за людей і групи, локальні записи — за сервіси, яким домен не потрібен (демони, резервне копіювання, моніторинг).
Ключове тут — заздалегідь закріпити діапазони ідентифікаторів під кожну роль, інакше під час підключення хоста до каталогу наявні файли змінять власника й застосунок перестане читати свої дані.
Друга умова — керування групами через правила, а не правка файлів на хості: тоді відкликання доступу перевіряється однією командою й залишається в журналі аудиту.
Як відбувається впровадження: від аудиту записів до регламенту
Впровадження йде не з правки конфігів, а з повної картини: у парку серверів облікові записи накопичуються, доступ «на час» залишається назавжди, під час звільнення блокують вхід у систему, але забувають ключі в authorized_keys, sudo-правила та задачі в cron.
Тому порядок зворотний звичному: спершу фіксуємо, що є, потім проєктуємо ролі, і лише потім змінюємо конфігурацію.
- Аудит облікових записів. Збираємо список користувачів і груп із хостів, розбираємо
sudoers, терміни дії паролів, ключі та сервісні акаунти, звіряємо з реальними співробітниками й власниками процесів. - Інвентаризація прав. Будуємо матрицю «хто — яка група — яке sudo-правило — на яких хостах», позначаємо надлишкові права з вимкненим паролем і доступ до каталогів, яким він не потрібен.
- Схема доступу. Формулюємо ролі — адміністратор, черговий, розробник, сервісний акаунт — і правила: права видаються групами, а не персонально, вхід root за паролем закритий, централізоване джерело облікових записів обов'язкове.
- Налаштування. Переносимо схему в опис конфігурації, щоб доступ відтворювався на новому хості, а не налаштовувався руками: групи, sudo-політики, обмеження сесій, запис дій у системний журнал.
- Перевірка на стенді, потім у продакшені. Перевіряємо синтаксис правил до застосування, розкочуємо групами серверів зі збереженням попередньої версії конфігурації — відкат займає хвилини.
- Перевірка після впровадження. Проходимо тести від імені кожної ролі: потрібна команда проходить, зайва відбивається, спроба підвищення прав потрапляє в журнал. На виході — звіт «до і після» за кількістю записів і правил.
- Передавання регламенту. Віддаємо документ: як завести й як закрити обліковий запис, що робити під час звільнення, хто і з якою періодичністю переглядає права; проводимо навчання відповідальних і передаємо шаблони перевірок.
Конфігурації, схеми доступу та регламенти за обліковими записами
Налаштування облікових записів закінчується не робочим входом на сервер, а набором артефактів, за якими ваша команда зможе керувати доступами без нас. Усе лежить у тому самому репозиторії, що й конфігурація інфраструктури, — з історією змін і можливістю відкотити правку.
- Файли конфігурацій — правила входу, обмеження sudo й налаштування підключення до каталогу, розкладені за ролями й хостами, а не один спільний зліпок на весь парк.
- Карта ролей і груп — таблиця «роль → групи → хости → рівень доступу», за якою відразу видно, хто і куди потрапляє.
- Політики паролів і ключів — термін життя, складність, блокування після невдалих спроб, вимоги до ключів і другий фактор для адміністративних облікових записів.
- Регламент видачі й відкликання прав — заявка, погоджувач, термін дії тимчасового доступу, порядок дій під час звільнення й переведення.
- Порядок перегляду прав — звіряння активних облікових записів із кадровими даними за розкладом і окремий обхід службових облікових записів і сервісних ключів.
- Документація щодо облікових записів — де еталонна конфігурація, як перевірити розбіжність на хості, що робити в разі відмови входу.
- Інструкції для служби підтримки — типові сценарії: співробітник пішов, змінив роль, втратив ключ, потрібен разовий доступ на добу.
Кожен пункт перевіряємо: розгортаємо доступи на чистому стенді строго за документацією й дивимося, де її не вистачило. Зазвичай після такого прогону інструкції стають коротшими, а карта ролей — точнішою.
Кейс: єдина модель доступу замість роз'їханих записів
Що було до робіт
До нас прийшла Роздрібна мережа з парком із 40 серверів, де доступ жив у локальних файлах: у кожного адміністратора свій запис у sudoers або в групі wheel, паролі пересилалися в месенджерах, а ssh-ключі не відкликалися після звільнення.
Інвентаризація показала 340 записів із підвищеними правами — частина належала підрядникам, які вже рік не торкалися інфраструктури.
Розбір одного інциденту з падінням сервісу займав три дні: за логами не можна було зрозуміти, чий обліковий запис запускав команду і що саме змінювалося на диску.
Що змінили й що вийшло
Облікові записи звели в єдиний каталог, а права описали ролями за зонами відповідальності, а не за людьми.
Постійні привілеї залишили тільки черговій зміні, агентам моніторингу та сервісним обліковим записам; решті видаємо тимчасові — на 4 години, із зазначенням задачі та автоматичним закінченням терміну.
Паролі прибрали на користь ключів, а кожна дія з підвищеними правами пишеться в спільний журнал із прив'язкою до конкретної людини.
Постійних привілейованих записів залишилося 27 замість 340. Видача доступу займає 15 хвилин за заявкою з погодженням, відкликання — хвилини: обліковий запис вимикаємо в каталозі, і він перестає працювати на всіх серверах одразу, без обходу машин вручну.
Розбір інциденту скоротився до півтори години: видно, хто запускав команду, з якої машини і що було до і після.
Окремо закріпили регламент: щоквартальне звіряння каталогу з фактичними підключеннями, перегляд ролей під час зміни посади й обов'язковий розбір кожного випадку підвищення прав поза заявкою.
Що робити, якщо облікові записи вже роз'їхалися по серверах?
Знести локальні облікові записи й одразу ввімкнути централізований каталог не можна: на серверах уже закріплені власники файлів із конкретними UID, ключі доступу в домашніх каталогах, правила sudo з точковими винятками та службові завдання за розкладом.
Масова заміна ламає не лише вхід людей, а й обмін між сервісами — бекапи, вивантаження й розсилки зупиняються без зрозумілої помилки в журналах.
Перший крок на живій інфраструктурі — опис, а не правки. Збираємо по всіх хостах локальних користувачів і групи, їхні UID, склад груп, права sudo, власників каталогів із даними та активні ключі доступу.
Робимо це збирачем фактів (у нас — Ansible), на виході — зведена таблиця, де відразу видно, кого не можна чіпати взагалі, а кого можна переводити першою хвилею.
Далі — поступовий перехід. Нових користувачів заводимо в каталозі, локальні записи залишаємо, поки ім'я, UID і групи збігаються: файли, створені до і після переведення, читаються однаково — це і є зворотна сумісність, заради якої перехід розтягують на тижні.
Правила sudo переносимо окремими файлами в каталог включень, а не правкою спільного файлу: помилка в одному рядку тоді не вимикає sudo всім одразу.
Облікові записи застосунків і службові залишаємо локальними — вони прив'язані до фіксованого UID, і переведення рве доступ до даних і права на каталоги. Відповідальним на час переходу зберігаємо аварійний локальний вхід із ротацією пароля й записом у журнал.
Старий механізм вимикаємо тільки після звіряння: якщо за локальними обліковими записами входів немає заданий термін, їх відводимо в архів.
Технічні питання щодо облікових записів і прав доступу
Облікові записи й права — ділянка, де зміни накопичуються роками й рідко ревізуються. Нижче — відповіді на питання, які найчастіше виникають під час розбору доступу й передавання регламенту.
Чи можна залишити спільний обліковий запис?
Тільки якщо він потрібен технічно. Іменний запис із точковими правилами sudo в окремому файлі залишає персональний слід у журналах, а дії залишаються відтворюваними. Спільний логін, якщо без нього не можна, обмежуємо ключем і адресою джерела.
Як заводити сервісні облікові записи?
Без оболонки входу й із мінімумом прав: оболонка nologin, доступ до потрібних каталогів через групу, а не через право запису для всіх. Так сервіс не перетворюється на готову точку входу для зловмисника.
Як дати доступ підряднику й не втратити контроль?
Окремий обліковий запис, вхід за ключем, обмежений набір команд через sudo і термін дії. Після робіт доступ блокується, ключ відкликається, дії залишаються в журналі.
Чи можна видати права на час?
Так, це штатний режим: правила видачі виносимо в окремі файли, вмикаємо й вимикаємо їх за розкладом, а термін життя самого облікового запису обмежуємо окремим параметром.
Кому належить регламент після передавання?
Вам. Передаємо матрицю доступу, порядок видачі й відкликання прав, чек-лист під час звільнення та самі конфігурації з коментарями — регламент можна виконувати й змінювати без нашої участі.
Розкажіть про свій парк серверів — повернемося з планом
Щоб оцінка була по суті, а не за шаблоном, достатньо кількох вступних. Потрібно розуміти, звідки беруться облікові записи, як влаштований вхід на сервери і де осідають події — тоді аудит доступу рахується за реальною картиною, а не за здогадками.
Що надіслати для старту обговорення:
- Джерело облікових записів: локальні файли, каталог LDAP або домен Active Directory, а також чи є гібридні схеми.
- Правила входу: налаштування SSH — заборона пароля для сервісних облікових записів, обмеження за групами, чи вимкнений прямий вхід суперкористувача.
- Список привілейованих ролей: хто і через що отримує підвищені права, чи є разові винятки в sudoers.
- Політику життєвого циклу: термін дії пароля, блокування після невдалих спроб, порядок звільнення й відкликання ключів.
- Куди пишуться журнали входу й зміни прав: локальні файли, виділений сервер збору або зовнішня система.
- Інвентар: скільки серверів, які групи образів, чи є контури з окремими вимогами до доступу.
У відповідь повертаємо конкретику, за якою можна ухвалювати рішення. Карту доступу: хто куди ходить, через яку групу, де видані зайві права.
Межі робіт із явним переліком, що входить, а що залишається на вашому боці, і порядок перевірки: контрольний список по кожному серверу, спосіб відкату й точка, на якій зміни фіксуються.
Передавання результатів — конфігурації, схема ролей, регламент видачі й відкликання доступу та коротка інструкція для чергової зміни. Опишіть задачу — повернемося з оцінкою та планом.
