Mutual TLS authentication in Azure Front Door (preview)

Dotyczy: ✔️ Front Door Premium

Wzajemne uwierzytelnianie TLS (mTLS), czyli uwierzytelnianie klienta, zapewnia, że ruch jest bezpieczny i godny zaufania w obu kierunkach między klientem a serwerem. Korzystając z wzajemnego TLS, możesz skonfigurować Azure Front Door do weryfikacji tożsamości klienta poprzez przedstawienie ważnego certyfikatu klienta. Wzajemna autentyzacja TLS jest przydatna w sytuacjach, gdy musisz bezpiecznie zidentyfikować i zarządzać klientami, aby skierować zasoby takie jak aplikacje biznesowe (B2B), aplikacje Internetu Rzeczy (IoT), aplikacje bankowe, VPN, sieci korporacyjne i inne.

Możesz używać wzajemnego TLS oraz innych autoryzacji i metod uwierzytelniania obsługiwanych przez Azure Front Door.

Tryby walidacji wzajemnej TLS

• Wyłącz mTLS: certyfikat klienta i walidacje nie są wymagane. Ta opcja jest domyślnie zaznaczona.

• Włącz mTLS:

  • Wymagany i zweryfikowany certyfikat klienta: Certyfikat klienta jest obowiązkowy. Azure Front Door przeprowadza pełną weryfikację, w tym sprawdza obecność certyfikatów klienta, ich ważność oraz sprawdzanie przed odwołaniem, łańcuchem CA root oraz listą SAN/CN. Azure Front Door przekierowuje żądanie z nagłówkiem X-Azure-ClientCertificate do the origin. Ta opcja jest domyślnym scenariuszem, gdy mTLS jest włączony.

  • Wymagany certyfikat klienta, ale niezweryfikowany: Certyfikat klienta jest obowiązkowy. Azure Front Door nie wykonuje żadnych innych walidacji. Azure Front Door porzuca żądania, które nie zawierają certyfikatów. Źródło musi przeprowadzić wszystkie walidacje. Domyślnie Azure Front Door przekazuje certyfikat do backendu za pomocą nagłówków w tym trybie.

    • Walidacja certyfikatu klienta, jeśli jest przedstawiona: Certyfikat klienta nie jest obowiązkowy. Azure Front Door przeprowadza pełną walidację, gdy obecny jest certyfikat klienta i przekazuje go do źródła przez X-Azure-ClientCertificate nagłówek. Jeśli klient nie przedstawi certyfikatu klienta, Azure Front Door przekazuje żądanie do Origin w celu dalszej weryfikacji.

  • Przejście mTLS do źródła: Certyfikat klienta nie jest wymagany. Azure Front Door nie wykonuje żadnych walidacji. Źródło musi przeprowadzić wszystkie walidacje.

Walidacja uwierzytelniania klienta

Gdy konfigurujesz Azure Front Door do weryfikacji certyfikatu klienta, sprawdza on następujące informacje:

• Aktualna data jest krótsza niż data certyfikatu Not After .

• Aktualna data jest większa lub równa dowie certyfikatu Not Before .

• Certificate Extended Key Usage nie jest obecny lub jeśli istnieje, zawiera OID uwierzytelniania klienta.

• Ważność i integralność, że certyfikat nie został zmieniony, zmienił format certyfikatu.

• Sprawdź łańcuch certyfikatów, jeśli certyfikat klienta jest wydany przez zaufanego emitenta dla określonej domeny, CN (nazwa certyfikatu) certyfikatów tworzy nieprzerwany łańcuch.

Możesz także skonfigurować opcjonalne walidacje, takie jak:

• Zweryfikowaj rozszerzenie SAN/CN certyfikatu klienta względem listy Dozwolonych SAN przesłanej do Azure Front Door. Własna domena Azure Front Door musi być wyraźnie uwzględniona na tej liście, aby była uznana za ważną do wzajemnej walidacji TLS. SAN jest walidowany jako pierwszy, jeśli nie ma dopasowania lub SAN jest pusty, wtedy CN jest walidowany. Jeśli któryś z SAN lub CN spełnia listę dozwolonych SAN skonfigurowaną w Azure Front Door, weryfikacja się udaje.

• Sprawdź status odwołania certyfikatu klienta, korzystając z OCSP (Online Certificate Status Protocol).

Sprawdzanie odwołania certyfikatów

Azure Front Door wspiera walidację względem statusu odwołania certyfikatu. Domyślnie jest ona włączona. Podczas walidacji Azure Front Door wyszukuje certyfikat przedstawiony przez klienta, używając zdefiniowanego respondera OCSP w rozszerzeniu Authority Information Access (AIA). Jeśli certyfikat klienta zostanie cofnięty, Azure Front Door odpowiada klientowi kodem statusowym HTTP 403 oraz uzasadnieniem działania. Jeśli certyfikat jest ważny, Azure Front Door nadal przetwarza żądanie.

Czy mTLS obsługuje certyfikaty publiczne i prywatne?

Azure Front Door obecnie obsługuje certyfikaty wydawane zarówno przez znane publiczne urzędy certyfikacyjne, jak i prywatnie ugruntowane urzędy certyfikacyjne.

• Certyfikaty CA wydawane przez znane organy certyfikacyjne: Zaufane magazyny certyfikatów zazwyczaj zawierają certyfikaty pośrednie i rootowe, które umożliwiają zaufane połączenia przy minimalnej lub żadnej dodatkowej konfiguracji na urządzeniu.

• Certyfikaty CA wydawane przez organizacje ustanowiły autorytety certyfikacyjne: Twoja organizacja zazwyczaj wydaje te certyfikaty prywatnie, a inne podmioty im nie ufają. Musisz importować certyfikaty pośrednie i root do zaufanych magazynów certyfikatów, aby klienci mogli ustanowić zaufanie łańcuchowe.

Jednak Azure Front Door wykonuje kontrole Extended Key Usage (EKU) na certyfikatach klientów, aby upewnić się, że są one przeznaczone do uwierzytelniania klienta. Ze względu na zmiany branżowe, publiczne organy certyfikacyjne (CA) wkrótce przestają wydawać certyfikaty uwierzytelniania klienta z wymaganym EKU.

Przejście na korzystanie z prywatnych CA, które mogą nadal wydawać certyfikaty z odpowiednim EKU, dla scenariuszy mTLS na Azure Front Door. To przejście zapewnia nieprzerwane i bezpieczne uwierzytelnianie klienta.

Ważne kwestie projektowe przed implementacją mTLS na domenach Front Door

• Włącz mTLS na nowych domenach i nowych punktach końcowych, aby uniknąć niepotrzebnych przestojów.

• Gdy włączasz mTLS, nie możesz włączyć buforowania tras lub nadpisywania tras przez silnik reguł przez buforowanie. To ograniczenie uniemożliwia zwracanie pamięci podręcznej do klientów nieuwierzytelnionych.

• mTLS działa funkcjonalnie na domenie. Jednak aby zapewnić bezpieczeństwo tam, gdzie złośliwi użytkownicy nie mogą obejść mTLS i dotrzeć do twojego punktu źródłowego, istnieje kontrola mTLS na punkcie końcowym Azure Front Door. Przed włączeniem mTLS na niestandardowej domenie, najpierw włącz mTLS na punkcie końcowym Azure Front Door, do którego domena niestandardowa będzie powiązana. Wszystkie domeny z mTLS mogą być powiązane tylko z trasami pod takimi punktami końcowymi. Nie można przypisać domen z mieszanym stanem wzajemnej uwierzytelniania do tego samego punktu końcowego.

• Nie można powiązać domeny endpoint Azure Front Door z trasami, gdy mTLS jest włączone na endpointzie Front Door. Z drugiej strony, musisz odłączyć domenę endpoint od wszystkich tras pod tym punktem, zanim włączysz mTLS na tym punkcie.

• Jest przestoj, jeśli włączysz mTLS na istniejącej domenie Azure Front Door, ponieważ musisz wprowadzić następujące zmiany. Włącz mTLS do nowych niestandardowych domen.

1. Stwórz nowy endpoint z włączonym mTLS lub użyj dowolnego istniejącego punktu Azure Front Door z włączonym mTLS.

2. Odłącz domenę niestandardową od istniejących tras i punktu końcowego, który nie ma włączonego mTLS.

3. Następnie ponownie powiązać domenę niestandardową z punktem końcowym.

• Po włączeniu wzajemnej uwierzytelniania na domenie, jej wyłączenie powoduje również przestoje.

  1. Odłącz domenę niestandardową od wszystkich tras w ramach istniejącego endpointu z włączonym mTLS.

  2. Wyłącz mTLS na domenie.

  3. Ponownie połącz domenę z innym punktem końcowym bez włączonego mTLS.

• Dodaj kontrolę dostępu do swojego źródła, aby potwierdzić, że żądanie pochodzi z ważnego Front Door. Aby uzyskać więcej informacji, zobacz Zabezpiecz ruch do źródeł usługi Azure Front Door.

• Zarządzanie certyfikatami w CA: Przesyłaj root oraz do trzech pośrednich (PEM, <25 KB) przez Azure Key Vault. Brak autorotacji, ale podwójne wsparcie CA umożliwia płynne przewracanie się (rollover).

• Azure Front Door wykonuje kontrole Extended Key Usage (EKU) na certyfikatach klientów, aby upewnić się, że są one przeznaczone do uwierzytelniania klienta, co jest ważnym środkiem bezpieczeństwa. Jednak ze względu na zmiany branżowe, publiczne Urzędy Certyfikacyjne (CA) wkrótce przestaną wydawać certyfikaty uwierzytelniania klienta z wymaganym EKU. Przejście na korzystanie z prywatnych CA, które mogą nadal wydawać certyfikaty z odpowiednim EKU dla scenariuszy mTLS na Azure Front Door, zapewniając nieprzerwane i bezpieczne uwierzytelnianie klientów.

• Klienci odchodzą od OCSP. Podczas sprawdzania odwołania certyfikatu Front Door, Azure Front Door obecnie sprawdza tylko OCSP.

• Jeśli klient wysyła żądania z następującymi nagłówkami, Azure Front Door porzuca te nagłówki i przekazuje żądanie do origin.

  • X-Azure-ClientCertEndDate
  • X-Azure-ClientCertFingerprint
  • X-Azure-ClientCertIssuer
  • X-Azure-ClientCertSerial
  • X-Azure-ClientCertStartDate
  • X-Azure-ClientCertSubject
  • X-Azure-ClientCertVerify
  • X-Azure-ClientCertificate

Jakie metryki i pola logu ujawnia rozwiązanie?

Rozwiązanie ujawnia następujące metryki:

• Liczba żądań mTLS.

• Nieudane żądania mTLS.

• żądania błędów mTLS, podzielone według typów błędów, nazw hostów SNI oraz protokołów TLS.

Limit limitu konfiguracji

• Łańcuch certyfikatów CA klienta może obejmować root oraz do trzech pośrednich.

• Certyfikaty CA muszą być kodowane PEM i mieć mniej niż 25 KB.

• Automatyczna rotacja nie jest obsługiwana.

• Możesz dołączyć dwa certyfikaty CA dla płynnego przejścia podczas wygaśnięcia lub cofnięcia. Azure Front Door używa ważnego certyfikatu CA do walidacji w czasie działania.

Kroki konfiguracji

1. Aby dowiedzieć się więcej o ograniczeniach, zobacz sekcję dotyczącą najważniejszych aspektów projektowych . Zaleca się włączenie mTLS na nowych punktach końcowych i domenach.

2. Zaloguj się do portalu Azure i wyszukaj swój profil Front Door.

3. W sekcji Bezpieczeństwo wybierz certyfikaty Mutual TLS CA. Widzisz listę istniejących łańcuchów certyfikatów mTLS, jeśli wcześniej je przesłałeś.

4. Wybierz + Dodaj. Widzisz Key Vault i Secret obiekty, do których masz dostęp. Wybierz te, których chcesz używać jako klucza publicznego w mTLS handshake.

5. W ustawieniach wybierz Menedżer Drzwi wejściowych. Widzisz listę swoich punktów końcowych.

6. Wybierz + Dodaj punkt końcowy i zaznacz Enforce mutual TLS.

   Note

   Nie możesz dodać domyślnej domeny Azure Front Door (na przykład .z01.azurefd.net) jako domeny do tras na tym punkcie końcowym, gdy włączone jest wymuszanie wzajemnego TLS. Przejdź do kolejnego kroku, aby utworzyć własne domeny z włączonym mTLS przed tworzeniem tras.

7. W obszarze Ustawienia wybierz pozycję Domeny. Widzisz listę swoich istniejących domen niestandardowych.

8. Wybierz + Dodaj.

9. W Dodaj stronę domeny skonfiguruj swoją domenę, a następnie przewiń do Zaawansowanych ustawień i wybierz Włącz wzajemny TLS , aby skonfigurować wzajemny TLS dla domeny.

10. Wybierz Dodaj domenę.

    1. Tryb TLS Mutual (TLS): wybierz spośród czterech opcji

       • Wymagany i zweryfikowany certyfikat klienta
       • Wymagany certyfikat klienta jest wymagany, ale niezweryfikowany
       • Walidacja certyfikatu klienta, jeśli jest prezentowana
       • Przejście mTLS do Origin

    2. Wybierz certyfikat CA gdy jest wypełniony dla Azure Front Door, aby zweryfikować certyfikat klienta przeciw.

    3. Włącz Sprawdzenie Odwołania Certyfikatu.

    4. Dodaj listę SAN/CN do porównania. Własna domena Azure Front Door musi być wyraźnie uwzględniona na tej liście, aby była uznana za ważną do wzajemnej walidacji TLS.

11. Po pomyślnym utworzeniu domeny przejdź do wcześniej utworzonego punktu końcowego w Menedżerze Drzwi Frontowych i dodaj trasę, która powiąże tę domenę z właściwą grupą źródłową.

12. Sprawdź, czy mTLS działa zgodnie z oczekiwaniami. Możesz sprawdzić ten warunek, wiążąc lokalny IP hosta z jednym z IP Azure Front Door.

13. Po pomyślnej walidacji zaktualizuj niestandardowy rekord CNMAE domeny w DNS, aby wskazywał na punkt końcowy Azure Front Door.

    Ogranicz dostęp backend/origin tak, aby przyjmował ruch tylko z Azure Front Door, co uniemożliwia ominięcie mTLS poprzez bezpośredni dostęp do źródła. Aby uzyskać więcej informacji, zobacz Zabezpiecz ruch do źródeł usługi Azure Front Door.

Aby edytować istniejącą konfigurację mTLS na domenie, na stronie Domeny wybierz nazwę domeny. Strona Edytuj domenę pojawia się z aktualną konfiguracją mTLS.

Unexpected 403 (Forbidden) from Azure Front Door for mTLS request

Aby uzyskać więcej informacji diagnostycznych, przekaż nagłówek X-Azure-DebugInfo:1 z żądaniem do Azure Front Door. Dla odpowiedzi Front Door zwraca nagłówek debugowania, X-Azure-Externalerror, z wartością sugerującą, jaki może być błąd. Poniższa tabela przedstawia wartości błędu i ich znaczenia.

Treści powiązane

• TLS encryption with Azure Front Door
• Zasady protokołu TLS usługi Azure Front Door