För ungefär ett och ett halvt år sedan flyttade jag till ett nytt företag och började arbeta som deras DBA. Företaget har inte tidigare tillämpat några patchar på några Oracle-databaser. Sedan jag har varit här har jag sett IT-systemsäkerhet bli mer av en fokuspunkt och genomgå en högre nivå av granskning än tidigare sett. Istället för att vänta på ett direktiv för att börja implementera vanliga säkerhetskorrigeringar för våra Oracle-databaser, bestämde jag mig för att vara proaktiv. Dagen kommer då vi måste börja patcha våra Oracle-databaser regelbundet och jag skulle vilja säga att vi redan har det implementerat.
Apr2012-processorn släpptes precis förra veckan och detta är den första processorn som vi kommer att applicera på våra Oracle-databaser. Innan jag använde den första CPU:n gick jag en liten fundering på hur man skulle implementera denna förändring i vår företagsmiljö. Jag bestämde mig för att dela med mig av några av dessa förändringar om någon annan skulle hamna i en liknande situation i framtiden.
1. De 3 D:en:Innan någon patchning började dokumenterades en patchpolicy, spreds till IT-personal och ledning och diskuterades. Detta dokument diskuterade på hög nivå behovet av vanliga säkerhetskorrigeringar, när säkerhetskorrigeringarna skulle komma ut och hur de skulle tillämpas på våra system för att minska risken för databasen, applikationen och slutanvändarna.
2. Patch Timeline – Jag har lyxen att ha en klon av vår produktionsdatabas bara för DBA:s användning och ingen annan. Min tidslinje börjar där. Inom en vecka efter att processorn släpptes ska jag applicera processorn på min DBA-databas och lösa eventuella problem. Med två veckor efter CPU-släppet ska jag applicera patchen på våra utvecklingsdatabaser. Inom en månad efter CPU-släppet ska jag applicera patchen på Test- och Stage-databasen. Och slutligen, inom 6 veckor efter CPU-släppet, ska jag ha applicerat patchen i produktionen. Det här är bara min tidslinje och vad som fungerar i vår miljö. Din tidslinje kan vara annorlunda. Men det är viktigt att alla förstår tidslinjen och att tidslinjen gör två till synes motsägelsefulla saker – 1) tillämpar patchen långsamt så att eventuella databas- eller applikationsproblem löses innan du går vidare till nästa steg i tidslinjen. När plåstret väl är i produktion bör det inte finnas några överraskningar och förtroende för att plåstret inte kommer att gå sönder något. 2) applicerar patchen tillräckligt snabbt så att säkerhetshål täpps till inom rimlig tid. I min miljö är sex veckor till produktion långsam nog för att fånga upp problem, men ungefär lika snabbt som vi känner oss bekväma med att gå. Din miljö kan ha andra tidslinjer.
3. Log It – Jag anser starkt att patchar bör dokumenteras i någon form av ändringslogg. Med loggen bör du kunna gå tillbaka och se exakt när varje patch applicerades på varje databas. Detta kan räcka långt för att diagnostisera om ett plåster var ansvarigt för ett problem. Om jag får en biljett om att en procedur tar emot fel och problemet först noterades den 1 maj, då kan jag titta på ändringsloggen. Om jag applicerade plåstret den 30 april kan plåstret ha introducerat problemet. Men om jag applicerade plåstret den 2 maj och problemet fanns en dag tidigare, så är inte plåstret orsaken till problemet. Vissa organisationer har redan en ändringskontrollmekanism på plats och Oracles patchlogg bör passa inom den strukturen.
4. Test/Test/Test – Som DBA har vi en skyldighet att se till att ändringar som införs i produktionen har en hög grad av förtroende för att applikationen inte går sönder. Det är mycket viktigt att testa dina förändringar och patchar är inte annorlunda. Om du inte går igenom din patch-tidslinje kommer du inte att ha tillräckligt med tid att testa och om det finns ett problem som patchen har introducerat till din miljö, skulle det vara karriärsjälvmord om du inte testade tillräckligt innan produktionen startade.
5. Säkerhetskopiering – Man måste säkerhetskopiera databasen och Oracle-hemkatalogen som korrigeras innan korrigeringen appliceras. Du vet aldrig om du måste gå tillbaka till en tidigare punkt före plåstret i ett eller båda av dessa områden. Man bör då och då testa återställningsmetoden eller backa ut patchar i god tid före produktion. Denna testning behöver inte nödvändigtvis göras en gång per kvartal, utan bör göras minst en gång om året.
Jag tror att de om täcker de viktigaste tankarna jag hade om ämnet. Om du har frågor/kommentarer, låt mig veta.