Che cos'è la sicurezza dei container?

La sicurezza dei container implica la protezione delle applicazioni containerizzate e della loro infrastruttura durante tutto il loro ciclo di vita, dallo sviluppo alla distribuzione e alla protezione runtime. Comprende la scansione delle vulnerabilità, la gestione della configurazione, il controllo degli accessi, la segmentazione della rete e il monitoraggio. La sicurezza dei container mira a massimizzare i vantaggi intrinseci dell'isolamento delle applicazioni, minimizzando i rischi associati alla condivisione delle risorse e alla potenziale superficie di attacco. Aderendo alle best practice e utilizzando strumenti di sicurezza specializzati, le organizzazioni possono salvaguardare il loro ambiente container da accessi non autorizzati e violazioni di dati , mantenendo la conformità alle normative del settore.

 

Spiegazione della sicurezza dei container

I container ci danno la possibilità di sfruttare le architetture di microservizi e di operare con maggiore velocità e portabilità. I container introducono anche vantaggi intrinseci di sicurezza. L'isolamento del carico di lavoro , l'astrazione delle applicazioni e la natura immutabile dei container, infatti, influiscono pesantemente sulla loro adozione.

Kubernetes, inoltre, offre funzioni di sicurezza integrate. Gli amministratori possono definire politiche di controllo dell'accesso basate sui ruoli (RBAC) per evitare accessi non autorizzati alle risorse del cluster. Possono configurare le politiche di sicurezza dei pod e le politiche di rete per impedire determinati tipi di abuso sui pod e sulla rete che li collega. Gli amministratori possono imporre quote di risorse per mitigare l'interruzione causata da un aggressore che compromette una parte di un cluster. Con le quote di risorse in atto, ad esempio, un aggressore non sarà in grado di eseguire un attacco denial-of-service privando il resto del cluster delle risorse necessarie per funzionare.

Ma come avrà capito, nessuna tecnologia è immune da attività dannose. La sicurezza dei container, le tecnologie e le pratiche implementate per proteggere non solo le sue applicazioni, ma anche l'ambiente containerizzato - dagli host, i runtime e i registri alle piattaforme di orchestrazione e ai sistemi sottostanti - è fondamentale.

Video: Rileva le vulnerabilità nelle immagini container e assicura la sicurezza e la conformità durante tutto il ciclo di vita dello sviluppo con la scansione dei container.

Sfondo

La sicurezza dei container riflette la natura mutevole dell'architettura IT. L'ascesa del cloud-native computing ha modificato radicalmente il modo in cui creiamo le applicazioni. Per stare al passo con la tecnologia, dobbiamo adeguare il nostro approccio alla sicurezza.

In passato, la cybersecurity significava proteggere un singolo perimetro. I container rendono questo concetto obsoleto, avendo aggiunto più livelli di astrazione che richiedono strumenti specializzati per interpretare, monitorare e proteggere i nostri ambienti containerizzati.

L'ecosistema dei container può essere difficile da comprendere, data la pletora di strumenti e i problemi unici che risolvono rispetto alle piattaforme tradizionali. Allo stesso tempo, l'adozione diffusa delle tecnologie dei container ci offre l'opportunità di spostarci a sinistra, mettendo in sicurezza i container dalle prime fasi della pipeline CI/CD fino alla distribuzione e al runtime.

Ma prima di immergersi nei dettagli della sicurezza dei container, è necessario comprendere le piattaforme utilizzate per la gestione dei container. Ci concentreremo su una delle piattaforme più grandi e conosciute, Kubernetes.

Che cos'è Kubernetes?

Kubernetes è una delle principali piattaforme di orchestrazione che aiuta a ottimizzare e implementare un'infrastruttura basata su container. Più precisamente, si tratta di una piattaforma open-source utilizzata per gestire carichi di lavoro containerizzati automatizzando processi come lo sviluppo, la distribuzione e la gestione delle applicazioni.

In quanto piattaforma open-source ampiamente adottata, la sicurezza di Kubernetes è fondamentale per le organizzazioni che distribuiscono applicazioni containerizzate. Le organizzazioni devono creare un ambiente sicuro, in particolare quando incorporano codice open-source in applicazioni di terze parti. Kubernetes, con il suo ampio ecosistema e le numerose integrazioni per la gestione dei container, consente di creare processi automatizzati e sistematici che integrano la sicurezza nel cuore della pipeline di costruzione e distribuzione. Sfruttando le caratteristiche native di Kubernetes, come RBAC, le politiche di sicurezza dei pod e le politiche di rete, le organizzazioni possono costruire e mantenere una solida posizione di sicurezza con un'infrastruttura di orchestrazione dei container resiliente.

