Google e la nostra privacy, qualche esempio hands on

Molto spesso sento dire "che mi importa se mi rubano la password, cosa vuoi che vedano?".

Oggi proviamo a fare un gioco di prestigio. Prendiamo il nostro account google, ci offre molti servizi, ma che vuoi ci sia al suo interno? Pronti a stupirvi?


https://www.google.com/maps/timeline

Qui trovate tutti i vostri spostamenti. Tutti. Nel mio caso, dal 2014 in poi. Divertitevi a cliccare sui puntini rossi, scoprirete che viene memorizzato proprio tutto, ogni percorso, sosta, persino se siete andati a piedi o in auto.




https://myaccount.google.com/activitycontrols

Facciamo una cosa, "tagliamo corto", clicchiamo su questo link. Scopriamo insieme cosa viene memorizzato.

Bhè, ovviamente le ricerche effettuate con chrome e youtube... che domande.

 

Vanno tanto di moda i dispositivi, quindi non volete memorizzare tutto ciò che avete detto con "ok google" ?

Nel mio caso il termostato di casa aveva sufficienti elementi per denunciarmi per stalking.

Ovviamente non parliamo dei file, tramite google drive (ora backup e sync), sempre più aggressivo (basta inserire una chiavetta per allertarlo e domandarci se vogliamo fare il backup di quei file.

Vogliamo dimenticarci ovviamente dei contatti del telefono? E delle email su gmail e quindi di tutti gli account di registrazione fatti con la stessa email altrove?

Qualora fosse sfuggito qualcosa... bhè... ci sono sempre i DNS di google, il classico 8.8.8.8 e 8.8.4.4 che raccolgono tutto ciò che è (casomai) sfuggito...

A breve farò un esperimento. A tempo debito ci sarà da divertirsi. Avete presente quando cercate qualcosa e per una settimana tutte le pubblicità vi tartassano con prodotti correlati? Il fenomeno è diffuso e normato... ma...

Gare d'appalto, qualche proposta per migliorare la trasparenza.

Mi rendo conto, questo post è molto fuori contesto rispetto a tutti gli altri, ma ho comunque voluto esprimere un parere alla luce di oltre 15 anni di Gare impiantistiche.

Il nuovo codice degli appalti è valido, ma è (come ogni cosa) perfettibile. Ci sono aspetti che aprono dei varchi ad una possibile assenza di trasparenza. Personalmente, nel corso di questi anni, ho sviluppato un personale parere e delle personali proposte per migliorare le regole con cui le aziende giocano la propria partita nel mondo delle Gare che, ripeto, è stato migliorato comunque esponenzialmente nelle ultime revisioni.

La riparametrazione

La riparametrazione è un meccanismo con il quale la Stazione Appaltante (previa dichiarazione di voler adottare questa procedura in fase di bando) ridistribuisce in maniera lineare i punteggi della componente tecnica per portarli al massimo valore.

Esempio:

Punteggi: 80 al tecnico e 20 all'economico.

Azienda 1: prende 70 punti al tecnico.

Azienda 2: prende 60 punti al tecnico.

Azienda 3: prende 50 punti al tecnico.

Mediante il meccanismo della riparametrazione, l'Azienda 1 viene portata a 80 punti, l'Azienda 2 viene portata a 76 e l'azienda 3 a 60 (ho banalizzato, l'equazione è molto complessa, vi scongiuro, non mi fate fare i calcoli esatti).

Accade quindi che la classifica finale viene falsata in quanto il punteggio economico diviene ancor meno importante. Proporre un prodotto meno costoso fa parte di una strategia di libera concorrenza che, in questo caso, viene penalizzata.

Il ruolo del progettista

Il ruolo del progettista è troppo predominante in quanto un progettista può, di fatto, dare una linea progettuale troppo favorevole verso l'una o l'altra azienda semplicemente stringendo la selezione del prodotto sfavorendo la libera concorrenza.

Troppo spesso i prodotti da utilizzare richiesti in fase di progetto non sono ragionevolmente aperti ad una libera riflessione, ma hanno esattamente le caratteristiche tecniche di un solo marchio/modello. L'eccessiva specificità nella richiesta progettuale pone evidenti vantaggi nei confronti di chi ha rapporti commerciali particolareggiati con il marchio (di fatto) esplicitamente richiesto.

Facciamo un esempio:

Da progetto devo chiedere un link radio che collega A con B. Un conto è sviluppare una richiesta progettuale di questo tipo:

- Link radio a 5 Ghz

- Guadagno Antenne almeno 16 dbi

- Possibilità di gestire gli allarmi in maniera centralizzata

- Temperatura di esercizio da -10 a +60°C

- Banda nominale 450Mbit

- Certificazione CE

- Sincronizzazione GPS

Un conto è richiedere:

- Dimensions Radio Box 938.4 x 468.4 x 281.4 mm (36.94 x 18.44 x 11.08") 1042 x 573 x 502 mm (41.02 x 22.56 x 19.76") Weight Radio (Mount Included) Box 16 kg (35.27 lb) 26.5 kg (58.42 lb) 

- Max. Power Consumption 40W Power Supply 50V, 1.2A PoE GigE Adapter (Included) Power Method Passive Power over Ethernet Supported Voltage Range +42 to +58VDC, -48VDC 

- Automatic Transmit Power Control (ATPC) 

- Certifications CE, FCC, IC Mounting Pole Mount Kit (Included) Wind Loading 863 N @ 200 km/hr (194 lbf @ 125 mph) 

- Wind Survivability 200 km/hr (125 mph) 

- Operating Temperature -40 to 55° C (-40 to 131°F) 

- LEDs (12) Status LEDs: Data Port Link/Activity Data Port Speed Management Port Link/Activity Management Port Speed 

- GPS Synchronization Master/Slave Link Status Modulation Mode 0.25x to 4x, 6x, 8x, 10x (Unlabeled), Overload Remote and Local Displays (Calibrated Signal Strength) 

- Operating Frequency AF-5 FCC 15.247, 15.407, IC RSS-210 ETSI EN 301 893, EN 302 502 Other Regions 5470 - 5600 MHz, 5650 - 5850 MHz 5470 - 5875 MHz 5470 - 5950 MHz AF-5U FCC 15.247, IC RSS-210 ETSI EN 302 502 Other Regions 5725 - 5850 MHz 5725 - 5875 MHz 5725 - 6200 MHz 

- Interface Data Port (1) 10/100/1000 Ethernet Port Management Port (1) 10/100 Ethernet Port Auxiliary Port (1) RJ-12, 

