Sdílet prostřednictvím

Přehled vzájemného ověřování se službou Application Gateway

Vzájemné ověřování nebo ověřování klientů umožňuje službě Application Gateway ověřovat požadavky odesílané klientem. Obvykle pouze klient ověřuje službu Application Gateway; vzájemné ověřování umožňuje klientovi i službě Application Gateway navzájem ověřovat.

Poznámka:

Doporučujeme používat protokol TLS 1.2 se vzájemným ověřováním, protože v budoucnu bude protokol TLS 1.2 vyžadován.

Vzájemné ověřování

Application Gateway podporuje vzájemné ověřování založené na certifikátech, kde můžete nahrát důvěryhodné certifikáty certifikační autority klienta do služby Application Gateway a brána tento certifikát používá k ověření klienta, který odesílá požadavek do brány. S nárůstem případů použití IoT a zvýšenými požadavky na zabezpečení napříč odvětvími nabízí vzájemné ověřování způsob, jak spravovat a řídit, kteří klienti můžou komunikovat s vaší službou Application Gateway.

Služba Application Gateway poskytuje následující dvě možnosti ověřování klientských certifikátů:

Režim vzájemného předávání TLS

V režimu vzájemného předávání protokolu TLS služba Application Gateway vyžádá během metody handshake protokolu TLS klientský certifikát, ale neukončí připojení, pokud certifikát chybí nebo je neplatný. Připojení k back-endu pokračuje bez ohledu na přítomnost nebo platnost certifikátu. Pokud je certifikát poskytnutý, služba Application Gateway ji může v případě potřeby předat do back-endu. Back-endová služba zodpovídá za ověření klientského certifikátu. Pokud chcete nakonfigurovat předávání certifikátů, projděte si proměnné serveru. Pokud je certifikát certifikační autority v režimu passthrough, nemusíte nahrávat žádný certifikát certifikační autority. Chcete-li nastavit passthrough, postupujte podle kroků v Konfigurování služby Application Gateway se vzájemným ověřováním pomocí šablony ARM.

Poznámka:

V současné době se tato funkce podporuje pouze prostřednictvím nasazení Azure Resource Manageru pomocí rozhraní API verze 2025-03-01.

Režim striktního vzájemného protokolu TLS

Ve vzájemném režimu striktního protokolu TLS služba Application Gateway vynucuje ověřování klientských certifikátů během metody handshake protokolu TLS vyžadováním platného klientského certifikátu. Chcete-li to povolit, musí být certifikát důvěryhodné klientské certifikační autority obsahující kořenovou certifikační autoritu a volitelně zprostředkující certifikační autority nahraný jako součást profilu SSL. Tento profil SSL se pak přidružuje k posluchači, aby vynucoval vzájemné ověřování.

Podrobnosti o konfiguraci vzájemného režimu striktního protokolu TLS

Aby bylo možné nakonfigurovat režim striktního vzájemného ověřování, musí být certifikát důvěryhodné certifikační autority klienta nahrán jako součást části ověřování klienta profilu SSL. Profil SSL pak musí být přidružený k naslouchacímu procesu, aby bylo možné dokončit konfiguraci vzájemného ověřování. V klientském certifikátu, který nahrajete, musí vždy existovat kořenový certifikát certifikační autority. Můžete také nahrát řetěz certifikátů, ale řetězec musí obsahovat kořenový certifikát certifikační autority kromě tolika zprostředkujících certifikátů certifikační autority, kolik chcete. Maximální velikost každého nahraného souboru musí být 25 kB nebo menší.

Pokud například klientský certifikát obsahuje kořenový certifikát certifikační autority, několik zprostředkujících certifikátů certifikační autority a listový certifikát, ujistěte se, že se kořenový certifikát certifikační autority a všechny certifikáty zprostředkující certifikační autority nahrají do služby Application Gateway v jednom souboru. Další informace o extrahování certifikátu důvěryhodné klientské certifikační autority najdete v tématu extrakce důvěryhodných certifikátů certifikační autority klienta.

Pokud nahráváte řetěz certifikátů s kořenovou certifikační autoritou a zprostředkující certifikační autoritou, musí se řetězec certifikátů nahrát ve formátu PEM nebo CER do brány.

Důležité

