Sysdig
Learn Cloud Native

Sign up to receive our newsletter

Panoramica della sicurezza di IBM Cloud

Uno dei modi in cui IBM vuole imporsi nel mercato del cloud computing, dove resta un attore minore, è concentrandosi sulla flessibilità e la personalizzazione.

È fantastico, da una prospettiva di marketing. Ma da una prospettiva di sicurezza, più configurazioni comportano più sfide, ecco perché imparare a proteggere gli ambienti IBM Cloud è fondamentale per utilizzare con successo i servizi cloud offerti da IBM, sia che vengano utilizzati da soli che in più ampie configurazioni multicloud o ibride.

(Per essere chiari, i problemi di sicurezza interessano tutti i cloud, non solo quello di IBM. Ma l’interesse di IBM per la flessibilità dei propri servizi cloud e delle proprie configurazioni rende particolarmente complesso gestire i rischi associati alle diverse architetture e ai diversi setup).

Di seguito, spieghiamo in che modo proteggere i workload in esecuzione su IBM Cloud. Nello specifico, analizziamo l’approccio di IBM al modello di responsabilità condivisa, gli errori più comuni nella sicurezza di IBM Cloud, le migliori prassi per proteggere IBM Cloud e il modo in cui proteggere e monitorare IBM Cloud Kubernetes Service, una delle piattaforme cloud chiave di IBM.

Responsabilità condivisa su IBM Cloud

Come tutti i provider di cloud pubblico, IBM Cloud adotta un modello di responsabilità condivisa che definisce quali responsabilità relative alla sicurezza e alla conformità spettano a IBM Cloud e quali ai clienti.

IBM offre un’analisi molto dettagliata delle responsabilità, che può essere consultata per maggiori dettagli sull’organizzazione della responsabilità condivisa in IBM. In generale, però, le disposizioni possono essere riassunte come segue:

  • I clienti sono responsabili della protezione di tutte le applicazioni e di tutti i dati che utilizzano o eseguono su IBM Cloud, compresi quelli ospitati da servizi IBM gestiti (come IBM Cloud Kubernetes Service).
  • IBM è responsabile di proteggere tutte le reti fisiche e i server che fanno funzionare il cloud (sebbene, come spiegheremo meglio di seguito, i clienti siano responsabili di proteggere i server bare metal che utilizzano in IBM Cloud).
  • La responsabilità di proteggere la maggior parte delle risorse virtualizzate, ad esempio i server virtuali e le reti virtuali, viene condivisa tra IBM e i clienti. IBM gestisce la sicurezza dei componenti di virtualizzazione (come gli hypervisor) che i clienti non controllano, mentre ai clienti spetta la protezione di risorse quali il sistema operativo che scelgono di installare sulle macchine virtuali.

Sfide per la sicurezza di IBM Cloud

A livello molto elevato, la principale sfida per la sicurezza di IBM Cloud è rappresentata dal fatto che, poiché IBM offre ai propri clienti moltissimi modi diversi per configurare e distribuire i workload, risulta molto complesso rispettare le migliori prassi. Quando si lavora in ambienti cloud che possono essere progettati e configurati in molti modi diversi, non esiste un set di regole fisse da seguire.

In questi casi, forse ha più senso pensare a quello che non bisogna fare in termini di sicurezza quando si progettano e si configurano i workload in IBM Cloud. Quelli di seguito sono i principali errori da evitare per garantire la sicurezza di IBM Cloud.

Non trascurare la sicurezza dei server bare metal

Uno dei modi in cui IBM Cloud cerca di differenziarsi dai concorrenti nei propri servizi, è offrendo una vasta gamma di istanze di server IaaS bare metal. I server cloud bare metal tipicamente offrono migliori prestazioni rispetto ai server virtuali, perché i clienti non devono condividere una macchina fisica sottostante con altri utenti.

Da un punto di vista della sicurezza, tuttavia, si può commettere l’errore di dare per scontato che IBM gestisca la sicurezza dei server al posto del cliente. Per quanto sia vero che, in generale, la maggior parte dell’infrastruttura fisica in IBM Cloud è protetta da IBM, le istanze dei server bare metal rappresentano un’eccezione. Dal momento che i clienti distribuiscono queste istanze e le forniscono con il sistema operativo e le applicazioni che desiderano eseguire, spetta a loro proteggere i server bare metal. IBM si occupa della sicurezza fisica, ma le altre responsabilità sono in capo al cliente.

Non dimenticare di proteggere i servizi gestiti

IBM Cloud offre diversi servizi cloud gestiti che includono un’implementazione di Tekton sull’host, una piattaforma CI/CD, Hadoop gestito e diversi servizi di automazione e analisi Cloud Pak.

Come avviene per i server bare metal, i servizi gestiti di IBM Cloud possono essere ingannevoli in termini di sicurezza, poiché i clienti potrebbero dare per scontato che IBM gestisca più responsabilità di quanto non faccia effettivamente. Sebbene IBM protegga l’infrastruttura sottostante che fa funzionare i servizi gestiti, le applicazioni SaaS e le API che fornisce come parte dei propri servizi, non protegge le applicazioni o i dati che i clienti scelgono di distribuire attraverso uno di questi servizi gestiti.

