Di Jeff Ebeling - Architetto della sicurezza del cloud, Skyhigh Security
9 luglio 2024 4 Minuti di lettura
Skyhigh Client Proxy (SCP) è uno strumento estremamente prezioso a disposizione di tutti i clienti Skyhigh Secure Web Gateway (SWG). Viene utilizzato per autenticare e reindirizzare in modo trasparente il traffico HTTP/S verso i Secure Web Gateway di Skyhigh (SWG On Prem e/o SWG Cloud). Oltre a identificare l'utente che ha chiamato il processo che effettua la richiesta web, SCP fornisce un contesto aggiuntivo che può essere utilizzato per prendere decisioni più intelligenti in materia di filtraggio proxy e di connessione! Inoltre, come descritto più avanti in questo blog tecnico, l'SCP può essere utilizzato e i suoi vantaggi possono essere realizzati indipendentemente dalla posizione di Skyhigh SWG in una catena di proxy.
Per iniziare, consulti la Guida al prodotto SCP e in particolare la sezione che descrive il contesto fornito nelle intestazioni SCP(Metadati SCP). Le intestazioni fornite da SCP includono:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ulteriori note sulle intestazioni SCP (intestazioni SWEB) sono riportate più avanti in questo blog.
Ovviamente SCP funziona perfettamente con Skyhigh SWG, ma cosa succede se Skyhigh SWG (Cloud o On Prem) deve fungere da proxy genitore di un proxy di terze parti già utilizzato nell'ambiente, o se Skyhigh SWG viene utilizzato solo come servizio di filtraggio collegato a un proxy di decrittografia di terze parti? Questo articolo descrive come realizzare il pieno valore di SCP in qualsiasi ambiente che includa Skyhigh SWG.

In questo caso d'uso, l'autenticazione viene eseguita facoltativamente su un proxy di decriptazione per il traffico consapevole del proxy. Ciò consente una vera autenticazione con Kerberos, NTLM, LDAP, SAML, ecc. se supportata dal proxy di decriptazione. SCP offre anche un modo per "autenticare" il traffico che non è consapevole del proxy. Indipendentemente dall'autenticazione, il contesto fornito da SCP può essere utilizzato sia dal proxy di decriptazione che da Skyhigh SWG. Il proxy di decriptazione può verificare le intestazioni SWEB fornite da SCP tramite una chiamata in banda laterale a Skyhigh SWG on-Prem (esempio di regole mostrato di seguito) e quindi utilizzare il contesto nelle decisioni di connessione e filtraggio. Ad esempio, il contesto fornito da SCP potrebbe essere utilizzato per decidere se consentire la connessione, se decriptare o meno, o anche se avviare una vera autenticazione. Il proxy di decriptazione può anche semplicemente inoltrare le intestazioni SWEB fornite da SCP a SWG, in modo che il contesto aggiunto possa essere utilizzato nelle regole di SWG. F5 ha pubblicato una guida all'integrazione per questa architettura.

In questo caso d'uso, non c'è alcun requisito per decriptare al primo proxy. La vera autenticazione può ancora essere eseguita tramite il primo proxy, utilizzando l'autenticazione proxy tramite i codici di stato 407. SCP è in grado di intercettare le richieste HTTP/S dirette o proxy e di effettuare richieste proxy esplicite a un proxy locale Skyhigh o di terze parti. L'intercettazione del traffico già proxyato consente a SCP di operare con successo nelle "reti sicure" che non hanno un percorso predefinito e/o i server DNS non risolvono gli indirizzi esterni. SCP fornisce un metodo per autenticare il traffico che non è consapevole del proxy. Questa architettura offre una semplice "rampa di accesso" a Skyhigh SSE, consentendo una funzionalità di gran lunga superiore rispetto a qualsiasi proxy locale attualmente in uso. Inoltre, SCP aggiunge un'opzione di proxy trasparente per Windows e Mac, per coprire le applicazioni che non sono consapevoli del proxy e sono in esecuzione in ambienti con proxy esplicito. Tutto ciò che il proxy figlio deve fare è "fare un salto successivo" al traffico SCP verso il SWG Skyhigh (Cloud o On Prem), lasciando intatte le intestazioni SWEB.
SCP fornisce tutte le informazioni contestuali tramite le intestazioni SWEB inserite nella richiesta CONNECT per le transazioni HTTPS o nelle richieste dei singoli metodi per le transazioni HTTP. I comandi all'interno di una connessione proxy HTTPS accettata NON ricevono intestazioni. Quando SWG verifica le intestazioni SWEB, le rimuove per impostazione predefinita (la disabilitazione della rimozione fa parte delle impostazioni di autenticazione SWPS utilizzate quando si valuta la proprietà Authentication.Authenticate in Skyhigh SWG).
Le intestazioni SWEB codificate Base64 generate da SCP vengono prima crittografate con il segreto condiviso del tenant incluso come parte delle policy SCP generate in Skyhigh Cloud o Trellix ePO. L'inquilino viene identificato mediante l'intestazione ID cliente SWEB. Un proxy di terze parti non può decriptare le intestazioni SWEB e sarà in grado di inoltrare solo le intestazioni fornite da SCP.
Skyhigh SWG (quando agisce come proxy di decriptazione) mantiene il contesto SWG per tutta la durata della connessione HTTPS. Quando utilizza Next Hop Proxy verso il cloud Skyhigh SWG da Skyhigh SWG On Prem con l'impostazione Secure Channel abilitata, alcune intestazioni SWEB vengono sempre aggiunte automaticamente. Le intestazioni aggiunte automaticamente sono: CustomerID, Username (Authentication.Username) e Gruppi (Authentication.UserGroups). Le intestazioni SWEB generate da SWG sono crittografate da Skyhigh SWG On Prem con le credenziali (ID cliente e Shared Secret) che fanno parte della configurazione di UCE Hybrid. Se si utilizza SCP per la connessione diretta a qualsiasi proxy, tutte le intestazioni SWEB sono naturalmente incluse.
SCP è l'identificazione dell'utente più che l'autenticazione; una chiamata di sistema raccoglie il nome utente e i gruppi associati al chiamante del processo, dal momento dell'accesso, i gruppi saranno attuali solo a partire dall'ultima connessione alla directory client.
Scopra come la sua organizzazione può utilizzare Secure Web Gateway e Skyhigh Client Proxy per proteggere i sistemi e i dati dei suoi dipendenti, ottenendo una maggiore visibilità e un controllo più granulare del traffico HTTP e HTTPS.
Torna ai blogSarang Warudkar 18 febbraio 2026
Niharika Ray e Sarang Warudkar 12 febbraio 2026
Thyaga Vasudevan 21 gennaio 2026
Jesse Grindeland 18 dicembre 2025
Thyaga Vasudevan 12 dicembre 2025