Controllo sicurezza: protezione dei dati

  • Articolo

La protezione dei dati copre il controllo della protezione dei dati inattivi, in transito e tramite meccanismi di accesso autorizzati, tra cui individuazione, classificazione, protezione e monitoraggio degli asset di dati sensibili usando il controllo di accesso, la crittografia, la gestione delle chiavi e la gestione dei certificati. |

DP-1: Individuare, classificare ed etichettare i dati sensibili

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
3.2, 3.7, 3.13 RA-2, SC-28 A3.2

Principio di sicurezza: stabilire e gestire un inventario dei dati sensibili, in base all'ambito di dati sensibili definito. Usare gli strumenti per individuare, classificare ed etichettare i dati sensibili nell'ambito.

Linee guida di Azure: usare strumenti come Microsoft Purview, che combina le soluzioni di conformità di Azure Purview e Microsoft 365 e Azure SQL Individuazione dati e classificazione per analizzare in modo centralizzato, classificare ed etichettare i dati sensibili che risiedono in Azure, in locale, In Microsoft 365 e in altre posizioni.

Implementazione di Azure e contesto aggiuntivo:

Linee guida AWS: replicare i dati da diverse origini a un bucket di archiviazione S3 e usare AWS Macie per analizzare, classificare ed etichettare i dati sensibili archiviati nel bucket. AWS Macie può rilevare dati sensibili, ad esempio credenziali di sicurezza, informazioni finanziarie, dati PHI e PII o altro modello di dati in base alle regole di identificatore dei dati personalizzate.

È anche possibile usare il connettore di analisi multi-cloud di Azure Purview per analizzare, classificare ed etichettare i dati sensibili che risiedono in un bucket di archiviazione S3.

Nota: è anche possibile usare soluzioni aziendali di terze parti dal marketplace AWS allo scopo della classificazione e dell'etichettatura dei dati.

Implementazione di AWS e contesto aggiuntivo:

Linee guida GCP: usare strumenti come Google Cloud Data Loss Prevention per analizzare, classificare ed etichettare i dati sensibili che risiedono negli ambienti GCP e locali.

Inoltre, usare Google Cloud Data Catalog per usare i risultati di un'analisi DLP (Cloud Data Loss Prevention) per identificare i dati sensibili con i modelli di tag definiti.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DP-2: Monitorare anomalie e minacce che prendono di mira dati sensibili

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
3.13 AC-4, SI-4 A3.2

Principio di sicurezza: monitorare le anomalie relative ai dati sensibili, ad esempio il trasferimento non autorizzato dei dati alle posizioni esterne alla visibilità e al controllo dell'organizzazione. Ciò comporta in genere il monitoraggio di attività anomale (trasferimenti insoliti o di grandi quantità di dati) che potrebbero indicare un'esfiltrazione di dati non autorizzata.

Linee guida di Azure: usare Azure Information Protection (AIP) per monitorare i dati classificati ed etichettati.

Usare Microsoft Defender per archiviazione, Microsoft Defender per SQL, Microsoft Defender per i database relazionali open source e Microsoft Defender per Cosmos DB per avvisare il trasferimento anomalo di informazioni che potrebbero indicare trasferimenti non autorizzati di dati sensibili Informazioni.

Nota: se necessario per la conformità della prevenzione della perdita dei dati (DLP), è possibile usare una soluzione DLP basata su host da Azure Marketplace o una soluzione DLP di Microsoft 365 per applicare controlli detective e/o preventivi per impedire l'esfiltrazione dei dati.

Implementazione di Azure e contesto aggiuntivo:

Linee guida di AWS: usare AWS Macie per monitorare i dati classificati ed etichettati e usare GuardDuty per rilevare attività anomale in alcune risorse (S3, EC2 o Kubernetes o risorse IAM). I risultati e gli avvisi possono essere elaborati, analizzati e monitorati usando EventBridge e inoltrati a Microsoft Sentinel o hub di sicurezza per l'aggregazione e il rilevamento degli eventi imprevisti.

È anche possibile connettere gli account AWS a Microsoft Defender per i controlli di conformità, la sicurezza dei contenitori e le funzionalità di sicurezza degli endpoint.

Nota: se necessario per la conformità della prevenzione della perdita di dati (DLP), è possibile usare una soluzione DLP basata su host da AWS Marketplace.

Implementazione di AWS e contesto aggiuntivo:

Linee guida GCP: usare Il Centro comandi di Google Cloud Security/Rilevamento minacce eventi/Rilevamento anomalie per avvisare il trasferimento anomalo di informazioni che potrebbero indicare trasferimenti non autorizzati di informazioni sensibili.

È anche possibile connettere gli account GCP a Microsoft Defender per cloud per i controlli di conformità, la sicurezza dei contenitori e le funzionalità di sicurezza degli endpoint.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DP-3: Crittografare i dati sensibili in movimento

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
3.10 SC-8 3.5, 3.6, 4.1

Principio di sicurezza: proteggere i dati in transito contro attacchi "fuori banda" (ad esempio l'acquisizione del traffico) usando la crittografia per garantire che gli utenti malintenzionati non possano leggere o modificare facilmente i dati.

Impostare il limite di rete e l'ambito del servizio in cui i dati nella crittografia di transito sono obbligatori all'interno e all'esterno della rete. Sebbene ciò sia facoltativo per il traffico nelle reti private, è fondamentale per il traffico nelle reti esterne e pubbliche.

Linee guida di Azure: applicare il trasferimento sicuro nei servizi, ad esempio Archiviazione di Azure, in cui è incorporata una funzionalità nativa di crittografia dei dati in transito.

Applicare HTTPS per carichi di lavoro e servizi dell'applicazione Web assicurandosi che tutti i client che si connettono alle risorse di Azure usino la sicurezza del livello di trasporto (TLS) v1.2 o versione successiva. Per la gestione remota delle macchine virtuali, usare SSH (per Linux) o RDP/TLS (per Windows) anziché un protocollo non crittografato.

Per la gestione remota delle macchine virtuali di Azure, usare SSH (per Linux) o RDP/TLS (per Windows) anziché un protocollo non crittografato. Per il trasferimento sicuro dei file, usare il servizio SFTP/FTPS nel BLOB di archiviazione di Azure, servizio app app e app per le funzioni anziché usare il servizio FTP normale.

Nota: i dati nella crittografia di transito sono abilitati per tutto il traffico di Azure in viaggio tra i data center di Azure. TLS v1.2 o versione successiva è abilitato nella maggior parte dei servizi di Azure per impostazione predefinita. Alcuni servizi come Archiviazione di Azure e gateway applicazione possono applicare TLS v1.2 o versioni successive sul lato server.

Implementazione di Azure e contesto aggiuntivo:

Linee guida PER AWS: applicare il trasferimento sicuro nei servizi, ad esempio Amazon S3, RDS e CloudFront, in cui è incorporata una funzionalità nativa di crittografia dei dati in transito.

Applicare HTTPS (ad esempio in AWS Elastic Load Balancer) per applicazioni Web e servizi del carico di lavoro (sul lato server o sul lato client o su entrambi) assicurandosi che tutti i client che si connettono alle risorse AWS usino TLS v1.2 o versioni successive.

Per la gestione remota di istanze EC2, usare SSH (per Linux) o RDP/TLS (per Windows) anziché un protocollo non crittografato. Per il trasferimento sicuro dei file, usare il servizio AWS Transfer SFTP o FTPS anziché un normale servizio FTP.

Nota: tutto il traffico di rete tra i data center AWS viene crittografato in modo trasparente a livello fisico. Tutto il traffico all'interno di un VPC e tra vpn peered tra aree geografiche viene crittografato in modo trasparente al livello di rete quando si usano tipi di istanza di Amazon EC2 supportati. TLS v1.2 o versione successiva è abilitato nella maggior parte dei servizi AWS per impostazione predefinita. Alcuni servizi come AWS Load Balancer possono applicare TLS v1.2 o versioni successive sul lato server.

Implementazione di AWS e contesto aggiuntivo:

Linee guida GCP: applicare il trasferimento sicuro nei servizi come Google Cloud Storage, in cui è incorporata una funzionalità di crittografia nativa dei dati in transito.

Applicare HTTPS per i carichi di lavoro e i servizi dell'applicazione Web che garantiscono che tutti i client che si connettono alle risorse GCP usino la sicurezza del livello di trasporto (TLS) v1.2 o versione successiva.

Per la gestione remota, Google Cloud Compute Engine usa SSH (per Linux) o RDP/TLS (per Windows) anziché un protocollo non crittografato. Per il trasferimento sicuro dei file, usare il servizio SFTP/FTPS nei servizi come Google Cloud Big Query o Cloud App Engine anziché un normale servizio FTP.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DP-4: Abilitare la crittografia dei dati inattivi per impostazione predefinita

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
3.11 SC-28 3.4, 3.5

Principio di sicurezza: per integrare i controlli di accesso, i dati inattivi devono essere protetti da attacchi "fuori banda" (ad esempio l'accesso all'archiviazione sottostante) usando la crittografia. Ciò consente di garantire che gli utenti malintenzionati non possano leggere o modificare facilmente i dati.

Linee guida di Azure: molti servizi di Azure dispongono di dati inattivi abilitati per impostazione predefinita al livello dell'infrastruttura usando una chiave gestita dal servizio. Queste chiavi gestite dal servizio vengono generate per conto del cliente e ruotate automaticamente ogni due anni.

Se tecnicamente fattibile e non abilitato per impostazione predefinita, è possibile abilitare i dati inattivi crittografia nei servizi di Azure o nelle macchine virtuali a livello di archiviazione, a livello di file o a livello di database.

Implementazione di Azure e contesto aggiuntivo:

Linee guida AWS: molti servizi AWS dispongono di dati inattivi abilitati per impostazione predefinita nel livello infrastruttura/piattaforma usando una chiave master del cliente gestita da AWS. Queste chiavi master del cliente gestite da AWS vengono generate per conto del cliente e ruotate automaticamente ogni tre anni.

Se tecnicamente fattibile e non abilitato per impostazione predefinita, è possibile abilitare i dati inattivi crittografia nei servizi AWS o nelle macchine virtuali a livello di archiviazione, a livello di file o a livello di database.

Implementazione di AWS e contesto aggiuntivo:

Linee guida GCP: molti prodotti e servizi Google Cloud dispongono di dati inattivi abilitati per impostazione predefinita al livello di infrastruttura usando una chiave gestita dal servizio. Queste chiavi gestite dal servizio vengono generate per conto del cliente e ruotate automaticamente.

Se tecnicamente fattibile e non abilitato per impostazione predefinita, è possibile abilitare i dati inattivi crittografia nei servizi GCP o nelle macchine virtuali a livello di archiviazione, a livello di file o a livello di database.

Nota: per ulteriori dettagli, vedere il documento "Granularità della crittografia per i servizi Google Cloud".

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DP-5: Usare l'opzione della chiave gestita dal cliente nella crittografia dei dati inattivi quando necessario

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
3.11 SC-12, SC-28 3.4, 3.5, 3.6

Principio di sicurezza: se necessario per la conformità alle normative, definire il caso d'uso e l'ambito del servizio in cui è necessaria l'opzione chiave gestita dal cliente. Abilitare e implementare i dati inattivi tramite chiavi gestite dal cliente nei servizi.

Linee guida di Azure: Azure offre anche un'opzione di crittografia usando chiavi gestite autonomamente (chiavi gestite dal cliente) per la maggior parte dei servizi.

Azure Key Vault Standard, Premium e Managed HSM sono integrati in modo nativo con molti servizi di Azure per i casi d'uso delle chiavi gestite dal cliente. È possibile usare Azure Key Vault per generare la chiave o portare chiavi personalizzate.

Tuttavia, l'uso dell'opzione chiave gestita dal cliente richiede ulteriori sforzi operativi per gestire il ciclo di vita della chiave. Ciò può includere la generazione di chiavi di crittografia, la rotazione, la revoca e il controllo di accesso e così via.

Implementazione di Azure e contesto aggiuntivo:

Linee guida AWS: AWS offre anche un'opzione di crittografia usando chiavi gestite autonomamente (chiave master del cliente gestita dal cliente archiviata in AWS Key Management Service) per determinati servizi.

AWS Key Management Service (KMS) è integrato in modo nativo con molti servizi AWS per i casi d'uso delle chiavi master dei clienti gestiti dal cliente. È possibile usare AWS Key Management Service (KMS) per generare le chiavi master o portare chiavi personalizzate.

Tuttavia, l'uso dell'opzione chiave gestita dal cliente richiede ulteriori sforzi operativi per gestire il ciclo di vita della chiave. Ciò può includere la generazione di chiavi di crittografia, la rotazione, la revoca e il controllo di accesso e così via.

Implementazione di AWS e contesto aggiuntivo:

Linee guida GCP: Google Cloud offre un'opzione di crittografia usando chiavi gestite autonomamente (chiavi gestite dal cliente) per la maggior parte dei servizi.

Google Cloud Key Management Service (Cloud KMS) è integrato in modo nativo con molti servizi GCP per le chiavi di crittografia gestite dal cliente. Queste chiavi possono essere create e gestite usando Cloud KMS e vengono archiviate le chiavi come chiavi software, in un cluster HSM o esternamente. È possibile usare Cloud KMS per generare la chiave o fornire chiavi personalizzate (chiavi di crittografia fornite dal cliente).

Tuttavia, l'uso dell'opzione chiave gestita dal cliente richiede ulteriori sforzi operativi per gestire il ciclo di vita della chiave. Ciò può includere la generazione di chiavi di crittografia, la rotazione, la revoca e il controllo di accesso e così via.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DP-6: Usare un processo di gestione delle chiavi sicure

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
N/D IA-5, SC-12, SC-28 3,6

Principio di sicurezza: documentare e implementare uno standard di gestione della chiave crittografica aziendale, processi e procedure per controllare il ciclo di vita della chiave. Quando è necessario usare la chiave gestita dal cliente nei servizi, usare un servizio di insieme di credenziali delle chiavi protetto per la generazione di chiavi, la distribuzione e l'archiviazione. Ruotare e revocare le chiavi in base alla pianificazione definita e quando si verifica un ritiro o un compromesso chiave.

Linee guida di Azure: usare Azure Key Vault per creare e controllare il ciclo di vita delle chiavi di crittografia, tra cui la generazione di chiavi, la distribuzione e l'archiviazione. Ruotare e revocare le chiavi in Azure Key Vault e il servizio in base alla pianificazione definita e quando si verifica un ritiro o un compromesso chiave. Richiedere un determinato tipo di crittografia e dimensioni minime della chiave durante la generazione di chiavi.

Quando è necessario usare la chiave gestita dal cliente (CMK) nei servizi o nelle applicazioni del carico di lavoro, assicurarsi di seguire le procedure consigliate:

  • Usare una gerarchia di chiavi per generare una chiave di crittografia dei dati separata con la chiave di crittografia delle chiavi (KEK) nell'insieme di credenziali delle chiavi.
  • Assicurarsi che le chiavi siano registrate con Azure Key Vault e implementate tramite ID chiave in ogni servizio o applicazione.

Per ottimizzare la durata del materiale chiave e la portabilità, portare la propria chiave (BYOK) ai servizi (ad esempio, importando chiavi protette da HSM dalle macchine hardware locali in Azure Key Vault). Seguire le linee guida consigliate per eseguire la generazione e il trasferimento delle chiavi.

Nota: fare riferimento alle informazioni seguenti per il livello FIPS 140-2 per i tipi di Key Vault di Azure e il livello di conformità/convalida FIPS.

  • Chiavi protette dal software negli insiemi di credenziali (SKU Standard di & Premium): FIPS 140-2 Level 1
  • Chiavi protette da HSM negli insiemi di credenziali (SKU Premium): FIPS 140-2 Livello 2
  • Chiavi protette da HSM in Managed HSM: FIPS 140-2 Level 3

Azure Key Vault Premium usa un'infrastruttura HSM condivisa nel back-end. Azure Key Vault Managed HSM usa endpoint di servizio riservati dedicati con un modulo di protezione hardware dedicato per quando è necessario un livello superiore di sicurezza delle chiavi.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: usare IL Servizio gestione chiavi DI AWS (KMS) per creare e controllare il ciclo di vita delle chiavi di crittografia, tra cui la generazione di chiavi, la distribuzione e l'archiviazione. Ruotare e revocare le chiavi nel servizio di gestione delle chiavi in base alla pianificazione definita e quando si verifica un ritiro o un compromesso chiave.

Quando è necessario usare la chiave master del cliente gestita dal cliente nei servizi o nelle applicazioni del carico di lavoro, assicurarsi di seguire le procedure consigliate:

  • Usare una gerarchia di chiavi per generare una chiave di crittografia dei dati separata (DEK) con la chiave di crittografia delle chiavi (KEK) nel servizio di gestione delle chiavi.
  • Assicurarsi che le chiavi siano registrate con il servizio di gestione delle chiavi e implementano tramite i criteri IAM in ogni servizio o applicazione.

Per ottimizzare la durata e la portabilità del materiale chiave, portare la propria chiave (BYOK) ai servizi (ad esempio, importando chiavi protette da HSM dalle macchine hardware locali in kmS o Cloud HSM). Seguire le linee guida consigliate per eseguire la generazione e il trasferimento delle chiavi.

Nota: AWS KMS usa l'infrastruttura HSM condivisa nel back-end. Usare AWS KMS Custom Key Store supportato da AWS CloudHSM quando è necessario gestire il proprio archivio chiavi e i moduli di protezione hardware dedicati (ad esempio, requisiti di conformità alle normative per un livello superiore di sicurezza delle chiavi) per generare e archiviare le chiavi di crittografia.

Nota: fare riferimento alle informazioni seguenti per il livello FIPS 140-2 per il livello di conformità FIPS in AWS KMS e CloudHSM:

  • Impostazione predefinita di AWS KMS: FIPS 140-2 Livello 2 convalidata
  • AWS KMS con CloudHSM: FIPS 140-2 Level 3 (per determinati servizi) convalidati
  • AWS CloudHSM: FIPS 140-2 Livello 3 convalidato

Nota: per la gestione dei segreti(credenziali, password, chiavi API e così via), usare AWS Secrets Manager.

Implementazione di AWS e contesto aggiuntivo:

Linee guida GCP: usare Cloud Key Management Service (Cloud KMS) per creare e gestire i cicli di vita delle chiavi di crittografia nei servizi Google Cloud compatibili e nelle applicazioni del carico di lavoro. Ruotare e revocare le chiavi nel Servizio di gestione delle chiavi cloud e il servizio in base alla pianificazione definita e quando si verifica un ritiro o un compromesso chiave.

Usare il servizio Cloud HSM di Google per fornire chiavi supportate dall'hardware a Cloud KMS (Servizio gestione chiavi) Offre la possibilità di gestire e usare chiavi crittografiche personalizzate durante la protezione da moduli di sicurezza hardware completamente gestiti (HSM).

Il servizio Cloud HSM usa le macchine virtuali, che sono FIPS 140-2 Livello 3 convalidato e sono sempre in esecuzione in modalità FIPS. FIPS 140-2 Livello 3 convalidato e sono sempre in esecuzione in modalità FIPS. Lo standard FIPS specifica gli algoritmi di crittografia e la generazione di numeri casuali usati dai moduli di protezione hardware.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DP-7: Usare un processo di gestione dei certificati sicuro

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
N/D IA-5, SC-12, SC-17 3,6

Principio di sicurezza: documentare e implementare uno standard di gestione dei certificati aziendale, processi e procedure che includono il controllo del ciclo di vita del certificato e i criteri di certificato (se è necessaria un'infrastruttura chiave pubblica).

Assicurarsi che i certificati usati dai servizi critici dell'organizzazione vengano inventariati, monitorati, monitorati e rinnovati tempestivamente usando il meccanismo automatizzato per evitare interruzioni del servizio.

Linee guida di Azure: usare Azure Key Vault per creare e controllare il ciclo di vita del certificato, tra cui la creazione/importazione, la rotazione, la revoca, l'archiviazione e l'eliminazione del certificato. Assicurarsi che la generazione del certificato segue lo standard definito senza usare proprietà non sicure, ad esempio dimensioni di chiavi insufficienti, periodo di validità eccessivamente lungo, crittografia non sicura e così via. Configurare la rotazione automatica del certificato in Azure Key Vault e i servizi di Azure supportati in base alla pianificazione definita e alla scadenza di un certificato. Se la rotazione automatica non è supportata nell'applicazione front-end, usare una rotazione manuale in Azure Key Vault.

Evitare di usare un certificato autofirmato e un certificato con caratteri jolly nei servizi critici a causa della garanzia di sicurezza limitata. È invece possibile creare certificati firmati pubblici in Azure Key Vault. Le autorità di certificazione seguenti sono i provider partner attualmente integrati con Azure Key Vault.

  • DigiCert: Azure Key Vault offre certificati OV TLS/SSL con DigiCert.
  • GlobalSign: Azure Key Vault offre certificati OV TLS/SSL con GlobalSign.

Nota: usare solo l'autorità di certificazione approvata e assicurarsi che i certificati radice/intermedi noti rilasciati da questi CA siano disabilitati.

Implementazione di Azure e contesto aggiuntivo:

Indicazioni su AWS: usare AWS Certificate Manager (ACM) per creare e controllare il ciclo di vita del certificato, tra cui creazione/importazione, rotazione, revoca, archiviazione ed eliminazione del certificato. Assicurarsi che la generazione del certificato segue lo standard definito senza usare proprietà non sicure, ad esempio dimensioni di chiavi insufficienti, periodo di validità eccessivamente lungo, crittografia non sicura e così via. Configurare la rotazione automatica del certificato in ACM e i servizi AWS supportati in base alla pianificazione definita e alla scadenza di un certificato. Se la rotazione automatica non è supportata nell'applicazione front-end, usare la rotazione manuale in ACM. Nel frattempo, è consigliabile tenere sempre traccia dello stato di rinnovo del certificato per garantire la validità del certificato.

Evitare di usare un certificato autofirmato e un certificato con caratteri jolly nei servizi critici a causa della garanzia di sicurezza limitata. Creare invece certificati con firma pubblica (firmati dall'autorità di certificazione Amazon) in ACM e distribuirlo a livello di codice nei servizi come CloudFront, Load Balancers, Gateway API e così via. È anche possibile usare ACM per stabilire l'autorità di certificazione privata (CA) per firmare i certificati privati.

Nota: usare solo una CA approvata e assicurarsi che i certificati radice/intermedi di CA noti rilasciati da queste autorità di certificazione siano disabilitati.

Implementazione di AWS e contesto aggiuntivo:

Linee guida GCP: usare Google Cloud Certificate Manager per creare e controllare il ciclo di vita del certificato, tra cui creazione/importazione, rotazione, revoca, archiviazione ed eliminazione del certificato. Assicurarsi che la generazione del certificato segue lo standard definito senza usare proprietà non sicure, ad esempio dimensioni di chiavi insufficienti, periodo di validità eccessivamente lungo, crittografia non sicura e così via. Configurare la rotazione automatica del certificato in Gestione certificati e i servizi GCP supportati in base alla pianificazione definita e alla scadenza di un certificato. Se la rotazione automatica non è supportata nell'applicazione front-end, usare la rotazione manuale in Gestione certificati. Nel frattempo, è consigliabile tenere sempre traccia dello stato di rinnovo del certificato per garantire la validità del certificato.

Evitare di usare un certificato autofirmato e un certificato con caratteri jolly nei servizi critici a causa della garanzia di sicurezza limitata. È invece possibile creare certificati pubblici firmati in Gestione certificati e distribuirlo a livello di codice nei servizi, ad esempio Load Balancer e DNS cloud e così via. È anche possibile usare il servizio autorità di certificazione per stabilire l'autorità di certificazione privata (CA) per firmare i certificati privati.

Nota: è anche possibile usare Google Cloud Secret Manager per archiviare i certificati TLS.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):

DP-8: Garantire la sicurezza del repository di chiavi e certificati

CONTROLLI CIS v8 ID ID R4 NIST SP 800-53 ID PCI-DSS v3.2.1
N/D IA-5, SC-12, SC-17 3,6

Principio di sicurezza: assicurarsi che la sicurezza del servizio dell'insieme di credenziali delle chiavi utilizzata per la gestione del ciclo di vita della chiave crittografica e del certificato. Proteggere il servizio dell'insieme di credenziali delle chiavi tramite il controllo di accesso, la sicurezza di rete, la registrazione e il monitoraggio e il backup per garantire che le chiavi e i certificati siano sempre protetti usando la massima sicurezza.

Linee guida di Azure: proteggere le chiavi e i certificati crittografici grazie alla protezione avanzata del servizio azure Key Vault tramite i controlli seguenti:

  • Implementare il controllo di accesso usando i criteri di controllo degli accessi in base al ruolo in Azure Key Vault Gestito HSM a livello di chiave per garantire che vengano seguiti i privilegi minimi e la separazione dei principi dei compiti. Ad esempio, assicurarsi che la separazione dei compiti sia disponibile per gli utenti che gestiscono le chiavi di crittografia in modo che non abbiano la possibilità di accedere ai dati crittografati e viceversa. Per Azure Key Vault Standard e Premium, creare insiemi di credenziali univoci per applicazioni diverse per garantire che vengano seguiti i privilegi minimi e la separazione dei principi dei compiti.
  • Attivare la registrazione Key Vault di Azure per garantire la registrazione del piano di gestione critico e delle attività del piano dati.
  • Proteggere l'Key Vault di Azure usando collegamento privato e Firewall di Azure per garantire un'esposizione minima del servizio
  • Usare l'identità gestita per accedere alle chiavi archiviate in Azure Key Vault nelle applicazioni del carico di lavoro.
  • Quando si eliminano i dati, assicurarsi che le chiavi non vengano eliminate prima che i dati effettivi, i backup e gli archivi vengano eliminati.
  • Eseguire il backup delle chiavi e dei certificati usando Azure Key Vault. Abilitare la protezione di eliminazione temporanea ed eliminazione per evitare l'eliminazione accidentale delle chiavi. Quando le chiavi devono essere eliminate, è consigliabile disabilitare le chiavi anziché eliminarle per evitare l'eliminazione accidentale delle chiavi e la cancellazione crittografica dei dati.
  • Per i casi d'uso BYOK (Bring Your Own Key), generare chiavi in un HSM locale e importarle per ottimizzare la durata e la portabilità delle chiavi.
  • Non archiviare mai le chiavi in formato testo non crittografato all'esterno dell'Key Vault di Azure. Le chiavi in tutti i servizi dell'insieme di credenziali delle chiavi non sono esportabili per impostazione predefinita.
  • Usare i tipi di chiavi supportati da HSM (RSA-HSM) in Azure Key Vault Premium e Azure Managed HSM per la protezione hardware e i livelli FIPS più forti.

Abilitare Microsoft Defender per Key Vault per la protezione avanzata dalle minacce nativa di Azure per Azure Key Vault, fornendo un livello aggiuntivo di intelligence sulla sicurezza.

Implementazione di Azure e contesto aggiuntivo:

Linee guida per AWS: per la sicurezza delle chiavi di crittografia, proteggere le chiavi grazie alla protezione avanzata del servizio DI GESTIONE delle chiavi AWS tramite i controlli seguenti:

  • Implementare il controllo di accesso usando i criteri chiave (controllo degli accessi a livello di chiave) insieme ai criteri IAM (controllo degli accessi in base all'identità) per garantire che vengano seguiti i privilegi minimi e la separazione dei principi dei compiti. Ad esempio, assicurarsi che la separazione dei compiti sia disponibile per gli utenti che gestiscono le chiavi di crittografia in modo che non abbiano la possibilità di accedere ai dati crittografati e viceversa.
  • Usare i controlli detective, ad esempio CloudTrails, per registrare e tenere traccia dell'utilizzo delle chiavi nel servizio di gestione delle chiavi e avvisare le azioni critiche.
  • Non archiviare mai le chiavi in formato di testo non crittografato all'esterno del servizio di gestione delle chiavi.
  • Quando le chiavi devono essere eliminate, è consigliabile disabilitare le chiavi nel servizio di gestione delle chiavi anziché eliminarle per evitare l'eliminazione accidentale delle chiavi e la cancellazione crittografica dei dati.
  • Quando si eliminano i dati, assicurarsi che le chiavi non vengano eliminate prima che i dati effettivi, i backup e gli archivi vengano eliminati.
  • Per portare la propria chiave (BYOK) usa casi, generare chiavi in un HSM locale e importarle per ottimizzare la durata e la portabilità delle chiavi.

Per la sicurezza dei certificati, proteggere i certificati grazie alla protezione avanzata del servizio AWS Certificate Manager (ACM) tramite i controlli seguenti:

  • Implementare il controllo di accesso usando i criteri a livello di risorsa insieme ai criteri IAM (controllo degli accessi in base all'identità) per garantire che vengano seguiti i privilegi minimi e la separazione dei principi dei compiti. Ad esempio, assicurarsi che la separazione dei compiti sia disponibile per gli account utente: gli account utente che generano certificati sono separati dagli account utente che richiedono solo l'accesso in sola lettura ai certificati.
  • Usare i controlli detective, ad esempio CloudTrails, per registrare e tenere traccia dell'utilizzo dei certificati in ACM e avvisare le azioni critiche.
  • Seguire le linee guida per la sicurezza del Servizio di gestione delle chiavi per proteggere la chiave privata (generata per la richiesta di certificato) usata per l'integrazione del certificato di servizio.

Implementazione di AWS e contesto aggiuntivo:

Indicazioni per GCP: per la sicurezza delle chiavi crittografiche, proteggere le chiavi grazie alla protezione avanzata del servizio di gestione delle chiavi tramite i controlli seguenti:

  • Implementare il controllo di accesso usando i ruoli IAM per garantire che vengano seguiti i privilegi minimi e la separazione dei principi dei compiti. Ad esempio, assicurarsi che la separazione dei compiti sia disponibile per gli utenti che gestiscono le chiavi di crittografia in modo che non abbiano la possibilità di accedere ai dati crittografati e viceversa.
  • Creare un anello chiave separato per ogni progetto che consente di gestire e controllare facilmente l'accesso alle chiavi seguendo le procedure consigliate per privilegi minimi. Rende anche più facile controllare chi può accedere alle chiavi in corrispondenza di quando.
  • Abilitare la rotazione automatica delle chiavi per assicurarsi che le chiavi vengano aggiornate e aggiornate regolarmente. Ciò consente di proteggere da potenziali minacce alla sicurezza, ad esempio attacchi di forza bruta o attori malintenzionati che tentano di ottenere l'accesso alle informazioni sensibili.
  • Configurare un sink del log di controllo per tenere traccia di tutte le attività che si verificano all'interno dell'ambiente del Servizio di gestione delle chiavi GCP.

Per la sicurezza dei certificati, proteggere i certificati grazie alla protezione avanzata del servizio gestione certificati GCP e autorità di certificazione tramite i controlli seguenti:

  • Implementare il controllo di accesso usando i criteri a livello di risorsa insieme ai criteri IAM (controllo degli accessi in base all'identità) per garantire che vengano seguiti i privilegi minimi e la separazione dei principi dei compiti. Ad esempio, assicurarsi che la separazione dei compiti sia disponibile per gli account utente: gli account utente che generano certificati sono separati dagli account utente che richiedono solo l'accesso in sola lettura ai certificati.
  • Usare i controlli detective, ad esempio i log di controllo cloud per registrare e tenere traccia dell'utilizzo dei certificati in Gestione certificati e avvisare le azioni critiche.
  • Secret Manager supporta anche l'archiviazione del certificato TLS. È necessario seguire la procedura di sicurezza simile per implementare i controlli di sicurezza in Secret Manager.

Implementazione di GCP e contesto aggiuntivo:

Stakeholder della sicurezza dei clienti (Altre informazioni):