Secure Web Gateway Migrazione: lista di controllo per il passaggio e il ripristino
- Una migrazione SWG richiede un inventario, una fase pilota, dei test, un'implementazione graduale e un rollback verificato, proprio come qualsiasi passaggio all'ambiente di produzione.
- L’autenticazione, i certificati TLS e le relative eccezioni, l’instradamento del traffico e le integrazioni ICAP o DLP comportano i rischi maggiori.
- Mettano in funzione il nuovo gateway in parallelo e trasferiscano gli utenti a ondate, anziché effettuare il passaggio in un’unica soluzione.
- Si definiscano i trigger di rollback e i criteri di accettazione prima della prima fase di produzione, non durante un incidente.
- La migrazione rappresenta l'occasione migliore per eliminare regole inutilizzate da anni ed eccezioni ormai obsolete.
Una migrazione di tipo “ secure web gateway ” comporta il trasferimento dell’ispezione del traffico web e delle politiche da una piattaforma proxy a un’altra, sia che si tratti del passaggio da un’appliance on-premises a una nuova appliance, a un servizio cloud o a un modello ibrido. La presente lista di controllo copre l’intera sequenza: inventario, progettazione dell’ambiente di destinazione, conversione delle politiche, preparazione al rollback, fase pilota, test, passaggio graduale e collaudo.
Il presente articolo fa parte della guida alla sicurezza del cloud ibrido. Per informazioni specifiche su Blue Coat ProxySG e Symantec Edge SWG, si prega di consultare “Blue Coat ” e “ProxySG End of Life: Migration Planning”.
Fase 1: Inventario
La Fase 1 documenta lo stato attuale dell’infrastruttura dei gateway, la gestione del traffico, l’identità, l’ispezione TLS, le politiche e le integrazioni prima di qualsiasi attività di progettazione.
Infrastrutture
- Ogni gateway: modello, versione del software, ubicazione, ruolo e date di fine vita (per ProxySG ed Edge SWG, consultare l’articolo di Broadcom sul ciclo di vita)
- Volume di traffico e throughput massimo per sito, con percentuale di decrittografia TLS
- Numero di utenti per sito e per l'accesso remoto
- Concatenazione di proxy a monte e a valle, bilanciatori di carico e progettazione del failover
Gestione del traffico
- Impostazioni proxy esplicite, file PAC e WPAD
- Punti di intercettazione trasparenti (WCCP, instradamento basato su criteri)
- Tunnel da rami (IPsec, GRE)
- Agenti sugli endpoint
- Eccezioni relative alla vendita diretta su Internet
Identità
- Ambiti di autenticazione (SAML, Kerberos/IWA, LDAP, certificati client)
- Mappature di gruppo utilizzate nella politica
- Il traffico non autenticato (server, IoT, OT) e le modalità di gestione dello stesso
Ispezione TLS
- Certificato di ispezione, ubicazione chiave, data di scadenza e modalità di distribuzione
- Elenco delle eccezioni alla decrittografia con motivazioni e responsabili
Politica
- Esportazione completa del policy, compresi l’ordine delle regole, le categorie, gli elenchi personalizzati e le eccezioni
- Regole per le quali non sono stati registrati risultati negli ultimi 90 giorni (candidate alla dismissione)
Integrazioni
- Integrazioni di ICAP con DLP, antivirus e sandboxing
- Inoltro dei log a SIEM e strumenti di reportistica
- Monitoraggio e avvisi
Fase 2: Progettazione del bersaglio
La Fase 2 stabilisce dove verranno ispezionati i singoli siti e gruppi di utenti e in che modo verranno gestiti il traffico, i certificati e i registri.
- Stabilite dove verrà effettuato il controllo per ciascun sito e gruppo di utenti: in locale, nel cloud o in ambiente ibrido
- Si definisca il metodo di instradamento del traffico per ciascuna delle seguenti categorie: proxy esplicito o PAC per le reti gestite, agenti o controlli del browser per gli utenti in roaming, tunnel per le filiali
- Si prega di verificare la configurazione dell’ispezione TLS in modo che ogni flusso venga decrittografato una sola volta. Le linee guida della NSA raccomandano di effettuare l’ispezione una sola volta all’interno della rete aziendale ed evitare ispezioni ridondanti da parte di proxy collegati in serie (NSA)
- Capacità in termini di volume per la produttività massima dei picchi decriptati, oltre alla crescita
- Progettazione dell’alta disponibilità e del comportamento in caso di guasto
- Decidete dove archiviare i log e le prove relative al DLP
- Pianifichi la nuova CA di ispezione o il trasferimento di quella esistente e verifichi la compatibilità con i sistemi di archiviazione delle chiavi e l’eventuale integrazione con un HSM richiesta
Fase 3: Attuazione delle politiche
La Fase 3 traduce la politica esistente nella nuova piattaforma attraverso una mappatura strutturata e convalidata, anziché una conversione diretta dei file.
- Assegnare a ciascuna regola di origine la sua equivalente di destinazione, oppure contrassegnarla per la dismissione
- Mappare le categorie degli URL tra i fornitori e analizzare le differenze per le categorie di maggiore impatto
- Ricreare elenchi personalizzati, elenchi di autorizzazione ed elenchi di blocco
- Tradurre le regole subordinate all’autenticazione e confermare le mappature dei gruppi
- Ricreare le procedure di bypass della decrittografia e valutare se ciascuna di esse sia ancora necessaria
- Sostituire, ove possibile, i trasferimenti DLP basati su ICAP con il servizio di protezione dei dati proprio della piattaforma, verificando dove avvenga l’ispezione, oppure ristabilire le integrazioni
- Registri ogni modifica e ogni regola dismessa, indicandone il motivo, seguendo il proprio processo di controllo delle modifiche alla configurazione (il documento NIST SP 800-128 descrive le pratiche di gestione della configurazione incentrate sulla sicurezza)
Alcune piattaforme offrono la possibilità di importare in modo assistito le politiche esistenti. Consideri ogni importazione come un punto di partenza che richiede comunque una revisione e una verifica.
Fase 4: Preparazione del rollback
La Fase 4 definisce i fattori scatenanti e le modalità del rollback prima della fase pilota. Si effettui un test di rollback durante la fase pilota e si verifichi lo stato di preparazione prima di ogni fase di implementazione in produzione.
Trigger di rollback (esempi)
- Errori di autenticazione superiori a una soglia concordata
- Un’applicazione fondamentale per l’attività che rimane indisponibile per un periodo superiore a quello concordato
- Richieste di assistenza superiori a un multiplo prestabilito del valore di riferimento
- È stato accertato che i controlli di sicurezza non vengono applicati
Meccanismi di rollback
- Mantenete in servizio i vecchi gateway e applicate le patch fino al collaudo finale
- Si raccomanda di tenere traccia delle versioni delle modifiche apportate al file PAC, al DNS e al routing, in modo da poterle ripristinare
- Si tenga conto dei tempi di memorizzazione nella cache del DNS e del PAC nelle stime relative al rollback
- Si assicuri che la vecchia CA di ispezione continui a essere considerata attendibile sui dispositivi durante la transizione
- Stabilisca chi è autorizzato ad autorizzare un rollback e documenti la procedura
- Eseguire il rollback di prova durante la fase pilota e verificare lo stato di preparazione prima di ogni fase di migrazione
Fase 5: Progetto pilota
La Fase 5 prevede la gestione di un gruppo pilota rappresentativo sul nuovo portale, in parallelo con quello precedente, per almeno un ciclo economico.
- Selezionare utenti pilota che rappresentino i reparti chiave, le tipologie di dispositivi e le sedi, compreso il personale IT e alcuni utenti esperti dell’azienda
- Si metta in funzione il nuovo gateway in parallelo con quello precedente
- Indirizzi il traffico pilota verso il nuovo gateway tramite PAC, agenti o modifiche al routing che possano essere annullate rapidamente
- Fornite agli utenti del programma pilota un canale chiaro per segnalare eventuali problemi
- Mantenere il progetto pilota per almeno un ciclo economico completo, compresa la chiusura di fine mese, se del caso
Fase 6: Collaudo
La Fase 6 verifica ogni aspetto in cui gli utenti noteranno una differenza, dall’autenticazione alle prestazioni e al failover.
| Area di prova | Cosa verificare |
|---|---|
| Autenticazione | Gli utenti e i gruppi vengono identificati correttamente; il SSO funziona; il traffico di sistema non autenticato si comporta come previsto |
| Politica relativa alle categorie e agli URL | Le categorie “Consentito”, “Bloccato” e “Avviso” funzionano come nel codice sorgente |
| Ispezione TLS | Certificati riconosciuti come affidabili su tutti i dispositivi gestiti; la funzione di bypass funziona; le app fissate funzionano |
| Protezione dalle minacce | I campioni di malware di prova e gli URL noti come dannosi vengono bloccati |
| DLP | I documenti di test relativi a ciascuna classe di dati vengono individuati al momento del caricamento |
| Applicazioni aziendali | Le 50 principali applicazioni web e SaaS fondamentali per l’azienda: un approccio end-to-end |
| Prestazioni | I tempi di caricamento delle pagine e la larghezza di banda nei momenti di picco sono accettabili |
| Registrazione | Gli eventi giungono al SIEM con i campi previsti |
| Failover | Il guasto di un nodo gateway viene gestito senza alcun impatto per l'utente |
Fase 7: Transizione graduale
La Fase 7 prevede il trasferimento graduale degli utenti e dei siti al nuovo gateway, a ondate, a partire dai siti a minor rischio.
- Raggruppi gli utenti e i siti in ondate in base al rischio e alla complessità, iniziando dai siti a basso rischio
- Vi preghiamo di comunicare in anticipo ogni fase, indicando un referente di supporto
- Pianifichino le ondate al di fuori dei periodi critici per l’attività aziendale
- Assicurare la presenza di personale nella sala operativa durante le prime ore di ogni ondata
- Monitorare i ticket dell’help desk, i tassi di blocco e i tassi di errore rispetto ai valori di riferimento
- Fate una pausa tra un'ondata e l'altra per risolvere eventuali problemi prima di proseguire
Fase 8: Collaudo e dismissione
La Fase 8 conferma che i criteri di accettazione sono stati soddisfatti, dopodiché provvede alla dismissione dei vecchi gateway, certificati e contratti.
Criteri di accettazione (esempi)
- Tutti gli utenti e i siti sono stati migrati
- Il volume delle richieste all'helpdesk è tornato ai livelli normali da due settimane
- Tutti i casi di test hanno superato i controlli in produzione
- Registri e rapporti verificati dal reparto operativo di sicurezza e dal reparto di conformità
- Elenco delle eccezioni esaminato e approvato
Messa fuori servizio
- Rimuovere i vecchi gateway dai file PAC, dal routing e dal DNS
- Revocare e rimuovere la vecchia CA di ispezione dai dispositivi, qualora sia stata sostituita
- Archiviare i log obsoleti in base alla politica di conservazione
- Cancellare in modo sicuro i dati dall’hardware e smaltirlo
- Chiudere le licenze e i contratti di assistenza
Tempistiche tipiche
I tempi dipendono dalle dimensioni del patrimonio e dalla complessità della polizza.
Un’organizzazione con un’unica sede può completare una migrazione nel giro di poche settimane. Le grandi imprese con più sedi spesso procedono a un’implementazione parallela e a un’adozione graduale nell’arco di un periodo compreso tra sei e dodici mesi, secondo Skyhigh Security.
In che modo Skyhigh supporta la migrazione a SWG
Skyhigh supporta la migrazione da SWG grazie all’implementazione parallela, all’importazione convalidata delle politiche CPL e a modelli di implementazione flessibili.
Skyhigh Hybrid SSE Mesh viene implementato parallelamente ai gateway esistenti, in modo che le politiche possano essere convalidate sul traffico parallelo prima di qualsiasi passaggio definitivo. Skyhigh riformula le politiche CPL esistenti di Blue Coat nella propria console unificata delle politiche attraverso un processo di importazione convalidato, e le politiche vengono definite nella console cloud di Skyhigh. Le politiche relative alle applicazioni web e private possono essere applicate sul gateway on-premise, mentre il traffico che richiede una protezione dei dati applicata nel cloud viene inoltrato al cloud di Skyhigh. Gli utenti remoti vengono serviti tramite punti di presenza nel cloud. Skyhigh SWG funziona in locale, in modalità ibrida o nel cloud, pertanto la migrazione non impone un cambiamento nel modello di implementazione. Il programma di modernizzazione «Blue Coat » offre supporto per i servizi e un incentivo commerciale per i clienti idonei.
Fonti
- NSA. Gestione dei rischi derivanti dall’ispezione del protocollo TLS (novembre 2019). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
- NIST. SP 800-128: Guida alla gestione delle configurazioni dei sistemi informativi incentrata sulla sicurezza. https://csrc.nist.gov/pubs/sp/800/128/upd1/final
- Broadcom. Fine del ciclo di vita e ciclo di vita del prodotto per Edge SWG (ProxySG) e Advanced Secure Gateway (KB 151102). https://knowledge.broadcom.com/external/article/151102/end-of-life-and-product-lifecycle-for-pr.html
- Skyhigh Security. “Modernizzazione dell’ Secure Web Gateway Symantec Edge con Skyhigh Hybrid SSE Mesh” (15 luglio 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html
- Skyhigh Security. “L’adozione dell’ibrido è diventata più semplice grazie alla piattaforma Skyhigh SSE” (3 ottobre 2024). https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html