Při použití vzájemného ověřování nezapomeňte do služby Application Gateway nahrát celý řetěz certifikátů důvěryhodné certifikační autority klienta.

Každý profil SSL může podporovat až 100 řetězů certifikátů důvěryhodné certifikační autority klienta. Jedna služba Application Gateway může podporovat celkem 200 řetězů certifikátů klienta důvěryhodné certifikační autority.

Poznámka:

  • Vzájemné ověřování je k dispozici pouze u skladových položek Standard_v2 a WAF_v2.
  • Konfigurace vzájemného ověřování pro naslouchací procesy protokolu TLS (Preview) je aktuálně dostupná prostřednictvím rozhraní REST API, PowerShellu a rozhraní příkazového řádku.

Certifikáty podporované pro vzájemné ověřování v režimu striktního režimu TLS

Application Gateway podporuje certifikáty vydané veřejnými i soukromě vytvořenými certifikačními autoritou.

  • Certifikáty certifikační autority vydané z dobře známých certifikačních autorit: Zprostředkující a kořenové certifikáty se běžně nacházejí v úložištích důvěryhodných certifikátů a umožňují důvěryhodná připojení s malou až žádnou další konfigurací v zařízení.
  • Certifikáty CA vydané certifikačními autoritami vaší organizace: Tyto certifikáty jsou obvykle vydávány soukromě prostřednictvím vaší organizace a nejsou důvěryhodné jinými entitami. Zprostředkující a kořenové certifikáty musí být importovány do důvěryhodných úložišť certifikátů, aby klienti mohli vytvořit důvěryhodnost řetězu.

Poznámka:

Při vydávání klientských certifikátů od dobře zavedených certifikačních autorit zvažte spolupráci s certifikační autoritou, abyste zjistili, jestli je možné vydat zprostředkující certifikát pro vaši organizaci, aby se zabránilo neúmyslné ověřování klientských certifikátů mezi organizacemi.

Další ověřování klientů pro vzájemný režim striktního protokolu TLS

Ověřte DN klientského certifikátu

Máte možnost ověřit bezprostředního vystavitele klientského certifikátu a povolit, aby služba Application Gateway důvěřovala tomuto vystaviteli. Tato možnost je ve výchozím nastavení vypnutá, ale tuto možnost můžete povolit prostřednictvím portálu, PowerShellu nebo Azure CLI.

Pokud povolíte službě Application Gateway ověřovat okamžitého vystavitele klientského certifikátu, zde je postup, jak zjistit, který název vystavitele klientského certifikátu bude extrahován z nahraných certifikátů.

  • Scénář 1: Řetěz certifikátů zahrnuje: kořenový certifikát – zprostředkující certifikát – listový certifikát
    • Název subjektu zprostředkujícího certifikátu je tím, co služba Application Gateway extrahuje jako DN vystavitele klientského certifikátu, proti kterému se bude ověřovat.
  • Scénář 2: Řetěz certifikátů zahrnuje: kořenový certifikát – zprostředkující certifikát – certifikát zprostředkující2 – listový certifikát
    • Název subjektu zprostředkujícího certifikátu2 je to, co se extrahuje jako název vystavitele klientského certifikátu a ověří se proti.
  • Scénář 3: Řetěz certifikátů zahrnuje: kořenový certifikát – listový certifikát
    • Název subjektu kořenového certifikátu se extrahuje jako název vystavitele klientského certifikátu.
  • Scénář 4: Více řetězů certifikátů se stejnou délkou ve stejném souboru Řetěz 1 obsahuje: kořenový certifikát – zprostředkující certifikát – listový certifikát. Řetěz 2 obsahuje: kořenový certifikát – zprostředkující certifikát – listový certifikát.
    • Název subjektu certifikátu Intermediate1 se extrahuje jako DN vystavitele klientského certifikátu.
  • Scénář 5: Několik řetězů certifikátů s různými délkami ve stejném souboru Řetěz 1 obsahuje: kořenový certifikát – zprostředkující certifikát – listový certifikát. Řetěz 2 obsahuje kořenový certifikát – zprostředkující certifikát2 – zprostředkující certifikát3 – listový certifikát.
    • Název subjektu mezilehlého certifikátu 3 se extrahuje jako DN vystavitele klientského certifikátu.

Důležité

