Co to jest Mutual TLS (mTLS)?

Mutual TLS (mTLS) - definicja

Mutual TLS to rozszerzenie protokołu Transport Layer Security, w którym zarówno serwer, jak i klient uwierzytelniają się wzajemnie przy użyciu certyfikatów X.509. Kanał komunikacyjny jest szyfrowany, a tożsamości obu stron potwierdzane w ramach jednego protokołu. Mechanizm jest zdefiniowany w standardach IETF dla TLS 1.2 i TLS 1.3, z użyciem profilu certyfikatów opisanych w RFC 5280. W TLS 1.3 pełny handshake (z uwierzytelnieniem klienta w handshaku) wymaga 1 RTT wymiany pakietów między klientem a serwerem, co skraca opóźnienie względem typowego pełnego handshaku w TLS 1.2, który zwykle wymaga 2 RTT. Potwierdzają to specyfikacje RFC 8446:2018 i RFC 5246:2008.

W kontekście anonimizacji zdjęć i nagrań wideo mTLS chroni dane w tranzycie między komponentami przetwarzania. Dotyczy to przesyłania plików wejściowych z serwera plików do modułu przetwarzania, komunikacji API orkiestrującej zadania oraz dystrybucji wyników z zamazanymi twarzami i tablicami rejestracyjnymi. mTLS jest środkiem technicznym wspierającym zapewnienie poufności i integralności transmisji w rozumieniu art. 32 RODO.

Rola mTLS w anonimizacji zdjęć i wideo

Przetwarzanie obrazów zawierających wizerunki i numery rejestracyjne obejmuje wrażliwe konteksty zgodności. mTLS ogranicza powierzchnię ataku podczas transferów na ścieżce przetwarzania i automatyzacji.

• Bezpieczne kanały między węzłami on-premise - np. worker AI do serwera kolejek - minimalizują ryzyko przechwycenia ramek z twarzami przed zamazaniem. Odnosi się to do metod wykrywania i rozmywania realizowanych lokalnie, bez transmisji do chmury.
• Uwierzytelnianie klientów technicznych - tylko dozwolone usługi mogą wysyłać zadania przetwarzania i pobierać wyniki. To wspiera zasadę minimalizacji i rozliczalności.
• Kontrola dostępu do API automatyzujących batch processing - w ekosystemie, gdzie harmonogram odpytuje usługę anonimowania, mTLS może zastąpić lub wzmocnić tokeny, zgodnie z RFC 8705.

Technologie i standardy mTLS

Wdrożenie mTLS opiera się na zestawie norm IETF, NIST i dobrych praktyk wdrożeniowych. Kluczowe różnice między TLS 1.2 i 1.3 wpływają na bezpieczeństwo i opóźnienia.

Certyfikaty X.509 muszą być zgodne z RFC 5280. Revokacja powinna opierać się na OCSP lub CRL, najlepiej z OCSP stapling (status_request), zgodnie z RFC 6066; OCSP jest zdefiniowane w RFC 6960, a rozszerzenie Multiple Certificate Status Request w RFC 6961. Dobór krzywych i długości kluczy powinien spełniać NIST SP 800-52r2 oraz SP 800-57 - zalecane ECDSA P-256 lub RSA 2048 dla minimum 112 bitów bezpieczeństwa, a preferencyjnie profile o sile 128-bitowej.

Kluczowe parametry i metryki wdrożenia mTLS

Parametry wdrożenia determinują poziom ochrony i wpływ na wydajność przetwarzania multimediów. Dobór zgodnie z normami ułatwia audyt zgodności.

