Vi avviso subito, questo post e’ composto da considerazioni che ho tratto da tre diversi articoli, che infatti indichero’ in fondo come fonti, quindi per risparmiarvi la noia di leggere i miei pensieri scomposti vi conviene leggere direttamente i tre articoli.
State continuando a leggere? Peggio per voi, vi avevo avvisati. L’argomento e’ molto interessante, si tratta della sicurezza ai tempi del Cloud Computing, ci entra a pieno titolo anche il nuovo sistema operativo di Mountain View, Google Chrome OS. L’argomento e’ complesso, dunque la trattazione da parte mia non potra’ che essere incompleta, superficiale ed a tratti scontata o errata [1].
I PROBLEMI DEL CLOUD COMPUTING – Qualche giorno fa l’ENISA (Agenzia europea per la sicurezza delle reti e dell’informazione) ha pubblicato un’approfondita analisi sui benefici e sui rischi del cloud computing in termini di sicurezza (Cloud Computing Risk Assessment). Il documento e’ bello corposo, tra le altre cose si concentra sulle PMI, perche’, come e’ scritto sullo stesso documento:
“Data la riduzione dei costi e la maggior flessibilita’ che comporta, il passaggio al cloud computing diventa irresistibile per molte PMI”
Col passaggio al clod computing pero’ ci sono almeno tre possibili rischi.
PORTABILITA’ – Uno di questi e’ il rischio di Lock-in, ossia il rischio di restare legati a quel fornitore del servizio, perche’ per il cliente puo’ diventare difficile passare da un fornitore ad un altro e trasferire i suoi dati da un servizio ad un altro. I fornitori ovviamente faranno di tutto per creare le condizioni affinche’ il cliente trovi difficile (o impossibile) la migrazione. Ad esempio chiudendo il formato dei dati, in modo da renderne difficile la portabilita’, legando il cliente ad un software proprietario, ecc.
Il fornitore gestisce un’applicazione web che mette a disposizione dei propri clienti via internet, si chiama SaaS (software come un servizio), e memorizza i dati dei clienti in un database. Generalmente i gestori di SaaS forniscono ai clienti delle API che permettono di leggere ed eventualmente esportare i dati. Esistono anche i servizi di PaaS, dove i fornitori mettono a disposizione degli utenti delle piattaforme hardware con applicazioni disponibili su web.
Tuttavia non sempre l’esportazione dei dati tramite API e’ alla portata di tutti, puo’ capitare che sia necessario sviluppare un’applicazione apposita che tramite le API interagisca col database esportando i dati richiesti e scrivendoli in un file pronto per essere usato per qualunque cosa, anche ad esempio essere importato in un altro provider.
Se pero’ questa possibilita’ non viene garantita a tutti i clienti risulta ovvio che ci sara’ un fenomeno di lock-in. Infatti generalmente le piccole e medie imprese non hanno uno sviluppatore in loco, diventa quindi una spesa aggiuntiva far sviluppare l’applicazione necessaria per “traslocare“. Anche se il piu’ delle volte e’ il nuovo fornitore stesso a occuparsi del trasferimento dei dati (con un costo aggiuntivo ovviamente). Se pero’ la PMI non vuole affidarsi ad un nuovo fornitore, ma mettere i suoi dati nel database dell’impresa, la difficolta’ di trasferire i propri dati da un database esterno ad uno interno, potrebbe scoraggiarla dal farsi carico della gestione dei propri dati.
Sarebbe dunque preferibile affidarsi ad un servizio che fornisca un’ottima portabilita’, perche’ anche se nell’immediato potrebbe sembrare irrilevante, nel medio e lungo periodo e’ indispensabile poter contare sulla possibilita’ di cambiare servizio o gestire i propri dati senza problemi.
SICUREZZA – Gli altri problemi riguardano la sicurezza, non tutti i gestori di cloud computing attuano tutti gli accorgimenti volti a impedire problemi di sicurezza, e non si tratta solo di accorgimenti sul server del fornitore, ma anche di sistemi che rendano sicuri i “dati in movimento“ dal computer del cliente al server. In entrambi i casi i rischi esistono e sono diversi (divulgazione di informazioni, intercettazioni, Denial-of-Service).
ATTENTI ALLA PASSWORD – Un grande passo in avanti nel cloud computing lo fara’ il nuovo sistema operativo di Mountain View tra un anno, quando verra’ commercializzato. Nelle varie discussioni e nelle presentazioni si fa ampio riferimento alla sicurezza di questo nuovo sistema operativo, di come il sistema venga installato su una una partizione accessibile in sola lettura (rendendo improbabile la presenza di virus e malware), in piu’ in caso di presenza di codice malevolo un semplice riavvio ripristinera’ il sistema pulito.
Ma uno dei piu’ grandi problemi di sicurezza del cloud computing (e non solo) si trova tra la sedia e la tastiera. Sono proprio gli utenti. Prendete ad esempio il caso di Google Chrome OS, potete accedere ai vostri dati da qualsiasi dispositivo con Google Chrome OS, semplicemente inserendo nome utente e password. Se questo da un lato e’ una grande comodita’, dall’altro e’ un rischio enorme. Chiunque con il nostro nome utente e la nostra password potrebbe avere accesso a tutti i nostri dati, e stiamo parlando anche di dati (estremamente) sensibili, email personali, dati sui nostri conti correnti bancari, e tutti i nostri file e i documenti.
Google non si occupa di questo problema, demandandone la responsabilita’ ai singoli utenti. Ma siamo sicuri che i singoli utenti siano in grado di scegliere una password abbastanza sicura da non essere trovata dal primo che capita?
Secondo uno studio condotto su MySpace, il 65% di tutte le password contiene 8 caratteri [2] o meno e queste sono le password piu’ gettonate: password1; abc123; myspace1 e password. “Vabbe’, sono ragazzini per la maggior parte“, direte voi. Pero’, secondo un altro studio, condotto questa volta su 1300 impiegati in grandi imprese ha evidenziato come il 66% di loro tiene la password scritta in fogli di carta nell’ufficio, e il 58% tiene la password in un file nel computer (documento di Word o foglio di calcolo).
A mio avviso Google questo problema non puo’ semplicemente scaricarlo sugli utenti, se ne dovra’ fare carico. Se vuole veramente fornire un servizio sicuro dovra’ inventarsi un sistema di autenticazione un po’ piu’ sicuro di “nome utente e password“. Il massimo che sembra essere intenzionata a fare mi pare sia un sistema di crittografia, ma non credo protegga dall’accesso tramite password, serve eventualmente per proteggere i dati da un accesso non autorizzato.
LADRI DI PASSWORD SU COMMISSIONE – Non dimentichiamo che grazie al cloud computing i ladri di password possono avere accesso ad un’alta capacita’ di calcolo, rendendo possibile “scovare” anche password che prima si ritenevano sicure. Inoltre alcuni attacchi avvengono su commissione, piu’ e’ elevato il livello di complessita’ di una password piu’ sara’ alto l’onorario. Il tutto usando attacchi di brute force (possibilmente senza venire bloccati dai sistemi di sicurezza). Immaginate cosa succedera’ con l’espansione del cloud computing usato anche da imprese.
David Campbell (consulente sulla sicurezza) ha dichiarato:
“As it becomes possible now for the black hat community to get their hands on large amounts of computing power, we as security professionals are going to need to reassess threat models that we thought previously were not a factor, [...] Using stolen credit cards, they could create a super computer that would be faster potentially than what the three-letter agencies have and they wouldn’t be paying for the CPU cycles.”
L’accorgimento piu’ ovvio in questi casi e’ che chi fornisce servizi a cui si accede tramite password implementi un sistema che blocchi l’accesso dopo alcuni tentativi errati (molti lo fanno gia’ fortunatamente). In assenza di questi meccanismi nessuno e’ al sicuro, nemmeno chi usa password complesse.
[1] Sembra un post scritto da Aranzulla, mi vergogno di me stesso. [^]
[2] La password piu’ e’ lunga meglio e’, molti consigliano sopra i 14 caratteri, inoltre dovrebbe contenere (quando e’ possibile) non solo lettere (maiuscole e minuscole) e numeri ma anche i caratteri speciali (# $ % £) [^]
Fonti:
[^] torna su | post<li> | 
Diamo per scontato che abbiate una scheda wireless funzionante e con i driver installati, senza mettere mano al file 
Il 18 ottobre sulla mailing list degli annunci degli sviluppatori di Debian compare 
Ora andiamoci a leggere quanto Steve McIntyre (attuale leader del progetto Debian) ha 
