Sei in grado di comprendere concretamente gli accordi sul livello del servizio? Guida alla demistificazione degli accordi sul livello del servizio per la sicurezza sul cloud

A cosa servono gli accordi sul livello del servizio?  

Gli accordi sul livello del servizio (Service Level Agreement, o SLA), nel contesto di questo blog, rappresentano la fiducia di un provider di servizi di sicurezza sul cloud nella sua capacità di fornire un servizio resiliente, scalabile e ad alte prestazioni. Gli SLA sono diventati più comuni con l'aumento della popolarità delle soluzioni SaaS, e forniscono alle organizzazioni delle garanzie sui livelli del servizio, come ad esempio per prestazioni e disponibilità, per un ampio pool di risorse condivise. Anche se questi accordi tendono a essere particolarmente rilevanti per gli avvocati, tutte le parti coinvolte in una decisione di acquisto dovrebbero comprendere appieno gli SLA di un provider, al fine di:

1. Comprendere l'impatto a livello aziendale dell'affidabilità, la velocità e l'esperienza complessiva dell'utente del servizio
2. Quantificare il rischio, per comprendere cosa esclude l'accordo
3. Distinguere tra leader di settore e innovatori e altri provider che utilizzano parole accattivanti per creare l'illusione che si stiano sottoscrivendo SLA di qualità

In questo post, analizzeremo gli SLA dei provider di servizi di sicurezza sul cloud, di Zscaler e di altri, per:

• Scoprire l'ingrediente segreto degli eccellenti SLA di Zscaler
• Individuare e analizzare i componenti più importanti degli SLA, con un approfondimento specifico sugli accordi relativi alla latenza dei proxy
• Fornire dei criteri di valutazione per distinguere accordi SLA all'avanguardia nel settore dagli accordi di altri provider, i quali troppo spesso sono pieni di esclusioni che vanificano l'obiettivo dell'accordo stesso

 

L'approccio di Zscaler agli accordi SLA: qual è l'ingrediente segreto

Fondamentalmente, l'ingrediente segreto di uno SLA d'eccellenza è un security cloud d'eccellenza. Non si può puntare tutto sugli SLA, se non si è in grado di concretizzarli.

Gli accordi SLA di Zscaler sono frutto di oltre un decennio dedicato allo sviluppo, alla creazione e all'implementazione del security cloud più grande al mondo, progettato per proteggere il traffico più critico. Molti provider hanno tentato di replicare il nostro approccio, celando la loro mancanza di differenziazione tecnica dietro accordi SLA che sembrano buoni sulla carta, ma che celano in realtà delle lacune.

Ecco alcune delle caratteristiche principali degli altri provider:

Provider di soluzioni CASB isolate che tentano di espandersi verso nuovi mercati:

1. Piattaforma progettata per attività semplici, come la scansione fuori banda delle app SaaS utilizzando le API REST invece di elaborare il traffico critico alla velocità massima di rete, che richiede un approccio e una struttura molto diversi
2. Strategia incentrata sull'annoverare le "caratteristiche" delineate nei report di analisti di alto livello (ad es. nel MQ di Gartner), e non sulla scoperta e la risoluzione dei problemi specifici dei clienti.
3. Architetture basate sul progetto open-source del proxy Squid, che presenta da tempo il problema della scalabilità insufficiente

Fornitori di hardware legacy che cercano di rimanere sul mercato:

1. Ripropongono apparecchi virtuali single-tenant sull'IaaS (ad es. GCP, AWS) con data center dalle risorse di calcolo limitate, un modello di responsabilità condivisa e disponibilità inaffidabile 
2. Concatenano servizi affidandosi a servizi esistenti e nuovi, introducendo complessità e latenza con ogni funzionalità aggiuntiva
3. Offrono aggiornamenti irregolari del servizio e del sistema operativo per firewall basati su VM (ad es. 6-9 mesi per aggiornamenti del sistema operativo per eseguire la migrazione da firewall fisici a firewall basati su VM ospitati nel cloud pubblico)

Questi approcci hanno dimostrato di avere dei limiti significativi per quanto concerne la fornitura di un servizio di qualità e gli accordi SLA che ne derivano. Spiegheremo queste limitazioni in modo più dettagliato di seguito.  

 

Orgogliosi di mostrare la nostra scalabilità

Quando si valutano gli SLA di un fornitore, praticamente si analizza la forza della sua piattaforma cloud. Senza dati accessibili pubblicamente sulla scalabilità e sulle prestazioni, come è possibile valutare concretamente la piattaforma e i conseguenti accorsi SLA?  Zscaler è l'unico provider del settore a condividere pubblicamente i dati a supporto delle proprie affermazioni riguardo a scalabilità e prestazioni. 

