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 alcuna convalida dei certificati.

Con TLS autenticato dal backend o l'autenticazione del backend, il bilanciatore del carico può verificare l'identità dei backend a cui si connette. Con mTLS di backend, il bilanciatore del carico può inoltre 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 frontend, il bilanciatore del carico funge da server, verificando l'identità del client. In mTLS backend, il bilanciatore del carico funge da client, dimostrando la propria identità al backend.

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

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

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

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

Funzionalità

mTLS utilizza l'infrastruttura a chiave pubblica (PKI) per autenticare l'identità delle entità che comunicano sulla rete. L'infrastruttura include tre componenti: un client, un server e un'autorità di certificazione (CA). TLS autenticato dal backend e mTLS del backend aggiungono le seguenti funzionalità ai bilanciatori del carico delle applicazioni:

  • Il bilanciatore del carico può convalidare i certificati presentati dai backend in base ai tuoi trust anchor. Puoi caricare più trust anchor 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 (PKI web).

  • Puoi configurare i certificati intermedi oltre agli ancoraggi attendibili 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 di indicazione del nome del server (SNI) TLS 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 con il proprio certificato TLS e il bilanciatore del carico verifica che almeno uno dei campi Nome alternativo del soggetto (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 autenticato dal backend e mTLS del backend, assicurati che rispettino questi requisiti:

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

  • I certificati del server foglia forniti dal backend hanno i seguenti requisiti:

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

  • I certificati radice e intermedi utilizzati con TLS autenticato dal backend devono soddisfare i seguenti requisiti:

Componenti chiave di TLS autenticato dal backend e mTLS del backend

Con TLS autenticato dal 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 TLS autenticato del backend, il bilanciatore del carico accetta qualsiasi certificato dal backend. Utilizzando mTLS del backend, puoi configurare ulteriormente il bilanciatore del carico in modo che presenti il proprio certificato client al backend, che può essere utilizzato per autenticare il bilanciatore del carico.

Per configurare TLS autenticato del backend, devi:

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

Per configurare l'mTLS del backend, devi creare un certificato client e allegarlo alla risorsa di configurazione dell'autenticazione del backend. Non puoi allegare il certificato client dopo la creazione della risorsa di configurazione dell'autenticazione del backend.

Il seguente diagramma mostra i diversi componenti collegati al servizio di backend di un bilanciatore del carico delle applicazioni che abilitano TLS autenticato del backend e mTLS del backend.

Componenti TLS autenticato dal backend e mTLS del backend.
Componenti TLS autenticato dal backend e mTLS del backend (fai clic per ingrandire).

Le informazioni che seguono forniscono una panoramica dei diversi componenti utilizzati per configurare TLS autenticato dal backend e mTLS del backend.

Configurazione dell'attendibilità

Per autenticare i certificati server che il 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. Configuri la configurazione di attendibilità utilizzando una TrustConfig risorsa, che esprime l'intera configurazione di attendibilità e contiene un singolo archivio attendibilità.

Un archivio di 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 server valido deve mostrare una catena di attendibilità che rimanda a un ancoraggio di attendibilità nell'archivio attendibilità.

Un certificato intermedio fa parte di una catena di attendibilità che riconduce a un trust anchor nell'archivio di attendibilità. Viene utilizzato, insieme a eventuali CA intermedie aggiuntive incluse nel certificato foglia, 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 concatenato a una radice di attendibilità 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.

L'archivio attendibilità non contiene chiavi private perché per verificare una catena di attendibilità sono necessari solo i certificati.

Risorsa di configurazione dell'autenticazione del backend

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

  • TLS autenticato dal backend (utilizzando la configurazione di attendibilità e le radici di attendibilità pubbliche)
  • mTLS di backend (utilizzando il certificato client)

Per abilitare TLS autenticato del backend e mTLS del backend, la risorsa di configurazione dell'autenticazione del backend punta alle seguenti risorse:

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

  • Radici di attendibilità pubbliche (wellKnownRoots): indica se il bilanciatore del carico considera attendibili i certificati del server di backend emessi da CA pubbliche, oltre ai certificati considerati attendibili dalla configurazione di attendibilità. Per scoprire di più, consulta Utilizzo delle radici pubbliche di attendibilità.

  • Certificato client (clientCertificate): il certificato client che il bilanciatore del carico utilizza per esprimere la propria identità al backend, se la connessione al backend utilizza mTLS. Per TLS autenticato dal 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 del backend.

  • Configurazione dell'autenticazione del backend (authenticationConfig)
  • Nome host SNI (sni)
  • SAN accettati (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 influenzano la procedura di convalida indipendentemente dal fatto che TLS autenticato del backend sia configurato.

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 che corrisponda al nome host SNI.

Per impostazione predefinita, il bilanciatore del carico verifica che il certificato TLS del backend includa un nome comune del soggetto che corrisponda al nome host SNI. Tuttavia, se i SAN sono configurati 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 che corrisponda a uno dei nomi comuni del soggetto accettati (subjectAltNames) configurati nel servizio di backend.

Certificato client

Oltre a TLS autenticato del 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 backend, devi:

  • Crea una risorsa certificato client contenente il certificato client (bilanciatore del carico) e la relativa chiave privata.
  • Collega il certificato client alla risorsa di configurazione dell'autenticazione del backend.

L'mTLS del backend è compatibile anche con le identità dei carichi di lavoro gestiti di Compute Engine quando configuri i certificati gestiti tramite Certificate Manager. I certificati gestiti con PKI pubblica 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, il bilanciatore del carico restituisce un codice di stato HTTP 502 per le richieste di cui esegue il proxy e registra uno stato generico in Cloud Logging.

Configura TLS autenticato del backend e mTLS del backend sul bilanciatore del carico

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

Utilizza l'infrastruttura a chiave pubblica privata

Di seguito è riportata una panoramica generale dei passaggi chiave da seguire per configurare TLS autenticato del backend e mTLS del backend 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 di internet pubblica.

  1. Crea una risorsa di configurazione dell'attendibilità che comprenda il trust anchor (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 faccia riferimento alla configurazione dell'attendibilità. Se vuoi configurare l'mTLS del backend, la risorsa di configurazione dell'autenticazione del backend fa riferimento sia alla configurazione dell'attendibilità sia al certificato client.

  4. Collega la risorsa di configurazione dell'autenticazione del backend al servizio di backend del bilanciatore del carico.

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

Utilizzare radici di attendibilità pubbliche

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

Per utilizzare le radici di attendibilità pubbliche, non è necessario creare una configurazione dell'attendibilità e associarla alla risorsa di configurazione dell'autenticazione del backend. Devi invece impostare PUBLIC_ROOTS come valore nel campo wellKnownRoots della risorsa di configurazione dell'autenticazione backend. Detto questo, puoi anche creare una configurazione di attendibilità che includa esplicitamente le radici dei certificati emessi pubblicamente, oltre ai certificati considerati 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 certificati emessi pubblicamente, valuta la possibilità di scegliere una CA consolidata e attendibile e che utilizzi la firma incrociata intermedia per l'emissione dei certificati di backend per ridurre il rischio di scadenza o revoca di un certificato radice.

Passaggi di convalida del certificato del server

Durante la convalida del certificato del server durante TLS autenticato dal backend o l'autenticazione del backend, il bilanciatore del carico esegue le seguenti operazioni:

  1. Verifica che il server disponga della chiave privata del certificato.

    Il server dimostra di possedere la chiave privata associata al certificato che presenta al bilanciatore del carico firmando un'informazione utilizzando la chiave privata e inviandola al bilanciatore del carico come parte del messaggio CertificateVerify. Il bilanciatore del carico verifica 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 dispone della 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 di attendibilità include almeno un trust anchor o l'attributo wellKnownRoots è impostato su PUBLIC_ROOTS, il bilanciatore del carico tenta di verificare una catena di attendibilità tra il certificato del server e il trust anchor configurato. I controlli di verifica includono quanto segue:

    • Il certificato server, i certificati intermedi (se forniti) e il certificato radice configurato del backend sono conformi ai requisiti dei certificati.
    • Per tutti i certificati nella catena di attendibilità, il campo Subject (Soggetto) nel certificato padre corrisponde al campo Issuer (Emittente) nel certificato figlio. Questa verifica contribuisce a garantire che l'identità (oggetto) del certificato principale sia la stessa indicata come emittente nel certificato secondario.
    • Per tutti i certificati nella catena di attendibilità, l'identificatore della chiave del soggetto (SKID) del certificato padre corrisponde all'identificatore della chiave dell'autorità (AKID) nel certificato figlio. Questa corrispondenza conferma che il certificato secondario è stato emesso dall'autorità radice corretta e che può essere considerato attendibile perché la chiave pubblica della radice viene citata nell'AKID per verificare la validità del certificato.

  3. Stabilisci una connessione con il backend.

    Se la convalida del certificato ha esito positivo, il bilanciatore del carico procede con la connessione al backend.

    Tuttavia, se la convalida del certificato non riesce, il bilanciatore del carico termina la connessione al backend, invia un codice di stato HTTP 502 al client e registra il motivo della terminazione in Cloud Logging. In caso di errore di convalida del certificato, le successive richieste in entrata attivano il bilanciatore del carico per riavviare la connessione di backend.

    La connessione di backend può non riuscire anche se il server di backend rifiuta la connessione. Con mTLS backend, ciò può accadere perché il certificato client risulta 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.

Gestione degli errori e logging

I bilanciatori del carico delle applicazioni forniscono funzionalità di logging dettagliate che consentono di monitorare la convalida dei certificati server, identificare potenziali problemi e risolvere i problemi di connessione. Questa sezione descrive i diversi tipi di errori che possono verificarsi durante la convalida mTLS e come vengono registrati.

Se la convalida del certificato del server non riesce, la connessione viene interrotta e gli errori vengono registrati in Cloud Logging. Questi errori sono descritti nella tabella seguente.

Stato del certificato server Errore registrato
La catena di certificati del server è troppo lunga (più di 10 certificati intermedi inclusi nel certificato server). server_cert_chain_exceeded_limit

Un server o un certificato intermedio ha una dimensione della chiave RSA non valida.

Non viene eseguita alcuna convalida.

Le chiavi RSA possono variare da 2048 a 4096 bit.

 server_cert_invalid_rsa_key_size

Un server o un certificato intermedio utilizza una curva ellittica non supportata.

Non viene eseguita alcuna convalida.

Le curve valide sono P-256 e P-384.

 server_cert_unsupported_elliptic_curve_key

Un server o un certificato intermedio utilizza un algoritmo non RSA o non ECDSA.

Non viene eseguita alcuna convalida.

 server_cert_unsupported_key_algorithm

La PKI da utilizzare per la convalida ha più di dieci certificati intermedi che condividono lo stesso oggetto e le stesse informazioni sulla chiave pubblica dell'oggetto.

Non viene eseguita alcuna convalida.

 server_cert_pki_too_large

Un certificato intermedio fornito per la convalida aveva più di 10 vincoli relativi ai nomi.

server_cert_chain_max_name_constraints_exceeded

Il certificato del server ha un campo di estensione Extended Key Usage (EKU), ma questo campo non include serverAuth.

server_cert_chain_invalid_eku
Il limite di tempo è stato superato durante il tentativo di convalidare la catena di certificati. server_cert_validation_timed_out

È stato raggiunto il limite di profondità o iterazione durante il tentativo di convalidare la catena di certificati.

La profondità massima per una catena di certificati è dieci, inclusi i certificati radice e server. Il numero massimo di iterazioni è 100 (certificati esaminati per convalidare la catena di certificati del server).

 server_cert_validation_search_limit_exceeded

Hai configurato mTLS senza configurare una risorsa TrustConfig.

 server_cert_validation_not_performed

Il server non ha fornito il certificato richiesto durante l'handshake.

 server_cert_not_provided

La verifica del certificato del server non è riuscita con la risorsa TrustConfig.

 ssl_certificate_verification_failed

Il servizio non è in grado di eseguire la convalida della catena di certificati.

 server_cert_validation_unavailable
Errore interno durante la convalida della catena di certificati. server_cert_validation_internal_error

TrustConfig corrispondente non trovato.

 server_cert_trust_config_not_found
Il payload del certificato del server (inclusi eventuali certificati intermedi) è troppo grande (più di 16 KB). server_cert_exceeded_size_limit

Limitazioni

  • TLS autenticato dal backend e mTLS del backend possono essere configurati solo per i bilanciatori del carico delle applicazioni esterni globali. I bilanciatori del carico delle applicazioni classici non supportano TLS autenticato dal backend e mTLS del backend.

  • TLS autenticato dal backend e mTLS del backend non sono supportati per i seguenti tipi di backend:

    • Backend di NEG internet globali

    • Backend App Engine

  • Per abilitare mTLS del backend, devi anche configurare TLS autenticato del backend.

  • Se vuoi abilitare mTLS del backend, devi creare il certificato client prima di configurare la risorsa di configurazione dell'autenticazione del backend.

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

  • Il bilanciatore del carico non trasmette 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 del certificato 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.

  • TLS autenticato dal backend non supporta i controlli di revoca dei certificati.

Quote e limiti

  • Un singolo archivio di 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 su soggetto e chiave pubblica del soggetto.

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

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

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

  • Il numero massimo di nomi alternativi del soggetto consentiti nel campo tlsSettings.subjectAltNames[] è 5.

Passaggi successivi