Blog Home Topics: SSL

Il mondo sta cambiando

giu 07, 2017 Inserito da Radware
Il mondo sta cambiando da Daniel Lakier
Il mondo sta cambiando, lo ha sempre fatto, ma adesso l’evoluzione è più rapida di quanto non sia mai stata prima. Questo cambiamento generale si traduce in trasformazioni ancora più radicali nel mondo informatico. Alcune delle aree chiave in corso di mutazione non sono nuove, per esempio la disponibilità o la sicurezza. Altre, quali l’automazione, stanno maturando rapidamente, e poi c’è sempre l’eterna necessità di cose “semplici.” Semplice è un aggettivo nebuloso, ma in questo caso si riferisce alla facilità di reperimento, di impostazione, alla flessibilità delle piattaforme e la semplicità nella gestione dopo l’implementazione.

Questo cambiamento accelerato è guidato da diversi fattori di mercato e commerciali. Alcuni degli elementi chiave che guidano il mercato sono la conformità, il time-to-market, il rischio di perdita informatica e l’aumento della concorrenza a livello di user experience. Questo cambiamento si sente molto in ambito ADC.
 
La conformità riguarda soprattutto la sicurezza, ma in alcuni casi anche la disponibilità. Strettamente legato alla conformità è il rischio di perdita informatica in seguito a un attacco. Man mano che le infrastrutture IT mondiali diventano meno isolate e più pubbliche (SAAS, cloud pubblici, etc.), le organizzazioni devono discostarsi dalla protezione delle infrastrutture e da un modello di sicurezza che protegge i dati. Lo standard comune per proteggere i dati web e l’integrità in movimento è il SSL/TLS. L’uso di questa tecnologia di crittografia è aumentato notevolmente l’anno scorso. Secondo Mozilla Firefox e Google Chrome, il traffico criptato SSL rappresentava il 50% di tutto il traffico Internet. Questo incremento dell’utilizzo comporta diverse conseguenze non programmate.

In primo luogo, il SSL può proteggere i nostri dati ma anche limitare la nostra visibilità sui dati che entrano nelle nostre reti utilizzando la medesima tecnologia. Perché è importante questa mancanza di visibilità? In passato, le aziende solitamente ignoravano il traffico SSL in entrata. Avevano fatto una scelta ritenendo che il traffico SSL rappresentasse una quantità minima di tutto il traffico in entrata, pensavano che ignorarlo potesse essere un rischio accettabile. Questo concetto era condiviso dalla maggior parte dei fornitori di sistemi di sicurezza (le apparecchiature che, per limitare il rischio, avrebbero bisogno della visibilità). Quindi, ad esempio, se compraste un firewall oggi, nel peggiore dei casi perdereste l’85% della vostra capacità di trasmissione; nel caso migliore, il 70%, qualora decideste di controllare il traffico SSL. Ovviamente, questo non vi permetterà di coprire una quantità sufficiente di traffico se il 50% è crittografato SSL. Ciò che contribuisce a peggiorare questo problema è che la maggior parte degli analisti concorda che, entro il 2020, ben oltre il 70% di internet sarà crittografato SSL.
 
Quindi, qual è la risposta? Utilizzare un dispositivo esterno appositamente progettato per eseguire l’off-load e il controllo di processi SSL. Negli ultimi 15 anni, gli ADC hanno effettuato l’off-load SSL ad alte velocità e sono diventati una soluzione molto efficace per questo problema in termini di costi. Tuttavia, questa necessità generale di visibilità è spinta da una nostra vecchia conoscenza, la compliance. Certamente, avete bisogno di proteggere i vostri dati, senza però violare il diritto alla privacy delle persone. Questo problema è molto più difficile da risolvere e richiede funzionalità avanzate della soluzione SSL prescelta, che consentano di scegliere selettivamente cosa controllare e cosa ignorare. Con l’emanazione di diverse leggi regionali in materia di dati personali (PII), questa funzionalità è passata dall’essere un requisito opzionale ad una necessità.

Se questa fosse la fine della storia della protezione dei dati in movimento, sarebbe abbastanza complessa, ma non lo è. Proprio come qualsiasi altra corsa agli armamenti (e la sicurezza informatica è una corsa agli armamenti), la velocità di adozione e la complessità di tale sicurezza aumentano in modo esponenziale. La maggior parte di noi ha vissuto l’aggiornamento chiavi da 1K a 2K circa due anni fa. Abbiamo avuto modo di vedere come tale cambiamento abbia influito sulle prestazioni dei nostri server e di altre apparecchiature (è avvenuto anche piuttosto recentemente, quindi ce lo ricordiamo bene). Abbiamo dovuto fare questo cambiamento perché gli algoritmi non erano più abbastanza complessi. Cambiamenti come questo sono sempre accaduti, ma raramente a questo ritmo. Siamo in cima al secondo grande cambiamento di algoritmo SSL in soli tre anni e, data la storia recente, è probabile che ce ne sarà un altro nei prossimi cinque anni. La cosa interessante di questi cambiamenti SSL è che sono innescati dai mercati in generale. Le aziende devono adeguarsi per non rimanere indietro. Se, ad esempio, il TLS1.3 nella sua forma attuale diventa lo standard, tutti dovranno cambiare il loro algoritmo SSL da RSA a ECC perché il RSA non è attualmente supportato nello standard TLS1.3. Questo cambiamento, come il passaggio alle chiavi 2K, influenzerà le prestazioni dell’infrastruttura esistente di tutti. La buona notizia è che alcune aziende hanno creato soluzioni appositamente progettate con una visione lungimirante per contribuire a mitigare il rischio di questi cambiamenti. Se vi state chiedendo in quali termini questo problema vi potrebbe riguardare, ci sono quattro aree chiave da tenere a mente.

