Considerazioni sulla conformità di container e Kubernetes

Se utilizzi i container sei consapevole dei potenziali rischi per la sicurezza. Probabilmente hai adottato un approccio DevOps per i flussi di lavoro oppure potresti avere una pipeline CI/CD ben consolidata ma desideri proteggere i tuoi dati sensibili.

Il controllo degli accessi basato sui ruoli (RBAC) fornisce il metodo standard per la gestione dell'autorizzazione per gli endpoint dell'API Kubernetes. La configurazione dell'RBAC del cluster Kubernetes controlla quali soggetti possono eseguire determinati verbi e su quali tipi di risorse e in quali spazi dei nomi, tuttavia il controllo RBAC non prescrive come configurare i ruoli, ed è qui che entrano in gioco i framework di conformità.

In molti settori, soddisfare i requisiti di conformità è una parte necessaria dell'attività. Sebbene inizialmente i problemi di conformità potevano rappresentare un ostacolo alla creazione e all'esecuzione di applicazioni containerizzate e cloud native, i framework e le tecnologie si stanno evolvendo rapidamente, rendendo possibile una conformità completa negli ambienti cloud native. I principali framework di conformità relativi alle applicazioni containerizzate sono:

• Benchmark CIS per Kubernetes e Docker
• NIST SP 800-190
• PCI
• HIPAA

La conformità di fatto consiste nel garantire che le tue applicazioni siano sicure. Poiché le normative richiedono che anche le organizzazioni siano in grado di dimostrare a terzi che le applicazioni sono costantemente sicure, la semplice protezione dell'applicazione non è sufficiente per soddisfare i requisiti di conformità. Implica anche il monitoraggio e la conservazione di registri per dimostrare un rispetto costante della conformità.

La conformità può essere impegnativa, ma il mancato rispetto degli standard di conformità può essere ancora più gravoso in termini monetari: la spesa media per le multe relative alle violazioni della conformità è quasi tre volte il costo medio richiesto per soddisfare i requisiti di conformità.

Gli standard di conformità possono avere un ruolo importante anche nel modo in cui le organizzazioni definiscono le policy di governance della sicurezza. Invece di creare linee guida da zero, le organizzazioni, anche quelle che non sono tenute a soddisfare le linee guida di un framework specifico, possono utilizzare i framework di conformità come punto di partenza per definire i propri criteri interni.

I framework

Benchmark CIS: sviluppati dal Center for Internet Security, i benchmark CIS forniscono best practice per i container, in particolare quelli che utilizzano il runtime Docker e Kubernetes, ma non sono vincolanti per nessun settore.

NIST 800-190: il framework del National Institute of Standards and Technology per la sicurezza dei container è uno dei tanti framework di conformità in materia di sicurezza informatica pubblicati dal National Institute of Standards and Technology. Tutte le agenzie del governo federale degli Stati Uniti e le imprese che lavorano per il governo devono soddisfare i requisiti NIST 800-190.

PCI: sviluppato da una partnership composta da cinque importanti società di carte di credito, il framework Payment Card Industry (PCI) riguarda le organizzazioni che archiviano, elaborano o trasmettono informazioni di pagamento.

HIPAA: le protezioni tecnologiche della normativa HIPAA riguardano il modo in cui le organizzazioni raccolgono, elaborano o trasmettono informazioni sanitarie protette elettroniche identificabili individualmente.

La pubblicazione speciale 800-190 del National Institute of Standards and Technology (NIST 800-190) offre un quadro di riferimento per comprendere alcune delle sfide specifiche relative alla protezione delle applicazioni containerizzate, nonché le misure che le organizzazioni devono adottare per migliorare il profilo di sicurezza delle applicazioni.

Le linee guida NIST sono rivolte alle agenzie governative degli Stati Uniti e alle imprese che lavorano per il governo; tuttavia, qualsiasi azienda potrebbe essere interessata a seguire le linee guida NIST 800-190, sia per migliorare la sicurezza generale sia perché possono facilitare l'adeguamento ad altri framework di conformità come PCI e HIPAA.

I rischi

Le linee guida NIST 800-190 evidenziano le fonti comuni di vulnerabilità della sicurezza nelle applicazioni containerizzate, tra cui:

• Immagini compromesse
• Configurazioni errate nelle immagini dei container
• Immagini dei container non attendibili
• Segreti gestiti in modo inadeguato
• Controlli degli accessi configurati in modo errato
• Vulnerabilità del sistema operativo
• Superfici di attacco inutilmente grandi

Un aspetto altrettanto importante evidenziato nelle linee guida NIST 800-190 è la necessità, da parte delle aziende, di adottare un diverso approccio alla sicurezza per le applicazioni containerizzate rispetto alle applicazioni tradizionali. Le applicazioni containerizzate hanno fattori di rischio diversi rispetto alle macchine virtuali e richiedono un diverso insieme di pratiche di sicurezza.

Le linee guida NIST 800-190 richiedono alle organizzazioni di:

• Utilizzare strumenti appositamente progettati per gestire le vulnerabilità delle immagini durante l'intero ciclo di vita dell'immagine, dalla creazione alla distribuzione e al runtime.
• Assicurarsi che le immagini siano conformi alle best practice di configurazione.
• Proteggere i segreti archiviandoli all'esterno dell'immagine, utilizzando Kubernetes per la gestione, limitare l'accesso ai segreti per i container che ne hanno bisogno e crittografare i segreti inattivi e in transito.
• Utilizzare una connessione sicura quando si esegue il push o il pull dal registro.
• Assicurarsi che il container utilizzi sempre l'ultima versione dell'immagine.
• Segmentare il traffico di rete, almeno per isolare le reti sensibili da quelle non sensibili.
• Usare Kubernetes per introdurre i nodi in modo sicuro e mantenere un inventario dei nodi e dei loro stati di connettività.
• Controllare il traffico in uscita dai container.
• Garantire la conformità continua con gli standard di configurazione del runtime dei container come i benchmark CIS.
• Utilizzare i controlli di sicurezza per rilevare minacce e potenziali intrusioni a livello di container e infrastruttura.
• Utilizzare un sistema operativo rinforzato e specifico per i container con una superficie di attacco il più piccola possibile.
• Prevenire la manomissione del file system dell'host assicurando che i container dispongano del minor numero di autorizzazioni possibile per funzionare come previsto.

Anche le organizzazioni che non hanno bisogno di conformarsi ai requisiti NIST 800-190 dovrebbero considerarli un riferimento utile per migliorare il profilo di sicurezza della propria organizzazione. Questi requisiti fanno sì che le organizzazioni tengano conto della sicurezza durante le fasi di compilazione, deployment e runtime, soddisfacendo in ogni fase i requisiti di sicurezza necessari.

Il Payment Card Industry Data Security Standard (PCI DSS) è stato creato nel 2004 da Visa, MasterCard, American Express, Discover e JCP per creare uno standard di settore per la sicurezza e la protezione dei dati. Gli standard sono stati aggiornati molte volte da quando sono stati rilasciati per la prima volta, per stare al passo con i cambiamenti tecnologici. Si applicano all'intero ambiente dei dati dei titolari di carta, ovvero le persone, i processi e le tecnologie che archiviano, elaborano o trasmettono i dati dei titolari di carta. In termini di tecnologia, questo include sia hardware che software.

Rispettare i requisiti PCI non è facile e costa alle aziende in media 5,5 milioni di dollari all'anno. Tuttavia, il mancato rispetto della conformità è molto più costoso, con un costo medio annuo delle sanzioni di 14,8 milioni di dollari. Con i giusti processi e strumenti in atto, la conformità PCI non deve essere per forza un problema insormontabile.

Lo standard PCI DSS ha 12 requisiti che sono associati a 6 obiettivi più generali. ovvero:

Creare e mantenere un sistema di rete sicuro

1. Installare e mantenere una configurazione firewall per proteggere i dati dei titolari di carta
2. Non utilizzare le impostazioni predefinite fornite dal fornitore per le password di sistema e altri parametri di sicurezza

Proteggere i dati dei titolari di carta

1. Proteggere i dati dei titolari di carta memorizzati
2. Crittografare la trasmissione dei dati dei titolari di carta su reti pubbliche aperte

Garantire il mantenimento dei programmi di gestione delle vulnerabilità

1. Proteggere tutti i sistemi da malware ed exploit e aggiornare regolarmente il software antivirus
2. Sviluppare e mantenere sistemi e applicazioni sicuri
3. Implementare una forte misura di controllo degli accessi

