Autenticazione TLS reciproca in Frontdoor di Azure (anteprima)

Si applica a: ✔️ Frontdoor Premium

L'autenticazione TLS reciproca (mTLS), o autenticazione del client, garantisce che il traffico sia sicuro e affidabile in entrambe le direzioni tra client e server. Utilizzando TLS mutuo, puoi configurare Frontdoor di Azure per verificare l'identità del client presentando un certificato client valido. L'autenticazione TLS reciproca è utile in situazioni in cui è necessario identificare e gestire in modo sicuro i client per risorse, come applicazioni business-to-business (B2B), applicazioni Internet of Things (IoT), app bancarie, VPN, reti aziendali e altro ancora.

Puoi usare TLS mutuo insieme ad altre autorizzazioni e metodi di autenticazione supportati da Frontdoor di Azure.

Modalità di validazione TLS reciproche

• Disabilita mTLS: certificati client e validazioni non sono necessarie. Questa è l'opzione predefinita.

• Abilita mTLS:

  • Certificato cliente richiesto e convalidato: Il certificato del cliente è obbligatorio. Frontdoor di Azure effettua la validazione completa, inclusa la verifica della presenza dei certificati client, della validità, e il controllo contro revoche, catena Root CA e lista SAN/CN. Frontdoor di Azure inoltra la richiesta con l'intestazione X-Azure-ClientCertificate all'origine. Questa opzione è lo scenario predefinito quando mTLS è abilitato.

  • Certificato cliente richiesto ma non validato: Il certificato del cliente è obbligatorio. Frontdoor di Azure non esegue altre validazioni. Frontdoor di Azure lascia perdere richieste che non contengono certificati. L'origine deve eseguire tutte le validazioni. Di default, Frontdoor di Azure passa attraverso il certificato al backend tramite header in questa modalità.

    • Validazione del certificato client se presentata: Il certificato del cliente non è obbligatorio. Frontdoor di Azure effettua la validazione completa quando è presente un certificato client e inoltra il certificato client all'origine tramite X-Azure-ClientCertificate header. Se il client non presenta un certificato client, Frontdoor di Azure passa la richiesta all'origine per ulteriori validazioni.

  • passthrough mTLS all'origine: Il certificato del cliente non è richiesto. Frontdoor di Azure non effettua alcuna validazione. L'origine deve eseguire tutte le validazioni.

Validazione dell'autenticazione del client

Quando configuri Frontdoor di Azure per validare il certificato client, controlla le seguenti informazioni:

• La data attuale è inferiore alla data del certificato Not After .

• La data attuale è maggiore o uguale alla data del certificato Not Before .

• L'Uso della Chiave Estesa del Certificato non è presente, o se presente, contiene l'OID di autenticazione del client.

• Validità e integrità che il certificato non sia stato modificato nel formato del certificato.

• Controlla la catena dei certificati: se il certificato client è emesso da un emittente affidabile per il dominio specificato, il CN (nome del certificato) delle certificazioni forma una catena ininterrotta.

Puoi anche configurare validazioni opzionali, come:

• Valida l'estensione SAN/CN del certificato client rispetto alla lista SAN consentita caricata su Frontdoor di Azure. Il nome host di dominio personalizzato Frontdoor di Azure deve essere esplicitamente incluso in questa lista per essere considerato valido per la validazione reciproca TLS. SAN viene convalidato per primo, se nessuna corrispondenza o SAN è vuoto, allora CN viene convalidato. Se uno dei SAN o CN corrisponde alla lista SAN consentita configurata su Frontdoor di Azure, la validazione ha successo.

• Controlla lo stato di revoca del certificato cliente utilizzando OCSP (Online Certificate Status Protocol).

Verifica della revoca del certificato

Frontdoor di Azure supporta la validazione dello stato di revoca del certificato. Per impostazione predefinita, è abilitata. Durante la validazione, Frontdoor di Azure cerca il certificato presentato dal client utilizzando il rispondente OCSP definito nella sua estensione Authority Information Access (AIA). Se il certificato client viene revocato, Frontdoor di Azure risponde al client con un codice di stato HTTP 403 e una ragione. Se il certificato è valido, Frontdoor di Azure continua a elaborare la richiesta.

MTLS supporta certificati pubblici e privati?

Frontdoor di Azure attualmente supporta certificati rilasciati sia da noti enti pubblici di certificazione sia da enti di certificazione privatamente istituite.

