Progettazione di una gerarchia CA

Con CA privata AWS, puoi creare una gerarchia di autorità di certificazione con un massimo di cinque livelli. La CA principale, nella parte superiore di una struttura gerarchica, può avere un numero qualsiasi di rami. La CA principale può avere fino a quattro livelli di subordinato CAs su ogni ramo. È inoltre possibile creare più gerarchie, ognuna con una propria root.

Una gerarchia CA ben progettata offre i seguenti vantaggi:

• Controlli granulari di sicurezza appropriati per ogni CA

• Divisione delle attività amministrative per migliorare il bilanciamento del carico e la sicurezza

• Utilizzo di CAs con trust limitato e revocabile per le operazioni quotidiane

• Periodi di validità e limiti del percorso del certificato

Il diagramma seguente illustra una semplice gerarchia CA a tre livelli.

Ogni CA nell'albero è supportata da un certificato X.509 v3 con autorità di firma (simboleggiata dall'icona). pen-and-paper Ciò significa che possono firmare altri certificati a loro subordinati. CAs Quando una CA firma il certificato di una CA di livello inferiore, conferisce un'autorità limitata e revocabile al certificato firmato. La CA principale nel livello 1 firma i certificati emessi da una CA subordinata di alto livello nel livello 2. QuestiCAs, a loro volta, firmano i certificati di CAs livello 3 utilizzati dagli amministratori PKI (dell'infrastruttura a chiave pubblica) che gestiscono i certificati delle entità finali.

La protezione in una gerarchia CA deve essere configurata per essere più forte nella parte superiore della struttura. Questa disposizione protegge il certificato emesso da una CA root e la relativa chiave privata. La CA principale fissa l'affidabilità per tutti i certificati subordinati CAs e per quelli di entità finale sottostanti. Sebbene la compromissione di un certificato dell'entità finale possa causare danni localizzati, la compromissione della radice distrugge la fiducia nell'insieme. PKI I certificati root e di alto livello CAs vengono utilizzati solo di rado (in genere per firmare altri certificati CA). Di conseguenza, essi sono strettamente sottoposti a audit e sottoposti a audit per garantire un minor rischio di compromissione. Ai livelli inferiori della gerarchia, la protezione è meno restrittiva. Questo approccio consente le attività amministrative di routine di emissione e revoca dei certificati di entità finale per utenti, host di computer e servizi software.

Nota

L'utilizzo di una CA root per firmare un certificato subordinata è un evento raro che si verifica solo in una manciata di circostanze:

• Quando viene creato PKI

• Quando un'autorità di certificazione di alto livello deve essere sostituita

• Quando è necessario configurare un risponditore dell'elenco di revoca dei certificati (CRL) o del protocollo Online Certificate Status Protocol (OCSP)

Root e altri protocolli di alto livello CAs richiedono processi operativi e protocolli di controllo degli accessi altamente sicuri.

Convalida dei certificati dell'entità finale

I certificati di entità finale traggono la loro fiducia da un percorso di certificazione che conduce attraverso il subordinato a una CA principale. CAs Quando un browser Web o un altro client viene presentato con un certificato di entità finale, tenta di costruire una catena di attendibilità. Ad esempio, è possibile verificare che il nome distinto dell'emittente del certificato e il nome distinto dell'oggetto corrispondano ai campi corrispondenti del certificato emesso da una CA emittente. La corrispondenza continuerebbe a ogni livello successivo della gerarchia fino a quando il client raggiunge una root attendibile contenuta nel relativo archivio attendibili.

Il trust store è una libreria di dati affidabili CAs contenuta nel browser o nel sistema operativo. Per un account privatoPKI, il reparto IT dell'organizzazione deve assicurarsi che ogni browser o sistema abbia precedentemente aggiunto la CA root privata al relativo trust store. In caso contrario, il percorso di certificazione non può essere convalidato, causando errori client.

Il diagramma successivo mostra il percorso di convalida seguito da un browser quando viene presentato con un certificato X.509 dell'entità finale. Si noti che il certificato dell'entità finale manca dell'autorità di firma e serve solo per autenticare l'entità che lo possiede.

Il browser ispeziona il certificato dell'entità finale. Il browser rileva che il certificato offre una firma da CA subordinata (livello 3) come credenziale di attendibilità. I certificati per il subordinato CAs devono essere inclusi nello stesso PEM file. In alternativa, possono anche trovarsi in un file separato che contiene i certificati che compongono la catena di attendibilità. Dopo aver trovato questi, il browser controlla il certificato di CA subordinata (livello 3) e rileva che questo offre una firma da CA subordinata (livello 2). A sua volta, la CA subordinata (livello 2) offre una firma dalla CA root (livello 1) come credenziale di attendibilità. Se il browser trova una copia del certificato emesso da una CA root privata preinstallato nel relativo archivio attendibilità, convalida il certificato dell'entità finale come attendibile.

