Skip to main content
Sicurezza del cloud

Che cos'è SSE? Definizione, componenti e best practice

Che cos'è SSE? SentinelOne spiega Security Service Edge: i suoi componenti principali, i vantaggi chiave, gli errori di implementazione e le best practice per i team distribuiti.

Di SentinelOne
Reviewer: Joe Coletta
Che cos'è SSE? Definizione, componenti e best practice

Punti chiave

  • SSE (Security Service Edge) è una piattaforma di sicurezza erogata dal cloud che combina Secure Web Gateway (SWG), Cloud Access Security Broker (CASB) e Zero Trust Network Access (ZTNA) per proteggere l'accesso al web, ai servizi cloud e alle applicazioni private.
  • SSE è il sottoinsieme esclusivamente di sicurezza di SASE. Fornisce controlli di sicurezza degli accessi senza SD-WAN o trasformazione della rete, il che lo rende il punto di ingresso più pratico per le organizzazioni che puntano a un SASE completo.
  • SSE applica policy basate sull'identità nei PoP cloud distribuiti vicini agli utenti. Valuta il dispositivo, il rischio utente, la posizione e il contesto dell'applicazione durante ogni sessione, non solo al login, limitando così fino a dove può arrivare un account compromesso.
  • Le organizzazioni adottano SSE per proteggere forze lavoro remote e ibride, ambienti cloud-first, settori regolamentati e shadow IT. Inoltre riducono la proliferazione degli strumenti, il volume degli avvisi SOC e la superficie di attacco della VPN.

Che cos'è SSE?

SSE (Security Service Edge) è una categoria di mercato introdotta da Gartner nel 2021 che consolida tre funzioni di sicurezza principali, Secure Web Gateway (SWG), Cloud Access Security Broker (CASB) e Zero Trust Network Access (ZTNA), in una piattaforma unificata erogata dal cloud. Come la guida all'architettura di sicurezza cloud di Gartner la definisce, SSE è "un sottocomponente di SASE che protegge l'accesso al web, ai servizi cloud e alle applicazioni private."

SSE è importante perché i tuoi utenti non si trovano più dietro un'unica rete affidabile. La sicurezza deve seguirli. Invece di instradare il traffico attraverso un data center centrale, SSE applica policy basate sull'identità vicino all'utente e all'applicazione. Questo riduce la latenza, colma le lacune di visibilità e riunisce accesso remoto, utilizzo SaaS e traffico internet sotto un unico insieme di policy.

SSE è emerso perché le organizzazioni adottavano solo i componenti di sicurezza del più ampio framework Secure Access Service Edge (SASE) senza l'intero stack di rete. Gartner ha identificato questo modello e ha definito SSE come il sottoinsieme esclusivamente di sicurezza di SASE. Questo ha fornito ai team una categoria chiara per consolidare la sicurezza erogata dal cloud senza attendere la trasformazione della wide area network (WAN).

SSE vs. SASE

SASE (Secure Access Service Edge) è il framework più ampio da cui deriva SSE. Gartner ha introdotto SASE nel 2019 come convergenza di rete e sicurezza in un unico servizio erogato dal cloud. SSE è il sottoinsieme esclusivamente di sicurezza: contiene i controlli di sicurezza degli accessi senza il livello di trasformazione della rete.

Funzionalità

SSE

SASE

Secure Web Gateway (SWG)

✓

✓

Cloud Access Security Broker (CASB)

✓

✓

Zero Trust Network Access (ZTNA)

✓

✓

Firewall-as-a-Service (FWaaS)

✓

✓

Ottimizzazione SD-WAN e WAN

✗

✓

Trasformazione della rete

✗

✓

La maggior parte delle organizzazioni arriva a un SASE completo iniziando con SSE. I controlli di sicurezza vengono implementati più rapidamente, il business case è più diretto e i team possono dimostrare il valore prima di affrontare la trasformazione WAN. Se la tua roadmap di rete è ancora in evoluzione o gestita da un team separato, SSE è il giusto punto di ingresso.

Perché le organizzazioni hanno bisogno di SSE

