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 protokol TLS 1.2 bude v budoucnu zmocněn.

Vzájemné ověřování

Služba 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žije k ověření klienta, který odesílá požadavek na bránu. 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.

Aby bylo možné nakonfigurovat vzájemné ověřování, musí být certifikát důvěryhodné certifikační autority klienta nahrán jako součást části profilu SSL pro ověřování klientů. Profil SSL pak bude potřeba přidružit 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řenovými certifikačními autoritami a certifikáty zprostředkující certifikační autority, musí se řetězec certifikátů nahrát jako soubor 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ů důvěryhodné certifikační autority klienta.

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. Podpora webu Azure Portal bude brzy k dispozici.

Certifikáty podporované pro vzájemné ověřování

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 minimální až žádnou další konfigurací na zařízení.
  • Certifikáty certifikační autority vydané ze zavedených certifikačních autorit organizace: Tyto certifikáty se obvykle vydávají 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 vytvořili vztah důvěryhodnosti ř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ěření ověřování klientů

Ověření dnu klientského certifikátu

Máte možnost ověřit bezprostředního vystavitele klientského certifikátu a povolit službě Application Gateway důvěřovat ho. 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 se rozhodnete službě Application Gateway povolit ověření okamžitého vystavitele klientského certifikátu, tady je postup, jak zjistit, jaký název vystavitele klientského certifikátu se extrahuje 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 to, co služba Application Gateway extrahuje jako dn vystavitele klientského certifikátu a ověří se proti.
  • 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 certifikátu zprostředkujícího2 bude extrahovaný jako název vystavitele klientského certifikátu a bude ověřen 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 a použije 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 zprostředkující 1 se extrahuje jako název 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át – certifikát zprostředkující3 – listový certifikát.
    • Název subjektu zprostředkující 3 se extrahuje jako název 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. Nahráním více řetězů certifikátů do jednoho souboru skončíte ve scénáři 4 nebo pět a může dojít k problémům později, když se zobrazený klientský certifikát neshoduje s vystavitelem klientského certifikátu, který služba Application Gateway extrahovaná z řetězů 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 se 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, 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 nemůže přeložit plně kvalifikovaný název domény definovaného respondéru nebo síťového připojení je zablokovaný do nebo od respondenta, stav odvolání certifikátu selže a Služba Application Gateway vrátí odpověď HTTP 400 na žádajícího klienta.

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 mezipaměť OCSP nebyla naplněna 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í.

Notes

  • Kontrola odvolání prostřednictvím seznamu CRL se nepodporuje.
  • 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í.