In genere, il browser confronta inoltre ogni certificato con un elenco di revoca dei certificati ()CRL. Un certificato scaduto, revocato o configurato in modo errato viene rifiutato e la convalida non riesce.

Pianificazione della struttura di una gerarchia CA

In generale, la gerarchia CA dovrebbe riflettere la struttura dell'organizzazione. Cerca di stabilire una lunghezza del percorso (ovvero il numero di livelli di CA) non superiore a quella necessaria per delegare i ruoli amministrativi e di sicurezza. Aggiungere una CA alla gerarchia significa aumentare il numero di certificati nel percorso di certificazione, aumentando così il tempo di convalida. Mantenendo al minimo la lunghezza del percorso si riduce anche il numero di certificati inviati dal server al client durante la convalida di un certificato di entità finale.

In teoria, una CA root, priva di pathLenConstraintparametri, può autorizzare livelli illimitati di subordinati. CAs Una CA subordinata può avere tanti subordinati CAs figlio quanti ne sono consentiti dalla configurazione interna. CA privata AWS le gerarchie gestite supportano percorsi di certificazione CA fino a cinque livelli di profondità.

Le strutture CA ben progettate hanno diversi vantaggi:

• Controlli amministrativi separati per diverse unità organizzative

• La capacità di delegare l'accesso ai subordinati CAs

• Una struttura gerarchica che protegge i livelli superiori CAs con controlli di sicurezza aggiuntivi

Due strutture CA comuni realizzano tutto questo:

• Due livelli CA: CA root e CA subordinata

  Si tratta della struttura CA più semplice che consente di separare i criteri di amministrazione, controllo e sicurezza per la CA root e una CA subordinata. È possibile mantenere controlli e criteri restrittivi per la CA principale, consentendo al contempo un accesso più permissivo per la CA subordinata. Quest'ultimo viene utilizzato per l'emissione in blocco di certificati di entità finale.

• Tre livelli CA: CA root e due livelli di CA subordinata

  Analogamente a quanto sopra, questa struttura aggiunge un ulteriore livello CA per separare ulteriormente la CA root dalle operazioni CA di basso livello. Il livello CA intermedio viene utilizzato solo per firmare subordinati CAs che emettono certificati di entità finale.

Le strutture CA meno comuni sono le seguenti:

• Quattro o più livelli CA

  Sebbene meno comuni delle gerarchie a tre livelli, le gerarchie CA con quattro o più livelli sono possibili e potrebbero essere necessarie per consentire la delega amministrativa.

• Un livello CA: solo CA root

  Questa struttura è comunemente utilizzata per lo sviluppo e il test quando non è richiesta una catena completa di attendibilità. Utilizzata nella produzione, è atipica. Inoltre, viola la best practice di mantenere politiche di sicurezza separate per la CA principale e quella che emette i certificati di entità finale. CAs

  Tuttavia, se state già emettendo certificati direttamente da una CA principale, potete migrare a. CA privata AWS In questo modo si ottengono vantaggi in termini di sicurezza e controllo rispetto all'utilizzo di una CA root gestita con Open SSL o altro software.

Esempio di servizio privato PKI per un produttore

In questo esempio, un'ipotetica azienda tecnologica produce due prodotti Internet delle cose (IoT), una lampadina intelligente e un tostapane intelligente. Durante la produzione, per ogni dispositivo viene rilasciato un certificato di entità finale in modo che possa comunicare in modo sicuro via Internet con il produttore. L'azienda protegge PKI inoltre la propria infrastruttura informatica, tra cui il sito Web interno e vari servizi informatici ospitati autonomamente che gestiscono le operazioni finanziarie e commerciali.

Di conseguenza, la gerarchia CA modella da vicino questi aspetti amministrativi e operativi del business.

Questa gerarchia contiene tre radici, una per le operazioni interne e due per le operazioni esterne (una CA root per ogni linea di prodotto). Illustra inoltre la lunghezza del percorso di certificazione multiplo, con due livelli di CA per le operazioni interne e tre livelli per le operazioni esterne.