Vantaggi dei contenitori

In parole povere, i container rendono la creazione, la distribuzione e la scalabilità delle applicazioni cloud-native più facile che mai. Per gli sviluppatori di app cloud-native, i vantaggi principali dei container includono:

  1. Eliminare l'attrito: Gli sviluppatori evitano gran parte dell'attrito associato al trasferimento del codice dell'applicazione dai test alla produzione, poiché il codice dell'applicazione confezionato come container può essere eseguito ovunque.
  2. Unica fonte di verità per lo sviluppo delle applicazioni: Tutte le dipendenze associate all'applicazione sono incluse nel contenitore. Ciò consente all'applicazione di essere eseguita in modo semplice e identico su macchine virtuali, server bare metal e cloud pubblico.
  3. Tempi di costruzione più rapidi: La flessibilità e la portabilità dei container consente agli sviluppatori di ottenere guadagni di produttività prima irraggiungibili.
  4. Fiducia per gli sviluppatori: Gli sviluppatori possono distribuire le loro applicazioni con fiducia, sapendo che la loro applicazione o piattaforma funzionerà allo stesso modo su tutti i sistemi operativi.
  5. Collaborazione rafforzata: Più team che utilizzano i container possono lavorare su singole parti di un'applicazione o di un servizio senza interrompere il codice confezionato in altri container.

Come qualsiasi architettura IT, le applicazioni cloud-native richiedono sicurezza. Gli ambienti di container portano con sé una serie di sfide di cybersecurity che riguardano le immagini, i container, gli host, i runtime, i registri e le piattaforme di orchestrazione, tutte da affrontare.

 

Comprendere la superficie di attacco.

Consideri la struttura tentacolare e multistrato di Kubernetes. Ogni livello - dal codice e dai container ai cluster e ai servizi cloud di terze parti - pone una serie distinta di sfide alla sicurezza.

Proteggere le distribuzioni Kubernetes richiede la protezione dell'infrastruttura sottostante (nodi, bilanciatori di carico, ecc.), dei componenti configurabili e delle applicazioni che vengono eseguite nel cluster - compreso il mantenimento della postura dei nodi sottostanti e il controllo dell'accesso all'API e a Kubelet. È anche importante impedire l'esecuzione di carichi di lavoro dannosi nel cluster e isolare la comunicazione dei carichi di lavoro attraverso rigorosi controlli di rete.

I runtime dei container possono essere soggetti a difetti di codifica che consentono l'escalation dei privilegi all'interno di un container. Il server API di Kubernetes potrebbe essere configurato in modo improprio, dando agli aggressori l'opportunità di accedere a risorse che si presume siano bloccate. Le vulnerabilità che consentono attacchi di escalation dei privilegi potrebbero esistere all'interno di un'applicazione containerizzata o nei sistemi operativi in esecuzione sui nodi Kubernetes.

Anatomia della superficie di attacco dei container.

Figura 1: Anatomia della superficie di attacco dei container.

In questo sistema, un problema a un livello viene amplificato quando un altro livello ha un problema di sicurezza.

E i contenitori possono, ovviamente, ospitare delle vulnerabilità. Allo stesso tempo, i contenitori possono oscurare la visibilità. Immaginiamo un'unica immagine insicura istanziata numerose volte come contenitori in esecuzione separati. Quella che era una singola crepa è ora una vasta rete di fessure nella fortezza.

L'imperativo di mantenere la visibilità sulle operazioni di sistema e sulla sicurezza, mentre si distribuiscono sempre più container, diventa sempre più impegnativo. E questo è solo mantenere la visibilità, uno degli innumerevoli obiettivi.

La Figura 1, con dettagli più ampi delineati nella Tabella 1, offre un punto di partenza per comprendere la superficie di attacco delle applicazioni containerizzate.

È importante notare che la rappresentazione è semplificata. In realtà, gli aggressori hanno numerose strade da esplorare nel tentativo di sfruttare le vulnerabilità nelle applicazioni containerizzate. La difesa di questo stack tecnologico non è necessariamente più scoraggiante della sicurezza di altri ambienti e tecnologie. La containerizzazione presenta solo considerazioni di sicurezza uniche che le organizzazioni devono affrontare per un'infrastruttura sicura e resiliente.

