Estate 2022 – Day #1! – Fuggire, si, ma dove?

Day 1! Finalmente partiti! Come sempre Roma ha tentato di trattenerci inventandosi qualsiasi tipo di problema, ma abbiamo tenuto duro e per le 11 eravamo sulla strada.

Quella di oggi era una delle tappe più lunghe di tutto il viaggio: la prima e l’ultima infatti sono le tappe con cui cerchiamo di scavalcare tutta l’Italia in un sol boccone. La conseguenza è che la giornata è andata via quasi tutta in macchina per fare una lunga prima trasferta da Roma a Schio. Siamo arrivati verso le 17.30 ed abbiamo fatto un rapido giro in città, ma abbiamo deciso che per questa sera ci riposiamo di modo da poterci muovere presto domani mattina per una prima gita prima della prossima tappa verso Innsbruck.

La piccola Opel Corsa si è comportata egregiamente e nonostante il clima fuori dalla macchina fosse veramente insostenibile (abbiamo raggiunto picchi di 42 gradi in zona Bologna) il viaggio è stato più che sopportabile. Devo dire che non vedo l’ora di scavalcare le Alpi ed arrivare a climi più miti. La notizia positiva è che il consumo medio è stato di 15,8 KM per Litro nonostante l’Appennino!

Qualche dato tecnico sulla tappa:

  • KM Percorsi: 560,2
  • Litri di benzina: 35,41
  • Consumo: 15,8 KM/L
  • Dischi del giorno (tappa lunga, due dischi):
    • Judas Priest – Firepower
    • Pink Floyd – The Dark Side of the Moon

Segui il viaggio in tempo reale: https://www.polarsteps.com/skeyby

3, 2, 1… go!

Da oramai parecchi anni, il periodo estivo è l’occasione per fare un’abbuffata di città estere. Complice la frequente necessità di andare in vacanza nelle settimane a cavallo della settimana di Ferragosto – che rende quasi impossibile l’ipotesi di andare in vacanza in un singolo posto senza spendere cifre esorbitanti – il mese di Agosto diventa l’occasione per un bel tour in macchina di varie città europee.

Oramai la formula è abbastanza rodata, la media di chilometri da percorrere ogni giorno è di circa 300/350: andando oltre questa soglia la parte di viaggio diventa troppo faticosa da gestire.

In molti chiedono come mai questa scelta, piuttosto che l’idea di prendere un aereo per andare direttamente in un posto. Ci sono vari fattori, il primo è quello che il viaggio stesso diventa parte della vacanza: vedere il paesaggio che cambia progressivamente durante il viaggio è una delle cose più affascinanti di tutto. Vedere lo scenario che cambia, la vegetazione che cambia, le case vicino all’autostrada che cambiano forme e colori… ogni paese ha le sue abitudini, i suoi colori, le sue forme, e così la cosa diventa palese. Il secondo è che muovendosi in macchina è anche possibile visitare mete che sono leggermente fuori dal centro delle città e che normalmente non si potrebbero visitare spostandosi in aereo. Il terzo è che l’idea di stare per un periodo lungo in una singola città straniera mi sembra in qualche modo limitante, nel senso che una volta esaurite le cinque, sei attività turistiche focali della città, rischia di diventare tutto un po’ statico.

Al contrario, quindi, oramai da anni abbiamo strutturato le vacanze come un giro in cui assaggiare un po’ di tutto, salvo poi negli anni successivi tornare nei posti preferiti per approfondire un po’ di più aspetti che solletichino interessi vari.

Negli anni passati, in fine, ha avuto un peso enorme nella scelta di questo tipo di itinerario la possibilità di poter contare sulla Prius che, grazie al motore Ibrido riesce a contenere i costi di viaggio pur essendo molto comoda.

Dario ci illustra le comodità della Toyota Prius…

A dicembre del 2021, però, la Prius, a causa di una serie di fattori non direttamente legati a lei, ha deciso di abbandonarci progressivamente, prima dando problemi alla batteria di servizio e poi accendendo una laconica spia di allarme generico. La vita è frenetica e purtroppo per mancanza di tempo ho lasciato correre le riparazioni alla Prius ad un momento successivo scegliendo di appoggiarmi alla macchina aziendale, una Renault Megane Station Wagon. Sicuramente una vettura che può competere in quanto a comodità di viaggio e che, comunque, ha 10 anni di meno della Prius e come tale offre tutta una serie di confort tecnologici aggiuntivi.

