Continua dalle Parti I e II
L’auditing, i cambiamenti di configurazione e l’attività
dell’utente sono rilevanti non soltanto per determinare le falle nella
sicurezza, ma anche per essere aggiornati sui cambiamenti apportati alla rete e
sulle tendenze inerenti le prestazioni del network. Un efficace programma di
auditing include la manutenzione dei log per l’accesso alla San, i cambiamenti
di configurazione e le attività dell’utente.
Sulla base di queste
informazioni, il sistema di auditing dovrebbe verificare il comportamento sia
normale sia anomalo ed includere le procedure per reagire a eventuali
violazioni.
Come controllo dell’accesso, l’auditing è abitualmente un
argomento per l’inventario dei tool disponibili e della loro efficace
applicazione. Tutte le San dispongono di utility di audit ma, se necessario,
sono disponibili sul mercato package supplementari di auditing. Noi consigliamo
di studiare e sviluppare un programma di auditing efficace per la vostra San.
Gli allarmi sono le reazioni ai risultati degli audit.
Dovrebbero variare da una semplice notifica non-intrusiva degli incidenti di
minore rilevanza a un completo piano anticrisi in caso di una minaccia
importante.
È essenziale regolare gli allarmi che identificano i problemi
seri senza gridare “al lupo”. Di nuovo, questo modo do agire richiede uno studio
e una progettazione da parte degli amministratori dello storage. Il primo punto
nello sviluppo di una strategia efficace di allarme risiede nel determinare cosa
costituisce un normale modello di attività della San. Oltre ai dati di traffico,
potrebbe essere necessario includere l’uso di tool di gestione e apportare
cambiamenti alla San. Quando si assemblano i dati, è meglio avere una visione
più ampia su cosa è normale.
Una volta stabilito cosa si intende per
“normalità”, lo step seguente è determinare quanto l’attività della San può
discostarsi dal normale prima che si trasformi in allarme. Oltre all’ovvia
analisi della varianza nei parametri di attività della San, dovrebbero essere
inclusi i modelli dell’attività del business e i possibili eventi esterni. Per
esempio, se una nevicata eccezionale dovesse bloccare i trasporti nella vostra
zona, sarebbe logico prevedere che un maggior numero di persone tenti il log
sulla San da remoto perché lavora da casa. D’altra parte, non vi aspettereste un
sacco di tentativi di cambiare la configurazione della San nel mezzo di una
bufera di neve. Allo stesso m odo dell’accesso, le procedure d’allarme efficaci
richiedono un controllo costante, frequenti cambiamenti e un aggiornamento
continuo per essere sempre in sincronia con le realtà dell’impresa.
L’availability non è solitamente considerata una
componente di sicurezza di una San, ma ha un importante rapporto con essa.
L’availability è soprattutto un’architettura e si riferisce al grado di
ridondanza, di fault tolerance e di fail over propri di in una San. Tuttavia
l’avalilability coinvolge il disaster recovery e questo viene solitamente visto
come componente di sicurezza.
Nel contesto della sicurezza, l’availability
include lo sviluppo e la manutenzione di un efficace piano di disaster recovery
per gestire gli incidenti che potrebbero bloccare il data center o distruggere i
dati. Il disaster recovery richiede una progettazione attenta e frequenti
controlli per assicurarsi che il programma copra ogni aspetto del piano e che
questo realmente funzionerà quando le cose andranno veramente male.
