Cloud e livelli di servizio

Leggo qui di una serie di disservizi che ha colpito alcuni servizi di Google. Il motivo per cui l’articolo ha attirato la mia attenzione è l’accenno al livello di servizio dichiarato da Google per “Apps for business” (99.9% di uptime)  in rapporto ai guasti di questa settimana. Quello dell’uptime dichiarato è un tema che serve da tempo immemore per mostrare come i livelli di servizio siano una questione tutt’altro che banale. il 99.9% vuole dire che è tollerato un giorno su mille di disservizio, ma naturalmente c’è differenza ad esempio, per chi ci deve lavorare, se si tratta di disservizi della durata di un minuto, o se il disservizio è di una giornata consecutiva. Il computo di Google è fatto mensilmente, secondo la tabella, quindi per ogni mese sono tollerati circa tre quarti d’ora di disservizio… come giustamente segnala l’articolo, in questa settimana diversi utenti si sono già trovati oltre questo limite. A parte la possibilità per loro di dimostrare che il disservizio c’è stato, che affidabilità ha un fornitore che è già noto che non rispetta i propri SLA, per una percentuale imprecisata di utenti? Certo, per molti dei suoi utenti il problema non si è manifestato (o non se ne sono accorti), ma il punto non è quello e non è neanche Google in sé: il punto è che la sua infrastruttura non sembra garantire che lo SLA sia rispettato, anzi sembrerebbe il contrario, anche se poi sui grandi numeri finora gli è andata bene. Il problema  degli SLA è che… finché non c’è il guasto, il sistema funziona ;)

Ma il vero punto dei livelli di servizio sono le penali, ovvero: cosa succede se invece il servizio rimane fermo per più di un giorno ogni tre anni, in violazione di quanto promesso? Così mi sono andato a cercare gli SLA del servizio, e ci ho trovato esattamente quello che mi aspettavo (alla data di oggi).

Cominciamo quindi con una serie di definizioni, la più interessante delle quali mi sembra questa:

“Downtime” means, for a domain, if there is more than a five percent user error rate. Downtime is measured based on server side error rate

Astraiamoci da Google e pensiamo a generici servizi in cloud.

Immaginiamo quindi che il servizio sia utilizzato da un’azienda per gestire la propria contabilità. Se c’è un tasso di errori di meno del cinque per cento, non è nemmeno downtime. Sarebbe interessante sapere cosa intendono per errori, ma potenzialmente la nostra azienda si potrebbe trovare con almeno una fattura su 25 registrata in modo errato (o magari persa?) senza che sia neppure downtime. Questo ci porta ad una considerazione importante: quando si parla di cloud si pensa sempre alla disponibilità, ma con la complessità di certe architetture anche l’errore e la perdita di dati sono problemi tutt’altro che trascurabili.

Ma la vera essenza dello SLA è quella riportata nel primo paragrafo e nella tabella, che è la classica clausola “per il consumatore” che si trova anche in molti contratti di connettività:

If Google does not meet the Google Apps SLA, and if Customer meets its obligations under this Google Apps SLA, Customer will be eligible to receive the Service Credits described below. This Google Apps SLA states Customer’s sole and exclusive remedy for any failure by Google to meet the Google Apps SLA.

Bene, quindi se la mia azienda resta con l’amministrazione ferma per 10 giorni… quello che ottiene sono altri quindici giorni di servizio a fine contratto. Fantastico.

Ora mi permetto una piccola analogia: immaginiamoci che un fornitore di materiale da costruzione vi venda delle travi d’acciaio che sono garantite per una certa tensione di rottura, e che vi dica che… se per caso le travi non sopportano effettivamente quella tensione, ve ne danno un’altra gratis. Le usereste per fare un ponte? No, ma non si porrebbe neanche il problema: la trave deve reggere, non importa se la trave in sé costa poco, e per garantire che regga ci si prendono una serie di margini di sicurezza notevoli. Allora, se il cloud deve servire per delle infrastrutture importanti e non solo per giocare, bisogna cominciare a ragionare negli stessi termini, compresi i margini di sicurezza dimostrabili.

Naturalmente si può dire che le infrastrutture IT sono molto più complesse di qualsiasi altra, e in parte è certamente vero, ma è anche vero che nell’IT la robustezza è un costo che si può trascurare con molta più facilità, mentre invece, proprio per la maggiore complessità dei sistemi, non dovrebbe essere così.

Giusto per fare un esempio, prima di parlare di banda larga a piacere, bisognerebbe parlare di banda garantita: se la rete sarà lo strumento con cui aziende e cittadini interagiranno fra loro e con la PA, allora non dovrebbe essere possibile un’offerta in cui la connettività va giù ad ogni temporale e viene ripristinata “nelle 48 ore lavorative” quando va bene…