La Renault Megane si fa bella prima di partire…

Avvicinandosi il periodo della partenza quindi ho rifatto un po’ i conti in funzione del fatto che la Megane nella migliore delle circostanze offre un consumo di 13,5 Km per Litro contro i circa 22 Km per Litro della Prius – la differenza è abbastanza sensibile ed è stata origine di un sacco di riflessioni.

“Fortunatamente” (notare le virgolette) dei ragazzi hanno deciso di fare un incidente proprio sotto casa alcune settimane prima della partenza, finendo contro la Megane parcheggiata. Molto bene.

Trattandosi di una macchina aziendale presa con LeasePlan, fortunatamente (questa volta senza virgolette), ho potuto richiedere una vettura sostitutiva in attesa del ritorno della Megane… fato ha voluto che l’auto sostitutiva fosse una Opel Corsa 1.2 — simpaticissima city car che però ci ha fatto precipitare in un mare di dubbi in merito alla possibilità di fare quasi 7000 km in 18 giorni in una vettura di categoria così piccola.

L’Opel Corsa a Torino Porta Susa!

Alla prima occasione utile abbiamo provato ad effettuare un viaggio un po’ più lungo per vedere come si comportasse, recandoci a Torino. Con grande stupore la macchina si è comportata molto bene, anche grazie al fatto che sia dotata di Cruise Control: ho impostato la velocità di crociera a 120Km e guidare è stato decisamente meno faticoso. Con l’occasione ho approfittato anche per fare un po’ di misurazioni sul consumo in autostrada e, tratto appenninico compreso, la Corsa se l’è cavata con un consumo di 15 Km per Litro, con aria condizionata e 4 passeggeri a bordo.

A questo punto la curiosità e l’entusiasmo sono alle stelle 😂, anche perché la permanenza a Roma tra caldo, incendi e tutto il resto diventa sempre più complessa… è partito quindi il conto alla rovescia alla partenza!

L’altra metà!

Con l’allegria enti delle restrizioni sul Covid, anche in ufficio stanno iniziando a vedersi, dopo anni, sempre meno le mascherine.

Per chi, come me, ha cambiato lavoro in piena Pandemia questa fase è fonte di continuo stupore: da settembre ad oggi ho conosciuto molti colleghi nuovi, ma sempre tutti con la mascherina su metà volto… e allora il cervello che lavora per compensazione si è fatto una proiezione mentale di come potesse essere la bocca, il mento, la punta del naso delle persone. Ed ora, come dicevamo, con grande stupore inizio a vedere l’altra metà reale delle persone che ho conosciuto, ed alcuni sono drasticamente diversi da come me li ero immaginati!

Uomini con barba a sorpresa, donne con lineamenti inattesi! E la cosa bella è che il nostro cervello tende ad associare così tanto l’estetica delle persone a (supposti) tratti attitudinali che alcuni mi sembrano pure totalmente diversi come persone.

Normalità mi mancavi.

Verifica certificato SSL e Chain correlata

Come verificare un certificato HTTPS più la relativa chain

Siccome Google è il miglior post-it che si possa avere, incollo qui il comando per verificare il certificato SSL e la relativa Chain di un dato server HTTPS con abilitato l’SNI.

echo | openssl s_client -showcerts -connect www.google.com:443 -servername www.google.com | more

Sorting OpenAPI 3 Specs by Paths

OpenAPI is a the new emerging standard in API definitions and documentations.

It’s based on a Specification File structured in Json, and a few editors and viewer tools are popping up here and there.

Unfortunately something that seems pretty inconsistent is the sorting of the paths in the viewer against the editor. The specifications leave to the writer to decide in which order the API Paths should be sorted, but most of the editors doesn’t allow to reorder the paths inside of the Json file.

So, I made this small-and-ugly script to sort the PATHS inside of an OpenAPI json file alphabetically, which seems a pretty practical approach even in documentations.

It reads a file called openapi.json and writes out a file called openapi_sorted.json.

Feel free to use it as you like.

<?php

##
## Small tool to sort the paths inside an OpenAPI definition file
## Taken from https://andrea.brancatelli.it/
##

$mainObject = json_decode(file_get_contents("openapi.json"));

$paths = get_object_vars($mainObject->paths);
ksort($paths);

$mainObject->paths = new StdClass();

foreach ($paths as $eachPath => $eachValue) {
	$mainObject->paths->$eachPath = $eachValue;
}

