Наскрізне шифрування трафіку між сервісами: TLS/mTLS

Шифрування трафіку між сервісами: де рветься захист

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

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

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

Жоден із цих сигналів не відповідає на питання, чи був канал зашифрований і чи перевірено сертифікат сторони, що викликає.

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

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

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

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

Що змінюється в надійності та строках після впровадження

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

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

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

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

Відкликання скомпрометованого сертифіката теж стає звичайною операцією, а не аварійним нічним заходом.

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

Режими шифрування трафіку: де що доречно

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

За односторонньої перевірки сервер пред’являє сертифікат, а клієнт — ні: канал захищений від прослуховування, але сторона, що викликає, залишається анонімною. Взаємна перевірка сторін (mTLS) додає зустрічну вимогу — сервіс без валідного сертифіката з’єднання не отримає.

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

Перехід між режимами майже ніколи не роблять одномоментно.

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

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

Інвентаризація, схема довіри та випуск сертифікатів

Шифрування трафіку між сервісами починається не з налаштування, а з чесної картини: хто з ким з’єднується, хто в парі клієнт, а хто сервер, де канал уже захищений, а де дані йдуть відкритим текстом.

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

Порядок робіт

1. Інвентаризація сервісів. Збираємо учасників обміну: ім’я, середовище, хто ініціює з’єднання, на якому порту слухає, що вже під захистом. Реєстр стає джерелом правди, за яким звіряємося на кожному наступному кроці.

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

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

4. Пілотний контур. Перші сервіси переводимо в режим спостереження: з’єднання перевіряється, але в разі незбігу не рветься — розходження пишеться в журнал. Так випливають пари «хто до кого ходить», яких не було в реєстрі.

5. Перевірка відмов. Ламаємо навмисно: центр, що випускає, недоступний у момент продовження, на вузлі розійшовся час, сертифікат відкликано, клієнт прийшов зі старим. У кожного випадку має бути передбачуваний результат і запис у журналі, а не мовчазний обрив.

6. Обов’язкова перевірка за групами. У строгий режим переводимо парами, від некритичних сервісів до основних, зі спостереженням за часткою відмов і можливістю повернути попередню поведінку однією настройкою.

Регламенти ротації ключів і політики доступу

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

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

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

Розбір впровадження: заміри до та після переведення

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

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

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

Що змінили

Усередині контуру підняли власну службу сертифікації та передали керування нею сервісній мережі Istio у режимі взаємної автентифікації.

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

Строгий режим увімкнули лише після того, як за кожним шляхом підтвердилася відсутність незашифрованого трафіку.

Окремо перевірили оборотність: повернення політики в режим спостереження відкриває канал за хвилини, тому помилка конфігурації не залишає сервіси без зв’язку.

Кількість інцидентів, пов’язаних із доступом між компонентами, зійшла до нуля, а ручні операції із сертифікатами перестали займати інженерний час.

Що робити, якщо сертифікати випускаються вручну?

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

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

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

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

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

Змінюємо по одному сервісу, після заміни перевіряємо не факт «зеленого замка», а повний шлях — взаємну автентифікацію, ім’я в сертифікаті, строк придатності, реакцію на відкликання.

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

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

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

Часті сумніви: сумісність, відмови, відкат

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

Що буде, якщо сертифікат минув або вузол недоступний?

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

Чи можна відкотити зміни, якщо щось пішло не так?

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

Як зрозуміти, який сервіс ламає з’єднання?

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

Обговоримо вашу схему захисту та повернемося з оцінкою

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

Для розбору достатньо такого набору:

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

Повернемося з оцінкою та планом робіт: перелік переведених зв’язків, порядок увімкнення за контурами, строки життя сертифікатів із процедурою ротації та схема відкату.

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

Автоматизацію випуску й продовження сертифікатів ставимо до переведення бойових зв’язків, інакше ручна ротація стає окремою точкою відмови.

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