Posted in ict, Sicurezza | Tagged , , , | Leave a comment

Parlamentarie e sicurezza

Leggo in questi giorni delle “primarie” interne al Movimento 5 Stelle. I commenti sono i più vari, ma vorrei fare qualche considerazione assolutamente non politica, ma tecnica. E parto dalla conclusione, che per chi segue questo blog non sarà una sorpresa: le votazioni online sono un’ottima cosa per quei casi in cui l’interesse a imbrogliare è tanto basso da essere abbondantemente superato dai vantaggi di partecipazione. Ad esempio, è ottimo per le associazioni culturali. Ma non appena anche solo il sospetto della possibilità di brogli è significativo, la votazione online mostra tutti i suoi limiti. Non mi ripeto su tutte le questioni tecniche, che ho già discusso tante volte, mi limito a riassumere alcune considerazioni.

Il voto da remoto non offre nessuna garanzia rispetto al controllo e alla coercizione. Addirittura, ricordo di aver letto di un liceo in US in cui i genitori controllavano chi i figli votassero (online) per il consiglio studentesco.

Il voto elettronico non offre garanzie reali rispetto a “modifiche” degli apparati o dei programmi che permettano di modificare i risultati. Non mi ripeto, chi vuole approfondire può leggere i post precedenti sull’argomento, ma il voto elettronico al seggio viene ormai abbandonato da tanti paesi proprio per motivi di sicurezza, figuriamoci quello da remoto. Su questo c’è una considerazione importante: anche se fosse possibile avere delle garanzie, sarebbero verificabili solo da tecnici informatici specializzati nel campo della sicurezza (io, ad esempio). Questo vuole dire che l’elettore/candidato, che attualmente può partecipare al processo di verifica facendosi nominare rappresentante di lista, delegherebbe tutto il suo potere di controllo a noi tecnici: quello che gli raccontiamo, lui deve credere.

In ogni caso, offrire delle garanzie seppur minime richiederebbe un processo molto più complesso e costoso di quello che leggo riguardo alle Parlamentarie…

In caso si sospettino brogli, e ricordo i sospetti di brogli alle politiche di qualche anno fa, sarebbe molto difficile fugare i dubbi, perché non ci sarebbe niente da ricontare. L’uso del voto elettronico al seggio si sta infatti orientando sempre più verso il voto verificabile mediante la stampa di una scheda cartacea, ma è praticabile solo al seggio. Il solo fatto che sia difficile fugare i sospetti di brogli secondo me indebolisce la democrazia.

Quindi, come ultima considerazione: il web e Internet sono ottimi per molte cose: fa male chi li sottovaluta, ma si illude chi pensa che ci si possa fare tutto.

 

Posted in ict, Sicurezza | Tagged , | 1 Comment

Spear phishing, altro che…

Leggo qui che ad un grosso ente pubblico USA sono stati sottratti 75 Gbyte di dati personali relativo a quasi quattro milioni di cittadini, compresi i soliti dati come numeri di carta di credito, numeri di conto corrente bancario eccetera. Come è stato effettuato l’attacco si legge qui: spear phishing. Lo spear phishing è un phishing mirato, che invece di inviare mail a indirizzi a caso, invia mail realizzate appositamente per colpire i dipendenti di una specifica organizzazione, cercando di convincerli a inserire le proprie credenziali in una pagina civetta o ad eseguire del codice che comprometterà il loro pc. Lo spear phishing è alla base degli attacchi di maggiore scalpore degli ultimi tempi, compreso quello a RSA dello scorso anno.

È una forma di social engineering,  come tale si basa su comportamenti scorretti da parte degli utenti. Il che vole dire che si contrasta con un insieme di misure tecnologiche, di politiche ma soprattutto di sensibilizzazione specifica all’utenza. Esercitazioni di spear phishig possono mostrare come, se ben praticato, percentuali molto elevate del personale di un’organizzazione possono consegnare all’attaccante le proprie credenziali, mentre ad un attaccante spesso bastano quelle di un solo utente… Una volta avuto accesso alla rete aziendale con le credenziali di un utente, le possibilità di accesso a informazioni riservate o di praticare ulteriori attacchi per accedere alle credenziali di altri utenti sono generalmente ampissime. Trovo abbastanza curioso che ci sia sempre tanta attenzione al testing delle applicazioni web, e così poca al testing dei propri utenti. Eppure, un’attività di sensibilizzazione mirata può essere estremamente efficace, in modo misurabile.

 

Posted in ict, Sicurezza | Tagged , , , , , | Leave a comment