Con le funzionalità di IDFW (Identity Firewall), un amministratore di NSX può creare regole DFW (Distributed Firewall) Active Directory basate sull'utente.

È possibile utilizzare IDFW per sessioni di desktop virtuali (VDI), di desktop remoti (supporto RDSH) e macchine fisiche consentendo l'accesso simultaneo da parte di più utenti, l'accesso all'applicazione utente in base ai requisiti e la possibilità di mantenere ambienti utente indipendenti. I sistemi di gestione VDI controllano quali utenti possono accedere alle macchine virtuali VDI. NSX-T Data Center controlla l'accesso ai server di destinazione dalla macchina virtuale di origine in cui è abilitato IDFW. Con RDSH, gli amministratori creano gruppi di sicurezza con utenti diversi in Active Directory (AD) e consentono o negano a tali utenti l'accesso a un server delle applicazioni in base al loro ruolo. Ad esempio, Risorse umane e Ingegneria possono connettersi allo stesso server RDSH e accedere ad applicazioni diverse da quel server.

IDFW deve sapere a quale desktop un utente Active Directory (AD) accede per applicare le regole firewall. Ci sono due metodi che IDFW utilizza per il rilevamento degli accessi: Guest Introspection (GI) e/o lo scraping del registro eventi. Guest Introspection viene distribuito sui cluster ESXi in cui sono in esecuzione macchine virtuali IDFW. Quando gli eventi di rete vengono generati da un utente, un agente guest installato nella macchina virtuale inoltra le informazioni tramite il framework Guest Introspection a NSX Manager. La seconda opzione è la Active Directory programmatore del registro eventi. Lo scraping del registro eventi abilita IDFW per i dispositivi fisici. Configurare il gestore del registro eventi Active Directory in NSX Manager in modo che punti a un'istanza del controller di dominio Active Directory. NSX Manager estrarrà quindi gli eventi dal registro eventi di sicurezza AD.

Per le macchine virtuali è possibile utilizzare l'analisi degli eventi del relativo registro, tuttavia quando si utilizza sia il programma di analisi AD sia Guest Introspection, quest'ultimo avrà la precedenza sullo scraping del registro eventi. Guest Introspection è abilitata tramite VMware Tools e se si utilizza l'installazione completa di VMware Tools e IDFW, Guest Introspection avrà la precedenza sullo scraping del registro eventi.

IDFW può essere utilizzato anche su macchine virtuali con sistemi operativi supportati. Vedere Configurazioni supportate dal firewall di identità.

IDFW elabora l'identità dell'utente all'origine solo nelle regole del firewall. Solo il traffico proveniente dall'origine in cui viene elaborata l'identità utente sarà soggetto alle regole IDFW. I gruppi basati su identità non possono essere utilizzati come destinazione nelle regole del firewall.

Nota: IDFW si basa sulla sicurezza e sull'integrità del sistema operativo guest. Un amministratore locale malintenzionato può eseguire lo spoofing della propria identità in più modi per ignorare le regole firewall. Le informazioni sull'identità dell'utente vengono fornite dall'agente thin Guest Introspection NSX nelle macchine virtuali guest. Gli amministratori della sicurezza devono assicurarsi che l'agente thin sia installato e in esecuzione in ogni macchina virtuale guest. Gli utenti che hanno effettuato l'accesso non devono avere il privilegio di rimuovere o arrestare l'agente.

Le regole firewall basate sull'identità sono determinate dall'appartenenza a un gruppo Active Directory (AD). L'Unità organizzativa con un utente AD e l'Unità organizzativa con il gruppo AD in cui si trova l'utente devono essere entrambe aggiunte in Unità organizzative da sincronizzare affinché le regole IDFW funzionino. Per le configurazioni IDFW e i protocolli supportati, vedere Configurazioni supportate dal firewall di identità.

Le regole IDFW non sono supportate nei Global Manager in un ambiente di federazione. IDFW può comunque essere utilizzato in locale nei siti federati creando regole IDFW nei Local Manager.

Gruppi di criteri IDFW e logica di corrispondenza della regola DFW

Possono essere presenti due tipi di gruppi di criteri IDFW:
  • Gruppi omogenei con solo gruppi AD come membri del gruppo di criteri.
  • Gruppi eterogenei in cui possono essere presenti altri membri oltre ai gruppi AD, ad esempio macchine virtuali e indirizzi IP.
Le regole di sicurezza basate su gruppi di identità omogenei applicano la regola a tutte le macchine virtuali supportate da NSX in cui accede l'utente AD appartenente a uno dei membri del gruppo AD. Con i gruppi di identità eterogenei, il fondamento logico è la possibilità di creare origini più specifiche e precise per i criteri di sicurezza IDFW anziché origini ampiamente applicabili. Una regola di sicurezza in cui un gruppo di identità eterogeneo viene utilizzato nell'origine verrà applicata solo alle macchine virtuali che fanno parte del gruppo di criteri (staticamente o tramite un criterio dinamico o tramite l'assegnazione di indirizzo IP/intervallo) quando un utente AD appartenente ai gruppi AD membri effettua l'accesso. La regola è un'intersezione (operazione AND) delle macchine virtuali che sono membri del gruppo con le macchine virtuali in cui accedono gli utenti AD di destinazione.

È possibile trovare i membri effettivi di un gruppo eterogeneo di criteri di identità utilizzando la seguente logica:[Set di unione di tutti i membri non AD] AND. per esempio intersezione con [Set di macchine virtuali in cui accedono gli utenti AD appartenenti ai gruppi AD membri].

Esempio 1 - Membri della macchina virtuale statica insieme ai gruppi di AD come membri.
  • Intento: quando si associano alcune macchine virtuali in modo statico insieme a gruppi AD, lo scopo è applicare il criterio ai membri delle macchine virtuali statiche quando un utente AD appartenente ai gruppi AD vi accede.
  • Esempi di origine non applicabili: macchine virtuali in cui un utente AD appartenente a uno dei gruppi AD membri esegue l'accesso, ma che NON sono membri statici del gruppo di criteri. Macchine virtuali che sono membri statici del gruppo di criteri, ma l'utente che accede appartiene a gruppi AD NON membri del gruppo di criteri.
Esempio 2 - Criteri basati su nome dinamico per le macchine virtuali insieme a gruppi AD come membri.
  • Finalità: applicare un criterio di sicurezza SOLO alle macchine virtuali il cui nome corrisponde ai criteri quando un utente AD specifico accede a tali macchine.
  • Esempi di origine non applicabili: macchine virtuali in cui l'utente AD accede ma che non corrispondono ai criteri del nome. Macchine virtuali in cui i criteri del nome corrispondono, ma l'utente che accede non appartiene a uno dei gruppi AD membri.