Panoramica di TLS e mTLS con autenticazione lato backend

Quando un bilanciatore del carico si connette ai backend all'interno di Google Cloud, il bilanciatore del carico accetta qualsiasi certificato presentato dai backend. In questi casi, il bilanciatore del carico non esegue la convalida dei certificati.

Con il TLS con autenticazione del backend o l'autenticazione del backend, il bilanciatore del carico può verificare l'identità dei backend a cui si connette. Inoltre, con il mTLS di backend, il bilanciatore del carico può dimostrare la propria identità ai backend utilizzando un certificato TLS client.

Il seguente diagramma mostra la differenza tra mTLS frontend e backend, concentrandosi sul ruolo del bilanciatore del carico in ogni caso. In mTLS lato client, il bilanciatore del carico agisce come server, verificando l'identità del client. In mTLS di backend, il bilanciatore del carico agisce come client, dimostrando la propria identità al backend.

mTLS frontend e backend.
mTLS frontend e backend (fai clic per ingrandire).

mTLS opera in modo indipendente sul frontend e sul backend. Puoi configurare mTLS sul frontend, sul backend o su entrambi.

Questo documento fornisce una panoramica del TLS autenticato lato backend e del mTLS lato backend. Per scoprire di più su mTLS frontend, consulta la Panoramica di mutual TLS.

TLS autenticato e mTLS del backend possono essere configurati nella risorsa di servizio del backend dei bilanciatori del carico delle applicazioni esterni globali.

Funzionalità

mTLS utilizza l'infrastruttura a chiave pubblica (PKI) per autenticare l'identità delle persone che comunicano sulla rete. L'infrastruttura include tre componenti: un client, un server e un'autorità di certificazione (CA). Il TLS con autenticazione del backend e il mTLS con autenticazione del backend aggiungono le seguenti funzionalità agli Application Load Balancer:

  • Il bilanciatore del carico può convalidare i certificati presentati dai backend rispetto ai tuoi trust anchor. Puoi caricare più ancore di attendibilità per consentire la migrazione senza problemi da una PKI precedente a una nuova senza tempi di inattività.

  • Il bilanciatore del carico può convalidare i certificati TLS dei backend rispetto alle radici di attendibilità pubbliche (Infrastruttura a chiave pubblica web).

  • Puoi configurare i certificati intermedi oltre agli ancoraggi di attendibilità per contribuire a creare il percorso di convalida dei certificati di backend. L'utilizzo di certificati intermedi significa che i server di backend non devono fornire la catena di certificati completa.

  • Puoi configurare un nome host TLS SNI (Server Name Indication) per il tuo servizio di backend. Durante l'handshake TLS, il bilanciatore del carico include questo nome host SNI nel messaggio ClientHello che invia al backend. Il backend risponde quindi con il proprio certificato TLS e il bilanciatore del carico verifica che almeno uno dei campi Nome alternativo dell'oggetto (SAN) di questo certificato corrisponda al nome host o a uno dei campi SAN configurati per il servizio di backend.

  • Puoi configurare il servizio di backend del bilanciatore del carico in modo che utilizzi mTLS in modo che il bilanciatore del carico possa dimostrare la propria identità ai backend. Questa autenticazione viene eseguita utilizzando un certificato client (bilanciatore del carico) che il bilanciatore del carico presenta al backend.

Requisiti del certificato

Quando configuri i certificati per TLS con autenticazione lato backend e mTLS lato backend, assicurati che rispettino questi requisiti:

  • Gli strumenti di crittografia moderna costituiscono la base dell'autenticazione mTLS. I certificati devono utilizzare algoritmi RSA o ECDSA per lo scambio di chiavi. Gli algoritmi di hashing devono utilizzare SHA-256 o una funzione di hashing crittografica più sicura. Gli algoritmi di hashing come MD4, MD5 e SHA-1 non sono supportati.

  • I certificati dei server secondari forniti dal backend hanno i seguenti requisiti:

  • Per i certificati client foglia (bilanciatore del carico) utilizzati in mTLS backend, il certificato deve essere una risorsa di certificato di Certificate Manager. L'ambito di questo certificato deve essere client-auth, il che indica che viene utilizzato come certificato client nel backend mTLS.

  • I certificati radice e intermedi utilizzati con TLS con autenticazione del backend hanno i seguenti requisiti:

