Prima ancora di scrivere una regola, in Check Point si costruisce un vocabolario. Quel vocabolario sono gli oggetti: definizioni con un nome, che vivono nel database del Security Management Server e che le regole si limitano a richiamare. Capire perché il prodotto è fatto così spiega metà degli errori che si commettono dopo.

Le regole non contengono indirizzi, contengono nomi

In una regola di Access Control le colonne Source, Destination, Services & Applications, Content, Install On e Time non accettano indirizzi scritti a mano: accettano oggetti. Source e Destination accettano reti, host, zone, dynamic object, domain object, access role e updatable object; Services & Applications accetta servizi, applicazioni, applicazioni mobili, siti, categorie di traffico e gruppi personalizzati; Content accetta data type; Install On accetta network object.

Da qui discendono i tre motivi per cui gli oggetti esistono:

  • Leggibilità. Una riga che dice Finance-LAN verso ERP-Server si legge; una riga di soli indirizzi no, e chi rivedrà la policy fra sei mesi non saprà che cosa stava proteggendo.
  • Riuso. Lo stesso oggetto compare in decine di regole, dentro altri gruppi, nelle regole di NAT, nelle eccezioni di Threat Prevention.
  • Manutenzione in un punto solo. Se un indirizzo cambia, si corregge l’oggetto, non le regole che lo usano.

Dove vivono: Object Explorer, categorie, metadati

Gli oggetti si creano e si cercano dalla Objects Bar (F11) e dall’Object Explorer, organizzati per categoria: Network Objects (Security Gateway, host, reti, address range, dynamic object, security zone), Services, Custom Applications/Sites, VPN Communities, Users, Data Types, Servers, Time Objects, UserCheck Interactions, Limit.

Quasi ogni oggetto porta con sé gli stessi metadati: nome, commento, colore e tag. Non sono decorazioni. Il tag è un criterio di ricerca personalizzato, e il colore è ciò che rende riconoscibile a colpo d’occhio un insieme di oggetti in una rule base lunga.

La ricerca di SmartConsole lavora in due modi, ed è la differenza che conta. La ricerca generale è testuale sulla rule base: accetta nomi completi, prefissi e caratteri jolly, e se cerchi un indirizzo IP o una rete restituisce anche gli oggetti di rete correlati e le regole che li usano. Il packet search invece simula il modo in cui il gateway elabora un pacchetto, scandaglia le colonne Source e Destination e per questo trova anche gli oggetti annidati dentro i gruppi; si può restringere a una singola colonna indicando il nome della colonna seguito da due punti e dal criterio. Il packet search non supporta IPv6.

Una modifica all’oggetto è una modifica a tutte le regole

Questo è il punto che il vendore considera critico. Quando cambi l’indirizzo di un host o il contenuto di un gruppo non stai modificando “quell’oggetto”: stai modificando il comportamento di ogni regola che lo richiama, senza che nessuna di quelle righe appaia cambiata.

La sequenza temporale conta quanto la modifica:

  1. la modifica è salvata nella tua sessione, ma resta privata;
  2. con Publish diventa visibile agli altri amministratori ed entra nel database di gestione;
  3. con Install Policy arriva ai Security Gateway e comincia a filtrare traffico.

L’unica eccezione che vale la pena ricordare sono gli Updatable Objects, che rappresentano servizi esterni come fornitori cloud o aree geografiche: le loro liste di indirizzi e domini si aggiornano da sole sul gateway quando il fornitore le cambia, senza bisogno di installare la policy. Il perimetro di quell’oggetto cambia anche quando tu non tocchi niente.

La regola pratica prima di modificare un oggetto condiviso è una sola: cerca dove viene usato, per nome, per indirizzo e con il packet search, invece di fidarti del ricordo di dove l’avevi messo.

Trappole tipiche d’esame

  • Oggetti ridondanti. Tre host con lo stesso indirizzo e nomi diversi non producono un errore di validazione: producono una policy illeggibile, statistiche di hit count sparpagliate su regole diverse e una bonifica futura che ne dimenticherà uno. Le domande scenario chiedono la conseguenza, non se sia vietato.
  • “Cambio solo l’oggetto”. Modificare un oggetto usato in dodici regole significa modificare dodici regole. Se lo scenario dice che dopo una modifica di oggetto è caduto traffico che prima passava, la risposta corretta riguarda quasi sempre il riuso dell’oggetto, non un errore nella rule base.
  • Confondere i tre momenti. Salvataggio automatico nella sessione, Publish e Install Policy non sono sinonimi: solo l’ultimo cambia il comportamento del gateway, e solo gli Updatable Objects fanno eccezione perché si aggiornano senza installazione.
  • Cercare a occhio nella colonna Source. Un oggetto può essere sepolto in un gruppo annidato: la lettura visiva della regola non basta, il packet search sì.
  • Pensare che l’oggetto sia dentro la regola. Cancellarlo o riciclarlo perché “quella regola non serve più” ignora tutte le altre regole e tutti i gruppi che continuano a richiamarlo.