Abilita OCI HYOK con Thales CipherTrust Manager utilizzando OCI Load Balancer per l'alta disponibilità
Introduzione
Nell'esercitazione precedente, abbiamo esplorato l'integrazione di Thales CipherTrust Manager con Oracle Cloud Infrastructure (OCI) per abilitare le funzionalità HYOK (Hold Your Own Key), sia con che senza un gateway API OCI. Sebbene il clustering di CipherTrust Manager fornisca un livello di recuperabilità, non garantisce un'alta disponibilità accurata dal punto di vista della rete.
Thales CipherTrust Manager non supporta in modo nativo un indirizzo IP virtuale (indirizzo VIP) per il failover senza interruzioni tra i nodi.
Questa esercitazione descrive le limitazioni introdotte da OCI Load Balancer per fornire alta disponibilità di rete per le istanze di Thales CipherTrust Manager. Posizionando i manager CipherTrust in cluster dietro un load balancer OCI, possiamo garantire disponibilità continua e tolleranza agli errori per i servizi di gestione delle chiavi esterne in OCI, anche in caso di guasto di un nodo o di interruzione del data center.
Questa esercitazione descrive in dettaglio l'architettura, la configurazione e le considerazioni per la distribuzione di questa impostazione nell'ambiente OCI.
Obiettivi
- Task 1: esaminare le architetture HYOK di OCI e Thales CipherTrust Manager esistenti.
- Task 2: creare un load balancer OCI.
- Task 3: Integra il load balancer OCI con una distribuzione HYOK basata su gateway API OCI esistente.
- Task 4: Integra il load balancer OCI con una distribuzione HYOK esistente senza il gateway API OCI.
- Task 5: esaminare tutte le architetture HYOK di OCI e Thales CipherTrust Manager per rendere Thales CipherTrust Manager altamente disponibile.
Task 1: rivedere le architetture HYOK Manager OCI e Thales CipherTrust esistenti
Prima di introdurre OCI Load Balancer nell'architettura, è essenziale rivedere le distribuzioni HYOK di OCI e Thales CipherTrust Manager esistenti. Nelle implementazioni precedenti, abbiamo trattato due modelli principali:
Questa sezione riassumerà brevemente queste due progettazioni ed evidenzierà i loro punti di forza e limiti, ponendo le basi per l'introduzione di OCI Load Balancer per colmare il divario di disponibilità.
Entrambe le architetture si basavano sul clustering di più responsabili Thales CipherTrust per fornire recuperabilità, ma mancavano di un'alta disponibilità accurata a livello di rete a causa dell'assenza del supporto nativo dell'indirizzo VIP in Thales CipherTrust Manager. Ogni implementazione ha gestito in modo efficace la gestione delle chiavi, ma ha introdotto potenziali singoli punti di errore dal punto di vista dell'instradamento della rete e dell'accessibilità dei servizi.
Prima di iniziare, assicurarsi di disporre dei seguenti elementi:
-
Due o più istanze di Thales CipherTrust Manager distribuite in domini di disponibilità o di errore diversi (e in cluster). Per ulteriori informazioni, vedere Impostare due appliance Thales CipherTrust Cloud Key Manager in OCI, creare un cluster tra di esse e configurarne una come autorità di certificazione.
-
Una VCN con subnet appropriate (privata o pubblica, a seconda dell'architettura). È qui che posizionerai il load balancer OCI.
-
Certificati (se si utilizza l'interruzione SSL nel load balancer OCI). Questo è qualcosa che spiegheremo in questo tutorial.
Task 2: Creare un load balancer OCI
Per ottenere l'alta disponibilità per Thales CipherTrust Manager a livello di rete, introduciamo OCI Load Balancer nell'architettura. Il load balancer OCI sarà un singolo punto di accesso resiliente che distribuisce in modo intelligente le richieste in entrata nei nodi Thales CipherTrust Manager in cluster.
Questo task fornirà un load balancer OCI che si basa su più istanze di Thales CipherTrust Manager. Potrai configurare set backend, controlli dello stato, interruzione SSL (se applicabile) e regole del listener personalizzate in base alla distribuzione HYOK, indipendentemente dal fatto che tu stia utilizzando o meno il gateway API OCI.
Questa impostazione del load balancer OCI garantisce che il servizio di gestione delle chiavi rimanga raggiungibile anche se uno dei nodi Thales CipherTrust Manager non è più disponibile, migliorando in modo significativo l'affidabilità e la tolleranza agli errori dell'integrazione della gestione delle chiavi esterne con OCI.
-
Eseguire il login a OCI Console, andare a Networking e fare clic su Load balancer.
-
Fare clic su Crea load balancer.
-
Immettere le informazioni riportate di seguito.
- Nome: immettere un nome descrittivo, ad esempio
Load_Balancer_for_CCKM
. - Tipo: selezionare privato o pubblico, a seconda del caso d'uso.
- VCN e subnet: selezionare la VCN e le subnet in cui verrà distribuito il load balancer OCI nel compartimento destro.
- Fare clic su Avanti.
- Criterio: selezionare Roubin ponderato.
- Lasciare vuoto il campo Seleziona server backend, verranno configurati in un secondo momento.
- Criterio di controllo dello stato: selezionare HTTP con la porta
80
per ora, questa operazione verrà modificata in un secondo momento.
- Nome set backend: immettere un nome descrittivo, ad esempio
CTM_Appliances
. - Fare clic su Avanti.
- Nome listener: immettere un nome descrittivo, ad esempio
LISTENER
. - Tipo e porta di traffico del listener: TCP e porta
80
, verranno modificati in seguito. - Fare clic su Avanti.
- Lasciare tutte le impostazioni di log predefinite.
- Fare clic su Avanti.
- Nome: immettere un nome descrittivo, ad esempio
-
Rivedere le informazioni e fare clic su Sottometti.
-
Tenere presente che verrà creato il load balancer OCI. Dopo alcuni minuti, verrà visualizzato Attivo.
-
Fare clic su Ascoltatori per rivedere il listener che è necessario modificare.
-
Fare clic su Set backend per esaminare il set backend che sarà necessario modificare. Tenere presente inoltre che lo stato viene visualizzato come Incompleto. Questo perché è ancora necessario aggiungere i server backend di Thales CipherTrust Manager al set.
-
Prima di configurare il listener e il set backend con SSL, è necessario aggiungere un certificato. Per aggiungere, andare a Certificati e cifrature e fare clic su Aggiungi certificato.
-
Assicurarsi di avere creato un certificato e una chiave privata firmati validi per il load balancer OCI.
Per creare una richiesta di firma certificato (CSR, Certificate Signing Request) e utilizzare il manager Thales CipherTrust per firmare il certificato con la relativa CA locale, vedere Creare un CSR sia per le appliance CCKM Thales che per la firma da parte della CA.
-
Inoltre, assicurarsi di disporre della CA radice (bundle ready).
-
In Aggiungi certificato immettere le seguenti informazioni.
- Nome certificato: immettere un nome descrittivo, ad esempio
LB-CTM-CERT
. - Selezionare Incolla certificato SSL.
- Certificato SSL: incollare il certificato SSL firmato.
- Selezionare Specifica certificato CA.
- Selezionare Incolla certificato CA.
- Certificato CA: incollare il certificato CA (bundle).
- Selezionare Specify Private Key.
- Selezionare Incolla chiave anonima.
- Chiave privata: incollare la chiave private.
- Fare clic su Aggiungi certificato.
- Nome certificato: immettere un nome descrittivo, ad esempio
-
Si noti che la richiesta di lavoro sottomessa è accettata e si fa clic su Visualizza tutte le richieste di lavoro.
-
Si noti che la richiesta è riuscita.
-
Andare a Certificati e cifrature e notare che il certificato viene aggiunto.
-
Andare a Set backend, fare clic sui tre punti per aprire il menu del set backend creato, quindi fare clic su Modifica.
-
In Modifica set backend immettere le informazioni riportate di seguito.
- Selezionare Usa SSL per abilitare SSL.
- Risorsa del certificato: selezionare Certificato gestito dal load balancer.
- Selezionare il nome del certificato.
- Fare clic su Salva modifiche
-
Fare clic su Chiudi.
-
Andare a Listeners, fare clic sui tre punti per aprire il menu del set backend creato, quindi fare clic su Modifica.
-
In Modifica listener immettere le informazioni riportate di seguito.
- Protocollo: selezionare TCP.
- Porta: selezionare 443.
- Selezionare Usa SSL.
- Risorsa del certificato: selezionare Certificato gestito dal load balancer.
- Selezionare Nome certificato.
- Fare clic su Salva modifiche
-
Fare clic su Chiudi.
-
Tenere presente che il listener sta ascoltando la porta TCP
443
. -
Passare a Set backend e tenere presente che lo stato è ancora incompleto. Questo perché non è stato aggiunto alcun server come backend al set.
-
Fare clic sui tre punti per aprire il menu del set backend creato, quindi fare clic su Aggiorna controllo stato.
-
In Aggiorna controllo stato, immettere le seguenti informazioni.
- Protocollo: selezionare TCP.
- Porta: selezionare 443.
- Fare clic su Salva modifiche
-
Fare clic su Chiudi.
-
Fare clic sul set backend creato in precedenza.
-
Fare clic su Backend, quindi su Aggiungi backend.
-
In Aggiungi backend immettere le informazioni riportate di seguito.
- Tipo backend: selezionare Indirizzi IP.
- Aggiungere i backend seguenti (indirizzi IP dei CTM):
- CTM 1 (MS)
- Indirizzo IP: immettere
10.111.10.32
. - Porta: selezionare 443.
- Peso: selezionare 1.
- Indirizzo IP: immettere
- CTM 2 (ABBREVIAZIONE)
- Indirizzo IP: immettere
10.222.10.111
. - Porta: selezionare 443.
- Peso: selezionare 2.
- Indirizzo IP: immettere
- CTM 1 (MS)
- Fare clic su Aggiungi.
-
Tenere presente che lo stato verrà visualizzato come Critico. L'esecuzione del controllo dello stato sui server Thales CipherTrust Manager potrebbe richiedere un minuto.
-
Tenere presente che ora l'integrità viene modificata in OK. A questo punto, tornare alla panoramica del set backend.
-
Tenere presente che anche lo stato generale del set backend è OK. Ora, tornare alla panoramica del load balancer OCI.
-
Tenere presente che il load balancer OCI è attivo, che lo stato generale è OK e che il load balancer ha un indirizzo IP.
Assicurarsi di creare un record DNS per il load balancer. Abbiamo creato un record nel listener DNS privato all'interno della VCN OCI.
Task 3: Integra il load balancer OCI in una distribuzione HYOK basata su gateway API OCI esistente
In questo task, integreremo il load balancer OCI nella distribuzione HYOK basata su gateway API OCI esistente, garantendo un'architettura trasparente e ad alta disponibilità.
In questa architettura, combiniamo i punti di forza del gateway API OCI e del load balancer OCI per migliorare l'affidabilità e la sicurezza dell'integrazione HYOK OCI con Thales CipherTrust Manager.
OCI API Gateway continua a fungere da punto di accesso sicuro rivolto al pubblico, applicando criteri di autenticazione, autorizzazione e instradamento. Dietro di esso, OCI Load Balancer distribuisce le richieste su più nodi CipherTrust Manager, garantendo alta disponibilità e tolleranza agli errori a livello di rete.
Questa progettazione a più livelli mantiene un modello di accesso sicuro tramite il gateway API OCI. Risolve la mancanza di supporto per gli indirizzi VIP nativi in Thales CipherTrust Manager introducendo un backend resiliente tramite OCI Load Balancer.
-
Passare al gateway API OCI creato nella seguente esercitazione: Impostare una chiave OCI Hold Your Own Key utilizzando Thales CipherTrust Manager con OCI API Gateway.
-
Passare a Distribuzioni e fare clic su Distribuzione.
-
Fare clic su Modifica.
-
Fare clic su Cicli.
-
Si noti che l'URL punta al nome FQDN
ctm1.oci-thales.lab
, ovvero il nome CTM AMS. -
Modificare l'URL in modo che indichi ora il nome FQDN
lb-ctm.oci-thales.lab
, il load balancer OCI appena creato, quindi fare clic su Successivo e assicurarsi di salvare le modifiche.
L'illustrazione seguente mostra il flusso di traffico end-to-end con il gateway API OCI e il load balancer OCI integrati nell'architettura.
Task 4: Integra il load balancer OCI in una distribuzione HYOK esistente ma senza gateway API OCI
In questo task verrà descritto come configurare e utilizzare OCI Load Balancer come unico punto di accesso per Thales CipherTrust Manager in una distribuzione HYOK OCI, consentendo un'architettura pulita, performante e ad alta disponibilità.
In questa architettura, semplifichiamo la distribuzione rimuovendo il gateway API OCI e posizionando il load balancer OCI direttamente di fronte al cluster di Thales CipherTrust Manager. Questo approccio è ideale per le integrazioni private in cui non è richiesto l'accesso pubblico e l'obiettivo è garantire l'alta disponibilità all'interno di una rete interna sicura.
Instradando le richieste tramite il load balancer OCI, possiamo distribuire il traffico su più nodi Thales CipherTrust Manager mantenendo al contempo la resilienza delle sessioni e le funzionalità di failover, anche in caso di errore di un nodo o di un dominio di disponibilità. Questa impostazione risolve la limitazione chiave della mancanza di supporto di indirizzi VIP nativi di Thales CipherTrust Manager, senza la complessità aggiuntiva dei criteri e dei flussi di autenticazione del gateway API OCI.
Seguire i task elencati nella seguente esercitazione: Impostare una chiave di blocco OCI utilizzando Thales CipherTrust Manager senza il gateway API OCI. Ora, tuttavia, tutti gli indirizzi IP CTM1 (AMS) sono stati modificati nell'indirizzo IP del load balancer.
- Applicazione risorsa delle applicazioni OCI Integration.
- Nome host dell'URL dell'endpoint del vault esterno CTM1. Questa modifica verrà sincronizzata anche con (ASH) CTM2 quando il CTM si trova in un cluster.
- Endpoint privato OCI (il servizio di gestione delle chiavi esterne OCI lo utilizzerà).
Questo è il flusso di integrazione dettagliato per OCI con l'integrazione Thales CipherTrust Manager (HYOK) con solo il load balancer OCI nel percorso.
L'illustrazione seguente mostra il flusso di traffico end-to-end con solo il load balancer OCI integrato nell'architettura.
Task 5: esaminare tutte le architetture HYOK di OCI e Thales CipherTrust Manager per rendere il responsabile di Thales CipherTrust altamente disponibile
Non esiste un approccio completo alla distribuzione di Thales CipherTrust Manager for Hold Your Own Key (HYOK) in OCI. Sono disponibili diverse opzioni di architettura per ottenere una distribuzione resiliente e ad alta disponibilità a seconda della topologia di rete, dei requisiti di sicurezza e dell'infrastruttura disponibile, sia basata sul cloud che on-premise.
Questa sezione fornisce una panoramica consolidata di tutti i modelli di architettura supportati per l'integrazione di Thales CipherTrust Manager con OCI HYOK, con particolare attenzione all'alta disponibilità. Queste includono combinazioni di:
- Implementazioni di data center singoli o doppi.
- Uso del gateway API OCI.
- Uso del load balancer OCI.
- Uso di load balancer in hosting on-premise o di data center, sia con che senza alta disponibilità.
Ogni architettura offre vantaggi e compromessi in termini di complessità, funzionalità di failover e controllo. Che tu stia eseguendo un'impostazione completamente cloud nativa, operando in ambienti ibridi o sfruttando i load balancer legacy nei tuoi data center, esiste un modello adatto.
Le architetture coperte includono:
N. architettura | Descrizione |
---|---|
1 | CTM in un unico data center: impostazione di base senza gateway API OCI o load balancer OCI |
2 | CTM in un unico data center con OCI API Gateway: accesso esterno, nessuna HA |
3 | CTM in due data center con OCI API Gateway e OCI Load Balancer - soluzione HA completa |
4 | CTM in due data center con OCI API Gateway e load balancer on-premise (no HA) – resilienza parziale |
5 | CTM in due data center con OCI API Gateway e load balancer (HA) on-premise: HA gestito esternamente |
6 | CTM in un unico data center con OCI API Gateway e load balancer on-premise (no HA): failover limitato |
7 | CTM in due data center con solo OCI Load Balancer: accesso interno, HA completo a livello di rete senza OCI API Gateway |
Questa panoramica ti aiuterà a confrontare e selezionare l'architettura che meglio si allinea ai tuoi requisiti tecnici e operativi.
-
Architettura 1: l'illustrazione seguente mostra il flusso di traffico end-to-end senza gateway API OCI e nessun bilanciamento del carico integrato nell'architettura.
-
Architettura 2: la seguente figura mostra il flusso di traffico end-to-end con solo il gateway API OCI e nessun bilanciamento del carico integrato nell'architettura.
-
Architettura 3: la seguente figura mostra il flusso di traffico end-to-end con il gateway API OCI e il load balancer OCI integrati nell'architettura.
-
Architettura 4, 5 e 6: l'illustrazione seguente mostra il flusso di traffico end-to-end con OCI API Gateway e i load balancer on-premise integrati nell'architettura.
-
Architettura 7: l'illustrazione seguente mostra il flusso di traffico end-to-end con solo il load balancer OCI integrato nell'architettura.
Conclusione
Garantire l'alta disponibilità per Thales CipherTrust Manager in una distribuzione HYOK di Oracle Cloud Infrastructure (OCI) è essenziale per mantenere un accesso sicuro e ininterrotto alle chiavi di cifratura gestite dal cliente. Sebbene il clustering dei manager CipherTrust fornisca recuperabilità, non è sufficiente soddisfare i requisiti di alta disponibilità a livello di rete.
Questa esercitazione ha dimostrato in che modo il load balancer OCI può colmare tale lacuna, sia in combinazione con il gateway API OCI sia come soluzione standalone per l'accesso interno. Abbiamo anche esaminato diversi modelli di architettura del mondo reale, tra cui modelli ibridi che sfruttano i load balancer on-premise, aiutandoti a scegliere il design in linea con la tua strategia di infrastruttura e gli obiettivi di disponibilità.
Integrando attentamente i servizi di rete di OCI con Thales CipherTrust Manager, le organizzazioni possono creare una soluzione di gestione delle chiavi esterna resiliente e sicura che supporta la conformità e la continuità operativa di livello aziendale.
Conferme
- Autore: Iwan Hoogendoorn (Cloud Networking Black Belt)
Altre risorse di apprendimento
Esplora altri laboratori su docs.oracle.com/learn o accedi a più contenuti di formazione gratuiti sul canale YouTube di Oracle Learning. Inoltre, visitare education.oracle.com/learning-explorer per diventare Oracle Learning Explorer.
Per la documentazione del prodotto, visitare Oracle Help Center.
Enable OCI HYOK with Thales CipherTrust Manager Using OCI Load Balancer for High Availability
G40053-01
Copyright ©2025, Oracle and/or its affiliates.