Componenti chiave di TLS e mTLS con autenticazione del backend

Con il TLS autenticato del backend, il bilanciatore del carico può verificare l'identità dei backend a cui si connette. Puoi configurare TLS autenticato di backend su un bilanciatore del carico HTTP(S) che utilizza HTTPS o HTTP/2 come protocollo del servizio di backend. Se non configuri il TLS con autenticazione del backend, il bilanciatore del carico accetta qualsiasi certificato dal backend. Utilizzando mTLS di backend, puoi anche configurare il bilanciatore del carico in modo che presenti il proprio certificato client al backend, che può utilizzarlo per autenticare il bilanciatore del carico.

Per configurare il TLS autenticato lato backend, devi:

  • Crea una risorsa di configurazione dell'attendibilità.
  • Crea una risorsa Configurazione di autenticazione del backend.
  • Aggiorna l'attributo di impostazione TLS nel servizio di backend, indirizzandolo alla risorsa Configurazione autenticazione backend.

Per configurare mTLS di backend, devi creare un certificato client e collegarlo alla risorsa Configurazione di autenticazione del backend. Non puoi collegare il certificato client dopo aver creato la risorsa Configurazione autenticazione backend.

Il seguente diagramma mostra i diversi componenti, collegati al servizio di backend di un bilanciatore del carico delle applicazioni, che attivano TLS con autenticazione del backend e mTLS di backend.

Componenti TLS e mTLS autenticati lato backend.
Componenti TLS e mTLS di backend autenticati (fai clic per ingrandire).

Le informazioni che seguono forniscono una panoramica di questi diversi componenti utilizzati per configurare il TLS autenticato e il mTLS di backend.

Configurazione dell'attendibilità

Per autenticare i certificati del server che il tuo backend presenta al bilanciatore del carico, quest'ultimo deve essere configurato con certificati X.509 che stabiliscono una catena di attendibilità per l'emittente del certificato del backend. Configura la configurazione attendibilità utilizzando una TrustConfig risorsa, che esprime l'intera configurazione attendibilità e contiene un singolo magazzino attendibilità.

Un archivio attendibilità incapsula un trust anchor (certificato radice) e, facoltativamente, uno o più certificati intermedi. Un trust anchor è un certificato che rappresenta una radice di attendibilità. Un certificato del server valido deve mostrare una catena di attendibilità che rimandi a un'ancora di attendibilità nell'archivio attendibilità.

Un certificato intermedio fa parte di una catena di attendibilità che rimanda a un trust anchor nell'archivio di attendibilità. Viene utilizzato, insieme a eventuali altre CA intermedie incluse nel certificato finale, per creare la catena di attendibilità durante il processo di convalida. La creazione di un certificato intermedio è facoltativa.

Se devi utilizzare un certificato autofirmato, scaduto, non collegato a un'autorità di certificazione radice specificata o la cui convalida non è riuscita, puoi aggiungerlo a una lista consentita nella configurazione dell'attendibilità. Anche la creazione di un certificato autofirmato che può essere aggiunto a una lista consentita è facoltativa.

Il trust store non contiene chiavi private perché solo i certificati sono necessari per verificare una catena di attendibilità.

Risorsa Configurazione di autenticazione del backend

La risorsa Configurazione dell'autenticazione del backend (BackendAuthenticationConfig), collegata al servizio di backend del bilanciatore del carico, consente quanto segue:

  • TLS autenticato lato backend (utilizzando la configurazione di attendibilità e le radici di attendibilità pubbliche)
  • mTLS di backend (utilizzo del certificato client)

