Controlli di sicurezza e analisi forense per le app GKE

Last reviewed 2019-08-22 UTC

Questo articolo descrive nel dettaglio la strumentazione e gli strumenti utilizzati nell'analisi forense per le app di cui è stato eseguito il deployment in Google Kubernetes Engine (GKE).

Creare e mantenere un ambiente sicuro per il codice, le app e l'infrastruttura è una priorità assoluta per qualsiasi organizzazione. Se si verifica un incidente di sicurezza, è fondamentale anche sapere come rispondere e analizzare il problema.

Google Cloud semplifica la protezione delle app GKE fornendo funzionalità avanzate per la sicurezza che contribuiscono a proteggere il cluster e l'ambiente Google Cloud. Cloud Audit Logs forniscono un logging dettagliato che puoi utilizzare nell'analisi forense. Insieme, le funzionalità avanzate di sicurezza e il logging forniscono una piattaforma affidabile per aiutarti a proteggere le app GKE della tua organizzazione.

L'obiettivo di questo articolo è aiutarti a proteggere l'infrastruttura Google Cloud e il codice basato su container in GKE e anche a prepararti per un incidente di sicurezza.

Proteggere l'ambiente e prepararsi per l'analisi forense con Google Cloud richiede diversi passaggi critici:

  • Protezione del tuo ambiente Google Cloud. Configurare Google Cloud ed eseguire il deployment dei carichi di lavoro utilizzando i controlli e la configurazione appropriati per la sicurezza.
  • Prepara un piano di risposta agli incidenti. Pianificare come rispondere a un incidente di sicurezza.
  • Raccolta di tutti i log e le origini dati pertinenti. Raccogli in anticipo i log e i dati appropriati sul tuo ambiente Google Cloud e scopri come accedervi.
  • Utilizzare il rilevamento automatico degli eventi. Configura una scansione proattiva per avvisarti di potenziali eventi di sicurezza, configurazioni errate e vulnerabilità.
  • Uso degli strumenti di analisi per l'analisi forense. Usa gli strumenti di analisi per individuare e documentare un incidente di sicurezza.

Protezione dell'ambiente Google Cloud

Google Cloud offre una gamma di configurazioni e strumenti che puoi utilizzare per proteggere la tua organizzazione e i tuoi progetti Google Cloud.

Modello di responsabilità condivisa

La sicurezza nel cloud è una responsabilità condivisa tra il cloud provider e il cliente. Google Cloud aiuta a proteggere l'infrastruttura sottostante fornendo la crittografia at-rest per impostazione predefinita e fornendo funzionalità che puoi utilizzare per proteggere i tuoi carichi di lavoro, ad esempio i controlli dell'accesso in IAM e gli Cloud Audit Logs. Per GKE, Google Cloud aiuta a proteggere il piano di controllo e i clienti sono responsabili della protezione dei loro carichi di lavoro. Per una discussione approfondita sul modello di sicurezza condivisa, leggi il post del blog Esplorare la sicurezza dei container: il modello di responsabilità condivisa in GKE.

Sicurezza di GKE

Kubernetes e GKE forniscono diversi meccanismi per proteggere il tuo cluster e i relativi carichi di lavoro. La creazione di un ambiente con accesso con privilegi minimi e controlli appropriati relativi alla sicurezza riduce la superficie di attacco. Diverse guide forniscono informazioni dettagliate su come proteggere il cluster e i relativi carichi di lavoro:

Preparazione di un piano di risposta agli incidenti

Una risposta efficace agli incidenti è fondamentale per la gestione e il ripristino dagli incidenti e per prevenire incidenti futuri. Per idee su come creare o migliorare il tuo piano di risposta agli incidenti, consulta Piano di risposta agli incidenti di Google Cloud.