SSE affronta un fallimento strutturale nell'architettura di sicurezza tradizionale. Quando i tuoi utenti si connettono direttamente alle applicazioni cloud, il traffico non passa mai attraverso il tuo stack di sicurezza on-premises. Perdi contemporaneamente visibilità su accesso web, utilizzo SaaS e sessioni di applicazioni private.

Gli avversari notano questi punti ciechi. Nel 2023, gli attaccanti hanno usato social engineering contro l'help desk di MGM Resorts per ottenere accesso e interrompere le operazioni di hotel e casinò. Il SEC 8-K filing dell'azienda ha stimato un impatto finanziario negativo di circa 100 milioni di dollari nel solo terzo trimestre, esclusi i costi di ripristino e gli effetti dell'assicurazione cyber. Quando i tuoi utenti, appaltatori e amministratori si autenticano da uffici domestici, reti non gestite e app cloud, i controlli incentrati sul perimetro lasciano lacune che gli attaccanti focalizzati sull'identità sfruttano. SSE riduce queste lacune valutando identità e contesto in ogni sessione, limitando così fino a dove può arrivare un singolo account compromesso.

SSE consolida le funzioni di sicurezza che proteggono l'accesso al cloud e al web in un unico punto di applicazione. Invece di gestire appliance separate per il filtro web, il controllo delle app cloud e l'accesso remoto, applichi policy coerenti tramite un'unica piattaforma erogata dal cloud. Questo riduce direttamente la proliferazione degli strumenti che genera avvisi eccessivi e crea lacune di copertura tra prodotti di sicurezza disconnessi. SSE è anche uno dei modi più pratici per applicare i principi di zero trust security all'accesso degli utenti.

Per i settori regolamentati, Security Service Edge ha ottenuto una convalida formale. Un briefing della CISA sulle linee guida federali zero trust identifica SASE/SSE come un'architettura accettabile per soddisfare i requisiti Trusted Internet Connection (TIC) 3.0, con maggiore flessibilità rispetto ai modelli tradizionali.

Ogni componente di SSE colma una specifica lacuna di accesso aperta dal lavoro distribuito.

Componenti principali di SSE

Le piattaforme Security Service Edge convergono tre servizi di sicurezza fondamentali. Ognuno affronta un modello di accesso distinto che la tua forza lavoro distribuita crea ogni giorno.

Secure web gateway (SWG)

Secure Web Gateway protegge l'accesso a internet e al web applicando il filtro URL, la protezione anti-malware, l'ispezione dei contenuti e le policy di utilizzo accettabile. All'interno di SSE, le funzionalità di secure web gateway devono essere erogate dal cloud, non basate su appliance. Un requisito architetturale fondamentale di SSE è che l'ispezione avvenga in un'infrastruttura cloud distribuita vicina agli utenti, anziché tramite uno stack centralizzato di appliance. Questo elimina la penalizzazione in termini di latenza dovuta all'instradamento del traffico web di ritorno attraverso un data center centrale.

Cloud access security broker (CASB)

Cloud Access Security Broker fornisce visibilità e controllo sull'utilizzo delle applicazioni cloud, applica le policy di sicurezza dei dati sulle piattaforme SaaS e monitora le violazioni della conformità. All'interno di SSE, le funzioni di cloud access security broker operano in due modalità: inline, per il blocco in tempo reale, e basata su API, per l'individuazione retrospettiva di app cloud non autorizzate.

La distinzione tra doppia modalità è importante dal punto di vista operativo. Il CASB basato su API rileva lo shadow IT che l'ispezione inline non vede perché il traffico verso app non autorizzate non passa mai attraverso il proxy SSE. Se stai confrontando le basi del CASB con controlli cloud più ampi, questa separazione è uno dei motivi principali per cui le piattaforme SSE includono sia metodi inline sia basati su API.

Zero trust network access (ZTNA)

Zero Trust Network Access sostituisce la VPN legacy applicando i principi zero trust del NIST all'accesso remoto. Ogni richiesta viene verificata in base all'identità e al contesto, con accesso a privilegi minimi concesso solo ad applicazioni specifiche anziché ad ampi segmenti di rete. In pratica, lo zero trust network access è spesso il caso d'uso SSE più rapido da implementare perché si adatta chiaramente all'accesso remoto alle applicazioni.