Superficie d'attacco Vettore di attacco Descrizione Esempio
Via rete Traffico di rete dannoso Sfruttare le vulnerabilità della rete o le configurazioni errate per ottenere l'accesso all'ambiente del container. Esegue la scansione delle porte aperte e sfrutta le configurazioni errate per ottenere l'accesso ai nodi worker.
Configurazione dell'host Sistema host configurato in modo errato Sfruttare le configurazioni errate nel sistema operativo host per ottenere l'accesso all'ambiente del container. Scoprire permessi di file insicuri per accedere a file sensibili, come i file di configurazione dei container.
Vulnerabilità dell'host Vulnerabilità host non patchate Sfruttare le vulnerabilità del sistema operativo host per ottenere l'accesso all'ambiente del container. Identificare e sfruttare le vulnerabilità del kernel senza patch per ottenere i privilegi di root sui nodi worker.
Vulnerabilità delle applicazioni host Vulnerabilità delle applicazioni host senza patch Sfruttare le vulnerabilità nelle applicazioni host per ottenere l'accesso all'ambiente del container. Si rivolge alle vecchie versioni di Docker con vulnerabilità per ottenere privilegi di root sui nodi worker.
Vulnerabilità e misconfigurazioni dell'orchestrazione dei container Orchestrazione dei container configurata in modo errato Sfruttare le configurazioni errate nel sistema di orchestrazione dei container per ottenere l'accesso all'ambiente dei container. Sfruttare le politiche di controllo degli accessi non sicure nei cluster Kubernetes per accedere a pod e servizi.
Immagini container compromesse L'attaccante ottiene l'accesso al processo di creazione dell'immagine container Compromettere il processo di creazione dell'immagine container per iniettare codice dannoso nelle immagini container. Sfruttamento di vulnerabilità in Pipeline CI/CD per iniettare codice dannoso durante il processo di creazione dell'immagine container.
Vulnerabilità e errori di configurazione dei contenitori Vulnerabilità dei contenitori senza patch Sfruttare le vulnerabilità del contenitore stesso per ottenere l'accesso all'ambiente del contenitore. Puntano a vulnerabilità non patchate in applicazioni popolari che girano all'interno di container per ottenere l'accesso.
Fuga del contenitore L'attaccante ottiene un accesso privilegiato al contenitore Uscire dall'isolamento del contenitore e ottenere l'accesso al sistema host. Sfruttare le vulnerabilità nel runtime del container o abusare delle configurazioni errate del sistema host per ottenere i privilegi di root sul sistema host.

Tabella 1: Scomposizione della superficie di attacco dei container.

Fortunatamente, ogni livello della superficie di attacco può essere rafforzato grazie a considerazioni sulla progettazione e sui processi, nonché a opzioni di sicurezza native e di terze parti per ridurre il rischio di carichi di lavoro compromessi. Avrà bisogno di una strategia poliedrica, ma il nostro obiettivo in questa sezione della guida è di fornirle proprio questo.

Figura 2: La sicurezza dei container riguarda l'intero ciclo di vita dello sviluppo del software.

Figura 2: La sicurezza dei container riguarda l'intero ciclo di vita dello sviluppo del software.

 

Come mettere in sicurezza i contenitori

Gli utenti di container devono assicurarsi di avere una sicurezza full-stack costruita ad hoc, per affrontare i requisiti di gestione delle vulnerabilità, conformità, protezione runtime e sicurezza di rete delle loro applicazioni containerizzate.

Sicurezza di rete dei container

Le applicazioni containerizzate affrontano gli stessi rischi delle applicazioni bare metal e basate su VM, come il cryptojacking, il ransomware e la BotNet C2. La sicurezza di rete del container limita in modo proattivo le comunicazioni indesiderate e impedisce alle minacce di attaccare le sue applicazioni attraverso una moltitudine di strategie. I componenti chiave della sicurezza di rete riguardano la microsegmentazione, il controllo degli accessi, la crittografia e le politiche per mantenere un ambiente sicuro e resiliente. Il monitoraggio continuo, la registrazione e gli audit regolari aiutano a identificare e correggere le potenziali lacune nella sicurezza, così come le patch tempestive per mantenere aggiornate le sue piattaforme e infrastrutture.

Mentre gli strumenti di sicurezza shift-left offrono una protezione in fase di distribuzione contro le vulnerabilità note, i firewall containerizzati di prossima generazione proteggono dalle vulnerabilità sconosciute e non patchate. Eseguendo l'ispezione deep-packet Layer 7 e la scansione di tutto il traffico consentito, identificano e impediscono l'ingresso e la diffusione di malware all'interno del cluster e bloccano le connessioni malevole in uscita utilizzate per l'esfiltrazione dei dati e gli attacchi di comando e controllo (C2). La microsegmentazione basata su identità aiuta a limitare la comunicazione tra le applicazioni al Livello 3 e 4.

