Architettura di Cisco ISE: personas e tipi di nodo

Cisco ISE non è un singolo software monolitico, ma una piattaforma distribuita costruita attorno al concetto di persona. Comprendere come le personas si mappano sui nodi è il fondamento su cui poggia ogni scelta di design (e buona parte delle domande dell’esame SISE).

Nodo, persona e ruolo: tre concetti distinti

Un nodo è un’istanza ISE installata: appliance fisica (serie SNS) o virtuale. Ogni nodo esegue una o più personas, cioè le funzioni logiche che il nodo svolge nel deployment. Il ruolo (primary/secondary) descrive invece la relazione di alta disponibilità tra due nodi che condividono la stessa persona.

La distinzione è precisa:

• Persona = quale funzione svolge il nodo (Administration, Monitoring, Policy Service, pxGrid).
• Ruolo = chi comanda fra due nodi con la stessa persona (primary o secondary).

Primary/secondary si applicano solo alle personas Administration, Monitoring e pxGrid. I PSN non hanno ruolo primary/secondary: sono tutti attivi e lavorano in parallelo.

Le quattro personas

Administration (PAN — Policy Administration Node)

È l’unico punto da cui si configura tutto: policy set, identity source, profili di autorizzazione, sponsor portal. Il PAN primario detiene la copia master del database di configurazione e la replica verso tutti gli altri nodi. Il PAN secondario resta in standby: subentra solo dopo una promozione (manuale o automatica con Auto‑Failover). Nessun traffico RADIUS live passa dal PAN.

Monitoring (MnT — Monitoring & Troubleshooting)

Raccoglie log, report, alarm e i RADIUS Live Logs. Riceve i syslog da PSN e Network Access Device e funge da data warehouse per il troubleshooting. Anche qui esistono un MnT primary e uno secondary: entrambi raccolgono log contemporaneamente (duplicazione dei dati), ma solo il primario è quello interrogato di default.

Policy Service (PSN — Policy Service Node)

È il motore operativo. Termina le sessioni RADIUS e TACACS+, valuta authentication e authorization, esegue profiling, posture, guest, client provisioning e BYOD. È il PSN — e solo il PSN — che dialoga in RADIUS con i NAD (switch, WLC, firewall come Firepower). Il NAD punta all’indirizzo del PSN come RADIUS server:

radius server ISE-PSN-01
 address ipv4 10.1.1.21 auth-port 1812 acct-port 1813

Il PSN riceve l’Access‑Request, valuta la policy contro gli identity store e restituisce Access‑Accept/Reject con i risultati (dACL, VLAN, SGT). In produzione si mettono più PSN dietro un load balancer o si elencano più PSN sul NAD per ridondanza.

pxGrid

È il bus di context sharing publish/subscribe: condivide informazioni di sessione e contesto con l’ecosistema di sicurezza (Firepower/FMC, Stealthwatch, sistemi di terze parti). Non partecipa all’autenticazione RADIUS; abilita la remediation coordinata. Anche pxGrid supporta active/standby.

Standalone vs distribuito

La regola chiave: quando PAN e MnT girano su nodi dedicati, il deployment scala fino a 50 PSN; se PAN e MnT sono co‑locati con il PSN, il numero massimo di PSN crolla. La capacità in numero di endpoint concorrenti dipende dai PSN (e dalla taglia dell’appliance), non dal PAN.

Trappole tipiche d’esame

• Scenario: “Serve un nodo che gestisca i report e i Live Logs di autenticazione.” → Risposta giusta: MnT (Monitoring), non PAN. Il PAN configura, il MnT osserva.
• Scenario: “Le autenticazioni RADIUS dai NAD falliscono anche se il PAN è raggiungibile.” → Il NAD deve puntare al PSN, non al PAN o al MnT: solo il PSN termina RADIUS.
• Scenario: “Il numero di endpoint è cresciuto e le sessioni saturano.” → Si aggiungono/scalano i PSN; non serve un PAN più grande. Il dimensionamento endpoint dipende dai PSN.
• Scenario: “Voglio HA per la configurazione.” → Si aggiunge un PAN secondary (ruolo), non una seconda persona Administration su nodi a caso. Ricorda che i PSN non hanno primary/secondary.
• Scenario: “Devo condividere il contesto di sessione con Firepower per la remediation.” → Persona pxGrid, non una nuova policy sul PSN.