Architettura di riferimento Keyfactor EJBCA

Panoramica

Questa architettura di riferimento definisce la progettazione concettuale per l'integrazione di Keyfactor EJBCA Enterprise come autorità di certificazione (CA) di terze parti su Google Distributed Cloud (GDC) air-gapped.

Keyfactor EJBCA Enterprise è una piattaforma di autorità di certificazione scalabile, solida e conforme a FIPS che consente alle organizzazioni di gestire l'infrastruttura a chiave pubblica (PKI) in ambienti eterogenei.

GDC con air gap include un servizio di autorità di certificazione nativo per la gestione automatizzata di chiavi e certificati all'interno del limite del cloud ospitato. Il servizio CA nativo è la soluzione consigliata per la maggior parte dei clienti, in quanto fornisce funzionalità PKI completamente gestite e senza interruzioni all'interno della piattaforma. Tuttavia, le organizzazioni che hanno standardizzato la propria infrastruttura PKI su Keyfactor EJBCA per i carichi di lavoro esistenti al di fuori di GDC potrebbero preferire utilizzare la stessa architettura CA e le stesse policy di gestione coerenti per i carichi di lavoro in esecuzione nei propri ambienti GDC.

Caratteristiche e funzionalità

La soluzione fornisce diversi componenti funzionali di base per la gestione del ciclo di vita dei certificati:

  • Gestione automatizzata del ciclo di vita dei certificati: utilizza l'emittente EJBCA personalizzato all'interno dei cluster standard GDC per automatizzare il provisioning, il rinnovo e la revoca dei certificati server tramite cert-manager.
  • Automazione ACME standardizzata: supporto per il protocollo ACME (Automatic Certificate Management Environment) utilizzando le verifiche DNS-01, che consentono ai servizi della piattaforma di richiedere e rinnovare i certificati senza interruzioni.
  • Integrazione HSM sicura: protezione crittografica diretta di tutte le chiavi private CA all'interno di un modulo di sicurezza hardware (HSM) certificato CC EAL4+, che garantisce che il materiale della chiave non esca mai dal limite di sicurezza fisica. Keyfactor EJBCA Enterprise può utilizzare il proprio HSM gestito o connettersi a un HSM esterno.
  • Compatibilità con air-gapped: flussi di lavoro specializzati per il mirroring dell'immagine dell'emittente cert-manager EJBCA dai registri pubblici al registro Harbor privato GDC, garantendo la disponibilità offline.
  • Isolamento del traffico in uscita: configurazione della rete in uscita utilizzando le risorse GDC Subnet e CloudNATGateway per limitare il traffico API GDC direttamente all'indirizzo IP del server EJBCA esterno.

Principi architetturali

  • Modello di responsabilità condivisa: il cliente gestisce il server EJBCA e l'HSM esterni, di cui è proprietario dell'infrastruttura PKI fisica e delle chiavi radice CA, mentre GDC fornisce i livelli di calcolo, DNS interno e client automatizzati all'interno del cluster standard.
  • Progettazione incentrata sulla sicurezza: rispetta i requisiti di sicurezza air-gapped utilizzando i mirror delle immagini container locali e applicando un gating in uscita rigoroso per ridurre al minimo la superficie di attacco della rete.
  • Standardizzazione del protocollo: assegna la priorità ai protocolli standard (ACME e mTLS REST) per l'interazione con la CA, evitando dipendenze da API proprietarie e consentendo integrazioni client flessibili.

Architettura

L'architettura segue il modello di autorità di certificazione esterna, in cui il server EJBCA e il modulo di sicurezza hardware (HSM) di backup sono ospitati esternamente al di fuori dei limiti fisici di GDC, ma sono accessibili tramite rete. Il server EJBCA può essere sottoposto a deployment esternamente come appliance hardware o software. L'integrazione di base descritta in questa guida richiede solo che il server EJBCA esterno sia raggiungibile tramite un indirizzo IP stabile.

Diagramma dell'architettura di Keyfactor EJBCA.

