For cirka halvandet år siden flyttede jeg til en ny virksomhed og begyndte at arbejde som deres DBA. Virksomheden har ikke tidligere anvendt nogen patches til nogen Oracle-databaser. Siden jeg har været her, har jeg set it-systemsikkerhed blive mere et fokuspunkt og gennemgå en højere grad af kontrol end tidligere set. I stedet for at vente på et direktiv om at begynde at implementere almindelige sikkerhedsrettelser til vores Oracle-databaser, besluttede jeg at være proaktiv. Den dag vil komme, hvor vi bliver bedt om at begynde at patche vores Oracle-databaser med jævne mellemrum, og jeg vil gerne sige, at vi allerede har det implementeret.
Apr2012 CPU'en blev netop udgivet i sidste uge, og dette er den første CPU, som vi vil anvende på vores Oracle-databaser. Før jeg anvendte den første CPU, gik der en lille tanke om, hvordan man implementerede denne ændring i vores virksomhedsmiljø. Jeg besluttede at dele et par af disse ændringer, hvis andre kommer i en lignende situation i fremtiden.
1. De 3 D'er:Før enhver patching begyndte, blev en patchpolitik dokumenteret, udsendt til it-personale og ledelse og diskuteret. Dette dokument diskuterede på et højt niveau behovet for regelmæssige sikkerhedsrettelser, hvornår sikkerhedsrettelserne ville komme ud, og hvordan de ville blive anvendt på vores systemer for at reducere risikoen for databasen, applikationen og slutbrugerne.
2. Patch Timeline - Jeg har den luksus at have en klon af vores produktionsdatabase kun til DBA's brug og ingen andre. Min tidslinje starter der. Inden for en uge efter CPU'ens frigivelse skal jeg anvende CPU'en til min DBA-database og løse eventuelle problemer. Med to uger efter CPU-udgivelsen skal jeg anvende patchen til vores udviklingsdatabaser. Inden for en måned efter CPU-udgivelsen skal jeg anvende patchen til Test- og Stage-databasen. Og endelig, inden for 6 uger efter CPU-udgivelsen, skal jeg have anvendt patchen til produktionen. Dette er bare min tidslinje og hvad der virker i vores miljø. Din tidslinje kan være anderledes. Men det er vigtigt, at alle forstår tidslinjen, og at tidslinjen gør to tilsyneladende modstridende ting – 1) anvender patchen langsomt, så eventuelle database- eller applikationsproblemer bliver ordnet, før du fortsætter til næste trin i tidslinjen. Når først plasteret rammer produktionen, bør der ikke være nogen overraskelser, og tillid til, at patchen ikke går i stykker. 2) anvender patchen hurtigt nok til, at sikkerhedshuller tilstoppes i rimelig tid. I mit miljø er seks uger til produktion langsomt nok til at fange problemer, men omtrent lige så hurtigt, som vi føler os trygge ved at gå. Dit miljø kan have andre tidslinjer.
3. Log It – Jeg mener stærkt, at patches skal dokumenteres i en form for ændringslog. Med loggen burde du være i stand til at gå tilbage og se præcis, hvornår hver patch blev anvendt på hver database. Dette kan gå langt i at diagnosticere, om et plaster var ansvarlig for et problem. Hvis jeg får en billet om, at en procedure modtager fejl, og problemet først blev noteret den 1. maj, så kan jeg se på ændringsloggen. Hvis jeg påsatte plasteret den 30. april, så kan plasteret have introduceret problemet. Men hvis jeg påsatte plasteret den 2. maj, og problemet eksisterede en dag tidligere, så er plasteret ikke årsagen til problemet. Nogle organisationer har allerede en ændringskontrolmekanisme på plads, og Oracle-patchloggen bør passe ind i denne struktur.
4. Test/Test/Test – Som DBA har vi pligt til at sikre, at ændringer, der indføres i produktionen, har en høj grad af tillid til, at ansøgningen ikke går i stykker. Det er meget vigtigt at teste dine ændringer, og patches er ikke anderledes. Hvis du ikke gennemgår din patch-tidslinje, vil du ikke have tilstrækkelig tid til at teste, og hvis der er et problem, som patchen har introduceret til dit miljø, ville det være karriere-selvmord, hvis du ikke testede tilstrækkeligt, før du startede produktionen.
5. Sikkerhedskopier – Man skal sikkerhedskopiere databasen og Oracle-hjemmebiblioteket, der patches, før programrettelsen anvendes. Du ved aldrig, om du bliver nødt til at gå tilbage til et tidligere punkt før plasteret i et eller begge af disse områder. Man bør lejlighedsvis teste gendannelsesmetodikken eller bakke patches ud i god tid før produktion. Denne test behøver ikke nødvendigvis at blive udført én gang i kvartalet, men bør være mindst én gang om året.
Jeg tror, at de omkring dækker de store tanker, jeg havde om emnet. Hvis du har spørgsmål/kommentarer, så lad mig det vide.