È una di quelle invenzioni storiche che cambiano abitudini, paradigmi lavorativi, processi di business in modo morbido ma inesorabile, accettata da grandi e piccole realtà, in grado di portare continuità e al tempo stesso profonda innovazione.
Proprio queste ultime caratteristiche lo rendono potente, al punto che da tempo si dibatte sul tema del cloud ibrido – cioè quello che si compone di parti tradizionali e online, esperienze private e che si affidano a provider condivisi, costruite sul miglioramento di processi esistenti da tempo e di cui si conoscono le inefficienze rispetto a innovazioni profonde nei modi di fare business.
Qualora non fosse bastata la spinta – modaiola o meno – della trasformazione digitale, ecco che la recente situazione pandemica ha creato emergenze e modus operandi che hanno ulteriormente esacerbato la necessità di rendere fruibili in modo remoto ed onnipresente processi ed applicazioni ad utenti attivi in ogni momento e connessi da qualunque luogo.
Cosa che ha portato a reazioni spesso frettolose, percepite talvolta come semplificazioni con importante riduzione di costi, definite spesso “lift-and-shift” e caratterizzate dallo spostamento di server dai datacenter tradizionali aziendali in ambienti cloud amazoniani, microsoftesi o googlici.
I progetti con un approccio più strutturato però, hanno ipotizzato una reingegnerizzazione delle piattaforme applicative secondo i principi del Platform-as-a-Service (o PaaS).
Se dal punto di vista IT e sviluppo questo approccio moderno ed efficace ha richiesto una frammentazione del server nei suoi componenti fondamentali – come storage, liste di accesso, networking, database ed altro – in pochi hanno percepito la profonda differenza dal punto di vista della sicurezza, specialmente in relazione alla responsabilità condivisa.
Questo concetto è stato riassunto in modo eccellente da Amazon Web Services o AWS nella frase “questa differenziazione della responsabilità viene comunemente detta sicurezza del cloud rispetto a sicurezza nel cloud” e illustrata altrettanto efficacemente come segue.
 |
Figure 1 - Cloud Responsibility Model (Fonte AWS - aws.amazon.com) |
Questo schema, utilizzato molto spesso per educare le aziende ad una evoluzione consapevole dei propri processi e schemi di business per trarre vantaggio da piattaforme cloud, presenta una semplificazione talvolta eccessiva del concetto che cercherò di spiegare con un esempio.
Ipotizziamo che l’azienda fittizia ACME Ricambi Motoveicoli abbia completato la sua prima trasformazione digitale quattro anni fa, implementando un sistema di server esposti su Internet e ubicati nel proprio datacenter per realizzare un sistema mirato alla vendita online dei propri prodotti e servizi.
Nel caso in esame, supponiamo che la soluzione abbia avuto successo ma che si sia rivelata eccessivamente complessa e costosa da manutenere, a causa dell’infrastruttura richiesta.
Così nel 2019 il progetto è evoluto con lo spostamento dei server in cloud, con la speranza di una riduzione dei costi.
Complice la pandemia che ha causato un aumento dell’utenza, la necessità di scalare le risorse ha comportato costi per le repliche dei server superiori all’efficienza operativa, a causa della struttura monolitica dei server (la fretta aveva spinto ad optare per una soluzione veloce...).
A fine 2020 la nostra ACME Ricambi Motoveicoli ha quindi optato per una revisione completa del progetto che frammentasse le singole componenti dei server, istanziandole in modo bilanciato e scalabile in cloud. In sostanza l'idea è di separare quello che normalmente definisce un server - ad esempio lo storage o spazio su disco, il database su cui vengono memorizzati i dati, le regole d'accesso ai servizi esposti e così via. Ogni frammento viene configurato in cloud singolarmente, con un sistema che ne moltiplica le istanze all'aumentare della domanda. Questo approccio è ideale perché replica solo le componenti del mosaico applicativo che ne hanno bisogno, ottimizzando il rapporto investimento/prestazioni.
Se da un punto di vista applicativo ed operativo questa è la via corretta, dal punto di vista della sicurezza ciò richiede una profonda modifica delle strategie di protezione – proprio a causa della opacità tipica della responsabilità condivisa.
Per capire a cosa mi riferisco, approfondiamo un pezzo del grafico riportato sopra:
E lo è certamente per quanto riguarda la resilienza dello storage e/o dell’istanza database.
Ciò che lo schema semplificato non ci dice è che se guardiamo più da vicino questi due elementi nelle impostazioni di sicurezza, notiamo quanto segue.
La configurazione di un’istanza di storage, ad esempio Amazon S3 Bucket ha come impostazione predefinita in Permissions – Bucket Policy - Principal un valore predefinito pari a *, che permette a chiunque di accedere a uno storage esposto e raggiungibile.
Un’istanza
Amazon >RDS – cioè database – presenta una configurazione
predefinita il database senza alcuna protezione dalla cancellazione.
Una compromissione dell’ambiente cloud – ad esempio per
furto di credenziali – permetterebbe agli attaccanti di cancellare
l’istanza del database, magari dopo averne trasferito i dati.
Questi due esempi illustrano come l’intera concezione della sicurezza nel paradigma PaaS richieda conoscenze che normalmente non sono alla portata di tutti; questo significa la necessità di un aggiornamento delle competenze del team di security, elemento spesso non considerato nella pianificazione dei progetti cloud.
Sarebbe anche auspicabile dotarsi di soluzioni specializzate di inventario e analisi dinamica della configurazione, magari in grado di abbracciare più fornitori di servizi cloud. In questo modo si arriva ad una presentazione unificata e organica della superficie vulnerabile, mappata direttamente sulla visibilità raggiunta dell'ambiente multi-cloud, capacità discusse nel precedente articolo "Dai dati grezzi alle informazioni fruibili: visibilità e osservabilità".
La Cloud Security Alliance, istituzione per la divulgazione culturale della sicurezza in ambienti cloud, ha rilasciato due importanti pubblicazioni in merito di cui consiglio la lettura:
The Treacherous Twelve (Gli Infidi Dodici), in cui elencava già nel 2016 dodici incidenti in cloud la cui causa era prevalentemente l’inosservanza di best practice nelle configurazioni.
The Egregious Eleven (Gli Egregi Undici), in cui due anni fa presentava l’analisi di undici incidenti importanti di cui l’origine era ancora spesso la configurazione sbagliata o troppo permissiva delle risorse.
Il Cloud è certamente la via per una maggiore agilità di business e per un’economia di scala nel controllo dei costi IT. L’adozione di questa nuova tecnologia non può però prescindere dall' aggiornamento delle competenze di security e dal potenziamento delle capacità di visibilità, osservabilità, rilevamento e risposta adatte a questa nuova sfida.
Marco Rottigni
Per
approfondire:
https://www.theinnovationgroup.it/ll-cloud-ibrido-leva-strategica-per-il-business/
https://aws.amazon.com/it/compliance/shared-responsibility-model/
Nessun commento:
Posta un commento