Quindi, se per esempio si caricano dati sensibili su IBM Analytics Engine o si utilizzano delle applicazioni proprie in un container o su IBM Cloud Kubernetes Service, la responsabilità di proteggere tali dati e applicazioni è del cliente. IBM non anonimizza i dati né scansiona le immagini dei container alla ricerca di vulnerabilità. Questi sono compiti dei clienti.

Configurazione efficace di IAM

Come accade per qualunque cloud, i workload ospitati su IBM Cloud sono sicuri solo tanto quanto le policy di Identity and Access Management (IAM) che li governano.

IBM Cloud offre uno strumento IAM che i clienti possono utilizzare per gestire le autorizzazioni attraverso la console cloud, CLI o API. È necessario configurare le regole IAM in maniera tale da applicare il principio dei privilegi minimi a tutte le risorse eseguite in un ambiente IBM Cloud.

È necessario osservare, tuttavia, che lo strumento IAM di IBM Cloud funziona in maniera un po’ diversa rispetto agli strumenti IAM di altri provider. Per esempio, gli utenti vengono gestiti attraverso strumenti esterni e non vengono definiti in IAM, come accade per l’IAM di AWS. È consigliabile leggere i documenti di IBM sullo strumento IAM per il cloud per comprenderne l’approccio unico prima di iniziare a scrivere policy IAM per i workload.

Non affidarsi solo al monitoraggio della sicurezza e agli avvisi di IBM

IBM Cloud fornisce alcuni strumenti di sicurezza nativi. Il più rilevante è IBM Cloud Security Advisor, che offre una panoramica sui possibili problemi di sicurezza che IBM rileva nell’ambiente cloud. Le sue analisi si basano soprattutto sulle configurazioni di monitoraggio della sicurezza definite da IBM, ma è anche possibile creare regole personalizzate.

Cloud Security Advisor è un utile punto di partenza per il monitoraggio della sicurezza di IBM Cloud, ma di solito non è sufficiente a garantire un monitoraggio completo per due motivi. Il primo è che funziona solo con IBM Cloud, e questo è un problema se si utilizzano anche altri ambienti cloud o on-premise non integrati con l’ambiente IBM Cloud. Il secondo è che Cloud Security Advisor non è sempre in grado di rilevare minacce molto specifiche o ampiamente sfaccettate, ad esempio come quelle che potrebbero esistere in ambienti Kubernetes complessi.

Protezione di IBM Cloud Kubernetes Service

Dal momento che IBM Cloud Kubernetes Service è diventato uno dei principali prodotti Kubernetes gestiti in grado di competere con Amazon Elastic Kubernetes Service o Google Kubernetes Engine, vale la pena analizzarlo brevemente soprattutto come parte di una più ampia strategia di sicurezza per IBM Cloud.

Dal momento che IBM Cloud Kubernetes Service è un servizio gestito, IBM gestisce la sicurezza per i server che ospitano i cluster di Kubernetes. Protegge anche il traffico di rete e offre a ciascun cliente un cluster dedicato e single-tenant per proteggere da problemi a workload non collegati.

A parte questo, però, la maggior parte della sicurezza è responsabilità del cliente, che dovrà occuparsi di:

  • Aggiornamenti e upgrade: Quando un cluster viene utilizzato, gli utenti devono aggiornarlo manualmente ogni volta in cui vengono rilasciate nuove versioni di Kubernetes. (IBM Cloud invierà una notifica quando è disponibile una nuova versione.)
  • Sicurezza delle immagini dei container: I clienti devono verificare l’eventuale presenza di vulnerabilità nei container utilizzati in Kubernetes attraverso la scansione delle immagini.
  • Sicurezza dell’API di Kubernetes: Mediante strumenti quali RBAC di Kubernetes, i clienti devono mitigare i rischi di abusi che riguardano l’API di Kubernetes.
  • Mitigazione delle vulnerabilità: Anche se IBM protegge i nodi che formano i cluster di Kubernetes, è responsabilità dei clienti mitigare i rischi legati al fatto che una vulnerabilità potrebbe essere sfruttata, ad esempio impedendo ai container di eseguire la modalità privilegiata e isolandoli a livello di rete.

Per molti aspetti, proteggere i workload in esecuzione su IBM Cloud Kubernetes Service è come proteggere qualunque altro tipo di ambiente Kubernetes. La principale differenza sta nel fatto che IBM protegge il server sottostante e l’infrastruttura di rete. Tutte le altre responsabilità ricadono, invece, sul cliente.

Conclusione

Per sfruttare al massimo le particolari funzionalità di IBM Cloud, tra cui una vasta gamma di servizi gestiti e un set molto ampio di opzioni per risorse quali istanze dei server bare metal, è necessario capire in che modo si debbano proteggere i workload in esecuzione in IBM Cloud. Strumenti quali IBM Cloud Security Advisor sono un punto di partenza, ma in molti casi sarà necessario adottare ulteriori strumenti terzi a scopo di monitoraggio e controllo.