Un Security Management Server fermo non spegne la sicurezza — i Security Gateway continuano ad applicare l’ultima policy installata — ma congela tutto il resto: nessuna modifica alla Rule Base, nessuna installazione di policy, nessuna gestione degli oggetti. Management High Availability serve esattamente a togliere questo singolo punto di rottura dall’architettura di gestione, ed è il primo argomento in cui l’esame misura se hai capito la differenza fra «il traffico passa» e «l’infrastruttura è gestibile».
Che cosa mette al riparo, e che cosa no
Check Point definisce Management High Availability come la modalità di installazione e configurazione di due Management Server che sincronizzano automaticamente fra loro i database di gestione. Ciò che viaggia sono i dati di gestione: policies, rules, user definitions, network objects e system configuration settings. La sincronizzazione si appoggia alla tecnologia delle revisions e trasferisce solo le modifiche incrementali dall’ultimo allineamento, così l’impatto sulle risorse dei server resta contenuto.
Un ambiente di High Availability è fatto da un Active Security Management Server e da uno o più Standby. L’amministratore lavora sull’Active; uno Standby si può aprire solo in Read Only mode. Se la comunicazione con l’Active si interrompe può accadere che più di un server risulti Active: questa condizione ha un nome preciso, Collision Mode, ed è una situazione da riconoscere, non da archiviare come normale.
Quello che Management High Availability non offre è un bilanciamento del carico né un indirizzo virtuale condiviso: i due server restano due macchine distinte, con due indirizzi, e il passaggio di ruolo lo decide l’amministratore.
Primary/Secondary e Active/Standby sono due coppie diverse
È la distinzione che l’esame chiede spesso in modo obliquo. Primary e Secondary sono ruoli di installazione: si fissano nel First Time Configuration Wizard, nel campo Define Security Management as, e il primo server installato è il Primary. Active e Standby sono invece ruoli operativi: dicono chi in questo momento accetta modifiche e chi è in sola lettura. Un changeover scambia Active e Standby, ma non trasforma un Secondary in Primary.
Portare in servizio il secondo server
Il Secondary va installato con la stessa versione di Gaia usata per il Primary: la documentazione lo scrive come requisito, non come raccomandazione. Nel First Time Configuration Wizard si sceglie Security Gateway and/or Security Management, poi Security Management only, quindi Secondary nel campo Define Security Management as, e si imposta una Activation Key da 4 a 127 caratteri per il Secure Internal Communication. Serve poi una licenza valida.
Il resto si fa da SmartConsole collegata al Primary: in Object Explorer, New > More > Network Object > Gateways and Servers > Check Point Host, con nome e indirizzo del secondo server; nella scheda Management si seleziona Network Policy Management, che porta con sé Secondary Server, Logging and Status e Provisioning; si apre Communication, si digita la stessa Activation Key, si esegue Initialize e si verifica che il Trust state sia Established. Dopo Install database si attende nella Task List che il full sync sia completato, e in High Availability Status si controlla di vedere un Active e uno Standby.
Un passaggio che si dimentica volentieri: su ogni Security Gateway e su ogni cluster va aperto Fetch Policy e aggiunto il server secondario, altrimenti i gateway continueranno a cercare la policy solo dove non c’è più nessuno ad ascoltare.
Trappole tipiche d’esame
La sincronizzazione che sembra fatta e non lo è. Le sessioni non pubblicate non vengono sincronizzate: una modifica lasciata aperta in SmartConsole non esiste per l’altro server. È la causa principale dei database incoerenti citata da Check Point, e in un quesito si maschera dietro frasi come «l’amministratore ha appena modificato la Rule Base e ha avviato il changeover».
La rete che non lascia parlare i due membri. Se SIC non si stabilisce, il Trust state non arriva a Established; se il traffico fra i due server viene filtrato, la finestra High Availability Status mostra No communication oppure Not communicating, last sync time. Una domanda che descrive due server «entrambi Active» sta descrivendo Collision Mode, cioè un guasto di comunicazione, non una scelta di configurazione.
Il failover mai collaudato. Tre dettagli emergono solo provando davvero: gli amministratori creati con cpconfig sul Primary non possono accedere alla SmartConsole del Secondary finché il full sync non è completo; SmartEvent è supportato solo sull’Active Management Server; backup e snapshot vanno raccolti e ripristinati su tutti i server dell’ambiente High Availability insieme, altrimenti si ricostruisce un ambiente già disallineato.