Monitorare le operazioni di un cluster di base di AKS per un PCI-DSS 3.2.1 (parte 7 di 9)

Questo articolo descrive le considerazioni relative a un cluster servizio Azure Kubernetes (AKS) che esegue un carico di lavoro in base allo standard Pci-DSS 3.2.1 di Payment Card Industry Data Security Standard (PCI-DSS 3.2.1).

Questo articolo fa parte di una serie. Leggere l'introduzione.

Monitorare e testare regolarmente le reti

Requisito 10—Tenere traccia e monitorare tutti gli accessi alle risorse di rete e ai dati di titolari di schede

Supporto per le funzionalità dell'AKS

Azure offre la funzionalità Informazioni dettagliate contenitore che monitora i contenitori, inclusi i cluster di AKS. Per maggiori informazioni, consultare la Panoramica delle informazioni dettagliate sui contenitori.

AKS fornisce log di controllo a più livelli che possono essere utili per proteggere il sistema e i dati in modo proattivo. I log attività forniscono informazioni sulle operazioni correlate alla gestione di account e segreti, alla gestione delle impostazioni di diagnostica, alla gestione del server e ad altre operazioni di accesso alle risorse. Tutti i log vengono registrati con data, ora, identità e altre informazioni dettagliate. È anche possibile accedere a tutti i record cronologici di tutte le chiamate API effettuate nel cluster di AKS. I log includono informazioni sul chiamante, sull'ora in cui è stata effettuata la chiamata e sull'origine in cui è stata avviata la chiamata. Per maggiori informazioni, consultare la sezione Log del pianto di controllo/delle risorse di AKS.

RBAC (controllo degli accessi in base al ruolo) può essere usato per gestire i criteri di accesso alle risorse come procedura standard in Azure.

Tutti i log devono essere archiviati in un account di archiviazione di proprietà del cliente o nei log di Monitoraggio di Azure. In questo modo, è possibile generare rapidamente informazioni dettagliate da un volume elevato di dati. Tutti i log vengono conservati con almeno tre copie in un'area. È possibile avere più copie abilitando il backup o la replica tra aree. Tutte le voci di log sono disponibili solo tramite canali HTTP protetti.

Il framework di avvisi di Azure consente di configurare gli avvisi per rilevare l'accesso sospetto. È possibile impostare gli avvisi da attivare e gli eventi. Gli utenti possono anche controllare manualmente il log completo usando Analisi dei log con funzionalità di filtro in base al tipo di attività, al contenuto dell'attività o al chiamante dell'attività.

Responsabilità

Requisito 11—Testare regolarmente i sistemi e i processi di sicurezza

Supporto per le funzionalità dell'AKS

AKS è integrato con i servizi di monitoraggio di Azure:

• Microsoft Defender per contenitori offre molte funzionalità di analisi della sicurezza. Ad esempio, Defender per contenitori analizza le immagini pull, push e importate nei registri contenitori e fornisce raccomandazioni. Per i dettagli, consultare la sezione Valutazione delle vulnerabilità.

• Monitoraggio di Azure può essere usato per impostare avvisi in base al tipo di evento per proteggere l'integrità e la sicurezza del sistema. Quando si verificano errori di sistema previsti nei nodi di AKS, AKS esegue l'autenticazione automatica della risorsa in modo tempestivo senza interruzioni dell'elaborazione del sistema.

I cluster di AKS sono protetti da Gateway applicazione di Azure con Web Application Firewall (WAF) e possono essere configurati in modalità di rilevamento per registrare avvisi e minacce. È preferibile usare la modalità di prevenzione, che blocca attivamente le intrusioni e gli attacchi rilevati. Per i dettagli, consultare la sezione Procedure consigliate per la sicurezza e la connettività di rete nel servizio Azure Kubernetes (AKS).

Responsabilità

Requisito 10.1

Implementare log di controllo per collegare tutti gli accessi ai componenti di sistema a ogni singolo utente.

Responsabilità

È consigliabile controllare le operazioni eseguite su ogni componente usando i metodi seguenti:

• Log attività di Monitoraggio di Azure. Il log attività fornisce informazioni sul tipo e sull'ora delle operazioni delle risorse di Azure. Registra anche l'identità che ha avviato l'operazione. È abilitata per impostazione predefinita e le informazioni vengono raccolte non appena viene eseguita l'operazione di risorsa. L'audit trail non è modificabile e non può essere eliminato.

  I dati vengono mantenuti per 90 giorni. Per le opzioni di conservazione più lunghe, è consigliabile inviare voci del log attività ai log di Monitoraggio di Azure e configurare criteri di conservazione e archiviazione.

  

• Impostazioni di Diagnostica di Azure. Le impostazioni di diagnostica forniscono informazioni di diagnostica e controllo delle risorse di Azure e della piattaforma a cui si applica l'impostazione. È consigliabile abilitare le impostazioni di diagnostica per AKS e altri componenti nel sistema, ad esempio Archiviazione BLOB di Azure e Key Vault. In base al tipo di risorsa, è possibile scegliere il tipo di log e i dati delle metriche da inviare a una destinazione. La destinazione di diagnostica deve soddisfare i periodi di conservazione necessari.

  • Dalle categorie di AKS fornite abilitare i log di controllo di Kubernetes. Le impostazioni di diagnostica includono kube-audit o kube-audit-admin e guard.

    Abilitare kube-audit-admin per visualizzare le chiamate al server API basate su log che potrebbero modificare lo stato del cluster. Se è necessario un audit trail di tutte le interazioni del server API (inclusi gli eventi non modificabili, ad esempio le richieste di lettura), abilitare kube-audit invece. Questi eventi possono essere prolifici, creare rumore e aumentare il costo di consumo. Questi log contengono informazioni sull'accesso e sul nome dell'identità usati per effettuare la richiesta.

    Abilitare i log guard per tenere traccia degli id di Microsoft Entra gestiti e dei controlli di controllo degli accessi in base al ruolo di Azure.

  • Oltre ai log basati sull'utente, prendere in considerazione i log dal piano di controllo Kubernetes, tra cui kube-apiserver e kube-controller-manager. Questi log non sono in genere associati all'utente, ma possono aiutare a correlare le modifiche di sistema apportate dagli utenti.

    Per maggiori informazioni, consultare la sezione Visualizzazione dei log dei componenti del piano di controllo.

  Questa implementazione di riferimento abilita cluster-autoscaleri log, kube-controller-managerkube-audit-admin e guard inoltra a un'area di lavoro Analisi dei log. Il periodo di memorizzazione dell'area di lavoro è impostato su 90 giorni.

  

• La diagnostica di Servizio Azure Kubernetes (AKS) consente di rilevare e risolvere i problemi relativi al cluster, ad esempio gli errori dei nodi. Include anche dati di diagnostica specifici della rete, che non comporta costi aggiuntivi. Questi dati non sono in genere associati all'attività dell'utente, ma possono essere utili se è necessario comprendere gli effetti delle modifiche di sistema apportate dagli utenti. Per informazioni, consultare Diagnostica del Servizio Azure Kubernetes.

I meccanismi di audit trail precedenti devono essere implementati al momento della distribuzione delle risorse. Criteri di Azure deve essere attivo anche per assicurarsi che queste configurazioni non siano inavvertitamente o disabilitate inavvertitamente nell'ambiente CDE.

Requisito 10.2

Implementare log di controllo automatizzati per tutti i componenti del sistema per ricostruire gli eventi seguenti:

• 10.2.1 Tutti gli accessi utente ai dati di titolari di carte
• 10.2.2 Tutte le azioni eseguite da qualsiasi utente con privilegi di utente root o amministratore
• 10.2.3 Accesso a tutti i log di controllo
• 10.2.4 Tentativi di accesso logico non validi
• 10.2.5 Uso e modifiche dei meccanismi di identificazione e autenticazione—compresi, a titolo esemplificativo, creazione di nuovi account ed elevazione dei privilegi—e tutte le modifiche, le aggiunte o le eliminazioni per gli account con privilegi root o di amministratore
• 10.2.6 Inizializzazione, arresto o sospensione dei log di controllo
• 10.2.7 Creazione ed eliminazione di oggetti a livello di sistema

Responsabilità

AKS fornisce log di controllo a più livelli, come descritto nel Requisito 10.1. Di seguito sono riportati alcuni punti chiave:

• Per impostazione predefinita, i log attività forniscono informazioni sulle operazioni critiche delle risorse di Azure. Tutti i log includono lo stato, l'ora e l'identità che ha avviato l'operazione.
• Abilitare le impostazioni di diagnostica per accedere a tutti i record di tutte le chiamate API effettuate nel cluster di AKS. I log forniscono informazioni dettagliate sul richiedente, sul timestamp, sull'origine della richiesta e sul contenuto della richiesta. Archiviare i log in un'area di lavoro Analisi dei log con un periodo di conservazione appropriato. Abilitare la registrazione dell'area di lavoro Analisi dei log per assicurarsi che venga registrato anche l'accesso al audit trail.
• Abilitare la raccolta syslog con Container Insights per acquisire i log eventi di sicurezza e integrità del sistema operativo a livello di nodo del servizio Azure Kubernetes nell'area di lavoro Analisi dei log. Questi log devono essere inseriti anche nel sistema SIEM.
• Includere la registrazione di controllo del sistema operativo e dell'utilizzo per altre risorse di calcolo, ad esempio agenti di compilazione e jump box. Disabilitare l'accesso ai sistemi direttamente come radice. Verificare che tutte le azioni vengano eseguite con un'identità specifica.
• Registrare tentativi di accesso non riusciti. Sono incluse le richieste di accesso ai componenti, ad esempio Archiviazione di Azure, Azure Key Vault, il server API AKS e qualsiasi accesso RDP/SSH in altri sistemi.
• Sfruttare le funzionalità offerte dagli agenti di sicurezza di terze parti per analizzare i modelli utente all'interno del cluster di AKS. Queste funzionalità possono essere utili per i dati di controllo dell'accesso utente.

Requisito 10.3

Registrare almeno le voci seguenti dei log di controllo per tutti i componenti di sistema per ogni evento:

• 10.3.1 Identificazione utente
• 10.3.2 Tipo di evento
• 10.3.3 Data e ora
• 10.3.4 Indicazione di esito positivo o negativo
• 10.3.5 Origine dell'evento
• 10.3.6 Identità o nome dei dati interessati, del componente di sistema o della risorsa.

Responsabilità

Come descritto nel Requisito 10.2, è possibile ottenere i log di controllo dal cluster abilitando l'impostazione di diagnostica per AKS. I log contengono informazioni dettagliate su get, list, create, update, delete, patch e post events. I log contengono le informazioni specificate nel requisito. Archiviare i log in un account di archiviazione in modo da poter eseguire query sulle informazioni.

Ad esempio, si desidera visualizzare il set di informazioni precedente per gli eventi kube-audit-admin eseguendo questa query:

AzureDiagnostics
| where Category == 'kube-audit-admin'
| project TimeGenerated, ResourceId, log_s,  pod_s
| top 200 by TimeGenerated desc

Il set di risultati mostra le informazioni come parte del campo log_s.

Per informazioni sui log del piano di controllo, consultare la sezione Log del piano di controllo/risorsa di AKS.

Requisito 10.4

Usando la tecnologia per la sincronizzazione dell'ora, sincronizzare tutti gli orologi e gli orari critici del sistema ed assicurarsi che sia implementato quanto segue per l'acquisizione, la distribuzione e l'archiviazione dell'ora.

• 10.4.1 L'ora dei sistemi critici è esatta e coerente.
• 10.4.2 I dati di ora sono protetti.
• 10.4.3 Le impostazioni di ora sono ricevute da fonti accettate dal settore.

Nota: un esempio di tecnologia per la sincronizzazione dell'ora è Network Time Protocol (NTP).

Responsabilità

AKS usa NTP dagli host di Azure sottostanti e non richiede alcun traffico di rete in uscita per supportare NTP. Altre VM aggiunte all'ambiente CDE potrebbero usare server NTP esterni, ad esempio ntp.ubuntu.org (e il relativo pool) come origine di sincronizzazione dell'ora. L'ambiente di calcolo aggiuntivo che si inserisce nell'ambiente CDE deve usare in modo esplicito l'origine NTP desiderata e deve essere documentato.

Requisito 10.5

Limitare la visualizzazione dei log di controllo a coloro che realmente necessitano di tali informazioni per motivi professionali.

• Limitare la visualizzazione dei log di controllo a coloro che realmente necessitano di tali informazioni per motivi professionali.
• 10.5.2 Proteggere i file dei log di controllo da modifiche non autorizzate.
• 10.5.3 Eseguire immediatamente il backup dei file dei log di controllo in un server di log centralizzato o su supporti difficili da alterare.
• 10.5.4 Scrivere i log per tecnologie rivolte al pubblico su un server di log o un dispositivo per supporti sicuro, centralizzato e interno.
• 10.5.5 Usare un meccanismo di monitoraggio dell'integrità dei file o un software di rilevamento delle modifiche dei log per assicurarsi che i dati di log esistenti non possano essere modificati senza generare avvisi (sebbene l'aggiunta di nuovi dati non dovrebbe generare avvisi).

Responsabilità

La presenza di più sink di registrazione comporta un sovraccarico per la protezione, la revisione, l'analisi e l'esecuzione di query sui dati degli audit trail. Pianificare le topologie degli audit trail per bilanciare i compromessi tra l'isolamento completo dei audit trail e i problemi di gestione.

Quando possibile, integrare i log. Il vantaggio è la possibilità di esaminare, analizzare ed eseguire query sui dati in modo efficiente. Azure offre diverse opzioni tecnologico. È possibile usare informazioni dettagliate sui contenitori di Monitoraggio di Azure per scrivere log in un'area di lavoro Analisi dei log. Un'altra opzione consiste nell'integrare i dati nelle soluzioni di gestione delle informazioni e degli eventi di sicurezza (SIEM), ad esempio Microsoft Sentinel. Altre scelte di terze parti più comuni sono Splunk, QRadar e ArcSight. Microsoft Defender per il cloud e Monitoraggio di Azure supportano tutte queste soluzioni. Queste soluzioni sono sink di dati di sola accodamento per assicurarsi che la traccia non possa essere modificata.

Defender per il cloud può esportare i risultati a intervalli configurati. Per altre informazioni, vedere Esportazione continua.

Tutti i log vengono conservati con almeno tre copie in un'area. Come strategia di backup, è possibile avere più copie abilitando il backup o la replica tra aree. Tutte le voci di log sono disponibili solo tramite canali HTTP protetti.

Analisi dei log e Microsoft Sentinel supportano vari controlli di accesso in base al ruolo per gestire l'accesso audit trail. Assicurarsi che i ruoli siano mappati ai ruoli e alle responsabilità dell'organizzazione.

Assicurarsi che l'area di lavoro Analisi dei log supporti sia le operazioni che le esigenze di conformità. Si consideri un'area di lavoro dedicata per i cluster nell'ambito, che vengono inoltrati alla soluzione SIEM.

La maggior parte della registrazione in AKS proviene da stdout/stderr e verrà raccolta dalle informazioni dettagliate sui contenitori di Monitoraggio di Azure. Se sono presenti altri log creati manualmente, è consigliabile creare dati in modo che vengano inviati a un flusso di inoltro attendibile e non siano soggetti a manomissioni.

Requisito 10.6

Esaminare i log e gli eventi di sicurezza per tutti i componenti di sistema al fine di identificare anomalie o attività sospette.

• 10.6.1 Esaminare gli elementi seguenti almeno quotidianamente:
  • Tutti gli eventi di sicurezza
  • Log di tutti i componenti di sistema che archiviano, elaborano o trasmettono dati di titolari di carte e/o dati di autenticazione sensibili
  • Log di tutti i componenti di sistema critici
  • Log di tutti i server e i componenti di sistema che eseguono funzioni di sicurezza (ad esempio, firewall, sistemi di rilevamento intrusioni/sistemi di prevenzione intrusioni, server di autenticazione, server di reindirizzamento per e-commerce ecc).
• 10.6.2 Esaminare periodicamente i log di tutti gli altri componenti di sistema in base alle politiche e alla strategia di gestione dei rischi dell'organizzazione, secondo quanto stabilito dalla valutazione annuale dei rischi dell'organizzazione.
• 10.6.3 Mantenere monitorate le eccezioni e le anomalie individuate durante il processo di revisione e intervenire all'occorrenza.

Responsabilità

I servizi di monitoraggio di Azure, Monitoraggio di Azure e Microsoft Defender per il cloud, possono generare notifiche o avvisi quando rilevano attività anomale. Questi avvisi includono informazioni sul contesto, ad esempio gravità, stato e tempo di attività.

Man mano che vengono generati avvisi, avere una strategia di correzione e rivedere lo stato di avanzamento. Un modo consiste nel tenere traccia del punteggio di sicurezza in Microsoft Defender per il cloud e confrontarlo con i risultati cronologici.

Centralizzare i dati in una singola visualizzazione usando soluzioni SIEM, ad esempio Microsoft Sentinel. L'integrazione dei dati può fornire un contesto di avviso avanzato.

In alternativa, controllare manualmente il log completo nella risorsa di archiviazione. Ad esempio, nei log di Monitoraggio di Azure è possibile usare una funzionalità di filtro in base al tipo di attività, al contenuto dell'attività o al chiamante dell'attività.

Disporre dei criteri dell'organizzazione per esaminare gli avvisi e gli eventi a cadenza regolare e pianificare le iniziative con obiettivi di miglioramento specifici. Usare query salvate personalizzate in Analisi dei log per documentare le query di log desiderate e semplificare l'esecuzione di query. In questo modo, il team sa cosa è importante esaminare in quanto riguarda la versione 10.6 e che tutti gli sforzi manuali coinvolti in questo processo seguono un flusso di lavoro coerente.

Requisito 10.7

Conservare la cronologia dei log di controllo per almeno un anno, con minimo tre mesi disponibili immediatamente per l'analisi (ad esempio disponibili online, archiviati o recuperabili da backup).

Responsabilità

Per impostazione predefinita, i log non vengono conservati a tempo indeterminato. Assicurarsi di configurare i log attività di Azure e le impostazioni di diagnostica da conservare in modo che sia possibile eseguire query. Specificare un periodo di conservazione di tre mesi quando si abilitano le impostazioni di diagnostica per le risorse. I log di Monitoraggio di Azure supportano l'archiviazione a lungo termine, in modo che possano essere usati per i controlli o l'analisi offline. Implementare la soluzione di archiviazione a lungo termine per allinearsi al principio della scrittura una sola volta, leggere molti.

Requisito 10.8

10.8.1 Requisito aggiuntivo solo per provider di servizi: risolvere gli errori di eventuali controlli di sicurezza critici in maniera tempestiva. I processi di risoluzione degli errori presenti nei controlli di sicurezza devono includere:

• Ripristino delle funzioni di sicurezza
• Identificazione e documentazione della durata (data e ora di inizio e fine) dell'errore di sicurezza
• Identificazione e documentazione delle cause dell'errore, inclusa la causa principale, e documentazione delle attività di correzione richieste per identificare ed eliminare la causa principale
• Identificazione e risoluzione di eventuali problemi di sicurezza emersi durante l'errore
• Esecuzione di una valutazione dei rischi per determinare se sono richieste ulteriori azioni a causa dell'errore di sicurezza
• Implementazione di controlli per evitare che la causa del guasto si ripeta
• Ripresa del monitoraggio dei controlli di sicurezza

Responsabilità

Quando è pratico, avere avvisi che indicano l'esistenza di controlli di sicurezza critici. In caso contrario, assicurarsi che il processo di controllo possa rilevare la mancanza di un controllo di sicurezza previsto in modo tempestivo. Prendere in considerazione controlli come gli agenti di sicurezza in esecuzione nel cluster di AKS e i controlli di accesso (IAM e rete) nelle risorse di Azure. Includere le impostazioni per verificare se il cluster del servizio Azure Kubernetes è un cluster privato, per i punti di esposizione di rete tramite regole del gruppo di sicurezza di rete (NSG) o verificare la presenza di indirizzi IP pubblici imprevisti. Includere anche modifiche impreviste in DNS, routing di rete, firewall e Microsoft Entra ID.

Requisito 10.9

Assicurarsi che i criteri di sicurezza e le procedure operative per il monitoraggio dell'accesso alle risorse di rete e ai dati di titolari di schede siano documentati, applicati e noti a tutte le parti interessate.

Responsabilità

È fondamentale mantenere una documentazione completa sui processi e sui criteri. Gestire la documentazione sui criteri applicati. Nell'ambito delle attività di monitoraggio, gli utenti devono essere addestrati per abilitare e visualizzare i log di controllo e identificare e correggere i rischi comuni. È importante per le persone che fanno parte del processo di approvazione dal punto di vista dei criteri.

Requisito 11.1

Implementare processi per verificare la presenza di punti di accesso wireless (802.11) e rilevare e identificare tutti i punti di accesso wireless autorizzati e non autorizzati con cadenza trimestrale.

Le reti esterne non rientrano nell'ambito di questa documentazione e devono essere valutate separatamente.