Sicurezza del runtime del contenitore

La sicurezza runtime nativa del cloud è il processo di identificazione di nuove vulnerabilità nei container in esecuzione e di protezione dell'applicazione contro di esse. Le organizzazioni che utilizzano i container dovrebbero sfruttare la protezione runtime avanzata per stabilire le linee di base comportamentali su cui si basa il rilevamento delle anomalie. La sicurezza di rete può identificare e bloccare processi, file e comportamenti di rete dannosi che si discostano da una linea di base.

Utilizzando una strategia di difesa in profondità per prevenire gli attacchi di livello 7, come la Top 10 di OWASP, le organizzazioni dovrebbero implementare la protezione runtime con la sicurezza delle applicazioni web e delle API , oltre alla sicurezza di rete dei container tramite firewall containerizzati di prossima generazione.

Sicurezza del registro dei container

Introdurre la sicurezza nella fase di creazione del container significa spostarsi a sinistra invece che in modo reattivo al momento dell'esecuzione. La sicurezza della fase di costruzione deve concentrarsi sulla rimozione delle vulnerabilità, del malware e del codice insicuro. Poiché i container sono composti da librerie, binari e codice applicativo, è fondamentale proteggere i registri dei container.

Il primo passo per la sicurezza del registro container è stabilire un registro container ufficiale per la sua organizzazione. Senza dubbio, uno o più registri esistono già. È compito del team di sicurezza trovarli e assicurarsi che siano adeguatamente protetti, il che include la definizione di standard e protocolli di sicurezza. L'obiettivo generale degli standard di sicurezza del registro dei container dovrebbe essere incentrato sulla creazione di immagini affidabili. A tal fine, DevOps e i team addetti alla sicurezza devono allinearsi sulle politiche che, in primo luogo, impediscono ai container di essere distribuiti da registri non attendibili.

Le intrusioni o le vulnerabilità all'interno del registro offrono una facile apertura per compromettere le applicazioni in esecuzione. Il monitoraggio continuo dei registri per verificare la variazione dello stato di vulnerabilità rimane un requisito fondamentale per la sicurezza. Altri requisiti includono il blocco del server che ospita il registro e l'utilizzo di politiche di accesso sicure.

Sicurezza dell'orchestrazione dei container

La sicurezza dell'orchestrazione dei container è il processo di attuazione di misure adeguate di controllo degli accessi per prevenire i rischi derivanti da account con privilegi eccessivi, attacchi in rete e movimenti laterali indesiderati. Sfruttando la gestione dell'accesso all'identità (IAM) e l'accesso meno privilegiato, dove l'attività di Docker e Kubernetes è esplicitamente inserita nella whitelist, i team addetti alla sicurezza e all'infrastruttura possono garantire che gli utenti eseguano solo comandi basati sui ruoli appropriati.

Inoltre, le organizzazioni devono proteggere le comunicazioni pod-to-pod, limitare i danni impedendo agli aggressori di muoversi lateralmente nel loro ambiente e proteggere qualsiasi servizio frontend dagli attacchi.

Sicurezza del sistema operativo host (OS)

La sicurezza del sistema operativo host è la pratica di proteggere il suo sistema operativo (OS) da un attacco informatico. Con la crescita della tecnologia di sviluppo di app cloud-native, cresce anche la necessità di sicurezza dell'host.

Il sistema operativo che ospita il suo ambiente container è forse il livello più importante quando si tratta di sicurezza. Un attacco che compromette l'ambiente host potrebbe consentire agli intrusi di accedere a tutte le altre aree del suo stack. Ecco perché gli host devono essere scansionati per le vulnerabilità, temprati per soddisfare i benchmark CIS e protetti contro i controlli di accesso deboli (comandi Docker, comandi SSH, comandi sudo, ecc.).

 

Soluzioni per la sicurezza dei container

La sicurezza dell'ambiente containerizzato richiede un approccio multilivello per affrontare le potenziali vulnerabilità e minacce. Negli ultimi anni, le soluzioni di sicurezza container su cui le organizzazioni possono contare per salvaguardare le applicazioni e l'infrastruttura containerizzate durante le fasi di sviluppo, distribuzione e runtime hanno acquisito maggiore sofisticazione e capacità. I moderni strumenti di sicurezza minimizzano efficacemente i rischi di violazioni e fughe di dati, promuovendo la conformità e mantenendo ambienti sicuri, accelerando al contempo l'adozione di DevSecOps .

Monitoraggio dei contenitori