Le seguenti fasi offrono una visione generale del processo:

  1. Identificazione. L'identificazione tempestiva e accurata degli incidenti è fondamentale per una gestione efficace ed efficace degli incidenti. L'obiettivo di questa fase è monitorare gli eventi di sicurezza per rilevare e creare report su potenziali incidenti relativi ai dati.
  2. Coordinamento. Quando viene segnalato un incidente, chi risponde alla chiamata esamina e valuta la natura del rapporto per determinare se rappresenta un potenziale incidente di dati e avvia un processo di risposta agli incidenti.
  3. Risoluzione. In questa fase, l'obiettivo è esaminare la causa principale, limitare l'impatto dell'incidente, risolvere eventuali rischi immediati per la sicurezza, implementare le correzioni necessarie come parte della correzione e recuperare i sistemi, i dati e i servizi interessati.
  4. Miglioramento continuo. Ogni nuovo incidente ti offre nuovi insight che possono aiutarti a migliorare gli strumenti, la formazione e i processi.

Rispetta il piano e ricorda quando rivolgerti agli esperti

Prima di lanciare qualsiasi codice in un cluster di produzione, è fondamentale comprendere il modello di sicurezza per l'app e l'infrastruttura (incluso Google Cloud) e creare un piano di risposta agli incidenti. Nel piano, assicurati di includere un percorso di escalation che descriva i team da coinvolgere in quale fase della risposta.

Ad esempio, una risposta all'incidente potrebbe iniziare con il team delle operazioni che invia un potenziale incidente che in seguito viene classificato come incidente di sicurezza. L'incidente viene quindi assegnato ai membri appropriati del team per la sicurezza. Il piano di risposta agli incidenti definisce quando chiamare i professionisti della sicurezza esterni e come coinvolgerli. Sviluppare un processo come questo è un aspetto critico della preparazione di una risposta efficace agli incidenti.

Raccolta di tutti i log e le origini dati pertinenti

Dopo aver implementato i meccanismi di protezione della sicurezza necessari per il tuo ambiente Kubernetes e aver bozza di un piano di risposta agli incidenti, devi assicurarti di poter accedere a tutte le informazioni necessarie per l'analisi forense. Dovresti iniziare raccogliendo i log non appena esegui il deployment di un'app o configuri un progetto Google Cloud. L'acquisizione dei log contribuisce a garantire che siano disponibili se ne hai bisogno per l'analisi. In generale, alcune origini dati sono univoche per gli ambienti Google Cloud, mentre altre sono comuni ai container. Entrambe le origini sono fondamentali per la conservazione e per essere rese disponibili per l'analisi.

I log forniscono un set di dati avanzati per identificare eventi di sicurezza specifici. Ognuna delle seguenti origini dei log potrebbe fornire dettagli che puoi utilizzare nell'analisi.

Cloud Audit Logs

Gli audit log di scrittura dei servizi Google Cloud sono chiamati Cloud Audit Logs. Questi log ti aiutano a rispondere alle domande: "Chi ha fatto cosa, dove e quando?" Esistono tre tipi di audit log per ogni progetto, cartella e organizzazione: attività di amministrazione, accesso ai dati ed evento di sistema. Complessivamente, questi log ti aiutano a comprendere quali chiamate amministrative alle API sono state effettuate, a quali dati è stato eseguito l'accesso e quali eventi di sistema si sono verificati. Queste informazioni sono fondamentali per qualsiasi analisi. Per un elenco dei servizi Google Cloud che forniscono audit log, consulta Servizi Google con audit log.

Cloud Audit Logs per GKE espone anche l'audit logging di Kubernetes, che fornisce un record cronologico delle chiamate effettuate al server dell'API Kubernetes. Questi log vengono raccolti anche in Cloud Audit Logs.

Log dell'app

Cloud Logging raccoglie i log di output ed errori standard del container. Puoi aggiungere altri log usando l'approccio sidecar. Per i cluster in cui sono abilitati Istio e Cloud Logging, l'adattatore Istio stackdriver raccoglie e registra i log specifici di Istio e li invia a Cloud Logging.

