Vi siete mai chiesti cosa succederebbe se mentre state pagando con Bancomat al supermercato vi venisse clonata la tessera ed una telecamera riprendesse il vostro codice PIN? Anche questo può accadere nel mondo Internet, dove costanti sono gli inserimenti sui form di iscrizione alla newsletter, i form di acquisto, i form di login, i form di contatto.

Immaginiamo ora che qualche furbetto possa intromettersi nella comunicazione tra voi (o meglio, il vostro browser), che state tranquillamente inviando il vostro numero di carta di credito tramite modulo di pagamento, e un server che ospita il sito e-commerce nel quale state acquistando. Lo stesso furbetto ha ora il vostro codice in mano, e dato che il server non ha dichiarato nessun metodo di protezione, il codice che è riuscito a ricevere è mostrato in chiaro, senza cifratura. Ora potrà rubarvi tutti i risparmi di una vita.

Ma quindi, come possiamo proteggere il canale di comunicazione tra i nostri clienti e i nostri siti? Proprio da questo quesito nasce il protocollo HTTPS (conosciuto anche come HyperText Transfer Protocol over Secure Socket Layer/Transport Layer Security, italianizzando Protocollo per il Trasferimento di Ipertesti Sicuro), basato sul normale protocollo di scambio di informazioni HTTP, ma come dice il nome stesso con l’aggiunta di uno strato di sicurezza. Questo protocollo permette di scambiare dati su un canale sicuro attraverso la rete, e si può facilmente comprendere se un sito lo utilizza, notando le differenze nell’immagine sottostante.

Lo scambio di dati viene protetto in base ad un certificato, detto certificato SSL, che definisce come la cifratura deve avvenire, per poter scrivere e leggere il dato parlando una “lingua comune”, ma trasferirlo in rete senza che questa lingua venga riconosciuta.

Il funzionamento di una richiesta

Una comune richiesta tra client e server su protocollo HTTP può comprendere:

• la richiesta stessa fatta tramite URL,
• gli header di richiesta (come si vuole la pagina, con che browser si sta visitando il sito, ecc..)
• i parametri di form e pagine mandati tramite richieste GET e POST
• i cookies, strumenti per la memorizzazione di stato tra le diverse pagine che si visitano e che possono anche contenere dati personali

Ogni qualvolta questa richiesta avviene, il protocollo HTTPS fa si che client e server si accordino su un metodo di cifratura efficace, basato sul certificato SSL e sulla chiave pubblica del server, e definito ciò iniziano con lo scambio dati.

Per i meno tecnici, è possibile avere una visione più semplicistica di cosa accade con qualche immagine.

Per i più esperti invece specifichiamo che il metodo di codifica utilizzato è quello della Crittografia Asimmetrica con Firma Digitale, in cui il server genera:

• una chiave pubblica messa a disposizione verso altri ed utilizzata per cifrare i contenuti da mandargli; è anche verificata da un’autorità esterna tramite certificato digitale
• una chiave privata, che utilizza solo il server per decifrare i dati che arrivano dall’esterno
  

Autorità per la Certifica

Solitamente, per essere validi, i certificati vengono ottenuti tramite Certification Authority (CA), che sono autorità di terze parti e rispettano gli standard internazionali per la verifica del server ed il rilascio dei certificati in questione.
Esistono molteplici autorità, dislocate in tutto il territorio mondiale, ed offrono diverse soluzioni per certificare il proprio server.

Tipologie di Certificati SSL

Ogni certificato può avere differenti stadi di crittografia (definiti in bit), validità e garanzia in caso di danni per hacking differenti. Vediamo ora alcuni esempi di certificato SSL che possono essere richiesti, ognuno con costi differenti.

Certificato SSL semplice

E’ il più semplice dei certificati, e verifica un solo dominio, senza però controllare l’identità della società che l’ha richiesto. Nella barra degli indirizzi appare così:

Certificato SSL EV

Ad un livello più avanzato del precedente, questo certificato permette la validazione estesa del dominio, permettendo la verifica dell’azienda che lo richiede. Nella barra degli indirizzi appare in questa maniera:

Certificato SSL Wildcard

A differenza di un certificato per dominio singolo, questo permette di coprire più domini che abbiano ugual estensione. Ad esempio, sarà possibile certificare https://www.example.com, ma anche https://store.example.com e https://blog.example.com . La modalità di visualizzazione è la stessa di un certificato semplice, in quanto ad oggi non è possibile applicare validazioni estese per domini con wildcard.

Certificato SSL per Indirizzo IP

Questa tipologia di certificato copre un intero server identificato dall’indirizzo IP o un’intera zona coperta da quell’indirizzo IP.

SEO, dopo la sicurezza

Dal 2014 sembra che Google dia priorità in SERP agli indirizzi che risultano essere sicuri, proprio per promuovere l’utilizzo sempre più massivo dei protocolli standard per la sicurezza che sono stati messi a disposizione.

