Benvenuti alla decima lezione, un evento speciale. Oggi parleremo di un altro blade di Check Point — Identity Awareness. Sin dall'inizio, quando abbiamo descritto il NGFW, abbiamo definito che è fondamentale avere la possibilità di regolare l'accesso basandosi su account utente anziché sugli indirizzi IP. Questo è particolarmente legato all'aumentata mobilità degli utenti e alla diffusione del modello BYOD — bring your own device. In azienda ci possono essere molte persone che si connettono tramite WiFi, ricevono IP dinamici e provengono da diverse segmenti di rete. Prova a creare delle liste di accesso basate sugli IP. Qui, senza l'identificazione degli utenti, è impossibile procedere. Ed è proprio il blade di Identity Awareness che ci aiuta in questo.
Ma prima, capiamo a cosa serve più frequentemente l'identificazione degli utenti?
- Per limitare l'accesso alla rete in base agli account utente invece che agli indirizzi IP. L'accesso può essere regolato non solo a Internet, ma anche a qualsiasi altro segmento di rete, come il DMZ.
- Accesso a VPN. Concordate che per un utente sia molto più comodo utilizzare il proprio account di dominio per l'autenticazione piuttosto che un'altra password inventata.
- Per gestire Check Point è necessaria anche un'account, che può avere diversi diritti.
- E la parte più interessante — la reportistica. È molto più gratificante vedere nei rapporti gli utenti specifici piuttosto che i loro indirizzi IP.
Inoltre, Check Point supporta due tipi di account:
- Local Internal Users. L'utente viene creato nel database locale del server di gestione.
- External Users. Può essere utilizzato come database esterno Microsoft Active Directory o qualsiasi altro server LDAP.
Oggi parleremo dell'accesso alla rete. Per gestire l'accesso alla rete, in presenza di Active Directory, viene utilizzato il cosiddetto Access Role, che consente di utilizzare tre parametri dell'utente:
- Network log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats timeout 30s user haproxy group haproxy daemondefaults log global mode http option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000frontend http_front bind *:80 stats uri /haproxy?stats default_backend http_backbackend http_back balance roundrobin server server_name1 private_ip1:80 check server server_name2 private_ip2:80 check — cioè la rete da cui l'utente sta tentando di connettersi
- AD User o User Group — questi dati vengono estratti direttamente dal server AD
- Machine — la stazione di lavoro.
L'identificazione degli utenti può avvenire in diversi modi:
- AD Query. Check Point legge i log del server AD riguardo agli utenti autenticati e ai loro indirizzi IP. I computer che si trovano nel dominio AD vengono identificati automaticamente.
- Browser-Based Authentication. Identificazione tramite il browser dell'utente (Captive Portal o Transparent Kerberos). Questo è comunemente usato per dispositivi non facenti parte del dominio.
- Terminal Servers. In questo caso, l'identificazione avviene tramite un agente terminale speciale (installato sul server terminal).
Questi sono i tre metodi più comuni, ma ce ne sono altri tre:
- Identity Agents. Viene installato un agente speciale sui computer degli utenti.
- Identity Collector. Un'utility separata installata su Windows Server che raccoglie i log di autenticazione al posto del gateway. È praticamente necessario in caso di un gran numero di utenti.
- RADIUS Accounting. E chiaramente ci vuole il vecchio e caro RADIUS.
In questa lezione dimostrerò il secondo metodo — Browser-Based. Penso che sia abbastanza teoria, passiamo alla pratica.
Video tutorial
Resta sintonizzato per ulteriori aggiornamenti e unisciti al nostro 🙂
Fonte: habr.com
