AWS security come capitolo strategico di un paradigma finalizzato a fornire una serie di controlli che aiutano a proteggere al meglio le infrastrutture aziendali. Le organizzazioni che scelgono il cloud non devono mai dimenticare che la sicurezza dei singoli server è a carico del cliente, non di Amazon. Questa distinzione, purtroppo, non è sempre compresa nella sua essenza. Il modello, infatti, è quello della responsabilità condivisa.
Il principio della responsabilità condivisa
Cosa protegge Amazon? Il provider si occuperà di proteggere:
- l’hardware
- il software
- la rete
- le infrastrutture su cui girano i servizi cloud AWS (link interno:)
Rispetto all’AWS security di che cosa si deve occupare l’azienda? Tra le varie attività, il cliente si dovrà occupare di:
- gestire gli altri ambienti, inclusi i sistemi operativi guest
- effettuare patch e aggiornamenti
- risolvere la sicurezza del software applicativo
- gestire le identità e gli accessi
- configurare il firewall
In questo modello di responsabilità condivisa, per i cloud provider non è possibile fornire anche la gestione delle vulnerabilità. Questo perché l’attività richiederebbe al provider di avere accesso alle credenziali a livello di amministratore o di root per ciascun server. Il che, come è noto, sarebbe un problema per la gestione della Privacy dei dati.
AWS security: attenzione a presidiare tutti gli indirizzi IP
Parlare di AWS security significa saper gestire nel modo migliore il servizio. Se è vero che l’infrastruttura di Amazon sia regolarmente testata per le vulnerabilità, questo non vuol dire che sia risolta automaticamente anche la sicurezza sui singoli indirizzi IP gestiti da un’azienda. Mentre gli indirizzi IP all’interno di AWS dovrebbero essere trattati allo stesso modo di qualsiasi indirizzo IP privato o pubblico, le politiche di gestione delle vulnerabilità aziendali dovrebbero essere estese anche ai server ospitati in AWS.
Gli esperti forniscono tutte le linee guida per affidarsi al cloud presidiando al meglio la AWS security.
#1 AWS security: occhio agli aggiornamenti
Non c’è AWS security se non c’è un controllo continuo delle vulnerabilità di questo tipo di ambiente. Per soddisfare la fine del modello di responsabilità condivisa, le aziende devono condurre una scansione periodica delle vulnerabilità di AWS.
Storicamente, AWS ha richiesto l’autorizzazione esplicita per eseguire qualsiasi forma di valutazione della vulnerabilità sui server all’interno dell’infrastruttura AWS. Le regole sono state aggiornate nel 2016 per consentire alle organizzazioni di eseguire le scansioni di vulnerabilità su:
- istanze EC2
- gateway di traduzione degli indirizzi di rete ed Elastic Load Balancer
- Amazon Relational Database Servic
- CloudFront
- Amazon API Gateway
- Lambda e funzionalità Lambda a livello edge
- Elastic Beanstalk
Per garantire la conformità alle regole che caratterizzano la AWS security, prima di eseguire una scansione i responsabili dei servizi in cloud devono controllare bene quali sono le ultime politiche di AWS.
#2 Come scegliere una soluzione per la scansione delle vulnerabilità AWS
La prima cosa da fare, dunque, è scegliere il sistema di scansione adeguato. Le scansioni possono essere eseguite manualmente, il che significa che spesso richiedono tempo e possono essere soggette a errori.
Il metodo migliore per condurre scansioni delle vulnerabilità di AWS è installare un’istanza virtuale di un’appliance di scansione delle vulnerabilità direttamente in AWS. La scelta dell’appliance più adatta dipende sia dalle esigenze di scansione delle vulnerabilità previste dalla propria azienda sia dall’esperienza degli amministratori della sicurezza responsabili della procedura.
Le appliance di scansione delle vulnerabilità virtuali sono generalmente in grado di scansionare indirizzi IP privati e pubblici all’interno di EC2 e Amazon Virtual Private Cloud, indirizzi IP privati collegati ad Amazon tramite una VPN IPSec e indirizzi IP pubblici su Internet.
- Appliance di terze parti – Molte appliance sono progettate per funzionare con il modello di sicurezza condiviso di AWS per garantire che le aziende non violino i test di penetrazione di Amazon e le regole di scansione delle vulnerabilità. Sono molte le terze parti che forniscono questo tipo di strumenti: Virtual Scanner Appliance di Qualys o Tenus’s Nessus, solo per citare i più noti.
- Appliance open source – Esistono anche opzioni open source, come Scout2 o Pacu, così come le appliance fornite direttamente da AWS come, ad esempio, il servizio di valutazione della vulnerabilità di Amazon Inspector progettato per le app distribuite su EC2.
- Appliance as a Service – Le appliance possono essere acquistate dal Marketplace di Amazon e distribuite tramite Amazon Machine Image (AMI). Una volta acquistato un abbonamento al sistema di scansione delle vulnerabilità, l’istanza AMI può essere avviata direttamente dalla console AWS EC2. L’abbonamento all’appliance di scansione virtuale richiede in genere un abbonamento in modalità SaaS: in alcuni casi è inclusa come parte dell’abbonamento standard mentre in altri casi risulta come una funzionalità aggiuntiva.
#3 Analogie e differenze tra un’appliance e l’altra
Sia gli strumenti di terze parti che quelli open source elencano generalmente le vulnerabilità classificate come critiche, alte, medie e basse rispetto alla fornitura di un indice. Molti strumenti offrono anche una prioritizzazione delle risposte, fornendo una serie di raccomandazioni utili.
Alcuni scanner virtuali, se dotati di credenziali di amministratore valide (per Windows) o root (su sistemi Unix), possono fornire livelli di patch per il sistema operativo, per il software di terze parti e per le vulnerabilità relative alla configurazione del sistema.
Esistono anche strumenti che offrono una funzione di reportistica che consente di mappare gli asset rispetto alle tipologie di attacco tale da consentire un’analisi dello storico in vista di evoluzioni future. Nelle appliance di terze parti si trovano anche sistemi che includono il rilevamento delle risorse, il rilevamento delle intrusioni, il rilevamento delle minacce interne, l’analisi del comportamento degli utenti, il monitoraggio dell’attività del cloud e altro ancora.
#4 Valutare la frequenza delle scansioni
Per garantire l’AWS security è importante anche valutare attentamente la periodicità con cui verranno eseguite le scansioni. La parola magica è la continuità: lo svolgimento regolare di questo tipo di monitoraggio e controllo garantisce che i buchi a livello di sicurezza vengano identificati e risolti in modo tempestivo.
Le appliance, dunque, possono essere programmate per eseguire una scansione su un arco temporale qualsiasi. Le opzioni più gettonate sono quelle trimestrali, semestrali o annuali.
Esistono però anche alcuni strumenti che offrono un monitoraggio in tempo reale. La cadenza, infatti, dipende in gran parte dalle risorse gestite e dai motivi legati alle necessità di scansione delle vulnerabilità. Un conto è ottemperare a un requisito di sicurezza dell’organizzazione e un altro allinearsi a una conformità normativa come, ad esempio, SOC 2, HIPAA, ISO 27001, PCI DSS e FedRAMP.
#5 Conoscere i costi
Il costo di un’appliance virtuale di scansione delle vulnerabilità va ripartito in due:
- Il primo costo riguarda il cosidetto bring-your-own-license relativo alla gestione dell’AMI.
- Il secondo costo riguarda il servizio che AWS richiede per l’esecuzione dell’appliance e che va a coprire la capacità di calcolo necessaria (che rappresenta il costo maggiore), in funzione del tipo di istanza, della quantità di memoria utilizzata e della quantità di dati in ingresso e in uscita.
#6 Eseguire la scansione per identificare i rischi
Una volta scelta la soluzione più adatta per la scansione delle vulnerabilità, averla installata e aver mappati i sistemi presenti nell’ambiente, è finalmente possibile eseguire la scansione.
L’appliance cercherà vulnerabilità comuni come, ad esempio:
- errori nel codice del software
- configurazione errata del software
- software senza patch
- problemi di conformità
Molti strumenti possono anche intercettare:
- IP e domini dannosi
- vulnerabilità delle credenziali
- problemi di controllo degli accessi
- Problemi di sicurezza del bucket S3
Attenzione però: nel perimetro dell’AWS security non rientra l’uso dei sistemi di scansione delle vulnerabilità per:
- Attacchi o simulazioni DDoS
- Flooding (protocollo di instradamento usato dai router per i pacchetti in ingresso su tutte le linee ad eccezione di quella da cui proviene)
- Monitoraggio relativo alla richiesta di risorse
#7 Analizzare sempre i risultati
L’efficacia degli strumenti non può prescindere dall’abilità del personale dedicato a seguire l’attività. È necessario avere in azienda le competenze tecniche necessarie a interpretare i risultati dei processi di scansione delle vulnerabilità. Una volta identificati e classificati i rischi, il personale preposto dovrebbe mettere in atto un piano per rimediare ai buchi dell’AWS security, aggiornando tutti i processi e attuando delle contromisure per impedire che si presentino problemi i in futuro.
Per quanto gli strumenti di scansione delle vulnerabilità siano molto utili, è sempre bene ricordarsi che non sono esenti dai falsi positivi. Alcuni, ad esempio, potrebbero non essere in grado di valutare la gravità di una vulnerabilità rispetto a u determinato contesto organizzativo. Al di là di questo accorgimento, la scansione delle vulnerabilità dovrebbe essere una componente integrata alla distribuzione di server all’interno di AWS. Perché la sicurezza non è una cosa che si ha: è una cosa che si fa.
