Około półtora roku temu przeniosłem się do nowej firmy i zacząłem pracować jako DBA. Firma nie stosowała wcześniej żadnych poprawek do żadnych baz danych Oracle. Odkąd tu jestem, zauważyłem, że bezpieczeństwo systemu IT staje się bardziej punktem skupienia i przechodzi wyższy poziom kontroli niż wcześniej. Zamiast czekać, aż dyrektywa zacznie wdrażać regularne poprawki bezpieczeństwa dla naszych baz danych Oracle, zdecydowałem się działać proaktywnie. Nadejdzie dzień, w którym będziemy musieli zacząć regularnie łatać nasze bazy danych Oracle i chciałbym powiedzieć, że już to wdrożyliśmy.
Procesor z kwietnia 2012 został właśnie wydany w zeszłym tygodniu i jest to pierwszy procesor, który zastosujemy w naszych bazach danych Oracle. Zanim zastosowałem pierwszy procesor, zastanowiłem się, jak wprowadzić tę zmianę w naszym środowisku korporacyjnym. Postanowiłem podzielić się kilkoma z tych zmian na wypadek, gdyby ktoś inny znalazł się w podobnej sytuacji w przyszłości.
1. 3D:Przed rozpoczęciem jakichkolwiek poprawek, zasady dotyczące poprawek zostały udokumentowane, rozpowszechnione wśród personelu IT i kierownictwa oraz omówione. W tym dokumencie omówiono na wysokim poziomie potrzebę regularnych poprawek bezpieczeństwa, kiedy łatki bezpieczeństwa wyjdą i jak zostaną zastosowane w naszych systemach, aby zmniejszyć ryzyko dla bazy danych, aplikacji i użytkowników końcowych.
2. Patch Timeline – mam luksus posiadania klona naszej produkcyjnej bazy danych tylko na użytek DBA i nikogo innego. Tam zaczyna się moja oś czasu. W ciągu tygodnia od wydania procesora mam zastosować procesor do mojej bazy danych DBA i rozwiązać wszelkie problemy. W dwa tygodnie od premiery procesora mam zamiar zastosować poprawkę do naszych baz danych deweloperskich. W ciągu miesiąca od premiery procesora mam zastosować łatkę do bazy danych Test i Stage. I wreszcie, w ciągu 6 tygodni od premiery procesora, mam wprowadzić łatkę do produkcji. To tylko moja oś czasu i to, co działa w naszym środowisku. Twoja oś czasu może być inna. Ale ważne jest, aby wszyscy rozumieli oś czasu i aby oś czasu robiła dwie pozornie sprzeczne rzeczy – 1) powoli stosuje poprawkę, aby wszelkie problemy z bazą danych lub aplikacjami zostały rozwiązane przed przejściem do następnego kroku na osi czasu. Gdy łatka trafi do produkcji, nie powinno być żadnych niespodzianek i pewności, że łatka niczego nie zepsuje. 2) zastosuje poprawkę wystarczająco szybko, aby luki w zabezpieczeniach zostały załatane w rozsądnym czasie. W moim środowisku sześć tygodni do produkcji to wystarczająco dużo czasu, aby wykryć problemy, ale mniej więcej tak szybko, jak czujemy się komfortowo. Twoje środowisko może mieć inne ramy czasowe.
3. Log It – uważam, że poprawki powinny być udokumentowane w jakimś dzienniku zmian. Dzięki dziennikowi powinieneś być w stanie wrócić i zobaczyć dokładnie, kiedy każda poprawka została zastosowana do każdej bazy danych. Może to znacznie pomóc w zdiagnozowaniu, czy poprawka była odpowiedzialna za problem. Jeśli otrzymam zgłoszenie, że procedura zawiera błędy, a problem został po raz pierwszy zauważony 1 maja, mogę zajrzeć do dziennika zmian. Jeśli zaaplikowałem łatkę 30 kwietnia, to łatka mogła spowodować problem. Ale jeśli nałożyłem łatkę 2 maja, a problem istniał dzień wcześniej, to łatka nie jest przyczyną problemu. Niektóre organizacje mają już mechanizm kontroli zmian, a dziennik poprawek Oracle powinien pasować do tej struktury.
4. Test/Test/Test – Jako DBA mamy obowiązek zapewnić, że zmiany wprowadzane do produkcji mają wysoki stopień pewności, że aplikacja nie ulegnie awarii. Niezwykle ważne jest, aby przetestować swoje zmiany, a łatki nie różnią się od siebie. Jeśli nie przejdziesz przez oś czasu łatek, nie będziesz miał wystarczającej ilości czasu na testowanie, a jeśli pojawi się problem, który łatka wprowadziła do twojego środowiska, byłoby to samobójstwo kariery, gdybyś nie przetestował odpowiednio przed rozpoczęciem produkcji.
5. Kopie zapasowe — przed zastosowaniem poprawki należy wykonać kopię zapasową bazy danych i katalogu macierzystego Oracle. Nigdy nie wiesz, czy będziesz musiał wrócić do poprzedniego punktu przed aktualizacją w jednym lub obu tych obszarach. Należy od czasu do czasu przetestować metodologię przywracania lub cofnąć poprawki na długo przed produkcją. Testy te niekoniecznie muszą być przeprowadzane raz na kwartał, ale powinny odbywać się przynajmniej raz w roku.
Myślę, że te okrywają główne przemyślenia, jakie miałem na ten temat. Jeśli masz pytania/komentarze, daj mi znać.
