データベースのセキュリティについて解説する本連載。前回まで、データを中心にした多層防御の重要性とそれらを取り巻く物理セキュリティについて説明しました。今回は、守るべきデータに対して何が行われたかを追跡する監査について説明します。

迅速なセキュリティ・インシデントの認識で次の一手を

個人情報や機密情報などの重要なデータを不正アクセスから守るためには、多層防御という考え方が重要であることを第1回で説明しました。加えて、ネットワーク・ファイアウォールによる水際対策だけでなく、それが破られたケースを考慮した物理セキュリティの観点からも説明しました。データに近い層および物理的な層で防壁を施行してデータを守ることで、起こりうるリスクの低減化につながります。

この考え方の中で大切なことは、「各層で施行した予防策を組み合わせることで、少しでもワークファクター(※1)を稼ぐという考え方が重要である」と筆者は考えています。

※1 ワークファクターは聞きなれない言葉かもしれませんが、セキュリティに対してかける労力を意味します。

さて、これまで説明してきたデータ層におけるアクセス制御や物理セキュリティを厳しくし、外部からの攻撃や内部犯行を防ぐことにはやはり限界があります。限界とは、ヒト・モノに対するコストがほとんどです。

例えば、ネットワーク・ファイアウォールやOSなどのアクセス制御において、もし設定ミスやポリシーに漏れがあれば不正なアクセスを許してしまうリスクが生じます。また、悪意のあるユーザーがデータベース上にあるデータを不正入手可能な状態を作りだしていることも好ましくありません。

アクセス制御を用いて防御できればそれが一番ですが、それでも防げないリスクに対する次の一手が、「いかに早くセキュリティ・インシデントを認識するか」というものです。今回は、セキュリティ・インシデントの観点から監査について触れ、多層防御における検知について説明したいと思います。

監査の目的を考える

監査の目的は、トレーサビリティを確保することであり、責任の所在を明確にするための追跡を確保することとなります。つまり、「ある事象を実施したことで生じる結果に対する責任」や「説明を行う行為を確保する」ことが監査を取得する目的となります。

監査はユーザー操作の痕跡を残し、ユーザーの操作に責任を持たせる効果があります。ちなみに、英語のAccountability（アカウンタビリティ）という言葉は、「誰が責任を取るのか?」という意味を表します。

さて、個々の操作に責任を持たせるという意味での監査証跡ですが、オラクルのコンサルタントがお客さまとヒアリングをすると、データベースの監査についてはログをため込んでいるだけという運用を目の当たりにすることがあります。監査ログを有効に活用するための例として、本連載では「検知」という観点を説明します。

検知を行う理由としては「アクセス制御の補完の目的」もあれば「業界標準ルールに準拠するため」など、いろいろあると思います。物理セキュリティを取り上げた第3回で説明しましたが、厳しすぎるルールは場合によっては、企業本来の営利目的を停滞させ、俊敏性の低下、機会損失を与えている可能性があります。また、営利目的でシステムを活用する企業においては、コンプライアンスや業界基準に伴う監査（例えばPCI DSS）準拠が必須となる場合があります。

監査ログを取得する重要性を説明したうえで、どのように取得するかについて紹介しましょう。監査ログは必要な時にすぐに活用することが非常に大事になります。ただ監査ログを取得するだけでは、ディスク容量を消費するだけでゴミになってしまいます。したがって、監査ログを使いやすい状態を構築し、その中から不正操作やその予兆を検出する状態を施行します。

つまり、通常状態と逸脱した状態を判別できる仕組みを構築して、監査ログの兆候を学習し、通常と逸脱を検知する仕組みを構築します。例えば、データベースのパフォーマンスを定期的に監視しておき、CPU使用率が急上昇した場合、CPU使用率が急上昇した事象が「通常状態から逸脱した状態」と言えます。

では、検知はどのように実施すればよいのでしょうか? 情報セキュリティマネジメントのプロセスは一般的に「予防」「検知」「対応」の3つに分類されます(※2)。物理セキュリティやアクセス制御など、インシデント発生(※3)を防ぐことを目的とする対策は「予防」に分類されます。データベースの監査は、これら3つのプロセスの「検知」の対策になります（予兆を検知したり、上述の説明責任が心理的障壁となって「予防」につながったりすることもあるでしょう）。インシデントを検知できるようになって初めて「対応」ができるようになりますので、「検知」の対策である監査が極めて重要であることを理解いただけると思います。

※2 予防、検知、対応のほかに復旧が含まれることもありますが、ここでは復旧は対象外とします。
※3 インシデントとは想定できる事象のことを指し、想定できない事象はアクシデントと呼ばれます。

考慮不足だと危険?　検知のための監査設計を考える

データベースの監査と言っても、「とりあえず取得して定期的にチェックすればOK」という程度の対応では、インシデント検知は難しいでしょう。

例えば、考慮不足により膨大な量の監査ログが取得されると、監査の運用が困難になり、インシデント発生時に初動が遅れたり、最悪の時は見逃してしまったりすることが危惧されます。取得する監査ログが膨大だと、監査ログの書き込み処理によるオーバーヘッドも無視できなくなる可能性があります。十分な監査の設計が行われていないと、機密情報が監査ログに含まれるかどうかも検討されないため、セキュリティリスクを高めることも考えられます。

また、取得した監査ログは一定期間、改ざんや削除から保護する必要があります。監査証跡にインシデント発生を示すような記録がなくても、監査証跡が容易に改ざんできるようであれば、インシデントが発生しなかった証拠としては弱くなり、検知できていない不正操作の存在を否定しきれません。

考え始めると、インシデント検知をするための正しい仕組みをつくることは決して容易ではないことに気付きます。大ざっぱにまとめると、検知のための正しい仕組みには、適切な監査対象の範囲の設定を行い、出力される監査証跡を改ざんから守り、監査証跡を確認する際に異常が検知できることが必要になります。

次回は、検知のための監査の具体的なアプローチについてお話いたします。

森谷 真樹

日本オラクル株式会社 クラウド・テクノロジーコンサルティング統括本部


日本オラクルのコンサルティング部門に所属。データベースセキュリティ製品の導入などを担当。セキュリティ (とくにデータベース周り) の第一人者になれるよう日々勉強中。