Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Best practice per Certificate Manager

Questa pagina descrive varie best practice per la configurazione e la gestione dei certificati su Google Cloud utilizzando Certificate Manager e Certificate Authority Service (servizio CA). Questa pagina descrive come progettare l'architettura di gestione dei certificati.

Prima di leggere questa pagina, assicurati di conoscere le pagine di panoramica di Certificate Manager e di Certificate Authority Service.

Progettare l'architettura di gestione dei certificati

Quando progetti una strategia di gestione dei certificati aziendali, devi tenere conto dei casi d'uso chiave della tua organizzazione e dell'intero ciclo di vita dei certificati. Queste decisioni influiscono sul costo, sul sovraccarico operativo e sulla facilità di implementazione delle funzionalità di gestione dei certificati, come l'emissione, la revoca e la rotazione.

Le sezioni seguenti spiegano i nostri consigli per ogni scelta di progettazione.

Scegliere un tipo di certificato

Quando crei un certificato, devi assicurarti di selezionare un tipo di certificato appropriato per il tuo caso d'uso, a seconda dei requisiti dell'applicazione e delle norme di sicurezza della tua organizzazione.

Per analizzare il tipo di certificato più adatto alle tue esigenze, consulta il seguente diagramma di flusso:

Valuta il tipo di certificato da scegliere. — Valuta il tipo di certificato da scegliere (fai clic per ingrandire).

Ecco alcuni link alla documentazione utili per gli argomenti menzionati nel diagramma di flusso:

Semplificare la gerarchia del servizio CA privato

Ti consigliamo di mantenere la gerarchia del servizio CA il più semplice possibile per garantire operazioni e risoluzione dei problemi senza intoppi. Devi archiviare l'autorità di certificazione (CA) radice nel suo progetto Google. La CA radice firma alcune CA intermedie, che a loro volta emettono i certificati finali.

Questa struttura gerarchica piatta migliora la trasparenza, semplifica le procedure di revoca dei certificati e riduce la probabilità di configurazioni errate. Sebbene il servizio CA sia un servizio regionale, una CA radice in una regione può firmare CA subordinate situate in altre regioni.

Segui queste best practice nella gerarchia del servizio CA, come mostrato nel diagramma:

Isola la CA radice nel suo Google Cloud progetto per firmare la CA emittente.
Crea CA emittenti nei pool di CA ospitati in progetti separati. Ospita questi pool in progetti separati e segmentali in base alla posizione geografica (regione), al ciclo di vita dello sviluppo software (sviluppo, produzione, test) o a un caso d'uso specifico.
Configura Certificate Manager in modo che utilizzi un pool di CA emittenti in grado di emettere certificati con attendibilità privata per le risorse supportate.

Progettazione della gerarchia CA consigliata. — Progettazione consigliata per la gerarchia della CA (fai clic per ingrandire).

Utilizzare una copertura completa dei nomi host

Ti consigliamo di assicurarti che i certificati forniscano una copertura sufficiente dei nomi host per tutti i domini e i sottodomini che i tuoi servizi devono proteggere. Una copertura inadeguata dei nomi host può comportare avvisi di sicurezza per gli utenti, interruzioni del servizio ed esperienza utente negativa.

Evita di utilizzare un singolo certificato per più domini. Se il singolo certificato non viene rinnovato o viene eliminato accidentalmente, tutti i domini che copre diventano non protetti. Ti consigliamo di creare certificati distinti per domini diversi.

Se prevedi di aggiungere nuovi sottodomini o servizi in un secondo momento, utilizza i caratteri jolly per includerli nel certificato fin dall'inizio. Ad esempio, un certificato con carattere jolly per *.myorg.example.com protegge solo il primo livello di sottodominio, ma non i livelli di sottodominio più profondi come sub.subdomain.myorg.example.com.

Utilizzare i certificati gestiti da Google

Per una gestione efficiente dei certificati pubblici e per la facilità d'uso, ti consigliamo di utilizzare i certificati gestiti da Google. Questo approccio riduce significativamente il sovraccarico operativo, automatizzando attività come la rotazione dei certificati ed eliminando i rischi associati ai rinnovi manuali.

