PKI на власному контурі: прострочений сертифікат валить сервіс
PKI всередині компанії майже завжди виростає стихійно: спочатку один сертифікат для тестового стенда, потім десятки — для балансувальників, брокерів повідомлень, внутрішніх API і партнерських інтеграцій.
Видають їх вручну: інженер заходить на центр сертифікації, генерує ключ, копіює файл на сервер і записує строк дії сертифіката в таблицю, яку потім ніхто не відкриває.
Поки сертифікатів п’ять, схема працює. Коли їх сотні й вони розкидані по середовищах, планове закінчення строку перетворюється на збій: прострочений сертифікат валить сервіс уночі або в пік навантаження, симптом виглядає як помилка з’єднання, і пошук причини займає години.
Простій сервісу коштує дорожче за саму заміну — падають партнерські інтеграції, черга накопичує необроблені завдання, черговий вручну продовжує те, про що ніхто не пам’ятав.
Ручний випуск сертифікатів не масштабується і з інженерних причин: немає інвентарю, де видно, який ключ якому сервісу належить, немає єдиних політик на алгоритми й строки, а відкликання скомпрометованого ключа розтягується на дні. Кожна заміна — окрема операція з ризиком зачепити сусідній сервіс.
Далі розбираємо, як це закривається: централізований випуск і ротація через Vault, короткі строки життя сертифіката, автоматичний перевипуск за розкладом і контроль залишку днів до завершення строку — щоб збій через сертифікат перестав бути подією, що потребує людини.
Що дає керований випуск і ротація ключів
Головний вимірюваний ефект PKI — час випуску сертифіката. Замість днів погоджень і ручного підпису сервіс отримує пару «ключ — сертифікат» за хвилини: інженер указує призначення й строк життя, решту робить центр сертифікації. Приватний ключ при цьому не залишає машину й не пересилається в листуванні.
Автоматичний випуск сертифікатів вбудовується в розгортання: новий сервер під час уведення в роботу сам отримує сертифікат під свою роль і не чекає, поки хтось згадає про заявку. Короткий строк життя стає нормою, бо продовження перестає бути ручною операцією.
Ротація ключів відбувається за розкладом: підпис змінюється до завершення строку, проміжні центри оновлюються ланцюжком, а вікно, у якому скомпрометований ключ залишається небезпечним, стискається до годин.
Для старих сервісів, які не вміють продовжуватися самі, залишається контрольований перехідний режим.
Відкликання — єдина точка. Звільнення співробітника, витік ключа або виведення вузла з експлуатації закриваються однією операцією в центрі сертифікації: анульований сертифікат перестає прийматися всіма сервісами, а не лише тим, де встигли поправити конфігурацію.
Журнал аудиту доступу фіксує, хто й коли отримав сертифікат, з якою роллю і на який строк, — за ним розбирають інцидент, не відновлюючи хронологію з листування. Разом це прибирає клас збоїв «забули продовжити»: прострочений сертифікат більше не валить робочий контур у вихідні.
Архітектури PKI: один центр чи ієрархія з проміжними
Довіра в PKI тримається на тому, хто підписує сертифікати і де лежить ключ, яким цю довіру створено. Один центр сертифікації — мінімальна схема: швидке впровадження, простий регламент, мінімум сутностей.
Зворотний бік — єдина точка відмови: компрометація ключа обнуляє весь ланцюжок і змушує перевипускати всі сертифікати одразу.
Ієрархія розводить зони відповідальності: кореневий центр сертифікації йде в офлайн і не бере участі в рутинному випуску, а працюють проміжні — їх можна відкликати окремо, не чіпаючи корінь.
Зберігання кореневих ключів проєктується окремо: апаратний модуль або офлайн-носій, розділення доступу між кількома власниками, регламент уведення в роботу та відновлення.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Один кореневий центр | Внутрішній контур, невеликий парк сервісів і короткий цикл випуску | Єдина точка відмови: компрометація ключа обнуляє довіру й потребує перевипуску всіх сертифікатів |
| Кореневий центр + проміжні | Кілька команд і контурів, зовнішні партнери, потрібно розмежувати доступ | Дорожче в експлуатації: регламенти, строки життя, планове відкликання проміжних, контроль ланцюжків |
| Зовнішній публічний центр сертифікації | Публічні сервіси й домени, які відкриває браузер клієнта | Залежність від зовнішніх правил випуску та строків; ключі на боці провайдера |
Змішана схема трапляється частіше за крайні: внутрішні сервіси обслуговує власний корінь, публічні домени — зовнішній публічний центр сертифікації.
У Vault це розводиться окремими точками монтування під корінь, проміжні та ролі випуску — політики й строки життя сертифікатів не перетинаються.
Етапи впровадження: від інвентаризації до передачі
Впровадження PKI — це не «розгорнути сховище секретів і почати видавати сертифікати», а послідовність, де кожен наступний крок спирається на дані попереднього.
Якщо пропустити інвентаризацію або не зафіксувати схему довіри, випуск запрацює, але за першої ж ротації чи зміни власника сервісу спливуть забуті ручні правки.
Нижче — порядок, за яким ми ведемо роботи, щоб на виході отримати керований випуск і відкликання, а не набір розрізнених операцій.
- Інвентаризація сервісів. Збираємо, хто й куди ходить захищеними каналами: сервіси, балансувальники, брокери повідомлень, внутрішні API, інтеграції із зовнішніми системами. Окремо фіксуємо, як продовжуються сертифікати сьогодні — вручну, скриптом за розкладом або «коли впаде».
- Схема довіри. Визначаємо глибину ланцюжка: власний корінь і проміжні центри, де зберігаються їхні ключі, які строки випуску й політики відкликання застосовуємо до різних класів сервісів.
- Розгортання й налаштування сховища секретів. Піднімаємо відмовостійку конфігурацію, вмикаємо модуль PKI, розпаковуємо корінь і проміжний центр, вмикаємо журналювання всіх операцій випуску й відкликання.
- Ролі та доступи. Розмежовуємо права: хто випускає, хто відкликає, хто читає закриті ключі. Застосунки отримують доступ під своїми обліковими даними, а не під спільним адміністративним.
- Налаштування випуску. Підключаємо автоматичне продовження: агент на вузлі отримує новий сертифікат до завершення строку, сервіс перечитує його без перезапуску й простою.
- Перевірка на стенді. Проганяємо сценарії видачі, ротації, відкликання, відмови вузла й втрати зв’язку зі сховищем. Заміряємо час відновлення й переконуємося, що відкат на попередній сертифікат можливий.
- Передача в експлуатацію. Віддаємо конфігурації, схеми довіри, регламент відкликання та інструкції для чергової зміни, розбираємо з командою замовника типові збої — далі система живе без нашої участі.
Документація, схеми й регламенти з PKI
Робота закінчується не запуском, а моментом, коли ваша команда сама випускає сертифікат, відкликає скомпрометований і закриває інцидент без дзвінка підряднику.
Тому разом з працюючою інфраструктурою передаємо комплект артефактів: він описує не «як ми це зробили», а як підтримувати це далі.
- Схема довіри — дерево центрів сертифікації, строки життя кореневих і проміжних сертифікатів, місця зберігання закритих ключів і коло осіб із доступом до них.
- Політики доступу — ролі та права на випуск, продовження й відкликання, розділення повноважень: один інженер не може одночасно виписати сертифікат і підтвердити його відкликання.
- Регламент ротації та відкликання — строки перевипуску за класами сертифікатів, що йде автоматично, що вручну, вікно робіт і порядок дій у разі компрометації ключа.
- Конфігурації та код — налаштування сховища, описи ролей і політик, скрипти випуску в системі контролю версій: стенд піднімається з нуля без ручних операцій.
- Карта інтеграцій — які сервіси залежать від PKI і як проходить їхній перевипуск без простою: окремо планова заміна, окремо аварійна.
- Інструкції для чергової зміни — сценарії на типові збої: прострочений сертифікат у балансувальника, недоступне сховище, підозра на витік ключа, з точками ескалації.
- Моніторинг і перевірки — оповіщення про наближення строку завершення, перевірка ланцюжка довіри й прав, звіт про стан PKI для чергового.
Передача відбувається розбором на стенді: ваші інженери самі випускають і відкликають сертифікати під нашим наглядом, а не читають інструкцію після відходу команди.
Кейс: прибрали простої через прострочені сертифікати
До переходу на автоматизовану PKI близько 40 внутрішніх сервісів отримували сертифікати вручну: заявка в черзі, інженер випускав файл і розкладав його по вузлах, а продовження жило в календарі в однієї людини.
За квартал набиралося 8–10 простоїв через прострочені сертифікати, відновлення займало від 20 хвилин до кількох годин — спочатку шукали винуватця, потім перевипускали й перезапускали. Побічний ефект: розгортання перестали ставити наприкінці тижня, щоб устигнути зреагувати.
Що змінили
Розгорнули внутрішній центр сертифікації на HashiCorp Vault: кореневий ключ ізольовано, проміжні видаються ролями під конкретний сервіс, строк життя — від годин до кількох днів.
Випуск і продовження перейшли в автоматику: застосунок запитує сертифікат сам, оновлення підхоплюється без перезапуску, відкликання скомпрометованого — за списком відкликання протягом хвилини.
Що стало
- простої через прострочені сертифікати: 8–10 за квартал → жодного за порівнянний період;
- випуск сертифіката: години очікування → секунди, без заявок і погоджень;
- відновлення після збою: години → хвилини, з відкатом на попередній проміжний сертифікат без зупинки сервісів;
- частка сервісів з автопродовженням: 0 → 100%.
Відмовостійкість перестала залежати від одного інженера: сховище рознесено по зонах, ключі роздруківки розділені між відповідальними, а перевипуск відбувається за розкладом — короткий строк життя сертифіката вже не ризик, а норма.
Чим відрізняється внутрішній PKI від публічного центру
Різниця не в криптографії — формати й алгоритми сертифікатів однакові.
Різниця в тому, у чиєму сховищі довіри вже лежить кореневий сертифікат центру: публічний центр сертифікації заздалегідь прописаний у браузерах, операційних системах і мобільних платформах, тому його сертифікат приймають без налаштування.
Корінь внутрішнього PKI стає довіреним лише там, куди його поставили самі — на керованих серверах, у кластерах, на робочих машинах співробітників.
Із цього випливає межа застосування. Публічний центр потрібен усюди, де сертифікат побачить чужий пристрій: сайт для клієнтів, відкритий програмний інтерфейс, застосунок із магазину, платіжний шлюз, обмін із партнерами.
Внутрішній PKI закриває служби, до яких зовнішній користувач не дістається: взаємну автентифікацію сервісів, шифрування трафіку між базами й проксі, доступ адміністраторів, тунелі в офісні мережі.
Довіра сертифікату — не бінарна ознака, а питання про те, хто може додати корінь у сховище. Поки парк машин керований, поширення кореня — рутинна операція. На пристрої клієнта або партнера такого важеля немає, і внутрішній центр там марний.
Вибір схеми тому частіше гібридний: публічний центр обслуговує зовнішній контур, внутрішній — службовий.
Vault у цій зв’язці бере на себе випуск і ротацію короткоживучих сертифікатів на запит сервісу: проміжний центр налаштовується один раз, а продовження далі йде без ручних заявок.
Внутрішній контур отримує сертифікат за секунди, зовнішній залишається сумісним із будь-яким браузером.
Технічні сумніви: відкликання, ротація, відмовостійкість
П’ять питань, які найчастіше спливають до старту: доля вже виданих сертифікатів, компрометація ключа, випуск без ручних заявок, відмовостійкість самого сховища й доступ до кореневих ключів.
Що буде з уже виданими сертифікатами під час відкликання?
Сертифікат не зникає миттєво: він потрапляє до опублікованого списку відкликання, і сервіси, які перевіряють статус, перестають його приймати. Строк життя скорочує вікно — сервісні сертифікати випускаємо на дні, а не на роки.
Ключ скомпрометовано — як швидко ви його відкличете?
Приватний ключ генерується всередині сховища й ніколи його не залишає, тому витоку файлу не буває. За підозри відкликаємо автоматичним сценарієм за хвилини й випускаємо новий — зупиняти сервіс не потрібно.
Чи можна випускати сертифікати без ручних заявок?
Так. Сервіс запитує сертифікат за своєю роллю з обмеженням за доменами, випуск займає секунди. Ручне підтвердження залишається лише для кореневих ключів — там ціна помилки вища.
Що буде, якщо сховище недоступне?
Уже видані сертифікати продовжують працювати — вони перевіряються на боці сервісів. Випуск нових переживає збій: вузли об’єднані в кластер з автоматичним перемиканням, резервний приймає запити.
Хто отримує доступ до кореневих ключів і як зберігаються резервні копії?
Кореневий ключ збирається за схемою розділення секрету — потрібні частини в кількох відповідальних, повністю він не лежить ніде. Резервні копії шифруються й зберігаються поза основним сховищем, відновлення перевіряємо на навчаннях.
Обговоримо задачу й повернемося з планом робіт
Щоб оцінка була предметною, а не середньою по ринку, потрібен короткий вступний контекст: які сервіси випускають і приймають сертифікати, скільки їх і як часто вони оновлюються, чи є власний центр сертифікації й хто відповідає за кореневі ключі.
Години розмови з вашим інженером і схеми контуру зазвичай достатньо, щоб зрозуміти, будуємо ми PKI з нуля чи йдемо від поточного стану.
Розбір конфігурацій і повернення з оцінкою та планом робіт робить той самий інженер, який потім налаштовує контур, — не відділ продажів. На цьому етапі долучаються наші фахівці з інфраструктури та криптографії.
- Склад робіт — випуск і відкликання сертифікатів, ролі та політики доступу, автоматична ротація, резервне копіювання кореневих ключів, контроль строків дії.
- Що потрібно від вас — доступ до тестового сегмента, перелік сервісів-споживачів і відповідальний, який ухвалює рішення щодо політик.
- Порядок старту — спочатку межі контуру й схема довіри, потім налаштування в тестовому сегменті, далі перенесення в робочий без зупинки сервісів.
- Контрольні точки — після кожного етапу показуємо результат: працюючий випуск, відкликання, перевірку ланцюжка.
- Передача контуру — регламенти, інструкції з відновлення та розбір із вашими інженерами на живому контурі.
- Межі робіт — фіксуємо до старту, щоб не було різночитань щодо обсягу й строків.
Опишіть задачу — повернемося з оцінкою, планом робіт і порядком старту.