Per abilitare TLS e mTLS con autenticazione del backend, la risorsa Configurazione autenticazione backend fa riferimento alle seguenti risorse:

  • Configurazione attendibilità (trustConfig): la configurazione attendibilità allegata utilizzata per convalidare il certificato del server fornito dal backend.

  • Radici di attendibilità pubbliche (wellKnownRoots): indica se il bilanciatore del carico considera attendibili i certificati dei server di backend emessi da CA pubbliche, oltre ai certificati considerati attendibili dalla configurazione della attendibilità. Per scoprire di più, consulta l'articolo Utilizzare le radici pubbliche di fiducia.

  • Certificato client (clientCertificate): il certificato client utilizzato dal bilanciatore del carico per esprimere la propria identità al backend, se la connessione al backend utilizza mTLS. Per TLS con autenticazione del backend (autenticazione del backend), questo campo può essere vuoto, nel qual caso il bilanciatore del carico autentica solo il backend, ma non se stesso, al backend.

Servizio di backend

All'interno del servizio di backend, l'attributo tlsSettings punta alle seguenti risorse per convalidare il certificato di backend.

  • Configurazione di autenticazione del backend (authenticationConfig)
  • Nome host SNI (sni)
  • SAN accettate (subjectAltNames)

I campi SNI (sni) e SAN (subjectAltNames) nell'attributo tlsSettings controllano il modo in cui il bilanciatore del carico convalida il certificato del backend in base ai valori SAN del certificato. Questi campi influiscono sulla procedura di convalida indipendentemente dal fatto che sia configurato o meno il protocollo TLS con autenticazione del backend.

Quando il campo SNI è impostato (tlsSettings.sni), il bilanciatore del carico esegue le seguenti operazioni:

  • Invia il nome host SNI al server di backend durante l'handshake TLS.
  • Verifica che il certificato TLS del backend includa un nome comune del soggetto corrispondente al nome host SNI.

Per impostazione predefinita, il bilanciatore del carico controlla che il certificato TLS del backend includa un nome comune del soggetto corrispondente al nome host SNI. Tuttavia, se le SAN sono configurate sul servizio di backend (tlsSettings.subjectAltNames), il bilanciatore del carico esegue le seguenti operazioni:

  • Ignora il nome host SNI per la verifica SAN.
  • Verifica che il certificato TLS del backend includa un nome comune del soggetto corrispondente a uno dei nomi comuni del soggetto accettati (subjectAltNames) configurati nel servizio di backend.

Certificato client

Oltre al TLS autenticato dal backend (autenticazione del backend), puoi configurare il servizio di backend di un bilanciatore del carico in modo che utilizzi mTLS, in modo che il bilanciatore del carico possa dimostrare la propria identità al backend. Questa autenticazione utilizza un certificato client (bilanciatore del carico) che il bilanciatore del carico presenta al backend.

Per configurare mTLS di backend, devi:

  • Crea una risorsa del certificato client contenente il certificato del client (load balancer) e la relativa chiave privata.
  • Allega il certificato client alla risorsa Configurazione dell'autenticazione del backend.

mTLS di backend è compatibile anche con le identità dei carichi di lavoro gestiti di Compute Engine quando configuri i certificati gestiti tramite Gestione certificati. I certificati PKI pubblici gestiti non sono supportati e tutti i certificati client devono avere un ambito client-auth e rispettare i requisiti dei certificati.

Se il backend richiede un certificato client, deve essere configurato per accettarlo. Se il backend rifiuta la connessione del bilanciatore del carico, quest'ultimo restituisce un codice di stato HTTP 502 per le richieste di cui fa il proxy e registra uno stato generico in Cloud Logging.

Configura TLS autenticato e mTLS sul backend del bilanciatore del carico

