Migrare un'applicazione sul cloud può semplificare la gestione dell'infrastruttura, accelerare lo sviluppo e rendere più flessibile la distribuzione dei servizi.
Ma il cloud non elimina la necessità di occuparsi della sicurezza.
Un servizio configurato in modo errato può rendere accessibili risorse che dovrebbero rimanere private, esporre informazioni operative o permettere accessi più ampi del necessario.
Il problema non riguarda necessariamente una vulnerabilità del provider: spesso dipende da come il servizio è stato configurato e gestito.
Che cosa significa configurazione errata nel cloud?
Immaginiamo un'applicazione che utilizza:
Applicazione web
↓
API
↓
Database
↓
Storage cloud
Ogni componente può avere regole di accesso differenti.
Se lo storage contiene documenti destinati esclusivamente agli utenti autenticati, una configurazione che permette a chiunque di leggerli può creare un problema di riservatezza.
Analogamente, un database raggiungibile pubblicamente o una chiave API con privilegi eccessivi possono aumentare il rischio.
La questione centrale è la differenza tra l'accesso previsto e quello effettivamente consentito.
1. Archivi di file accessibili pubblicamente
Molti servizi cloud permettono di conservare immagini, documenti, backup e altri file.
In alcuni casi, l'accesso pubblico è intenzionale: per esempio, per distribuire immagini di un sito o file scaricabili liberamente.
In altri casi, può essere una conseguenza di una configurazione sbagliata.
Un archivio potrebbe contenere:
- documenti interni;
- backup;
- esportazioni di database;
- file di configurazione;
- dati personali;
- documentazione non destinata al pubblico.
Non tutti questi contenuti sono necessariamente presenti in un archivio pubblico, ma la possibilità di esporli rende importante verificare le autorizzazioni.
La domanda da porsi è semplice:
i file accessibili pubblicamente sono davvero destinati a essere pubblici?
2. Database raggiungibili da Internet
Un database può essere ospitato su un servizio gestito dal provider oppure su una macchina virtuale.
In entrambi i casi, bisogna verificare chi possa raggiungerlo.
Una configurazione da esaminare potrebbe essere:
Internet
↓
Database
Se il database deve essere utilizzato soltanto da un'applicazione, normalmente è preferibile limitare l'accesso alla rete o ai componenti autorizzati.
Le misure possono comprendere:
- regole firewall restrittive;
- accesso attraverso reti private;
- autenticazione robusta;
- privilegi limitati;
- aggiornamenti;
- monitoraggio degli accessi.
Un database raggiungibile pubblicamente non è automaticamente compromesso, ma l'esposizione non necessaria dovrebbe essere corretta.
3. Chiavi API e credenziali
Le applicazioni cloud spesso utilizzano chiavi API, token e credenziali per comunicare con altri servizi.
Se questi segreti vengono inseriti nel codice client, caricati in repository pubblici o inclusi in file accessibili via web, potrebbero finire nelle mani sbagliate.
Un esempio di configurazione da evitare è:
const API_SECRET = "inserisci-qui-un-segreto-reale";
Il problema non è la sintassi del codice in sé, ma il fatto che un segreto inserito nel codice distribuito agli utenti può essere esposto.
È preferibile conservare le credenziali sensibili in un sistema di gestione dei segreti o in configurazioni server-side protette, assegnando loro soltanto i privilegi necessari.
Se una chiave è stata esposta, non basta cancellarla dal file: occorre valutarne la revoca o rotazione e verificare eventuali utilizzi anomali.
4. Permessi troppo ampi
Un altro errore comune riguarda i privilegi assegnati agli utenti, alle applicazioni e ai servizi.
Per esempio, un componente che deve soltanto leggere alcuni file potrebbe ricevere permessi di scrittura o accesso a un'intera area di storage.
Il principio del privilegio minimo suggerisce di concedere soltanto ciò che serve.
In pratica:
Servizio A
↓
Lettura dei file necessari
è generalmente preferibile a:
Servizio A
↓
Accesso completo a tutte le risorse
La stessa logica vale per account amministrativi, identità di servizio, ruoli cloud e autorizzazioni delle API.
5. Ambienti di sviluppo dimenticati
Le infrastrutture cloud rendono semplice creare nuove risorse.
Questa flessibilità, però, può produrre ambienti che rimangono attivi anche dopo la conclusione di un progetto.
Per esempio:
Produzione
Sviluppo
Test
Demo
Vecchio ambiente
Un ambiente dimenticato potrebbe avere configurazioni meno restrittive rispetto a quello principale.
È utile controllare periodicamente le risorse attive, identificare quelle senza un proprietario e dismettere quelle che non servono più.
La dismissione deve comprendere anche eventuali indirizzi pubblici, DNS, credenziali e autorizzazioni rimaste associate.
6. Interfacce di gestione esposte
Alcuni servizi cloud mettono a disposizione dashboard e interfacce amministrative.
L'accessibilità via Internet può essere prevista dal provider, ma bisogna comunque verificare:
- quali account possono accedere;
- se è attiva la MFA;
- come vengono assegnati i privilegi;
- se esistono account inutilizzati;
- se vengono registrate le attività;
- se sono presenti restrizioni appropriate.
È importante distinguere la console ufficiale del provider da eventuali interfacce personalizzate pubblicate direttamente dall'organizzazione.
7. Come individuare le esposizioni?
Non tutte le configurazioni errate sono visibili dall'esterno.
Una verifica pubblica può rilevare alcuni elementi, come servizi raggiungibili, hostname, certificati o risposte HTTP anomale.
Altri aspetti richiedono invece un controllo autenticato della configurazione cloud, dei permessi e delle policy interne.
Per questo motivo è utile combinare due approcci:
Osservazione esterna
- quali servizi sono raggiungibili;
- quali hostname sono pubblicati;
- quali informazioni vengono restituite;
- quali risorse sembrano inattese.
Verifica della configurazione interna
- quali utenti hanno accesso;
- quali permessi sono assegnati;
- quali dati sono pubblici;
- quali chiavi sono attive;
- quali risorse non sono più necessarie.
Una verifica esterna, da sola, non può certificare che un'infrastruttura cloud sia sicura.
Una checklist per il controllo periodico
- [ ] Gli archivi pubblici contengono soltanto file destinati al pubblico?
- [ ] I database sono accessibili esclusivamente dai sistemi autorizzati?
- [ ] Le chiavi API e le credenziali sono protette?
- [ ] I permessi rispettano il principio del privilegio minimo?
- [ ] Gli account inutilizzati sono stati rimossi?
- [ ] Gli ambienti di sviluppo sono ancora necessari?
- [ ] Le dashboard amministrative sono adeguatamente protette?
- [ ] I log permettono di ricostruire gli accessi rilevanti?
- [ ] Esiste un inventario aggiornato delle risorse cloud?
- [ ] Le configurazioni vengono riesaminate dopo le modifiche infrastrutturali?
Chi è responsabile della sicurezza nel cloud?
La responsabilità è condivisa, ma non identica per ogni servizio.
Il provider gestisce determinate componenti della piattaforma; il cliente rimane responsabile delle configurazioni, degli accessi e dei dati secondo il modello di servizio utilizzato.
Per questo è importante non dare per scontato che una risorsa sia sicura soltanto perché ospitata su un'infrastruttura cloud professionale.
La configurazione concreta conta quanto la tecnologia scelta.
In sintesi
Le configurazioni errate nel cloud possono riguardare storage pubblici, database, credenziali, permessi e ambienti dimenticati.
Non sempre è possibile individuarle attraverso una scansione esterna: alcune richiedono verifiche interne e autorizzate.
Un buon processo di sicurezza combina quindi inventario, controllo degli accessi, revisione delle configurazioni e osservazione periodica della superficie pubblica.
MiHakero può aiutare a individuare esposizioni e servizi osservabili dall'esterno, offrendo un primo livello di controllo da affiancare alle verifiche delle configurazioni cloud e dei permessi interni.