Ongeveer anderhalf jaar geleden verhuisde ik naar een nieuw bedrijf en begon ik te werken als hun DBA. Het bedrijf paste eerder geen patches toe op Oracle-databases. Sinds ik hier ben, heb ik gezien dat IT-systeembeveiliging meer een focuspunt is geworden en een hoger niveau van controle heeft ondergaan dan voorheen. In plaats van te wachten op een richtlijn om reguliere beveiligingspatches voor onze Oracle-databases te implementeren, besloot ik proactief te zijn. Er komt een dag dat we onze Oracle-databases regelmatig moeten gaan patchen en ik zou willen zeggen dat we het al hebben geïmplementeerd.
De CPU van april 2012 is net vorige week uitgebracht en dit is de eerste CPU die we gaan toepassen op onze Oracle-databases. Voordat ik de eerste CPU toepast, heb ik even nagedacht over hoe we deze verandering in onze bedrijfsomgeving kunnen implementeren. Ik besloot een paar van die veranderingen te delen voor het geval iemand anders in de toekomst in een vergelijkbare situatie terechtkomt.
1. De 3 D's:voordat met patchen werd begonnen, werd een patchbeleid gedocumenteerd, verspreid onder IT-personeel en management en besproken. Dit document besprak op hoog niveau de noodzaak van regelmatige beveiligingspatches, wanneer de beveiligingspatches zouden uitkomen en hoe ze zouden worden toegepast op onze systemen om het risico voor de database, de applicatie en de eindgebruikers te verminderen.
2. Patch-tijdlijn - Ik heb de luxe om een kloon van onze productiedatabase te hebben, alleen voor gebruik door de DBA en voor niemand anders. Mijn tijdlijn begint daar. Binnen een week na de release van de CPU moet ik de CPU toepassen op mijn DBA-database en eventuele problemen oplossen. Met twee weken na de CPU-release, moet ik de patch toepassen op onze ontwikkelingsdatabases. Binnen een maand na de release van de CPU moet ik de patch toepassen op de Test and Stage-database. En tot slot, binnen 6 weken na de release van de CPU, moet ik de patch op de productie hebben toegepast. Dit is slechts mijn tijdlijn en wat werkt in onze omgeving. Uw tijdlijn kan anders zijn. Maar het is belangrijk dat iedereen de tijdlijn begrijpt en dat de tijdlijn twee schijnbaar tegenstrijdige dingen doet:1) de patch langzaam toepassen zodat eventuele database- of applicatieproblemen worden opgelost voordat verder wordt gegaan met de volgende stap in de tijdlijn. Zodra de patch in productie is, zouden er geen verrassingen moeten zijn en het vertrouwen dat de patch niets zal breken. 2) past de patch snel genoeg toe zodat gaten in de beveiliging binnen een redelijke tijd worden gedicht. In mijn omgeving is zes weken tot productie langzaam genoeg om problemen op te vangen, maar ongeveer net zo snel als we ons prettig voelen. Uw omgeving heeft mogelijk andere tijdlijnen.
3. Log It – Ik ben er sterk van overtuigd dat patches moeten worden gedocumenteerd in een soort wijzigingslogboek. Met het logboek zou u in staat moeten zijn om terug te gaan en precies te zien wanneer elke patch op elke database is toegepast. Dit kan een lange weg gaan bij het diagnosticeren of een patch verantwoordelijk was voor een probleem. Als ik een ticket krijg dat een procedure fouten krijgt en het probleem werd voor het eerst opgemerkt op 1 mei, dan kan ik het wijzigingslogboek bekijken. Als ik de patch op 30 april heb toegepast, heeft de patch mogelijk het probleem geïntroduceerd. Maar als ik de patch op 2 mei heb aangebracht en het probleem was een dag eerder aanwezig, dan is de patch niet de oorzaak van het probleem. Sommige organisaties hebben al een mechanisme voor wijzigingscontrole en het Oracle-patchlogboek zou binnen die structuur moeten passen.
4. Test/Test/Test – Als DBA hebben we de plicht ervoor te zorgen dat wijzigingen die in de productie worden doorgevoerd een hoge mate van zekerheid hebben dat de applicatie niet kapot gaat. Het is van vitaal belang om uw wijzigingen te testen en patches zijn niet anders. Als u uw patch-tijdlijn niet doorloopt, heeft u niet voldoende tijd om te testen en als er een probleem is dat de patch in uw omgeving heeft geïntroduceerd, zou het zelfmoord zijn als u niet voldoende zou testen voordat u in productie ging.
5. Back-ups - Men moet een back-up maken van de database en de Oracle-homedirectory die wordt gepatcht voordat de patch wordt toegepast. U weet nooit of u op een of beide gebieden terug moet naar een vorig punt vóór de patch. Men zou af en toe de herstelmethodologie moeten testen of patches ruim voor productie moeten verwijderen. Deze test hoeft niet per se een keer per kwartaal te worden uitgevoerd, maar moet minimaal een keer per jaar zijn.
Ik denk dat die over de belangrijkste gedachten die ik over het onderwerp had, dekken. Als je vragen/opmerkingen hebt, laat het me weten.