Сквозное шифрование трафика между сервисами: TLS/mTLS

Шифрование трафика между сервисами: где рвётся защита

Периметр обычно закрыт: терминация TLS на балансировщике, строгие правила входящего трафика, регулярные проверки снаружи. Внутри кластера картина другая — вызовы между сервисами уходят по сети кластера открытым текстом. HTTP, gRPC, обращения к кэшу и очереди идут без шифрования, и процесс, получивший права в своём пространстве имён, может слушать чужой трафик.

Проблема в том, что в средствах наблюдения этого не видно. Метрики показывают коды ответов и задержки, логи — тела запросов при включённой отладке, трассировки — длительность участков. Ни один из этих сигналов не отвечает на вопрос, был ли канал зашифрован и проверен ли сертификат вызывающей стороны. Служебные вызовы — проверки готовности, сбор метрик, обращения к брокеру — вообще редко попадают в учёт, поэтому незащищённые стыки сервисов годами живут вне чьей-либо зоны ответственности.

Отсюда цена ошибки: перехват данных внутри сети отдаёт токены доступа, ключи сессий и персональные данные в открытом виде, а заметить это постфактум почти нечем. Сетевая политика тоже не закрывает вопрос — она ограничивает, кто с кем может говорить, но не то, что именно они передают. На проверке требований безопасности такой участок становится первым замечанием, а его устранение — срочной задачей с переделкой конфигураций всех участников обмена.

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

Что меняется в надёжности и сроках после внедрения

Измеримые эффекты здесь удобнее смотреть по четырём величинам: доля ручных операций в выпуске и ротации сертификатов, время восстановления после отказа сервиса, число инцидентов на стыках и доля соединений, которые вообще проходят проверку подлинности обеих сторон. До внедрения обычно две из четырёх не измеряются вовсе — и это первое, что меняется.

Класс отказов, который уходит целиком, — неявное доверие внутри периметра. Когда сервис принимает запрос просто потому, что он пришёл из внутренней сети, любая подмена или ошибка маршрутизации выглядит как «странное поведение» и ищется часами. Взаимная проверка сертификатов превращает это в явный отказ на входе: соединение не устанавливается, в журнале видно, кто и почему не прошёл проверку.

Время восстановления сокращается за счёт ротации. Раньше продление сертификата было ручной операцией с окном простоя и риском, что его забудут, — теперь срок жизни короткий, а замена идёт автоматически и без остановки трафика. Отзыв скомпрометированного сертификата тоже становится обычной операцией, а не аварийным ночным мероприятием.

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

Режимы шифрования трафика: где что уместно

Режим защиты канала выбирают не по принципу «строже — лучше», а по границе доверия и по тому, кто управляет ключами на каждой стороне. При односторонней проверке сервер предъявляет сертификат, а клиент — нет: канал защищён от прослушивания, но вызывающая сторона остаётся анонимной. Взаимная проверка сторон (mTLS) добавляет встречное требование — сервис без валидного сертификата соединение не получит.

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

Переход между режимами почти никогда не делают одномоментно. Совместимее всего промежуточный вариант, когда точка входа принимает и проверенные, и непроверенные соединения, а доля mTLS-соединений служит критерием завершения миграции: дошла до нуля — строгий режим включается одной настройкой. Штатные средства управления сервисной сетью, например Istio, поддерживают такой переход из коробки, поэтому откат сводится к возврату прежней политики, а не к пересборке конфигурации.

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

Шифрование трафика между сервисами начинается не с настройки, а с честной картины: кто с кем соединяется, кто в паре клиент, а кто сервер, где канал уже защищён, а где данные идут открытым текстом. Без такого реестра любая настройка превращается в угадывание, и первый же забытый сервис ломает обмен.

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

1. Инвентаризация сервисов. Собираем участников обмена: имя, среда, кто инициирует соединение, на каком порту слушает, что уже под защитой. Реестр становится источником правды, по которому сверяемся на каждом следующем шаге.

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

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

4. Пилотный контур. Первые сервисы переводим в режим наблюдения: соединение проверяется, но при несовпадении не рвётся — расхождение пишется в журнал. Так всплывают пары «кто к кому ходит», которых не было в реестре.

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

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

Регламенты ротации ключей и политики доступа

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

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

Итог — предсказуемая эксплуатация: новый сервис встаёт в контур доверия за часы, отзыв ключа занимает минуты, а проверка со стороны безопасности проходит по документам, а не по рассказам.

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

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

Начали с инвентаризации: сняли карту обмена, отметили уже защищённые пути и зафиксировали базовые метрики — долю сервисов с взаимной аутентификацией, время выпуска сертификата, число отказов при ротации.

Что изменили

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

Отдельно проверили обратимость: возврат политики в режим наблюдения открывает канал за минуты, поэтому ошибка конфигурации не оставляет сервисы без связи. Число инцидентов, связанных с доступом между компонентами, ушло в ноль, а ручные операции с сертификатами перестали занимать инженерное время.

Что делать, если сертификаты выпускаются вручную?

Ручной выпуск — это когда сертификат запрашивают через консоль центра сертификации, а дату продления держат в календаре и в голове одного инженера. Пока сервисов десяток, схема терпима; на сотне узлов она даёт предсказуемый класс отказов: продление пропустили, цепочка доверия не подхватилась, и соединение между сервисами падает с ошибкой проверки сертификата. Ошибка видна не там, где причина, — диагностика уходит в сторону сети и балансировщика.

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

Переход на автоматизацию делают по-сервисно и без простоя: новые сертификаты выпускает уже автоматический центр, старые доживают свой срок, обе цепочки доверия добавляются в хранилища на клиентах. Меняем по одному сервису, после замены проверяем не факт «зелёного замка», а полный путь — взаимную аутентификацию, имя в сертификате, срок годности, реакцию на отзыв. Откат остаётся тривиальным: предыдущий сертификат и ключ лежат в хранилище до конца окна замены.

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

Частые сомнения: совместимость, отказы, откат

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

Что будет, если сертификат истёк или узел недоступен?

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

Можно ли откатить изменения, если что-то пошло не так?

Да. Политики описываются декларативно и версионируются, откат — возврат предыдущего описания, а не ручная правка. Первый этап идёт в режиме наблюдения: трафик идёт как раньше, нарушения только логируются, поэтому строгий режим включаем уже по фактам.

Как понять, какой сервис ломает соединение?

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

Обсудим вашу схему защиты и вернёмся с оценкой

Чтобы оценка опиралась на факты, а не на предположения, нам нужен срез текущего состояния обмена. Без него этап внедрения защиты обмена упирается в неучтённые связи: сервис, который все считали внутренним, ходит через общий узел, и его трафик остаётся открытым.

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

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

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

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