Panoramica dell'autenticazione reciproca con il gateway applicazione

L'autenticazione reciproca, o autenticazione client, consente all'Application Gateway di autenticare il client che invia richieste. In genere, solo il client autentica il Gateway applicazione. L'autenticazione reciproca consente sia al client che al gateway applicazione di autenticarsi tra loro.

Note

È consigliabile usare TLS 1.2 con l'autenticazione reciproca perché TLS 1.2 verrà imposto in futuro.

Autenticazione reciproca

Il gateway applicativo supporta l'autenticazione reciproca basata su certificati. È possibile caricare certificati CA client attendibili su Application Gateway, che utilizza tali certificati per autenticare i client che inviano richieste. Con l'aumento dei casi d'uso IoT e l'aumento dei requisiti di sicurezza in tutti i settori, l'autenticazione reciproca consente di gestire e controllare quali client possono comunicare con il gateway applicazione.

Application Gateway offre le seguenti due opzioni per convalidare i certificati client:

Modalità pass-through TLS reciproca

In modalità pass-through TLS reciproca (mTLS), il gateway applicazione richiede un certificato client durante l'handshake TLS, ma non termina la connessione se il certificato è mancante o non valido. La connessione al back-end procede indipendentemente dalla presenza o dalla validità del certificato. Se viene fornito un certificato, l'Application Gateway può trasmetterlo al backend, se richiesto dall'applicazione. Il servizio back-end è responsabile della convalida del certificato client.

Vantaggi della modalità pass-through mTLS

La modalità pass-through mTLS offre i vantaggi seguenti:

  • Configurazione del gateway semplificata: non è necessario caricare certificati CA a livello di gateway.
  • Autenticazione flessibile: supporta scenari di traffico misto in cui alcuni client usano certificati e altri usano l'autenticazione basata su token.
  • Applicazione dei criteri back-end: consente all'applicazione back-end di implementare criteri e logica di convalida dei certificati personalizzati.
  • Riduzione del sovraccarico del gateway: esegue l'offload della convalida del certificato nel back-end, riducendo l'elaborazione nel gateway.
  • Supporto graduale per la migrazione: consente l'implementazione graduale di mTLS senza interrompere i modelli di traffico esistenti.

Per inoltrare i certificati client al backend, configurare le variabili del server. Per altre informazioni, vedere Variabili del server.

Configurare la modalità pass-through mTLS

È possibile configurare la modalità di pass-through mTLS utilizzando il portale di Azure o i modelli ARM.

Per configurare la modalità pass-through mTLS nel portale di Azure:

  1. Accedere alla risorsa dell'Application Gateway.

  2. In Impostazioni selezionare Profili SSL.

  3. Selezionare + Aggiungi per creare un nuovo profilo SSL.

  4. Immettere un nome per il profilo SSL.

  5. Nella scheda Autenticazione client selezionare Passthrough.

    In modalità pass-through il certificato client è facoltativo. Il server back-end è responsabile dell'autenticazione client.

    Screenshot che mostra la finestra di dialogo Crea profilo SSL nel portale di Azure con pass-through selezionato per il metodo di autenticazione client.

  6. Configurare le impostazioni dei criteri SSL in base alle esigenze.

  7. Selezionare Aggiungi per creare il profilo SSL.

  8. Associare il profilo SSL al listener HTTPS.

Note

Il supporto di PowerShell e dell'interfaccia della riga di comando per la configurazione pass-through non è attualmente disponibile.

Modalità TLS reciproca rigorosa

In modalità TLS reciproca rigorosa il gateway applicazione impone l'autenticazione con certificato client durante l'handshake TLS richiedendo un certificato client valido. Per abilitare la modalità strict, caricare un certificato CA attendibile del client che contenga una CA radice e opzionalmente CA intermedie come parte del profilo SSL. Associare questo profilo SSL a un listener per applicare l'autenticazione reciproca.

Configurare la modalità strict TLS reciproca

Per configurare la modalità strict di autenticazione reciproca, caricare un certificato CA del client attendibile come parte dell'autenticazione client di un profilo SSL. Associare quindi il profilo SSL a un listener per completare la configurazione. Il certificato client caricato deve includere sempre un certificato CA radice. È possibile caricare una catena di certificati, ma la catena deve includere un certificato CA radice oltre a qualsiasi certificato CA intermedio. La dimensione massima di ogni file caricato deve essere pari o inferiore a 25 kB.

Ad esempio, se il certificato client contiene un certificato CA radice, più certificati CA intermediari e un certificato foglia, carica il certificato CA radice e tutti i certificati CA intermediari nel Gateway delle applicazioni in un unico file. Per altre informazioni su come estrarre un certificato ca client attendibile, vedere Estrarre certificati ca client attendibili.

Se stai caricando una catena di certificati con certificati CA radice e CA intermedia, carica la catena di certificati come file PEM o CER nel gateway.

Importante

Caricare l'intera catena di certificati CA client attendibili nell'Application Gateway quando si usa l'autenticazione mutua.

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.

Note

  • L'autenticazione reciproca è disponibile solo per le SKU di Standard_v2 e WAF_v2.
  • La configurazione dell'autenticazione reciproca per i listener di protocollo TLS è attualmente disponibile tramite l'API REST, PowerShell e l'interfaccia della riga di comando.

Certificati supportati per l'autenticazione reciproca in modalità TLS stretta

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

  • Certificati CA rilasciati da autorità di certificazione note: i certificati intermedi e radice si trovano comunemente negli archivi certificati attendibili e consentono connessioni attendibili senza alcuna configurazione aggiuntiva nel dispositivo.
  • Certificati CA emessi da autorità di certificazione stabilite dall'organizzazione: questi certificati vengono in genere emessi privatamente tramite l'organizzazione e non sono considerati attendibili da altre entità. Importare certificati intermedi e radice in archivi certificati attendibili per i client per stabilire l'attendibilità della catena.

Note

Quando si rilasciano certificati client da autorità di certificazione ben consolidate, è consigliabile collaborare con l'autorità di certificazione per verificare se è possibile emettere un certificato intermedio per l'organizzazione. Questo approccio impedisce l'autenticazione accidentale dei certificati client tra organizzazioni.

Convalida dell'autenticazione del client per la modalità rigorosa di TLS reciproco

Verificare il DN del certificato client

È possibile verificare l'autorità emittente immediata del certificato client e consentire solo ad Application Gateway di considerare attendibile quell'autorità. Questa opzione è disattivata per impostazione predefinita, ma è possibile abilitarla tramite il portale, PowerShell o interfaccia della riga di comando di Azure.

Se si abilita Application Gateway per verificare l'emittente immediato del certificato client, gli scenari seguenti descrivono come il DN dell'emittente del certificato client viene estratto dai certificati caricati:

  • Scenario 1: la catena di certificati include il certificato radice, il certificato intermedio e il certificato foglia.
    • Il nome soggetto del certificato intermedio viene estratto come DN dell'emittente del certificato client.
  • Scenario 2: la catena di certificati include il certificato radice, il certificato intermedio1, il certificato intermedio2 e il certificato foglia.
    • Il nome soggetto del certificato intermedio2 viene estratto come DN dell'emittente del certificato client.
  • Scenario 3: La catena di certificati include il certificato radice e il certificato foglia.
    • Il nome soggetto del certificato root viene estratto come DN dell'emittente del certificato client.
  • Scenario 4: più catene di certificati con la stessa lunghezza nello stesso file. La catena 1 include il certificato radice, il certificato intermedio1 e il certificato foglia. La catena 2 include il certificato radice, il certificato intermedio2 e il certificato foglia.
    • Il nome soggetto del certificato intermedio1 viene estratto come DN dell'emittente del certificato client.
  • Scenario 5: più catene di certificati con lunghezze diverse nello stesso file. La catena 1 include il certificato radice, il certificato intermedio1 e il certificato foglia. La catena 2 include il certificato radice, il certificato intermedio2, il certificato intermedio3 e il certificato foglia.
    • Il nome soggetto del certificato intermedio3 viene estratto come DN dell'emittente del certificato client.

Importante

È consigliabile caricare una sola catena di certificati per ogni file. Questa raccomandazione è particolarmente importante se si abilita l'opzione verifica DN del certificato client. Il caricamento di più catene di certificati in un file comporta uno scenario 4 o 5, che potrebbe causare problemi in un secondo momento quando il certificato client presentato non corrisponde al DN del certificato client che il gateway applicazione ha estratto dalle catene.

Per ulteriori informazioni su come estrarre catene di certificati CA client attendibili, vedere Estrarre catene di certificati CA client attendibili.

Variabili del server

Con l'autenticazione TLS reciproca, è possibile usare variabili server aggiuntive per passare informazioni dal certificato del client ai server di back-end dietro l'Application Gateway. 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 TLS reciproca, è possibile convalidare la catena di certificati e il nome distinto dell'autorità emittente. Inoltre, lo stato di revoca del certificato client può essere controllato con OCSP (Online Certificate Status Protocol). Durante la convalida, il certificato presentato dal client viene cercato tramite il risponditore OCSP definito nell'estensione AIA (Authority Information Access). Se il certificato client è stato revocato, Application Gateway risponde al client con un codice di stato HTTP 400 e un motivo specifico. Se il certificato è valido, la richiesta continua a essere elaborata dall'Application Gateway e inoltrata al back-end pool definito.

È possibile abilitare la revoca dei certificati client tramite l'API REST, il template di Resource Manager, Bicep, CLI o PowerShell.

Per configurare il controllo di revoca client in un Application Gateway esistente usando Azure PowerShell, usare i 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

Per un elenco di tutti i riferimenti di Azure PowerShell per la configurazione dell'autenticazione client su Application Gateway, consultare i seguenti articoli:

Per verificare che lo stato di revoca OCSP sia stato valutato per la richiesta client, i log di accesso contengono una proprietà denominata sslClientVerify che mostra 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. Se il gateway applicazione non riesce a risolvere il nome di dominio completo (FQDN) del risponditore definito oppure se la connettività di rete è bloccata da o verso il risponditore, lo stato di revoca del certificato ha esito negativo e il gateway applicazione restituisce una risposta HTTP 400 al client richiedente.

Note

I controlli OCSP vengono convalidati tramite la cache locale in base all'ora nextUpdate definita da una risposta OCSP precedente. Se la cache OCSP non è stata popolata da una richiesta precedente, la prima risposta potrebbe non riuscire. Al nuovo tentativo del client, la risposta deve essere trovata nella cache e la richiesta viene elaborata come previsto.

Note

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

Contenuti correlati

Dopo aver imparato l'autenticazione reciproca, consultare Configurare Application Gateway con l'autenticazione reciproca in PowerShell per creare un Application Gateway che utilizza l'autenticazione reciproca.

  • Last updated on