L'impronta globale di Zscaler: 100% data center di calcolo (senza on-ramp o vPoP)

Siamo così sicuri delle nostre affermazioni sulla scalabilità che vogliamo renderle pubblicamente visibili, in ogni momento, fornendo dati in tempo reale. Dai un'occhiata al Pannello di controllo dell'attività del cloud di Zscaler per visualizzare queste metriche aggiornate al secondo.

Spunti di riflessione:

Perché nessun altro provider rende pubblici i dati o le metriche sulla propria scalabilità o sul funzionamento del proprio cloud? Suggerimento: l'immagine di una macchina da corsa per simboleggiare la velocità NON vale.

 

Gli SLA di Zscaler: alta disponibilità, sicurezza di livello superiore e velocità massima

Questa è l'essenza degli SLA di Zscaler Internet Access (ZIA), come descritto nella nostra scheda prodotto. La gestione del security cloud più all'avanguardia del settore richiede SLA altrettanto all'avanguardia.

1. SLA sull'alta disponibilità (a misura del cliente)
In genere, qui i fornitori si fanno la guerra a suon di 9 (si noteranno frequentemente espressioni come il 99,999%, per indicare la disponibilità). Più aumentano i 9, più grande è l'impegno a garantire la disponibilità. Ad esempio, con il 99,9% di disponibilità, un fornitore garantisce che il suo servizio sarà interrotto per non più di 525 minuti in un anno: (1-99,9%) x 525.600 (525.600 è il numero di minuti in un anno). Un fornitore con cinque nove, ossia 99,999%, si impegna a meno di 6 minuti di inattività all'anno. 

Leggendo attentamente i nostri SLA, è possibile notare che Zscaler offre un accordo innovativo basato sulla percentuale di transazioni perse a causa di inattività o lentezza, e non sulla percentuale di tempo in cui il servizio non è stato disponibile. Questo SLA a misura di cliente è in linea con l'effettivo impatto commerciale dei tempi di inattività e prevede persino il rimborso quando il servizio è disponibile al 100%, ma il cliente subisce un rallentamento dovuto a una congestione imprevista. 

Spunti di riflessione: 

Se le transazioni diminuissero del 20% a causa di una congestione, il fornitore potrebbe affermare che il servizio era comunque disponibile al 100%?

È qui che i venditori lift-and-shift, che gestiscono le loro macchine virtuali legacy single-tenant sull'IaaS, incontrano le maggiori difficoltà, per via della mancanza di controllo e dell'imprevedibilità dell'infrastruttura sottostante. È abbastanza comune che negli SLA di questi fornitori sia presente un lungo elenco di esclusioni che vanifica lo scopo dello SLA stesso.

In questo esempio, un fornitore di NGFW legacy esclude gli aggiornamenti non pianificati dallo SLA, rendendolo quindi inutile:

Spunti di riflessione: 

Se il cloud risulta inaspettatamente e senza preavviso inattivo, ma questo non viene considerato tempo di inattività, allora che cos'è il tempo di inattività? Non è proprio questa sua la definizione? 

In un altro esempio, lo stesso fornitore di NGFW legacy esclude gli eventi di scalabilità dal proprio SLA:

Spunti di riflessione: 

L'obiettivo principale dei servizi forniti sul cloud non è forse quello di eliminare i costi e le problematiche legate alla scalabilità?

2. Lo SLA sulla cattura dei virus noti al 100% (sicurezza superiore)
Un proxy iperscalabile deve offrire un'esperienza utente rapidissima, ma anche una sicurezza di livello superiore, senza scendere a compromessi. Se tutto si riducesse a trasferire dei pacchetti dal punto A al punto B senza scansioni, potremmo anche offrire una latenza di 0 ms, ma il livello di sicurezza sarebbe scarsissimo. L'accordo SLA sulla cattura dei virus noti è una novità assoluta per il settore, che ancora una volta conferma la superiorità della nostra sicurezza. Ci impegniamo a impedire al 100% di tutti i malware/virus noti di diffondersi attraverso la nostra piattaforma. Per ogni errore, riceverai del credito.

Gli altri fornitori sfruttano degli espedienti nei propri SLA lasciando passare il traffico "notoriamente sicuro", come CDN e servizi di condivisione di file, senza alcuna scansione a causa di limiti legati all'architettura, alla scalabilità o alla resilienza. Nell'attuale panorama di minacce in continua evoluzione, questo approccio si sta rivelando sempre più obsoleto, poiché le minacce veicolate da fonti attendibili e affidabili sono in continuo aumento. 

Spunti di riflessione: 

Vuoi considerare attendibile tutto il traffico proveniente da CDN, provider di cloud pubblici o servizi di condivisione di file? 