• Wersja protokołu - TLS 1.3 jako domyślna, zgodnie z NIST SP 800-52r2 i zaleceniami IETF.
• Suite kryptograficzne - TLS_AES_128_GCM_SHA256 lub TLS_AES_256_GCM_SHA384. Dla urządzeń bez AES - TLS_CHACHA20_POLY1305_SHA256. Wszystkie wymienione w RFC 8446.
• Algorytm i długość klucza certyfikatu - ECDSA P-256 lub P-384, alternatywnie RSA 2048 lub 3072. Wytyczne NIST SP 800-57 Pt.1 Rev.5.
• Walidacja łańcucha - pełna weryfikacja ścieżki PKI zgodnie z RFC 5280, w tym EKU ClientAuth i ServerAuth.
• Revokacja - OCSP stapling w serwerze i wymuszenie walidacji w kliencie. RFC 6066; OCSP: RFC 6960 (oraz RFC 6961 dla multiple status).
• RTT handshaku - 1 RTT w TLS 1.3 zmniejsza opóźnienie zdalnych wywołań usług pomocniczych. Potwierdza to RFC 8446.
• Okres ważności certyfikatów - krótkie lifetimy zmniejszają ryzyko, zgodne z NIST SP 800-57. Praktycznie 90 dni lub mniej przy automatyzacji rotacji.
• Pinning CA lub publicznego klucza - redukcja ryzyka błędnych wydań, zgodnie z praktykami bezpieczeństwa aplikacji.

Wyzwania i ograniczenia mTLS

mTLS wzmacnia bezpieczeństwo warstwy transportowej, ale wymaga dojrzałej operacji PKI i świadomości protokołu.

• Zarządzanie cyklem życia certyfikatów - generowanie, dystrybucja, rotacje i odwołania wymagają automatyzacji. Błędy skutkują przestojami przetwarzania wideo.
• Kompatybilność - niektóre starsze biblioteki klienckie nie wspierają TLS 1.3 lub OCSP stapling. Należy planować fallback bez obniżania bezpieczeństwa.
• 0-RTT - nie zalecane dla żądań wymagających uwierzytelnienia klienta i odporności na replay. RFC 8446 sekcja 8.
• Brak ochrony danych w spoczynku - mTLS nie zastępuje szyfrowania dysków i kontroli dostępu lokalnie.

Przykłady zastosowań w ekosystemie Gallio PRO

Gallio PRO pracuje on-premise. Oprogramowanie automatycznie zamazuje twarze i tablice rejestracyjne, a inne elementy można zamazywać ręcznie w edytorze. mTLS zabezpiecza kanały komunikacji komponentów, ale nie służy do przetwarzania w czasie rzeczywistym, ponieważ Gallio PRO nie realizuje anonimizacji strumieniowej.

• Połączenie orkiestrowania z workerami przetwarzania - mTLS ogranicza dostęp do usługi rozmywania twarzy i tablic rejestracyjnych wyłącznie do zaufanych klientów technicznych.
• Dostęp do repozytorium wejściowego i wyjściowego - transfery plików z wizerunkami przed zamazaniem odbywają się przez kanał TLS z uwierzytelnieniem klienta.
• Integracje API w automatyzacji procesów - mTLS może być wymagany na bramce API zgodnie z RFC 8705, co ułatwia rozliczalność wywołań.
• Audyt zgodności - szyfrowanie transmisji stanowi środek techniczny zgodny z art. 32 RODO i normami ISO 27001, co dokumentuje się w rejestrze środków bezpieczeństwa.

Odniesienia normatywne i źródła

Poniżej zebrano dokumenty źródłowe i standardy, które definiują mTLS oraz zalecenia konfiguracyjne. Wymienione pozycje są podstawą do weryfikacji twierdzeń technicznych i liczbowych w tym haśle.

• IETF RFC 8446 - The Transport Layer Security TLS 1.3, 2018.
• IETF RFC 5246 - The Transport Layer Security TLS 1.2, 2008.
• IETF RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and CRL Profile, 2008.
• IETF RFC 6066 - Transport Layer Security TLS Extensions, 2011.
• IETF RFC 6960 - X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP, 2013.
• IETF RFC 6961 - The TLS Multiple Certificate Status Request Extension, 2013.
• IETF RFC 8705 - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens, 2020.
• NIST SP 800-52 Rev.2 - Guidelines for the Selection, Configuration, and Use of TLS Implementations, 2019.
• NIST SP 800-57 Part 1 Rev.5 - Recommendation for Key Management, 2020.
• ENISA - Transport Layer Security TLS Deployment Best Practice, 2019.
• RODO - Rozporządzenie 2016/679, art. 32 Bezpieczeństwo przetwarzania.