La capacità di monitorare il registro per le vulnerabilità è essenziale per mantenere la sicurezza dei container. Poiché gli sviluppatori strappano e sostituiscono continuamente i container, gli strumenti di monitoraggio che consentono ai team addetti alla sicurezza di applicare i timbri delle serie temporali ai container sono fondamentali quando si cerca di determinare cosa è successo in un ambiente containerizzato.

Gli strumenti più diffusi per il monitoraggio dei container includono Prometheus, Grafana, Sumo Logic e Prisma Cloud. Prisma Cloud offre il rilevamento delle minacce in runtime e l'analisi delle anomalie sia per le applicazioni cloud-native che per quelle tradizionali. Sfrutta l'apprendimento automatico e l'analisi comportamentale per identificare le attività sospette nell'intero ciclo di vita dei container, dalla creazione all'esecuzione.

Strumenti di scansione dei contenitori

I container devono essere sottoposti a una scansione continua delle vulnerabilità, sia prima di essere distribuiti in un ambiente di produzione, sia dopo essere stati sostituiti. È troppo facile per gli sviluppatori includere per errore una libreria in un contenitore che presenta vulnerabilità note. È anche importante ricordare che quasi ogni giorno vengono scoperte nuove vulnerabilità. Ciò significa che ciò che oggi può sembrare un'immagine container perfettamente sicura, domani potrebbe diventare il veicolo attraverso il quale vengono distribuiti tutti i tipi di malware. Ecco perché il mantenimento della fiducia dell'immagine container è un componente centrale degli strumenti di scansione dei container.

Gli strumenti di scansione dei container includono Aqua Security, Anchore, Clair e Prisma Cloud. Prisma Cloud offre la scansione delle vulnerabilità a livello profondo per le immagini container nei registri e durante le pipeline CI/CD. Rileva le vulnerabilità note, le configurazioni errate e il malware, aiutandola a costruire container sicuri fin dall'inizio.

Strumenti per la sicurezza di rete dei container

Una volta distribuiti, i container devono essere protetti dai continui tentativi di rubare dati proprietari o risorse di calcolo. I firewall di nuova generazione containerizzati, la sicurezza delle applicazioni web e delle API (WAAS)e gli strumenti di microsegmentazione ispezionano e proteggono tutto il traffico in entrata e in uscita dai container (nord-sud ed est-ovest), garantendo una visibilità e un controllo completi di livello 7 sull'ambiente Kubernetes. Inoltre, i firewall containerizzati scalano dinamicamente in base alle dimensioni e alle richieste in rapida evoluzione dell'infrastruttura container, garantendo sicurezza e larghezza di banda per le operazioni aziendali.

Gli strumenti di sicurezza di rete includono Calico, Flannel, i plugin CNI (ad esempio, Istio, Cilium), Kubernetes NetworkPolicy e Prisma Cloud. Prisma Cloud si integra con le piattaforme di orchestrazione di container come Kubernetes per fornire il rilevamento delle minacce in rete. Mette in sicurezza il traffico est-ovest tra i container e impedisce gli spostamenti laterali non autorizzati all'interno del suo ambiente.

Motori di politica

Gli strumenti moderni consentono ai team addetti alla sicurezza del cloud di definire politiche che determinano essenzialmente chi e cosa può accedere a un determinato microservizio. Le organizzazioni hanno bisogno di un quadro per definire queste politiche e assicurarsi che siano mantenute in modo coerente in un ambiente di applicazioni container altamente distribuito.

I motori di policy più diffusi sono Cilium, OPA Gatekeeper, Neutrino, Kubernetes Network Policy API e Prisma Cloud. Prisma Cloud applica le politiche di sicurezza sulle distribuzioni di container, tra cui il controllo dell'accesso alla rete, le limitazioni delle risorse e la firma delle immagini. Questo assicura una postura di sicurezza coerente e la conformità agli standard della sua organizzazione.

Scelta delle soluzioni giuste

Quando sceglie una soluzione per proteggere il suo ambiente containerizzato, consideri le esigenze della sua organizzazione e le aree di rischio. Ha bisogno di un rilevamento avanzato delle minacce, di una gestione delle vulnerabilità o di un'applicazione rigorosa dei criteri? Valutare l'integrazione con gli strumenti e l'infrastruttura esistenti. L'integrazione perfetta con le pipeline di sviluppo, le piattaforme di orchestrazione e i sistemi SIEM cambia le carte in tavola.

Ricordiamo che la sicurezza efficace dei container va oltre i singoli strumenti. L'implementazione di un approccio stratificato con monitoraggio continuo, scansione proattiva, politiche forti e sicurezza di rete affidabile migliorerà significativamente la resilienza del suo ambiente containerizzato contro le minacce.

 