Componenti aggiuntivi

Oltre ai tre servizi principali, le piattaforme SSE in genere incorporano:

  • Firewall-as-a-Service: Funzionalità di firewall di rete erogate dal cloud senza appliance on-premises
  • Data Loss Prevention (DLP): Integrato con CASB per applicare le policy di gestione dei dati nelle app cloud
  • Remote Browser Isolation: Esegue le sessioni web in ambienti isolati per contenere le minacce basate sul browser
  • Cloud Security Posture Management (CSPM): Rilevamento continuo delle configurazioni errate negli ambienti cloud

Insieme, questi componenti sostituiscono il tradizionale modello di traffico hairpin con un'applicazione distribuita nel cloud. Il modo in cui lavorano insieme come sistema è ciò che determina le decisioni di implementazione reali.

Come funziona SSE

Security Service Edge sostituisce l'ispezione centralizzata basata su appliance con un'applicazione distribuita nel cloud. SSE instrada il traffico verso Points of Presence cloud distribuiti, o PoP, situati vicino agli utenti e alle destinazioni.

  • Il vecchio percorso: User → VPN → Data Center → Internet → Data Center → VPN → User
  • Il percorso SSE: User → Nearest Cloud PoP (inspection + enforcement) → Destination

Come descritto da NIST SP 1800-35, le moderne architetture zero trust e allineate a SSE indirizzano il traffico verso punti di applicazione distribuiti situati più vicino all'utente finale o all'endpoint, anziché instradarlo di nuovo verso un data center centrale per l'ispezione e la crittografia.

Flusso del traffico e applicazione delle policy

In base a NIST 1800-35, SSE elabora il traffico attraverso una sequenza definita:

  1. L'utente o il client si autentica presso il provider di identità e vengono valutate le policy di accesso condizionale.
  2. SSE stabilisce un tunnel autenticato verso il cloud PoP più vicino, non verso il tuo data center.
  3. Il traffico passa attraverso il servizio cloud SSE per l'ispezione: filtro URL, analisi delle minacce, DLP e controllo degli accessi.
  4. SSE applica le policy di accesso condizionale durante l'intera sessione, non solo al momento del login.
  5. SSE inoltra il traffico verso la destinazione: internet pubblico tramite SWG, applicazioni SaaS tramite CASB o risorse private tramite un connettore ZTNA.

Il quarto passaggio è la distinzione architetturale critica. La VPN legacy autentica una sola volta al momento della creazione del tunnel. SSE valuta continuamente la policy in base a segnali contestuali in evoluzione, inclusi lo stato di conformità del dispositivo, il punteggio di rischio dell'utente, la posizione geografica, la sensibilità dell'applicazione e le restrizioni basate sul tempo.

Quella valutazione continua dipende da una cosa: l'identità. È la base su cui è costruito l'intero modello di enforcement.

Controllo basato sull'identità

SSE utilizza l'identità verificata come principale meccanismo di controllo degli accessi. La policy segue l'utente, il dispositivo e il contesto della sessione, sostituendo l'approccio basato sulla posizione di rete (indirizzo IP o appartenenza alla VLAN) da cui dipendevano le architetture legacy.

Il modo più chiaro per vedere in azione una policy consapevole dell'identità è negli ambienti in cui il vecchio perimetro ha fallito per primo.

Casi d'uso di SSE

SSE affronta quattro scenari in cui la sicurezza basata sul perimetro mostra più chiaramente i suoi limiti.

Forza lavoro remota e ibrida

Quando la tua forza lavoro si connette da uffici domestici e reti non gestite, la VPN tradizionale concede un ampio accesso alla rete a chiunque si autentichi con successo. SSE sostituisce quel modello con accesso a livello applicativo tramite ZTNA, protezione dalle minacce web tramite SWG e applicazione delle policy SaaS tramite CASB. Ogni sessione viene valutata continuamente invece di essere considerata attendibile dopo un singolo accesso.

Ambienti applicativi cloud-first

