これだけは押さえたい! データベースセキュリティ(5) 考慮不足だと危険? データベース監査の設計を考える(後編)

データベースのセキュリティについて解説する本連載。今回も前回に引き続き、データベース監査の設計を紹介します。前編ではインシデント検知に向けた監査設計の重要性を説明しましたが、後編となる今回はインシデント検知に向けた具体的なデータベース監査の設計アプローチを紹介します。

データベース監査を考える際の2つのポイント

前編では、データベース監査は、情報セキュリティマネジメントのプロセス(※1)における「検知」を行うための手段に当たり、インシデント検知に向けた監査設計が重要であると説明しました。

※1 本連載においては、情報セキュリティマネジメントのプロセスを「予防」「検知」「対応」の3つに分類している。「復旧」などのプロセスを含む考え方もあるが、本連載では割愛。

筆者はデータベース監査設計を考える際、次の2つのポイントがあると考えています。

「検知」を強化するための監査設計
「検知」から「対応」へとつなげる監査設計

1に関しては、「検知」そのものを効率的かつ実用的なレベルにまで引き上げるための監査設計を意図しています。前編では、アクセス制御や物理セキュリティ向上による「予防」からの対応にもコスト面（ヒト・モノのコスト）で限界があることから、監査による「検知」の重要性を紹介しました。その「検知」機能を高めるための設計となります。これが1つ目の監査設計ポイントとなります。

2に関しては、「検知」された後の「対応」まで考えた監査設計を意図しています。われわれは任意のインシデントが「検知」された際、そのインシデントを放置するわけにはいきません。当然ながら、適切な「対応」を行う必要があります。これを、本連載の第1回にて紹介された、幼少期の(第1回)執筆者が父親のお金を盗んだ事件を例に考えてみましょう。

父親のお金が盗まれているというインシデントが「検知」された際、父親は何らかの「対応」を行うことを考えるでしょう。では、適切な「対応」を実施するために必要な情報とは、どのような情報でしょうか?

誰がお金を盗んだのか?
犯人はどのように父親の部屋に侵入したのか?
犯人はいつ侵入したのか?

例えば、お金を盗んだのが息子で、父親が寝ている深夜帯に部屋に侵入していることが判明すれば、現場を押さえて教育的指導を行うという「対応」ができます。また、お金を盗んだのが外部犯であり、施錠されていない窓から侵入していることが判明すれば、該当する窓をしっかり施錠し、施錠された窓を開けようとすればアラートが鳴るような防犯対策を具体的な「対応」として行うことができます。

この具体的な「対応」までつなげるための情報を考慮した設計が、2つ目の監査設計ポイントとなります。

では、上記2つのポイントを抑えたデータベース監査として、具体的にどのような監査設計を行う必要があるのでしょうか? 本稿では、それぞれのポイントに対して、具体的な監査設計アプローチをいくつか紹介します。前提として、「監査証跡の一元管理」「監査者と監査対象者の分離」「監査証跡の保護」といった基本的な監査設計アプローチに関しては割愛し、語られることが少ないアプローチについて説明します。

「検知」を強化するための監査設計の具体的なアプローチ

セキュリティ意識の高いお客さまに見られるケースですが、「全ユーザーの全オペレーションをデータベースで監査しておけば取り漏れはない」という指針の下、監査すべきオペレーションをほとんど精査せずに、データベースで監査証跡を大量に取得しているケースがあります。

結果として、監査証跡の大量取得によるデータベースの性能劣化や監査証跡へのアクセス効率低下を引き起こし、必要な時に必要な監査情報を確認できなくなってしまう場合があります。これは、情報セキュリティの3要素(※2)である可用性の低下に該当し、インシデント発生時の「検知」が適切に行われないことにつながってしまいます。

※2 JIS Q 27002では、情報セキュリティとして機密性(Confidentiality)、完全性(Integrity)、可用性(Availability)を3要素として定義している。

では、このような問題を回避するための具体的なアプローチとして、どのような例が考えられるでしょうか? 今回は「監査証跡取得の分割取得アプローチ」を例としてご紹介します。