Puoi configurare TLS autenticato e mTLS sul bilanciatore del carico utilizzando una PKI privata o radici di attendibilità pubbliche.

Utilizza PKI privata

Di seguito è riportata una panoramica generale dei passaggi chiave da seguire per configurare il TLS autenticato e il mTLS sul bilanciatore del carico utilizzando i certificati emessi dalla tua PKI privata. La PKI privata ha il vantaggio di essere completamente sotto il tuo controllo e isolata dai sistemi PKI della rete internet pubblica.

  1. Crea una risorsa di configurazione attendibilità contenente l'ancora di attendibilità (certificato radice) e i certificati intermedi che fungono da radici di attendibilità.

  2. Per configurare mTLS di backend, crea un certificato client contenente il certificato client (bilanciatore del carico) e la relativa chiave privata.

  3. Crea una risorsa di configurazione dell'autenticazione del backend che fa riferimento alla configurazione dell'attendibilità. Se vuoi configurare mTLS nel backend, la risorsa Authentication Config del backend fa riferimento sia alla configurazione dell'attendibilità sia al certificato client.

  4. Collega la risorsa Configurazione di autenticazione del backend al servizio di backend del bilanciatore del carico.

Per scoprire di più su questa configurazione, consulta le seguenti guide:

Utilizzare le radici di attendibilità pubbliche

Oltre a utilizzare i certificati emessi dalla tua PKI privata per attivare il TLS autenticato lato backend, puoi anche utilizzare le radici pubbliche di attendibilità per convalidare il certificato lato backend.

Per utilizzare le radici di attendibilità pubbliche, non è necessario creare una configurazione dell'attendibilità e collegarla alla risorsa Configurazione dell'autenticazione del backend. Devi invece impostare PUBLIC_ROOTS come valore nel campo wellKnownRoots della risorsa Configurazione autenticazione backend. Detto questo, puoi anche creare una configurazione di attendibilità che includa esplicitamente le radici dei certificati emessi pubblicamente, oltre ai certificati attendibili dalla configurazione di attendibilità.

L'impostazione PUBLIC_ROOTS utilizza un insieme di CA radice, simile all'insieme di CA radice considerate attendibili dai browser, gestito da Google e che può cambiare nel tempo. Ciò comporta il rischio che i certificati di backend diventino non validi quando queste radici cambiano. Se devi convalidare i certificati emessi pubblicamente, ti consigliamo di scegliere una CA consolidata e attendibile che utilizzi la firma tra CA intermedia per emettere i certificati di backend per ridurre il rischio che un certificato radice scada o venga revocato.

Procedura di convalida del certificato del server