Limitare l'accesso ai dati dei titolari di carta per azienda in funzione delle necessità

1. Identificare e autenticare l'accesso ai componenti del sistema
2. Limitare l'accesso fisico ai dati dei titolari di carta

Monitorare e testare regolarmente le reti

1. Tracciare e monitorare tutti gli accessi alle risorse di rete e ai dati dei titolari di carta
2. Testare regolarmente i sistemi e i processi di sicurezza

Garantire il mantenimento delle policy di sicurezza delle informazioni

1. Mantenere una policy che gestisca la sicurezza delle informazioni per tutto il personale

Conformità PCI per applicazioni containerizzate

Esistono diversi requisiti relativi a ciascuno dei sei obiettivi sopra delineati dal settore PCI che sono direttamente rilevanti per gli ambienti container e Kubernetes. Valuta gli strumenti di sicurezza del container e di Kubernetes per assicurarti che possano soddisfare questi requisiti:

1.12 Schema di rete attuale che identifica tutte le connessioni tra l'ambiente dei dati dei titolari di carta (CDE) e altre reti, comprese eventuali reti wireless.

1.1.4 Requisiti per un firewall a ogni connessione Internet e tra qualsiasi zona demilitarizzata (DMZ) e la zona della rete interna.

1.2 Creare configurazioni di firewall e router che limitano le connessioni tra reti non attendibili e qualsiasi componente di sistema nell'ambiente dei dati dei titolari di carta.

1.2.1 Limitare il traffico in entrata e in uscita a quanto strettamente necessario per l'ambiente dei dati dei titolari di carta e negare specificamente tutto il resto del traffico.

1.3.2 Limitare il traffico Internet in entrata agli indirizzi IP all'interno della DMZ.

1.3.4 Non consentire traffico in uscita non autorizzato dall'ambiente dei dati dei titolari di carta a Internet.

1.3.5 Consentire solo connessioni "accertate" nella rete.

2.1 Modificare sempre le impostazioni predefinite fornite dal fornitore e rimuovere o disabilitare gli account predefiniti non necessari prima di installare un sistema sulla rete.

2.2 Sviluppare standard di configurazione per tutti i componenti del sistema. Assicurarsi che questi standard risolvano tutte le vulnerabilità di sicurezza note e siano coerenti con gli standard di rafforzamento del sistema accettati dal settore.

2.2.1 Implementare una sola funzione primaria per server per impedire la coesistenza di funzioni che richiedono livelli di sicurezza diversi sullo stesso server. (Ad esempio, i server Web, i server di database e DNS dovrebbero essere implementati su server separati).

2.2.2 Abilitare solo i servizi, i protocolli, i daemon, ecc. necessari, come richiesto per il funzionamento del sistema.

2.2.3 Implementare funzionalità di sicurezza aggiuntive per tutti i servizi, protocolli o daemon necessari considerati non sicuri.

2.2.5 Rimuovere tutte le funzionalità non necessarie, come script, driver, funzionalità, sottosistemi, file system e server Web non necessari.

2.3 Crittografare tutti gli accessi amministrativi non da console utilizzando la crittografia avanzata.

2.4 Mantenere un inventario dei componenti di sistema che rientrano nell'ambito dello standard PCI DSS.

3.6.2 Proteggere la distribuzione delle chiavi crittografiche.

6.1 Stabilire un processo per identificare le vulnerabilità della sicurezza, utilizzando fonti esterne affidabili per le informazioni sulle vulnerabilità della sicurezza e assegnare una classificazione del livello di rischio (ad esempio, "alto", "medio" o "basso") alle vulnerabilità della sicurezza scoperte di recente.

6.2 Assicurarsi che tutti i componenti di sistema e il software siano protetti dalle vulnerabilità note installando le patch di sicurezza fornite dal fornitore. Installare le patch di sicurezza critiche entro un mese dal rilascio.

6.4.1 Separare gli ambienti di sviluppo/test dagli ambienti di produzione e far rispettare la separazione con gli strumenti di accesso.

6.4.2 Separazione dei compiti tra ambiente di sviluppo/test e di produzione.

6.5.1 Errori di inserimento, in particolare inserimento SQL. Considerare anche gli errori di inserimento di LDAP e XPath e dei comandi del sistema operativo, nonché altri errori di inserimento.