file_put_contents("openapi_sorted.json", json_encode($mainObject,
	JSON_PRETTY_PRINT |
	JSON_UNESCAPED_SLASHES |
	JSON_UNESCAPED_UNICODE));

Politiche di gestione dei Backup nel rispetto delle linee guida del GDPR

Un breve documento che presenta alcuni cambi di strategia adottati in Schema31 nella gestione dei backup per recepire e rispettare le nuove linee guida del GDPR.

Introduzione

Con l’introduzione delle linee guida per la Privacy diventate operative a partire dal 25 Maggio 2018, lo scenario della gestione dei dati personali nell’ambito dei processi informatici è notevolmente cambiato. 

Al proprietario del dato personale vengono infatti riconosciute una serie di tutele legate alle indicazioni di come i suoi dati vengano trattati e conservati da aziende terze che si trovino a gestirli.

Conseguentemente, l’intera filiera di gestione del dato personale viene impattata da una revisione sistematica che permetta di garantire una totale trasparenza ed un totale rispetto dei dati gestiti.

Nell’ambito del GDPR vengono introdotti 8 principi base nella gestione del dato personale :

  • Il diritto all’informativa: l’organizzazione che gestisca dei dati personali è tenuta ad informare l’utente di quali dati stia conservando, a che fine e per quanto tempo verranno conservati.
  • Il diritto all’accesso: l’organizzazione che gestisca dei dati personali è tenuta a garantire a fornire, entro un mese, una copia di tutti i dati personali in suo possesso ad un utente che ne richieda l’accesso.
  • Il diritto alla rettifica: l’organizzazione che gestisca dei dati personali è tenuta a correggere entro un mese dei dati che, secondo l’indicazione dell’utente risultino incompleti, parziali o errati.
  • Il diritto all’oblio: l’organizzazione che gestisca dei dati personali è tenuta a cancellarli qualora l’utente lo richieda o, comunque, ritiri il consenso al trattamento.
  • Il diritto a limitare il trattamento: l’organizzazione che gestisca dei dati personali è tenuta a limitare al minimo possibile il set dei dati che raccoglie o gestisce di un determinato utente.
  • Il diritto alla portabilità: l’organizzazione che gestisca dei dati personali è tenuta a rendere possibile la migrazione dei dati personali di un utente ad un’altra organizzazione nella maniera più semplice possibile.
  • Il diritto all’obiezione: l’organizzazione che gestisca dei dati personali è tenuta ad interrompere ogni trattamento dei dati dell’utente che obietti la legittimità al trattamento, fino a che non dimostrerà di essere titolata a trattarli.
  • Limiti alla profilazione: l’organizzazione che gestisca dei dati personali è tenuta a porre dei vincoli nei processi automatizzati di profilazione dell’utente, con specifico riferimento all’analisi incrociata dei dati di un utente ed alla definizione di ciò che potrebbe riguardarlo in maniera correlata a preferenze che abbia espresso.

Nella loro applicazione, questi 8 principi base impattano in maniera diversa su fasi diverse della gestione di un processo informatico. Taluni di essi, infatti, saranno recepiti in fase di definizione della comunicazione verso l’utente (Diritto all’informativa), taluni saranno recepiti in fase di design dei sistemi informatici software che gestiscano i dati (Diritto alla rettifica, diritto alla limitazione del trattamento, diritto alla portabilità, limiti alla profilazione), taluni saranno recepiti in fase di esercizio del sistema informatico (Diritto all’accesso, diritto all’oblio, diritto a limitare il trattamento, diritto all’obiezione).

Implementazione delle logiche di backup

Ognuno di questi aspetti cardine viene recepito in maniera più o meno complessa nell’ambito di un sistema informatico – quello di maggiore impatto, ed oggetto di questo documento – è senza dubbio l’infrastruttura volta a garantire il backup dei dati gestiti dall’applicazione. Essa infatti viene impattata in maniera diretta dal diritto all’oblio, che riguarda fondamentalmente tutte quelle strategie da adottare nel momento in cui sia necessario cancellare un determinato dato su richiesta di un utente, nonché dai normali parametri di riservatezza e confidenzialità.