I componenti chiave di questa architettura includono:

  • Server EJBCA Enterprise: sottoposto a deployment esternamente come appliance hardware o software Keyfactor, che ospita le CA (radice e subordinate) e genera tutto il materiale della chiave CA all'interno di un HSM certificato CC EAL4+.
  • VPC predefinito: VPC in cui vengono sottoposti a deployment i carichi di lavoro utente, nei cluster Kubernetes standard o nelle macchine virtuali.
  • DNS interno GDC: gestisce le zone DNS private locali (utilizzando il nome di dominio privato configurato nelle variabili di ambiente) utilizzate per risolvere le verifiche DNS-01 ACME.
  • Gateway NAT in uscita GDC: indirizza il traffico in uscita dai pod del cluster all'indirizzo IP del server EJBCA esterno.
  • Registro privato Harbor: ospita le immagini container con mirroring (ad esempio l' emittente cert-manager EJBCA) per il deployment air-gapped.

Concetti e tecnologie

Questa sezione descrive in dettaglio i componenti funzionali, le loro responsabilità e il modo in cui comunicano all'interno del sistema.

Infrastruttura e piattaforma

  • Cluster standard GDC: l'ambiente di calcolo principale in cui risiedono i pod dell'emittente EJBCA e di cert-manager, che eseguono l'automazione dei certificati per i carichi di lavoro.
  • Registro Harbor: l'origine attendibile locale e sicura per tutte le immagini container in GDC. Fornisce la scansione automatizzata per garantire che le immagini siano prive di vulnerabilità note prima del deployment.
  • Gateway in uscita GDC: risorse di rete native della piattaforma (subnet e CloudNATGateway) che regolano e proteggono il traffico API in uscita dai pod del cluster al server CA esterno.

Servizi e logica

  • Server EJBCA Enterprise: il motore CA esterno (appliance software o hardware ) responsabile della gestione delle gerarchie CA (radice e subordinate), della convalida delle richieste di certificati, della firma dei certificati e della registrazione dei record di audit.
  • Modulo di sicurezza hardware (HSM): il modulo crittografico conforme a CC EAL4+ che gestisce la generazione delle chiavi e la firma dei certificati, garantendo che le chiavi private CA non vengano mai esposte.
  • DNS interno GDC: gestisce le zone DNS private (ManagedDNSZone e ResourceRecordSet) utilizzate dal servizio di convalida delle verifiche ACME per verificare la proprietà del dominio tramite record TXT temporanei.
  • cert-manager con emittente EJBCA: il controller di certificati nativo di Kubernetes che intercetta le richieste di certificati e utilizza l'emittente EJBCA per tradurle in chiamate API EJBCA sicure.

Flusso di dati e interfacce

  • Protocollo ACME: l'interfaccia API standard per l'emissione automatizzata di certificati server con convalida del dominio utilizzando la verifica DNS-01.
  • API REST EJBCA: l'interfaccia RESTful utilizzata per il bootstrapping amministrativo e le operazioni programmatiche (come la firma e la revoca di CSR).
  • Autenticazione client mTLS: il meccanismo di autenticazione principale per l'integrazione di cert-manager, che verifica l'identità del client tramite mutual TLS utilizzando certificati client dedicati.

Considerazioni

  • Scalabilità e prestazioni:
    • Il server EJBCA esterno deve essere scalato (CPU, memoria, capacità HSM) per gestire le richieste di convalida e firma simultanee, in particolare durante i profili di emissione burst.
    • Le risorse del gateway in uscita GDC devono essere dimensionate per garantire una latenza minima al server CA esterno, evitando timeout durante i cicli di convalida di cert-manager.
  • Sicurezza e conformità:
    • L'isolamento delle chiavi radice CA all'interno di un HSM esterno soddisfa standard di sicurezza e conformità elevati (ad esempio BSI VS-NfD).
    • L'accesso amministrativo a EJBCA deve essere strettamente limitato utilizzando i controlli degli accessi basati sui ruoli (RBAC) e mappato ai numeri di serie dei certificati client univoci.
  • Disponibilità e affidabilità:
    • Per garantire un funzionamento continuo ed evitare un singolo punto di errore, è consigliabile eseguire il deployment ad alta disponibilità del server EJBCA esterno in più zone di disponibilità (utilizzando una configurazione attiva-passiva o in cluster).
    • Il deployment di più repliche del controller cert-manager all'interno di GDC garantisce che l'emissione automatizzata di certificati lato cluster rimanga resiliente.
  • Gestione operativa:
    • Il cliente mantiene la proprietà del server EJBCA, inclusi l'applicazione di patch di sistema, rotazione della chiave HSM e la pubblicazione di CRL.
    • Gli amministratori della piattaforma GDC del cliente sono responsabili della manutenzione del controller cert-manager e dell'emittente EJBCA nel cluster e della gestione dei record DNS privati lato GDC.

Decisione di progettazione

Le scelte architetturali principali per questa soluzione si concentrano sul bilanciamento dell'automazione con i vincoli dell'ambiente air-gapped.

Opzione di integrazione EJBCA

Il servizio di autorità di certificazione nativo di GDC è la soluzione PKI consigliata per la maggior parte dei clienti, in quanto fornisce funzionalità PKI completamente gestite e senza interruzioni all'interno degli ambienti GDC con air gap. Tuttavia, per le organizzazioni che hanno già standardizzato la propria infrastruttura PKI su Keyfactor EJBCA per i carichi di lavoro al di fuori di GDC, l'integrazione del server CA esterno esistente viene offerta come opzione di attivazione. In questo modo, possono riutilizzare i modelli PKI, le policy di sicurezza e i modelli operativi stabiliti senza riprogettare la gerarchia di attendibilità o migrare i flussi di lavoro principali.

Opzioni di convalida delle verifiche ACME

Sono supportati completamente i protocolli di convalida delle verifiche ACME HTTP-01 e DNS-01. Sebbene questa guida all'architettura evidenzi la verifica DNS-01 utilizzando il DNS interno di GDC (ideale per ambienti privati isolati che non possono supportare il traffico HTTP pubblico in entrata), i clienti possono selezionare uno dei due metodi di convalida in base alla topologia di rete, alle policy di sicurezza e ai requisiti dei carichi di lavoro specifici.

Consigli per il canale amministrativo mTLS

L'utilizzo di mutual TLS (mTLS) è consigliato come metodo di autenticazione solido per cert-manager e i client di integrazione. mTLS fornisce una verifica crittografica altamente sicura dell'identità del client utilizzando i certificati client, anche se il cliente può scegliere di configurare altri meccanismi di autenticazione supportati dalla propria istanza EJBCA in base alle policy di sicurezza aziendali.

Ipotesi e limitazioni

Ipotesi

  • Il server EJBCA esterno è sottoposto a deployment, configurato e raggiungibile tramite un indirizzo IP stabile.
  • Il server EJBCA è preconfigurato con le CA radice e subordinate necessarie, insieme ai profili di entità finali appropriati.
  • È disponibile un meccanismo sicuro (ad esempio un nodo bastion o un flusso di lavoro di trasferimento offline) per pubblicare l'immagine container dell'emittente EJBCA nel registro Harbor GDC.
  • I cluster Kubernetes standard all'interno di GDC hanno cert-manager preinstallato o configurato per il funzionamento.

Limitazioni

  • Manutenzione HSM ed EJBCA esterni: il control plane GDC non gestisce il server EJBCA esterno o l'HSM di backup; le operazioni del ciclo di vita (backup, upgrade, rotazioni delle chiavi) vengono gestite dal team operativo PKI del cliente.
  • Vincolo di convalida DNSSEC: poiché viene utilizzato il DNS interno privato, la convalida DNSSEC deve essere disattivata lato server nella configurazione ACME per evitare errori di risoluzione per i domini privati locali.
  • Dipendenza dalla connettività in uscita: i servizi di emissione automatizzata di certificati dipendono dalla disponibilità e dalla latenza del link di rete tra il rack GDC e il server EJBCA esterno.