6.5.3 Storage crittografico non sicuro.

6.5.4 Comunicazioni non sicure.

6.5.6 Tutte le vulnerabilità "ad alto rischio" identificate nel processo di identificazione delle vulnerabilità (come definito nel Requisito 6.1 PCI DSS).

10.2.5 Implementare audit trail automatizzati per tutti i componenti del sistema per ricostruire l'uso e le modifiche ai meccanismi di identificazione e autenticazione, inclusi, a titolo esemplificativo, la creazione di nuovi account e l'elevazione dei privilegi e tutte le modifiche, aggiunte o eliminazioni degli account con privilegi di root o amministrativi.

11.2.1 Eseguire scansioni alla ricerca di vulnerabilità interne trimestrali. Risolvere le vulnerabilità ed eseguire nuove scansioni per verificare che tutte le vulnerabilità "ad alto rischio" siano risolte in conformità con la classificazione delle vulnerabilità dell'entità (secondo il Requisito 6.1). Le scansioni devono essere eseguite da personale qualificato.

11.5 Implementare un meccanismo di rilevamento delle modifiche (ad esempio, strumenti di monitoraggio dell'integrità dei file) per avvisare il personale di cambiamenti non autorizzati (incluse modifiche, aggiunte ed eliminazioni) nei file di sistema critici, file di configurazione o file di contenuto; e configurare il software per eseguire confronti di file critici almeno settimanalmente.

11.5.1 Implementare un processo per rispondere a qualsiasi avviso generato dalla soluzione di rilevamento delle modifiche.

L'Health Information Portability and Accountability Act del 1996 ha creato il quadro di conformità HIPAA per disciplinare la privacy dei pazienti in relazione a tutte le cartelle cliniche. La Security Rule, aggiunta nel 2003, disciplina i record sanitari digitali. Qualsiasi organizzazione che gestisca informazioni sanitarie protette elettroniche (ePHI) identificabili individualmente deve soddisfare i requisiti HIPAA. Ciò include le applicazioni utilizzate direttamente dagli operatori sanitari per l'assistenza, le comunicazioni o la fatturazione.

La sfida principale per la conformità HIPAA è che il framework di sicurezza fornisce solo linee guida generali piuttosto che specifiche su come le organizzazioni dovrebbero soddisfare tali linee guida negli ambienti di container e Kubernetes. Inoltre, la differenza tra ciò che costituisce e non costituisce un'informazione sanitaria protetta è spesso meno evidente rispetto, ad esempio, a ciò che contraddistingue un'informazione della carta di credito che deve essere protetta in conformità con gli standard PCI.

Oltre agli stessi fornitori di servizi sanitari, qualsiasi organizzazione che fornisce servizi come lo storage o la fatturazione ai fornitori di servizi sanitari deve soddisfare i requisiti HIPAA se i servizi che fornisce comportano la gestione di informazioni sanitarie personali elettroniche (ePHI).

Gli standard della Security Rule HIPAA sono suddivisi in tutele amministrative, fisiche e tecniche. Le tutele tecniche, che riguardano l'infrastruttura informatica, comprendono i seguenti criteri:

• Controllo degli accessi
• Audit control
• Integrità
• Autenticazione
• Sicurezza della trasmissione

La Security Rule HIPAA non fornisce dettagli precisi su come le organizzazioni dovrebbero proteggere le informazioni ePHI e non è specifica per le applicazioni containerizzate. Spesso, il miglior punto di partenza per adempiere ai requisiti della conformità HIPAA è applicare il framework NIST SP 800-190, che fornisce linee guida e best practice per la sicurezza dei container. A differenza dei requisiti HIPAA, le linee guida NIST SP 800-190 forniscono un framework specifico per i container e può quindi essere più facile dimostrare la conformità. Tuttavia, soddisfare i requisiti HIPAA implica l'implementazione di ulteriori controlli di segregazione dei dati per proteggere le informazioni ePHI e tenerle separate da altri tipi di dati.

HIPAA richiede inoltre che le organizzazioni conservino backup, non solo dei dati ma anche dei file di configurazione, in modo che l'applicazione possa essere completamente ripristinata per dimostrare il continuo rispetto della conformità.