Configurare la connettività di rete e mTLS per la gestione delle chiavi esterne di Managed HSM (anteprima)

Importante

La gestione esterna delle chiavi di Managed HSM è in anteprima. Le funzionalità di anteprima vengono rese disponibili all'utente in base alla condizione che si accettano le condizioni supplementari per l'utilizzo. Alcuni aspetti di questa funzionalità potrebbero cambiare prima della disponibilità generale.

Questo articolo descrive la configurazione di sicurezza a livello di rete e di trasporto necessaria per connettere Managed HSM al proxy EKM. È rivolto a tecnici della rete e della sicurezza che configurano o gestiscono una distribuzione di gestione delle chiavi esterna.

Imparerai come scegliere un modello di connettività, quale traffico in uscita genera Managed HSM e come effettuare il provisioning e la rotazione dei certificati mutual TLS (mTLS) che autenticano entrambe le estremità della connessione.

Per l'architettura end-to-end e il flusso delle richieste, vedere l'architettura di gestione delle chiavi esterne di Managed HSM. Per i passaggi di installazione a livello di comando, vedere Avvio rapido: Creare la prima chiave esterna usando il interfaccia della riga di comando di Azure.

Modello di connettività

Managed HSM avvia una connessione mTLS in uscita verso il tuo proxy EKM. Nella versione di anteprima iniziale, il proxy EKM deve essere raggiungibile tramite la rete Internet pubblica su un FQDN risolvibile pubblicamente. Questo è l'unico modello di connettività supportato.

La sicurezza non dipende dalle restrizioni a livello di rete. La connessione è protetta da TLS reciproco (mTLS): entrambi i lati presentano e verificano i certificati X.509 prima che venga scambiato qualsiasi payload. Gli indirizzi IP di origine del modulo di protezione hardware gestiti non sono statici e non possono essere elencati, quindi non è possibile limitare il traffico in ingresso solo al modulo di protezione hardware gestito. L'identità basata su certificati è il meccanismo di sicurezza supportato.

Configurare il modello Internet pubblico

In questo modello, il proxy EKM è raggiungibile tramite internet pubblico su un FQDN risolvibile pubblicamente.

  1. Distribuire il proxy EKM in un host con un indirizzo IP pubblico e un record DNS.
  2. Ottenere un certificato server TLS da un'autorità di certificazione (CA) il cui certificato radice verrà registrato nella connessione di gestione delle chiavi esterne.
  3. Configurare il proxy per l'ascolto sulla porta TCP 443 con TLS 1.3 abilitato. La porta 443 è necessaria per l'anteprima.
  4. Creare la connessione di gestione delle chiavi esterne con --host impostato sull'FQDN pubblico e --server-ca-certificate impostato sul certificato CA radice in formato PEM.

Per il comando completoaz keyvault ekm-connection create, vedere Avvio rapido: Creare la prima chiave esterna usando il interfaccia della riga di comando di Azure.

Note

Anche se il proxy è raggiungibile pubblicamente, la connessione viene comunque autenticata a vicenda. Un attaccante che raggiunge l'endpoint del proxy senza un certificato client HSM gestito valido non può completare l'handshake.

Panoramica di mTLS

La connessione tra Managed HSM e il proxy EKM utilizza TLS reciproco (mTLS). Entrambi i lati presentano certificati X.509 ed entrambi i lati verificano il certificato del peer prima di scambiare qualsiasi payload.

  • Certificato server : il proxy EKM presenta questo certificato al modulo di protezione hardware gestito. HSM gestito lo verifica confrontandolo con la CA radice registrata nella connessione di gestione esterna delle chiavi.
  • Certificato client : il modulo di protezione hardware gestito presenta questo certificato al proxy EKM. Il proxy deve convalidarlo e rifiutare le connessioni da emittenti sconosciute.

Questa autenticazione bidirezionale è ciò che stabilisce l'identità. Gli indirizzi IP di origine di HSM gestiti non sono stabili e non possono essere fissati dal cliente, quindi l'inserimento in un elenco di indirizzi IP consentiti basato su IP non è sufficiente. L'identità basata su certificati è l'unico meccanismo supportato.

Requisiti TLS:

  • Versione minima: TLS 1.3.
  • Pacchetti di crittografia obbligatori: TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256.

Certificato server (proxy → HSM gestito)

Il certificato server del proxy è un certificato PKIX standard. L'utente è responsabile del provisioning, del rinnovo e della sua revoca.

Cosa convalida HSM gestito:

  • Il certificato è collegato alla CA radice registrata nel campo --server-ca-certificate della connessione di gestione delle chiavi esterne.
  • Il certificato si trova all'interno della finestra di validità.
  • Il nome alternativo del soggetto (SAN) corrisponde al nome host del proxy configurato nella connessione di gestione delle chiavi esterne.

Cosa --server-ca-certificate accetta:

Un certificato CA radice in formato PEM o DER. Passare il percorso del file al certificato quando si esegue az keyvault ekm-connection create o az keyvault ekm-connection update. Nel flusso di caricamento del portale di Azure usare il formato PEM con un'estensione.cer.

Rotazione del certificato del server:

  • Se il nuovo certificato è concatenato alla stessa CA radice già registrata nella connessione di gestione esterna delle chiavi, distribuisci il nuovo certificato sul proxy. Non è necessaria alcuna modifica alla connessione di gestione delle chiavi esterne.

  • Se il nuovo certificato usa una CA radice diversa, aggiornare la connessione di gestione delle chiavi esterne con la nuova CA prima di distribuire il nuovo certificato:

    az keyvault ekm-connection update \
  --hsm-name <Managed HSM Name> \
  --server-ca-certificate oldandnewrootcas.pem

    Aggiornare prima la connessione per evitare una finestra in cui il proxy presenta un certificato che il modulo di protezione hardware gestito non può convalidare.

