Un firewall che non sa chi sei può solo tirare a indovinare. Identity Awareness è il Software Blade con cui Check Point chiude questa distanza, e la prima cosa che l’esame CCSA verifica non è come si configura, ma quale problema risolve e che cosa cambia — nelle regole e nei log — quando è attivo.

Il limite di una regola scritta sugli indirizzi

La documentazione R82 definisce Identity Awareness come un Software Blade su un firewall Check Point che applica l’accesso alla rete e registra i dati in base alla posizione di rete, all’identità dell’utente e all’identità del computer. Le tre dimensioni convivono: la posizione di rete non sparisce, le altre due si aggiungono.

Senza il blade, «consenti al reparto amministrazione di raggiungere il gestionale» deve per forza diventare «consenti a quella subnet». La traduzione ha due difetti strutturali. È imprecisa, perché chiunque ottenga un indirizzo di quella subnet eredita il permesso: il portatile di un fornitore, una stampante riassegnata, un ospite finito sulla rete sbagliata. Ed è fragile, perché il legame fra persona e indirizzo si rompe ogni volta che qualcuno cambia postazione, riceve un altro indirizzo dal DHCP o entra in VPN. La regola continua a esistere e a sembrare corretta: semplicemente non descrive più la realtà che voleva descrivere.

Lo stesso vale per la tracciabilità: un log che nomina soltanto un indirizzo costringe a una seconda indagine — chi lo aveva, a quell’ora — spesso non più ricostruibile a posteriori.

Che cosa aggiunge il blade

Con Identity Awareness attivo il gateway associa a un indirizzo un’identità: un utente, un computer, o entrambi. Da quel momento l’identità è disponibile nei due punti che valgono la maggior parte delle domande d’esame.

Nelle regole: gli Access Role sono oggetti utilizzabili nelle colonne Source e Destination delle regole di Access Control Policy, quindi una regola può dire davvero «gli utenti di quel gruppo», indipendentemente dall’indirizzo che hanno oggi.

Nei log: dopo l’installazione della policy, i log in SmartConsole mostrano l’identità di utenti e computer nella scheda Logs & Events, con il profilo di colonne Access Control.

L’identità, inoltre, non resta confinata al firewall: viene usata anche dagli altri blade, a partire da Application Control e URL Filtering, che possono così distinguere chi sta usando un’applicazione e non solo che l’applicazione è stata usata.

Scegliere la fonte fa parte dello scopo

Identity Awareness non è un meccanismo unico: è un insieme di Identity Sources che alimentano la stessa decisione. Il punto che l’esame verifica è che la fonte si sceglie in base all’obiettivo.

La documentazione R82 indica AD Query per logging e auditing con enforcement di base; la coppia AD Query e Browser-Based Authentication quando servono anche gli utenti non Windows; gli Identity Agent con Browser-Based Authentication quando serve un livello di sicurezza alto, per esempio a protezione dei server di un data center; il Terminal Servers Identity Agent dove più utenti arrivano dallo stesso indirizzo, come negli ambienti Terminal Server e Citrix; Remote Access per identificare i client VPN in Office Mode; RADIUS Accounting dove l’autenticazione passa da un server RADIUS; Identity Collector negli ambienti su larga scala con domain controller Microsoft Active Directory. La Browser-Based Authentication, nella sua forma Captive Portal, è indicata per gli utenti non AD e per gli ospiti, ed è il ripiego quando gli altri metodi non riescono a identificare qualcuno.

Dietro le fonti c’è una separazione di ruoli che conviene fissare subito: il Policy Decision Point, o PDP, gestisce la logica di acquisizione delle identità ed è il punto di terminazione delle varie fonti, autentica e interroga l’appartenenza ai gruppi; il Policy Enforcement Point, o PEP, riceve le identità dal PDP e applica al traffico la logica di enforcement basata su identità.

Attivare il blade è un’operazione guidata: in SmartConsole si apre Gateways & Servers, si apre l’oggetto gateway, scheda Network Security, e il wizard propone Methods For Acquiring Identity e l’integrazione con Active Directory. Altre fonti si aggiungono dopo.

Trappole tipiche d’esame

  • Attivare il blade non produce identità. Dopo il wizard va installata la Access Control Policy: finché non lo fai, i log non mostrano utenti e le regole basate su identità non hanno nulla su cui lavorare. Uno scenario che descrive «blade abilitato, nessun utente nei log» ha spesso qui la risposta.
  • La fonte sbagliata per lo scopo giusto. AD Query rileva solo utenti e computer di Active Directory: ospiti, dispositivi mobili e macchine fuori dominio restano anonimi per costruzione, non per un errore di configurazione. Se la traccia parla di utenti non identificati e l’unica fonte attiva è AD Query, il difetto è la scelta della fonte, non la regola.
  • Identificare non è applicare. AD Query è raccomandata per logging e auditing con enforcement di base: vedere il nome di un utente in un log non dimostra che una regola lo stia usando per decidere. Le due cose si verificano separatamente.
  • Se il PDP non riceve, il PEP non applica. Le identità arrivano al gateway attraverso i sistemi di autenticazione: quando la comunicazione con il domain controller, con il server RADIUS o con l’agent non funziona, il sintomo visibile è una regola che non scatta. Prima di riscrivere la regola si verifica che l’identità stia davvero arrivando.
  • Identity Awareness non è l’autenticazione degli amministratori. Chi entra in SmartConsole si governa con i permission profile: è un altro capitolo. Qui si parla degli utenti del traffico che attraversa il gateway.