Шаблоны реализации взаимного TLS (mTLS)

Стандартный TLS аутентифицирует только сервер для клиента с помощью сертификата. Взаимный TLS (mTLS) расширяет эту схему: обе стороны предъявляют сертификаты и проверяют их. Клиент предъявляет клиентский сертификат после запроса сервера, переданного через CertificateRequest в процессе рукопожатия TLS. Сервер проверяет клиентский сертификат относительно доверенного CA. mTLS является основой сетей с нулевым доверием: вместо опоры на безопасность сетевого периметра сервисы криптографически аутентифицируют друг друга при каждом соединении. Сервисные сетки, такие как Istio, Linkerd и Consul Connect, прозрачно реализуют mTLS между микросервисами.

Рукопожатие mTLS расширяет TLS 1.3 следующим образом: после ServerHello и сертификата сервера с сообщением о завершении сервер отправляет сообщение CertificateRequest, указывающее допустимые центры сертификации и алгоритмы подписи. Клиент отвечает сообщениями Certificate (цепочка сертификатов клиента) и CertificateVerify (подпись транскрипции с помощью закрытого ключа клиента). Сервер проверяет цепочку клиентского сертификата относительно хранилища доверенных CA и проверяет подпись CertificateVerify. Если обе проверки успешны, соединение считается взаимно аутентифицированным. Клиент не может подделать CertificateVerify без закрытого ключа, соответствующего сертификату.

В средах сервисных сеток клиентские сертификаты обычно выдаются внутренним CA. Istio использует SPIFFE (структуру удостоверений производственной среды для всех) и SVID: каждая рабочая нагрузка получает сертификат с URI SAN SPIFFE (альтернативным именем субъекта), например spiffe://cluster.local/ns/default/sa/payment-service. Срок действия таких сертификатов невелик (24 часа), и плоскость управления сеткой (istiod) автоматически выполняет их ротацию. В ориентированном на пользователей mTLS, например в корпоративных VPN и клиентах API, сертификаты могут выдаваться корпоративным CA с более длительными сроками действия и доставляться через MDM (управление мобильными устройствами) на устройства сотрудников.

Проверка mTLS на стороне сервера включает несколько этапов: (1) Проверка цепочки — убедиться, что цепочка клиентского сертификата восходит к доверенному корневому CA в хранилище клиентских CA сервера. (2) Проверка срока действия — убедиться, что сертификат не истёк и уже действителен. (3) Проверка отзыва — с помощью OCSP или CRL убедиться, что сертификат не был отозван. (4) Сопоставление SAN/CN — извлечь утверждение об идентичности из SAN сертификата (URI SPIFFE, имя DNS или адрес электронной почты). (5) Авторизация — проверить, имеет ли аутентифицированная идентичность право доступа к запрошенному ресурсу. Этапы 4 и 5 требуют логики на уровне приложения, выходящей за рамки базовой настройки TLS.

Короткоживущие сертификаты устраняют необходимость в явном отзыве: если срок действия сертификата составляет 24 часа, компрометация имеет ограниченное окно воздействия. Ротация требует: (1) Подготовительной ротации — выпуска нового сертификата до истечения срока действия старого (ротацию следует выполнять по достижении 80% срока действия). (2) Замены без простоя — сервис должен принимать и старые, и новые сертификаты в переходный период. (3) Плавной перезагрузки — стек TLS должен перезагружать учётные данные без разрыва существующих соединений (nginx: nginx -s reload; Envoy: динамическое обновление сертификата через xDS). API рабочих нагрузок SPIFFE, реализуемый SPIRE, автоматизирует доставку и ротацию сертификатов через API доменного сокета Unix.

Istio прозрачно реализует mTLS с помощью прокси-сайдкаров Envoy, внедряемых в каждый под. Управляющая плоскость (istiod) выполняет роль CA, используя промежуточный сертификат, подписанный корневым CA сетки. Сайдкар каждого пода получает SPIFFE SVID через API SDS (службы обнаружения секретов). Политики PeerAuthentication настраивают режим mTLS: STRICT (mTLS обязателен), PERMISSIVE (принимаются и mTLS, и незашифрованный текст, что удобно для миграции) или DISABLE. Ресурсы AuthorizationPolicy определяют, каким службам разрешено взаимодействовать; проверка выполняется по идентификатору SPIFFE в сертификате клиента. Это реализует модель нулевого доверия внутри кластера без изменений в коде приложения.

