Управління SSH-ключами для команди: Ansible, Vault, ротація

Чому керування SSH-ключами ламається при зростанні команди

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

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

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

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

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

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

Розбираємо, як пов'язати видачі з ролями інженерів, винести публічні ключі в керований реєстр і зробити ротацію плановою — на Ansible і Vault.

Що дає єдиний контур видачі та відкликання доступів

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

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

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

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

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

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

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

Підходи до зберігання та видачі ключів доступу

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

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

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

Етапи впровадження: від інвентаризації до передачі

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

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

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

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

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

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

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

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

Шаблони ролей, політик доступу та регламентів ротації

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

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

Кейс: вікно доступу скоротилося з тижнів до хвилин

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

Спочатку ми зібрали інвентар: пройшли по серверах, зіставили відкриті ключі з людьми й побачили, що на одного інженера припадає 6–8 копій.

Далі завели єдиний реєстр доступу та перевели видачу на автоматичні сценарії Ansible — ключ створюється під конкретну людину, отримує строк дії, а закрита частина не покидає його робочу машину.

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

Метрики до та після

Підключення нового інженера скоротилося з 3–5 робочих днів до 15–20 хвилин разом із перевіркою прав. Закриття доступу після відходу — з кількох тижнів до однієї команди: ключ відкликається з реєстру й перестає працювати на всіх вузлах одразу. Кількість копій ключів на людину впала з 6–8 до однієї.

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

Що робити, якщо ключі вже роздані по серверах і людях?

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

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

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

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

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

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

Метрики перехідного періоду — частка входів за новими ключами, кількість залишених старих і дата примусового відключення.

Технічні сумніви: сумісність, відкат і аудит

Централізований випуск ключів не вимагає оновлювати парк цілком за один день.

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

Обов'язкова умова одна: керований доступ на запис до конфігурації sshd і запис кожної зміни в журнал.

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

Що відбувається при збої та як виглядає відкат?

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

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

Як підтверджується, що доступ справді відкликано?

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

Як розділяється доступ підрядників?

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

Обговоримо завдання та повернемося з оцінкою й планом

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

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

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

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