Сервисная сетка должна разрешать вызовы только от конкретных сервисных идентичностей. За счёт какого механизма она проверяет отправителя без доверия к IP-адресу?
Сервисная сетка обычно использует взаимную аутентификацию TLS (mTLS) и удостоверения рабочих нагрузок. Прокси отправителя и прокси получателя устанавливают защищённое соединение, а сертификат отправителя подтверждает его криптографическую идентичность, не зависящую от IP-адреса.
После проверки сертификата прокси получателя применяет политику авторизации: например, разрешает вызовы только от идентичности конкретного сервиса или его namespace.
В традиционной сетевой модели доступ часто ограничивали по IP-адресам, подсетям и портам. Для динамической инфраструктуры этот подход стал ненадёжным: контейнеры и виртуальные машины получают новые адреса, перемещаются между узлами, а один адрес может использоваться разными экземплярами.
Сервисные сетки появились как способ вынести сетевые функции из бизнес-кода в инфраструктурный слой. К ним относятся шифрование трафика, идентификация рабочих нагрузок, политики доступа, повторные попытки и наблюдаемость.
Если разрешать вызовы по IP-адресу, злоумышленная или ошибочно настроенная рабочая нагрузка, получившая доступ к подходящему адресу, может выглядеть как доверенный клиент. Кроме того, IP-правила плохо отражают логическую структуру системы: сервис может состоять из множества краткоживущих реплик.
Неверная идентификация приводит к избыточным разрешениям, утечке данных и сложному аудиту. Простого шифрования трафика недостаточно: оно защищает содержимое, но само по себе не отвечает на вопрос, какой сервис установил соединение.
При включённом mTLS рядом с приложениями работают прокси сервисной сетки. Прокси отправителя получает сертификат от доверенного центра сертификации, а прокси получателя проверяет цепочку доверия, срок действия и соответствие сертификата ожидаемой идентичности.
Идентичность обычно связывается не с IP, а с атрибутами рабочей нагрузки: сервисным аккаунтом, namespace, именем сервиса или идентификатором, совместимым с моделью SPIFFE. Секретный ключ должен находиться у прокси или агента, который управляет удостоверением; приложение не обязано самостоятельно реализовывать TLS.
После успешного рукопожатия прокси получает подтверждённую идентичность клиента и сопоставляет её с политикой авторизации. Например, правило может разрешать вызовы к платёжному сервису только от идентичности сервиса заказов. Отдельно могут проверяться метод, путь, порт или дополнительные атрибуты запроса.
Важно различать аутентификацию и авторизацию. Сертификат доказывает, кто установил соединение, но не означает автоматического разрешения любого действия. Разрешение определяется политикой получателя.
Подход имеет компромиссы. Сетке нужны выпуск, ротация и отзыв удостоверений, доверенный центр сертификации, корректная передача идентичности через прокси и диагностика ошибок политики. Дополнительные прокси потребляют CPU и память, а неверно включённый режим строгого mTLS может нарушить связь с компонентами, которые не поддерживают нужный протокол.
Защита действует только там, где трафик действительно проходит через доверенные прокси или другой контролируемый enforcement point. Она не заменяет изоляцию сети, управление секретами, защиту узлов и контроль исходящего трафика.
В кластере сервис заказов обращался к платёжному сервису. Сначала доступ ограничивали по IP-подсетям, но после масштабирования и перемещения реплик правила стали разрешать лишние соединения, а расследование инцидентов не показывало логическую принадлежность клиента.
Рассматривались три варианта. Ручная поддержка IP-правил была простой, но плохо подходила для динамических адресов. Реализация mTLS в каждом приложении давала полный контроль, однако требовала одинаково надёжной криптографии, ротации сертификатов и обработки ошибок во всех командах. Сервисная сетка централизовала эти функции, но добавляла прокси, операционную сложность и зависимость от корректной настройки политик.
Выбрали сервисную сетку с автоматической выдачей удостоверений и строгой проверкой mTLS между сервисами. Доступ к платёжному сервису разрешили по идентичности сервиса заказов, а затем отдельно ограничили допустимые операции. В результате смена IP и количества реплик перестала требовать изменения правил, а аудит стал опираться на идентичности рабочих нагрузок; при этом для внешнего трафика сохранили отдельный механизм аутентификации и авторизации.
Нет. mTLS обеспечивает конфиденциальность, целостность канала и аутентификацию сторон, но не определяет разрешённые действия. Если политика авторизации отсутствует или слишком широкая, любой клиент с действующим удостоверением может получить больше доступа, чем требуется. Безопасная схема требует принципа наименьших привилегий и явных правил для целевых сервисов.
Он сможет выдавать себя за эту идентичность до истечения срока сертификата или его отзыва. Поэтому важны короткоживущие сертификаты, автоматическая ротация, защита закрытых ключей, ограничение области действия удостоверения и мониторинг необычного использования. mTLS не устраняет риск компрометации узла или прокси: он снижает риск подмены при условии сохранности ключевого материала.
Сертификат рабочей нагрузки отвечает на вопрос, какой сервис установил сетевое соединение, но не обязательно указывает конечного пользователя или его права. Для пользовательского доступа могут потребоваться отдельные механизмы: токены, сессии, внешняя аутентификация и проверка бизнес-разрешений. Если прокси передаёт пользовательские атрибуты дальше, нужно защищать их от подмены и чётко определить доверенную границу.