Навіщо потрібен SSH Certificate Authority замість статичних ключів
Приватний ключ, скопійований у резервну копію, на другий ноутбук або в конфігурацію збірки, перестає бути секретом — але продовжує працювати. Довгоживучі SSH-ключі живуть роками: їх видають підряднику на час проєкту, а закривають ручним обходом парку.
На момент, коли потрібно довести, у кого є вхід, актуального списку немає ні в експлуатації, ні в служби безпеки.
SSH Certificate Authority знімає саму причину проблеми: замість довгоживучого ключа інженер отримує короткоживучий сертифікат, підписаний центром під конкретну роль.
На серверах залишається лише публічний ключ центру, приватний не покидає сховище, а строк дії та набір прав задаються в сертифікаті, а не на хості.
Управління SSH-доступом переїжджає в одну точку: видача, строк, відкликання. Інвентаризація ключів перетворюється на список виданих сертифікатів із власником і часом, а не на перепис файлів по всьому парку. Аудит доступів спирається на один журнал: хто, коли і під якою роллю отримав вхід.
Відкликання перестає бути ручною операцією. Видача припиняється, а вже виданий сертифікат спливає сам через заданий строк — від кількох хвилин до зміни. Копія, що залишилася на чужій машині, на цей момент марна: підпис центру в неї є, а дійсності вже немає.
Нижче розбираємо, як це поставити: де розміщувати центр, як пов'язати його з поточною автентифікацією і що робити з уже розісланими ключами.
Що дає централізована видача сертифікатів доступу
Централізована видача будується на одному довіреному ключі центру сертифікації: sshd на кожному хості читає його з TrustedUserCAKeys, а вхід дозволяється сертифікатом, підписаним цим центром.
Особисті відкриті ключі в authorized_keys перестають бути точкою управління — на хостах їх просто не залишається, а роль користувача задається полем principals у сертифікаті. Інженер отримує доступ тією ж звичною командою, змінюється лише джерело довіри.
Строк життя сертифіката стає параметром доступу. Для автоматизації та службових завдань видаємо його на хвилини, для ручного чергування — на робочу зміну, і після завершення вікна доступ закривається сам, без чиєїсь участі.
Вікно скорочується з «поки не згадають» до вимірюваного інтервалу, і цей інтервал однаковий для всіх хостів, бо задається в одному місці, а не в конфігурації кожної машини.
Відкликання доступу перестає бути проєктом. Достатньо припинити видачу нових сертифікатів для ролі або людини, а чинні погасити через список відкликання — це хвилини роботи, а не обхід парку хостів і правка ключів.
Під час звільнення або зміни ролі вікно доступу не тягнеться до наступної ревізії доступів, а закривається того ж дня.
З цього зникає цілий клас відмов: «забули видалити ключ». Нікому забувати — нічого видаляти, бо постійних ключів на хостах немає, а виданий сертифікат спливає за розкладом.
Окремо вирішується й спадщина, коли той самий ключ лежить у спільній папці й переходить між підрядниками та командами роками: такий ключ просто не проходить перевірку.
Журнал підключень стає повним і однозначним. У логах хоста видно серійний номер сертифіката, набір principals і відпечаток центру сертифікації, а в журналі видачі — кому, на яку роль і на який строк його було видано.
Два записи пов'язуються за номером, тому на питання «хто і коли заходив на цей хост» є відповідь без звірки таблиць доступу вручну.
Способи видачі SSH-доступу: порівняння варіантів
Варіантів три, і різняться вони не інструментом, а точкою, де ухвалюється рішення про доступ: на самому хості, у центрі сертифікації або в обох одразу. Практичний критерій один — як швидко закривається доступ інженеру, який пішов або втратив ноутбук.
Усе інше — зручність видачі, строк життя доступу, повнота аудиту — наслідок вибраної точки. Нижче порівняння за двома осями: коли варіант доречний і чим за нього платить команда.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
Статичні ключі в authorized_keys |
Невеликий парк хостів, один-два адміністратори, склад доступу змінюється рідко | Відкликання — ручна правка на кожному хості; у ключа немає строку життя; копія файлу обходить контроль; аудит лише за журналами входу |
| Сертифікати з централізованою видачею | Парк зростає, потрібні короткий строк життя доступу та єдині політики доступу на всі хости | Потрібен власний центр сертифікації та його обслуговування; хости мають йому довіряти; потрібні регламенти видачі та ротації |
| Гібридний режим доступу | Перехідний період: нові хости вже на сертифікатах, старі ще на ключах | Два контури довіри одночасно; потрібно точно знати, хто і де ходить по статиці; вікно переходу треба обмежувати датою |
Чистої схеми на практиці майже не буває: парк хостів оновлюється нерівномірно, і частина машин ще живе зі статикою.
Тому перехід оформлюють окремим етапом із датою закриття — інакше гібридний період перетворюється на постійний режим із подвійним обліком доступу та зайвими точками відмови.
Порядок впровадження: від аудиту ключів до передачі регламентів
Порядок впровадження сертифікатів будується так, щоб доступ до серверів не переривався ні на один черговий цикл. Спочатку фіксуємо поточний стан, потім проєктуємо схему довіри, і лише потім видаємо сертифікати по-справжньому — спочатку пілотній групі, потім усьому парку.
- Інвентаризація парку. Збираємо список хостів, службових облікових записів і людей, які ходять по SSH, відзначаємо, де осіли статичні ключі та які давно не використовувалися. Без цієї карти не зрозуміти, які ролі та принципали потрібні.
- Проєктування схеми довіри. Визначаємо ролі видачі, набір принципалів, строк життя сертифікатів і шаблони підпису; вирішуємо, що робити з довгоживучими ключами та як влаштувати аварійний доступ.
- Налаштування видачі. Розгортаємо Vault як центр сертифікації, пов'язуємо його з каталогом користувачів, вмикаємо журнал видачі та перевірку підпису на боці хостів.
- Пілотна група. Переводимо 5–10 інженерів і чергову зміну, перевіряємо штатний вхід, спливання сертифіката та відкликання доступу. Якщо черговий не може увійти в аварію, схема не готова.
- Поетапний перевід парку. Йдемо сегментами: спочатку тестові та внутрішні хости, потім робочі сервіси, в останню чергу критичні вузли. На кожному етапі видно частку успішних входів і причини відмов.
- Передача регламентів. Віддаємо документацію: як видати й відкликати сертифікат, що робити при компрометації, порядок чергування та підключення нових співробітників.
Політики доступу, ролі та документація після впровадження
Після впровадження в замовника залишається не лише працюючий доступ за сертифікатами, а й повний комплект артефактів у його власному репозиторії. Без нього рішення перетворюється на чорну скриньку, яку здатен супроводжувати лише автор налаштування. Нижче — що саме передаємо і за якими ознаками перевіряємо, що цим можна користуватися самостійно.
- Схема довіри. Де лежить приватний ключ центру сертифікації, як хости отримують довіру до нього в налаштуванні sshd, які контури розведені окремими центрами, а не одним спільним.
- Ролі підпису. Файли ролей під кожну групу: час життя сертифіката, дозволені принципали, набір розширень, заборона пробросу агента та довільних команд.
- Політики доступу. Відповідність ролей і груп із каталогу, окремі правила для службових облікових записів і чергових, порядок видачі доступу поза планом із зазначенням того, хто погоджує.
- Регламент відкликання. Як відкликається один ключ і як — доступ усій групі, куди потрапляє список відкликаних, за який час він розходиться по хостах і як перевірити факт відкликання.
- Інструкції для чергових. Що робити при втраті ключа, кому ескалювати, як видати тимчасовий доступ і де подивитися журнал підпису щодо конкретного співробітника.
- Аудит і виписки. Журналювання кожної видачі: хто, коли, за якою роллю і з яким принципалом; вивантаження в загальний збір логів і строк зберігання.
- Експлуатаційна документація. Схеми стендів, ротація ключа центру, введення нових хостів і відновлення центру з резервної копії з перевіркою довіри на хостах.
Кейс: перехід із довгоживучих ключів на сертифікати
Клієнт — розподілений парк із кількох сотень серверів у трьох контурах. Доступ видавався за SSH-ключами, які жили роками: ключ співробітника залишався робочим і після звільнення, а інвентарю «хто куди ходить» не було.
Відкликання перетворювалося на окреме завдання — погодження, розсилка по командах і ручна правка списків довірених ключів на кожному вузлі.
Як було
Аудит виявив близько шестисот довгоживучих ключів; частина не використовувалася понад рік, але залишалася в довірених списках. Середній строк відкликання після звільнення — кілька днів, і весь цей час перепустка залишалася чинною.
Вхід виконувався спільним ключем на роль, тому за журналами не можна було розрізнити, хто саме заходив на вузол.
Що змінили і що стало
Розгорнули Vault у ролі SSH Certificate Authority: довірені центри прописали в конфігурації вузлів, а ключі стали підписуватися на короткий строк — робоча зміна замість безстрокового доступу.
Права розклали за ролями через принципали та політики: адміністратор бази та черговий інженер отримують різні набори хостів.
Строк життя сертифіката — 8 годин, продовження автоматичне, поки сесія активна. Відкликання займає хвилини: сертифікат потрапляє до списку відкликання, і вузли перестають пускати власника без обходу парку вручну.
Частка довгоживучих ключів скоротилася до одиниць відсотків — залишилися службові облікові записи з обмеженими правами, а інциденти з чинним доступом звільнених припинилися.
Що робити, якщо статичні ключі вже розгорнуті в парку серверів?
Міграція не вимагає зупиняти доступ: на кожному вузлі до authorized_keys додається директива TrustedUserCAKeys із публічним ключем центру сертифікації, і сервер починає приймати обидва способи автентифікації одночасно.
Статичні ключі при цьому залишаються робочими, а отже відкат на будь-якому кроці коштує одного рядка в sshd_config. Саме це робить перехід керованим: старий контур живе рівно стільки, скільки потрібно, і вимикається усвідомлено, а не в момент аварії.
Порядок етапів підпорядкований правилу «спочатку розширюємо довіру, потім звужуємо права». Насамперед інвентаризація: хто підключається, до яких вузлів, з яких адрес і під яким іменем — за статикою це видно лише опосередковано, тому реєстр збирається з журналів і конфігурацій.
Далі довіра до центру роздається по всьому парку, потім видаються самі сертифікати, і лише після того, як весь трафік пішов через них, статика видаляється з authorized_keys.
Сумісність зі старими серверами вирішується не «оновити все», а розділенням на контури. Там, де актуальна гілка OpenSSH або оновлюваний дистрибутив, сертифікати вмикаються штатно.
Вузли, які оновити не можна — застарілі збірки, вбудовані системи, обладнання із закритою прошивкою, — залишаються на локальних ключах в окремому контурі з жорстким обмеженням за вихідними адресами та строком дії. Це не компроміс, а явна межа: вона документується і поступово скорочується.
Окрема робота — підрядники. Сертифікат видається не людині взагалі, а ролі з набором principals і коротким строком життя, тому доступ перестає бути безстроковим.
У журналах з'являється конкретне ім'я та серійний номер замість рядка «підключився спільний ключ» — під час розбору інциденту це різниця між розслідуванням і здогадами.
Завершується перехід видаленням статичних ключів і переводом доступу лише через сертифікати, при цьому на кожному контурі залишається задокументований спосіб відкату. Розбираємо, як розкласти такий перехід за етапами під ваш парк.
Технічні сумніви: строки життя, відкликання та сумісність
Питання на старті впровадження майже завжди одні й ті самі: скільки живе сертифікат, що робити при звільненні, чи доведеться обходити сотні хостів руками і що залишиться в журналах.
Нижче — відповіді по суті: з параметрами, які ми фіксуємо в конфігурації, і з описом того, як це поводиться в реальній експлуатації.
Наскільки коротким має бути строк життя сертифіката?
Робочий діапазон — від кількох годин до однієї доби для людей і хвилини для службових завдань. Випуск відбувається в момент підключення, приватний ключ не покидає робочу станцію інженера, тому довгий строк життя не дає жодних зручностей, лише ризик.
Короткий строк працює як заміна відкликання: на момент, коли доступ потрібно забрати, сертифікат найчастіше вже сплив, а продовження відбувається непомітно для людини.
Як відкликати доступ, якщо співробітник пішов, а сертифікат ще діє?
Два незалежні рівні. Перший — список відкликаних сертифікатів, який роздається на хости й підхоплюється службою доступу без перезапуску та без розриву активних сесій. Другий — блокування облікового запису в каталозі: продовження в цьому разі просто не видається. Вікно, у якому старий сертифікат ще приймається, обмежене хвилинами, а не добами.
Як хост переконується, що пред'явлений сертифікат справжній?
Хост довіряє лише відкритому ключу центру підпису — він один раз прописується в його налаштуваннях. Підпис перевіряється локально, звернення до центру в момент входу не відбувається, тому недоступність центру не блокує роботу.
Принципали та додаткові обмеження всередині сертифіката задають, на які облікові записи та хости він діє, — той самий ключ не відкриває все одразу.
Що потрапить у журналювання доступу?
У журналах залишається відпечаток і серійний номер сертифіката, а не лише ім'я користувача: сесію можна пов'язати з конкретним випуском і зрозуміти, яким ключем користувалися.
Записи збираються в загальний потік з ідентифікатором запиту, тому розбір інциденту не перетворюється на звірку логів по кожному хосту.
Чи можна впроваджувати поетапно, не зупиняючи роботу?
Так. Спочатку піднімається центр підпису і переводиться один контур, звичайні ключі продовжують діяти паралельно. Потім групи хостів переводяться по черзі, на кожному кроці відкат — повернення довіри до попередніх ключів, він оборотний і не потребує перезбирання інфраструктури.
Обговоримо задачу: підберемо схему доступу під ваш контур
Щоб оцінка була точною, а не «за відчуттями», нам потрібно побачити поточний ландшафт доступу: скільки машин у контурі, як ключі видаються сьогодні і що має потрапляти до журналу. Нижче — що варто підготувати до розмови. Зберемо це за одну сесію і повернемося з оцінкою та планом впровадження.
- Карта парку: перелік серверів і стендів, згрупований за середовищами та рівнями критичності.
- Ролі та принципали: хто до яких груп входить, які права потрібні, кому доступ видається тимчасово.
- Поточна видача: як ключі з'являються зараз — вручну, скриптом, через панель або доменний обліковий запис.
- Точки входу: бастіон, проміжні хости, раннери збірки, адміністративні підмережі.
- Строк життя та відкликання: максимальний час дії сертифіката і порядок негайного відкликання при звільненні або інциденті.
- Джерело облікових даних: каталог користувачів, служба єдиного входу або інвентар — щоб пов'язати видачу зі штатним розписом.
- Обмеження контуру: ізольовані мережі, відсутність вихідного доступу, вимоги аудиту та внутрішні регламенти.
- Цільові метрики: час видачі доступу, частка серверів під сертифікатами, обсяг ручних операцій.
За цим набором ми запропонуємо схему доступу під ваш контур: де розміщується довірений центр, як влаштовані ролі, строки та відкликання, що потрапляє до журналу і як це підтверджується перевіркою.
Опишіть задачу — повернемося з оцінкою, планом за етапами, зонами відповідальності та точками відкату на кожному кроці.