3. SLA sulla bassa latenza del proxy (velocità massima) -
L'ispezione del traffico criptato (senza limiti) e l'utilizzo di motori di prevenzione delle minacce e della perdita di dati contemporaneamente consuma i cicli della CPU, è un dato di fatto. È qui che ci impegniamo a garantire una sicurezza e una protezione dati estremamente efficaci ed efficienti, con un'esperienza utente di livello superiore. 

 

Approfondimento sullo SLA correlato alla latenza del proxy

Quando si ottimizza l'esperienza utente, è necessario considerare sia la latenza della rete che la latenza del proxy. Parleremo dell'ottimizzazione della latenza di rete in un altro post, ma in breve, la latenza di rete è il tempo trascorso tra il client e Zscaler sommato a quello tra Zscaler e il server. Sia la latenza della rete che quella del proxy vengono ottimizzate in modo significativo, grazie alla nostra ampia presenza all'edge del servizio e alla capacità di peering nei punti di scambio. Tuttavia, in questa sezione parleremo della latenza del proxy:

La latenza del proxy è una metrica Layer 7 che riflette il tempo aggiuntivo (in millisecondi) introdotto dal proxy per eseguire la scansione della richiesta HTTP/S, sommato al tempo aggiuntivo per la scansione della risposta HTTP/S. Nell'illustrazione precedente, la latenza del proxy è Xms (richiesta) + Yms (risposta). In qualità di proxy Layer 7, Zscaler esegue molti motori di sicurezza e protezione dati, sia su intestazioni/payload della richiesta che su intestazioni/payload della risposta; è quindi importante acquisire entrambi i fronti.

La latenza del proxy può essere eliminata? No. Perché è un dato di fatto: la scansione di ogni transazione richiede cicli di CPU. La latenza del proxy può essere ottimizzata ? Sì e ne parleremo brevemente più avanti. 

 

Il modo giusto per offrire SLA eccellenti in termini di latenza del proxy

Purtroppo, gli altri fornitori sono noti perché inseriscono negli SLA esclusioni che vanificano il loro stesso scopo. È fondamentale comprendere cosa viene effettivamente escluso da un fornitore, come calcola la latenza e cosa sembra troppo bello per essere vero. 

1. Includere la scansione di minacce e DLP

Per un servizio di sicurezza, l'esclusione della scansione delle minacce e della DLP vanifica lo scopo dello SLA stesso

È "facile" trasferire dei pacchetti da una parte all'altra senza fare nulla. È bene fare attenzione quando i fornitori promettono valori di latenza che sembrano troppo belli per essere veri. Se Zscaler volesse offrire uno SLA senza la scansione delle minacce o della DLP, potrebbe offrire valori di 25 ms e 5 ms per il 95° percentile per le transazioni HTTPS decriptate e per le transazioni HTTP di testo normale, rispettivamente; si tratterebbe di valori di 2 volte migliori rispetto agli altri fornitori, ma riteniamo che questi dati non siano una misura rilevante e che siano altamente fuorvianti per i nostri clienti. 

Ad esempio, un provider di soluzioni CASB fornite come prodotti isolati, e quindi non create per l'elaborazione del traffico inline, mostra il suo vero volto nelle clausole:

Uno SLA sulla latenza del proxy non deve escludere il tempo aggiuntivo introdotto dai suoi motori.

2. Fornire trasparenza

La prova concreta si ha verificando tutte le affermazioni sulla latenza del proprio provider di sicurezza sul cloud. 

Un accordo SLA sulla latenza del proxy deve essere fornito con report e metriche a livello di transazione, che dovrebbero essere messi a disposizione dal fornitore stesso. Nessun dato = nessuno SLA. 

I dettagli a livello di transazione sono la prova tangibile dell'impatto della latenza, e sono fondamentali per garantire la trasparenza e la risoluzione dei problemi. Combinare scelte architetturali scadenti con degli SLA accattivanti pone gli altri fornitori in una posizione difficile:

1. Fornitori di soluzioni CASB offerte sotto forma di prodotti isolati costretti a espandersi in nuovi mercati: dato che si affidano a un progetto open source di proxy non scalabile, non dispongono di un piano di logging per le imprese in grado di acquisire log a livello di transazione (è bene che chi lavora nei SOC ne sia al corrente). Anche se si volesse, gli SLA non potrebbero essere riportati a livello di transazione con questo tipo di approccio. 
2. Fornitori di hardware legacy che cercano di rimanere competitivi sul mercato: il concatenamento di varie funzioni con VM firewall sull'IaaS genera valori di latenza disaggregati e l'impossibilità di segnalare la latenza del proxy end-to-end in tempo reale. 