Log dell'infrastruttura

I log dell'infrastruttura offrono informazioni sulle attività e gli eventi a livello di sistema operativo, cluster e networking.

Audit log di GKE

GKE invia due tipi di log di controllo: Audit log di GKE e Log di controllo di Kubernetes. Kubernetes scrive gli audit log in Cloud Audit Logs per le chiamate effettuate al server API Kubernetes. Le voci del log di controllo di Kubernetes sono utili per esaminare le richieste API sospette, raccogliere statistiche e creare avvisi di monitoraggio per le chiamate API indesiderate. Inoltre, GKE scrive gli audit log che identificano ciò che succede in un cluster GKE.

Audit log di Compute Engine per nodi GKE

GKE viene eseguito sui nodi di Compute Engine, che generano propri log di controllo. Inoltre, puoi configurare controlli controllati per acquisire i log di sistema di Linux. Inoltre, fornisce informazioni preziose come messaggi di errore, tentativi di accesso ed esecuzioni binarie per i nodi del cluster. Sia gli audit log di Compute Engine che quelli di audit forniscono insight sulle attività che si verificano a livello di infrastruttura del cluster sottostante.

Log dei container

Per i log di container e di sistema, GKE esegue il deployment di un agente di logging per nodo che legge i log dei container, aggiunge metadati utili e poi li archivia. L'agente Logging registra i log dei container nelle seguenti origini:

  • Log di output ed errori standard di processi containerizzati
  • Log di runtime kubelet e container
  • Log per componenti di sistema, ad esempio script di avvio delle VM

Per gli eventi, GKE utilizza un deployment nello spazio dei nomi kube-system che raccoglie automaticamente gli eventi e li invia a Cloud Logging. I log vengono raccolti per cluster, nodi, pod e container.

Istio on Google Kubernetes Engine

Per i cluster con Istio, durante la creazione del cluster viene installato l'adattatore Istio stackdriver, che invia metriche, logging e traccia dei dati dal tuo mesh alla suite operativa di Google Cloud.

Controllo per Container-Optimized OS su GKE

Per i sistemi Linux, il daemon audited fornisce l'accesso ai comandi a livello di sistema operativo e può fornire informazioni preziose sugli eventi all'interno dei tuoi container. Su GKE, puoi raccogliere i log controllati e inviarli a Cloud Logging.

Log di flusso VPC

I log di flusso VPC registrano un campione di flussi di rete inviati e ricevuti dalle istanze VM. Queste informazioni sono utili per analizzare le comunicazioni di rete. I log di flusso VPC includono tutto il traffico pod-to-pod tramite la funzionalità Visibilità tra nodi nel tuo cluster Kubernetes.

Altri servizi Google Cloud

I servizi Google Cloud generano Cloud Audit Logs e alcuni servizi (come Cloud Load Balancing) generano log aggiuntivi. Una volta abilitato un servizio, Cloud Logging inizia a generare log. Per Cloud Audit Logs, solo gli audit log delle attività di amministrazione sono abilitati per impostazione predefinita. Puoi abilitare gli audit log per gli altri servizi quando questi servizi sono abilitati.

Snapshot

Gli scatti possono essere utili per analizzare i contenuti dello spazio di archiviazione in un determinato punto. Puoi creare snapshot dello spazio di archiviazione associato a un nodo del cluster Google Kubernetes Engine e pianificarli a intervalli regolari. Poiché gli snapshot funzionano a livello di nodo del cluster e i nodi del cluster potrebbero cambiare nel tempo, devi automatizzare l'acquisizione di snapshot ogni volta che viene creato un nodo con nuovo spazio di archiviazione. Avere un'istantanea normale dell'archiviazione del tuo nodo contribuisce a garantire che siano disponibili dati di archiviazione per l'analisi.

Utilizzo del rilevamento automatico degli eventi