Da un punto di vista dell’applicativo in esecuzione e della sua base dati, l’implementazione di funzionalità di sicurezza e di cancellazione dei dati stanno oramai diventando funzionalità de-facto, che possono apparire abbastanza semplici da implementare: per garantire il diritto all’oblio, ad esempio, sarà sufficiente cancellare il tracciato dati relativo all’utente che ne abbia richiesto la cancellazione, mentre per garantire la confidenzialità del dato (e quindi indirettamente il diritto alla limitazione al trattamento) sarà sufficiente adottare dovute precauzioni nella gestione dei privilegi di accesso all’applicazioni ed eventuali politiche di cifratura dei dati su disco nella base dati (cifratura dati a riposo).

Raramente, invece, si focalizzano le problematiche dei dati degli utenti nell’ambito dell’ecosistema di Backup. Ogni dato trattato e gestito lascia alle sue spalle una proiezione della sua presenza sia all’interno dei sistemi informatici che lo hanno gestito, sia nei sistemi di backup.

Il GDPR, invece, richiede in maniera molto formale che ogni istanza dei dati dell’utente che chieda la cancellazione debba essere rimossa; è, quindi, assolutamente necessario prendere in considerazione anche delle strategie volte alla rimozione dalla stessa dai sistemi di backup.

Su Internet è possibile trovare della bibliografia  sul tema nel quale viene suggerito di adottare delle strategie volte a pianificare delle politiche di backup tramite le quali i dati di ogni utente siano collocati in un archivio a se stante – da cancellare quindi integralmente su richiesta dell’utente. Per quanto apparentemente risolutivo della problematica generale, questo approccio risulta decisamente di difficile applicazione in uno scenario applicativo che debba gestire dati di migliaia di utenti, sparsi in una base dati organizzata per gestire dei dati specifici di un determinato dominio applicativo.

Sarebbe altresì possibile progettare dei sistemi di backup che, invece di esportare la base dati in maniera diretta, la trasformino in un’estrazione aggregata dedicata, ma questo creerebbe degli enormi effort operativi nel mantenere la procedura di backup allineata con l’evoluzione della base dati, nonché un enorme incremento delle tempistiche di ripristino della base dati a fronte di un’anomalia hardware o applicativa (in altre parole, invece che limitarsi a ripristinare la base dati bisognerebbe avviare delle complesse procedure di re-importazione dei dati stessi) .

Tolta la possibilità di gestire in maniera automatizzata questa operazione, è necessario ridisegnare le procedure di backup affinché soddisfino i requisiti del GDPR.

In ambito SCHEMA31 stiamo pertanto adottando le seguenti linee guida:

Riduzione delle tempistiche di permanenza dei backup

Nel precedente approccio alla gestione dei Backup si era usata una filosofia secondo cui la situazione migliore possibile fosse quella di far perdurare il dato “più a lungo possibile” nel sistema di Backup.

Le così-dette policy di retention del sistema di backup erano pertanto disegnate per “riempire” totalmente il sistema di backup con la maggiore profondità storica possibile. All’esaurimento dello spazio nel sistema di backup, i nuovi backup avrebbero sovrascritto i più vecchi generando uno svecchiamento dei dati conservati. Nei casi degli applicativi con basi dati più contenute, questo poteva portare con semplicità ad una profondità storica di 5, 6, fino anche 10 anni di backup.

Questa scelta, “garantista” nei confronti della parte tecnologica, però risulta stridere fortemente con il diritto all’oblio (dato che una cancellazione nella base dati poteva far perdurare il dato nei backup anche per dieci anni), con il diritto alla limitazione del trattamento (dato che anche una riduzione del set dei dati trattati poteva richiedere decine di anni ad essere applicata), e con il diritto all’informativa (dato che non essendo pianificata in maniera preventiva una politica temporale di backup essa era di difficile formalizzazione nell’informativa all’utente).

A valle del ridisegno delle politiche di Backup in ottica GDPR si è deciso di modificare le policy di retention del sistema di backup affinché nessun dato storico venga conservato per più di due mesi dalla data in cui viene estratto dalla base dati.

Definire in maniera rigorosa questa metrica permette di comunicare questo dato in maniera chiara all’utenza (nel rispetto quindi del diritto all’informativa) e permette di garantire che a fronte di un utente che richieda una rettifica dei propri dati o la cancellazione dei propri dati, essa possa essere effettuata in maniera deterministica sia sulla base dati (in tempo reale) sia sulla base storica dei dati sulla piattaforma di backup (entro un massimo di due mesi).

Cifratura delle informazioni all’interno del sistema di backup

Un altro aspetto focale emerso durante la revisione delle politiche di Backup in un’ottica di rispetto delle linee guida del GDPR è relativo agli ulteriori step che è necessario adottare per garantire la tutela delle informazioni trattate dell’utenza, nell’ottica di limitare più possibile il trattamento delle stesse da parte sia di persone autorizzate che di persone non autorizzate che si trovino involontariamente a gestire i dati.

Detto altrimenti, la necessità – anche ai fini del rispetto delle norme ISO27001 e derivati – di definire il perimetro di confidenzialità di trattamento dei dati rende improvvisamente il sistema di backup il punto nevralgico della sicurezza all’interno dell’infrastruttura informatica: da una parte un utente malintenzionato non ha la necessità di superare gli elevati sbarramenti di sicurezza di un sistema disegnato per trattare dati riservati, quando può accedere ad una copia della base dati su un sistema con parametri di sicurezza inferiore (e solitamente aperto a molteplici sistemi diversi) quale il sistema di backup. D’altra parte qualsiasi operatore del sistema di Backup risulta involontariamente esposto a tutte le responsabilità di confidenzialità dei dati contenuti all’interno delle basi dati, spesso senza esserne neanche conscio.

Per aggirare questo problema si è deciso di definire delle logiche di cifratura delle basi dati esportate prima del loro invio verso il sistema di backup.

Specificamente, vi è da garantire una serie di aspetti fondamentali:

  • Il rispetto dei migliori RTO (Recovery Time Objective)  – pertanto la procedura di ripristino di un backup deve essere mantenuta più “fruibile” possibile.
  • Il rispetto della confidenzialità dei dati – pertanto la procedura di backup deve impedire il ripristino del backup da parte di un utente non designato all’operazione.
  • Il rispetto dell’isolamento dei dati in chiaro dagli operatori del sistema di backup – pertanto la procedura di Backup non deve prevedere chiavi di decifrazione all’interno del sistema di Backup.

Per garantire il rispetto di questi fattori si è optato per effettuare una cifratura a chiave asimmetrica (chiave RSA da 2Kb con cifratura AES-256) della base dati esportata prima che essa venga inviata al sistema centrale di gestione di backup .

Specificamente l’esportazione della base dati provvederà a cifrare il backup stesso tramite una duplice chiave pubblica:

  • La chiave pubblica del Server che sta effettuando il backup – di modo da garantire che in qualsiasi momento il Server che sta effettuando il backup sia in grado di ripristinare il proprio backup. Questo tipo di vincolo non introduce ulteriori falle ai principi di confidenzialità del dato, in quanto il codice che si occupa di effettuare il Backup ha già accesso alla base dati – conseguentemente qualsiasi violazione del Server da parte di un utente malintenzionato renderebbe accessibile la base dati nella sua interezza e non solo il suo stesso Backup. Al contempo questa scelta permette di garantire il miglior RTO possibile in quando un operatore correttamente abilitato all’accesso al Server potrà sempre effettuare il ripristino dello stesso (tramite l’accesso al backup con la chiave privata del Server stesso) qualora questo sia necessario. Parallelamente un operatore che abbia già accesso al Server, si può già considerare informato e conscio dei principi di confidenzialità dei dati che il Server stesso contiene.
  • La chiave pubblica del Responsabile della Privacy dell’azienda – di modo da garantire che a fronte di un evento disastroso che corrompa in maniera irreversibile il Server, il backup dei suoi dati sia comunque accessibile su una piattaforma terza (piattaforma sostitutiva del Server o piattaforma esterna) fornendo tutte le adeguate garanzie di continuità del business. Questo tipo di vincolo non introduce ulteriori falle ai principi di confidenzialità del dato, dato che l’unico a poter accedere ai dati stessi è il Responsabile della Privacy tramite la sua chiave privata – quindi persona già titolata a farlo. Al contempo permette di garantire degli RTO adeguati semplicemente coinvolgendo il Responsabile della Privacy nella fase di ripristino dei dati stessi, anche a fronte di attività di personale operativo sistemistico non necessariamente designato per operare sulla base dati in questione (ad esempio operatori della nuova infrastruttura) e che quindi potrebbero non essere coscienti dei livelli di confidenzialità necessari nel trattamento dei dati in questione (a differenza del Responsabile della Privacy che a questo punto è necessariamente coinvolto).

Il sistema di backup centralizzato a questo punto si limiterà a copiare i file cifrati all’interno del sistema di Storage storicizzato senza possibilità da parte degli operatori del sistema di Backup o di terzi malintenzionati che vi abbiano accesso, di leggere alcun dato contenuto al suo interno.

Riferimenti