Le organizzazioni che eseguono la maggior parte dei workload in SaaS o nel cloud pubblico non hanno alcun perimetro on-premises per applicare i controlli. Il traffico fluisce direttamente dagli utenti alle app cloud, aggirando completamente qualsiasi stack di ispezione on-premises. SSE sposta l'enforcement su PoP cloud distribuiti, applicando la policy a ogni sessione SaaS tramite CASB e a ogni richiesta web tramite SWG, indipendentemente da dove si trovi l'utente o dal dispositivo che utilizza.

Settori regolamentati

Sanità, servizi finanziari e agenzie federali devono soddisfare requisiti specifici relativi alla gestione dei dati, alla registrazione degli accessi e all'architettura di rete. Le linee guida CISA riconoscono le architetture allineate a SSE come accettabili per soddisfare i requisiti federali di TIC 3.0. CASB fornisce la classificazione dei dati e l'enforcement DLP richiesti da questi ambienti, con audit trail che soddisfano gli obblighi di reporting della conformità.

Shadow IT e proliferazione del cloud

Quando i dipendenti adottano strumenti SaaS non autorizzati, il team di sicurezza non ha visibilità su quali dati fluiscono dove. Il CASB in doppia modalità di SSE (inline per il blocco in tempo reale e basato su API per il rilevamento retrospettivo) intercetta sia l'utilizzo cloud autorizzato sia quello non autorizzato in un'unica piattaforma, senza richiedere che tutto il traffico venga instradato attraverso un proxy tradizionale.

In tutti e quattro gli scenari, i vantaggi operativi di SSE vanno ben oltre la chiusura delle lacune di sicurezza.

Principali vantaggi dell'adozione di SSE

Consolidare la sicurezza web, SaaS e dell'accesso remoto in un'unica piattaforma erogata dal cloud produce vantaggi in termini di postura di sicurezza, overhead operativo e carico di lavoro degli analisti, spesso simultaneamente.

  1. Miglioramento misurabile della postura di sicurezza: Il valore principale di SSE è la coerenza architetturale. Le policy seguono utenti e applicazioni indipendentemente dalla posizione, riducendo le lacune create quando l'accesso remoto, la sicurezza SaaS e il filtro web sono gestiti separatamente. Questa coerenza è il motivo per cui security service edge è adatto alle organizzazioni con utenti distribuiti e accesso cloud-first alle applicazioni.
  2. Consolidamento degli strumenti e riduzione dei costi: Se stai gestendo appliance separate per il filtro web, il controllo delle app cloud, l'accesso remoto e la prevenzione della perdita di dati, SSE le riunisce in un'unica piattaforma. Meno fornitori significa meno accordi di licenza, meno contratti di supporto e meno motori di policy da mantenere.
  3. Riduzione degli alert del SOC ed efficienza operativa: Il consolidamento di SSE riduce il numero di fonti di alert distinte che alimentano il tuo SOC. Quando lo combini con una piattaforma di extended detection and response (XDR) che migliora il rapporto segnale-rumore, l'impatto operativo si amplifica: il tuo team dedica meno tempo al triage degli alert ridondanti e più tempo all'indagine sulle minacce reali.
  4. Eliminazione della superficie di attacco della VPN: La sostituzione della VPN tramite zero trust network access rimuove le ampie concessioni di accesso alla rete che consentono il movimento laterale dopo la compromissione delle credenziali. I tuoi utenti ricevono solo accesso specifico all'applicazione, riducendo il blast radius di qualsiasi singola identità compromessa. Per molte organizzazioni, la sostituzione della VPN è il punto di ingresso più pratico e con meno attrito in SSE. Se il tuo team sta ancora valutando la sicurezza della VPN, questo è spesso il primo business case che ottiene l'approvazione del budget.

Questi vantaggi sono reali. Lo è anche il lavoro necessario per ottenerli.

Sfide dell'adozione di SSE