Domande frequenti sulla sicurezza dei container

Un motore di policy è un componente software che consente ai team DevSecOps di definire, gestire e applicare le politiche che regolano l'accesso e l'utilizzo delle risorse, come le applicazioni, le reti e i dati. 

I motori di policy valutano le richieste in arrivo rispetto a regole e condizioni predefinite, prendendo decisioni in base a tali policy. Aiutano a garantire la conformità, a migliorare la sicurezza e a mantenere il controllo sulle risorse. Nel contesto degli ambienti containerizzati, i motori di policy svolgono un ruolo cruciale nel mantenere costantemente le politiche di accesso e di sicurezza nelle applicazioni distribuite e nei microservizi, aiutando a gestire e automatizzare l'applicazione delle policy in infrastrutture complesse e dinamiche.

Common Vulnerabilities and Exposures (CVE) si riferisce a un sistema standardizzato per l'identificazione, la catalogazione e la condivisione di informazioni sulle vulnerabilità e le esposizioni di cybersecurity pubblicamente note. Le voci CVE sono costituite da un identificatore unico, una descrizione e un punteggio di gravità. Il sistema, gestito dalla MITRE Corporation, mira a facilitare il tracciamento, la gestione e la comunicazione delle vulnerabilità tra diversi database, strumenti e organizzazioni. Fornendo un riferimento comune per le vulnerabilità, CVE aiuta i professionisti della sicurezza, i ricercatori e gli sviluppatori a comprendere meglio i rischi potenziali, a dare priorità agli sforzi di riparazione e a migliorare la sicurezza generale di software e sistemi.

La Matrice ATT&CK di MITRE è una base di conoscenza completa e accessibile a livello globale delle tattiche e delle tecniche degli avversari informatici. È sviluppato e mantenuto da MITRE, un'organizzazione senza scopo di lucro che gestisce centri di ricerca e sviluppo sponsorizzati dal Governo degli Stati Uniti. ATT&CK è l'acronimo di Adversarial Tactics, Techniques, and Common Knowledge.

La matrice funge da quadro per comprendere, categorizzare e documentare i vari metodi che gli avversari informatici utilizzano per compromettere sistemi, reti e applicazioni. È progettato per aiutare i team addetti alla sicurezza, i ricercatori e le organizzazioni nelle varie fasi del ciclo di vita della cybersecurity, tra cui il rilevamento delle minacce, la prevenzione, la risposta e la mitigazione.

La Matrice MITRE ATT&CK è organizzata in una serie di categorie, chiamate tattiche, che rappresentano le diverse fasi del ciclo di vita dell'attacco di un avversario. Ogni tattica contiene più tecniche che gli avversari utilizzano per raggiungere i loro obiettivi durante quella fase. Le tecniche sono ulteriormente suddivise in sotto-tecniche, che forniscono informazioni più dettagliate su metodi e strumenti specifici utilizzati negli attacchi informatici.

Un contesto di sicurezza è un insieme di attributi o proprietà relative alle impostazioni di sicurezza di un processo, di un utente o di un oggetto all'interno di un sistema informatico. Nell'ambito degli ambienti containerizzati, un contesto di sicurezza definisce le impostazioni di sicurezza e di controllo degli accessi per i container e i pod, come le autorizzazioni di utenti e gruppi, l'accesso al file system, i livelli di privilegio e altre configurazioni relative alla sicurezza.

Kubernetes le consente di impostare contesti di sicurezza a livello di pod o di container. Configurando i contesti di sicurezza, può controllare le impostazioni di sicurezza e le restrizioni per le sue applicazioni containerizzate, assicurando che vengano eseguite con le autorizzazioni appropriate e in modo sicuro.

Alcuni degli attributi chiave che possono essere definiti all'interno di un contesto di sicurezza includono:

  • ID utente (UID) e ID gruppo (GID): Queste impostazioni determinano l'utente e il gruppo con cui un container o un pod verrà eseguito, controllando così l'accesso alle risorse e alle funzionalità del sistema.
  • Controllo dell'escalation dei privilegi: Questa impostazione determina se un processo all'interno di un contenitore può ottenere privilegi aggiuntivi, come l'esecuzione come utente root. Disabilitando l'escalation dei privilegi, può limitare l'impatto potenziale di un container compromesso.
  • Accesso al sistema di file: I contesti di sicurezza le consentono di definire il modo in cui i contenitori possono accedere al file system, compreso l'accesso in sola lettura o il montaggio di volumi con autorizzazioni specifiche.
  • Capacità Linux: Queste impostazioni controllano le funzionalità specifiche che un contenitore può utilizzare, come i binding di rete, le impostazioni dell'ora del sistema o le attività di amministrazione.
  • Contesto SELinux: I contesti di sicurezza possono essere utilizzati per definire il contesto SELinux per un container o un pod, applicando le politiche di controllo degli accessi obbligatori e isolando ulteriormente il container dal sistema host.

