Sicurezza nativa del cloud è un obiettivo fondamentale per tutte le organizzazioni. Ma cos’è realmente? Tutti sembrano definirla in modo diverso. Il suggerimento di Frank Dickson, Program Vice President, Security & Trust di Idc è che qualsiasi discussione sulla sicurezza nativa del cloud inizi con il cloud.
Le organizzazioni passano al cloud per flessibilità, scelta e facilità di implementazione.
I public cloud provider cercano di mantenere la promessa di questi vantaggi con un ambiente IT elastico in cui le risorse aumentano o diminuiscono su richiesta.
Queste risorse sono implementazioni altamente virtualizzate della stessa tecnologia che le organizzazioni aziendali eseguono nei loro data center locali, con la differenza fondamentale che consiste in molti tenant contro uno.
Mentre cerchiamo di implementare la sicurezza cloud in questa architettura IT unificata, vogliamo protezioni native di quell’ambiente, e quindi cloud native.
È allora che la conversazione può diventare complessa rapidamente, trasformandosi in una discussione che può includere contenitori liberamente accoppiati, piattaforme di distribuzione CI / CD, sicurezza senza server e microservizi.
Sicuramente, queste funzionalità consentono agli sviluppatori di apportare modifiche frequentemente senza influire sugli altri componenti di un’applicazione ospitata. La base è flessibile, scalabile e orientata verso un nuovo tipo di infrastruttura.
Tuttavia, non sembra facile. Di conseguenza, quando si tratta di una conversazione sulle responsabilità in merito alla sicurezza del cloud, e non nel cloud, tali misure di sicurezza e integrità dovrebbero essere fornite dal fornitore di cloud per mantenere la promessa di flessibilità, scelta e facilità di implementazione e non responsabilità del proprietario dell’applicazione.
Il suggerimento di Idc nella ricerca della “sicurezza nativa del cloud” è di capovolgere la responsabilità. Secondo Dickson la sicurezza nativa del cloud dovrebbe essere una parte integrante dell’offerta cloud.
Sicurezza hardware
Sfruttare il cloud, per impostazione predefinita, significa utilizzare l’infrastruttura IT di qualcun altro; l’integrità hardware dell’infrastruttura è la base su cui si basano tutte le misure future.
Se una persona avesse intenzione di costruire la casa dei propri sogni, vorrebbe gettare fondamenta nuove di zecca o radere al suolo una casa costruita negli anni ’30 su fondamenta di integrità sconosciuta?
Gli elementi di elaborazione di un’architettura nativa del cloud devono essere ridistribuibili in modo sicuro. La sicurezza nativa del cloud richiede la capacità di documentare e dimostrare la capacità di cancellare il firmware rimuovendo qualsiasi traccia di un utilizzo precedente.
Un secondo elemento di una sicurezza nativa del cloud prevede un firewalling delle istanze di calcolo dopo la distribuzione iniziale.
Data la complessità degli attacchi esterni odierni, è possibile che un’infezione software iniziata a livello di applicazione di un servizio ospitato possa viaggiare fino alla fine dello stack eseguibile e quindi iniziare un attacco est-ovest su altre istanze cloud rilevabili mentre attraversa il tessuto di rete.
È raro che si verifichi una violazione iniziale all’interno di una parte dell’ambiente che contiene il paydirt definitivo sotto forma di dati sensibili, credenziali e PI del cliente. Idc ritiene che i provider di servizi cloud che hanno isolato i propri livelli di rete offrano un altro importante costrutto di progettazione di un’infrastruttura nativa del cloud.
Sicurezza del software nel cloud
Anche in questo caso, le organizzazioni che passano al cloud cercano flessibilità, scelta e facilità di implementazione, ma spesso sono meno qualificate per quanto riguarda l’esposizione alla sicurezza, i requisiti di implementazione e le attività di manutenzione.
Aiutare i clienti con la loro parte del modello di responsabilità condivisa è un’altra opportunità per i fornitori di cloud di fornire la sicurezza nativa del cloud.
Oracle Cloud Infrastructure (OCI) è progettato per fornire alcune funzionalità di raggruppamento che aiutano. I compartimenti, ad esempio, consentono agli utenti di sviluppare limiti di gestione delle risorse logiche e granulari e politiche di accesso, una funzionalità di base che si inizia davvero ad apprezzare quando manca.
Fa per il cloud ciò che la virtualizzazione fa per i server e quasi nessuno riesce a capire bene questi limiti la prima volta finché non c’è più esperienza operativa da esaminare. IDC ritiene che i compartimenti siano un mezzo elegante per semplificare le regolazioni all’implementazione di una soluzione nativa per il cloud.
È possibile creare compartimenti in zone di sicurezza con criteri di sicurezza immutabili aggiuntivi. Un’area di sicurezza è associata a un compartimento con lo stesso nome, ma non è possibile aggiungere o spostare un compartimento standard in un compartimento di zona di sicurezza a meno che non siano soddisfatti tutti i criteri.
I prodotti di sicurezza OCI forniscono diversi modelli di criteri modificabili o “ricette” basati su punti di partenza di best practice per il controllo di elaborazione, rete, archiviazione di oggetti e risorse di database, che in alcuni casi devono soddisfare una configurazione definita da Oracle.
Le modifiche o le risorse appena create che violano qualsiasi criterio all’interno di una zona verranno negate. In questo modo OCI aiuta gli inquilini a evitare di eseguire configurazioni errate involontarie.
Un’altra caratteristica di progettazione utile è il gruppo IAM (Identity and Access Management). I gruppi consentono agli utenti di accedere alle risorse all’interno dei compartimenti tramite criteri scritti per il gruppo e non per l’utente. È un altro elemento della flessibilità di gestione del cloud che riduce le combinazioni di autorizzazioni utente necessarie per proteggere i dati di un tenant.
Utilizzando gruppi e compartimenti, i tenant possono unire la loro struttura organizzativa fisica alle risorse cloud disponibili aggiungendo, modificando ed eliminando istanze e persone lungo il percorso. IDC sa che le autorizzazioni e le politiche di accesso possono rapidamente diventare un pantano quando ogni partecipante tenant insiste sul fatto di essere un fiocco di neve (cioè unico).
In un blog post Idc ha anche esaminato il ruolo svolto da Oracle Cloud Guard nel controllo e nel mantenimento di ciò che i clienti OCI configurano e implementano nelle loro istanze di elaborazione, rete e storage.
Le complessità della distribuzione sicura di soluzioni cloud richiedono semplicemente una soluzione di gestione della postura. Incapace per progettazione di vedere cosa stanno facendo i suoi clienti nel cloud, Oracle ha creato uno strumento di gestione per aiutare i tenant ad applicare le proprie policy su tutte le risorse disponibili.
Infine, le discussioni sulla sicurezza cloud-native tendono anche a includere argomenti come intelligenza artificiale e apprendimento automatico, analisi dei big data, rilevamento delle minacce multi-vettore e intelligence sulle minacce, e altri ancora.
Alcuni fornitori di cloud pubblico possono essere più specifici con tali approfondimenti, suggerimenti e raccomandazioni perché hanno visibilità sugli inquilini del cliente. Poiché OCI non è in grado di farlo, Oracle ha confezionato informazioni AI / ML simili come ricette, strumenti di gestione del cloud e approfondimenti operativi sopra menzionati che Oracle sviluppa gestendo la propria attività all’interno del cloud. L’hanno costruito e l’hanno ottenuto; bevono il loro champagne e lo condividono.
Idc ritiene che una progettazione architettonica nativa del cloud sia fondamentalmente diversa dalla tecnologia e dalle pratiche che le organizzazioni hanno implementato da tempo nei loro ambienti locali.
I potenziali clienti che ricercano e comprendono queste differenze apprezzeranno il livello aggiuntivo di sicurezza offerto da OCI e saranno più disponibili a migrare anche carichi di lavoro sensibili in un ambiente cloud sapendo che è disponibile aiuto e che gli errori sono evitabili.
