Panoramica dell'autenticazione reciproca con il gateway applicazione

  • Articolo

L'autenticazione reciproca, o autenticazione client, consente al gateway applicazione di autenticare il client che invia le richieste. In genere, solo il client esegue l'autenticazione del gateway applicazione; l'autenticazione reciproca consente sia al client che al gateway applicazione di autenticarsi a vicenda.

Nota

È consigliabile usare TLS 1.2 con l'autenticazione reciproca, poiché TLS 1.2 sarà obbligatorio in futuro.

Autenticazione reciproca

Gateway applicazione supporta l'autenticazione reciproca basata su certificati, in cui è possibile caricare uno o più certificati client della CA attendibili nel gateway applicazione. Il gateway userà quindi tali certificati per autenticare il client che invia una richiesta al gateway. Con l'aumento dei casi d'uso di IoT e degli obblighi in materia di sicurezza in tutti i settori, l'autenticazione reciproca offre un modo per gestire e controllare quali client possono comunicare con il gateway applicazione.

Per configurare l'autenticazione reciproca, è necessario caricare un certificato client della CA attendibile come parte della sezione di autenticazione del client di un profilo SSL. Il profilo SSL dovrà quindi essere associato a un listener per completare la configurazione dell'autenticazione reciproca. Nel certificato client caricato deve sempre essere presente un certificato della CA radice. È inoltre possibile caricare una catena di certificati, che deve includere tuttavia un certificato della CA radice oltre a tutti i certificati della CA intermedia di cui si desidera disporre. La dimensione massima di ogni file caricato deve essere pari o inferiore a 25 kB.

Ad esempio, se il certificato client contiene un certificato della CA radice, più certificati della CA intermedi e un certificato foglia, assicurarsi che il certificato della CA radice e tutti i certificati della CA intermedi vengano caricati nel gateway applicazione in un unico file. Per altre informazioni su come estrarre certificati client della CA attendibili, vedere Come estrarre certificati client della CA attendibili.

Se si carica una catena di certificati contenente certificati della CA radice e della CA intermedia, la catena di certificati deve essere caricata come file PEM o CER nel gateway.

Importante

Quando si usa l'autenticazione reciproca, assicurarsi di caricare l'intera catena di certificati client della CA attendibili nel gateway applicazione.

Ogni profilo SSL può supportare fino a 100 catene di certificati client della CA attendibili. Un singolo gateway applicazione può supportare un totale di 200 catene di certificati client della CA attendibili.

Nota

  • L'autenticazione reciproca è disponibile solo negli SKU Standard_v2 e WAF_v2.
  • La configurazione dell'autenticazione reciproca per i listener di protocollo TLS (anteprima) è attualmente disponibile tramite l'API REST, PowerShell e l'interfaccia della riga di comando. Il supporto del portale di Azure sarà presto disponibile.

Certificati supportati per l'autenticazione reciproca

Il gateway applicazione supporta i certificati emessi da autorità costituite di certificazione pubbliche e private.

  • Certificati della CA emessi da autorità di certificazione note: i certificati intermedi e radice in genere si trovano negli archivi certificati considerati attendibili e consentono connessioni attendibili con la minima o nessuna configurazione aggiuntiva sul dispositivo.
  • Certificati della CA emessi da autorità costituite di certificazione stabilite dall'organizzazione: questi certificati in genere vengono in genere emessi privatamente tramite l'organizzazione e non sono considerati attendibili da altre entità. I certificati intermedi e radice devono essere importati in archivi certificati considerati attendibili per consentire ai client di determinare l'attendibilità della catena.

Nota

Quando si emettono certificati client da autorità di certificazione ben costituite, prendere in considerazione la possibilità di collaborare con l'autorità di certificazione per verificare se è possibile emettere un certificato intermedio per l'organizzazione, in modo da evitare l'autenticazione involontaria di certificati client tra organizzazioni.

Convalida di autenticazione client aggiuntiva

Verificare il DN del certificato client

È possibile verificare l'autorità di certificazione immediata del certificato client e consentire al gateway applicazione di considerare attendibile solo tale autorità. Questa opzione è disattivata per impostazione predefinita, ma è possibile abilitarla questa opzione tramite Portale, PowerShell o l'interfaccia della riga di comando di Azure.