• Certificati CA rilasciati da noti enti di certificazione: I depositi di certificati affidabili includono comunemente certificati intermedi e di origine, che consentono connessioni affidabili con poca o nessuna configurazione aggiuntiva sul dispositivo.

• Certificati CA rilasciati dalle autorità di certificazione istituite dall'organizzazione: La tua organizzazione di solito rilascia questi certificati in modo privato, e altre entità non li fidano. Devi importare certificati intermedi e root in archivi certificati affidabili affinché i clienti possano stabilire la trust della catena.

Tuttavia, Frontdoor di Azure esegue controlli Extended Key Usage (EKU) sui certificati client per assicurarsi che siano destinati all'autenticazione del client. A causa dei cambiamenti nel settore, le autorità pubbliche di certificazione (CA) smettono presto di emettere certificati di autenticazione dei clienti con l'EKU richiesta.

Passare all'uso di CA private, che possono continuare a emettere certificati con l'EKU corretto, per scenari mTLS su Frontdoor di Azure. Questa transizione garantisce un'autenticazione client ininterrotta e sicura.

Considerazioni importanti di progettazione prima di implementare mTLS sui domini Front Door

• Abilita mTLS su nuovi domini e nuovi endpoint per evitare tempi di inattività inutili.

• Quando abiliti mTLS, non puoi abilitare la cache sulle route o gli override di route del motore di regole con la cache. Questa restrizione impedisce di restituire contenuti nella cache ai client non autenticati.

• MTLS funziona funzionalmente sul dominio. Tuttavia, per garantire la sicurezza in cui gli utenti malintenzionati non possano bypassare mTLS per raggiungere la tua origine, c'è un controllo mTLS sull'endpoint Frontdoor di Azure. Prima di abilitare mTLS su un dominio personalizzato, prima abilita mTLS sull'endpoint Frontdoor di Azure a cui il dominio personalizzato sarà associato. Tutti i domini con mTLS possono essere associati solo a percorsi sotto tali endpoint. Non puoi associare domini con autenticazione mista a stato misto allo stesso endpoint.

• Non puoi associare il dominio endpoint Frontdoor di Azure alle route quando mTLS è abilitato sull'endpoint Front Door. Viceversa, devi dissociare il dominio endpoint da tutte le rotte sotto l'endpoint prima di abilitare mTLS sull'endpoint.

• C'è un periodo di inattività se attivi mTLS su un dominio Frontdoor di Azure esistente, poiché devi apportare le seguenti modifiche. Abilita mTLS per nuovi domini personalizzati.

1. Crea un nuovo endpoint con mTLS abilitato o usa qualsiasi endpoint Frontdoor di Azure esistente con mTLS abilitato.

2. Dissocia il dominio personalizzato dalle route esistenti e dall'endpoint che non ha mTLS abilitato.

3. Poi riassocia il dominio personalizzato all'endpoint.

• Una volta abilitata l'autenticazione reciproca su un dominio, disabilitarla causa anche tempi di inattività.

  1. Dissocia il dominio personalizzato da tutte le rotte sotto l'endpoint mTLS abilitato esistente.

  2. Disabilita mTLS sul dominio.

  3. Riassocia il dominio a un altro endpoint senza mTLS abilitato.

• Aggiungi il controllo di accesso alla tua origine per verificare che la richiesta proviene da una porta principale valida. Per ulteriori informazioni, vedere Proteggere il traffico verso le origini di Frontdoor di Azure.

• CA Certificate Management: Carica una root e fino a tre intermedi (PEM, <25 KB) tramite Azure Key Vault. Nessuna autorrotazione, ma il supporto con doppia CA consente un rollover senza interruzioni.

• Frontdoor di Azure esegue controlli di Uso Esteso delle Chiavi (EKU) sui certificati client per assicurarsi che siano destinati all'autenticazione del cliente, una misura di sicurezza importante. Tuttavia, a causa dei cambiamenti del settore, le Autorità di Certificazione (CA) pubbliche smetteranno presto di emettere certificati di autenticazione dei clienti con l'EKU richiesta. Transizione all'uso di CA private, che possono continuare a emettere certificati con l'EKU corretto per scenari mTLS su Frontdoor di Azure, garantendo un'autenticazione client ininterrotta e sicura.

• I clienti si stanno allontanando da OCSP. Durante il controllo di revoca del certificato Front Door, Frontdoor di Azure attualmente controlla solo OCSP.

• Se il client invia richieste con i seguenti intestamenti, Frontdoor di Azure elimina le intestazioni e inoltra la richiesta all'origine.

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