Configurando correttamente i contesti di sicurezza in Kubernetes, può migliorare la sicurezza delle sue applicazioni containerizzate, applicare il principio del minimo privilegio e proteggere il suo sistema complessivo da potenziali rischi di sicurezza.

La sicurezza del codice si riferisce alle pratiche e ai processi implementati per garantire che il codice del software sia scritto e mantenuto in modo sicuro. Ciò include l'identificazione e la mitigazione delle potenziali vulnerabilità e l'applicazione delle migliori pratiche di codifica sicura per prevenire i rischi per la sicurezza. La sicurezza del codice comprende vari aspetti, come:

  • Test statico di sicurezza delle applicazioni (SAST): Analizzare il codice sorgente, il bytecode o il codice binario per identificare potenziali vulnerabilità di sicurezza senza eseguire il codice.
  • Test di sicurezza delle applicazioni dinamiche (DAST): Testare le applicazioni in esecuzione per identificare le vulnerabilità della sicurezza, simulando gli attacchi e analizzando il comportamento dell'applicazione.
  • Analisi della composizione del software: Eseguire la scansione e il monitoraggio delle dipendenze (librerie, framework, ecc.) utilizzate nel suo codice per identificare le vulnerabilità note e assicurarsi che siano aggiornate.
  • Pratiche di codifica sicure: Seguire le linee guida e le best practice (ad esempio, OWASP Top Ten Project) per scrivere codice sicuro ed evitare di introdurre vulnerabilità.

Le policy sono regole e linee guida di sicurezza specifiche utilizzate per applicare i requisiti di sicurezza all'interno di un ambiente Kubernetes, mentre l'IaC è una pratica più ampia per la gestione e il provisioning di risorse infrastrutturali utilizzando il codice. Entrambi possono essere utilizzati insieme per migliorare la sicurezza, la coerenza e l'automazione nel suo ambiente Kubernetes. 

Utilizzando l'IaC, può definire e gestire le configurazioni di sicurezza di rete, come le politiche di rete, le regole del firewall e i controlli di accesso come parte delle definizioni dell'infrastruttura. Ad esempio, può includere le politiche di rete Kubernetes, le configurazioni di ingresso e di uscita e le politiche di controllo degli accessi basate sui ruoli (RBAC) nei manifesti Kubernetes, che vengono poi gestiti come infrastruttura come codice.

Strumenti come Terraform, CloudFormation e i manifesti Kubernetes le consentono di gestire le risorse dell'infrastruttura e le configurazioni di sicurezza in modo coerente e automatizzato. Incorporando le misure di sicurezza nelle sue definizioni IaC, può migliorare la sicurezza complessiva del suo ambiente container e Kubernetes e garantire l'aderenza alle best practice e ai requisiti di conformità.

La politica come codice (PaC) comporta la codifica e la gestione delle politiche dell'infrastruttura, della conformità e delle regole di sicurezza come codice all'interno di un sistema a controllo di versione. Il PaC consente alle organizzazioni di automatizzare l'applicazione e l'auditing delle loro politiche, assicurando che la loro infrastruttura sia costruita e mantenuta secondo gli standard richiesti. Integrando queste politiche nel processo di policy as code o come parte della creazione dell'infrastruttura, le organizzazioni possono garantire che il loro tooling si allinei con gli standard e le best practice necessarie.

La disposizione degli avvisi è un metodo per specificare la sua preferenza sul momento in cui desidera che un avviso la informi di un'anomalia. Le impostazioni includono conservatore, moderato e aggressivo. Le preferenze si basano sulla gravità dei problemi - bassa, media, alta. 

  • Il conservatore genera avvisi di gravità elevata.
  • Moderato genera avvisi di gravità elevata e media.
  • Aggressivo genera avvisi di gravità elevata, media e bassa.
