• Non ci sono risultati.

Violazione dei dati e integrità delle risorse

Nel documento Il Cloud Computing in ambito sanitario (pagine 79-81)

PARTE SECONDA SICUREZZA E CONTROLLO DEI SERVIZI IN CLOUD

3. Analisi di vulnerabilità, minacce e rischi del cloud computing

3.2 Minacce, rischi e contromisure

3.2.1 Violazione dei dati e integrità delle risorse

Quando più macchine virtuali appartenenti a utenti diversi (tenant), con- dividono la stessa macchina fisica, le vulnerabilità sui dati e sugli oggetti virtuali (VM, immagini e reti) in un sistema multi-tenant non progettato cor- rettamente, possono essere sfruttate da un attaccante per accedere non solo ai dati dell‟utente vittima, ma ai dati di tutti gli altri tenant, ponendo a rischio la confidenzialità. Ci sono diversi studi al riguardo che utilizzano tecniche sofisticate di covert e side channels8586.

Possibili contromisure possono essere la cifratura dei dati memorizzati, che aiuta a ridurre l‟impatto di una eventuale violazione, ma che, in caso di perdita o compromissione delle chiavi, può comunque portare ad un‟ennesima criticità o fare uso di firme digitali.

Anche un eventuale mancato controllo sull‟integrità delle immagini messe a disposizione nei repositories pubblici può essere sfruttata per com- promettere l‟utilizzo delle macchine virtuali e costituire una criticità per tutti coloro che ne usufruiranno. Per esempio un attaccante con un account valido può depositarvi un‟immagine con codice malevolo come un trojan horse, oppure potrebbe recuperare dei dati confidenziali (password, chiavi critto- grafiche) da immagini dismesse e non opportunamente “ripulite”.

È necessario che le immagini dei sistemi operativi delle VM siano me- morizzate localmente in un singolo storage logico o library, così da velociz- zare i tempi di accesso in caso di ripristino e diminuire i tempi di disservizio.

85 Z. WANG, R. B. LEE, Covert and Side Channels due to Processor Architecture, in Proceed-

ings of the 22nd Annual Computer Security Applications Conference, 2006 pp.473-482

86 Y. XU, M. BAILEY, F. JAHANIAN, K JOSHI, M. HILTUNEN, R. SCHLICHTING, An

Exploration of L2 Cache Covert Channels in Virtualized Environments, in Proceedings of the

72 Inoltre, non deve mai mancare un‟adeguata protezione dall‟accesso non au- torizzato e una puntuale verifica della loro integrità mediante meccanismi di

checksums, le cui informazioni devono risiedere separatamente dalla library.

Le minacce ai dati possono anche essere condotte tramite network dall‟esterno nel momento in cui la rete virtuale è connessa alla rete fisica.

Gli utenti, per accedere in maniera sicura al cloud, hanno bisogno di uti- lizzare canali di comunicazione protetti per preservare privacy e integrità. Soluzioni di tunnel VPN o accessi remoti con SSH, tra client e provider, ga- rantiscono, con efficaci algoritmi di cifratura, un‟adeguata protezione sino all‟accesso, ma non mettono al sicuro i percorsi interni al cloud. L‟uso dello standard WS-Security all‟interno, protegge a livello di messaggio SOAP le comunicazioni con i Web Services, ma in questo modo dovrà essere garanti- to il supporto degli standard in tutti i punti.

Le minacce dall‟interno possono partire da una VM all‟altra, se non vi è un‟opportuna separazione tra le VM ospitate sullo stesso host fisico. Un at- taccante può sfruttare la tecnica dell‟Address Resolution Protocol (ARP) Poisoning per falsare la tabella ARP della VM vittima con uno spoofing di coppie fittizie di indirizzi MAC e IP (ponendo come MAC il proprio e come IP quello del target), reindirizzando il traffico, in uscita dalla VM e diretto all‟IP del target, verso di sé e guadagnandone l‟accesso (attacco di tipo man-

in-the-middle)87.

Pertanto la rete virtuale va adeguatamente protetta prendendo spunto da- gli strumenti e dalle tecniche applicati alle reti fisiche e abilitando canali di comunicazione sicuri per mezzo della crittografia a chiave pubblica88, contro il network sniffing.

Le VM sono tenute isolate dall‟hypervisor non potendo leggere memo- ria, dati e usare le applicazioni di un‟altra. Tuttavia sono ancora possibili ac- cessi non autorizzati e port scanning.

Le contromisure risiedono nell‟aggiungere una protezione di tipo fire- wall, antivirus e/o anti-spyware e intrusion detection ad alcune o tutte le VM, tenendo però in considerazione un possibile rallentamento nelle per-

87 W. CHRISTIAN, C. MEINEL, Practical Network Security Teaching in an Online Virtual

Laboratory, in Proc. 2011 Intl. Conference on Security & Management , 2011, CSREA Press,

Las Vegas, Nevada, USA

88

VMware, Properly Configure VLANs, in vSphere Security, 2012, http://pubs.vmware.com/ rvsphere-51/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-51-security-guide.pdf

73 formance a causa dell‟impiego di risorse extra per effettuare la scansione simultanea delle VM. Oppure il firewall potrebbe essere previsto solo tra due VM in particolare o tra la scheda di rete fisica del server e una VM.

In aggiunta è possibile segmentare la rete virtuale confinando il traffico in VLAN distinte tra gli switch virtuali o usare schede di rete fisiche per se- parare in maniera ancor più sicura le zone virtuali tra loro, aumentando i co- sti per dispositivi e cablaggio.

Un‟altra possibile minaccia, nel caso in cui siano abilitate le VLAN su

switch che supportano le VLAN native (trasportano traffico privo di tag i-

dentificativo della VLAN), potrebbe consistere nell‟attacco VLAN-hopping che consente di raggiungere il target su una VLAN che normalmente non sa- rebbe accessibile per l‟attaccante. Sfrutta la tecnica del double tagging per inserire nel frame inviato un doppio tag. Quello più esterno identifica la VLAN nativa, quello più interno la VLAN del target. Il primo switch incon- trato dal frame, prima di inoltrarlo al successivo switch, elimina il tag ester- no poiché sulla VLAN nativa devono essere convogliati frame senza tag, mostrando così il tag interno, che può essere letto e quindi accettato dal se- condo switch e raggiungere il target su quella VLAN, dopo aver eliminato anche questo secondo tag89.

Per il VLAN-hopping gli switch virtuali VMware non supportano la VLAN nativa, ad ogni modo la vulnerabilità può ancora essere sfruttata se sono presenti altri switch configurati per utilizzarla. È essenziale evita- re,quindi, di utilizzare la VLAN nativa. Inoltre, è bene eliminarla da quelle consentite sui link di trunk o comunque sceglierne una che non sia realmente utilizzata nella rete.

Nel documento Il Cloud Computing in ambito sanitario (pagine 79-81)