L'automazione, insieme agli avvisi, è fondamentale per monitorare qualsiasi ambiente su vasta scala. Puoi utilizzare sia Google Cloud sia gli strumenti di Kubernetes per identificare potenziali minacce e errori di configurazione.

Security Command Center

Security Command Center è una piattaforma per la sicurezza e i rischi per Google Cloud. Security Command Center può semplificare la prevenzione, il rilevamento e la risposta alle minacce raccogliendo dati, identificando le minacce e consigliando azioni. Molti degli strumenti di scansione della sicurezza disponibili nei report di Google Cloud restituiscono Security Command Center, rendendo questa piattaforma utile per il rilevamento automatico. Security Command Center è uno strumento importante per i tuoi team SecOps o DevSecOps.

Event Threat Detection (Event Threat Detection)

Event Threat Detection è progettato per rilevare automaticamente le minacce più gravi che le organizzazioni devono affrontare e pubblicare i risultati in Security Command Center. Alcuni esempi di minacce sono l'aggiunta di utenti e account di servizio potenzialmente dannosi, istanze di Compute Engine compromesse e traffico di rete dannoso. Event Threat Detection si basa sull'intelligence open source e delle minacce minacce di Google e rileva le minacce nei log disponibili in Cloud Logging.

Security Health Analytics

Security Health Analytics è un servizio Google Cloud che analizza automaticamente le vulnerabilità e le configurazioni errate comuni nelle offerte Google Cloud. Security Health Analytics può rilevare vulnerabilità relative ai container. Le vulnerabilità includono il logging o il monitoraggio della disabilitazione e l'attivazione della dashboard dell'interfaccia utente web di gestione di Kubernetes. I risultati vengono scritti in Security Command Center.

Forseti Security

Forseti è un progetto open source in grado di creare un inventario delle risorse Google Cloud, scansionare l'ambiente e impostare i criteri da applicare. Forseti è integrato e può segnalare i risultati a Security Command Center. Puoi utilizzare Forseti per controllare i valori di configurazione arbitrari sui tuoi cluster GKE per garantire che siano coerenti con le tue specifiche. Se utilizzi Anthos, puoi utilizzare Anthos Config Management per definire configurazioni comuni, applicare queste configurazioni e monitorare la deviazione della configurazione.

cubo-cacciatore

kube-hunter esegue la scansione dei punti deboli nella sicurezza dei cluster Kubernetes utilizzando la scansione remota, interna e di rete. kube-hunter può essere utilizzato in modalità interattiva o come test di penetrazione automatizzato per il cluster.

Utilizzo di strumenti di analisi per l'analisi forense dei container

Molti strumenti nell'ecosistema Google Cloud e Kubernetes sono utili per l'analisi forense. Questa sezione ne include tre per riferimento futuro.

Analisi dei log di Google Cloud con BigQuery

Cloud Audit Logs possono essere esportati in Cloud Storage, Pub/Sub o BigQuery per ulteriori analisi. Ad esempio, potresti voler esaminare tutte le modifiche alle regole firewall nei tuoi progetti Google Cloud in un determinato periodo. Per farlo, puoi esportare Cloud Audit Logs in BigQuery. Quindi, utilizzando BigQuery, puoi creare una query SQL per restituire tali informazioni.

Esplorazione Docker

Docker-explorer è un progetto che aiuta un analista forense a esplorare i file system Docker offline. Questo approccio potrebbe essere utile quando un container Docker è compromesso.

Acquisizione kudictl sysdig + Ispezione Sysdig

Kubectl Sysdig Capture è un plug-in open source kubectl che attiva un'acquisizione delle attività di sistema in un pod. Sysdig rende disponibili le informazioni sui pod per Sysdig inspect, uno strumento open source usato per la risoluzione dei problemi dei container e le indagini sulla sicurezza. Sysdig inspect organizza visivamente il sistema granulare di rete, app e app di un sistema Linux e mette in relazione le attività all'interno di un pod.

Passaggi successivi