Vor ungefähr anderthalb Jahren bin ich in ein neues Unternehmen gezogen und habe dort als DBA angefangen. Das Unternehmen hat zuvor keine Patches auf Oracle-Datenbanken angewendet. Seit ich hier bin, habe ich gesehen, dass die IT-Systemsicherheit mehr in den Fokus gerückt ist und einer stärkeren Prüfung unterzogen wird als zuvor. Anstatt auf eine Anweisung zu warten, um mit der Implementierung regelmäßiger Sicherheitspatches für unsere Oracle-Datenbanken zu beginnen, habe ich mich entschieden, proaktiv zu sein. Der Tag wird kommen, an dem wir mit dem regelmäßigen Patchen unserer Oracle-Datenbanken beginnen müssen, und ich möchte sagen, dass wir es bereits implementiert haben.
Die Apr2012-CPU wurde erst letzte Woche veröffentlicht und dies ist die erste CPU, die wir auf unsere Oracle-Datenbanken anwenden werden. Bevor ich die erste CPU eingesetzt habe, habe ich mir ein paar Gedanken gemacht, wie wir diese Änderung in unserem Unternehmensumfeld umsetzen können. Ich habe mich entschieden, einige dieser Änderungen zu teilen, falls jemand in Zukunft in eine ähnliche Situation gerät.
1. Die 3 D’s:Bevor mit dem Patchen begonnen wurde, wurde eine Patch-Richtlinie dokumentiert, an das IT-Personal und das Management verteilt und besprochen. In diesem Dokument wurde auf hoher Ebene die Notwendigkeit regelmäßiger Sicherheitspatches erörtert, wann die Sicherheitspatches herauskommen und wie sie auf unsere Systeme angewendet werden, um das Risiko für die Datenbank, die Anwendung und die Endbenutzer zu verringern.
2. Patch-Zeitleiste – Ich habe den Luxus, einen Klon unserer Produktionsdatenbank nur für die Verwendung durch den DBA und für niemanden sonst zu haben. Meine Timeline beginnt dort. Innerhalb einer Woche nach der Veröffentlichung der CPU muss ich die CPU auf meine DBA-Datenbank anwenden und alle Probleme lösen. Zwei Wochen nach der CPU-Veröffentlichung soll ich den Patch auf unsere Entwicklungsdatenbanken anwenden. Innerhalb eines Monats nach der CPU-Veröffentlichung muss ich den Patch auf die Test- und Stage-Datenbank anwenden. Und schließlich soll ich den Patch innerhalb von 6 Wochen nach der CPU-Veröffentlichung auf die Produktion angewendet haben. Dies ist nur meine Zeitleiste und das, was in unserer Umgebung funktioniert. Ihr Zeitplan kann anders sein. Aber es ist wichtig, dass jeder die Zeitleiste versteht und dass die Zeitleiste zwei scheinbar widersprüchliche Dinge tut – 1) wendet den Patch langsam an, damit alle Datenbank- oder Anwendungsprobleme gelöst werden, bevor mit dem nächsten Schritt in der Zeitleiste fortgefahren wird. Sobald der Patch die Produktion erreicht, sollte es keine Überraschungen geben und darauf vertrauen, dass der Patch nichts kaputt macht. 2) Der Patch wird schnell genug angewendet, sodass Sicherheitslücken in angemessener Zeit geschlossen werden. In meiner Umgebung sind sechs Wochen bis zur Produktion langsam genug, um Probleme zu erkennen, aber ungefähr so schnell, wie wir uns wohl fühlen. Ihre Umgebung kann andere Zeitpläne haben.
3. Protokollieren – Ich bin der festen Überzeugung, dass Patches in einer Art Änderungsprotokoll dokumentiert werden sollten. Mit dem Protokoll sollten Sie zurückgehen und genau sehen können, wann jeder Patch auf jede Datenbank angewendet wurde. Dies kann bei der Diagnose, ob ein Patch für ein Problem verantwortlich war, einen großen Beitrag leisten. Wenn ich ein Ticket erhalte, dass eine Prozedur Fehler erhält und das Problem erstmals am 1. Mai bemerkt wurde, dann kann ich das Änderungsprotokoll einsehen. Wenn ich den Patch am 30. April angewendet habe, hat der Patch möglicherweise das Problem verursacht. Aber wenn ich den Patch am 2. Mai angewendet habe und das Problem einen Tag zuvor bestand, dann ist der Patch nicht die Ursache des Problems. Einige Organisationen haben bereits einen Änderungskontrollmechanismus eingerichtet und das Oracle-Patch-Protokoll sollte in diese Struktur passen.
4. Test/Test/Test – Als DBA haben wir die Pflicht sicherzustellen, dass Änderungen, die in die Produktion eingeführt werden, ein hohes Maß an Vertrauen darauf haben, dass die Anwendung nicht beschädigt wird. Es ist äußerst wichtig, Ihre Änderungen zu testen, und Patches sind nicht anders. Wenn Sie Ihren Patch-Zeitrahmen nicht durchgehen, haben Sie nicht genügend Zeit zum Testen, und wenn es ein Problem gibt, das der Patch in Ihre Umgebung eingeführt hat, wäre es Karriere-Selbstmord, wenn Sie nicht ausreichend getestet haben, bevor Sie die Produktion erreichen.
5. Sicherungen – Man muss die Datenbank und das zu patchende Oracle-Home-Verzeichnis sichern, bevor man den Patch anwendet. Sie wissen nie, ob Sie in einem oder beiden dieser Bereiche zu einem früheren Punkt vor dem Patch zurückkehren müssen. Man sollte die Wiederherstellungsmethodik gelegentlich testen oder Patches lange vor der Produktion zurücksetzen. Diese Prüfung muss nicht unbedingt einmal im Quartal durchgeführt werden, sollte aber mindestens einmal im Jahr erfolgen.
Ich denke, diese decken die wichtigsten Gedanken ab, die ich zu diesem Thema hatte. Wenn Sie Fragen/Kommentare haben, lassen Sie es mich wissen.