Inoltre, i certificati gestiti da Google offrono un'integrazione perfetta con altri Google Cloud servizi. Certificate Manager supporta solo la Public Certificate Authority (pki.goog) e la CA Let's Encrypt (letsencrypt.org) per l'emissione di certificati gestiti da Google con attendibilità pubblica. Certificate Manager esegue il provisioning dei certificati gestiti da Google con un periodo di validità di 45 o 90 giorni, a seconda della CA emittente:

I certificati emessi dalla Public CA stanno passando gradualmente da un periodo di validità di 90 giorni a un periodo di validità di 45 giorni. I certificati esistenti di 90 giorni rimangono validi per 90 giorni fino al prossimo rinnovo.
I certificati emessi dalla CA Let's Encrypt hanno un periodo di validità di 90 giorni.

Certificate Manager avvia automaticamente la procedura di rinnovo quando rimane circa un terzo del periodo di validità del certificato. Il rinnovo inizia circa 15 giorni prima della scadenza per i certificati di 45 giorni e circa 30 giorni prima della scadenza per i certificati di 90 giorni.

Scalare e migliorare il rendimento dei certificati

Le sezioni seguenti descrivono le best practice per scalare i certificati e migliorare il rendimento delle azioni correlate ai certificati, come il provisioning e il rinnovo.

Applicare il deployment decentralizzato per Certificate Manager

Utilizza Certificate Manager per progetto e per località, il che significa che i certificati vengono archiviati nello stesso progetto delle risorse associate nella stessa regione. Questa strategia migliora l'affidabilità impedendo il riutilizzo dei certificati in regioni diverse e riducendo al minimo l'impatto nell'improbabile evento di un'interruzione regionale.

Inoltre, poiché le quote e i limiti vengono applicati a livello di Google Cloud progetto, il deployment di Certificate Manager in più progetti aumenta le quote complessive. Questo perché l'utilizzo di una risorsa in un progetto non influisce sulla quota disponibile in un altro progetto.

Utilizzare i certificati con chiavi ECDSA

Questa sezione esamina il motivo per cui consigliamo ECDSA rispetto a RSA come best practice per le chiavi di firma dei certificati.

Quale tipo di chiave utilizzare

ECDSA P-256 è la scelta consigliata per la maggior parte dei certificati TLS perché offre una solida sicurezza crittografica, prestazioni eccellenti per le operazioni di firma e un utilizzo efficiente della larghezza di banda di rete.

Di seguito sono riportati alcuni dei possibili motivi per utilizzare altri tipi di chiavi di certificato:

Se devi supportare client legacy che non supportano i certificati ECDSA, puoi fornire certificati RSA-2048 oltre ai certificati ECDSA P-256.
Se hai requisiti di conformità specifici che richiedono l'utilizzo di dimensioni delle chiavi più grandi o tipi di chiavi particolari, puoi utilizzare le chiavi ECDSA P-384, RSA-2048, RSA-3072 e RSA-4096.

Perché scegliere ECDSA rispetto a RSA

Il vantaggio principale di ECDSA risiede nella sua capacità di fornire un livello di sicurezza crittografica equivalente con chiavi significativamente più piccole rispetto a RSA. Questa efficienza si traduce in vantaggi tangibili in termini di prestazioni e risorse. Una chiave più piccola non implica una sicurezza più debole: ECDSA si basa sul problema del logaritmo discreto della curva ellittica, che fornisce una maggiore sicurezza per unità di chiave e, in alcuni casi, una migliore efficienza computazionale rispetto a RSA.

Ad esempio:

Una chiave ECDSA a 256 bit fornisce un livello di sicurezza simile a una chiave RSA-3072.
Una chiave ECDSA a 384 bit fornisce un livello di sicurezza maggiore rispetto a qualsiasi dimensione di chiave RSA ampiamente supportata.

Vantaggi principali di ECDSA:

Rendimento: le operazioni di firma ECDSA sono significativamente meno intensive dal punto di vista computazionale rispetto alle operazioni RSA che forniscono un livello di sicurezza equivalente. Ciò riduce il carico della CPU e la latenza, il che è fondamentale per i sistemi a velocità effettiva elevata o sensibili alla latenza.
Efficienza: chiavi e firme più piccole richiedono meno larghezza di banda e spazio di archiviazione, il che è particolarmente vantaggioso per gli ambienti con risorse limitate come i dispositivi mobili e IoT.

