Un account amministratore SmartConsole non serve solo a far entrare qualcuno: decide chi risponde di una modifica, con quale credenziale entra, da quale postazione e fino a quando. L’esame ci costruisce sopra scenari in cui tutto sembra corretto tranne un dettaglio dell’account.

Amministratori SmartConsole, non utenti di Gaia

La prima distinzione da fissare è quale utenza si sta guardando. L’utente di Gaia, quello con cui si entra nel Gaia Portal o in Gaia Clish, appartiene al sistema operativo della singola macchina e serve a configurarla. L’amministratore SmartConsole vive invece nel database del Security Management Server e serve a gestire oggetti, policy e log di tutto l’ambiente. Due elenchi separati, due scopi separati: il fatto che il primo account si chiami admin in entrambi i mondi è esattamente ciò che rende ambigua la domanda d’esame.

Gli account SmartConsole si creano e si modificano in Manage & Settings > Permissions & Administrators. Da lì si sceglie il metodo di autenticazione, si assegna un permission profile e si può impostare una Expiration Date, cioè una scadenza oltre la quale l’account non consente più l’accesso. La documentazione consiglia anche una pratica che le domande premiano: accanto all’account con pieni poteri conviene “create a second administrator account with Read Only permissions”, da usare per consultare senza rischiare di cambiare.

I tipi di account: come si autentica un amministratore

Il “tipo” di un amministratore, all’esame, coincide con il suo Authentication Method. La guida R82 ne elenca sette selezionabili nella scheda dell’account, più uno aggiuntivo:

  • Check Point Password: password gestita dal Management Server, la scelta autonoma che non dipende da nulla di esterno.
  • OS Password: la password dell’utente del sistema operativo della macchina di gestione.
  • RADIUS, TACACS, SecurID: delega dell’autenticazione a un server esterno già presente in azienda.
  • API Key: pensata per l’accesso programmatico alle Management API, non per chi digita credenziali in una finestra di login.
  • SAML: l’amministratore viene autenticato da un Identity Provider esterno e, come scrive la documentazione, non è necessario inserire credenziali in SmartConsole.
  • In aggiunta o in alternativa a uno di questi metodi si può configurare l’autenticazione con file di certificato: la guida precisa “Alternatively, or in addition to one of the above authentication methods, you can configure certificate file authentication”.

Il criterio di scelta è di sostanza, non di gusto: un account umano quotidiano si appoggia alla directory aziendale, un account destinato all’automazione usa una API Key, un account di emergenza usa una Check Point Password che resta valida anche se il server esterno non risponde.

Che cosa un account può fare: profili e Trusted Clients

A ogni amministratore si assegna un Permission Profile, che si sceglie aprendo l’account con un doppio clic e selezionando il profilo nella sezione Permissions. I predefiniti sono tre, con le descrizioni della documentazione:

  • Read Only All — “Full Read Permissions. No Write permissions.”
  • Read Write All — “Full Read and Write Permissions.”
  • Super User — “Full Read and Write Permissions, including managing administrators and sessions.”

Sono immutabili: “You cannot change or delete the default permission profiles. You can clone them, and change the clones”. Qualunque esigenza intermedia si soddisfa clonando un profilo e modificando il clone.

All’account si affianca infine il perimetro di provenienza. I Trusted Clients, in Manage & Settings > Permissions & Administrators > Trusted Clients, limitano “the access to the Security Management Server from a specified list of hosts” e si esprimono come indirizzo IPv4 o IPv6, intervallo, netmask, nome host o wild card. Il valore predefinito è Any, cioè tutti gli host, e solo un amministratore Super User può aggiungerli, modificarli o eliminarli.

Trappole tipiche d’esame

  • Super User assegnato per abitudine. Chi deve solo consultare regole e log prende Read Only All; chi deve modificarle prende Read Write All. Super User aggiunge la gestione di amministratori e sessioni: darlo a tutti è l’errore di permessi che gli scenari puniscono più spesso, e negarlo a chi deve gestire le sessioni altrui è il suo speculare.
  • Il profilo predefinito che si tenta di modificare. La risposta corretta è sempre clonare, mai editare Read Write All o Super User.
  • Account giusto, sessione dimenticata. Se un collega ha lasciato SmartConsole aperta con modifiche non pubblicate, gli altri vedono un lucchetto sugli oggetti che sta toccando: non è un guasto del gateway né un problema di permessi, è una sessione ancora aperta. Fare il logout, o pubblicare, è parte dell’igiene di un account amministratore.
  • Prendersi la sessione di un altro. Chi ne ha il permesso può disconnettere o fare take over della sessione altrui, ma la documentazione avverte che così si disconnette la SmartConsole dell’altro amministratore e che le modifiche non pubblicate si perdono.
  • Expiration Date invisibile. Un amministratore con password corretta a cui viene negato l’accesso può semplicemente avere l’account scaduto.
  • Trusted Clients confusi con i permessi. Restringere l’elenco non toglie diritti a nessuno: impedisce la connessione da postazioni non elencate, e il messaggio non parla di profili.
  • OS Password scambiata per Check Point Password. Sono metodi diversi con archivi diversi: cambiare la password di Gaia non cambia quella di un amministratore Check Point Password, e viceversa.