多数のSQLデータベースを管理する者として言うと、わたしは自分のデータベースすべてにパッチをすべて適用することはしていない。理由の1つは、自分が使っていない機能にパッチを適用する必要はないということだ。このパッチ適用を省けばダウンタイムとテストの手間が省ける。加えて、前述のブログ筆者と同じく、パッチのインストールによって、それ以前に導入したバグフィックスなどが壊れてしまうことへの不安がある。

　ただし、OracleのCPUを拒むことには幾つか深刻な危険も伴う。開発環境で働く者にとっては、パッチ適用のメリットはほとんどないと思えるかもしれない。しかし、実稼働データベースに比べればダウンタイムは問題ではない。しかも、開発と実稼働環境との間の同期の問題もある。未パッチのシステム上で開発されたソフトウェアは、完全にパッチを当てた実稼働システムでは動作しないかもしれない。

　データベースの中には「カーラジオ局防御」の例えが当てはまるものもある。認証を受けないユーザーにはアクセスできないデータベースも存在する。しかし、それが単純にすべてのパッチを拒否する理由になると言い切れるだろうか。内部から悪用可能なセキュリティホールの修正パッチはどうだろう。社内システム経由でデータベースにアクセスできる人間は全員が信用できるのか。小さな会社なら信用できるかもしれないが、そうでなければ何らかのアクセスコントロールを掛けておくことが大切だ。必然的に、信用できないインサイダーを寄せ付けないため、これらコントロールに適切なパッチを当てることだ。

パッチ拒否に正当性はあるか

　Sentrigoの調査がOracle管理者の代表的な層をサンプリングしているのかという疑問もある。しかし、たとえアップデートを一切インストールしていない回答者が66％ではなく33％だったとしても、不安要因であることに変わりはない。この結果は、アップデート徹底拒否の姿勢を示しているからだ。多くのデータベースがアップデートに含まれるパッチを一切必要としないというのは考えにくい。

　アップデートをパスするという決定を誰が許可しているのかという疑問もわく。この決定は文書化されているのか。そこにはパッチの一覧と、それぞれのパッチが不要な理由が説明され、監査用の記録を残して説明責任を果たせるようになっているのか。

　組織の種類によっては、ISO/IEC 27002、SOX法（サーベンス・オクスリー法）、HMG InfoSec Standard No. 2といった規定のコンプライアンス要件として、こうした文書が必要になる。Oracleパッチ導入を担当している管理者の上司は、後に正当性を証明する必要が生じた場合に備え、パッチを適用しないときは文書作成を検討した方が賢明かもしれない。

パッチを怠った代償

　自社のデータベース管理者はデータベースセキュリティ確保の職務を果たしていると、多くのCIOやCISO（最高情報セキュリティ責任者）が考えている。多くの組織では確かにそうかもしれない。しかし中には、データベースは外部からアクセスできないという誤った認識に基づき、管理者がパッチを無視しているケースがあるかもしれない。外部からの侵入テストを行う会社が定期的にテストを実施しているのは、そうした認識があるからだ。

　小さな会社ではデータベース管理者がきっぱりそう言い切れる立場にいることも十分あり得るが、この点を誤れば相当の代償を払うことになる。米連邦取引委員会（FTC）とGuess（衣類ベンダー）のケースは警鐘と受け止めるべきものだ。

　同社のWebサイトにはSQLインジェクション攻撃に利用できる脆弱性が見つかったが、この脆弱性には修正パッチがあることが分かっていた。従ってGuessは、FTCに科せられた和解条件をのまなければならなかった。この和解で同社がつぶれることはなかったが、IT部門がかなりの間、肩身の狭い思いをしたことは想像に難くない。高くついた問題は、簡単に回避することができていたはずだ。

　自分が許認可の権限を持ったOracle管理者で、全データベースの全接続について把握しており、「The Oracle Hackers Handbook」の著者デビッド・リッチフィールド氏のようなOracle専門家をフォローしていて、最近のSQLインジェクション攻撃のような新しい展開が発生次第すぐに把握できているのなら、自分のデータベースは安全でありOracleのアップデートは不要だと言い切ってもいいだろう。

　しかしもしそうでない場合、Oracleのアップデートを見極めて自分のアーキテクチャに当てはまるものをすべてインストールする手順の作成を考えた方がよさそうだ。パッチをすべて導入しない場合はいつ、どのような理由で導入しなかったかを文書に記しておくことだ。

　Oracleデータベースのような複雑なものにパッチを当てる担当者には同情する。しかし、公開済みのアップデートで修正できていたはずの脆弱性を突いたセキュリティ問題にもし会社が見舞われた場合、同情してもらえる余地はほとんどないだろう。

本稿筆者のマイケル・コッブ氏は、データセキュリティおよび解析に関するトレーニングやサポートを提供するITコンサルティング会社、Cobweb Applicationsの創業者兼マネージングディレクター。CISSP-ISSAP（公認情報システムセキュリティプロフェッショナル―情報システムセキュリティアーキテクチャプロフェッショナル）の資格を持つ。共著書として『IIS Security』があり、主要なIT出版物に多くの技術記事を寄稿している。