Quando due amministratori aprono SmartConsole sullo stesso Security Management Server non stanno scrivendo nello stesso file: ognuno lavora dentro una propria sessione, e il sistema decide che cosa l’altro vede e quando lo vede. Capire quel meccanismo, e i permessi che lo governano, è il cuore di questo modulo.

La sessione privata: salvataggio, Publish, Discard

Una sessione nasce a ogni login in SmartConsole. Le modifiche che fai (un oggetto nuovo, una regola spostata, un commento) vengono salvate automaticamente, ma restano private: nessun altro amministratore le vede, e soprattutto non fanno parte della policy finché non le pubblichi.

Il ciclo è sempre lo stesso:

  • Publish, dalla toolbar di SmartConsole, rende le modifiche visibili agli altri amministratori e le rende candidabili all’installazione. Prima di pubblicare conviene risolvere gli errori di validazione segnalati.
  • Discard elimina tutto quello che hai fatto nella sessione corrente.
  • Session permette di assegnare alla sessione un nome e una descrizione: è così che il lavoro diventa tracciabile per chi guarderà l’elenco dopo.

Il punto che l’esame gira in molte forme: Publish e Install Policy sono due cose diverse. Publish scrive nel database di gestione; Install Policy manda la policy pubblicata ai Security Gateway. Le modifiche ancora private non entrano in un’installazione, nemmeno se la lanci tu.

Lock, sessioni altrui e Take over

Mentre lavori su un oggetto o su una regola, gli altri amministratori vedono un’icona di lucchetto su quell’elemento: è un lock che segnala che qualcuno ci sta lavorando in un’altra sessione. Non è un guasto da aggirare, è il modo in cui il sistema evita due modifiche contraddittorie sullo stesso oggetto.

L’elenco delle sessioni sta in Manage & Settings > Sessions > View Sessions, con proprietario, nome, descrizione e numero di modifiche. Che cosa puoi farci dipende dai permessi:

  • senza permessi particolari gestisci soltanto le tue sessioni;
  • con il permesso Manage Session puoi pubblicare, disconnettere e fare Take over della sessione di un altro amministratore. Il take over serve proprio a rimuovere i lock lasciati da chi non è raggiungibile.

Installazione concorrente della policy

Concurrent Install Policy permette a più amministratori di lanciare contemporaneamente attività di installazione diverse su gateway diversi: in precedenza era possibile eseguire in parallelo soltanto la stessa attività. I limiti da ricordare:

  • fino a cinque installazioni diverse in parallelo; le richieste successive vengono messe in coda;
  • sono supportate le policy Access Control e Threat Prevention, non Desktop e QoS;
  • alla prima installazione non puoi installare sullo stesso gateway Access Control e Threat Prevention nello stesso momento.

L’avanzamento si segue nella finestra Recent Tasks, in basso a sinistra.

Profili di permessi e account amministratore

Gli account si creano e si modificano in Manage & Settings > Permissions & Administrators. Per ogni amministratore scegli un metodo di autenticazione (Check Point Password, OS Password, RADIUS, TACACS, SecurID, API Key per il solo accesso alle Management API, SAML verso un identity provider esterno), un permission profile e una scadenza dell’account.

I profili predefiniti sono tre e non si modificano né si cancellano:

  • Read Only All: sola lettura su tutto;
  • Read Write All: lettura e scrittura su tutto;
  • Super User: lettura e scrittura più la gestione di amministratori e sessioni.

Per qualsiasi altra esigenza si clona un profilo predefinito oppure si crea un profilo Customized, in cui i permessi si assegnano per categoria (Gateways, Access Control, Threat Prevention, Monitoring, Events e funzioni di gestione) con la distinzione fra Read e Write dove è prevista.

Una nota che vale un punto: creare amministratori con cpconfig è sconsigliato, perché supporta solo Check Point Password, richiede il riavvio dei servizi e non mostra gli altri amministratori già definiti.

Trappole tipiche d’esame

  • Permessi sbagliati, per eccesso o per difetto. Read Write All non è Super User: chi deve fare take over o pubblicare la sessione di un collega ha bisogno del permesso di gestione delle sessioni, quindi Super User o un profilo Customized che lo includa. L’errore speculare, altrettanto penalizzato negli scenari, è assegnare Super User a chi deve solo modificare regole.
  • Trattare il lucchetto come un errore. Un oggetto bloccato non si forza: o l’altro amministratore pubblica o scarta, oppure serve un take over da parte di chi ne ha il permesso.
  • Sessioni lasciate aperte. Chi chiude il portatile senza pubblicare né uscire lascia lock attivi e modifiche invisibili. Il sintomo classico nelle domande scenario è “ho modificato la regola ma il gateway continua a comportarsi come prima”: quasi sempre la sessione non è stata pubblicata, oppure è stata pubblicata ma la policy non è stata installata.
  • Confondere Publish con Install Policy, in entrambe le direzioni: pubblicare non protegge nulla, e installare non porta con sé le modifiche private di un altro amministratore.
  • Leggere male Concurrent Install Policy. Il parallelismo riguarda attività diverse, il tetto è cinque con coda oltre quel numero, e Desktop e QoS restano fuori.