Tramite la personalizzazione delle impostazioni di anomalia, può controllare il criterio in cui vengono generati gli avvisi per le politiche di anomalie. Gli utenti possono modificare le impostazioni delle anomalie per cambiare la soglia di addestramento del modello, personalizzare la disposizione degli avvisi e aggiungere elenchi di anomalie attendibili per sopprimere gli avvisi provenienti da risorse attendibili.
Le soglie di addestramento dei modelli di anomalia si riferiscono a un metodo per definire diverse soglie di addestramento dei modelli per il rilevamento di anomalie per UEBA e anomalie della rete. Può impostare la soglia del modello di addestramento su bassa, media o alta. Queste soglie sono utilizzate per determinare il volume (ad esempio, un minimo di 100 eventi utente) e la durata dei dati utilizzati (ad esempio, 30 giorni) per l'addestramento dei modelli.
Un elenco di anomalie attendibili è un metodo per sopprimere risorse specifiche per le quali non desidera generare avvisi. Per esempio, se ci sono indirizzi IP che lei utilizza per eseguire test di penetrazione, può aggiungere questi IP a un elenco di fiducia per sopprimere i loro avvisi.
L'evento di audit si riferisce a un insieme di politiche basate su RQL che monitorano gli eventi di audit nel suo ambiente per individuare potenziali violazioni delle politiche. Si creano politiche di audit per segnalare eventi sensibili come attività di root o modifiche di configurazione che possono potenzialmente mettere a rischio il suo ambiente cloud.
Le politiche di anomalie di rete sono politiche di anomalie che monitorano continuamente i registri di rete alla ricerca di traffico di rete dannoso utilizzando l'apprendimento automatico, oltre a confrontare gli IP con AutoFocus. Le politiche di anomalie della rete possono rilevare varie minacce come botnet, ransomware e attacchi di worm.
L'autorizzazione comporta la concessione agli utenti autenticati dell'accesso alle risorse o alle funzioni del sistema, in base a criteri predefiniti. In Kubernetes, questo concetto è noto come controllo degli accessi basato sui ruoli (RBAC). RBAC concede ai gruppi di utenti, come gli sviluppatori, il permesso di interagire con risorse o funzioni specifiche in base ai loro requisiti lavorativi. L'implementazione di politiche di autorizzazione degli utenti solide e coerenti assicura che gli utenti abbiano solo i privilegi minimi necessari, riducendo il rischio di accesso non autorizzato e di escalation dei privilegi.

L'archiviazione sicura delle identità si riferisce a soluzioni e meccanismi progettati per archiviare in modo sicuro le informazioni sensibili, come password, chiavi crittografiche, token API e altri segreti, in modo altamente protetto e crittografato. I caveau segreti e i moduli di sicurezza hardware (HSM) sono due esempi comuni di archiviazione sicura delle identità.

I Secret Vault sono sistemi di archiviazione sicuri basati su software, progettati per gestire, archiviare e proteggere i dati sensibili. Impiegano meccanismi di crittografia e di controllo degli accessi per garantire che solo gli utenti o le applicazioni autorizzate possano accedere ai segreti memorizzati. Esempi di caveau segreti includono HashiCorp Vault, Azure Key Vault e AWS Secrets Manager. 

Caratteristiche del caveau segreto

  • Crittografia a riposo e in transito
  • Controllo degli accessi a grana fine
  • Registrazione e monitoraggio degli audit
  • Rotazione delle chiavi e versioning
  • Integrazione con i sistemi di gestione dell'identità e dell'accesso (IAM) esistenti

I moduli di sicurezza hardware (HSM) sono dispositivi fisici dedicati, resistenti alle manomissioni e altamente sicuri che salvaguardano e gestiscono le chiavi crittografiche, eseguono operazioni di crittografia e decrittografia e forniscono un ambiente sicuro per l'esecuzione di funzioni crittografiche sensibili. Gli HSM sono progettati per proteggere dagli attacchi fisici e logici, garantendo l'integrità e la riservatezza delle chiavi memorizzate. Esempi di HSM sono SafeNet Luna HSM, nCipher nShield e AWS CloudHSM.

Caratteristiche principali degli HSM

  • Certificazione FIPS 140-2 di livello 3 o superiore (uno standard del governo degli Stati Uniti per i moduli crittografici).
  • Generazione, archiviazione e gestione sicure delle chiavi
  • Generazione di numeri casuali basata sull'hardware
  • Rilevamento e protezione dalle manomissioni
  • Supporto per un'ampia gamma di algoritmi crittografici.

Sia i caveau segreti che gli HSM mirano a fornire una soluzione di archiviazione sicura delle identità, riducendo il rischio di accesso non autorizzato, di violazione dei dati e di altri incidenti di sicurezza. La scelta dipende da fattori quali i requisiti di sicurezza, il budget e le esigenze di integrazione.

UEBA si riferisce a un insieme di politiche di anomalie per identificare le attività devianti degli utenti, come ad esempio l'accesso di un utente da una località sconosciuta, tentativi di accesso successivi da località geografiche distanti e la creazione di un numero solitamente elevato di risorse di calcolo.