Rilevare le vulnerabilità di un cluster regolamentato di AKS per PCI-DSS 3.2.1 (parte 5 di 9)

Questo articolo descrive le considerazioni relative a un cluster servizio Azure Kubernetes (AKS) configurato 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.

Come qualsiasi soluzione cloud, un carico di lavoro PCI è soggetto a minacce di rete, identità e dati. Esempi comuni di origini che sfruttano il carico di lavoro e le vulnerabilità del sistema sono virus o aggiornamenti software che producono risultati indesiderati. Rilevare le minacce in anticipo e rispondere con la mitigazione in modo tempestivo. Creare avvisi critici per le attività del carico di lavoro ed estendere tali avvisi ai processi di sistema principali. Gli strumenti di monitoraggio dei file (FIM) o l'antivirus devono essere sempre in esecuzione. Avere un piano di risposta responsabile e un team che esamina gli avvisi e interviene.

Mantenere un piano digestione delle vulnerabilità

Requisito 5—Proteggere tutti i sistemi da malware e aggiornare regolarmente il software o i programmi antivirus

Supporto per le funzionalità dell'AKS

AKS non si comporta come un host di applicazioni tradizionale. Le VM del nodo in un cluster AKS hanno un'esposizione limitata e sono progettate per non essere accessibili direttamente. Poiché le VM del nodo non equivalgono alle VM tradizionali, non è possibile usare gli strumenti comuni delle VM. Le raccomandazioni di questa sezione vengono quindi applicate tramite costrutti Kubernetes nativi. L'applicazione di questi requisiti direttamente a livello di VM potrebbe causare il supporto del cluster.

Sarà necessario distribuire il software antimalware preferito in DaemonSet che verrà eseguito in un pod in ogni nodo.

Responsabilità

Assicurarsi che il software sia specializzato in Kubernetes e contenitori. Esistono diverse opzioni software di terze parti. Le scelte più diffuse includono Prisma Cloud e Aquasec. Ci sono anche opzioni open source come Falco. È responsabilità dell'utente assicurarsi che siano presenti processi per assicurarsi che il software di terze parti sia aggiornato. Inoltre, il monitoraggio e l'invio di avvisi delle soluzioni sono responsabilità dell'utente.

Requisito 6—Sviluppare e gestire sistemi e applicazioni sicuri

Supporto per le funzionalità dell'AKS

Analogamente ad altri servizi di Azure, AKS segue i processi Microsoft SDL (Security Development Lifecycle) per la sicurezza in tutte le fasi del processo di sviluppo. I vari componenti vengono analizzati a partire dalle prime fasi di sviluppo e i gap di sicurezza vengono coperti il prima possibile.

Le immagini AKS seguono un approccio con contratto di servizio FedRAMP, che richiede la patch delle vulnerabilità nelle immagini entro 30 giorni. Per applicare questo requisito, tutte le immagini vengono sanificate tramite una pipeline DevSecOps.

Settimanalmente, AKS fornisce nuove immagini per i pool di nodi. È responsabilità dell'utente applicarli per garantire l'applicazione di patch e l'aggiornamento dei nodi di lavoro set di scalabilità di macchine virtuali. Per maggiori informazioni, consultare la sezione Aggiornamento immagine nodo di Servizio Azure Kubernetes (AKS).

Per il piano di controllo di AKS, AKS installa o aggiorna le patch di sicurezza. Vengono aggiornati ogni 24 ore.

Il piano AKS e i nodi di lavoro vengono rafforzati usando i benchmark cis (CIS) del Centro per la sicurezza Internet, in particolare AKS CIS, Ubuntu CIS e Windows CIS.

AKS si integra con Registro contenitori di Azure. Usare Registro contenitori di Azure con funzionalità di analisi continue in Microsoft Defender per il cloud per identificare immagini e applicazioni vulnerabili a vari livelli di rischio. Per informazioni sull'analisi delle immagini e sul controllo dei rischi, consultare la sezione Microsoft Defender per contenitori.