Responsabilità

Questa architettura e l'implementazione non sono progettate per supportare transazioni locali o aziendali da rete a cloud tramite connessioni wireless. Per le considerazioni, consultare le linee guida nello standard ufficiale PCI-DSS 3.2.1.

Requisito 11.2

Eseguire analisi della vulnerabilità di rete interna ed esterna almeno trimestrale e dopo eventuali modifiche di rete significative, ad esempio:

• Nuove installazioni di componenti di sistema
• Modifiche della topologia di rete
• Modifiche alle regole del firewall
• Aggiornamenti dei prodotti

Per maggiori informazioni, consultare la sezione Payment Card Industry (PCI) Data Security Standard Approved Scanning Vendors..

Responsabilità

Disporre di un processo che verifica la presenza di modifiche nel cluster di AKS, nella configurazione di rete, nei registri contenitori e in altri componenti dell'architettura.

Se sono state apportate modifiche alla rete, il processo deve valutare se è necessaria un'analisi. Ad esempio, il cluster è ora esposto alla rete Internet pubblica? Le nuove regole del firewall sono eccessivamente permissive? All'interno del cluster sono presenti lacune di sicurezza nel flusso tra i pod?

Avere una definizione chiara e concordata di modifiche significative rispetto all'infrastruttura. Alcuni esempi sono:

• Configurazione di NSG o regole di Firewall di Azure
• Peering di rete virtuale
• Impostazioni DNS
• Configurazioni collegamento privato di Azure
• Altri componenti di rete

SI APPLICA A 11.2.1

L'analisi trimestrale delle vulnerabilità deve essere eseguita da personale esperto con una conoscenza approfondita delle funzionalità di rete di Azure e dei concetti di rete di Kubernetes. Eseguire il mapping dei risultati al Requisito 6.1 con i livelli di gravità e risolvere gli elementi con priorità alta. Se sono presenti modifiche significative, eseguire le analisi prima dell'analisi trimestrale pianificata. Ciò consente di rilevare nuove vulnerabilità in modo da poter risolvere in modo proattivo i problemi.

Questa analisi deve includere anche reti in cluster (da pod a pod).

SI APPLICA A 11.2.2

Selezionare un fornitore di analisi approvato (ASV) con un'esperienza completa con la rete di Azure e Kubernetes. Ciò fornisce profondità e specificità nella correzione suggerita.

Requisito 11.3

Implementare una metodologia di test di penetrazione con le caratteristiche seguenti:

• È basata su approcci ai test di penetrazione accettati dal settore (ad esempio, NIST SP800-115)
• Include la copertura dell'intero perimetro dell'ambiente CDE e dei sistemi critici
• Include test sia dall'interno che dall'esterno della rete
• Include test per la convalida di qualsiasi controllo di segmentazione e riduzione dell'ambito
• Definisce i test di penetrazione a livello di applicazione in modo da includere almeno le vulnerabilità elencate nel requisito 6.5
• Definisce i test di penetrazione a livello di rete in modo da includere i componenti che supportano le funzioni di rete nonché i sistemi operativi
• Include l'esame e la valutazione delle minacce e delle vulnerabilità verificatesi negli ultimi 12 mesi
• Specifica la conservazione dei risultati dei test di penetrazione e delle attività di correzione.

Responsabilità

Eseguire i test di penetrazione per individuare le lacune nella sicurezza raccogliendo informazioni, analizzando le vulnerabilità e segnalando i risultati. Si consiglia di seguire le linee guida del settore fornite in Penetration Testing Execution Standard (PTES) per affrontare gli scenari comuni e le attività necessarie per stabilire una linea di base.

Il professionista dei test di penetrazione deve avere una conoscenza approfondita della rete locale e di Azure per garantire che i test di segmentazione annuale siano trattati in modo approfondito. Estendere la metodologia di test alle reti in cluster. Questa persona richiede un'esperienza avanzata con i concetti di rete di Kubernetes.

I test devono coprire i livelli di dati e dell'applicazione in esecuzione nell'ambiente CDE.

In una procedura di test di penetrazione, i professionisti potrebbero dover accedere ai dati sensibili dell'intera organizzazione. Seguire le regole di engagement per assicurarsi che l'accesso e la finalità non vengano usati in modo improprio. Per indicazioni sulla pianificazione e l'esecuzione di attacchi simulati, vedere Regole di engagement per i test di penetrazione.