WebSolution è pronta anche per questa sfida, siamo in grado di assicurarti la messa in sicurezza della comunicazione tra il tuo sito e i tuoi clienti, per non farti rischiare troppo nella vasta rete. Contattaci per richiedere un preventivo!

Abbiamo partecipato al workshop “Docker: understand, use, orchestrate”. Ecco come è andata…

Dal 23 al 26 novembre abbiamo partecipato al Codemotion Milano 2016, uno tra gli appuntamenti di incontro tra esperti nel settore IT e Developement più importanti d’Italia. Anche se la proposta formativa dei workshop era diversificata ed ognuno di essi aveva molto da offrire, abbiamo deciso di partecipare al workshop tecnico su Docker. Vediamo più in dettaglio di cosa si è parlato.

Negli ultimi anni nel mondo della Information Technology la virtualizzazione ha avuto uno sviluppo preponderante in ambito Cloud e non solo, dove la possibilità di scalare su più nodi di calcolo è la funzionalità più ricercata.

Il mondo della virtualizzazione però in molti casi risulta appesantire molti processi di integrazione e sviluppo e minare le performance del sistema. Un esempio pratico potrebbe essere quello di un sistemista che deve istanziare e mantenere una cinquantina di macchine virtuali, tutte con caratteristiche applicative differenti. Parlando di virtualizzazione, una interazione del genere costerebbe allo stesso sistemista ore e ore di configurazioni, non potendo facilmente replicare una stessa macchina se non su un altra virtual machine.

Il progetto Docker parte dall’esigenza di facilitare i punti appena visti e implementare, sfruttando il sistema di containerizzazione già presente da tempo all’interno dei sistemi UNIX-based, la gestione dei containers, una soluzione più performante che garantisce un buon livello di isolamento applicativo e di risorse.

Ciò che nel mondo della virtualizzazione viene chiamato macchina virtuale, in Docker è un container, ed al suo interno è possibile configurare un intero sistema operativo, un pool di applicazioni, un singolo servizio, un server o una distribuzione applicativa, semplicemente descrivendone il contenuto.

Fonte: https://www.docker.com/what-docker

La struttura dei container di Docker è estremamente granulare ed applicabile a molte architetture informative già esistenti ed assestate. Inoltre, la comodità di Docker è che può essere usato con qualsiasi sistema operativo: se non si ha a disposizione una piattaforma Linux, Docker mette a disposizione dei wrapper per lanciare il servizio all’interno di una distribuzione Linux minimale.

Non importa assolutamente il mezzo, il programma funziona ovunque, con la stessa metodologia ed in egual modo.

Di default, un container di Docker deve essere inizializzato e composto da una o più immagini di container già esistenti, ma nulla vieta naturalmente di crearsi le proprie immagini.

Supponendo di voler avviare un container con una determinata immagine, è necessario richiedere al demone Docker (Docker daemon) esattamente quell’immagine, ed esso si occuperà di istanziare un container come processo con le caratteristiche specificate. Docker daemon, se non si è in possesso dell’immagine in un repository locale contatta il registry (contenitore in rete di immagini standard, il default per Docker è Docker Hub) e scarica una copia dell’image mantenedola in una cache locale nel caso potesse servire per ulteriori istanze future.

Il container può essere avviato come si avvierebbe una VM, passando variabili di ambiente, effettuando il mapping di porte e così via.

La vera forza di Docker è che permette di sviluppare la propria architettura informativa in modo stratificato ed agile. Ad esempio, partendo da un’immagine CentOS, si possono creare due immagini che la usano come base: una con un web server Apache e una con un web server Nginx. Volendo replicare questi nodi nella stessa macchina, il processo richiederebbe il solo costo temporale di scaricamento dell’immagine di CentOS e dei pacchetti Apache ed Nginx, per poi inizializzare le istanze in qualche minuto. Le istanze potrebbero contenere tutte una versione di Apache ed Nginx differenti, in quanto le immagini scaricate permettono la scelta di versione in avvio di una nuova istanza del container.
Un sistema del genere permette di isolare le dipendenze gestendo così al meglio il proliferarsi delle versioni di librerie e software senza troppi grattacapi, il tutto con pochi e semplici comandi.
E questo ci porta a descrive un workflow tipico.

Quante volte avete sentito la tipica frase: “Eh, ma sulla mia macchina funzionava!”
Bene, con Docker mai più!
Prendiamo l’applicazione, isoliamone le dipendenze e mettiamola in un container, creando una nuova immagine. Partendo da qui, l’immagine può essere distribuita a tutti gli sviluppatori che interverranno nel progetto, assicurandosi che ogni persona coinvolta avrà esattamente la stessa installazione applicativa, come potrà essere ugualmente replicata in fase di stage e produzione.

In questo modo, le applicazioni possono essere facilmente spostate in modo più economico e veloce, evitando problemi causati dalle caratteristiche delle piattaforme o dalle restrizioni dei singoli provider. In definitiva, Docker costa sicuramente meno, in termini economici e di risorse, rispetto a soluzioni di virtualizzazione più tradizionali.