Responsabilità

Requisito 5.1

Distribuire il software antivirus in tutti i sistemi comunemente interessati dal software dannoso, in particolare personal computer e server.

Responsabilità

È responsabilità dell'utente proteggere il carico di lavoro, l'infrastruttura e le pipeline di distribuzione scegliendo un software antimalware appropriato.

Poiché l'accesso alle macchine virtuali del nodo di AKS è limitato, proteggere il sistema a ogni livello in cui il malware potrebbe essere inserito nelle VM del nodo. Includere il rilevamento e la prevenzione nei nodi del cluster, nelle immagini del contenitore e nelle interazioni di runtime con il server API Kubernetes. Oltre al cluster, proteggere questi componenti che interagiscono con il cluster e possono avere il software antivirus installato in modo tradizionale:

• Jump box
• Agenti di compilazione

Allineare le attività di analisi al ciclo di vita dello sviluppo della sicurezza (SDL). In seguito a SDL, l'analisi dei vari componenti dell'architettura inizia nelle prime fasi di sviluppo e lacune di sicurezza viene coperta il prima possibile.

Requisito 5.1.1

Assicurarsi che i programmi antivirus possano rilevare, rimuovere e proteggere da tutti i tipi noti di software dannoso.

Responsabilità

Informazioni sul set di funzionalità di ogni offerta software e la profondità di analisi che può eseguire. Il software deve bloccare le minacce comuni e monitorare le nuove minacce. Assicurarsi che il software venga aggiornato, testato e sostituito regolarmente se non è adatto. Prendere in considerazione il software sviluppato da fornitori affidabili.

• Strumenti di monitoraggio che rilevano le vulnerabilità del cluster.

  In AKS, non è possibile eseguire soluzioni VM basate su agenti tradizionali direttamente nelle VM del nodo. Sarà necessario distribuire il software antimalware in DaemonSet che verrà eseguito in un pod in ogni nodo.

  Scegliere il software specializzato per Kubernetes e carichi di lavoro in contenitori. Esistono diverse opzioni software di terze parti. Le scelte più diffuse includono Prisma Cloud e Aquasec. Ci sono anche opzioni open source come Falco.

  Quando vengono distribuiti, vengono eseguiti come agenti nel cluster che analizza tutti i pool di nodi utente e di sistema. Anche se AKS usa pool di nodi di sistema per i relativi file binari di sistema di runtime, il calcolo sottostante è comunque responsabilità dell'utente.

  Lo scopo dell'esecuzione dell'agente è rilevare attività cluster insolite. Ad esempio, un'applicazione sta tentando di chiamare il server API? Alcune soluzioni generano un log di chiamate API tra pod, generano report e generano avvisi. Assicurarsi di esaminare i log ed eseguire le azioni necessarie.

  Installare gli agenti di sicurezza immediatamente dopo il bootstrap del cluster per ridurre al minimo le lacune non monitorate tra il cluster e la distribuzione delle risorse di AKS.

  Gli agenti di sicurezza vengono eseguiti con privilegi elevati e analizzano tutto ciò che viene eseguito nel cluster e non solo il carico di lavoro. Non devono diventare un'origine di esfiltrazione di dati. Inoltre, gli attacchi alla supply chain sono comuni per i contenitori. Usare strategie di difesa approfondite e assicurarsi che il software e tutte le dipendenze siano attendibili.

  Eseguire anche software antivirus su asset esterni che partecipano alle operazioni del cluster. Alcuni esempi includono jumpbox, agenti di compilazione e immagini del contenitore che interagiscono con il cluster.

  Quando l'agente esegue l'analisi, non deve bloccare o interferire con le operazioni critiche del cluster, ad esempio bloccando i file. Una configurazione errata potrebbe causare problemi di stabilità e potrebbe non supportare il cluster.

  Importante

  L'implementazione di riferimento fornisce una distribuzione segnaposto DaemonSet per eseguire un agente antimalware. L'agente verrà eseguito in ogni VM del nodo nel cluster. Posizionare la scelta del software antimalware in questa distribuzione.