La maggior parte delle organizzazioni incontra lo stesso insieme di ostacoli indipendentemente dalla scelta della piattaforma o dalle dimensioni del team.

  1. Gap di competenze in cybersecurity: L'implementazione di SSE richiede competenze nelle architetture di sicurezza cloud, nella migrazione delle policy e nell'integrazione multipiattaforma. SSE promette semplificazione operativa, ma per arrivarci servono pianificazione, progettazione architetturale e disciplina nelle policy che molte organizzazioni stanno ancora sviluppando.
  2. Integrazione dell'infrastruttura legacy: Non puoi semplicemente abbandonare un'infrastruttura on-premises funzionante. La maggior parte delle aziende ha effettuato investimenti significativi in una varietà di strumenti e fornitori, molti dei quali restano distribuiti on premises. La maggior parte delle migrazioni procede per un certo periodo in un modello ibrido, e quel modello comporta un proprio overhead di gestione.
  3. Resistenza organizzativa e debito di cybersecurity: I workflow esistenti e la conoscenza istituzionale costruiti attorno agli strumenti legacy creano attriti nella migrazione che sono più difficili da quantificare rispetto alla complessità tecnica, ma altrettanto dirompenti per le tempistiche.
  4. Lacune nella visibilità end-to-end: SSE aumenta le dipendenze esterne che non possiedi né controlli. Quando si verificano problemi, hai una visibilità limitata sulle reti ISP, sulle prestazioni delle applicazioni SaaS e su altre dipendenze cloud. Questo complica la incident response e richiede approcci di monitoraggio che i tuoi runbook attuali potrebbero non coprire.

Nessuno di questi ostacoli è un motivo per aspettare. Ognuno è prevedibile e le pratiche riportate di seguito li affrontano direttamente.

Best practice SSE

I team che implementano SSE con maggiore successo condividono alcune abitudini costanti: iniziano in modo mirato, allineano gli stakeholder fin dall'inizio e misurano prima e dopo. Queste pratiche si applicano sia che si stia implementando per 500 utenti sia per 50.000.

  • Esegui la migrazione per fasi, non tutta in una volta: Migrare simultaneamente tutte le funzioni di sicurezza introduce un rischio composto: interruzioni del servizio, test inadeguati delle policy e una complessità che supera la capacità del tuo team. Inizia con un singolo caso d'uso (ZTNA per l'accesso remoto o SWG per il traffico internet), dimostra il valore, quindi espandi. Questo vale anche per il più ampio percorso SASE: implementare SSE prima di tentare la piena convergenza SASE con la trasformazione WAN riduce il rischio e preserva la flessibilità nella tua roadmap di networking.
  • Parti da ZTNA per la forza lavoro distribuita: ZTNA è spesso il punto di ingresso più efficace perché affronta le lacune immediate nella sicurezza dell'accesso remoto, sostituisce le VPN legacy problematiche, offre miglioramenti dell'esperienza utente che rafforzano il supporto organizzativo e fornisce registri di accesso granulari che migliorano la visibilità del SOC rispetto ai tunnel VPN opachi.
  • Definisci fin da subito una governance congiunta tra sicurezza e networking: Prima dell'implementazione, definisci la governance per l'amministrazione della piattaforma, l'autorità sulle policy e i percorsi di escalation del SOC. Senza chiare assegnazioni di responsabilità, la migrazione della piattaforma supera il tuo modello operativo e crea lacune di sicurezza durante la transizione.
  • Valuta l'erogazione gestita rispetto a quella autogestita: Se il tuo team ha già risorse limitate, valuta servizi SSE gestiti per l'implementazione iniziale, l'ottimizzazione continua delle policy e il monitoraggio continuo. Questo approccio può cogliere i vantaggi del consolidamento senza aggravare il burnout del team, in particolare per le organizzazioni mid-market senza una solida capacità di security engineering.
  • Definisci le baseline prima dell'implementazione: Documenta il volume attuale degli avvisi, l'allocazione del tempo di triage degli analisti e la proliferazione delle policy prima di implementare SSE. Monitora queste metriche successivamente per costruire le evidenze richieste dalla leadership esecutiva per continuare a investire.

Con le pratiche giuste in atto, SSE offre vantaggi di consolidamento misurabili. Abbinalo a un livello XDR che migliori la qualità degli avvisi nell'intero ambiente e questi vantaggi si amplificano.

Callout Background Image Gradient

Demo sulla sicurezza del cloud

