Security Service Edge: quattro principi fondamentali per il tuo percorso SASE

Security Service Edge (SSE) è un concetto importante per comprendere il viaggio verso un’architettura Secure Access Service Edge (SASE). SSE è un termine introdotto da Gartner in riferimento allo stack di sicurezza in evoluzione necessario per raggiungere con successo una convergenza SASE, che include funzionalità tecnologiche come Cloud Access Security Broker (CASB), Secure Web Gateway (SWG), Firewall-as-a-Service e Zero Trust Network Access (ZTNA), requisiti fondamentali per lo stack.

La security è ricca di acronimi e ne vengono introdotti di nuovi in continuazione. Proviamo ad andare a fondo e cerchiamo di comprendere cosa significa adottare un approccio SSE al di là dei requisiti tecnologici fondamentali, esaminando la sua rilevanza per un’architettura SASE e Zero Trust.

Qual è la differenza tra SASE e SSE?

La prima era della sicurezza informatica si basava su firewall, Web proxy on-premise, sandbox, SIEM (Security Information and Event Management) e strumenti di sicurezza degli endpoint. Oggi sempre più dati si stanno spostando al di fuori del perimetro della rete, fuori dalla portata dei firewall, che in ogni caso non sono in grado di interpretare il traffico cloud. Se a ciò si aggiunge il fatto che sempre più endpoint che si connettono al Web, alle risorse aziendali e ai dati sono BYOD, i punti di controllo tradizionali non forniscono un quadro completo di ciò che sta accadendo ai nostri dati. In sintesi, ne deriva la fotografia di una supervisione estremamente inaffidabile dei dati aziendali.

Cerchiamo di capire come un approccio SSE, se implementato correttamente, può aiutare a mantenere i dati al sicuro nel cloud.

#1 La sicurezza deve seguire i dati

Al giorno d’oggi abbiamo una vasta quantità di traffico che un proxy Web tradizionale o un firewall non possono comprendere né vedere. Abbiamo utenti che sono ovunque, applicazioni che si trovano in più cloud e dati accessibili da qualsiasi luogo. Detto questo, occorre avere un punto di ispezione della sicurezza che segua i dati ovunque essi vadano. E se quel punto di ispezione deve seguire i dati, significa che il punto di ispezione deve trovarsi nel cloud per fornire vantaggi a utenti e applicazioni.

#2 La sicurezza deve essere in grado di decodificare il traffico cloud

Decodificare il traffico cloud significa che la sicurezza deve essere in grado di vedere e interpretare il traffico API JSON, cosa che i proxy Web e i firewall non sono in grado di fare.

#3 La sicurezza deve essere in grado di comprendere il contesto che circonda l’accesso ai dati

Dobbiamo andare oltre il semplice controllo di chi ha accesso alle informazioni e passare a un accesso continuo e in tempo reale e a controlli delle policy che si adattano costantemente in base a una serie di fattori, inclusi gli utenti stessi, i dispositivi che utilizzano, le applicazioni a cui stanno accedendo, le attività che stanno compiendo, l’istanza dell’applicazione (aziendale o personale), la sensibilità dei dati, i segnali ambientali come la geolocalizzazione e l’ora del giorno e le minacce presenti. Tutto ciò fa parte della comprensione, in tempo reale, del contesto con cui gli utenti stanno tentando di accedere ai dati.

#4 La sicurezza non può rallentare la rete

L’utente deve ottenere i propri dati velocemente e la rete deve essere affidabile. Se la sicurezza sta rallentando l’accesso o l’operatività, la produttività ne risente e i team inizieranno pericolosamente ad aggirare i controlli di sicurezza per riavere velocità e affidabilità di rete. Qualcuno potrebbe pensare che la velocità della sicurezza si possa ottenere semplicemente spostando i controlli di sicurezza nel cloud, ma non è così semplice. Accedere al cloud significa attraversare un luogo sporco, chiamato Internet, che può causare tutta una serie di problemi di routing e latenza. È qui che entrano in gioco le reti private che possono garantire un percorso regolare ed efficiente dall’utente finale alla sua destinazione e viceversa.

SSE significa riprendere il controllo

A causa di tutte queste esigenze, il perimetro tradizionale è scomparso ed è necessario spostare il punto di ispezione. SSE fornisce quel punto di ispezione, o meglio, molti punti di ispezione distribuiti che si avvicinano il più possibile a dove e come si accede ai dati, sia nel cloud che in un’applicazione privata.

Tutto questo ha profonde implicazioni sul modo in cui si progettano la sicurezza e l’infrastruttura e sul perché SSE e SASE sono necessari per essere ben organizzati. Proviamo a pensarla in questo modo: se il 90% della spesa per la sicurezza è incentrato sulla sicurezza on-premise, ma il 50% delle applicazioni e il 90% degli utenti sono off-premise, la sicurezza è già stata “tirata al massimo” come un elastico. Si sta cercando di trasferire la sicurezza dal modello on-premise a compiti per cui non è stata progettata, creando tensione per l’azienda che potrebbe portare a un eventuale strappo di quell’elastico, rompendo la sicurezza, che appunto non funzionerà.

Dei quattro punti sopra elencati, l’ultimo fa riferimento alla rete. Troppo spesso, storicamente, siamo partiti dalla rete per affrontare problemi di sicurezza, e questo perché spesso presumevamo che i nostri dati fossero sulla nostra rete e che la rete fosse sicura. Ma ora, i nostri dati non sono sulla nostra rete e i nostri utenti non sono sulla nostra rete. Ciò non significa che sia necessario prescindere dalla necessità di sicurezza della rete, né riduce l’importanza di questioni come il controllo degli accessi. Significa solo che alcune linee non sono così nette ma sfocate e dobbiamo rendercene conto.

Con un approccio SSE, i punti di ispezione Internet sono al posto giusto, si consolidano le capacità di ispezione su cloud, web e dati e, soprattutto, tutte queste capacità di ispezione si attivano in modo atomico, tutte allo stesso tempo, non in sequenza o una alla volta.

Per saperne di più sulle funzionalità di sicurezza SSE di Netskope e su come funzionano in un’architettura SASE: https://resources.netskope.com/solution-briefs/netskope-security-service-edge-sse

A cura di Jason Clark, Chief Security Officer & Chief Strategy Officer, Netskope