Wzorce implementacji Mutual TLS (mTLS)

Standardowy TLS uwierzytelnia wyłącznie serwer wobec klienta za pomocą certyfikatu. Wzajemne TLS (mTLS) rozszerza ten mechanizm: obie strony przedstawiają certyfikaty i weryfikują je. Klient przedstawia certyfikat klienta po otrzymaniu żądania serwera (za pomocą CertificateRequest podczas uzgadniania TLS). Serwer weryfikuje certyfikat klienta względem zaufanego CA. mTLS stanowi podstawę sieci w modelu zero trust: zamiast polegać na bezpieczeństwie granic sieci, usługi uwierzytelniają się wzajemnie kryptograficznie przy każdym połączeniu. Service meshe, takie jak Istio, Linkerd i Consul Connect, w sposób przezroczysty implementują mTLS między mikrousługami.

Uzgadnianie mTLS rozszerza TLS 1.3 w następujący sposób: po ServerHello oraz certyfikacie serwera i Finished serwer wysyła komunikat CertificateRequest określający akceptowane urzędy certyfikacji i algorytmy podpisu. Klient odpowiada komunikatami Certificate (łańcuch certyfikatu klienta) oraz CertificateVerify (podpis transkryptu wykonany za pomocą klucza prywatnego klienta). Serwer weryfikuje łańcuch certyfikatu klienta względem magazynu zaufanych CA i sprawdza podpis CertificateVerify. Jeśli obie weryfikacje się powiodą, połączenie jest wzajemnie uwierzytelnione. Klient nie może sfałszować CertificateVerify bez klucza prywatnego odpowiadającego certyfikatowi.

W środowiskach service mesh certyfikaty klienta są zwykle wydawane przez wewnętrzny urząd certyfikacji (CA). Istio używa identyfikatorów SPIFFE (Secure Production Identity Framework for Everyone) SVID: każdy workload otrzymuje certyfikat z identyfikatorem URI SAN (Subject Alternative Name) SPIFFE, takim jak spiffe://cluster.local/ns/default/sa/payment-service. Certyfikaty te są krótkotrwałe (24 godziny) i są automatycznie rotowane przez płaszczyznę sterowania mesha (istiod). W mTLS skierowanym do użytkownika (np. w firmowych sieciach VPN lub wśród klientów API) certyfikaty mogą być wydawane przez firmowy urząd certyfikacji, mieć dłuższy czas życia i być dostarczane za pośrednictwem MDM (zarządzania urządzeniami mobilnymi) na urządzenia pracowników.

Weryfikacja mTLS po stronie serwera obejmuje kilka etapów: (1) Walidacja łańcucha — sprawdzenie, czy łańcuch certyfikatu klienta prowadzi do zaufanego głównego CA w magazynie CA klientów serwera. (2) Sprawdzenie okresu ważności — upewnienie się, że certyfikat nie wygasł ani nie zaczął jeszcze obowiązywać. (3) Sprawdzenie unieważnienia — potwierdzenie za pomocą OCSP lub CRL, że certyfikat nie został unieważniony. (4) Dopasowanie SAN/CN — wyodrębnienie deklaracji tożsamości z SAN certyfikatu (identyfikatora URI SPIFFE, nazwy DNS lub adresu e-mail). (5) Autoryzacja — sprawdzenie, czy uwierzytelniona tożsamość ma uprawnienia do dostępu do żądanego zasobu. Etapy 4 i 5 wymagają logiki na poziomie aplikacji wykraczającej poza podstawową konfigurację TLS.

Krótkotrwałe certyfikaty eliminują potrzebę jawnego unieważniania: jeśli certyfikat wygasa po 24 godzinach, okno skutków jego przejęcia jest ograniczone. Rotacja wymaga: (1) Rotacji wstępnej — wystawienia nowego certyfikatu przed wygaśnięciem starego (rotację należy wykonać po upływie 80% okresu ważności). (2) Podmiany bez przestoju — usługa musi akceptować zarówno stare, jak i nowe certyfikaty w okresie przejściowym. (3) Kontrolowanego przeładowania — stos TLS musi przeładowywać dane uwierzytelniające bez zrywania istniejących połączeń (nginx: nginx -s reload; Envoy: dynamic xDS certificate update). SPIFFE Workload API (implementowane przez SPIRE) automatyzuje dostarczanie i rotację certyfikatów za pośrednictwem API gniazda domeny Unix.

Istio implementuje mTLS w sposób przezroczysty za pośrednictwem proxy sidecar Envoy wstrzykiwanych do każdego poda. Płaszczyzna sterowania (istiod) działa jako CA, używając certyfikatu pośredniego podpisanego przez główny urząd certyfikacji siatki. Sidecar każdego poda otrzymuje SPIFFE SVID za pośrednictwem interfejsu API SDS (Secret Discovery Service). Zasady PeerAuthentication konfigurują tryb mTLS: STRICT (mTLS wymagane), PERMISSIVE (akceptowane jest zarówno mTLS, jak i połączenia w jawnym tekście, na potrzeby migracji) lub DISABLE. Zasoby AuthorizationPolicy określają, które usługi mogą się ze sobą komunikować; uprawnienia są sprawdzane na podstawie tożsamości SPIFFE zawartej w certyfikacie klienta. Mechanizm ten zapewnia architekturę zero trust w obrębie klastra bez zmian w kodzie aplikacji.

W przypadku zewnętrznych klientów API mTLS zapewnia silniejsze uwierzytelnianie niż klucze API lub tokeny OAuth. Klient przechowuje klucz prywatny w bezpiecznym magazynie (HSM, magazynie kluczy systemu operacyjnego albo programowym magazynie kluczy chronionym hasłem). Certyfikat klienta jest przypięty do oczekiwanego CA punktu końcowego API. Każde żądanie API jest uwierzytelniane na poziomie TLS — nie jest wymagany osobny nagłówek Authorization. Cloudflare API Shield, certyfikaty klientów AWS API Gateway oraz mTLS dla kont usług Google Cloud implementują ten model. Zaatakowany klucz API może zostać użyty z dowolnego miejsca, natomiast wykorzystanie zaatakowanego klucza prywatnego mTLS wymaga również kradzieży urządzenia, na którym działa klient.

Wdrożenia mTLS wiążą się z kilkoma wyzwaniami operacyjnymi. (1) Dystrybucja certyfikatów — bezpieczne dostarczanie certyfikatów klienta do wszystkich usług, szczególnie w dynamicznych środowiskach, w których liczba podów zmienia się w czasie. (2) Kompromitacja CA — wewnętrzny urząd certyfikacji jest celem o wysokiej wartości; w przypadku jego kompromitacji wszystkie certyfikaty usług zostają unieważnione. Ograniczyć to ryzyko pomagają urzędy certyfikacji wspierane przez HSM oraz główne urzędy certyfikacji działające offline. (3) Debugowanie — zaszyfrowany ruch mTLS jest nieczytelny dla standardowych narzędzi debugujących; potrzebna jest obserwowalność siatki usług (Jaeger, Kiali). (4) Zgodność z urządzeniami pośredniczącymi — proxy przeprowadzające inspekcję TLS przerywają mTLS, chyba że zostaną jawnie skonfigurowane do przekazywania certyfikatów klienta. (5) Incydenty związane z wygaśnięciem certyfikatów — nieudana rotacja może spowodować całkowitą niedostępność usług.

SPIFFE (Secure Production Identity Framework for Everyone) definiuje standard tożsamości obciążeń wykorzystujący SVID X.509. SPIRE (SPIFFE Runtime Environment) jest implementacją referencyjną. SPIRE Server działa jako urząd rejestracji i CA. SPIRE Agents działają na każdym węźle, potwierdzają tożsamość obciążenia za pomocą mechanizmów potwierdzających tożsamość węzła (AWS instance identity, Kubernetes service account JWT, TPM) oraz mechanizmów potwierdzających tożsamość obciążenia (Unix PID, metadane środowiska uruchomieniowego kontenera). Workload API dostarcza obciążeniom SVID za pośrednictwem gniazda domeny Unix, wykorzystując prosty interfejs API gRPC. SPIRE integruje się z Envoy, Nginx oraz głównymi siatkami usług jako źródło certyfikatów.

W przypadku wdrożeń mTLS o wysokim poziomie bezpieczeństwa klucze prywatne powinny znajdować się w modułach HSM (Hardware Security Modules), a nie w programowych magazynach kluczy. Biblioteka TLS (OpenSSL, BoringSSL) ładuje klucz prywatny za pośrednictwem interfejsu PKCS#11, który przekierowuje operacje podpisywania do HSM. Klucz prywatny nigdy nie opuszcza granic HSM w postaci jawnego tekstu. Dostępne w chmurze moduły HSM obejmują AWS CloudHSM, Azure Dedicated HSM i Google Cloud HSM. W przypadku mTLS na poziomie urządzenia (IoT, laptopy firmowe) podobną funkcję zapewnia TPM 2.0 — klucz klienta TLS jest powiązany z TPM, a podpisywanie wymaga autoryzacji TPM, co znacznie utrudnia wyodrębnienie klucza ze skompromitowanego urządzenia.

Testowanie mTLS wymaga narzędzi obsługujących przedstawianie certyfikatu klienta. 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. Do testowania siatki usług polecenie istioctl proxy-config secret pod/name pokazuje bieżący certyfikat i termin jego ważności. Należy wykonać kubectl exec w podzie, a następnie użyć curl do wywołania punktu końcowego administratora sidecara (localhost:15000), aby sprawdzić aktywne listenery i ich konfigurację mTLS. Automatyczne testy rotacji powinny sprawdzać, czy połączenia pozostają stabilne podczas zdarzeń rotacji certyfikatów.

Jaki dodatkowy krok wprowadza mTLS w porównaniu ze standardowym TLS?

mTLS dodaje do TLS uwierzytelnianie za pomocą certyfikatu klienta — obie strony weryfikują wzajemnie swoje certyfikaty. SPIFFE SVID zapewniają standaryzowaną tożsamość obciążenia za pośrednictwem identyfikatorów URI SPIFFE w polach SAN certyfikatu. Istio implementuje mTLS w sposób przezroczysty za pośrednictwem sidecarów Envoy z trybami STRICT/PERMISSIVE. Certyfikaty krótkoterminowe (24 godziny) eliminują potrzebę unieważniania certyfikatów i ograniczają czas wykorzystania skutków kompromitacji. SPIRE automatyzuje wystawianie i rotację certyfikatów za pośrednictwem Workload API. Wdrożenia o wysokim poziomie bezpieczeństwa powinny przechowywać klucze prywatne mTLS w HSM lub TPM. Wyzwania operacyjne obejmują ochronę klucza CA, zgodność z urządzeniami pośredniczącymi oraz rotację bez przestojów.