Scoprite come la sicurezza del cloud basata sull'intelligenza artificiale può proteggere la vostra organizzazione con una demo individuale con un esperto dei prodotti SentinelOne.

Conclusione

SSE consolida SWG, CASB e ZTNA in una piattaforma di sicurezza unificata, erogata dal cloud, progettata per forze lavoro distribuite. Sostituisce l'ispezione centralizzata basata su appliance con un'applicazione continua delle policy consapevole dell'identità presso PoP cloud distribuiti. 

SSE copre la sicurezza dell'accesso alla rete e al cloud e, abbinato a XDR, estende la protezione a endpoint, workload e identità. Inizia con ZTNA, esegui la migrazione per fasi e definisci la governance fin dall'inizio. Così facendo, ogni utente raggiunge esattamente ciò di cui ha bisogno, da qualsiasi luogo, e nulla di più.

FAQ

Security Service Edge (SSE) è un'architettura di sicurezza erogata dal cloud che consolida Secure Web Gateway (SWG), Cloud Access Security Broker (CASB) e Zero Trust Network Access (ZTNA) in un'unica piattaforma.

Introdotto da Gartner nel 2021, SSE applica policy di sicurezza consapevoli dell'identità presso punti di presenza cloud distribuiti invece di instradare il traffico attraverso un data center centrale, offrendo alle organizzazioni una protezione coerente per utenti remoti, applicazioni SaaS e accesso a internet.

SSE è il sottoinsieme di SASE focalizzato sulla sicurezza. Include SWG, CASB e ZTNA, mentre SASE aggiunge funzioni di networking come SD-WAN e ottimizzazione del traffico.

Se desideri una sicurezza dell'accesso più forte senza riprogettare l'intera rete, SSE è di solito il miglior primo passo. Questo è il fulcro pratico della decisione tra SASE e SSE.

SSE può sostituire il ruolo di accesso remoto della VPN tramite ZTNA, ma il modello cambia. Invece di un ampio accesso a livello di rete dopo il login, ZTNA concede un accesso specifico all'applicazione in base a identità e contesto.

I tuoi utenti raggiungono solo le risorse approvate, il che riduce il rischio di movimento laterale e spesso migliora le prestazioni rispetto all'instradamento di tutto attraverso un concentratore VPN legacy.

SSE gestisce lo shadow IT principalmente tramite CASB. I controlli inline ispezionano il traffico in tempo reale e possono bloccare attività rischiose in tempo reale, mentre le connessioni basate su API esaminano gli ambienti SaaS out-of-band per rilevare utilizzi non autorizzati, dati esposti o violazioni delle policy.

Hai bisogno di entrambe le modalità perché alcuni utilizzi rischiosi del cloud non passano mai attraverso un forward proxy.

Sì. SSE e endpoint detection and response (EDR) o extended detection and response (XDR) risolvono parti diverse dello stesso problema. SSE governa l'accesso al web, alle app SaaS e alle app private, mentre EDR/XDR ti offre profondità su endpoint, identità e indagine dopo che l'attività ha raggiunto l'utente o il dispositivo.

Ottieni il massimo valore quando i log SSE alimentano la tua piattaforma XDR o SIEM per la correlazione con la telemetria di host e identità.

Inizia con zero trust network access se il tuo principale punto critico è la VPN legacy. Spesso offre i guadagni più rapidi in termini di sicurezza e usabilità perché restringe l'accesso ad applicazioni specifiche, migliora la visibilità sulle sessioni remote ed evita un'ampia esposizione della rete.

Successivamente, puoi estendere i controlli di secure web gateway e cloud access security broker tramite un rollout graduale.

Scopri di più su Sicurezza del cloud

Decorative background gradient

La tua sicurezza cloud—completamente valutata in 30 minuti.

Incontra un esperto SentinelOne per valutare il tuo livello di sicurezza cloud negli ambienti multi-cloud, individuare asset cloud, configurazioni errate, secret scanning e dare priorità ai rischi con Verified Exploit Paths™.
Dark dashboard UI with purple-highlighted nav, summary cards showing 149, 7, 78, 56, 1.2 h, and a status table with linked purple text