Quali metriche e campi logaritarimi esposta la soluzione?

La soluzione espone le seguenti metriche:

• Numero di richieste mTLS.

• Richieste mTLS fallite.

• Richieste di errore mTLS, suddivise per tipi di errore, nomi host SNI e protocolli TLS.

Limite della quota di configurazione

• La catena di certificati CA client può includere una root e fino a tre intermedi.

• I certificati CA devono essere codificati in PEM e avere meno di 25 KB.

• La rotazione automatica non è supportata.

• Puoi allegare due certificati CA per un rollover senza soluzione di continuità durante la scadenza o la revoca. Frontdoor di Azure utilizza il certificato CA valido per la validazione durante l'esecuzione.

Passaggi di configurazione

1. Per saperne di più sulle limitazioni, consulta la sezione delle considerazioni importanti sul design . Si consiglia di abilitare mTLS su nuovi endpoint e domini.

2. Accedi al portale Azure e cerca il tuo profilo Front Door.

3. Sotto Sicurezza, seleziona i certificati Mutual TLS CA. Vedi una lista delle tue catene di certificati mTLS esistenti se ne hai caricate in passato.

4. Seleziona + Aggiungi. Vedi Key Vault e oggetti segreti a cui hai accesso. Seleziona quelli che vuoi usare come parte della chiave pubblica di mTLS handshake.

5. Sotto Impostazioni, seleziona Gestore porta d'ingresso. Vedi l'elenco dei tuoi endpoint.

6. Seleziona + Aggiungi un endpoint e seleziona Imporre TLS mutuo.

   Note

   Non puoi aggiungere il dominio predefinito di Frontdoor di Azure (ad esempio, .z01.azurefd.net) come dominio alle route su questo endpoint quando Enforce il TLS mutuo è abilitato. Passa al passo successivo per creare domini personalizzati con mTLS abilitato prima di creare rotte.

7. In Impostazioni selezionare Domini. Vedi l'elenco dei tuoi domini personalizzati esistenti.

8. Seleziona + Aggiungi.

9. In Aggiungi una pagina di dominio , configura il tuo dominio e poi scorri fino a Impostazioni avanzate e seleziona Abilita TLS mutuo per configurare TLS reciproco per il dominio.

10. Seleziona Aggiungi per creare il dominio.

    1. Modalità TLS reciproca: scegli tra le quattro opzioni

       • Certificato cliente richiesto e validato
       • Certificato cliente richiesto ma non validato
       • Validazione del certificato client se presentata
       • passthrough mTLS all'origine

    2. Seleziona il certificato CA quando viene popolato per Frontdoor di Azure per validare il certificato client.

    3. Abilita il Controllo di Revoca del Certificato.

    4. Aggiungi la lista SAN/CN per essere confrontata. Il nome host di dominio personalizzato Frontdoor di Azure deve essere esplicitamente incluso in questa lista per essere considerato valido per la validazione reciproca TLS.

11. Dopo aver creato il dominio con successo, vai all'endpoint precedentemente creato sotto Front Door Manager e aggiungi una route per associare questo dominio al gruppo di origine corretto.

12. Verifica se mTLS funziona come previsto. Puoi verificare questa condizione assegnando l'IP locale dell'host a uno degli IP di Frontdoor di Azure.

13. Dopo una validazione riuscita aggiorna il record CNMAE personalizzato nel DNS per puntare all'endpoint Frontdoor di Azure.

    Limita l'accesso backend/origine per accettare solo il traffico da Frontdoor di Azure, impedendo così di bypassare mTLS accedendo direttamente all'origine. Per ulteriori informazioni, vedere Proteggere il traffico verso le origini di Frontdoor di Azure.

Per modificare la configurazione mTLS esistente su un dominio, nella pagina Domini , seleziona il nome di dominio. La pagina Modifica un dominio appare con la configurazione mTLS attuale.

Unexpected 403 (Forbidden) da Frontdoor di Azure per richiesta mTLS

Per ulteriori informazioni diagnostiche, passa l'intestazione X-Azure-DebugInfo:1 con la richiesta ad Frontdoor di Azure. Per la risposta, Front Door restituisce l'intestazione di debug, X-Azure-Externalerror, con un valore che suggerisce quale potrebbe essere l'errore. La tabella seguente elenca i valori di errore e i loro significati.

Contenuti correlati

• Crittografia TLS con Frontdoor di Azure
• Criteri TLS di Frontdoor di Azure