Doporučujeme nahrát pouze jeden řetěz certifikátů na jeden soubor. To je zvlášť důležité, pokud povolíte ověřování DN klientského certifikátu. Když do jednoho souboru nahrajete více řetězců certifikátů, skončíte ve scénáři 4 nebo 5 a může dojít k problémům později, když se předložený klientský certifikát neshoduje s DN vystavitelem klientského certifikátu, který aplikační brána z řetězců extrahovala.

Další informace o extrahování řetězů certifikátů důvěryhodné certifikační autority klienta najdete v tématu extrakce řetězů certifikátů důvěryhodné certifikační autority klienta.

Proměnné serveru

Při vzájemném ověřování TLS existují další proměnné serveru, které můžete použít k předávání informací o klientském certifikátu back-endovým serverům za službou Application Gateway. Další informace o tom, které proměnné serveru jsou k dispozici a jak je používat, najdete v tématu Proměnné serveru.

Odvolání certifikátu

Když klient zahájí připojení ke službě Application Gateway nakonfigurované se vzájemným ověřováním TLS, může se ověřit nejen řetězec certifikátů a rozlišující název vystavitele, ale stav odvolání klientského certifikátu je možné zkontrolovat pomocí protokolu OCSP (Online Certificate Status Protocol). Během ověřování se certifikát předaný klientem vyhledá prostřednictvím definovaného respondéru OCSP definovaného v jeho rozšíření AIA (Authority Information Access). V případě odvolání klientského certifikátu služba Application Gateway odpoví klientovi stavovým kódem HTTP 400 a důvodem. Pokud je certifikát platný, žádost bude dál zpracována službou Application Gateway a předána do definovaného back-endového fondu.

Odvolání klientského certifikátu je možné povolit prostřednictvím rozhraní REST API, šablony ARM, Bicep, rozhraní příkazového řádku nebo PowerShellu.

Pokud chcete nakonfigurovat kontrolu odvolání klienta ve stávající službě Application Gateway prostřednictvím Azure PowerShellu, můžete odkazovat na následující příkazy:

# Get Application Gateway configuration
$AppGw = Get-AzApplicationGateway -Name "ApplicationGateway01" -ResourceGroupName "ResourceGroup01"

# Create new SSL Profile
$profile  = Get-AzApplicationGatewaySslProfile -Name "SslProfile01" -ApplicationGateway $AppGw

# Verify Client Cert Issuer DN and enable Client Revocation Check
Set-AzApplicationGatewayClientAuthConfiguration -SslProfile $profile -VerifyClientCertIssuerDN -VerifyClientRevocation OCSP

# Update Application Gateway
Set-AzApplicationGateway -ApplicationGateway $AppGw

Seznam všech odkazů Azure PowerShellu pro konfiguraci ověřování klientů ve službě Application Gateway najdete tady:

Pokud chcete ověřit, že se pro požadavek klienta vyhodnotil stav odvolání OCSP, protokoly přístupu budou obsahovat vlastnost s názvem sslClientVerify se stavem odpovědi OCSP.

Je důležité, aby byl respondér OCSP vysoce dostupný a bylo možné připojení k síti mezi službou Application Gateway a respondérem. V případě, že služba Application Gateway nedokáže přeložit plně kvalifikovaný název domény (FQDN) definovaného respondéra nebo je zablokované síťové připojení k respondéru či od něj, kontrola stavu odvolání certifikátu selže a služba Application Gateway vrátí odpověď HTTP 400 klientovi, který odeslal žádost.

Poznámka:

Kontroly OCSP se ověřují prostřednictvím místní mezipaměti na základě času příštího aktualizace definovaného předchozí odpovědí OCSP. Pokud se mezipaměť OCSP nenaplní z předchozího požadavku, může první odpověď selhat. Po opakování klienta by se odpověď měla najít v mezipaměti a požadavek se zpracuje podle očekávání.

Poznámky

  • Kontrola odvolání prostřednictvím seznamu odvolaných certifikátů (CRL) není podporována.
  • Kontrola odvolání klienta byla zavedena v rozhraní API verze 2022-05-01

Další kroky

Po seznámení se vzájemným ověřováním přejděte do části Konfigurace služby Application Gateway se vzájemným ověřováním v PowerShellu a vytvořte službu Application Gateway pomocí vzájemného ověřování.

  • Last updated on