Questa pagina è stata tradotta dall'API Cloud Translation.

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 (CA Service). Questa pagina descrive come progettare l'architettura di gestione dei certificati.

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

Progettare l'architettura di gestione dei certificati

Quando progetti una strategia di gestione dei certificati aziendali, devi considerare i principali casi d'uso della tua organizzazione e l'intero ciclo di vita dei tuoi certificati. Queste decisioni influiscono su costi, overhead operativo e facilità di implementazione di funzionalità di gestione dei certificati come emissione, revoca e rotazione.

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

Scegli 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 quale tipo di certificato scegliere. — Valuta quale tipo di certificato scegliere (fai clic per ingrandire).

Ecco alcuni link utili alla documentazione 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 la tua 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 errori di configurazione. Sebbene CA Service sia un servizio regionale, una CA radice in una regione può firmare CA subordinate situate in altre regioni.

Segui queste best practice nella gerarchia dei servizi CA come mostrato nel diagramma:

Isola la CA radice nel suo progetto Google Cloud per firmare la CA emittente.
Crea CA emittenti in 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 del software (sviluppo, produzione, test) o a un caso d'uso specifico.
Configura Certificate Manager in modo che utilizzi un pool di CA emittenti che possono emettere certificati attendibili privatamente per le risorse supportate.

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

Utilizzare una copertura completa dei nomi host

Ti consigliamo di assicurarti che i tuoi 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 e un'esperienza utente negativa.

Evita di utilizzare un unico 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 caratteri jolly per includere i sottodomini o i servizi nel certificato fin dall'inizio. Ad esempio, un certificato con caratteri jolly per *.myorg.example.com protegge solo il primo livello di sottodominio, ma non i livelli di sottodominio più profondi, ad esempio sub.subdomain.myorg.example.com.

Utilizzare i certificati gestiti da Google

Per una gestione efficiente dei certificati pubblici e per facilità d'uso, ti consigliamo di utilizzare i certificati gestiti da Google. Questo approccio riduce significativamente l'overhead 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 serviziGoogle Cloud . I certificati gestiti da Google sono validi per 90 giorni e la procedura di rinnovo inizia circa un mese prima della scadenza.

Scalare e migliorare il rendimento del certificato

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

Applica il deployment decentralizzato per Certificate Manager

Utilizza Certificate Manager in base al progetto e alla 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 diverse regioni e riducendo al minimo l'impatto nell'improbabile caso di un'interruzione del servizio a livello di regione.

Inoltre, poiché le quote e i limiti vengono applicati a livello di progetto Google Cloud , 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 certificati con chiavi ECDSA

Questa sezione esamina perché consigliamo ECDSA anziché RSA come best practice per le chiavi di firma dei certificati.

Quale tipo di chiave utilizzare

ECDSA P-256 è il tipo di chiave consigliato 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.

Ecco alcuni dei possibili motivi per utilizzare altri tipi di chiavi del 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 chiavi di dimensioni maggiori o di tipi particolari, puoi utilizzare le chiavi ECDSA P-384, RSA-2048, RSA-3072 e RSA-4096.

Perché scegliere ECDSA anziché 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 offre 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 offre un livello di sicurezza simile a una chiave RSA-3072.
Una chiave ECDSA a 384 bit offre un livello di sicurezza maggiore rispetto a qualsiasi dimensione della chiave RSA ampiamente supportata.

Vantaggi principali di ECDSA:

Prestazioni: le operazioni di firma ECDSA sono significativamente meno intensive dal punto di vista computazionale rispetto alle operazioni RSA, fornendo un livello di sicurezza equivalente. Ciò riduce il carico della CPU e la latenza, il che è fondamentale per i sistemi ad alta velocità effettiva 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 il seguente criterio dell'organizzazione personalizzato per imporre l'utilizzo di tipi di chiavi specifici nei tuoi certificati. Ciò è applicabile solo ai certificati gestiti da Google da CA Service (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 di CA per le CA emittenti. Un pool di CA è una raccolta di più CA con una policy di emissione dei certificati comune e una policy 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 certificato in entrata tra tutte le CA abilitate all'interno del pool. Ciò migliora il rendimento senza influire sul carico di lavoro o sulle modifiche lato client.

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

Utilizzare le mappe di certificati

Per garantire una scalabilità ottimale, ti consigliamo di utilizzare mappe dei certificati con risorse supportate. Le mappe di certificati sono progettate per essere scalabili, 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 ti 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 ciascun approccio:

Funzionalità	Autorizzazione 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 della rete	Il bilanciatore del carico deve essere completamente accessibile tramite 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.	Supportato.

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 questo processo utilizzando le offerte di gestione del ciclo di vita dei certificati (CLM) che preferisci. In questo modo si riducono gli errori, i tempi di inattività e si garantisce 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 tua CA.
Invia la CSR e la chiave privata alla CA, quindi recupera il nuovo certificato.
Carica il nuovo certificato in Gestore certificati in una mappa dei certificati appropriata.
- Se i nomi di dominio nel nuovo certificato corrispondono a un certificato in scadenza, utilizza il metodo UpdateCertificate nella risorsa del certificato esistente.
- Se il nuovo certificato ha nomi di dominio diversi, utilizza prima il metodo CreateCertificateRequest con i nuovi file PEM (privacy-enhanced mail) per crearlo. Dopodiché, utilizza il metodo UpdateCertificateMapEntry 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à.

Applica controlli dell'accesso appropriati

Ti consigliamo di prendere in considerazione i principi del privilegio minimo e della separazione dei compiti durante la configurazione dei controlli dell'accesso. Le sezioni seguenti spiegano questi consigli in modo più dettagliato.

Applica il principio del privilegio minimo

Quando assegni le autorizzazioni per gestire i certificati, tieni presente 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 CA Service per ridurre 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 tal fine, 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:

Gestisci e mantieni la tua infrastruttura di certificati, ad esempio il provisioning della CA.
Configura i modelli di certificato.
Gestisci l'elenco revoche certificati (CRL) e i risponditori OCSP (Online Certificate Status Protocol).
Implementa criteri di sicurezza per la tua CA.

Per i progetti che ospitano una CA radice, evita di assegnare ruoli di base come Proprietario (roles/owner), Editor (roles/editor) e Amministratore di 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 necessità con giustificazione e approvazioni dopo l'installazione e la configurazione della CA radice.

Assicurati che il gruppo richiedente 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 mansioni:

Utente tipo	Descrizione	Ruoli IAM
Amministratori dei certificati	Configura e gestisci l'infrastruttura di CA e certificati.	Proprietario di Certificate Manager (`roles/certificatemanager.owner`), Amministratore servizio CA (`roles/privateca.admin`)
Richiedente certificati	Richiedi certificati per i carichi di lavoro.	Certificate Authority Service Certificate Requester (`roles/privateca.certificateRequester`)
Workload (service account di automazione)	Utilizzato dai workload o nelle pipeline per richiedere certificati.	Certificate Authority Service Workload Certificate Requester (`roles/privateca.workloadCertificateRequester`)
Ingegneri della sicurezza o proprietari dell'infrastruttura a chiave pubblica	Gestisci le norme, la revoca e il ciclo di vita dei certificati.	Responsabile operativo servizio CA (`roles/privateca.caManager`), CA Service Certificate Manager (`roles/privateca.certificateManager`)
Ingegneri DevOps o di piattaforma	Gestire il deployment dei certificati sui bilanciatori del carico e altro ancora.	Editor gestore certificati (`roles/certificatemanager.editor`)
Revisore o conformità	Monitora i certificati e il loro utilizzo.	Visualizzatore Certificate Manager (`roles/certificatemanager.viewer`), Auditor del servizio Certificate Authority (`roles/privateca.auditor`)

Utilizzare l'autorizzazione DNS per progetto per i deployment multiregionali e multicloud

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 del software (SDLC).

La suddivisione delle autorizzazioni DNS contribuisce a 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 alcun impatto negativo sui sistemi di produzione o su altri progetti in corso.

Utilizzare i record CAA per proteggere i domini

I record CAA (Certification Authority Authorization) sono un meccanismo di sicurezza nel Domain Name System (DNS). I record CAA forniscono ai proprietari di domini il controllo completo per configurare le autorità di certificazione (CA) pubbliche che possono emettere certificati per i loro domini. Questo controllo è importante per prevenire l'emissione non autorizzata di certificati. Con CAA in vigore, 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 la registrazione degli audit log 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à amministrative per tutti i servizi, incluso Certificate Manager, in una posizione centralizzata.

In questo modo, il team responsabile della sicurezza o il revisore può esaminare tutta l'attività relativa alla creazione o alla modifica delle risorse di Certificate Manager e CA Service in un unico posto. Per ulteriori informazioni sulla configurazione dei log aggregati, vedi Aggrega e archivia i log dell'organizzazione.

Monitorare l'utilizzo e la scadenza dei certificati

Ti consigliamo di configurare avvisi basati sui log per eventi importanti di Certificate Manager, come l'utilizzo della CA radice, la scadenza del certificato e l'eliminazione del certificato. Questi avvisi ti aiutano a dare la priorità alle operazioni, ad esempio un'elevata percentuale di errori di creazione dei certificati, e possono attivare un processo a valle per richiedere un nuovo certificato o aumentare la quota.

Configura i seguenti avvisi e criteri di 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 National Institute of Standards and Technology (NIST) 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 delle carte.

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