• Gestione della sicurezza dei contenitori. Eseguire strumenti di analisi dei contenitori nella pipeline per rilevare le minacce che potrebbero provenire tramite immagini del contenitore, ad esempio l'analisi delle vulnerabilità CI/CD in Microsoft Defender per contenitori. Le scelte di terze parti includono Trivy e Clair. Quando si creano immagini, cercare sempre immagini senza distribuzione. Queste immagini contengono solo i file binari essenziali nell'immagine Linux di base e riducono la superficie di attacco per gli attacchi. Usare una soluzione di analisi continua come la valutazione delle vulnerabilità in Microsoft Defender per contenitori per l'analisi continua delle immagini già inattive nei repository.

Requisito 5.1.2

Effettuare valutazioni periodiche dei sistemi che non vengono comunemente interessati da malware per identificare e valutare l'evoluzione delle minacce malware e confermare o meno la necessità di software antivirus.

Responsabilità

Le vulnerabilità comuni possono influire sui componenti esterni al cluster. Tenere traccia delle vulnerabilità di sicurezza osservando CVE e altri avvisi di sicurezza dalla piattaforma Azure. Verificare la presenza di aggiornamenti di Azure per le nuove funzionalità in grado di rilevare le vulnerabilità ed eseguire soluzioni antivirus nei servizi ospitati in Azure.

Ad esempio, l'archiviazione BLOB deve avere lo screening della reputazione malware per rilevare caricamenti sospetti. Microsoft Defender per Archiviazione include lo screening della reputazione malware. Valutare anche se per un servizio di questo tipo è necessaria una soluzione antivirus.

Requisito 5.2

Assicurarsi che tutti i meccanismi antivirus siano:

• Aggiornati,
• Inclusi in analisi periodiche
• In grado di generare log di controllo da conservare in base al Requisito 10.7 di PCI DSS.

Responsabilità

• Assicurarsi che il cluster sia protetto da nuovi attacchi usando la versione più recente del software antivirus. Esistono due tipi di aggiornamento da valutare:
  • Il software antivirus deve tenere il passo con gli aggiornamenti delle funzionalità più recenti. Un modo consiste nel pianificare gli aggiornamenti come parte degli aggiornamenti della piattaforma.
  • Gli aggiornamenti di Intelligence per la sicurezza devono essere applicati non appena sono disponibili per rilevare e identificare le minacce più recenti. Opta per gli aggiornamenti automatici.
• Verificare che le analisi della vulnerabilità siano in esecuzione, come pianificato.
• Conservare tutti i log generati in seguito all'analisi, che indicano componenti integri e non integri. Il periodo di conservazione consigliato è indicato nel requisito 10.7, ovvero un anno.
• Disporre di un processo che valuta e corregge i problemi rilevati.

Per informazioni su come vengono applicati gli aggiornamenti dell'antivirus Microsoft Defender per endpoint, consultare la sezione Antivirus Microsoft Defender aggiornamenti di intelligence per la sicurezza e i prodotti.

Requisito 5.3

Le funzionalità antivirus devono essere in esecuzione attivamente e non possono essere disabilitate o modificate dagli utenti. Ad eccezione del caso autorizzato dalla gestione per caso per un periodo di tempo limitato.

Responsabilità

L'utente è responsabile della configurazione del monitoraggio e dell'invio di avvisi dell'agente di sicurezza. Creare avvisi critici non solo per il carico di lavoro, ma anche per i processi di base del sistema. L'agente deve essere sempre in esecuzione. Rispondere agli avvisi generati dal software antimalware.

• Mantenere un log trail delle attività di analisi. Assicurarsi che il processo di analisi non registri i dati dei titolari di schede raschiati dal disco o dalla memoria.
• Impostare avvisi per le attività che potrebbero causare un errore imprevisto di conformità. Gli avvisi non devono essere disattivati inavvertitamente.
• Limitare le autorizzazioni per modificare la distribuzione dell'agente e tutti gli altri strumenti di sicurezza critici. Mantenere queste autorizzazioni separate dalle autorizzazioni di distribuzione del carico di lavoro.
• Non distribuire carichi di lavoro se gli agenti di sicurezza non sono in esecuzione come previsto.