Quando convalida il certificato del server durante il TLS con autenticazione del backend o l'autenticazione del backend, il bilanciatore del carico esegue le seguenti operazioni:

  1. Verifica che il server possieda la chiave privata del certificato.

    Il server dimostra il possesso della chiave privata associata al certificato che presenta al bilanciatore del carico firmando un'informazione con la sua chiave privata e inviandola al bilanciatore del carico come parte del messaggio CertificateVerify. Il bilanciatore del carico verifica quindi questa firma utilizzando la chiave pubblica del certificato del server. Se la verifica della firma non va a buon fine, significa che il server di backend non possiede la chiave privata corrispondente al certificato. In questi casi, il bilanciatore del carico termina l'handshake TLS senza registrare errori.

  2. Verifica la catena di attendibilità.

    Se la configurazione della attendibilità include almeno un'ancora di attendibilità o se l'attributo wellKnownRoots è impostato su PUBLIC_ROOTS, il bilanciatore del carico tenta di verificare una catena di attendibilità tra il certificato del server e l'ancora di attendibilità configurata. I controlli di verifica includono quanto segue:

    • Il certificato del server del backend, i certificati intermedi (se forniti) e il certificato radice configurato sono conformi ai requisiti dei certificati.
    • Per tutti i certificati della catena di attendibilità, il campo dell'oggetto nel certificato principale corrisponde al campo dell'emittente nel certificato secondario. Questa verifica contribuisce ad assicurare che l'identità (dell'oggetto) del certificato principale sia uguale a quella indicata come emittente nel certificato secondario.
    • Per tutti i certificati della catena di attendibilità, l'identificatore della chiave del soggetto (SKID) del certificato principale corrisponde all'identificatore della chiave dell'autorità (AKID) nel certificato secondario. Questa corrispondenza conferma che il certificato secondario è stato emesso dall'autorità principale corretta e che può essere considerato attendibile perché la chiave pubblica della principale viene richiamata nell'AKID per verificare la validità del certificato.
  3. Stabilisci una connessione con il backend.

    Se la convalida del certificato va a buon fine, il bilanciatore del carico procede con la connessione al backend.

    Tuttavia, se la convalida del certificato non va a buon fine, il bilanciatore del carico termina la connessione al backend, invia un codice di stato HTTP 502 al client e registra il motivo dell'interruzione in Cloud Logging. In caso di un errore di convalida del certificato, le richieste in arrivo successive attivano il bilanciatore del carico per riavviare la connessione al backend.

    La connessione al backend può non riuscire anche se il server di backend rifiuta la connessione. Con il backend mTLS, questo può accadere perché il certificato del client non è valido. Quando la connessione al backend non va a buon fine, il bilanciatore del carico risponde alle richieste proxy con un codice di stato HTTP 502 e registra un motivo di errore generico in Cloud Logging.

Limitazioni

  • TLS con autenticazione lato backend e mTLS con autenticazione lato backend possono essere configurati solo per bilanciatori del carico delle applicazioni esterni globali. I bilanciatori del carico delle applicazioni classici non supportano TLS con autenticazione del backend e mTLS con autenticazione del backend.

  • Il TLS autenticato e il mTLS di backend non sono supportati per i seguenti tipi di backend:

    • Backend NEG internet globali

    • Back-end di App Engine

  • Per attivare mTLS di backend, devi anche configurare il TLS con autenticazione di backend.

  • Se vuoi attivare l'autenticazione mTLS del backend, devi creare il certificato client prima di configurare la risorsa Configurazione di autenticazione del backend.

  • I controlli di integrità utilizzati dai backend non implementano le funzionalità di autenticazione TLS o mTLS. Devi configurare i backend con endpoint di controllo di integrità che possono rispondere alle richieste HTTP o HTTPS.

  • Il bilanciatore del carico non passa il nome host SNI del client dalla connessione TLS frontend quando si connette a un backend. Tuttavia, i backend possono accedere al nome host SNI del client utilizzando un'intestazione della richiesta personalizzata.

  • Per mTLS di backend, le chiavi dei certificati client sono limitate a quanto segue:

    • Le chiavi RSA possono variare da 2048 a 4096 bit.
    • Le chiavi ECDSA possono utilizzare le curve P-256 o P-384.
  • Il TLS autenticato lato backend non supporta i controlli di revoca del certificato.

Quote e limiti

  • Un singolo archivio attendibilità può contenere fino a 200 trust anchor e certificati intermedi combinati, con un limite separato di 100 per i certificati intermedi. Non più di tre certificati intermedi possono condividere le stesse informazioni relative a Subject e Subject Public Key.

  • La profondità massima di una catena di certificati è di 10 certificati, inclusi i certificati radice e a foglia. Il numero massimo di certificati intermedi che possono essere valutati durante il tentativo di creare la catena di attendibilità è 100.

  • TLS con autenticazione del backend limita la catena di certificati ricevuta dal backend a non più di 16 KB e 10 certificati.

  • I certificati radice utilizzati per la convalida non possono contenere più di 10 vincoli di nome.

  • Il numero massimo di nomi alternativi dell'oggetto consentito nel tlsSettings.subjectAltNames[] è 5.

Passaggi successivi