A causa dell'incapacità o della riluttanza nel fornire trasparenza, un noto fornitore di CASB è stato costretto a usare tattiche subdole per mascherare i problemi di latenza dietro a una media oraria. Poiché non in grado di effettuare il logging a livello di transazione, nelle ore a elevata variabilità, la media viene diminuita artificialmente. 

Zscaler si fonda sulla trasparenza. Siamo disposti e in grado di fornire ai nostri clienti la visibilità che meritano:

 

Zscaler fornisce un report sulla latenza basato sulle revisioni trimestrali dell'azienda (QBR)

 

Web Insights Log Viewer di Zscaler con visibilità sulla latenza del proxy a livello di transazione
 

3. Concentrarsi sulla latenza delle transazioni del proxy invece che sulla latenza dei pacchetti del firewall

La latenza dei pacchetti fornisce un quadro incompleto sulla latenza, specialmente nel nostro mondo incentrato sul web. 

Dato che stiamo parlando di latenza del proxy, sarò relativamente breve, ma è importante comprendere questa fondamentale differenza. La latenza dei pacchetti è una misura che indica il tempo impiegato da un apparecchio firewall fisico o virtuale per elaborare i pacchetti della richiesta (dal tempo di input a quello di output). Tuttavia, si tratta di una metrica fuorviante. La misurazione del tempo di elaborazione della richiesta rappresenta solo una frazione della latenza complessiva della transazione, e non tiene conto dell'aspetto più critico della latenza, ovvero la ricezione delle informazioni. Per natura, la maggior parte del traffico web è costituita da GET con piccoli payload e risposte di grandi dimensioni, perciò si tratta di un grave errore nella misurazione della latenza, soprattutto nel nostro mondo incentrato sul web. 

 

L'ingrediente segreto di Zscaler per ottenere livelli ottimali di latenza del proxy

Scalare l'infrastruttura cloud è il primo passo, ma la soluzione ottimale si basa sulla giusta architettura sottostante. Zscaler scansiona ogni singolo pacchetto in modo estremamente efficiente, sfruttando servizi di sicurezza paralleli chiamati SSMA (Single Scan, MultiAction):

I motori SSMA di Zscaler lavorano in parallelo

L'SSMA rappresenta il meglio di ciò che i professionisti della sicurezza richiedono al settore di implementare ormai da decenni: un'unica piattaforma in grado di bilanciare una sicurezza d'eccellenza con un'esperienza utente veloce. Questo è ciò che Gartner definisce "ispezione single-pass del traffico criptato e dei contenuti alla velocità della linea", nell'ambito dell'architettura SASE.

Con le architetture tradizionali, sia che si tratti di apparecchi per il concatenamento dei servizi, di servizi con base cloud o di un mix di entrambi, i pacchetti devono lasciare la memoria di una macchina virtuale (VM) per dirigersi verso un'altra VM in un data center o in un cloud completamente differente. Non è necessario essere esperti di fisica o di networking per capire quanto questo approccio sia inefficiente e complesso. 

Zscaler si basa su un'architettura nativa del cloud che colloca i pacchetti in una memoria condivisa su server altamente ottimizzati e progettati per ottimizzare il percorso dati. Inoltre, tutte le CPU di un nodo di Zscaler possono accedere contemporaneamente a tali pacchetti. Avendo CPU dedicate per ogni funzione, tutti i motori possono ispezionare gli stessi pacchetti contemporaneamente (da qui il nome Single Scan, MultiAction). In questo modo, possiamo garantire che non vi sia una latenza aggiuntiva introdotta dal concatenamento dei servizi. Questo consente al nodo di Zscaler di prendere decisioni sulle policy in modo estremamente rapido e di inoltrare i pacchetti a Internet.

In sintesi, riproporre degli apparecchi virtuali legacy e modificare dei progetti proxy open-source con motori aggiuntivi non è la soluzione giusta. Con questo tipo di approccio, i debiti tecnici che si devono affrontare e risolvere a causa dell'infrastruttura legacy sono decisamente troppi. 

Esempio di un fornitore legacy che ripropone VM FW legacy sull'IaaS con il concatenamento dei servizi

 

Richiedi ai fornitori onestà riguardo ai propri accordi SLA

Ecco qualche consiglio su come mettere in pratica queste informazioni. Molti dei nostri clienti esistenti e potenziali si concentrano sulla disponibilità quando parlano di SLA con i propri fornitori. Quello della disponibilità è sicuramente un argomento molto importante da toccare, ma non consente di avere una panoramica completa del servizio offerto da un provider.

Di seguito è riportata una pratica tabella che può essere utilizzata per identificare i componenti principali degli SLA che vengono sottoposti alle aziende: