Circa un anno e mezzo fa, mi sono trasferito in una nuova azienda e ho iniziato a lavorare come DBA. La società non ha applicato in precedenza alcuna patch a nessun database Oracle. Da quando sono qui, ho visto la sicurezza del sistema IT diventare più un punto focale e subire un livello di controllo più elevato rispetto a quanto visto in precedenza. Piuttosto che aspettare una direttiva per iniziare a implementare patch di sicurezza regolari per i nostri database Oracle, ho deciso di essere proattivo. Verrà il giorno in cui ci verrà chiesto di iniziare ad applicare regolarmente le patch ai nostri database Oracle e vorrei dire che l'abbiamo già implementato.
La CPU di aprile 2012 è stata rilasciata la scorsa settimana e questa è la prima CPU che applicheremo ai nostri database Oracle. Prima di applicare la prima CPU, ho pensato a come implementare questo cambiamento nel nostro ambiente aziendale. Ho deciso di condividere alcune di queste modifiche nel caso in cui qualcun altro dovesse trovarsi in una situazione simile in futuro.
1. Le 3 D:prima dell'inizio di qualsiasi applicazione di patch, una politica di patch veniva documentata, divulgata al personale IT e alla direzione e discussa. Questo documento ha discusso ad alto livello della necessità di patch di sicurezza regolari, quando sarebbero uscite le patch di sicurezza e come sarebbero state applicate ai nostri sistemi per ridurre i rischi per il database, l'applicazione e gli utenti finali.
2. Patch Timeline – Ho il lusso di avere un clone del nostro database di produzione solo per l'uso del DBA e nessun altro. La mia sequenza temporale inizia da lì. Entro una settimana dal rilascio della CPU, devo applicare la CPU al mio database DBA e risolvere eventuali problemi. A due settimane dal rilascio della CPU, applicherò la patch ai nostri database di sviluppo. Entro un mese dal rilascio della CPU, devo applicare la patch al database Test and Stage. E infine, entro 6 settimane dal rilascio della CPU, devo applicare la patch alla produzione. Questa è solo la mia sequenza temporale e ciò che funziona nel nostro ambiente. La tua sequenza temporale potrebbe essere diversa. Ma è importante che tutti comprendano la sequenza temporale e che la sequenza temporale faccia due cose apparentemente contraddittorie:1) applica la patch lentamente in modo che eventuali problemi del database o dell'applicazione vengano risolti prima di procedere al passaggio successivo nella sequenza temporale. Una volta che la patch sarà in produzione, non dovrebbero esserci sorprese e la certezza che la patch non interromperà nulla. 2) applica la patch abbastanza velocemente in modo che i buchi di sicurezza siano tappati in un tempo ragionevole. Nel mio ambiente, sei settimane prima della produzione sono abbastanza lente da rilevare i problemi, ma tanto velocemente quanto ci sentiamo a nostro agio nell'andare. Il tuo ambiente potrebbe avere altre linee temporali.
3. Log It – Sento fortemente che le patch dovrebbero essere documentate in una sorta di registro delle modifiche. Con il registro, dovresti essere in grado di tornare indietro e vedere esattamente quando ogni patch è stata applicata a ciascun database. Questo può fare molto per diagnosticare se una patch era responsabile di un problema. Se ricevo un ticket che indica che una procedura riceve errori e il problema è stato notato per la prima volta il 1 maggio, posso guardare il registro delle modifiche. Se ho applicato la patch il 30 aprile, la patch potrebbe aver introdotto il problema. Ma se ho applicato la patch il 2 maggio e il problema si è verificato un giorno prima, la patch non è la causa del problema. Alcune organizzazioni dispongono già di un meccanismo di controllo delle modifiche e il log delle patch Oracle dovrebbe rientrare in tale struttura.
4. Test/Test/Test – In qualità di DBA, abbiamo il dovere di garantire che le modifiche introdotte nella produzione abbiano un alto grado di sicurezza che l'applicazione non si romperà. È di vitale importanza testare le modifiche e le patch non sono diverse. Se non segui la sequenza temporale delle patch, non avrai tempo sufficiente per testare e se c'è un problema che la patch ha introdotto nel tuo ambiente, sarebbe un suicidio professionale se non eseguissi adeguatamente i test prima di entrare in produzione.
5. Backup:prima di applicare la patch, è necessario eseguire il backup del database e della home directory Oracle su cui è stata applicata la patch. Non sai mai se dovrai tornare a un punto precedente prima della patch in una o entrambe le aree. Occasionalmente si dovrebbe testare la metodologia di ripristino o eseguire il backup delle patch ben prima della produzione. Questo test potrebbe non essere necessariamente eseguito una volta al trimestre, ma dovrebbe essere almeno una volta all'anno.
Penso che quelli su coprano i pensieri principali che ho avuto sull'argomento. Se hai domande/commenti, fammi sapere.
