Il CCSA parte da qui perché quasi ogni domanda successiva — policy, log, licenze, troubleshooting — presuppone che tu sappia quale macchina sta facendo che cosa.

I tre livelli e i loro compiti

Il Security Management Server è, nella definizione della documentazione R82, il “Dedicated Check Point server that runs Check Point software to manage the objects and policies in a Check Point environment”. Ospita il database di gestione: oggetti di rete, rule base, profili di amministratore, impostazioni globali. Riceve i log dai gateway, salvo che tu non abbia installato un Log Server dedicato, e li rende consultabili. Non ispeziona un solo pacchetto del traffico degli utenti.

Il Security Gateway è il “Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies”. È l’unico dei tre che sta sul percorso del traffico: applica la policy che ha ricevuto, genera i log, esegue i Software Blade abilitati sul suo oggetto. Se il Management Server si spegne, il gateway continua ad applicare l’ultima policy installata: quello che si perde è la gestione, non l’applicazione.

SmartConsole è il client di amministrazione: si installa su una postazione Windows e si collega al Management Server. Non è uno strato di sicurezza, è una finestra sul database del Management Server. Quando salvi una modifica la stai scrivendo lì, non sul gateway.

I ruoli restano tre anche quando le macchine sono due o una. Il First Time Configuration Wizard, nella finestra Installation Type, chiede di scegliere “Security Gateway and/or Security Management”: selezionando entrambi ottieni una distribuzione standalone, con gestione e gateway sulla stessa macchina; selezionandone uno solo ottieni una distribuzione distributed. Standalone non fonde i ruoli, li ospita insieme.

Come i livelli si parlano: SIC e Install Policy

Il canale fra Management Server e Security Gateway si chiama Secure Internal Communication. Si inizializza con una Activation Key, che la documentazione descrive lunga “between 4 and 127 characters”: la digiti una prima volta nella finestra Secure Internal Communication del First Time Configuration Wizard del gateway, e una seconda volta in SmartConsole, nel campo Communication dell’oggetto gateway, dove la guida dice di “enter the same Activation Key you entered during the Security Gateway’s First Time Configuration Wizard”.

La chiave serve una volta sola: stabilita la fiducia, i due lati si autenticano con certificati emessi dalla Internal Certificate Authority del Management Server. Per questo reinstallare un gateway, cambiargli indirizzo o ripristinare uno snapshot può richiedere di resettare e ricreare la SIC.

Il percorso di una modifica ha poi due passi distinti, ed è il malinteso più costoso dell’intero esame: Publish scrive le modifiche nel database del Management Server e le rende visibili agli altri amministratori; Install Policy le trasferisce al gateway, che da quel momento le applica. Pubblicare non protegge nulla.

SmartConsole verso il Management Server, mai verso il gateway

Alla connessione SmartConsole chiede il nome o l’indirizzo IP del Security Management Server e le credenziali dell’amministratore. Puoi autenticarti con username e password, con un file di certificato, con un certificato CAPI preso dal Windows Certificate Store, oppure tramite un Identity Provider SAML: in quest’ultimo caso, dice la documentazione, non è necessario inserire credenziali. Alla prima connessione compare il fingerprint del certificato del server, che va confrontato con quello noto prima di accettarlo: è una verifica prevista, non un errore. Una casella dedicata apre la sessione in sola lettura, e credenziali e indirizzo restano salvati nelle impostazioni utente di Windows.

Quando la connessione non si stabilisce, l’ordine dei sospetti è: indirizzo sbagliato, tipicamente quello del gateway; metodo di autenticazione diverso da quello configurato per quell’amministratore; ed elenco dei Trusted Clients in Manage & Settings > Permissions & Administrators, il cui valore predefinito è Any ma che, una volta ristretto, respinge anche chi ha la password giusta.

Trappole tipiche d’esame

  • “Dove risiedono le regole?” Lo scenario descrive un gateway che blocca traffico e chiede quale componente contiene la policy. La risposta è il Management Server: il gateway ne ha una copia installata e la applica. Chi confonde i ruoli sceglie il gateway.
  • Publish scambiato per Install Policy. La domanda racconta di una regola creata e pubblicata mentre il traffico si comporta come prima. La modifica esiste nel database ma non sul gateway: manca Install Policy. Vale anche il contrario, cioè installare una policy senza aver pubblicato le modifiche della propria sessione.
  • SmartConsole puntata al gateway. “L’amministratore non riesce a collegarsi al firewall con SmartConsole”: SmartConsole si collega al Management Server, non al Security Gateway. In standalone i due indirizzi coincidono, e questo nasconde l’errore finché l’ambiente non diventa distribuito.
  • Standalone letto come un ruolo unico. Gestione e gateway sulla stessa macchina restano due ruoli: la policy va comunque pubblicata e installata.
  • Activation Key scambiata per una password permanente. Serve solo a inizializzare la SIC; dopo la prima negoziazione conta il certificato, e cambiarla nell’oggetto non riautentica nulla se non resetti la SIC.
  • Trusted Clients dimenticati. Sono la causa di blocco meno intuitiva fra SmartConsole e Management Server, perché credenziali e fingerprint sono corretti e l’errore non parla di permessi.
  • Il fingerprint preso per un allarme. Alla prima connessione è previsto: va verificato, non necessariamente rifiutato.