Requisito 5.4

Verificare che i criteri di sicurezza e le procedure operative per la protezione dei sistemi da malware siano documentati, usati e comunicati a tutte le parti interessate.

Responsabilità

È fondamentale mantenere una documentazione completa sul processo e sui criteri, in particolare i dettagli sulla soluzione antivirus usata per proteggere il sistema. Includere informazioni quali dove nel ciclo del prodotto vengono mantenuti gli aggiornamenti di intelligence per la sicurezza, la frequenza delle analisi e le informazioni sulle funzionalità di analisi in tempo reale.

Disporre di criteri di conservazione per l'archiviazione dei log. Per motivi di conformità, potrebbe essere necessario disporre dell'archiviazione a lungo termine.

Gestire la documentazione sulle procedure operative standard per la valutazione e la correzione dei problemi. Le persone che operano in ambienti regolamentati devono essere istruite, informate e incoraggiate a sostenere le garanzie di sicurezza. È importante per le persone che fanno parte del processo di approvazione dal punto di vista dei criteri.

Requisito 6.1

Stabilire un processo per identificare le vulnerabilità di sicurezza, usando fonti esterne attendibili per raccogliere informazioni sulle vulnerabilità di sicurezza e assegnare una classificazione dei rischi (ad esempio alto, medio o basso) alle nuove vulnerabilità di sicurezza individuate.

Responsabilità

Disporre di processi che controllano le vulnerabilità rilevate e vengono classificati in modo appropriato. Microsoft Defender per il cloud mostra raccomandazioni e avvisi, in base al tipo di risorsa e al relativo livello di gravità e ambiente. La maggior parte degli avvisi include tattiche MITRE ATT&CK® che consentono di comprendere la finalità della kill chain. Assicurarsi di disporre di un piano di correzione per analizzare e attenuare il problema.

In AKS, è possibile usare Registro contenitori di Azure in combinazione con l'analisi continua per identificare immagini e applicazioni vulnerabili a vari livelli di rischio. È possibile visualizzare i risultati in Microsoft Defender per il cloud.

Per maggiori informazioni, consultare la sezione Protezione dei contenitori in Defender per il cloud.

Requisito 6.2

Assicurarsi che tutti i componenti di sistema e software siano protetti da vulnerabilità note tramite l'installazione delle patch di sicurezza applicabili pubblicate dai fornitori. Installare le patch di sicurezza critiche entro un mese dal rilascio.

Responsabilità

• Per evitare attacchi alla catena di approvvigionamento da fornitori di terze parti, assicurarsi che tutte le dipendenze siano attendibili. È importante scegliere fornitori affidabili e attendibili.

• Settimanalmente, AKS fornisce nuove immagini per i pool di nodi. Tali immagini non vengono applicate automaticamente. Applicarli non appena sono disponibili. È possibile aggiornare manualmente o automaticamente tramite l'aggiornamento dell'immagine del nodo. Per maggiori informazioni, consultare la sezione Aggiornamento immagine nodo di Servizio Azure Kubernetes (AKS).

  Per il piano di controllo di AKS, AKS installa o aggiorna le patch di sicurezza.

• Ogni 24 ore, i nodi AKS scaricano e installano automaticamente le patch di sicurezza e del sistema operativo, singolarmente. Il firewall non deve bloccare questo traffico se si desidera ricevere tali aggiornamenti.

  Valutare la possibilità di abilitare le funzionalità di creazione di report nell'agente di sicurezza per ottenere informazioni sugli aggiornamenti applicati. Alcuni aggiornamenti di sicurezza richiedono il riavvio. Assicurarsi di esaminare gli avvisi e intervenire per garantire un tempo di inattività minimo o zero dell'applicazione con tali riavvii. Un'opzione open source per eseguire i riavvii in modo controllato è Kured (daemon di riavvio di Kubernetes).