Requisito 11.4

Usare tecniche di rilevamento e/o prevenzione delle intrusioni per rilevare e/o prevenire intrusioni nella rete. Monitora tutto il traffico sul perimetro dell'ambiente dei dati dei titolari di scheda e nei punti critici dell'ambiente dei dati dei titolari di scheda. Avvisare il personale per i sospetti compromessi.

Responsabilità

Proteggere il cluster di AKS controllando il traffico in ingresso usando un Web Application Firewall (WAF). In questa architettura, Gateway applicazione di Azure con WAF integrato impedisce l'intrusione. Usare la modalità di prevenzione per bloccare attivamente le intrusioni e gli attacchi rilevati. Non usare solo la modalità di rilevamento. Per maggiori informazioni, consultare la sezione Procedure consigliate per la sicurezza e la connettività di rete nel servizio Azure Kubernetes (AKS).

Un'opzione alternativa consiste nell'usare le funzionalità di rilevamento delle intrusioni e/o di prevenzione delle intrusioni in Firewall di Azure Premium. Per altre informazioni, vedere IDPS.

Un'altra opzione consiste nell'abilitare Azure Monitor Network Insights, che fornisce l'accesso alle funzionalità di monitoraggio della rete come Connection Monitor, la registrazione dei flussi per i gruppi di sicurezza di rete e Analisi del traffico.

Abilitare i piani di Microsoft Defender quando si applicano a vari componenti dell'ambiente CDE. Ad esempio, se SQL di Azure viene usato per archiviare CHD, Microsoft Defender per SQL assicurerà che vengano rilevate intrusioni a livello di dati.

Rilevare anche anomalie nei modelli di traffico connettendo i log del flusso del gruppo di sicurezza di rete a una soluzione SIEM centralizzata, ad esempio Microsoft Sentinel. In questa implementazione di riferimento i log sono in modalità di sola accodamento, riducendo al minimo il rilevamento delle modifiche nei log di controllo. Tuttavia, tutti i log inviati a sink esterni per l'archiviazione a lungo termine non devono essere modificati. Devono seguire l'approccio write-once/read-many. Assicurarsi che la soluzione FIM (File Integrity Monitoring) includa tali entità esterne per rilevare le modifiche.

Requisito 11.5

Distribuire una soluzione di rilevamento modifiche (ad esempio, una soluzione di monitoraggio dell'integrità dei file) per avvisare il personale alla modifica non autorizzata dei file di sistema critici, dei file di configurazione o dei file di contenuto. Configurare il prodotto per eseguire confronti di file critici almeno ogni settimana.

Responsabilità

Nel cluster eseguire una soluzione FIM (File Integrity Monitoring) in insieme a un agente di sicurezza compatibile con Kubernetes per rilevare l'accesso a livello di file e di sistema che potrebbe comportare modifiche a livello di nodo. Quando si sceglie una soluzione FIM, comprendere chiaramente le funzionalità e la profondità del rilevamento. Prendere in considerazione il software sviluppato da fornitori affidabili.

Controllare tutte le impostazioni predefinite dello strumento FIM per assicurarsi che i valori rilevino gli scenari da coprire e modificare tali impostazioni in modo appropriato.

Abilitare la soluzione per inviare i log alla soluzione di monitoraggio o SIEM in modo che possano generare avvisi. Tenere presente le modifiche apportate allo schema del log oppure si potrebbero perdere avvisi critici.

Qualsiasi altra risorsa di calcolo nell'ambiente CDE deve avere abilitato il rilevamento delle modifiche.

Requisito 11.6

Garantire che i criteri di sicurezza e le procedure operative per il monitoraggio e i test della sicurezza siano documentati, in uso e noti a tutte le parti coinvolte.

Responsabilità

È fondamentale mantenere una documentazione completa sui processi e sui criteri. Gestire la documentazione sui criteri applicati. Nell'ambito delle attività di test, includere la frequenza delle revisioni e i criteri di revisione. Assicurarsi che il team comprenda gli aspetti dei test di penetrazione. Disporre di un piano di correzione documentato per attenuare i rischi rilevati.

È importante per le persone che fanno parte del processo di approvazione dal punto di vista dei criteri.

Passaggi successivi

Gestire criteri che garantiscano la sicurezza delle informazioni per tutto il personale.