Asi před rokem a půl jsem se přestěhoval do nové společnosti a začal jsem pracovat jako jejich DBA. Společnost dříve neaplikovala žádné opravy na žádné databáze Oracle. Od té doby, co jsem zde, jsem viděl, jak se zabezpečení IT systémů stává více středem zájmu a prochází vyšší úrovní kontroly, než tomu bylo dříve. Spíše než čekat na směrnici k zahájení implementace pravidelných bezpečnostních záplat pro naše databáze Oracle jsem se rozhodl být proaktivní. Přijde den, kdy jsme povinni začít pravidelně opravovat naše databáze Oracle a rád bych řekl, že už to máme implementované.
CPU Apr2012 byl právě vydán minulý týden a toto je první CPU, které použijeme na naše databáze Oracle. Než jsem použil první CPU, trochu jsem se zamyslel nad tím, jak implementovat tuto změnu v našem podnikovém prostředí. Rozhodl jsem se podělit o pár těchto změn pro případ, že by se někdo v budoucnu dostal do podobné situace.
1. 3D:Předtím, než se začalo s opravami, byla zdokumentována politika oprav, rozeslána pracovníkům IT a managementu a prodiskutována. Tento dokument na vysoké úrovni pojednává o potřebě pravidelných bezpečnostních záplat, kdy budou bezpečnostní záplaty vycházet a jak budou aplikovány na naše systémy, aby se snížilo riziko pro databázi, aplikaci a koncové uživatele.
2. Časová osa oprav – mám ten luxus mít klon naší produkční databáze jen pro použití DBA a pro nikoho jiného. Moje časová osa začíná tam. Do jednoho týdne od vydání CPU mám použít CPU k mé databázi DBA a vyřešit všechny problémy. Po dvou týdnech vydání CPU musím aplikovat opravu na naše vývojové databáze. Do jednoho měsíce od vydání CPU mám aplikovat opravu na databázi Test and Stage. A konečně, do 6 týdnů od vydání CPU, mám aplikovat opravu na produkci. Toto je jen moje časová osa a to, co funguje v našem prostředí. Vaše časová osa se může lišit. Je však důležité, aby všichni rozuměli časové ose a aby časová osa dělala dvě zdánlivě protichůdné věci – 1) aplikuje opravu pomalu, aby se případné problémy s databází nebo aplikací vyřešily, než se přistoupí k dalšímu kroku na časové ose. Jakmile se patch dostane do výroby, nemělo by dojít k žádnému překvapení a důvěře, že patch nic nezlomí. 2) aplikuje záplatu dostatečně rychle, aby byly bezpečnostní díry zacpány v rozumném čase. V mém prostředí je šest týdnů do výroby dost pomalých na zachycení problémů, ale asi tak rychle, jak se cítíme pohodlně. Vaše prostředí může mít jiné časové osy.
3. Log It – Silně cítím, že patche by měly být dokumentovány v nějakém protokolu změn. S protokolem byste měli být schopni vrátit se a přesně vidět, kdy byla každá oprava aplikována na každou databázi. To může při diagnostice značně pomoci, pokud byla za problém zodpovědná oprava. Pokud dostanu lístek, že postup dostává chyby a problém byl poprvé zaznamenán 1. května, mohu se podívat do protokolu změn. Pokud jsem záplatu aplikoval 30. dubna, problém možná způsobila záplata. Ale pokud jsem náplast aplikoval 2. května a problém existoval o den dříve, pak náplast není příčinou problému. Některé organizace již mají mechanismus Change Control zaveden a protokol oprav Oracle by měl do této struktury zapadat.
4. Test/Test/Test – Jako DBA máme povinnost zajistit, aby změny zaváděné do výroby měly vysoký stupeň jistoty, že se aplikace nerozbije. Je životně důležité otestovat své změny a záplaty se neliší. Pokud neprojdete svou časovou osou patche, nebudete mít dostatek času na otestování a pokud dojde k problému, který patch zavedl do vašeho prostředí, byla by to sebevražda kariéry, pokud byste před spuštěním výroby dostatečně neotestovali.
5. Zálohy – Před aplikací opravy je nutné zálohovat databázi a domovský adresář Oracle, který je opravován. Nikdy nevíte, zda se v jedné nebo obou těchto oblastech nebudete muset vrátit k předchozímu bodu před opravou. Člověk by měl občas otestovat metodiku obnovy nebo zálohování záplat dlouho před výrobou. Toto testování nemusí být nutně nutné provádět jednou za čtvrtletí, ale mělo by to být alespoň jednou ročně.
Myslím, že ty o pokrývají hlavní myšlenky, které jsem měl na toto téma. Pokud máte dotazy/připomínky, dejte mi vědět.