Certificato client (HSM gestito → proxy)

Managed HSM presenta al proxy un certificato client X.509 specifico del pool a ogni connessione. Microsoft emette e gestisce questo certificato.

Recupera informazioni sul certificato client che Managed HSM usa per autenticarsi al proxy EKM:

az keyvault ekm-connection certificate show --hsm-name <Managed HSM Name>

Il comando restituisce il nome comune del soggetto del certificato client e una matrice di certificati radice X.509, in cui ogni certificato viene codificato come DER Base64.

Configurare il proxy per accettare il certificato:

Il proxy deve inserire entrambi i seguenti nell’elenco degli elementi consentiti:

  • Nome comune del soggetto del certificato client (subjectCommonName).
  • I certificati radice (caCertificates) restituiti dal comando.

Poiché l'elenco di elementi consentiti si basa sul nome comune del soggetto e sulla CA radice anziché su un'impronta digitale del certificato specifico, il proxy continua ad accettare le connessioni dopo che il modulo di protezione hardware gestito ruota il certificato client, purché il nome comune del soggetto e la CA radice non vengano modificati.

Rotazione dei certificati client mTLS

Microsoft ruota il certificato client di Managed HSM a intervalli regolari. Il nuovo certificato viene rilasciato prima della scadenza precedente e il modulo di protezione hardware gestito presenta automaticamente il nuovo certificato dopo la rotazione.

Poiché il proxy usa una lista consentita basata sul nome comune del soggetto e sui certificati radice, anziché su un certificato specifico, non è necessaria alcuna azione quando il certificato viene rinnovato, purché il nome comune del soggetto e caCertificates rimangano invariati.

Strategia di monitoraggio:

  1. Esegui az keyvault ekm-connection certificate show --hsm-name <Managed HSM Name> secondo una pianificazione (ad esempio, settimanalmente utilizzando un processo cron o un runbook di Automazione di Azure).
  2. Controllare le modifiche apportate alla matrice restituita caCertificates .
  3. Se caCertificates cambia, recuperare il nuovo array caCertificates e aggiungerlo all'elenco consentiti sul lato del proxy EKM.

Requisiti firewall e DNS

Configurare sia le regole del firewall che il DNS nella rete in cui viene eseguito il proxy EKM.

Regole del firewall

Configurate il firewall sul segmento di rete in cui è in esecuzione il proxy per:

  • Consenti TCP 443 in ingresso dalla rete Internet pubblica. L'anteprima richiede in particolare la porta 443. Gli indirizzi IP di origine del modulo di protezione hardware gestiti non sono statici e non possono essere elencati, quindi non è possibile limitare il traffico in ingresso solo al modulo di protezione hardware gestito.
  • Consentire TLS 1.3 in ingresso con i pacchetti di crittografia necessari.

Note

Non esistono tag di servizio di Azure per il traffico EKM in uscita di HSM gestito in anteprima. Poiché gli indirizzi IP di origine dell'HSM gestito non sono statici, la creazione di un elenco di elementi consentiti basato su IP non è supportata. Il proxy deve accettare TCP 443 da qualsiasi origine. La convalida del certificato client mTLS è l'unico meccanismo di controllo di accesso supportato.

Non fare affidamento sull'elenco di elementi consentiti basati su IP come controllo di sicurezza. La convalida del certificato client mTLS è il meccanismo di autenticazione che protegge il proxy.

Requisiti DNS

  • L'FQDN del proxy configurato nella connessione di gestione delle chiavi esterna deve risolversi in un indirizzo raggiungibile pubblicamente dal punto di vista di Managed HSM.
  • Se si modifica l'indirizzo proxy, aggiornare la connessione di gestione delle chiavi esterne in modo da riflettere il nuovo FQDN o IP. La risoluzione DNS avviene in Managed HSM a ogni connessione.

Risoluzione degli errori di rete comuni

Per la guida completa alla risoluzione dei problemi, vedere Risolvere i problemi relativi alla gestione delle chiavi esterne del modulo di protezione hardware gestito. I tre sintomi più comuni specifici della rete sono:

Mancata corrispondenza del certificato

L'handshake mTLS ha esito negativo perché il certificato server del proxy non si concatena alla CA registrata nella connessione di gestione delle chiavi esterne oppure il nome soggetto o la CA radice del certificato client del modulo di protezione hardware gestito non si trova nell'elenco di indirizzi consentiti del proxy. Controllare az keyvault ekm-connection certificate show e verificare che l'allow-list del proxy sia aggiornata. Verificare che la connessione --server-ca-certificate di gestione delle chiavi esterne corrisponda alla CA radice che ha emesso il certificato proxy corrente.

Errore di risoluzione dei nomi

Managed HSM non riesce a risolvere l'FQDN del proxy. Ciò si verifica quando il record DNS pubblico per il proxy è mancante o non aggiornato. Verificare che l'FQDN nella connessione di gestione delle chiavi esterna si risolva nel corretto indirizzo IP pubblico.

Timeout di connessione

Timeout della connessione TCP al proxy. Una causa comune è una regola del firewall che blocca il traffico in ingresso sulla porta proxy. Controllare i log del firewall e verificare che il proxy sia in ascolto sulla porta prevista.

Contenuti correlati

  • Last updated on