Come valutare i fornitori SASE: 12 criteri per selezionare la piattaforma SASE aziendale giusta
Cosa troverai qui?
- 1. 1. Modello architettonico e integrazione
- 2. 2. Copertura e profondità della sicurezza
- 3. 3. Punti di presenza globali e prestazioni di rete
- 4. 4. Funzionalità SD-WAN e ingegneria del traffico
- 5. 5. Affidabilità e prestazioni:
- 6. 6. Gestione centralizzata e applicazione delle policy
- 7. 7. Osservabilità, analisi e intelligence sulle minacce
- 8. 8. Roadmap, innovazione e sostenibilità del fornitore
- 9. 9. Metodologia di implementazione e migrazione
- 10. 10. Supporto, livelli di servizio e modello operativo
- 11. 11. Costo totale di proprietà e stabilità dei prezzi
- 12. 12. Conformità, sovranità dei dati e resilienza
- 13. Prossimi passi pratici per la valutazione e la selezione dei fornitori
- 14. Domande frequenti
Valutare i fornitori SASE richiede più che allineare elenchi di funzionalità. La parte difficile è capire se una piattaforma sembrerà ancora valida una volta che gestirà traffico reale, utenti reali e un’effettiva applicazione delle policy in tutta l’azienda. Molti fornitori sembrano validi in una tabella comparativa per poi deludere in seguito a causa di un’integrazione debole, prestazioni non uniformi o prezzi che diventano meno vantaggiosi dopo il primo periodo. Un approccio migliore consiste nel valutare i fornitori in base ad architettura, sicurezza, prestazioni, operazioni e costi, per poi collegare tali risultati agli obiettivi effettivi dell’organizzazione. La previsione di Gartner secondo cui il 70% degli acquisti di SD-WAN farà parte di SASE monovendor entro il 2028, rispetto al 25% nel 2025, è un segno che queste decisioni stanno diventando sempre più difficili da separare. I 12 criteri seguenti offrono a CISO, CIO e team di approvvigionamento un modo più pratico per selezionare e confrontare le piattaforme SASE aziendali.
1. Modello architettonico e integrazione
Il modello di architettura conta più di quasi ogni altra cosa in un processo di acquisto SASE perché modella il disordine, o la mancanza di esso, che il team erediterà in seguito. Influisce sul numero di parti mobili da gestire, sulla coerenza dell’applicazione delle policy e sulla quantità di lavoro di integrazione che rimarrà in sospeso dopo la firma del contratto. In pratica, gli acquirenti si imbattono solitamente in tre modelli generali:
Non tutti i fornitori SASE offrono uno stack realmente integrato. Alcuni si affidano ancora a prodotti separati per parti di ZTNA, SWG, CASB, FWaaS, DLP o SD-WAN. Gli acquirenti dovrebbero anche verificare quanto bene la piattaforma coesiste con router, firewall e strumenti di identità esistenti durante la migrazione. La compatibilità brownfield è importante per qualsiasi team che non possa sostituire tutto in una volta.
Cato Networks si posiziona come fornitore SASE a fornitore unico con networking e sicurezza integrati in un’unica piattaforma anziché assemblati in seguito. Questa è la promessa di base del modello a fornitore unico: meno giunture, meno lavoro di integrazione e meno residui operativi.
domande relative all’RFP “La vostra piattaforma SASE viene fornita come un’unica architettura convergente o dipende da componenti sviluppati separatamente? Descrivi come si integra con l’infrastruttura di rete e di sicurezza esistente.”
2. Copertura e profondità della sicurezza
La valutazione della sicurezza deve andare oltre la semplice verifica dell’esistenza di una funzionalità. Le vere domande sono se i controlli funzionano in linea, se le policy vengono applicate in modo coerente e se la prevenzione delle minacce è effettivamente parte della piattaforma invece di essere aggiunta da qualcos’altro.
I servizi di sicurezza fondamentali che ogni acquirente dovrebbe convalidare includono:
- NGFW / FWaaS
- Zero Trust Network Access (ZTNA)
- Secure Web Gateway (SWG)
- Cloud Access Security Broker (CASB)
- Prevenzione della perdita di dati (DLP)
- Prevenzione avanzata delle minacce (IPS, anti-malware, sandboxing)
La profondità è importante a livello di funzionalità. Un fornitore potrebbe essere forte nel CASB e debole nello SWG. Un altro potrebbe dichiarare di offrire DLP ma applicarlo solo a un insieme limitato di app cloud invece che a tutto il traffico pertinente. Gli acquirenti dovrebbero anche verificare se lo ZTNA continua a verificare l’identità e lo stato del dispositivo durante la sessione o se controlla solo una volta al momento dell’accesso.
La profondità della sicurezza è anche una questione di costi. Se la piattaforma può davvero sostituire le VPN, ridurre la spesa per i firewall ed eliminare la necessità di un prodotto DLP autonomo, l’economia cambia. Se quelle funzionalità sono scarse o pesantemente oggetto di upsell, la storia del consolidamento crolla rapidamente.
domande relative all’RFP “Per ogni servizio di sicurezza (FWaaS, SWG, CASB, ZTNA, DLP e prevenzione delle minacce), descrivete se è integrato nativamente nella piattaforma o integrato da un motore di terze parti. Fornite risultati di test indipendenti o certificazioni.”
3. Punti di presenza globali e prestazioni di rete
La copertura dei PoP e la qualità della dorsale non sono dettagli secondari. Hanno un effetto diretto sull’esperienza dell’utente, sulle prestazioni delle applicazioni e sulla capacità dell’organizzazione di soddisfare i requisiti di residenza dei dati.
Una dorsale privata globale è una rete di proprietà del fornitore che collega i suoi PoP in modo che il traffico aziendale possa seguire percorsi controllati e ottimizzati invece di dipendere interamente dall’internet pubblica. Quando ciò è fatto bene, può ridurre le oscillazioni di latenza e il jitter per gli utenti distribuiti.
Ma il numero di PoP di per sé non dice molto. Gli acquirenti dovrebbero misurare la latenza dalle posizioni reali dei loro utenti alle destinazioni reali delle loro applicazioni. Dovrebbero anche chiedere se il fornitore possiede la propria dorsale o se prende in leasing il trasporto da qualcun altro, perché ciò cambia quanto controllo di routing il fornitore ha realmente e quanto è credibile la storia dell’SLA.
Le prestazioni dovrebbero essere testate durante la valutazione, non prese dal materiale informativo del prodotto. Ciò include il comportamento di routing, l’overhead di ispezione e come il servizio si comporta nelle condizioni che interessano realmente all’azienda.
domande relative all’RFP “Fornite un elenco completo delle posizioni dei PoP. Possedete la vostra infrastruttura di dorsale o prendete in leasing la capacità? Qual è la latenza misurata tra [posizioni specifiche degli utenti] e [destinazioni specifiche delle applicazioni]?”
4. Funzionalità SD-WAN e ingegneria del traffico
L’SD-WAN nativa è una delle linee di demarcazione più chiare nel mercato SASE. La qualità dell’ingegneria del traffico influisce sugli SLA delle applicazioni, sulla connettività delle filiali e sulla realisticità con cui l’organizzazione può abbandonare l’MPLS.
Alcuni fornitori includono l’SD-WAN direttamente nella piattaforma. Altri, specialmente i fornitori nati sul versante SSE, dipendono ancora da un prodotto SD-WAN separato per completare il design. Questa scelta ha conseguenze per anni perché modifica sia l’onere di integrazione che il modello operativo.
Le aree chiave dell’SD-WAN da valutare includono:
- Routing consapevole delle applicazioni e policy QoS
- Aggregazione dei collegamenti e ottimizzazione dell’ultimo miglio
- Selezione dinamica del percorso basata sulla qualità del collegamento in tempo reale
- Supporto per diversi tipi di trasporto (MPLS, banda larga, LTE/5G)
La previsione di Gartner secondo cui il 70% degli acquisti di SD-WAN rientrerà in soluzioni SASE monovendor entro il 2028 conferma la direzione del mercato. I team che oggi acquistano SD-WAN e SASE separatamente potrebbero trovarsi a dover riconsiderare tale decisione prima del previsto.
domande relative all’RFP “La vostra funzionalità SD-WAN è integrata nativamente nella piattaforma SASE o proviene da un prodotto separato?” Descrivete il routing consapevole delle applicazioni, i controlli QoS e i tipi di trasporto supportati.”
5. Affidabilità e prestazioni:
Una piattaforma SASE deve scalare con l’attività aziendale tra utenti, sedi, volume di traffico ed espansione nel cloud senza imporre una riprogettazione o compromettere le prestazioni di ispezione. Sembra ovvio, ma molte piattaforme sono molto più brave a parlare di scalabilità che a dimostrarla.
In pratica, la scalabilità significa essere in grado di aggiungere un gran numero di utenti remoti, mettere online nuove filiali o iniziare a inviare traffico verso nuove regioni cloud senza un calo percepibile delle prestazioni. Elementi che gli acquirenti dovrebbero valutare:
- La piattaforma scala automaticamente l’ispezione di sicurezza senza intervento manuale?
- Qual è il throughput massimo per PoP e come viene gestita la capacità?
- La piattaforma può supportare implementazioni sia da 500 che da 50.000 utenti sulla stessa architettura?
I test delle prestazioni vanno eseguiti nella fase di valutazione, non dopo la selezione. I progetti pilota basati su traffico reale che simulano il carico di picco e la diffusione geografica dicono molto di più rispetto alle dichiarazioni di benchmark in una presentazione.
domande relative all’RFP “Descrivete come la vostra piattaforma si scala man mano che crescono utenti, posizioni e traffico. Qual è la vostra architettura per l’auto-scaling dell’ispezione di sicurezza? Fornite benchmark delle prestazioni sotto ispezione di sicurezza completa.”
6. Gestione centralizzata e applicazione delle policy
La gestione unificata nel SASE dovrebbe significare un unico punto per amministrare le policy di rete e di sicurezza, con un’applicazione eseguita in modo coerente tra PoP, filiali e utenti remoti. Se la piattaforma non è in grado di farlo, la semplicità promessa inizia a sembrare un po’ falsa.
Senza un’esperienza di gestione unica, le organizzazioni finiscono solitamente per avere derive nelle policy, un’applicazione incoerente tra i percorsi di accesso e più problemi di audit del previsto. Questo è esattamente il tipo di complessità che il SASE dovrebbe eliminare.
I criteri di valutazione qui dovrebbero includere:
- Controllo degli accessi basato sui ruoli (RBAC) per l’amministrazione multi-team
- Versionamento delle policy e tracciamento delle modifiche per gli audit di conformità
- Capacità di testare le policy in modalità simulazione prima dell’applicazione
- Coerenza nell’applicazione delle policy indipendentemente dalla posizione dell’utente o dal metodo di connessione
Cato Networks propone un’unica console di gestione che copre sia le policy di rete che quelle di sicurezza. Gli acquirenti dovrebbero comunque convalidare tale affermazione in un progetto pilota e osservando attentamente i flussi di lavoro amministrativi reali.
domande relative all’RFP “Tutta la configurazione e il monitoraggio delle policy vengono eseguiti da un’unica console? Come mantenete la coerenza delle policy tra i PoP e i metodi di accesso degli utenti? Descrivete le vostre funzionalità di RBAC, registrazione degli audit e simulazione delle policy.”
7. Osservabilità, analisi e intelligence sulle minacce
L’osservabilità e l’analisi non sono funzionalità secondarie. Sono ciò che consente ai team di risolvere i problemi degli utenti, rilevare le minacce più rapidamente e produrre la reportistica che le operazioni e la conformità continuano a richiedere.
Gli acquirenti dovrebbero cercare dashboard che colleghino gli eventi di rete agli avvisi di sicurezza, un tracciamento a livello di sessione che sia realmente utile durante le indagini e feed di threat intelligence che aggiornino i controlli in linea in tempo reale. Le aree di valutazione utili includono:
- Profondità della telemetria di rete e di sicurezza (a livello di flusso, di sessione, di applicazione)
- Integrazione con piattaforme SIEM/SOAR esistenti
- Rilevamento delle anomalie basato su AI/ML e risposta automatizzata
- Reportistica pronta per la conformità e audit trail esportabili
L’analisi avanzata e la threat intelligence basata sull’AI stanno iniziando ad agire come veri elementi di differenziazione piuttosto che come extra opzionali. I fornitori che sono forti in questo ambito possono ridurre i tempi di risposta e rendere le operazioni quotidiane molto meno cieche.
domande relative all’RFP “Descrivete le vostre funzionalità di analisi in tempo reale, le fonti di threat intelligence e l’integrazione SIEM/SOAR. Qual è il tempo medio della vostra piattaforma per rilevare e far emergere gli eventi di sicurezza? Fornite esempi di dashboard e output di reportistica.”
8. Roadmap, innovazione e sostenibilità del fornitore
SASE non è un acquisto a breve termine. Gli acquirenti devono sapere se il fornitore sarà ancora un partner credibile e ben finanziato tra tre o cinque anni, non solo se il prodotto sembra competitivo al momento.
Ciò significa guardare alla presenza sul mercato, all’adozione da parte dei clienti, alla trasparenza della roadmap e alla copertura degli analisti senza fingere che uno qualsiasi di questi segnali risolva la questione. Il posizionamento degli analisti può fornire un contesto utile. Non è una prova tecnica.
Chiedere la direzione del prodotto per i prossimi 18 mesi. Esaminare la stabilità finanziaria, la continuità della leadership e quanto investimento reale viene destinato ad aree come la sicurezza basata sull’IA, l’espansione di ZTNA e la copertura IoT o OT.
domande relative all’RFP “Condividete la vostra roadmap di prodotto per i prossimi 18 mesi. Quali funzionalità di IA/ML sono già in produzione rispetto a quelle solo pianificate? Fornite i vostri ultimi posizionamenti degli analisti e le metriche di crescita dei clienti.”
9. Metodologia di implementazione e migrazione
La migrazione è una delle parti più rischiose dell’adozione di SASE. Un fornitore può avere una piattaforma solida e rendere comunque doloroso il lancio se la coesistenza è debole, le opzioni di rollback sono vaghe o l’onboarding degli utenti viene trattato come un ripensamento.
Valutare domande come:
- Il fornitore fornisce una metodologia di migrazione documentata con fasi definite?
- La piattaforma può coesistere con i concentratori VPN e i firewall esistenti durante la transizione?
- Quali procedure di rollback esistono se una fase fallisce?
- Quali risorse di formazione e abilitazione sono incluse invece di essere proposte come upsell in seguito?
- Quale ecosistema di partner è disponibile per il supporto all’implementazione?
L’accesso remoto, la connettività di filiale e la migrazione al cloud creano tutti diversi tipi di stress durante il rollout. La valutazione dovrebbe riflettere quei casi d’uso reali invece di trattare l’implementazione come uno scenario generico.
Cato Networks fornisce una guida al rollout riguardante la migrazione graduale, la coesistenza e l’onboarding. Gli acquirenti dovrebbero confrontare quel livello di dettaglio tra i fornitori invece di presumere che ogni provider abbia la stessa maturità di migrazione.
domande relative all’RFP “Fornite la vostra metodologia di migrazione standard, incluse fasi, tempistiche, strategia di coesistenza VPN, procedure di rollback e piano di formazione. Quali risorse partner sono disponibili per il supporto all’implementazione?”
10. Supporto, livelli di servizio e modello operativo
Poiché SASE viene fornito come servizio, la qualità del supporto e la flessibilità operativa contano molto di più rispetto a un semplice acquisto di prodotto. I team dovrebbero esaminare lo storico dell’uptime, la qualità dell’escalation e quanto supporto quotidiano sia effettivamente incluso, invece di dare per scontato che sia presente.
La maggior parte delle aziende finisce per scegliere tra tre modelli operativi:
- Gestito Il fornitore o il partner gestisce la maggior parte delle operazioni quotidiane. Questo solitamente si adatta alle organizzazioni che non dispongono di profonde competenze interne di rete e sicurezza.
- Gestito La responsabilità è condivisa tra il fornitore e i team interni. Questo funziona quando l’organizzazione desidera un maggiore controllo senza gestire tutto direttamente.
- Self-service: I team interni gestiscono la piattaforma autonomamente con il supporto del fornitore dietro le quinte. Di solito è adatto a organizzazioni più grandi con operazioni mature.
I livelli di SLA e i percorsi di escalation dovrebbero essere verificati con le referenze dei clienti, non accettati basandosi solo sulle dichiarazioni di vendita.
domande relative all’RFP “Descrivete i vostri livelli di SLA, le garanzie di uptime e le prestazioni storiche degli SLA. Quali servizi NOC o SOC sono inclusi? Dettagliate il vostro percorso di escalation e la copertura del supporto regionale.”
11. Costo totale di proprietà e stabilità dei prezzi
Costi nascosti e rinnovi spiacevoli sono motivi comuni per cui gli accordi SASE deludono dopo il primo periodo. L’analisi del TCO dovrebbe coprire utenti remoti, filiali, ambienti cloud, servizi professionali e cosa succede ai prezzi nel corso di più anni.
Un modello di TCO utile dovrebbe coprire:
- Costi diretti: Licenze per utente, tariffe per sito, livelli di larghezza di banda, moduli aggiuntivi opzionali.
- Costi indiretti: Impegno di integrazione, formazione, servizi professionali, cambiamenti nel personale interno.
- Risparmi derivanti dal consolidamento: Costi VPN eliminati, spesa ridotta per i firewall, costi evitati per soluzioni DLP autonome.
- Economie di rinnovo: Garanzie di blocco del prezzo, tetti massimi di aumento annuale, soglie di sconto sul volume.
Il ROI dovrebbe ricollegarsi a operazioni più semplici, a una minore proliferazione di strumenti e a reali guadagni di efficienza. Il SASE può ridurre i costi, ma solo se il modello commerciale è abbastanza trasparente da essere affidabile e abbastanza stabile da reggere al momento del rinnovo.
domande relative all’RFP “Fornite un modello di prezzo dettagliato che copra i costi per utente, per sito e per larghezza di banda. Quali sono le vostre condizioni di rinnovo e i tetti massimi di aumento annuale dei prezzi? Elencare dettagliatamente quali servizi di rete e di sicurezza sono inclusi rispetto a quelli venduti come componenti aggiuntivi.
12. Conformità, sovranità dei dati e resilienza
Per le organizzazioni regolamentate, la conformità e la resilienza non sono criteri secondari. Se la piattaforma non è in grado di soddisfare i requisiti di residenza dei dati o le aspettative di continuità, il resto della valutazione smette rapidamente di avere importanza.
Le aree chiave da valutare includono:
- Certificazioni di conformità: SOC 2 Type II, ISO 27001, conformità al GDPR, FedRAMP (per il governo statunitense), framework specifici del settore (PCI DSS, HIPAA)
- Controlli sulla sovranità dei dati: Capacità di limitare l’elaborazione e l’archiviazione del traffico a specifiche regioni geografiche
- Architettura di resilienza: Ridondanza PoP, failover automatico, impegni RTO/RPO e procedure di disaster recovery testate
Le lacune di conformità scoperte dopo il lancio sono costose da correggere e solitamente dolorose internamente. Gli acquirenti dovrebbero convalidare le certificazioni in modo indipendente e assicurarsi che i controlli sulla residenza dei dati siano configurabili al livello effettivamente richiesto dall’azienda.
domande relative all’RFP “Elenca tutte le certificazioni di conformità possedute. Descrivi i tuoi controlli sulla residenza dei dati e come il traffico può essere limitato a regioni specifiche. Fornisci il tuo design ad alta disponibilità, i meccanismi di failover e gli impegni RTO/RPO documentati.”
Prossimi passi pratici per la valutazione e la selezione dei fornitori
Una volta chiari i criteri, il processo richiede comunque disciplina. Un flusso di valutazione fattibile solitamente appare così:
- Definisci le priorità aziendali e pondera i criteri. Una matrice decisionale è utile solo se i pesi riflettono obiettivi organizzativi reali invece di una generica precisione del foglio di calcolo.
- Crea e distribuisci una RFP strutturata. Le domande di cui sopra possono servire come base e il materiale RFP SASE pubblicato da Cato è un esempio di come i fornitori gestiscono tale processo.
- Seleziona tre o quattro fornitori. Valuta il primo round rispetto ai criteri ponderati ed elimina qualsiasi fornitore che non soddisfi i requisiti architettonici o di conformità essenziali.
- Esegui test pilota con traffico reale. Utilizza utenti, posizioni e applicazioni rappresentativi. I test delle prestazioni dovrebbero far parte della selezione, non essere qualcosa da rimandare a dopo.
- Convalida la migrazione e il supporto. Richiedi piani di lancio dettagliati e modelli TCO prima di prendere la decisione finale, perché solitamente sono questi gli aspetti in cui le piattaforme deboli iniziano a mostrare segni di cedimento.
- Negoziare e finalizzare. Bloccare la stabilità dei prezzi, gli impegni SLA e quanta più trasparenza possibile sulla roadmap che il fornitore metterà per iscritto.
Costruire una matrice di punteggio con i 12 criteri come righe e l’elenco dei fornitori come colonne. Ponderare le righe in base a ciò che conta di più per l’azienda. I team focalizzati sulla sicurezza potrebbero dare un peso maggiore ai criteri 2 e 7, mentre le organizzazioni globali potrebbero dare più importanza ai criteri 3 e 12. Le risorse di selezione di Cato possono essere materiale di riferimento utile, ma la ponderazione deve provenire dal proprio ambiente.
Domande frequenti
Quali sono le priorità chiave per i CISO quando selezionano un fornitore SASE?
I CISO dovrebbero preoccuparsi innanzitutto della profondità della sicurezza, della coerenza delle policy e di come l’identità venga applicata nel tempo. Ciò significa convalidare ZTNA, FWaaS, SWG, CASB, DLP e la prevenzione delle minacce non solo a parole. Dovrebbero inoltre verificare se tali servizi siano nativi della piattaforma o presi in prestito da motori di terze parti, quindi richiedere prove indipendenti che i controlli funzionino come dichiarato. La piattaforma convergente di Cato è un esempio di fornitore che cerca di facilitare tale convalida mantenendo lo stack sotto un unico piano di controllo.
Come possono i CIO garantire semplicità operativa e scalabilità in una piattaforma SASE?
I CIO dovrebbero cercare una piattaforma che sia genuinamente cloud-native, gestibile da un unico punto e capace di crescere senza riprogettazione man mano che utenti, siti e traffico cloud si espandono. La semplicità operativa deriva solitamente dalla coerenza delle policy e da un minor numero di componenti, non solo dal marchio. Il modo più sicuro per convalidare tale affermazione è attraverso revisioni del flusso di lavoro amministrativo e progetti pilota che simulino una crescita reale.
Su cosa dovrebbero concentrarsi i team di approvvigionamento per un confronto equo tra i fornitori?
I team di approvvigionamento dovrebbero imporre un confronto diretto tra licenze, funzionalità in bundle rispetto a quelle aggiuntive, livelli di supporto, costi di larghezza di banda, costi di implementazione e termini di rinnovo. Una matrice ponderata è utile, ma solo se i criteri di punteggio sono legati alle priorità aziendali. I termini di rinnovo contano molto perché è spesso lì che due accordi che sembravano simili all’inizio divergono economicamente.
Perché l’architettura cloud-native è importante nel SASE?
Una piattaforma cloud-native è solitamente posizionata meglio per lo scaling elastico, aggiornamenti delle policy più rapidi e un’ampia applicazione distribuita rispetto a un design di appliance legacy adattato in seguito. In termini pratici, ciò può significare un minor sovraccarico operativo e un miglior supporto per gli utenti remoti e i modelli applicativi cloud-first.
In che modo la visibilità e l’analisi influiscono sulla scelta del fornitore SASE?
Una solida visibilità e analisi riducono i tempi di rilevamento, migliorano la risoluzione dei problemi e facilitano la reportistica di conformità. Gli acquirenti dovrebbero considerare la profondità della telemetria, il tracciamento delle sessioni, il rilevamento delle anomalie e l’integrazione SIEM o SOAR. I fornitori che investono seriamente in queste aree tendono a offrire ai team operativi un quadro molto più chiaro di ciò che sta accadendo e perché.
This page was machine-translated. If you notice any inaccuracies or have feedback, please feel free to send it to us here.
