約1年半前、私は新しい会社に引っ越して、彼らのDBAとして働き始めました。同社はこれまで、Oracleデータベースにパッチを適用していませんでした。私はここに来てから、ITシステムのセキュリティがより焦点になり、以前に見られたより高いレベルの精査を受けるのを見てきました。 Oracleデータベースの定期的なセキュリティパッチの実装を開始するディレクティブを待つのではなく、積極的に取り組むことにしました。 Oracleデータベースに定期的にパッチを適用する必要がある日が来るでしょう。すでに実装されていると言いたいです。
2012年4月のCPUは先週リリースされたばかりで、これはOracleデータベースに適用する最初のCPUです。最初のCPUを適用する前に、この変更を企業環境に実装する方法について少し考えました。将来、他の誰かが同様の状況に陥った場合に備えて、これらの変更のいくつかを共有することにしました。
1. 3つのD：パッチ適用が開始される前に、パッチポリシーが文書化され、ITスタッフと管理者に配布され、議論されました。このドキュメントでは、定期的なセキュリティパッチの必要性、セキュリティパッチがいつ公開されるか、データベース、アプリケーション、およびエンドユーザーへのリスクを軽減するためにそれらをシステムに適用する方法について大まかに説明しました。
2。パッチのタイムライン– DBAが使用するためだけに、他の誰も使用しないように、本番データベースのクローンを作成できるという贅沢があります。私のタイムラインはそこから始まります。 CPUのリリースから1週間以内に、CPUをDBAデータベースに適用し、問題を解決します。 CPUリリースの2週間で、私はパッチを開発データベースに適用することになっています。 CPUがリリースされてから1か月以内に、パッチをTestandStageデータベースに適用します。そして最後に、CPUのリリースから6週間以内に、パッチを本番環境に適用することになっています。これは私のタイムラインであり、私たちの環境で機能するものです。タイムラインが異なる場合があります。ただし、全員がタイムラインを理解し、タイムラインが2つの一見矛盾することを行うことが重要です。1）パッチをゆっくりと適用して、データベースまたはアプリケーションの問題を整理してから、タイムラインの次のステップに進みます。パッチが本番環境に到達した後は、パッチが何も壊さないという驚きや自信はありません。 2）パッチを十分に速く適用して、セキュリティホールが妥当な時間で塞がれるようにします。私の環境では、本番環境までの6週間は問題を見つけるのに十分遅いですが、私たちが快適に過ごせるのとほぼ同じくらいの速さです。ご使用の環境には他のタイムラインがある場合があります。
3。 Log It –パッチはある種の変更ログに記録する必要があると強く感じています。ログを使用すると、戻って、各パッチが各データベースにいつ適用されたかを正確に確認できるはずです。これは、パッチが問題の原因であるかどうかを診断するのに大いに役立ちます。プロシージャがエラーを受け取り、問題が5月1日に最初に指摘されたチケットを受け取った場合、変更ログを確認できます。 4月30日にパッチを適用した場合、パッチによって問題が発生した可能性があります。しかし、5月2日にパッチを適用し、問題が1日前に存在した場合、パッチは問題の原因ではありません。一部の組織ではすでに変更管理メカニズムが導入されており、Oracleパッチログはその構造に収まるはずです。
4。テスト/テスト/テスト– DBAとして、本番環境に導入された変更に、アプリケーションが破損しないという高い信頼性を確保する義務があります。変更をテストすることは非常に重要であり、パッチも同じです。パッチのタイムラインを通過しないと、テストするのに十分な時間がありません。パッチが環境に導入されたという問題がある場合、本番環境に移行する前に適切にテストしなかった場合、キャリアの自殺になります。
5。バックアップ–パッチを適用する前に、パッチを適用するデータベースとOracleホームディレクトリをバックアップする必要があります。これらの領域の一方または両方で、パッチを適用する前に前のポイントに戻る必要があるかどうかはわかりません。本番環境のかなり前に、復元方法をテストしたり、パッチをバックアウトしたりする必要があります。このテストは、必ずしも四半期に1回行う必要はありませんが、少なくとも1年に1回行う必要があります。
それらは私が主題に関して持っていた主要な考えをカバーしていると思います。質問/コメントがあれば、私に知らせてください。