Se si sceglie di abilitare il gateway applicazione per verificare l'autorità di certificazione immediata del certificato client, è necessario determinare quale DN dell'autorità di certificazione del client verrà estratto dai certificati caricati.

  • Scenario 1: la catena di certificati include il certificato radice, il certificato intermedio e il certificato foglia.
    • Il nome del soggetto del certificato intermedio corrisponde a quello che il gateway applicazione estrarrà come DN dell'autorità di certificazione client e rispetto al quale verrà verificato.
  • Scenario 2: la catena di certificati include il certificato radice, il certificato intermediate1, il certificato intermediate2 e il certificato foglia.
    • Il nome del soggetto del certificato intermediate2 corrisponde a quello che verrà estratto come DN dell'autorità di certificazione client e rispetto al quale verrà verificato.
  • Scenario 3: la catena di certificati include il certificato radice e il certificato foglia.
    • Il nome del soggetto del certificato radice verrà estratto e usato come DN dell'autorità di certificazione client.
  • Scenario 4: più catene di certificati della stessa lunghezza nello stesso file. La catena 1 include il certificato radice, il certificato intermediate1 e il certificato foglia. La catena 2 include il certificato radice, il certificato intermediate2 e il certificato foglia.
    • Il nome del soggetto del certificato intermediate1 verrà estratto come DN dell'autorità di certificazione client.
  • Scenario 5: più catene di certificati con lunghezze diverse nello stesso file. La catena 1 include il certificato radice, il certificato intermediate1 e il certificato foglia. La catena 2 include il certificato radice, il certificato intermediate2, il certificato intermediate3 e il certificato foglia.
    • Il nome del soggetto del certificato intermediate3 verrà estratto come DN dell'autorità di certificazione client.

Importante

È consigliabile caricare solo una catena di certificati per ogni file. Ciò è particolarmente importante se si abilita la verifica del DN del certificato client. Caricando più catene di certificati in un unico file, si finirà nello scenario quattro o cinque e si potrebbero verificare problemi in un secondo momento, considerato che il certificato client presentato non corrisponde al gateway applicazione del DN dell'autorità di certificazione del certificato client estratto dalle catene.

Per altre informazioni su come estrarre catene di certificati client della CA attendibili, vedere Come estrarre catene di certificati client della CA client attendibili.

Variabili del server

Con l'autenticazione reciproca TLS reciproca, sono disponibili variabili del server aggiuntive che è possibile usare per passare informazioni sul certificato client ai server back-end dietro il gateway applicazione. Per altre informazioni sulle variabili del server disponibili e su come usarle, vedere Variabili del server.

Revoca del certificato

Quando un client avvia una connessione a un gateway applicazione configurato con l'autenticazione reciproca TLS, non solo è possibile convalidare la catena di certificati e il nome distinto dell'autorità emittente, ma anche verificare lo stato di revoca del certificato client con OCSP (Online Certificate Status Protocol). Durante la convalida, il certificato presentato dal client verrà cercato tramite il risponditore OCSP definito nella relativa estensione AIA (Authority Information Access). Nel caso in cui il certificato client sia stato revocato, il gateway applicazione risponderà al client con un codice di stato HTTP 400 e un motivo. Se il certificato è valido, la richiesta continuerà a essere elaborata dal gateway applicazione e inoltrata al pool back-end definito.

La revoca dei certificati client può essere abilitata tramite API REST, ARM, Bicep, interfaccia della riga di comando o PowerShell.

Per configurare il controllo della revoca del client in un gateway applicazione esistente tramite Azure PowerShell, è possibile fare riferimento ai comandi seguenti:

# 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

Un elenco di tutti i riferimenti di Azure PowerShell per la configurazione dell'autenticazione client nel gateway applicazione è disponibile qui:

Per verificare che lo stato di revoca OCSP sia stato valutato per la richiesta client, i log di accesso conterranno una proprietà denominata "sslClientVerify", con lo stato della risposta OCSP.

È fondamentale che il risponditore OCSP sia a disponibilità elevata e che sia possibile la connettività di rete tra il gateway applicazione e il risponditore. Nel caso in cui il gateway applicazione non sia in grado di risolvere il nome di dominio completo (FQDN) del risponditore definito o la connettività di rete è bloccata verso/dal risponditore, lo stato di revoca del certificato avrà esito negativo e il gateway applicazione restituirà una risposta HTTP 400 al client richiedente.

Nota: i controlli OCSP vengono convalidati tramite la cache locale in base all'ora di nextUpdate definita da una risposta OCSP precedente. Se la cache OCSP non è stata popolata da una richiesta precedente, la prima risposta potrebbe avere esito negativo. Al nuovo tentativo del client, la risposta dovrebbe essere trovata nella cache e la richiesta verrà elaborata come previsto.

Note

  • Il controllo della revoca tramite CRL non è supportato
  • Il controllo delle revoche client è stato introdotto nella versione 2022-05-01 dell'API

Passaggi successivi

Dopo aver appreso l'autenticazione reciproca, passare a Configurare il gateway applicazione con l'autenticazione reciproca in PowerShell per creare un gateway applicazione usando l'autenticazione reciproca.