- Alignment Tone Port System Maximum Throughput 1.2+ Gbps Maximum Range 100+ km (Dependent on Regulatory Region) Packets per Second 1+ Million Encryption 128-Bit AES Uplink/Downlink Ratio 50% Fixed Latency Full Duplex Mode Half Duplex Mode < 200 µs at Full Throughput < 2 ms at Full Throughput Radio Frame Synchronization GPS Dynamic Frequency Selection AF-5 AF-5U CE, FCC/IC CE (FCC/IC Not Applicable) MTU (Maximum Transmission Unit) Up to 9600

Dettagli totalmente insignificanti e non utili ai fini progettuali hanno come unico effetto limitare la libera concorrenza e favorire chi con il marchio palesemente richiesto a capitolato ha un rapporto commerciale di tutela.

Non basta la voce "o similare" (principio di equivalenza: http://www.sentenzeappalti.it/2016/11/20/principio-di-equivalenza-obbligo-di-valutazione-di-prodotti-con-specifiche-tecniche-analoghe-sussiste-onere-del-concorrente-dimostrare-lequivalenza-sin-dalla-presentazione-dellofferta-art/), bensì i dettagli non utili ai fini progettuali non devono essere motivo di esclusione, perchè qui si annida la maggior parte delle zona d'ombra, da sempre. 

E aggiungo: anche nelle voci rilevanti, le richieste devono essere ragionevoli. Una temperatura di esercizio di -70°C va bene al Polo Nord, ma in Lombardia direi che non è necessario, anzi inopportuno e deve richiedere come minimo un giustificativo.

Il progettista, inoltre, deve cercare sempre in primo luogo di favorire prodotti liberamente acquistabili e liberamente disponibili. Non è ammissibile, a titolo esemplificativo, che una gara contenga una specificità non reperibile liberamente sul mercato (come purtroppo recentemente sta accadendo sempre più spesso).

Requisiti del progettista

I requisiti affinchè un progettista partecipi ad una gara per la progettazione di un impianto spesso sono troppo stringenti, questo fa si che i nuovi progettisti non riescano ad inserirsi in contesti in cui potrebbero mostrare talento. Bisogna disincentivare in qualche modo, quindi, che i progetti vengano fatti sempre dagli stessi.

La Commissione di gara

La commissione di gara deve essere realmente sorteggiata ed ogni componente deve provenire da aree geografiche differenti e con competenze specifiche sull'oggetto di gara. E' inammissibile che la Commissione sia composta, come a volte accade, da tre persone provenienti dello stesso ufficio. Così come è chiaramente un'anomalia che un ingegnere idraulico valuti un progetto di una gara di videosorveglianza cittadina.
A mio avviso, inoltre, la Commissione dovrebbe rimanere segreta fino alla pubblicazione dei punteggi tecnici ed ogni componente non deve aver valutato più di una gara all'anno. Sono metodologie restrittive, mi rendo conto, ma non c'è altro modo. Se in commissione capitano sempre gli stessi (nonostante vi sia un "principio di rotazione" nell'art. 77, co. 3 del D.Lgs. 50/2016, seppur applicato ad appalti inferiori alla soglia introdotta dall'1 gennaio 2018), non solo perderanno di obiettività nella valutazione dei progetti, inevitabilmente condizionati da gare similari precedenti, ma il rischio di paventare simpatie verso alcune soluzioni o aziende diventa esponenzialmente più rilevante.

I criteri discrezionali

Ultimamente si assiste a Gare dal punteggio tecnico stratosferico. Un tempo 70-30 (tecnico-economico) era considerato anche troppo sbilanciato. Ora assistiamo a punteggi 80-20 o addirittura 90-10. Con la riparametrazione di cui abbiamo parlato prima, inoltre, il punteggio viene ancor più sbilanciato. Non è sempre un male, è semplicemente effetto dei fondi preassegnati. Se una Stazione Appaltante ha ottenuto un finanziamento, l'interesse non sarà quello di risparmiare, bensì sarà quello di avere un livello qualitativo alto.

Da qui però appare evidente un problema, se il punteggio tecnico fa giocare integralmente (o quasi) una partita, esso dev'essere quanto più obiettivo possibile. I sottopunteggi discrezionali vanno limitati al massimo o addirittura eliminati.

Esempio:

voce 1: banda di un ponte radio (per tornare all'esempio di prima), 10 punti max.

- 0 punti se offri 1Gbit

- 5 punti se offri 2.5Gbit

- 10 punti se offri oltre 2.5Gbit

Questo è un punteggio obiettivo, un dato tecnico non soggettivo.

voce 2: qualità del software di videosorveglianza, 30 punti max.

Questo è un punteggio discrezionale, soggettivo, insindacabile in cui una Commissione può spostare pesantemente la valutazione ma senza alcun contraddittorio e senza alcun dato oggettivo. A me piace il giallo, tu mi hai proposto un software con lo sfondo giallo, bene: ti do 30 punti. Incontestabili. L'altro software aveva 1000 funzionalità in più, ma a me piace il giallo, stop.

Appare evidente, quindi, che nei punteggi discrezionali si potrebbe annidare una zona grigia.

Cronoprogrammi e tempi di intervento

Troppo spesso i tempi di realizzazione ed i tempi di intervento sono oggetto di punteggi totalmente inutili in quanto dichiarazioni troppo ottimistiche comunque generano l'ottenimento di punteggi. 

L'aggiunta di penali al superamento dei tempi di consegna dichiarati e al superamento dei tempi di SLA non deve essere più discrezionale, ma obbligatoria o comunque fortemente incentivata. Questo accade troppo poco spesso in Gare impiantistiche, a differenza di quelle, ad esempio, edili.

Valutazioni su progetti e impianti

Ogni azienda per partecipare ad una gara, deve aver mostrato di aver effettuato impianti similari e di aver sviluppato un fatturato tale da consentire l'accesso alla gara. La SOA con le sue classifiche, le varie ISO come requisito pena esclusione, il recente rating di legalità ed ogni richiesta della stazione appaltante mira a fare una cernita delle aziende che possono partecipare. 

Perchè, dunque, non lasciare alla Stazione Appaltante la possibilità di valutare, in forma totalmente anonima, dopo 1 anno dal collaudo:

- la qualità del progetto (il progettista è stato in grado di ingegnerizzare un impianto realmente efficace che ha risposto alle esigenze della SA? Quante gare rimangono arenate a causa di problemi progettuali?)

- l'aderenza della soluzione proposta a quella realmente adottata in campo (ho dichiarato 2h di SLA di intervento, sistematicamente ci metto 16h, è una non conformità)

- la percentuale di disservizio e di malfunzionamento degli apparati

ed una serie di altre voci che vanno a comporre un quadro valutativo complessivo. Ogni azienda potrebbe aver accesso al proprio punteggio, pesato per importo a base d'asta, ma non alla Stazione Appaltante che ha rilasciato il punteggio (che rimarrebbe totalmente anonima). L'accesso ad una gara d'appalto, quindi, potrebbe essere discriminato anche in base alla valutazione delle altre SA. Nel giro di pochissimo tempo, le aziende "mordi e fuggi" che hanno dato un servizio di bassa qualità sarebbero correttamente penalizzate. 

Stessa cosa per i progettisti che non sono stati in grado di pensare ad un'opera funzionale. Avremmo in breve tempo ridotto di molto il numero di scenari bloccati e congelati in un terribile arrocco in cui "il progetto è scritto male, quindi non è colpa mia".

Questo sistema valutativo non è forse l'aspetto più importante di cui si dovrebbe preoccupare la SA? Quante volte sentiamo dire "quell'azienda in quel Comune ha fatto solo danni!"?

Procedure d'urgenza

Quello delle procedure d'urgenza è un vero problema. Vanno limitate al massimo, devono essere ampiamente giustificate e un ente terzo, esterno, deve autorizzare le suddette procedure. Va detto tuttavia che in parte questi accorgimenti sono stati attenzionati nel corso degli ultimi anni.

Inutilità del giustificativo del ribasso anomalo

Quella che doveva essere una punta di diamante verso la lotta alle offerte anomale, è diventata una vera e propria barzelletta. Qualcuno è stato mai escluso per ribasso anomalo? Se le Stazioni Appaltanti accettano come giustificazione dell'azienda proponente che "l'acquisizione della Commessa è motivo di pregio e quindi la proponente è disposta ad accettare una perdita economica", tutto questo non ha senso. Accordare un appalto con dichiarazioni di questo tipo è deleterio ai fini della qualità dell'opera.

Accesso agli atti

L'accesso agli atti spesso viene negato in quanto coperto da non meglio specificati "segreti industriali". L'accesso è una garanzia di trasparenza, esso va tutelato quanto più possibile. Se effettivamente vi è un motivo per cui l'accesso agli atti viene negato, questo deve essere debitamente e abbondantemente giustificato.


Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione, anche parziale, è vietata salvo autorizzazione.

Mettere in sicurezza WordPress

Un tempo realizzare un sito web non era così semplice, la figura del webmaster era fortemente specializzata ed aveva padronanza del linguaggio che decideva di utilizzare. Adesso, per fortuna direi, molti strumenti vengono in aiuto. Questo tuttavia spesso (non sempre) si traduce in figure professionali meno attente sul profilo tecnico (per non dire a volte completamente a secco delle più basilari norme di sicurezza). 

Per un periodo Drupal è stato un must, per poi essere sorpassato da Joomla ed infine da WordPress che ormai detiene il predominio dei CMS. Da un punto di vista di sicurezza questo predominio ha comportato, ovviamente, l'accensione dei riflettori mediante tool automatizzati ed in grado di scovare vulnerabilità, plugin pericolosi ed errori di configurazione.

Nel corso di un paio di decenni nella sicurezza e di oltre 10 anni di WP, ho adottato una serie di accorgimenti che condivido volentieri con il lettore di questo blog.

Attaccare per difendere

Al termine della nostra installazione di WordPress, non è una cattiva idea provare proprio quei tool per simulare ciò che un attaccante avrebbe tipicamente fatto per scovare problemi sul nostro sito.

Senza entrare nei meandri dei payload di metasploit, uno dei tool più efficaci è certamente WPScan, incluso nativamente in Kali Linux.

 

(immagine: fonte hackercool)

Essendo un software fortemente specializzato, ci restituirà delle indicazioni puntuali su cosa mettere in sicurezza. Salvo, ovviamente, non abbiate commesso i più elementari errori come nell'esempio:

(immagine: fonte hackercool)

Mettere in sicurezza il sistema Linux

Nelle installazioni professionali di alto profilo, WordPress viene ospitato da un server Linux dedicato, a differenza di quanto accade con i provider che vendono uno "spazio wordpress" dove centinaia di installazioni convivono sullo stesso server. Se ci troviamo nella situazione di poter mettere agevolmente mano sulla macchina Linux che ospita il nostro WP, possiamo adottare certamente delle contromisure efficaci.

Giocare con le ACL

Nei casi più estremi è possibile abilitare gli attributi speciali ACL, così nessuno potrà scrivere file, salvo questi non vengano sbloccati esplicitamente. Questo comporta, ovviamente, che ogni modifica richieda l'avvio di uno script di sblocco direttamente in SSH sul sistema Linux.

Verificare gli MD5

Creare uno script che ogni X minuti verifichi gli MD5 dei file e ne segnali eventuali variazioni, restituisce immediatamente evidenza di problemi di sicurezza e file caricati abusivamente. L'attaccante, inoltre, nella maggior parte dei casi è del tutto all'oscuro di uno script simile ed anche in caso di escalation di permessi, il tempo necessario a rilevare lo script diventa certamente superiore rispetto all'allarme che lo script può aver inviato.

Bannare IP leggendo i log di apache

Uno script che richiami iptables leggendo i log si apache ci consente di reagire immediatamente a qualsiasi bruteforce.

 

Chroot Jail

Avviare apache in chroot jail è cosa buona e giusta, a maggior ragione se abbiamo deciso di implementare script sul sistema. Questa pratica normalmente garantisce l'integrità degli script che abbiamo deciso di far girare al livello superiore e fuori dalla jail.

 

(immagine: fonte linuxclass)

Altre tecniche

Bhè... qualcosa devo pur tenermela per me, altrimenti rischio di restituire un vantaggio eccessivo a chi invece utilizza queste informazioni non a fin di bene.

 

 

Farsi aiutare da un firewall di livello 7

Per sua natura, un firewall hardware di livello 7 è in grado di ispezionare il traffico e identificare attacchi di natura protocollare o pattern di attacchi noti. Abilitare questo tipo di controllo aiuta molto ad incrementare la sicurezza per portarla ad un livello più alto.

 

Firewall di questo tipo normalmente sono in grado di bloccare a prescindere anche determinate categorie di IP, per cui è buona norma (sempre se si può anteporre un firewall hardware) bloccare tutto ciò che non sia strettamente necessario, come ad esempio le reti anonime TOR o gli IP provenienti da nazioni la cui visualizzazione non produce alcun interesse.

Altri tool e plugin specifici

WP possiede una serie di plugin di sicurezza, come ad esempio il famoso Wordfence in grado di avvertirci per una serie di casistiche (file modificati, bruteforce, aggiornamenti necessari, etc.) anche nella sua versione gratuita.

Personalmente, tuttavia, ritengo che un plugin per quanto efficace possa essere, sia sempre un componente facente parte di un sistema di per se vulnerabile. Se il sistema viene corrotto, il plugin potrà essere manomesso, e questo lascia il tempo che trova. La prima regola della sicurezza è proprio l'indipendenza del sistema a garanzia della stessa. Se WP è compromesso, manomettere un suo plugin sarà quanto di più facile e prioritario possibile.

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

GDPR... quanta confusione!

Sul GDPR se ne sentono ultimamente di cotte e di crude, ognuno tira l'acqua al suo mulino, ma la verità dove sta? Come al solito, "in medio stat virtus" dicevano gli antichi filosofi, nonostante non fossero particolarmente attenti alla privacy.

In questo articolo non parleremo di cosa fare per adeguarsi o delle ottemperanze procedurali, per quello internet è pieno di guide. Focalizzeremo l'attenzione sul troppo e sul troppo poco.

La parolina magica: adeguatezza

 

Il GDPR prevede un audit tecnico ed uno normativo/procedurale. Soprattutto sulla parte tecnica, la normativa apre ad una certa interpretazione lasciando sufficiente libertà di scelta nell'identificazione di quelle che sono le "adeguate misure di sicurezza". Il ruolo di un professionista che tecnicamente effettua queste valutazioni, ovvero di una figura in realtà più abituata a confrontarsi con gli attacchi informatici di quanto non sia abituato a leggere norme, è fondamentale. Ma "adeguate misure" aprono purtroppo un mondo di interpretazioni:

• "Adeguato" significa che la Signora Maria della salumeria sotto casa deve dotarsi del sistema di sicurezza del Pentagono perchè gestisce le anagrafiche dei fornitori? 
• "Adeguato" significa che uno studio medico che tratta dati sanitari, essendo piccolino, può permettersi di non avere alcuna cura delle informazioni sensibili?
• "Adeguato" significa che un commercialista che ha il gestionale in cloud può disinteressarsi dell'ottemperanza tecnica?

Andiamo con ordine. 

Il troppo

 

Sto assistendo continuamente a "mosche sparate con un cannone". Sfatiamo qualche mito:

• Non è sempre obbligatorio avere il DPO esterno, anzi, i casi sono ben definiti e salvo specifiche classificazioni, il DPO può anche non essere necessario. Tuttavia, anche qui, è pieno di professionisti che propongono il DPO anche alla Signora Maria che gestisce la nota salumeria del precedente esempio.

• Non è obbligatorio un Penetration Test, un Vulnerability Assessment o un'ispezione così approfondita sulle vulnerabilità dell'infrastruttura informatica. Sto assistendo ad aziende che stanno spingendo in maniera forsennata i PenTest. NO. Un PenTest fatto davvero bene (e non intendo "avanti > avanti > fine" con Nessus, e anche qui si apre un mondo) è costoso. E più è fatto bene e più è costoso. E' una decisione che deve essere basata sul buonsenso. SI se espongo dati sensibili, se l'architettura di rete necessita di un approfondimento così importante. Ma se ho il mio webserver in DMZ (o magari persino su un hoster esterno) e questo ospita un banale sito vetrina senza alcun meccanismo di autenticazione o raccolta dati... NO. Per carità, NO, è un'operazione estremamente costosa. Fatelo, se volete, ma non per un fantomatico obbligo normativo. E soprattutto, i PenTest vanno fatti da chi fa questo di mestiere... Per operare a cuore aperto serve il cardiochirurgo, non l'infermiere che ha seguito un video su youtube!

Il troppo poco

 

Viceversa, avendo approfondito l'argomento in maniera dettagliata, mi fa sorridere il software che con 200 euro fa tutto. Non esiste, e se esiste e lo fadavvero, vi prego di avvertirmi. Sarebbe interessante capire come può un semplice software fare un audit tecnico, procedurale e normativo all'interno di un'azienda. Come può un software sostituirsi ad un DPIA (quando necessario) o analizzare l'infrastruttura informatica, i piani di backup e disaster recovery, effettuare dei vulnerability assessment laddove risulti opportuno e vi siano server esposti con dati sensibili. Come può un software "faccio tutto io" a fare formazione specifica sulle esigenze e sui processi dell'azienda? Avete mai visto un software da 200 euro per ottenere l'ISO9000? No? Forse c'è un motivo.

Sarà ancora più interessante vedere, in seguito ad una denuncia su un incidente di sicurezza, l'ottemperamento alle "adeguate misure di sicurezza" di cui parlano gli articoli dal 32 al 35. Tanto poi, alla fine, le responsabilità non sono certo di chi vende il software magico.

Il GDPR non è il nuovo DPSS su cui bastava fare copia-incolla cambiando l'anno.

Fidarsi è bene, non fidarsi è meglio

 

Ogni caso è particolare, ma è evidente che la normativa abbia generato una corsa al business dove ognuno ha una sua soluzione magica. Il consiglio è di non fidarsi nè di chi propone l'adeguamento a pochi euro, nè di chi vuole fare un audit da 20.000 euro in un'azienda da 3 dipendenti, nè di me che per onestà intellettuale verso il lettore di questo articolo non faccio segreto di lavorare nel settore. Il consiglio è banale: leggetevi la normativa http://eur-lex.europa.eu/legal-content/IT/TXT/PDF/?uri=CELEX:32016R0679&from=IT . Potreste scoprire che nel vostro caso serva maggiore o minore accuratezza di quanto vi sia stato proposto.


Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

Il vero motore del Bitcoin

Il Bitcoin sta subendo un'impennata importante, non passa giorno che i telegiornali non ne parlino. Ma perchè improvvisamente è incrementata la richiesta?

Chi conosce questo blog, sa che mi occupo di bitcoin da quanto quotava appena 70 euro (qui parlavo del mining nel 2016, e qui spiegavo cosa fosse il mining nel 2013), le cose sono cambiate perchè la finanza speculativa è entrata prepotentemente all'interno dei meccanismi della valuta virtuale.

Faccio una premessa, sono molto critico su tutte le altre valute virtuali, perchè la domanda è quasi nulla e sono praticamente inspendibili. Solo il Bitcoin ha guadagnato il privilegio di poter essere speso in alcuni posti in alternativa ad una valuta tradizionale, e questo non è affatto poco. Oltretutto solo il Bitcoin è utilizzato da chi richiede soldi illegalmente, ma andiamo con ordine.

Vi siete mai chiesti qual è il vero motore di questa impennata?

(qui il grafico aggiornato in tempo reale)

Come in ogni mercato, la domanda fa incrementare il prezzo. Il Bitcoin non è diverso e non segue regole differenti da quelle del classico trading (di cui ho una modesta esperienza, da semplice curioso/matematico/logico che ha operato su alcuni mercati azionari). E qui la sicurezza informatica caratterizza pesantemente il mercato del Bitcoin.

Da gennaio 2016 la domanda sale, il bitcoin ha un inizio di rialzo che si mantiene costante. Chi sta comprando bitcoin?

Secondo  F-Secure il 2016 è l'anno in cui il fenomeno dei virus ransomware, ovvero quei software che crittografano i dati e li rendono inaccessibili salvo pagare un riscatto, esplode. Le vittime che rivogliono indietro i propri dati, devono pagare in Bitcoin (non tracciabili). E' più semplice di un bonifico in costa d'avorio oppure di una transazione western union. La vittima quindi cerca di convertire i propri Euro o Dollari in Bitcoin. La domanda sale, il prezzo del Bitcoin incrementa.

Il 2017 è stato l'anno in cui il ransomware si è consolidato, le previsioni sono di circa il 130% rispetto al 2016. Vari ransomware famosi hanno creato scompiglio, i vari TeslaCrypt et simila hanno dato una spinta, così arriviamo a Luglio 2017 con un incremento da 900$ a 2600$ in poche settimane.

A questo punto sono entrati gli speculatori professionisti, non i piccoli trader, ma chi fa questo di mestiere e muove volumi significativi. Lo si vede dal picco di fine luglio, il Bitcoin prende quasi il 100%. Scattano i take-profit, gli speculatori a breve termine vendono, il Bitcoin scende. Qualcuno ha duplicato il proprio capitale, questo nel trading tradizionale non esiste nè in cielo nè in terra. La notizia fa scalpore ed entrano i big, che acquistano nuovamente grandi quantitativi.

Scatta la corsa all'oro, si passa da 4300$ agli attuali 16000$. I telegiornali ne parlano, i piccoli investitori entrano. I grandi probabilmente attendono il minimo segnale per vendere. Ora tutto fa credere ad una bolla, chi si farà male sono i piccoli che non hanno messo degli stop-loss adeguati. Quando i big lasceranno la scena, con il 300% di margine, il Bitcoin crollerà, e lo farà violentemente perchè innescherà una serie di stop-loss uno dietro l'altro, creando un momentum negativo. La discesa sarà violenta.

Conviene investire ora? Io sono un informatico con la passione per il trading. Nessuno sa quanto ancora potrà camminare il Bitcoin. A grandi possibilità di margine corrisponde un grande, grandissimo rischio di perdere una somma di capitale molto alta. Se qualcuno ha una sfera magica in grado di capire il prossimo momento, se rialzista o ribassista, mi avverta. Ad ogni modo, perdonatemi la deviazione finanziaria, ma non sono andato del tutto OffTopic, la sicurezza informatica mai come in questo caso ha permeato la finanza mondiale condizionando il mercato.

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

Privacy e GDPR: nuovi adempimenti normativi (generici)

A fine maggio 2018 entrerà in vigore il GDPR, ovvero il Regolamento sulla Protezione dei Dati, approvato direttamente dal Parlamento Europeo. Sebbene in alcuni casi sia meno stringente della nostra normativa sulla privacy, vi sono sostanziali modifiche. Proviamo a schematizzare le variazioni che toccano direttamente le aziende e come queste devono gestire le informazioni.

• Cambiano i concetti e gli assiomi di partenza. Non si parla più di privacy, ma di protezione dei dati come componente primaria della privacy dei dati stessi. E non vi è più il concetto di "misura minima" ma subentra quello di "misura adeguata" nella protezione delle infrastrutture IT.

• Tutte le aziende che trattano dati sensibili di cittadini Europei devono adeguarsi, anche se non hanno sede all'interno della UE.

• Le aziende devono redirigere un registro delle attività di trattamento in cui sia ben esplicitato la finalità del trattamento stesso, il ciclo di gestione e le misure di sicurezza adottate per proteggere i dati (qualcosa di simile al vecchio DPSS).

• Solo i dati sensibili veramente indispensabili devono essere processati, e limitatamente a chi li deve elaborare. Questo sostanzialmente comporta nella maggior parte dei casi una riprogettazione dei sistemi che trattano i dati e di come questi debbano essere gestiti nel quotidiano.

• In caso di fuga di informazioni, l'azienda è obbligata a comunicarlo agli interessati entro e non oltre 72 ore dall'identificazione dell'accaduto.

• Le aziende avranno una nuova figura (l'equivalente del nostro "Responsabile della Privacy"), ovvero il DPO (Data Protector Officier), un esperto in materia giuridica, indipendente, che vigilerà anche sui processi aziendali. Il ruolo è obbligatorio in determinate casistiche (PA, società con più di 250 dipendenti o aziende che del trattamento dei dati fanno il loro core business).

• Similarmente a quanto accade ora, le aziende dovranno garantire la possibilità di cancellare i dati personali degli utenti in ogni momento. Cambia, tuttavia, la sanzione che può arrivare al 4% del fatturato annuo globale o ad un massimo di 20 milioni di euro.

• I sistemi informatici devono essere oggetto di un'analisi di rischio preventiva.

• I sistemi IT devono essere protetti da professionisti e consulenti. Seppur sia noto a tutti che una "medicina universale" non esista e che l'attacco informatico sia sempre in agguato, è necessario che le aziende dimostrino di aver investito nell'IT Security ed abbiano gestito la problematica con adeguata attenzione. La normativa italiana prevedeva l'adozione di misure di sicurezza perimetrale (un firewall, ad esempio) e di sicurezza dei client (un antivirus), è evidente tuttavia che questo adempimento risulta oramai perlopiù insufficiente. 

• Proprio il concetto di "misura adeguata" espone il titolare del trattamento a dimostrare, in caso di fuga di informazioni, perchè le misure adottate siano state reputate sufficienti. 

• Il titolare del trattamento dovrà occuparsi di formare tutti i collaboratori aziendali circa le tematiche in oggetto. Proviamo a dare una sfaccettatura più informatica: è opportuno che le risorse aziendali sappiano riconoscere un attacco di tipo Social Engineering in cui, ad esempio, un attaccante cerca di reperire informazioni via telefono.

• I locali ove risiedono i dati, anche elettronici, andranno adeguatamente protetti.

• Le tecnologie di backup e disaster recovery assumono un ruolo estremamente importante, soprattutto in ottica anti-estorsiva. La normativa attuale prevede già degli adeguamenti (ad esempio che i backup siano locati in plessi differenti), tuttavia il GDPR estende questi adeguamenti ad un'analisi più completa di tutto il processo di disaster recovery.

• I dati devono essere cifrati e la profilazione non deve essere riconducibile al singolo.

• Gli accessi illeciti ai dati devono essere obbligatoriamente notificati agli organi di competenza.

In un prossimo articolo andremo nel dettaglio degli adempimenti tecnologici riguardanti i responsabili IT e dell'infrastruttura informatica, entrando nel merito di come si stanno muovendo i vari vendor.


Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

Alterazione del campo IBAN nelle fatture: nuove superfici di attacco alle aziende

A volte un'operazione normale come inviare una fattura via email può trasformarsi in un problema.

Immaginate di inviare una fattura in PDF ed immaginate che il vostro interlocutore riceva la stessa identica fattura, sempre in formato PDF, ma con il campo IBAN cambiato o popolato da un codice bancario non vostro.

Questo è quanto accaduto di recente in un caso che ho avuto modo di seguire.


Fattura originaria (in questo caso senza IBAN):

Fattura alterata, pervenuta all'interlocutore:

Una telefonata del destinatario, insospettito da un IBAN insolito (seppur italiano!), ha messo in luce la problematica prima che potesse essere dannosa.

E' bene precisare che il destinatario utilizza un dominio generico erogato da un noto ISP italiano ed oggetto di innumerevoli recenti attacchi e problemi di sicurezza. Utilizzare email con domini aziendali non è mai un errore, oltre ad essere sinonimo di professionalità.

Va aggiunto che il proprietario dell'IBAN italiano su cui avviene materialmente la truffa spesso è coinvolto con la formula "ci giri il denaro che ti arriva e ti trattieni una percentuale", nella classica formula "vuoi guadagnare soldi online?" che spesso si legge su qualche banner. Ciò non toglie che il reato sia e rimanga quello di riciclaggio, che lo si faccia con o meno cognizione di causa, non si scherza.

Si consiglia la massima attenzione, spesso una telefonata può salvare migliaia di euro.


Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

Qualche accorgimento per passare delle buone ferie da responsabile EDP!

Il responsabile EDP, si sa, è sempre più o meno in servizio e ad Agosto spesso le ferie si trasformano in un vero e proprio "incubo da reperibilità".

Nel corso degli anni ho maturato una certa sfiga il 13 di Agosto. Giorno in cui immancabilmente sono dovuto scappare, ogni anno, per un problema sempre diverso. Sfighe a parte, a cui difficilmente sarà possibile porvi rimedio (e di sicuro un blog non vi sarà d'aiuto), una pianificazione e qualche consiglio potrà aiutare il responsabile informatico a minimizzare i propri interventi ed il proprio stress da "telefonata molesta". E no, la risposta non è "spegnete il telefono", non siate biricchini!

Ecco qualche personalissimo consiglio da mettere in pratica qualche giorno prima di andare in ferie:

1. Assicuratevi che tutti gli utenti abbiano ben chiare le proprie necessità, quando sono in ferie le esigenze cambiano! Quindi assicuratevi che gli utenti che necessitano di un autorisponditore ve lo dicano con anticipo (possibilmente non il 14 Agosto);

2. Come sopra: assicuratevi che gli utenti che necessitano di una VPN o di un Desktop Remoto vi diano il tempo di configurare il tutto e fare le verifiche dal proprio dispositivo (immagino non vogliate chiamate alle 21,00 perchè "non funziona la VPN dal MAC di mia figlia");

3. Spegnere i server non necessari! Meno superficie d'attacco lascio esposta, meglio è. Se ho un server di update ed il reparto RD è in ferie, non serve lasciare la macchina accesa;

4. Controllare la refrigerazione. E' impressionante la mole di problematiche legate alla refrigerazione che accadono ad Agosto! Con effetti anche spesso tutt'altro che banali (dischi che si guastano, server che vanno in protezione e si spengono, etc.). Se possibile dotatevi di un "piano B", al malfunzionamento di una macchina di condizionamento, fate intervenire degli aspiratori d'aria, spesso salva da guasti ben più gravi;

5. I backup vanno controllati sempre, ma prima di andare in ferie non è una cattiva idea investire del tempo per provare un piano di disaster recovery e verificare che realmente i backup siano utilizzabili e ripristinabili;

6. Inasprite le regole del firewall, anche se ad Agosto gli attacchi diminuiscono (dietro gli attacchi ci sono delle persone che, come voi, vanno in ferie), dare una controllata a tutte le regole (soprattutto quelle temporanee e diagnostiche, attivate per un fine specifico ma obsoleto) e spegnete quelle non più necessarie. A Settembre vi sarete dimenticati del perchè quella regola è stata attivata!

7.  Verificate che il vostro accesso all'infrastruttura sia perfettamente funzionante ed in sicurezza. Poter entrare rapidamente sulle proprie macchine spesso fa la differenza tra rientrare in azienda o risolvere tutto in pochi minuti da remoto;

8. Se disponete di sistemi di monitoraggio automatico, controllateli e verificate che facciano correttamente il loro lavoro (inviare email di alert, segnalare guasti, etc.);

9. Controllate le scadenze di tutto ciò che può scadere nel bel mezzo delle vostre ferie. Certificati SSL (HTTPS, IMAP, etc.), scadenza password, rinnovi di domini, etc.; 

E poi non resta che incrociare le dita e godersi delle meritate vacanze estive!

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

Keylogger e sistemi di protezione... quando tutto funziona bene

Raramente su questo blog parlo di prodotti e, quando e se lo faccio, cerco di essere estremamente obiettivo. Questo perchè è mia espressa volontà mantenere questo blog slegato dall'attività lavorativa di consulenza di cui mi occupo. Questo caso specifico, tuttavia, merita menzione.

Di recente le maggiori testate del settore (e non) hanno portato alla luce uno spiacevole scivolone di HP (http://www.zeusnews.it/n.php?c=25288, http://securityaffairs.co/wordpress/59013/hacking/hp-keylogger-conexant-audio-driver.html) per cui il software conexant della scheda audio fungeva da keylogger catturando ogni input della tastiera e scrivendo tutto "allegramente" in un file di log. 

(Fonte ZeusNews)

Tralasciando l'incredibile leggerezza degli sviluppatori, la cui accezione sto generosamente attribuendo, esistono sistemi che in automatico intervengono per evitare questo problema potenzialmente catastrofico (immaginate bene cosa significhi per un amministratore di rete vedersi sottratte tutte le password di accesso ai suoi sistemi). Uno di questi sistemi è Stormshield SES a cui io attribuisco personalmente la categoria di "analizzatore comportamentale". SES è un software molto leggero in grado di analizzare svariati aspetti del sistema ed intervenire su comportamenti specifici. Non è un antivirus, ma va considerato come supplemento alla protezione standard del client. 

Appresa la notizia abbiamo aperto un incidente di sicurezza interno ed avviato un'indagine sui clienti dotati di questa tecnologia e che possiedono portatili HP.

Quanto è emerso è evidente, il sistema ha bloccato l'eseguibile fin dal principio e prima ancora che questo fosse stato oggetto di approfondimento da parte dei ricercatori che ne hanno scoperto la problematica.

Tutto è bene quel che finisce bene. ...e gli altri?

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

Case Study: Quando il WISP ti fa saltare la Spanning Tree Topology

Lo Spanning Tree Protocol, con le sue varianti (RapidSTP), consente di raggiungere tipicamente due obiettivi:

• La ridondanza dei collegamenti tra più switch (ma non solo)
• La risoluzione di fenomeni di Broadcast Storm (comunemente chiamati loop)

Come funziona

Il funzionamento del protocollo RSTP è bene approfondirlo un attimo, seppur brevemente e semplificando alcuni concetti, così da entrare nel vivo del Case Study.

Immaginiamo di avere questa banale topologia di rete, ovvero uno switch di centro stella e due switch (A e B) secondari chiusi ad anello tra di loro.

E' subito evidente che, per prima cosa, in assenza del protocollo RSTP abilitato, la rete collasserebbe in un loop tale da renderla del tutto inutilizzabile. Il protocollo RSTP per sua natura impone il forward dei frame sulla porta solo dopo essersi accertato che non si tratta di un percorso ridondante. Quindi nella nostra architettura, della bretella A-B lo switch B blocca la porta mettendola in uno stato di non inoltro del traffico tradizionale (ma di inoltro delle BPDU, ovvero del traffico generato dall'RSTP degli switch stessi e necessario a trasferirsi informazioni circa la topologia di rete).

Altrettanto evidente è che l'interruzione di un qualsiasi percorso tra A e Root oppure tra B e Root, causerà (dopo un tempo minimo di convergenza) un cambio di topologia che vedrà protagonista la riattivazione completa della porta originariamente bloccata da B.

Ora immaginiamo uno scenario più articolato, ma che sostanzialmente è assimilabile a quello precedente:

Poniamo quindi il caso che le tratte nere siano in Fibra Ottica e le tratte rosse siano in Rame. Per sua natura, la Fibra Ottica ha una priorità superiore a quella in Rame, pertanto ogni switch intento a capire quale porta ridondante spegnere, tenderà a privilegiare la Fibra Ottica.

Tutto questo identifica, in maniera sommaria, una topologia di rete. Ad onor del vero ci sarebbe da parlare per ore su come gli switch eleggono una topologia e su come stabiliscono (in assenza di indicazioni specifiche) chi è il Root Switch e la gerarchia che ne deriva.

A noi, per non annoiarci in dettagli tecnici degni del miglior studente CCNA, interessa solo un principio: lo Spanning Tree abilitato per prevenire i loop, può essere lasciato di default. Ma lo Spanning Tree con percorsi ridondanti va configurato correttamente per non ritrovarsi con percorsi erroneamente lunghi oppure con lo switch dello scantinato come Root Switch a capo di tutta la topologia.

Questa configurazione si fa forzando l'autorevolezza di un apparato che deve imporsi su tutti gli altri.

Case Study

Poniamo il caso di avere un WISP che ci eroga connettività tramite un bridge radio (Layer 2, occhio, non Layer 3 come un router di un operatore tradizionale). Il bridge, ovviamente, fa passare le BPDU che lavorano a Livello 2 della pila ISO/OSI. Se siete particolarmente sfortunati ed il WISP ha impostato il Priority a 0 su uno dei suoi switch nella sua infrastruttura, esso si imporrà su tutto il nostro sistema in LAN forzando un cambio di topologia di rete che farà saltare ogni percorso minuziosamente studiato su carta.

L'aspetto più insidioso è che questo tipo di fenomeno spesso è apparentemente invisibile e si traduce in rallentamenti e micro-disconnessioni che, ad una prima e superficiale osservazione, possono essere sottovalutati o attribuiti "al solito server lento".

Soluzione

I log sono nostri amici: una volta identificato il problema disabilitare lo Spanning Tree sulle porte direttamente connesse ai gateway. E siccome non costa nulla, diciamo che è buona norma farlo sempre. 

Del resto, è del tutto sconsigliato creare una rete con percorsi ridondati senza controllare nei giorni successivi lo stato delle porte RSTP per capire se realmente il traffico sta facendo il percorso da noi voluto.

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

Desktop Virtualization (VDI): una breve panoramica nel mondo Horizon Vmware

Architetture VDI: cosa sono

Quando parliamo di architetture VDI (Virtual Desktop Infrastructure) parliamo di un'infrastruttura in grado di ospitare i desktop remoti degli utenti su server centralizzati spostando, di fatto, capacità elaborativa e di storage da un normale PC (con i limiti che questo possiede, da un punto di vista di ridondanza hardware, ad esempio) ad un pool di server adeguatamente vestiti per questo scopo.

Fondamentalmente, i PC diventano "stupidi" a tal punto da poter essere dei Thin Client, ovvero delle macchine con bassissima capacità (e dal bassissimo consumo energetico), appena sufficiente ad effettuare solo un banale collegamento con il server. In un'accezione più ampia, la propria postazione diviene accessibile da qualsiasi piattaforma, anche mobile, svincolando l'utente che ne trae (soprattutto se errante come un'agente di commercio) tipicamente molti benefici.

In ambito VDI dobbiamo però dividere delle architetture che caratterizzeranno completamente la nostra infrastruttura.

Architettura Full Clone Desktop Pool

L'architettura Full Clone è quella più vicina a chi ha dimestichezza con gli ambienti virtuali, ogni utente "atterra" su una sua macchina virtuale completamente dedicata. Questo comporta, come per ogni cosa, pregi e difetti. Ciò che acquistiamo come autonomia lo perdiamo come richieste hardware e costose licenze che vanno rinnovate ogni anno sui sistemi operativi desktop.

Architettura Linked Clone Desktop Pool

L'architettura Linked Clone necessita di una macchina chiamata Composer che si occupa di creare delle macchine figlie correlate che sono, in sostanza, dei differenziali tra la "Parent virtual machine" (o "Desktop Image") e le "Linked Clone Machine".

Avremo, quindi, un ambiente che racchiude i vantaggi principali della prima soluzione con quella che è la modalità più light della VDI e che vediamo di seguito.

Architettura Remote Desktop Session Host

L'architettura Remote Desktop Session Host è assimilabile (e si basa) al protocollo RDP/Microsoft Terminal Services. Per implementare questa modalità necessiteremo di un pool di server MS-TS in quanto le sessioni si sviluppano mediante questo meccanismo.

Anche qui, vantaggi e svantaggi si rincorrono. Da un punto di vista avremo un sistema poco esoso di risorse, dall'altro avremo altri costi di licenze (TS). Abbiamo, tuttavia, un grande vantaggio che apporta solo questa architettura, ovvero la possibilità di incapsulare delle applicazioni all'interno dell'ambiente VDI, in maniera completamente trasparente. 

Facciamo un esempio che personalmente adotto in ambienti dove la sicurezza è critica:

Ogni utente può avere il suo ambiente locale, ma la navigazione internet è demandata all'interno di una VDI. Sul desktop del client possiamo apprezzare una trasparenza impagabile, ovvero avere direttamente la chiamata verso (in questo caso) chrome in VDI senza fare alcun complesso accesso ad un altro ambiente virtuale in RDP.

Approfondiremo le tre modalità negli articoli successivi.



Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.

Architetture di collegamento: Fibre Channel su multi controller e RoundRobin

Quando ci si trova ad implementare uno storage collegato ad un'infrastruttura, soprattutto se virtuale, le performance divengono fondamentali. Spesso ci si domanda quale architettura seguire, quali sono le Best Practices e quale scenario è in grado, ad esempio, di sfruttare al massimo le performance di un array full SSD.

In passato abbiamo trattato alcuni temi, la cui lettura facilita la comprensione di questo articolo di approfondimento:

• Cosa succede quando si risparmia troppo sullo storage in un ambiente virtuale?
• Creare una SAN iSCSI con dischi in RAID su una LUN LVM Linux per VMWare

Immaginiamo di avere due scenari di questo tipo

Uno in iSCSI con 2 porte a 10Gbit con supporto TOE (per host) ed uno in Fibre Channel con 2 porte 8Gb (per host), in entrambi i casi in Direch Attach sulla SAN.

Qual è il metodo più conveniente per interconnettere gli apparati?

iSCSI con singolo controller

Dai test che abbiamo effettuato, quando è presente un solo controller, il metodo migliore per collegare gli host è in RoundRobin utilizzando la relativa funzione presente nel path manager di vmware.

In media è stato raggiunto un risultato di circa il 13% più performante rispetto al path singolo con il secondario in standby.

FC con singolo controller

Similarmente a quanto accade in ambito iSCSI, il collegamento in FC beneficia del meccanismo di distribuzione tipico del RoundRobin, ma in maniera persino superiore (22% rispetto al singolo path). Questo perchè l'overhead generato dal protocollo TCP in ambiente iSCSI probabilmente vanifica in parte il vantaggio di avere due percorsi bilanciati.

iSCSI e FC con doppio controller

Qui abbiamo una sorpresa. Qualora la SAN possieda due controller, utilizzare il RoundRobin comporta un rallentamento con entrambe le tecnologie rispetto ad un path singolo. Presupponendo di aver effettuato una pianificazione corretta, ovvero HBA1 su Controller1 e HBA2 su Controller2, il bilanciamento del carico impegna entrambi i controller che, nella realtà, perderanno tempo a ricostruire il flusso di informazioni che vengono loro richieste.

Abbiamo, sostanzialmente, creato un collo di bottiglia causato dal coinvolgimento dei due controller in un impegnativo stream ciclico (Ctrl1-Ctrl2-Ctrl1-Ctrl2...). Il RoundRobin non è, in questo scenario, conveniente.

Best Practices per incrementare le performance con SAN avente due o più controller

Abbiamo stabilito, quindi, che il meccanismo di bilanciamento RoundRobin è utile in caso di singolo controller perchè massimizza la parte network, ma è sfavorevole per gli scenari in cui la SAN abbia più controller perchè costringe questi ultimi ad un lavoro supplementare di interfacciamento tra di essi. Lavoro, questo, in grado di vanificare il vantaggio della doppia disponibilità di banda. 

Come fare, quindi? E' sufficientemente banale, creare più LUN e distribuirle lungo i path.

Come sappiamo, i path vengono gestiti per ogni LUN, quindi la creazione di N LUN scatenerà Nx2 path per host (nel nostro caso). A questo punto all'interno della SAN potremo definire il controller owner, ovvero il controller che prende in primis in carico la LUN e la presenta agli altri controller. Strutturando correttamente questa fase, sarà possibile avere un path primario per LUN, che coinciderà con il controller owner, e bilanciarne quindi i path in maniera manuale.

Proviamo a fare un esempio immaginando di aver creato 2 LUN:

La prima LUN è presentata dal controller 1, quindi noi utilizzeremo il path 1 con il 2 silente, pronto ad intervenire in caso di backup.

La seconda LUN, pariteticamente, viene gestita dal controller 2 utilizzando il path 2 (sullo stesso host, ovviamente).

Così facendo avremo naturalmente bilanciato i carichi utilizzando due path diversi su due LUN diverse. L'impegno dei controller sarà minimo perchè ognuno gestirà la sua owned LUN senza necessitare di impegnativi flussi di comunicazione come nel caso in cui venga utilizzato un RoundRobin su due controller differenti.

Lo scenario RoundRobin sullo stesso controller, ovviamente e per ovvie ragioni di inaffidabilità, non è stato contemplato perchè insicuro.

Discaimer: Ogni articolo di questo blog è stato integralmente scritto dall'autore. Il contenuto è completamente originale e la riproduzione è vietata salvo autorizzazione.