監査証跡の分割取得アプローチ

業務データに対するオペレーションの監査証跡が大量に生成され、データベースでパフォーマンスの問題が発生しているケースにしばしば遭遇します。こうしたケースでは、周辺アプリケーションからのデータベースへのアクセスはネットワーク経由で行われる点に着目し、ネットワーク経由でのオペレーションとローカル(データベース)でのオペレーションに対して監査証跡を異なる仕組みで取得することで、データベースにおける監査証跡取得の負荷を下げることができます。

これにより、データベースで出力される監査証跡から適切な「検知」につなげることが可能となります。

また、データベースの監査証跡を取得している多くのお客さまが、緊急度の高いインシデントに関しては何らかの仕組みを利用し、それらを「検知」する仕組みを作っていらっしゃいますが、インシデントが発生した後の「検知」に注力しているケースがほとんどです。監査証跡から得られた傾向より、インシデントを事前に検知するような仕組みを構築しているお客さまは多くありません。

今回はインシデントの事前検知につながるアプローチの1つ「監査証跡の可視化（見える化）アプローチ」を例として紹介します。

監査証跡の可視化（見える化）アプローチ

では、どのような情報を可視化する必要あるのでしょうか? 例えば、SQLの実行回数などがわかりやすいと思います。

近年の標的型攻撃では、短時間かつ一気に大量データを取得するのではなく、じっくりと少しずつデータを取得する傾向があります。これは短時間の瞬間的な負荷（スパイク）をなくすことで定常時におけるシステムの傾向状態を見えづらくするためです。機械的に一定の見えにくい負荷がある場合はボットネットのようなマルウェアが操作端末やアプリケーションに組み込まれていること可能性があります。

こうした脅威に対しては、不正につながるオペレーションの「見える化」が重要となります。

「検知」から「対応」へとつなげる監査設計の具体的なアプローチ

冒頭でも紹介したようにインシデントを「検知」した後は、適切な「対応」へとつなげることが可能な監査設計が重要となります。そのためには、監査証跡において4W1H(who「誰が」/what「何を」/where「どこから」/when「いつ」/ how「どのように」)を網羅する必要があります。

データベースにおける監査設計においてよく問題になるのが、who「誰が」を特定できないケースです。すなわち、監査証跡におけるユーザー一意性を担保できないケースです。これはデータベースにアクセスするユーザーが共通ユーザーとして作成されており、データベースで取得される監査証跡にはその共通ユーザーしか出力されず、誰が実施したオペレーションかを特定できないケースを指します。

このようなケースにおいては、どのような監査設計アプローチを取るべきでしょうか?

根本的なID管理方式を変更し、外部認証などを利用することで、データベースの監査証跡でユーザー一意性を確保するアプローチもありますが、影響範囲が大きく現実的でないケースが多いでしょう。今回は、前述の「監査証跡の見える化(可視化)アプローチ」と合わせて実施することが重要となる「多層監査証跡の突合アプローチ」を紹介します。

多層監査証跡の突合アプローチ&監査証跡の見える化(可視化)アプローチ

多層監査証跡の突合アプローチとは、データベースで取得される監査証跡に加えて、他のレイヤー（アプリケーション側やクライアント側）で取得される監査証跡を突合させて情報を保持することで、監査証跡におけるユーザ一意性や監査証跡における必要情報の欠落を補完するアプローチとなります。ポイントは多層監査証跡の突合により、前述の「4W1H」を網羅させることとなります。

では、どのように前述の「監査証跡の見える化アプローチ」と絡めていくべきでしょうか?

当社のコンサルティングサービスでは、多層監査証跡の突合処理の自動化および自動レポート化を推奨しています。セキュリティの完全性（改ざん排除）を確保するため、各種プログラム製品を利用することで、多層監査証跡の突合処理を行って信頼性があるレポートを生成することが可能です。さらに、4W1H(who「誰が」/what「何を」/where「どこから」/when「いつ」/ how「どのように」)が明確に把握できるレポート設計を行います。