Sicurezza

Sicurezza dei container

Cos'è la sicurezza dei container?

Con sicurezza dei container si intende la protezione dell'integrità dei container, dalle applicazioni che contengono all'infrastruttura su cui si basano. Quella dei container deve essere una sicurezza integrata e continua. In generale, questo significa che l'azienda deve:

  • Proteggere il flusso dei container e l'applicazione
  • Proteggere l'ambiente di deployment e l'infrastruttura dei container
  • Integrare gli strumenti di sicurezza aziendali e rispettare o migliorare le policy di sicurezza esistenti

L'ampia diffusione dei container è dovuta alla facilità di compilare, creare pacchetti e promuovere un'applicazione o servizio e tutte le relative dipendenze, per l'intero ciclo di vita e su diversi ambienti e destinazioni di deployment. Rispetto alla sicurezza, tuttavia, i container presentano alcune complessità. Policy e checklist di sicurezza statiche non sono scalabili ai container dell'azienda. La catena di fornitura esige più servizi di policy di sicurezza. I team devono compensare le esigenze di networking e governance dei container. È necessario separare strumenti e servizi di creazione ed esecuzione.

Per esser certi che i container siano affidabili e scalabili, è necessario prevedere la sicurezza già nel flusso dei container e difendere l'infrastruttura.


Integrare la sicurezza nel flusso dei container

Acquisire le immagini

I container sono costituiti da livelli di file che la community definisce “immagini container.” L'immagine di base è la più importante per la sicurezza, perché rappresenta il punto di partenza dal quale vengono create le immagini derivate. La sicurezza del container inizia con l'individuazione di origini affidabili per le immagini di base. Anche se si usano immagini affidabili, l'aggiunta delle applicazioni e delle configurazioni introduce nuove variabili. Quando si introduce il contenuto esterno con il quale vengono realizzate le app, è necessario prevederne una gestione proattiva.

Durante l'acquisizione delle immagini, occorre porsi le seguenti domande:

  • Le immagini sono firmate? Provengono da origini affidabili?

  • I livelli relativi a runtime e sistema operativo sono aggiornati?

  • Con quale frequenza e velocità vengono aggiornati i container?

  • I problemi noti vengono identificati? Come vengono tracciati?

Gestione dell'accesso

Dopo aver ottenuto le immagini, il passo successivo consiste nella gestione dell'accesso e nella promozione di tutte le immagini container usate dal team, il che significa proteggere sia le immagini scaricate che quelle realizzate. L'impiego di un registro privato consente di controllare l'accesso con assegnazioni basate su ruoli, agevolando la gestione del contenuto tramite l'associazione dei metadati al container. I metadati forniscono informazioni come l'identificazione e la registrazione di vulnerabilità note. Il registro privato consente inoltre di automatizzare e assegnare policy per le immagini container archiviate, riducendo gli errori umani che possono introdurre vulnerabilità nel container.

Nel processo decisionale sulla gestione degli accessi occorre chiedersi quanto segue:

  • Quali controlli degli accessi basati su ruoli è possibile usare per gestire immagini container?

  • È possibile aggiungere tag per agevolare l'ordinamento delle immagini? È possibile applicare tag alle immagini solo per la fase di sviluppo, quindi per quella di test e infine per quella di produzione?

  • Il registro offre metadati visibili che consentono di tenere traccia delle vulnerabilità note?

  • È possibile usare il registro per assegnare e automatizzare policy (ad esempio controllando firme, scansioni di codici e così via)?

Integrare i test di sicurezza e automatizzare il deployment

L'ultima fase del flusso è il deployment. Una volta completate, le build devono essere gestite nel rispetto degli standard di settore. In questo ambito è necessario comprendere come automatizzare le policy affinché vengano contrassegnate le build con problemi di sicurezza, soprattutto quando vengono individuate nuove vulnerabilità. Poiché applicare patch ai container non è mai una soluzione valida quanto ricrearli, l'integrazione dei test di sicurezza deve tenere conto delle policy che generano nuove build automatiche. La prima parte di questo passaggio consiste nell'esecuzione di strumenti di analisi dei componenti in grado di registrare e contrassegnare i problemi. La seconda fase consiste nel definire gli strumenti necessari per un deployment automatico e basato su policy.

Al momento di integrare i test di sicurezza e automatizzare il deployment, occorre porsi le domande seguenti:

  • Come impedire alle patch di eseguire i container e utilizzare invece trigger per ricreare e sostituire i container con aggiornamenti automatizzati?


Difendere l'infrastruttura

Un altro livello di sicurezza dei container è l'isolamento fornito dal sistema operativo host. È necessario un SO host che offra al container il massimo isolamento possibile. È questo un elemento di assoluta importanza nella difesa dell'ambiente di deployment del container. Il SO host viene abilitato mediante un runtime del container, gestito idealmente tramite un sistema di orchestrazione. Per rendere la piattaforma containerizzata resiliente, vengono usati lo spazio dei nomi di rete per isolare applicazioni e ambiente; gli archivi vengono connessi tramite montaggi protetti. Una soluzione di gestione delle API deve includere funzionalità di autenticazione e autorizzazione, integrazione LDAP, controlli dell'accesso agli end-point e limitazione della velocità.

Per decidere come difendere l'infrastruttura di container, tenere conto dei seguenti aspetti:

  • Quali container devono poter accedere ad altri? In che modo vengono rilevati?

  • Come viene effettuato il controllo degli accessi e la gestione delle risorse condivise (ad esempio rete e storage)?

  • Come vengono gestiti gli aggiornamenti dell'host? Tutti i container devono essere aggiornati nello stesso momento?

  • In che modo viene monitorata l'integrità del container?

  • In che modo la capacità viene scalata automaticamente per soddisfare la domanda?


Possiamo aiutarti

Red Hat® OpenShift Container Platform è incluso in Red Hat Enterprise Linux®. Automatizza il ciclo dell'applicazione containerizzata, integra la sicurezza nel flusso del container ed è progettata per i team DevOps. Il catalogo dei container consente di accedere a un gran numero di immagini certificate, runtime di linguaggio, database e middleware che possono essere eseguiti ovunque venga eseguito Red Hat Enterprise Linux. Le immagini Red Hat sono sempre firmate e verificate, per confermarne provenienza e integrità.

Red Hat monitora le immagini container per individuare vulnerabilità recenti appena riscontrate (con un indice di integrità costantemente aggiornato e pubblicamente visibile), e rilascia aggiornamenti della sicurezza e container ricostruiti e pubblicati nel registro pubblico.

Offre inoltre molto altro materiale utile:

  • Orchestrazione e gestione di container su web
  • Console web completa con funzionalità di collaborazione multi utente
  • Interfacce CLI e IDE
  • Automazione di build e source-to-image
  • Integrazione con CI
  • Automazione del deployment
  • Supporto per volumi di storage remoti
  • Installazione e amministrazione semplificata
  • Grande raccolta di linguaggi di programmazione, framework e servizi supportati

Inizia subito

Cloud computing

OpenShift consente di creare, sviluppare ed eseguire il deployment con rapidità e semplicità, in infrastrutture pubbliche o private.

Piattaforme Linux

Red Hat Enterprise Linux è una base stabile e versatile per eseguire il roll out di nuove applicazioni, virtualizzare ambienti e creare un cloud ibrido sicuro, il tutto con il nostro supporto pluripremiato.


Scopri altri vantaggi offerti dalla sicurezza dei container