• Estendere il processo di applicazione di patch alle risorse esterne al cluster di cui si effettua il provisioning, ad esempio jumpbox e agenti di compilazione.

• Rimanere aggiornati con le versioni di AKS. Se la progettazione usa una versione che ha raggiunto la fine del ciclo di vita, eseguire l'aggiornamento a una versione corrente. Per maggiori informazioni, consultare la sezione Versioni AKS supportate.

Requisito 6.3

Sviluppare applicazioni software interne ed esterne (incluso l'accesso amministrativo basato su Web alle applicazioni) in modo sicuro, come segue:

• In conformità con lo standard PCI DSS (ad esempio, autenticazione e registrazione protette)
• Sulla base di standard e/o procedure consigliate del settore.
• Incorporando la sicurezza delle informazioni nel ciclo di vita dello sviluppo software che si applica a tutto il software sviluppato internamente, incluso software personalizzato o personalizzato sviluppato da terze parti.

Responsabilità

Integrare e classificare in ordine di priorità le scelte di sicurezza nell'ambito del ciclo di vita e delle operazioni del carico di lavoro.

Diversi framework di settore sono mappati al ciclo di vita, ad esempio il framework NIST. Le funzioni NIST, ovvero identificare, proteggere, rilevare, rispondere e ripristinare, forniscono strategie per i controlli preventivi in ogni fase.

Microsoft SDL (Security Development Lifecycle) fornisce procedure consigliate, strumenti e processi per la sicurezza in tutte le fasi del processo di sviluppo. Vengono seguite le procedure Microsoft SDL per tutti i servizi di Azure, incluso AKS. Si segue anche il framework Operational Security Assurance (OSA) per i servizi cloud operativi. Assicurarsi di avere un processo simile. Queste procedure vengono pubblicate per proteggere le applicazioni.

• Microsoft SDL
• Microsoft OSA

Requisito 6.3.1

Rimuovere account, ID utente e password delle applicazioni personalizzate o per lo sviluppo e/o per i test prima che le applicazioni diventano attive o vengano rilasciate ai clienti.

Responsabilità

Durante la creazione del cluster, per impostazione predefinita vengono creati più utenti Kubernetes locali. Questi utenti non possono essere controllati perché non rappresentano un'identità univoca. Alcuni di loro hanno privilegi elevati. Disabilitare gli utenti usando la funzionalità Disabilita account locali di AKS.

Per altre considerazioni, vedere le linee guida nello standard UFFICIALE PCI-DSS 3.2.1.

Requisito 6.3.2

Verificare il codice personalizzato prima del rilascio in produzione o ai clienti, allo scopo di identificare le potenziali vulnerabilità (tramite processi manuali o automatizzati), tenendo conto dei requisiti seguenti:

• Le modifiche al codice vengono verificate da utenti diversi dall'autore del codice di origine e da utenti esperti delle tecniche di revisione del codice e delle procedure per la scrittura di codice sicuro.
• Le revisioni del codice accertano che il codice sia stato sviluppato in base alle linee guida per la scrittura di codice sicuro
• Le correzioni necessarie vengono implementate prima del rilascio.
• I risultati della revisione del codice vengono esaminati e approvati dalla direzione prima del rilascio.

Responsabilità

Tutto il software installato nel cluster viene originato dal registro contenitori. Analogamente al codice dell'applicazione, i processi e gli utenti esaminano immagini di Azure e di terze parti (Dockerfile e OCI). Tenere presente anche quanto segue:

• Avviare l'analisi delle immagini del contenitore dalle fasi iniziali al momento della creazione del cluster. Rendere il processo di analisi una parte delle pipeline di integrazione continua/distribuzione continua.

  Assicurarsi che le pipeline di distribuzione siano gestite in modo che sia le immagini di bootstrap del cluster che il carico di lavoro siano passate attraverso una verifica e/o un gate di quarantena. Gestire la cronologia su come e quali processi sono stati usati prima del pull nel cluster.

• Ridurre le dimensioni dell'immagine. In genere, le immagini contengono più file binari di quanto richiesto. La riduzione delle dimensioni dell'immagine non solo offre vantaggi in termini di prestazioni, ma limita anche la superficie di attacco. Ad esempio, l'uso di immagini senza distribuzione riduce al minimo la superficie di attacco delle immagini Linux di base.

• Usare gli strumenti di analisi statica che verificano l'integrità del Dockerfile e dei manifesti. Le opzioni di terze parti includono Dockle e Trivy.

• Usare solo immagini firmate.

• Comprendere (e accettare) l'immagine di base fornita da Azure e come è conforme ai benchmark CIS. Per maggiori informazioni, consultare la sezione Center for Internet Security (CIS) Benchmarks.

Registro contenitori di Azure con l'analisi continua in Microsoft Defender per il cloud aiuterà a identificare immagini vulnerabili e vari rischi che può rappresentare per il carico di lavoro. Per maggiori informazioni sull'analisi delle immagini e sul controllo dei rischi, consultare la sezione Sicurezza dei contenitori.

Requisito 6.4

Seguire processi e procedure di controllo delle modifiche per tutte le modifiche dei componenti di sistema.

Responsabilità

Assicurarsi di documentare i processi di controllo delle modifiche e progettare le pipeline di distribuzione in base a tali processi. Includere altri processi per rilevare situazioni in cui i processi e le pipeline effettive non sono allineati.

Requisiti 6.4.1, 6.4.2

• Separare gli ambienti di sviluppo/test dagli ambienti di produzione e imporre la separazione con controlli di accesso.
• Separazione dei compiti tra gli ambienti di sviluppo/test e produzione.

Responsabilità

Gestire ambienti di produzione e pre-produzione separati e ruoli che operano in tali ambienti.

• Non usare il cluster di produzione per scopi di sviluppo/test. Ad esempio, non installare Bridge in Kubernetes nei cluster di produzione. Usare cluster dedicati per carichi di lavoro non di produzione.

• Assicurarsi che gli ambienti di produzione non consentano l'accesso di rete agli ambienti di pre-produzione e viceversa.

• Non riutilizzare le identità di sistema in ambienti di pre-produzione e produzione.

  Usare i gruppi di Microsoft Entra per gruppi, ad esempio amministratori del cluster o entità pipeline. Non usare gruppi generalizzati o comuni come controlli di accesso. Non riutilizzare tali gruppi tra cluster di pre-produzione e di produzione. Un modo consiste nell'usare il nome del cluster (o un altro identificatore opaco) nel nome del gruppo, per essere espliciti sulle appartenenze.

  Usare i ruoli di controllo degli accessi in base al ruolo (RBAC) di Azure in modo appropriato tra gli ambienti. In genere, in ambienti di pre-produzione vengono assegnati più ruoli e diritti.

  Le identità solo in fase di pre-produzione (concesse a pipeline o team di progettazione software) non devono essere concesse all'accesso nell'ambiente di produzione. Al contrario, tutte le identità di sola produzione (ad esempio le pipeline) non devono essere concesse l'accesso nei cluster di pre-produzione.

  Non usare la stessa identità gestita assegnata dall'utente per qualsiasi risorsa nella pre-produzione e nell'ambiente di produzione. Questa raccomandazione si applica a tutte le risorse che supportano le identità gestite assegnate dall'utente, non solo la risorsa distribuita nel cluster. Di norma, le risorse di Azure che richiedono identità devono avere una propria identità distinta anziché condividerla con altre risorse.

• Usare l'accesso JIT (Just-In-Time) per l'accesso con privilegi elevati, inclusi i cluster di pre-produzione, se possibile. Usare i criteri di accesso condizionale sia nei cluster di pre-produzione che in cluster di produzione.

Requisito 6.4.3

I dati di produzione (PAN attivi) non vengono usati per attività di test o sviluppo.

Responsabilità

Assicurarsi che i dati CHD non vengano trasmessi nell'ambiente di sviluppo/test. Avere una documentazione chiara che fornisce la procedura per lo spostamento dei dati dall'ambiente di produzione al sviluppo/test. La rimozione di dati reali deve essere inclusa in tale procedura e approvata da parti responsabili.

Requisito 6.4.4

Rimuovere dati e account di test dai componenti del sistema prima che il sistema diventi attivo o passi in produzione.

Responsabilità

Rimuovere i dati di configurazione predefiniti, i dati di esempio e i dati di test noti nel sistema prima della distribuzione nell'ambiente di produzione. Non usare i dati dei titolari di schede a scopo di test.

Requisito 6.4.5

Le procedure di controllo delle modifiche per l'implementazione di patch di sicurezza e modifiche del software devono includere quanto segue:

• 6.4.5.1 Documentazione dell'impatto.
• 6.4.5.2 Documentazione dell'approvazione delle modifiche da parte di parti autorizzate.
• 6.4.5.3 Test delle funzionalità per verificare che la modifica non abbia un impatto negativo sulla sicurezza del sistema.
• 6.4.5.4 Procedure di back-out.

Responsabilità

Questi punti di indicazioni sono mappati ai requisiti precedenti:

• Documentare le modifiche all'infrastruttura previste in seguito alle patch di sicurezza e alle modifiche software. Questo processo è più semplice con l'approccio IaC (Infrastructure-as-Code). Ad esempio, con un file Bicep o un modello di Azure Resource Manager (modello arm), è possibile visualizzare in anteprima le modifiche della distribuzione usando l'operazione di simulazione. Per maggiori informazioni, consultare la sezione Operazioni di simulazione della distribuzione Bicep per le modifiche all'infrastruttura.

• Implementare controlli nelle pipeline di distribuzione che convalidano l'approvazione delle modifiche per le distribuzioni regolari. Documentare la giustificazione per le distribuzioni di emergenza in cui potrebbero essere stati ignorati i controlli.

  Definire i livelli e la profondità delle modifiche. Assicurarsi che il team accetti la definizione di modifiche significative, anziché modifiche minime. Se pratico, automatizzare l'individuazione di alcune di queste modifiche. I revisori per il carico di lavoro, l'infrastruttura e la pipeline devono avere una chiara comprensione dei livelli e convalidarli in base a tali criteri.

• Testare gli inviti di sicurezza. Assicurarsi che le transazioni sintetiche stiano testando problemi di sicurezza (sia consentiti che negati). Assicurarsi anche che tali test sintetici siano in esecuzione in ambienti di pre-produzione.

• Fare in modo che un processo di backout nel caso in cui una correzione di sicurezza abbia risultati imprevisti. Una strategia comune consiste nel distribuire mantenendo lo stato precedente usando distribuzioni blu-verde. Per i carichi di lavoro, inclusi i database, avere una strategia che funzioni per la topologia specifica ed è limitato alle unità di distribuzione.

Requisito 6.5

Evitare le vulnerabilità comuni per la scrittura del codice nei processi di sviluppo del software come indicato di seguito:

• Offrire agli sviluppatori almeno ogni anno un corso di formazione sulle tecniche di scrittura del codice aggiornate, che includa informazioni su come evitare le vulnerabilità comuni per la scrittura del codice.
• Sviluppare le applicazioni in base alle linee guida per la scrittura di codice sicuro.

Responsabilità

È fondamentale che i team delle applicazioni e i team operativi siano istruiti, informati e incoraggiati a supportare le attività di analisi del carico di lavoro e dell'infrastruttura. Ecco alcune risorse:

• Linee guida per la programmazione sicura
• Secure DevOps
• Proteggere le risorse del ciclo di vita dello sviluppo

Requisito 6.6

Per le applicazioni Web pubbliche, risolvere in modo continuativo nuove minacce e vulnerabilità. Assicurarsi che queste applicazioni siano protette da attacchi noti con uno dei metodi seguenti:

• Esaminare le applicazioni Web rivolte al pubblico utilizzando strumenti o metodi di valutazione della sicurezza della vulnerabilità delle applicazioni manuali o automatizzati. Eseguire una valutazione della vulnerabilità almeno ogni anno e dopo eventuali modifiche.

  Nota

  Questa valutazione non corrisponde alle analisi delle vulnerabilità eseguite come parte del Requisito 11.2.

• Installare una soluzione automatizzata che rileva e impedisce attacchi basati sul Web. Ad esempio, un web application firewall. Distribuire davanti alle applicazioni Web pubbliche e valutare attivamente tutto il traffico.

Responsabilità

Sono stati eseguiti controlli per rilevare il traffico proveniente dalla rete Internet pubblica usando un web application firewall (WAF). In questa architettura, Gateway applicazione di Azure controlla tutto il traffico in ingresso usando il WAF integrato. Il WAF si basa sul Core Rule Set (CRS) da OWASP (Open Web Application Security Project). Se i controlli tecnici non sono presenti, dispongono di controlli di compensazione. Un modo consiste nell'ispezione manuale del codice.

Assicurarsi di usare le versioni più recenti del set di regole e di applicare regole rilevanti per il carico di lavoro. Le regole devono essere eseguite in modalità Prevenzione. È possibile imporre tale requisito aggiungendo un'istanza di Criteri di Azure che controlla se WAF è abilitato e funziona in tale modalità.

Mantenere i log generati dal WAF del gateway applicazione per ottenere informazioni dettagliate sulle minacce rilevate. Ottimizzare le regole in base alle esigenze.

Eseguire test di penetrazione incentrati sul codice dell'applicazione. In questo modo, i professionisti che non fanno parte del team dell'applicazione troveranno lacune nella sicurezza (ad esempio l'inserimento SQL e l'attraversamento della directory) raccogliendo informazioni, analizzando le vulnerabilità e segnalando. In questo esercizio, i professionisti potrebbero dover accedere ai dati sensibili. Per assicurarsi che la finalità non venga utilizzata in modo improprio, seguire le indicazioni fornite in Regole di engagement per i test di penetrazione.

Requisito 6.7

Assicurarsi che i criteri di sicurezza e le procedure operative per lo sviluppo e la manutenzione di sistemi e applicazioni sicuri siano documentati, applicati e noti a tutte le parti interessate.

Responsabilità

È fondamentale mantenere una documentazione completa sui processi e sui criteri. I team devono essere sottoposti a training per assegnare priorità alle scelte di sicurezza nell'ambito del ciclo di vita e delle operazioni del carico di lavoro.

Microsoft SDL offre procedure consigliate, strumenti e processi per la sicurezza in tutte le fasi del processo di sviluppo. Le procedure Microsoft SDL vengono seguite rigorosamente quando creiamo software in Microsoft. Si segue anche il framework Operational Security Assurance (OSA) per i servizi cloud operativi. Queste procedure vengono pubblicate per proteggere le applicazioni.

• Microsoft SDL
• Microsoft OSA

Mantenere una documentazione completa per i test di penetrazione che descrivono l'ambito del test, dei processi di valutazione e della strategia di correzione per i problemi rilevati. Se si verifica un evento imprevisto, incorporare la valutazione del Requisito 6 come parte dell'analisi della causa radice. Se vengono rilevate lacune (ad esempio, viene rilevata una violazione della regola OWASP), chiudere tali lacune.

Nella documentazione sono disponibili linee guida chiare sullo stato di protezione WAF previsto.

Le persone che operano in ambienti regolamentati devono essere istruite, informate e incoraggiate a sostenere le garanzie di sicurezza. È importante per le persone che fanno parte del processo di approvazione dal punto di vista dei criteri.

Passaggi successivi

Limitare l'accesso ai dati di titolari di schede al personale autorizzato per motivi professionali. Identificare e autenticare l'accesso ai componenti di sistema. Limitare l'accesso fisico ai dati di titolari di schede.