Вы создали микросервисы или внутреннее API. Они общаются между собой в частной сети, и кажется, что трафик уже защищен от внешнего мира. Но представьте, что злоумышленник или вредоносный скрипт внутри периметра пытается подключиться к вашей базе данных или платежному сервису. Как ему помешать? Старый подход «доверяй, но проверяй» внутри сети больше не работает. На смену ему приходит модель нулевого доверия (ZTNA), где каждый запрос должен доказать свою подлинность.
SSL/TLS – не только для браузера
Когда вы заходите на сайт с HTTPS, ваш браузер проверяет сертификат сервера. Это односторонняя проверка. Для внутренних API этого мало. Нужна mTLS – взаимная аутентификация TLS. В этой схеме и клиент, и сервер предъявляют свои цифровые сертификаты. Сервер проверяет не только логин и пароль из заголовка запроса, а саму сущность, которая делает запрос. Это фундаментально иной уровень доверия.
Как это работает на практике? Ваш TLS-клиент (другой микросервис) при подключении к API-шлюзу или балансировщику нагрузки отправляет свой сертификат клиента. Сервер проверяет его по цепочке доверия до корневого центра сертификации (CA), который вы контролируете. Если сертификат валиден и не отозван (проверка по CRL или OCSP), доступ разрешен. Это и есть аутентификация на уровне протокола.
Инфраструктура открытых ключей (PKI) – ваш внутренний паспортный стол
Чтобы развернуть mTLS, вам нужна своя PKI. Можно использовать самоподписанные корневые сертификаты, но для продакшена лучше настроить иерархию: доверенный корневой CA, который находится в офлайн-хранилище, и промежуточные CA для выпуска сертификатов. Это основа для управления доступом.
Авторизация – что можно делать после аутентификации – часто строится на основе данных в сертификате. Например, в поле Subject (CN) или SAN можно указать роль сервиса: «payment-service.prod». Затем на API-шлюзе или в Service Mesh (как Istio или Linkerd) настраиваются политики безопасности, разрешающие доступ к определенным эндпоинтам только сертификатам с конкретными атрибутами. Так вы сегментируете сеть на логическом уровне.
Жизненный цикл и автоматизация: без этого система рухнет
Сертификаты имеют срок действия. Управлять сотнями из них вручную – путь к сбою. Здесь в игру вступает DevSecOps. Инструменты вроде HashiCorp Vault или Let’s Encrypt для внутренних CA могут автоматизировать выпуск, продление и отзыв сертификатов. В Kubernetes эту роль часто берет на себя контроллер для Ingress-ресурсов.
Что это дает на практике? Вы предотвращаете MITM-атаки внутри сети, так как трафик шифруется, а стороны проверяют друг друга. Вы останавливаете брутфорс-атаки – без валидного сертификата злоумышленник не сможет даже установить TLS-соединение. Вы защищаете данные, обеспечивая их конфиденциальность и целостность.
Внедрение: с чего начать?
Начните с картографии: составьте список всех внутренних коммуникаций. Настройте mTLS для самых критичных из них – например, между API-шлюзом и сервисами с персональными данными. Используйте готовые решения для вашего стека: модули для Nginx или Apache, аннотации в Kubernetes. Не забудьте про мониторинг и аудит выданных сертификатов, настройте сигнализацию на истечение срока действия.
Защита внутренних API сертификатами – это не просто «галочка» для соответствия требованиям PCI DSS или GDPR. Это создание безопасной, управляемой и наблюдаемой среды, где каждый запрос подотчетен. Вы меняете парадигму с защиты периметра на защиту каждого эндпоинта и каждого бита данных, что и является сутью современной безопасности.