Для внешних клиентов программных интерфейсов mTLS обеспечивает более надёжную аутентификацию, чем ключи программного интерфейса или токены OAuth. Клиент хранит закрытый ключ в защищённом хранилище (HSM, хранилище ключей OS или программный ключ с парольной фразой). Сертификат клиента закреплён за ожидаемым CA конечной точки программного интерфейса. Каждый запрос к программному интерфейсу аутентифицируется на уровне TLS — отдельный заголовок Authorization не требуется. API Shield Cloudflare, клиентские сертификаты API Gateway AWS и mTLS для сервисных аккаунтов Google Cloud реализуют эту модель. Скомпрометированный ключ программного интерфейса можно использовать откуда угодно; для использования скомпрометированного закрытого ключа mTLS потребуется также украсть устройство, на котором работает клиент.

Развёртывание mTLS связано с несколькими эксплуатационными проблемами. (1) Распространение сертификатов — безопасная доставка сертификатов клиентов во все службы, особенно в динамических средах, где количество подов постоянно меняется. (2) Компрометация CA — внутренний CA является целью высокой ценности; при его компрометации все сертификаты служб становятся недействительными. CA на базе HSM и автономные корневые CA снижают этот риск. (3) Отладка — зашифрованный трафик mTLS недоступен для стандартных средств отладки; необходимы средства наблюдаемости сервисной сетки (Jaeger, Kiali). (4) Совместимость с промежуточными сетевыми устройствами — прокси проверки TLS нарушают работу mTLS, если явно не настроить их на передачу сертификатов клиентов. (5) Инциденты из-за истечения срока действия сертификатов — сбой ротации может привести к полной остановке служб.

SPIFFE (стандарт защищённой производственной идентификации для всех) определяет стандарт идентификации рабочих нагрузок с использованием X.509 SVID. SPIRE (среда выполнения SPIFFE) является эталонной реализацией. SPIRE Server выполняет роль регистрационного центра и CA. SPIRE Agents работают на каждом узле, подтверждают идентичность рабочих нагрузок с помощью аттестаторов узлов (удостоверение экземпляра AWS, JWT учётной записи службы Kubernetes, TPM) и аттестаторов рабочих нагрузок (Unix PID, метаданные среды выполнения контейнеров). Workload API доставляет SVID рабочим нагрузкам через доменный сокет Unix, используя простой программный интерфейс gRPC. SPIRE интегрируется с Envoy, Nginx и основными сервисными сетками как источник сертификатов.

В системах mTLS с высокими требованиями к безопасности закрытые ключи должны храниться в аппаратных модулях безопасности (HSM), а не в программных хранилищах ключей. Библиотека TLS (OpenSSL, BoringSSL) загружает закрытый ключ через интерфейс PKCS#11, перенаправляющий операции подписи в HSM. Закрытый ключ никогда не покидает границы HSM в открытом виде. К облачным вариантам HSM относятся AWS CloudHSM, Azure Dedicated HSM и Google Cloud HSM. Для mTLS на уровне устройств (IoT, корпоративные ноутбуки) TPM 2.0 выполняет аналогичную функцию: ключ клиента TLS привязывается к TPM, а для подписи требуется авторизация TPM, поэтому извлечь ключ со скомпрометированного устройства чрезвычайно трудно.

Для тестирования mTLS нужны средства, поддерживающие передачу сертификата клиента. OpenSSL s_client: openssl s_client -connect host:443 -cert client.pem -key client.key -CAfile server-ca.pem. curl: curl --cert client.pem --key client.key --cacert server-ca.pem https://host. Для тестирования сервисной сетки команда istioctl proxy-config secret pod/name показывает текущий сертификат и срок его действия. Выполните в поде команду kubectl exec и используйте curl для обращения к административной конечной точке сайдкара (localhost:15000), чтобы проверить активные прослушиватели и их конфигурацию mTLS. Автоматизированное тестирование ротации должно подтверждать, что соединения остаются стабильными во время смены сертификатов.

Какой дополнительный шаг добавляет mTLS по сравнению с обычным TLS?

mTLS добавляет к TLS аутентификацию с помощью сертификата клиента — обе стороны проверяют сертификаты друг друга. SVID SPIFFE обеспечивают стандартизированную идентичность рабочих нагрузок через URI SPIFFE в полях SAN сертификатов. Istio прозрачно реализует mTLS с помощью сайдкаров Envoy с режимами STRICT/PERMISSIVE. Короткоживущие сертификаты (24 часа) устраняют необходимость отзыва и ограничивают период, в течение которого можно использовать скомпрометированные данные. SPIRE автоматизирует выпуск и ротацию сертификатов через Workload API. Закрытые ключи mTLS должны храниться в HSM или TPM при развёртывании систем с высокими требованиями к безопасности. К эксплуатационным проблемам относятся защита ключей CA, совместимость с промежуточными сетевыми устройствами и ротация без простоя.