1) Scaricamento dal server (l’applicazione scambia chiavi con il client, una delle funzioni che richiede più risorse dal punto di vista del server).

2) Controllo SSL in entrata a fini di visibilità della sicurezza (non è possibile controllare ciò che non si può vedere).

3) Controllo SSL in uscita per la visibilità della sicurezza in uscita (analogo al precedente, ma di solito strettamente legato alla prevenzione della fuga di dati (DLP). Richiede intelligenza per non visualizzare i dati PII).

4) Controllo SSL anticipato per la protezione dagli attacchi DDoS. Simile ai precedenti punti 2 e 3, ricordandosi tuttavia che l’ispezione SSL richiede molte risorse, quindi avere una soluzione con intelligenza incorporata per consentire di limitare il numero di controlli da effettuare è particolarmente importante in un ambiente DDoS, a meno che il dispositivo SSL non diventi il bersaglio più probabile degli attacchi DDoS.

La disponibilità è sempre stata un elemento chiave di ciò che gli ADC dovrebbero fare e rimane la funzione fondamentale offerta dalla maggior parte degli ADC. Credo che vedremo un rinnovato interesse nell’utilizzo degli ADC come strumento per testare le appliance / le applicazioni che eseguono un codice disparato in ambienti scalabili in modo da ridurre il time-to-market, ma diminuire il rischio; in questo modo, in caso di bug non preventivato, possiamo facilmente reindirizzare il traffico senza alcuna interruzione. Se dovessimo estrapolare questo aspetto con un esempio molto specifico, pensate di dover migrare due fornitori di sistemi informatici: non è necessario tagliare o eseguire entrambi in parallelo, né far funzionare due unità dello stesso fornitore con codici diversi.

L’altra area chiave è la semplicità. Semplice può significare tante cose, ma se lo si lega al crescente movimento di sviluppo agile e DevOps, possiamo puntare su diverse aree chiave che dovremmo prendere in considerazione. In primo luogo, la facilità di reperimento. Posso chiamare un partner e ottenere un preventivo facile da capire? Le modalità di pagamento sono flessibili, CapEx od OpEx? Posso acquistare su mercati cloud? Esistono dei modelli per l’impostazione? Posso avere una soluzione interamente gestita? Se voglio gestirla personalmente, l’automazione è supportata nativamente per l’impostazione e la gestione? Esiste un framework nativo che supporta l’automazione operativa? Ci sono strumenti e componenti che risparmiano tempo agli sviluppatori, come i gateway HTTP2, gli strumenti di ottimizzazione delle applicazioni, le funzionalità di gestione SLA e le funzioni di protezione delle applicazioni web integrate, quali un firewall per le applicazioni web e i gateway di autenticazione?

In ultima analisi, il mondo sta cambiando rapidamente e le applicazioni web sono il fulcro di questo cambiamento. Di conseguenza, dobbiamo fare tutto quello che è in nostro possesso per affrontare le sfide nel modo più efficace possibile.
 
Per maggiori informazioni, leggi “Keep It Simple; Make It Scalable: 6 Characteristics of the Futureproof Load Balancer” (IT “Mantienilo semplice, rendilo scalabile: 6 caratteristiche di un load balancer a prova di futuro”).
Scaricalo adesso
 
Daniel Lakier
Daniel Lakier è il Vicepresidente ADC a livello mondiale per Radware. Daniel ha lavorato nel settore della tecnologia più avanzata per oltre 20 anni. In questo periodo ha lavorato a diversi livelli verticali, compreso nei settori dell’energia, della produzione e della sanità. Daniel ama le nuove sfide e, per questo motivo, ha ricoperto incarichi molto vari nel corso della sua carriera: dall’ingegneria applicata, all’architettura e al commerciale. Del resto, Daniel è allo stesso tempo un insegnante e uno studente. Impara continuamente cose nuove e ama molto condividere le sue conoscenze. Ultimamente Daniel ha lasciato il suo ruolo di Presidente e CTO di un importante integratore di tecnologia, che aveva ricoperto per ben 8 anni, per iniziare a collaborare con Radware. Quando Daniel non è in ufficio, ama lavorare in campagna e inseguire le sue meravigliose figlie.
 
Radware
© 2008-2017 Radware, Ltd. All rights reserved.