L'uso di livelli CA root separati CAs e subordinati aggiuntivi sul lato delle operazioni esterne è una decisione progettuale che soddisfa le esigenze aziendali e di sicurezza. Con più alberi CA, PKI è a prova di futuro contro riorganizzazioni aziendali, cessioni o acquisizioni. Quando si verificano modifiche, un'intera gerarchia CA root può spostarsi in modo pulito con la divisione che protegge. Inoltre, con due livelli di CA subordinata, le radici CAs sono molto isolate dal livello 3, responsabile della firma in blocco dei certificati di migliaia o CAs milioni di articoli fabbricati.

Sul lato interno, le operazioni aziendali sul Web e sul computer interno completano una gerarchia a due livelli. Questi livelli consentono agli amministratori Web e ai tecnici operativi di gestire l'emissione di certificati in modo indipendente per i propri domini di lavoro. La suddivisione in domini funzionali distinti è una best practice di PKI sicurezza e protegge ciascuno da un compromesso che potrebbe influire sull'altro. Gli amministratori Web rilasciano certificati di entità finale da utilizzare dai browser Web in tutta l'azienda, autenticando e crittografando le comunicazioni sul sito web interno. I tecnici operativi emettono certificati delle entità finali che autenticano gli host del data center e i servizi informatici reciprocamente. Questo sistema aiuta a proteggere i dati sensibili crittografandoli su. LAN

Impostazione dei vincoli di lunghezza sul percorso di certificazione

La struttura di una gerarchia di CA è definita e applicata dall'estensione dei vincoli di base contenuta in ogni certificato. L'estensione definisce due vincoli:

• cA— Se il certificato definisce una CA. Se questo valore è false (impostazione predefinita), il certificato è un certificato di entità finale.

• pathLenConstraint— Il numero massimo di subordinati di livello inferiore CAs che possono esistere in una catena di fiducia valida. Il certificato dell'entità finale non viene conteggiato perché non è un certificato CA.

Un certificato emesso da una CA root richiede la massima flessibilità e non include un vincolo di lunghezza del percorso. Ciò consente alla radice di definire un percorso di certificazione di qualsiasi lunghezza.

Nota

CA privata AWS limita il percorso di certificazione a cinque livelli.

pathLenConstraintI valori dei subordinati CAs sono uguali o superiori a zero, a seconda della posizione nella gerarchia e delle feature desiderate. Ad esempio, in una gerarchia con treCAs, non viene specificato alcun vincolo di percorso per la CA principale. La prima CA subordinata ha una lunghezza di percorso pari a 1 e può quindi firmare un elemento secondario. CAs Ciascuno di questi bambini CAs deve necessariamente avere un pathLenConstraint valore pari a zero. Ciò significa che possono firmare certificati di entità finale ma non possono emettere certificati emessi da una CA aggiuntivi. Limitare il potere di crearne di nuovi CAs è un importante controllo di sicurezza.

Il diagramma seguente illustra questa propagazione di autorità limitata lungo la gerarchia.

In questa gerarchia a quattro livelli, la root non è vincolata (come sempre). Ma la prima CA subordinata ha un pathLenConstraint valore pari a 2, il che impedisce al figlio di CAs approfondire più di due livelli. Di conseguenza, per un percorso di certificazione valido, il valore del vincolo deve diminuire a zero nei due livelli successivi. Se un browser Web rileva un certificato di entità finale di questo ramo con una lunghezza di percorso maggiore di quattro, la convalida non riesce. Tale certificato potrebbe essere il risultato di una CA creata accidentalmente, di una CA configurata in modo errato o di un'emissione non autorizzata.

Gestione della lunghezza del percorso con modelli

CA privata AWS fornisce modelli per l'emissione di certificati root, subordinati e di entità finale. Questi modelli incapsulano le best practice per i valori dei vincoli di base, inclusa la lunghezza del percorso. I modelli includono:

• ootCACertificateR/V1

• ubordinateCACertificateS_0/V1 PathLen

• S_1/V1 ubordinateCACertificate PathLen

• ubordinateCACertificateS_ 2/V1 PathLen

• ubordinateCACertificateS_3/V1 PathLen

• EndEntityCertificate/V1

IssueCertificateAPIRestituirà un errore se si tenta di creare una CA con una lunghezza del percorso maggiore o uguale alla lunghezza del percorso del certificato CA di emissione.

Per ulteriori informazioni sui modelli di certificato, consulta Informazioni sui modelli di certificato.

Automatizzazione della configurazione della gerarchia CA con AWS CloudFormation

Una volta definito un progetto per la gerarchia delle CA, è possibile testarlo e metterlo in produzione utilizzando un modello. AWS CloudFormation Per un esempio di tale modello, vedere Dichiarazione di una gerarchia CA privata nella Guida per l'utente AWS CloudFormation .