Puoi creare la seguente policy dell'organizzazione personalizzata per applicare l'utilizzo di tipi di chiavi specifici nei certificati. Questo è applicabile solo ai certificati gestiti da Google del servizio CA (certificati gestiti con attendibilità privata), non ai certificati autogestiti e ai certificati gestiti da Google con attendibilità pubblica.

    name: organizations/ORGANIZATION_ID/customConstraints/custom.restrictAlgorithm \
    resourceTypes: \
    - certificatemanager.googleapis.com/CertificateIssuanceConfig \
    methodTypes: \
    - CREATE \
    - UPDATE \
    condition: "resource.keyAlgorithm == 'ECDSA_P256'" \
    actionType: ALLOW \
    displayName: Allow only ECDSA_P256 in Certificate Issuance configs \
    description: Only ECDSA_P256 certificates are allowed from CA Service.

Utilizzare un pool di CA per emettere certificati da CA private

Ti consigliamo di utilizzare i pool CA per le CA emittenti. Un pool di CA è una raccolta di più CA con un criterio di emissione dei certificati comune e un criterio Identity and Access Management (IAM). L'utilizzo di un pool di CA aumenta il totale delle query effettive al secondo (QPS) bilanciando il carico e distribuendo le richieste di certificati in entrata tra tutte le CA abilitate all'interno del pool. Ciò migliora il rendimento senza influire sul workload o sulle modifiche lato client.

I pool di CA forniscono un singolo endpoint per l'emissione e il recupero dei certificati. Puoi utilizzare i pool CA per ruotare in sicurezza le CA senza causare tempi di inattività dovuti alla scadenza o alla compromissione dei certificati.

Utilizzare le mappe dei certificati

Per garantire una scalabilità ottimale, ti consigliamo di utilizzare le mappe dei certificati con le risorse supportate. Le mappe dei certificati sono progettate per scalare, supportando migliaia di voci di certificati per impostazione predefinita e in grado di gestire milioni di certificati. Se utilizzate dai bilanciatori del carico, le voci della mappa dei certificati hanno la precedenza su altri certificati, come i certificati SSL di Compute Engine.

Le mappe dei certificati consentono anche di configurare la logica di selezione dei certificati. Ad esempio, durante un handshake, se il nome host di un client non corrisponde a nessuna voce nella mappa dei certificati di cui è stato eseguito il provisioning, il bilanciatore del carico restituisce il certificato principale.

Scegliere il tipo di autorizzazione del dominio corretto

Per emettere certificati gestiti da Google, puoi dimostrare la proprietà del dominio utilizzando l'autorizzazione del bilanciatore del carico o l'autorizzazione DNS.

La tabella seguente descrive le considerazioni per ogni approccio:

Funzionalità	Autorizzazione del bilanciatore del carico	Autorizzazione DNS
Complessità della configurazione	Non richiede ulteriori passaggi di configurazione o modifiche alla configurazione DNS.	Richiede la creazione di un'autorizzazione DNS e l'aggiunta del record CNAME corrispondente alla configurazione DNS.
Sicurezza di rete	Il bilanciatore del carico deve essere completamente accessibile tramite il internet sulla porta `443`, inclusa la configurazione DNS per tutti i domini gestiti da un certificato. L'autorizzazione del bilanciatore del carico non funziona con altre configurazioni.	L'autorizzazione DNS funziona con configurazioni molto complesse come porte diverse dalla 443 e livelli CDN davanti al proxy di destinazione.
Velocità di provisioning	Velocità di provisioning più rapida. Puoi eseguire il provisioning dei certificati solo dopo che il bilanciatore del carico è completamente configurato e gestisce il traffico di rete.	Puoi eseguire il provisioning dei certificati in anticipo, prima che il proxy di destinazione sia pronto a gestire il traffico di rete.
Certificati con caratteri jolly	Non supportati.	Supportati.

Automatizzare la rotazione dei certificati autogestiti

A differenza dei certificati gestiti da Google, i certificati autogestiti devono essere sostituiti manualmente prima della scadenza. Ti consigliamo di automatizzare questa procedura utilizzando le offerte di gestione del ciclo di vita dei certificati (CLM) di tua scelta. In questo modo, puoi ridurre gli errori, i tempi di inattività e garantire l'efficienza operativa.

