SSH CA: чим небезпечні розрослі статичні ключі
Класична схема виглядає так: в інженера є пара ключів, публічна частина копіюється в authorized_keys на кожному сервері, куди потрібен доступ. Поки хостів п’ять і людей троє, це працює.
Коли хостів сотня, а до фронту підключаються підрядники й чергові зміни, файл на кожному вузлі перетворюється на список, який ніхто не може назвати точно.
Відкликання доступу в такій схемі — не команда, а пошукове завдання. Треба згадати всі вузли, куди ключ колись копіювали, включно з тестовими стендами й резервними машинами, і на кожному видалити рядок.
Поки триває цей обхід, ключ продовжує працювати: вікно між звільненням співробітника та фактичним видаленням вимірюється днями.
Ротація статичних ssh-ключів майже не виконується: заміна означає повторне ручне розкладання по всіх вузлах, а помилка призводить до відмови в доступі в працюючої зміни.
Аудит ключів зводиться до читання authorized_keys — видно набір рядків, але не видно, кому він належить, коли виданий і до якого моменту чинний.
Вартість процесу зростає разом із кількістю вузлів: кожна нова машина додає точку ручного редагування, кожна нова людина — стільки ж.
Централізоване управління доступом через SSH CA розриває цей зв’язок: сертифікат видається під конкретну людину або роль і живе обмежений час, тому відкликання й аудит перестають залежати від пам’яті адміністратора. Розбираємо, як це закривається на практиці.
Що дає єдина видача сертифікатів доступу
Класична схема — публічні ключі, розкладені по файлах авторизації на кожному сервері.
Поки парк малий, це працює; під час зростання з’являється ротація вручну, копії ключів звільнених співробітників на десятках машин і неможливість швидко відкликати доступ: щоб закрити один ключ, треба обійти всі хости. Спільні ключі в репозиторіях і облікові записи-привиди — прямий наслідок такої моделі.
Єдина видача доступів переносить рішення на один центр сертифікації.
Інженер підтверджує особу (другий фактор, корпоративний вхід), отримує короткоживучий сертифікат доступу й працює за ним; хост перевіряє підпис центру та зазначені в сертифікаті принципал і дозволи, а не вміст файлу ключа. Сумісність із OpenSSH при цьому зберігається — змінюється джерело довіри, а не клієнт.
Короткоживучий сертифікат вимірюється годинами, а не місяцями: витік дає вікно в десятки хвилин замість безстрокового доступу.
Відкликання також перестає бути обходом парку — достатньо не продовжувати сертифікат або внести його до списку відкликаних, і це застосовується на всіх хостах одразу.
Журнал видачі доступів фіксує, хто й коли отримав сертифікат, з якого пристрою, на які хости й на який строк. Аудит перетворюється на вибірку з журналу, а не на листування з адміністраторами.
Вимірні наслідки: частка серверів зі статичними ключами падає до нуля, видача доступу новому інженеру займає хвилини, повне відкликання — одна операція замість обходу хостів, а кількість ручних дій під час приймання й звільнення скорочується до підтвердження ролі.
Формати доступу: SSH CA проти статичних ключів
Перед вибором формату варто зафіксувати, що саме хост перевіряє на вході: власника закритого ключа чи підписаний центром сертифікації сертифікат із параметрами.
Статичні ключі в authorized_keys — варіант без інфраструктури: на кількох хостах із незмінним складом команди він простіший і дешевший за будь-яке впровадження.
Далі починається зростання: файли прав доводиться синхронізувати, відкликання робиться вручну на кожному вузлі, а звільнення співробітника нічого не змінює до наступного обходу.
Сертифікати переносять рішення в довірену зону: проміжний вузол підпису видає посвідчення на короткий строк і обмежує його обліковими записами, адресами джерела й обов’язковою командою. Хостам достатньо перевірити підпис і строк — списків ключів на них більше немає.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
Статичні ключі в authorized_keys |
одиниці хостів, стабільний склад | ручне відкликання, немає строку дії, файли прав розходяться по вузлах |
| Сертифікати SSH CA | десятки хостів, ротація складу, підрядники | потрібен захищений вузол підпису та його постійна доступність |
| Проміжний вузол із пробросом | сегментовані мережі, доступ ззовні | точка відмови, аудит бачить вхід, але не дії всередині |
| Гібрид: сертифікати плюс один статичний ключ | аварійний доступ у разі відмови підпису | ключ живе поза строком дії й потребує окремого контролю |
Обмеження сертифікатів тримаємо в голові заздалегідь: відкликати виданий до закінчення строку штатними засобами не можна, тому строк роблять коротким, а продовження — автоматичним.
Довірена зона стає критичним елементом: її недоступність зупиняє видачу нових доступів, хоча вже видані продовжують працювати. Ці компроміси й визначають, який формат підходить вашому парку.
Впровадження за кроками: від аудиту ключів до передачі
Впровадження починається не з налаштування серверів, а з інвентаризації.
Поки невідомо, хто й куди ходить за ключами, будь-яка схема довіри залишиться теорією: ми збираємо публічні ключі з усіх машин, звіряємо їх з обліковими записами й позначаємо «нічийні» — ті, що залишилися від підрядників, стажистів і звільнених співробітників.
На виході утворюється реєстр, де в кожного ключа є власник і призначення, а в кожного сервера — список тих, кому доступ справді потрібен.
- Інвентаризація ключів. Збір і розбір авторизованих ключів, пошук дублів і ключів з необмеженим строком життя, фіксація поточних точок входу й сервісних облікових записів.
- Проєктування схеми довіри. Визначаємо, де живе закритий ключ центру сертифікації, хто ним керує, які ролі потрапляють у сертифікат, на який строк він видається й як продовжується.
- Розгортання стенда. Піднімаємо центр сертифікації в ізольованому контурі, налаштовуємо перевірку сертифікатів на серверах і порядок відкликання, щоб втрачений доступ гасився одразу, а не після ручного редагування всіх машин.
- Перевірка на стенді. Проганяємо сценарії: видача й продовження, відмова після відкликання, вхід чергового за недоступності центру сертифікації. Окремо — аварійний доступ, який не залежить від основної схеми.
- Міграція. Переводимо сервери групами, від периферійних до критичних; старі ключі залишаються резервним шляхом, поки нова схема не відпрацює повний цикл видачі й відкликання.
- Регламенти й передача. Передаємо документацію, правила видачі й відкликання, порядок дій у разі втрати ключа й навчання чергової зміни — далі підтримка працює без нас.
Артефакти на виході: конфігурації, схеми й регламенти
Роботи закінчуються не презентацією, а набором файлів і правил, які команда одразу застосовує в робочому контурі. Нижче — що саме залишається у вас у репозиторії та в системі доступу.
- Конфігурації довіри на вузлах: правки в
sshd_configіз зазначенням центру підпису, політики принципалів і окремого файлу відкритих ключів центру. - Ролі й сценарії розгортання: ідемпотентне розкочування конфігурацій на весь парк машин, включно з новими й перествореними вузлами.
- Автоматика випуску сертифікатів: строки життя, набір прав за ролями, видача для людей і сервісних облікових записів без ручних операцій.
- Схема довіри: карта «центр підпису — вузли — користувачі», точки відмови, межі сегментів і порядок ротації ключів центру.
- Регламент доступу: хто й на якій підставі його отримує, як оформлюється тимчасовий доступ, хто погоджує й як це фіксується.
- Порядок відкликання: списки відкликаних сертифікатів, строк доставки їх на вузли й дії чергового в разі компрометації ключа.
- Аудит і журнали: де дивитися, хто й коли входив, як події надходять у вашу систему збору логів і скільки зберігаються.
- Документація й передача: інструкція для чергових, процедура відновлення центру, журнал змін і розбір із командою.
Через пів року новий інженер видає доступ, відкликає його й піднімає центр заново за цими матеріалами — без пошуків автора налаштування.
Кейс: відкликання доступу за хвилини замість кількох днів
В одному проєкті доступ до 40+ серверів видавали копіюванням публічних ключів за інвентарем. Звільнення інженера перетворювалося на обхід усіх хостів і чищення authorized_keys: повне відкликання займало 2–4 дні, і весь цей час доступ залишався робочим. Спільний ключ на команду добивав картину — за логами не можна було зрозуміти, хто саме підключився.
Аутентифікацію перевели на SSH CA: сертифікат підписується на короткий строк і містить ролі доступу, тому не переноситься між людьми й не перевикористовується.
Приватний ключ довіреного центру зберігається в HashiCorp Vault і не залишає сховище, а видача йде за заявкою із записом у журнал.
| Що вимірювали | До | Після |
|---|---|---|
| Видача доступу новому інженеру | години ручних правок на кожному хості | хвилини за заявкою |
| Повне відкликання під час звільнення | 2–4 дні | хвилини |
| Відповідь на «у кого є доступ» | збирання за логами вручну | звіт за виданими сертифікатами |
| Ротація після інциденту | перевипуск ключів усій команді | відкликання й перевипуск зачеплених |
Відкликання перестало залежати від оперативності адміністраторів: сертифікат діє обмежений час, а в разі інциденту потрапляє до списку відкликаних, який хост перевіряє під час кожного підключення.
Клас відмов «залишковий доступ після звільнення або витоку ключа» закрито процесом, а не регламентом. Схему ролей і правила для хостів розібрано нижче на сторінці.
Що робити, якщо парк уже працює на статичних ключах?
Перехід на централізовану видачу не потребує «дня Х», коли всіх одночасно позбавляють статичних ключів. Демон SSH читає обидва джерела довіри одразу: файл із публічним ключем центру й звичний список авторизованих ключів працюють паралельно.
Поки в конфігурації хоста прописані обидва, парк переводиться групами — за командами, за середовищами або за типами машин.
Починається все з інвентаризації: хто на які хости ходить, під якими іменами, які обмеження зараз зашиті в статичних записах.
Потім публічний ключ центру додають до довірених на хостах, а на самі хости викочують сертифікати, щоб клієнти перестали скаржитися на підміну ключа під час першого підключення.
Далі — перехідний період із подвійною довірою. Новим співробітникам і сервісам видають лише сертифікати з коротким строком життя, старі статичні ключі залишаються робочими, але заново не випускаються.
Обмеження — обов’язкова команда, дозволені адреси, заборона перенаправлення портів — переносять зі статичних записів у параметри сертифіката, тому права переїжджають один в один, а не розширюються «про всяк випадок».
Окремо проєктується аварійний доступ: один службовий ключ поза загальним контуром, який зберігається за процедурою й використовується, якщо служба випуску недоступна. Він закриває головний ризик переходу — повну втрату доступу до хостів, і він же слугує планом відкату.
Коли за журналами видно, що останній статичний ключ більше не використовується, список авторизованих ключів видаляють, і центр залишається єдиною точкою видачі.
Часті технічні заперечення та відповіді інженерів
Інженери рідко сперечаються із самою ідеєю SSH CA — питання викликають деталі: де живе кореневий ключ, що буде в разі відмови вузла підпису й як відкликати вже виданий доступ. Протокол підтримується OpenSSH без надбудов, тож сумніви зазвичай не про принцип, а про експлуатацію. Нижче — типові заперечення та те, як вони закриваються.
У нас закритий контур — сертифікати випускати ніде?
Центр сертифікації — не сервіс, що постійно працює, а ключ, який підписує відкриті ключі користувачів і хостів. Підпис відбувається на ізольованій машині без мережі: вона отримує запит і віддає готовий сертифікат.
Публічну частину кореня роздають хостам через управління конфігураціями, закритий ключ контур не залишає.
Що буде, якщо вузол видачі недоступний?
Підпис не потребує постійного онлайну: сертифікат видається на час робочої сесії й діє незалежно від стану вузла.
Корінь тримають у холодному зберіганні, а повсякденний підпис ведуть проміжним сертифікатом — у разі відмови носія випускають новий проміжний, і довіру до хостів скидати не потрібно.
Як відкликати доступ, якщо виданий сертифікат ще чинний?
Основний механізм — короткий строк життя: сертифікат спливає за години, а не за роки. Для негайного відкликання публікується список відкликаних ключів, а в користувача прибираються principals, під якими він заходив. Хости перечитують список — доступ зникає без перевипуску ключів на всьому парку машин.
Залишкові сумніви перевіряємо на вашій інфраструктурі: парк хостів, роздача конфігурацій, ізоляція сегментів — під них вибирається схема.Обговоримо вашу схему доступу й повернемося з планом
Щоб запропонувати оцінку, а не загальні слова, нам потрібно побачити вашу схему доступу: як зараз видаються ключі, де вони зберігаються й хто керує правами на серверах.
Опишіть завдання — повернемося з планом робіт і розбором ризиків переходу на SSH-сертифікати замість довгоживучих ключів.
На обговоренні розберемо:
- поточний порядок видачі доступу й місця, де ключі копіюються вручну;
- склад парку: операційні системи, хмарні та локальні сервери, обладнання, де оновити конфігурацію найскладніше;
- ролі й групи: кому які сервери потрібні й за якою ознакою це визначається;
- вимоги до журналювання входів і строку життя сертифікатів;
- порядок відкликання доступу під час звільнення або зміни ролі співробітника;
- режим відкату, якщо частина серверів не підтримує новий спосіб аутентифікації;
- обмеження за строками й роботи, які не можна зупиняти.
За підсумками ви отримаєте оцінку трудовитрат, план робіт за етапами й цільову схему доступу з описом того, що змінюється на боці серверів, а що — у конфігурації клієнтів.
Якщо переходити повністю зараз невигідно, запропонуємо поетапний варіант: спочатку частину парку, потім решту, зі збереженням поточного способу входу на перехідний період.
