Ogni destinazione consentita è esplicita, attribuibile e verificabile
Sentinel governa l’accesso HTTP e HTTPS verso Internet di server e workload gestiti. Una policy default deny consente soltanto le destinazioni approvate per ciascuna sorgente; le modifiche vengono valutate, approvate, versionate e distribuite ai proxy attraverso bundle firmati.
- Default deny per server, gruppi e sorgenti esplicite
- Policy firmate, versionate e soggette ad approvazione
- Applicazione delle policy indipendente dal piano di controllo
Gestione delle policy di accesso a Internet
Il traffico in uscita attraversa un punto di controllo dedicato: la sorgente, la destinazione e la ragione dell’accesso diventano elementi espliciti della policy.
Sorgenti identificate
Le regole si applicano a singoli host, gruppi oppure a intervalli di rete dichiarati esplicitamente. Gli oggetti possono essere gestiti localmente o sincronizzati in sola lettura da un inventario esterno.
Destinazioni normalizzate
I domini esatti e wildcard vengono normalizzati prima della registrazione. La gestione degli IDN segnala la presenza di alfabeti misti e caratteri confondibili prima dell’inserimento di una destinazione nella policy.
Proxy ad alta disponibilità
Due o più nodi Squid applicano la configurazione attraverso un indirizzo virtuale. Ogni nodo conosce la generazione e l’impronta della policy attiva, così lo stato del cluster resta verificabile.
Destinazioni approvate
Le richieste conformi alla policy vengono inoltrate; quelle non previste vengono bloccate dalla regola predefinita. Un ordine di precedenza deterministico governa sia le regole definite dagli amministratori sia i blocchi derivati dalla threat intelligence.
Regole precise, temporanee e approvate
Sentinel tratta ogni modifica come una decisione di sicurezza: ne definisce il perimetro, calcola il rischio e collega ogni approvazione alle variazioni che verranno effettivamente applicate.
Durata come parte della policy
Le regole possono avere decorrenza e scadenza. Le autorizzazioni scadute non vengono compilate; il rinnovo costituisce una nuova modifica, valutata secondo il rischio corrente e registrata nell’audit.
Rischio calcolato dal server
Ampiezza degli intervalli di rete, wildcard, durata e caratteristiche del dominio determinano la classe di rischio. Il calcolo viene ripetuto sul contenuto effettivo della modifica, senza affidarsi a un valore dichiarato dall’interfaccia.
Approvazioni vincolate alla modifica
Le modifiche a rischio elevato richiedono l’approvazione di una persona diversa da chi le propone; quelle critiche richiedono due approvazioni e una nuova autenticazione. Qualsiasi variazione invalida le approvazioni precedenti.
Dalla modifica alla configurazione applicata
Una sola rappresentazione della policy alimenta analisi, compilazione e versionamento. La distribuzione conserva la relazione fra ciò che è stato approvato e ciò che ogni nodo applica.
Compilazione deterministica
Ordinamenti espliciti, formati canonici e identificatori stabili producono una configurazione identica a parità di policy. L’analisi delle ridondanze utilizza la stessa rappresentazione impiegata dal compilatore.
Validazione dedicata
Il bundle completo viene sottoposto a controlli strutturali e alla validazione della sintassi Squid prima della firma. Il servizio di validazione dispone di privilegi separati da quelli dell’API pubblica.
Firma e protezione anti-replay
Il manifesto Ed25519 collega generazione, impronta del bundle e compatibilità dell’agente. I nodi accettano soltanto contenuti integri, firmati da una chiave autorizzata e con generazione strettamente crescente.
Attivazione atomica
L’agente prepara la nuova generazione in un percorso separato, la verifica localmente e la attiva con un’unica sostituzione atomica. In caso di errore rimane operativa l’ultima configurazione valida.
Continuità operativa in caso di indisponibilità del piano di controllo
Il piano di controllo governa le modifiche, ma non è necessario per applicare una policy già accettata. I nodi continuano a utilizzare l’ultima configurazione valida durante il ripristino dell’API, del database o del repository Git.
Stato verificabile del cluster
Lo stato operativo dei nodi, l’assegnazione dell’indirizzo virtuale, la generazione e l’impronta applicate determinano se il cluster può ricevere una nuova policy. Eventuali divergenze bloccano le installazioni ordinarie e richiedono il riallineamento del cluster.
Ripristino mediante il normale processo di distribuzione
Il ripristino di una versione precedente produce una nuova generazione firmata, senza riutilizzare un bundle già distribuito. Le versioni conservano copie complete della policy e la configurazione corrente viene archiviata prima del recupero.
Threat intelligence, inventario e SIEM
Sentinel si integra con le fonti informative relative all’infrastruttura, alle identità e al rischio, conservando per ciascun dato l’indicazione della provenienza e dei controlli applicati.
Identità e autorizzazioni
La console utilizza il provider OIDC aziendale e assegna permessi granulari alle diverse operazioni. Consultazione, modifica, approvazione, installazione, recupero, gestione dei nodi, audit ed evidenze rimangono autorizzazioni distinte.
Inventario in sola lettura
Gli host importati mantengono l’identità stabile del sistema sorgente. Rimozioni o variazioni di indirizzo relative a oggetti già utilizzati vengono sottoposte a revisione ed escluse dalla compilazione fino alla decisione dell’operatore.
Provenienza degli indicatori di reputazione
Gli indicatori vengono normalizzati, associati alla fonte e soggetti a scadenza. I blocchi derivati da indicatori con elevata attendibilità precedono le regole definite dagli amministratori e restano riconoscibili nella policy, nel riepilogo delle modifiche e nell’interfaccia.
Eventi trasmessi al SIEM
Le operazioni sensibili e gli esiti della distribuzione vengono strutturati per la trasmissione al SIEM esterno. Una coda locale, nuovi tentativi programmati e il monitoraggio della consegna assicurano la continuità del flusso.
Audit ed evidenze verificabili
La cronologia tecnica collega le decisioni alle configurazioni distribuite e allo stato rilevato sui nodi. Le evidenze distinguono le attività di progettazione, implementazione, test e verifica svolte nell’ambiente operativo.
Audit a prova di manomissione
Gli eventi sono concatenati tramite hash e possono essere verificati in modo deterministico. Proposta, approvazione, installazione, recupero, variazioni dei nodi e tentativi di applicare bundle non validi lasciano una traccia strutturata.
Versioni complete della policy
Ogni distribuzione conserva la policy ripristinabile, il manifesto, l’impronta del bundle, la generazione e il riferimento alla cronologia Git protetta. Il riepilogo delle modifiche resta collegato alla configurazione applicata.
Livelli di evidenza
Il registro dei controlli separa progettazione, implementazione, test automatici e verifiche in ambienti di collaudo o produzione. Ogni avanzamento richiede riferimenti coerenti con il livello dichiarato.
Controlli operativi ripetibili
Una procedura diagnostica verifica database, migrazioni, catena di audit, nodi, policy applicata, indirizzo virtuale, chiavi, fonti informative, backup, copia del repository Git, integrazioni e configurazione di sicurezza, producendo esiti strutturati.
Perimetro operativo
Sentinel concentra il controllo dell’egress dei sistemi gestiti in un servizio dedicato, integrabile con l’infrastruttura e con i processi di sicurezza già adottati.
Server e workload gestiti
Il perimetro comprende sistemi applicativi, macchine virtuali e workload il cui traffico HTTP/HTTPS in uscita deve rispettare autorizzazioni definite per sorgente e destinazione.
Console, API e interfaccia a riga di comando
La console comprende policy, riepiloghi delle modifiche, approvazioni, traffico, threat intelligence, nodi, versioni, recupero, audit ed evidenze. L’API e l’interfaccia a riga di comando utilizzano gli stessi controlli applicativi.
Ambienti dedicati e ibridi
Il piano di controllo e i proxy vengono installati su infrastruttura dedicata, con identità, inventario, SIEM, monitoraggio e gestione delle chiavi collegati secondo l’architettura del cliente.
Modalità di installazione
DEC definisce il perimetro, installa i componenti, integra i sistemi esterni e prepara le procedure operative insieme al team responsabile dell’infrastruttura.
Architettura dedicata
Piano di controllo, database, repository delle policy, servizio di firma, proxy e indirizzo virtuale vengono dimensionati e segmentati secondo il numero di sorgenti, la disponibilità richiesta e i confini di rete esistenti.
Messa in esercizio verificabile
La consegna comprende configurazione, importazione iniziale degli oggetti, integrazioni, ruoli, procedure di approvazione, backup, ripristino e controlli operativi. Le prove svolte nell’ambiente vengono associate al livello di evidenza raggiunto.
Valutazione del controllo dell’egress
DEC può esaminare sorgenti, destinazioni, flussi HTTP/HTTPS, inventario, identità, processi di approvazione, requisiti di disponibilità e integrazioni per definire un perimetro verificabile di Sentinel.