Puoi anche utilizzare le mappe dei certificati per orchestrare una rotazione dei certificati senza interruzioni. Questa procedura include i seguenti passaggi:

Monitora la scadenza dei certificati utilizzando Cloud Monitoring e gli avvisi. Ti consigliamo di creare un avviso per i certificati in scadenza nei prossimi 15-30 giorni.
Genera una richiesta di firma del certificato (CSR) e una chiave privata da inviare alla CA.
Invia la CSR e la chiave privata alla CA, quindi recupera il nuovo certificato.
Carica il nuovo certificato in Certificate Manager in una mappa dei certificati appropriata.
- Se i nomi di dominio nel nuovo certificato corrispondono a un certificato in scadenza, utilizza il UpdateCertificate metodo sulla risorsa del certificato esistente.
- Se il nuovo certificato ha nomi di dominio diversi, utilizza prima il CreateCertificateRequest metodo con i nuovi file PEM (privacy-enhanced mail) per crearlo. Poi, utilizza il UpdateCertificateMapEntry metodo per sostituire il riferimento del vecchio certificato nella mappa dei certificati con quello nuovo.
Importante: devi completare questa procedura in una chiamata API senza causare tempi di inattività.

Applicare controlli dell'accesso appropriati

Ti consigliamo di considerare i principi del privilegio minimo e della separazione dei compiti quando configuri i controlli dell'accesso. Le sezioni seguenti spiegano questi consigli in modo più dettagliato.

Applicare il principio del privilegio minimo

Quando assegni le autorizzazioni per gestire i certificati, considera il principio del privilegio minimo e concedi le autorizzazioni minime necessarie per eseguire un'attività. Ti consigliamo vivamente di evitare di utilizzare i ruoli IAM di base. Assegna invece ruoli predefiniti o personalizzati di Certificate Manager e del servizio CA per mitigare il rischio di incidenti di sicurezza correlati all'accesso con privilegi eccessivi.

Pianificare la separazione dei compiti

Ti consigliamo di mantenere identità e autorizzazioni distinte per gli amministratori dei certificati e per coloro che hanno il ruolo di emittente o richiedente del certificato. A questo scopo, crea gruppi di amministratori e richiedenti separati nella parte superiore della gerarchia delle risorse per i tuoi utenti.

Assicurati che il gruppo di amministratori sia responsabile dell'esecuzione delle seguenti azioni:

Gestire e mantenere l'infrastruttura dei certificati, ad esempio il provisioning della CA.
Configurare i modelli di certificati.
Gestire l'elenco revoche certificati (CRL) e i risponditori del protocollo di stato dei certificati online (OCSP).
Implementare le policy di sicurezza per la CA.

Per i progetti che ospitano una CA radice, evita di assegnare ruoli di base come Proprietario (roles/owner), Editor (roles/editor) e Amministratore del servizio CA (roles/privateca.admin) a qualsiasi utente o gruppo. Questa pratica impedisce l'eliminazione accidentale, la configurazione errata e l'eccessiva esposizione. Utilizza invece Privileged Access Manager (PAM) per l'accesso Just-in-Time (JIT) in base alle esigenze con giustificazione e approvazioni dopo l'installazione e la configurazione della CA radice.

Assicurati che il gruppo di richiedenti sia responsabile delle operazioni quotidiane di elaborazione delle richieste di certificati e di emissione dei certificati in base a modelli predefiniti.

La tabella seguente elenca i ruoli IAM in genere associati a varie funzioni lavorative:

Utente tipo	Descrizione	Ruoli IAM
Amministratori dei certificati	Configurare e gestire l'infrastruttura di CA e certificati.	Proprietario di Certificate Manager (`roles/certificatemanager.owner`), Amministratore del servizio CA (`roles/privateca.admin`)
Richiedente del certificato	Richiedere certificati per i workload.	Richiedente del certificato del servizio Certificate Authority Service (`roles/privateca.certificateRequester`)
Workload (account di servizio di automazione)	Utilizzati dai workload o nelle pipeline per richiedere i certificati.	Richiedente del certificato del workload del servizio CA (`roles/privateca.workloadCertificateRequester`)
Ingegneri della sicurezza o proprietari di PKI	Gestire le policy dei certificati, la revoca e il ciclo di vita.	Responsabile delle operazioni del servizio CA (`roles/privateca.caManager`), Gestore dei certificati del servizio CA (`roles/privateca.certificateManager`)
Ingegneri DevOps o di piattaforma	Gestire il deployment dei certificati sui bilanciatori del carico, e altro ancora.	Editor di Certificate Manager (`roles/certificatemanager.editor`)
Revisore o conformità	Monitorare i certificati e il loro utilizzo.	Visualizzatore di Certificate Manager (`roles/certificatemanager.viewer`), Revisore di Certificate Authority Service (`roles/privateca.auditor`)

Utilizzare l'autorizzazione DNS per progetto per i deployment multiregionali e multi-cloud

Ti consigliamo di utilizzare l' approccio di autorizzazione DNS per progetto per gestire in modo indipendente più autorizzazioni per i progetti in più regioni, più cloud e durante il ciclo di vita dello sviluppo software (SDLC).

La suddivisione delle autorizzazioni DNS consente di garantire che ogni progetto mantenga il proprio insieme distinto di record e autorizzazioni DNS. Questo livello di controllo consente a ogni progetto di gestire autonomamente le proprie configurazioni DNS, senza interferire con le operazioni di altri progetti o esserne influenzato. Ad esempio, un team di sviluppo può sperimentare nuove configurazioni DNS per la propria applicazione specifica senza rischiare di avere un impatto negativo sui sistemi di produzione o su altri progetti in corso.

Utilizzare i record CAA per proteggere i domini

I record di autorizzazione dell'autorità di certificazione (CAA) sono un meccanismo di sicurezza nel DNS (Domain Name System). I record CAA forniscono ai proprietari di domini il controllo completo per configurare le Public Certificate Authority (CA) che possono emettere certificati per i loro domini. Questo controllo è importante per impedire l'emissione non autorizzata di certificati. Con CAA, la superficie di attacco per i certificati fraudolenti viene ridotta, rendendo i siti web più sicuri.

Per i certificati gestiti da Google, ti consigliamo di autorizzare manualmente quanto segue per garantire la massima affidabilità delle richieste di emissione e rinnovo dei certificati:

Cloud Logging, Cloud Monitoring e visibilità

Le sezioni seguenti descrivono le best practice per l'audit logging e per il monitoraggio dell'utilizzo e della scadenza dei certificati.

Abilitare e aggregare l'audit logging

Per monitorare tutte le risorse della tua organizzazione, aggrega gli audit log delle attività di amministrazione per tutti i servizi, incluso Certificate Manager, in una posizione centralizzata.

In questo modo, il team responsabile della sicurezza o il revisore può esaminare tutte le attività correlate alla creazione o alla modifica delle risorse di Certificate Manager e del servizio CA in un'unica posizione. Per saperne di più sulla configurazione dei log aggregati, consulta Aggregare e archiviare i log dell'organizzazione.

Monitorare l'utilizzo e la scadenza dei certificati

Ti consigliamo di configurare avvisi basati sui log per gli eventi importanti di Certificate Manager, come l'utilizzo della CA radice, la scadenza dei certificati e l'eliminazione dei certificati. Questi avvisi ti aiutano a eseguire il triage delle operazioni, ad esempio un'elevata percentuale di errori di creazione dei certificati, e possono attivare una procedura downstream per richiedere un nuovo certificato o aumentare la quota.

Configura i seguenti avvisi e policy dei log per le operazioni correlate ai privilegi:

Requisiti di conformità

In genere, i framework di conformità specificano aspettative e obiettivi di alto livello per la gestione dei certificati anziché per prodotti o configurazioni specifici.

Ad esempio, lo standard PCI DSS (Payment Card Industry Data Security Standard) e il NIST (National Institute of Standards and Technology) richiedono alle organizzazioni di documentare e implementare periodi di rotazione per le chiavi di firma. Inoltre, impongono il monitoraggio continuo dell'inventario e di tutte le chiavi e i certificati di firma attendibili che proteggono i dati dei titolari di carte.

Per saperne di più su come i Google Cloud servizi possono contribuire a soddisfare i vari requisiti del framework di conformità, consulta le seguenti risorse: