データベース・アクセス監視［後編］　～情報システムに関するセキュリティ対策の最新動向

　個人データの漏洩や業務データの改竄といったインシデントへの対策として、「IBM Security Guardium Data Protection for Databases」（以下、Guardium）を用いたデータベース･アクセス監視を2回にわたって紹介する。前編ではGuardiumのシステム構成について解説したが、後編では具体的にGuardiumの機能を使ってどのように監視を実現するかを解説する。

 

 

　本稿で述べるデータベース･アクセス監視とは、組織が所有するデータベースが安全に利用されていることを確認するプロセスの一環である。安全の定義には多様な考え方があるが、ここではデータベースを含んだシステムの設計や運用プロセスに関する標準として国家や業界・企業などが定める要件を満たす状態、を指すものとして説明する。

 

　これらの要件では、単にデータベースへのアクセスログ保存にとどまらず、以下のような監視を定めていることがある。

　プライバシーなど慎重に扱われるべきセンシティブ情報に対して、誰が・いつ・どのようにアクセスしたのかを監視し、データベースの設計に含まれていない不正なアクセスがないことを確認する。

　データベースの管理権限を用いたアクセスを監視し、不正な操作がないことを確認する。このような操作の例としては、テーブルやビューの作成、GRANTやREVOKEといった権限の変更、ログの初期化やレベルの変更などがある。

　データベースへのすべてのアクセスを監視し、不正と関連する操作がないことを確認する。このような操作の例としては、繰り返し失敗している認証の試行などがある。また何らかのインシデントが発生した際には、その過程や影響範囲の調査のためにアクセスの記録を提供する。

 

　Guardiumは上記のような監視を実行するための機能を提供するが、実際に適切な監視を行うには、個々のデータベース･アクセスをその属性（タイムスタンプ、クライアント・アプリケーションやユーザー、アクセス先テーブル、SQLコマンドなど）によって分類し、それぞれにどう対応するかをシステムに合わせて決定する必要がある。

 

　この決定には前提として、監視対象とするデータベース内の重要なデータを含むテーブル名や、それにアクセスするアプリケーションの仕様、運用プロセスでの操作内容やログレビューの確認基準に関する情報が必要である。

 

　このためGuardiumによる監視システムの構築は、要件を明確にするセキュリティ担当者とGuardium導入担当者に加え、データベース設計、アプリケーション設計、システム運用、ログレビューなど、各役割を担うメンバーの協力を得て進める必要がある。

 

 

　前編で解説したとおり、GuardiumはS-TAPと呼ばれるエージェント・ソフトウェアを利用して、データベース･サーバーとデータベース･クライアントの通信をキャプチャすることでデータベース・アクセスを監視する。

 

　キャプチャされる通信は、図表1に示すように、主に次の3つのアクティビティで構成される。データベースへの接続や切断など、図表1のモデルに含まれない通信も実際には存在するが、ここでは省略する。

 

　クライアントからデータベースへ送信される検索や更新などのリクエスト

 

　SQLクエリに応じてデータベースからクライアントへと送信される検索結果などのレスポンス

 

　データベースで発生する認証エラーやSQLエラーなど

 

　Guardiumのコレクタは、S-TAPから受信したアクティビティ情報をリアルタイムに分析し、監視の要件に該当するかを評価し、対応するアクションを実行する。また受信したアクティビティのログを保管し、過去の蓄積を利用した分析やレポート生成を実行する。

 

　典型的なユースケースでは、SQLクエリのアクセス先テーブルやクライアント情報を分析して、センシティブ情報へのアクセスや特権ユーザーによるアクセスであればログを保管し、さらにそれがアプリケーション設計や運用プロセスにないアクティビティであればアラートを発行する。またレビュアーによる定期的なログ確認のために、蓄積したログからレポートを生成する。

 

　実際にこのような使い方をするには、図表2に示すコレクタの機能コンポーネントに対して、要件に応じたカスタマイズの実施が必要である。以下に、各機能コンポーネントについて、カスタマイズの例や考慮点を挙げながら解説する。

 

 

　コレクタに収集された各アクティビティ情報は、そのクライアント情報などの属性を自動的に分析する。

 

　セキュリティ･ポリシー（以下、ポリシー）は、分析された属性を使ってそのアクティビティを評価し、結果に対応したアクションを実行する機能である。ポリシーにはカスタマイズによって設定される複数のポリシー・ルール（以下、ルール）が含まれており、各ルールはアクティビティに対する評価の条件（図表3）と、条件に一致した場合に実行されるアクション（図表4）で構成されている。

 

　また、ルールにはアクティビティに対応して3つのタイプがあり、図表3、図表4のように設定可能な条件とアクションがタイプによって異なる。以下にカスタマイズする際の基本的な方針を含めて、タイプごとに説明する。

 

　SQLクエリの評価に用いられるルールである。データベース・アクセスの監視要件を考慮して、ログのレビューが必要なアクティビティの情報を保管するようにアクションを設定する。一方でコレクタのパフォーマンスやディスク容量も考慮し、定期バッチアクセスなどのアクティビティは実行時刻など最小限の情報のみを保管するよう設定する。

 

　また、クライアントの情報やSQLの内容から不正なアクセスによるアクティビティと評価された場合は、十分な詳細度でログを保管したうえで、アラートを発行するようにアクションを設定する。

　

　例外の評価に用いられるルールである。基本的にはすべてのログを保管するようにアクションを設定する。このうち、とくに不正なアクセスによる例外と評価された場合は、アラートを発行するように設定する。

 

　結果セットの評価に用いられるルールである。クレジットカード番号のような固定フォーマットのデータの取得や、一度に大量のデータを取得するアクセスなどを特定してログに保管するように設定できるが、デフォルトでは機能が無効にされている。

 

　結果セットの評価はシステムに大きな通信量と負荷を発生させるため、データベース・アクセスが非常に限定されている環境でのみ利用するよう推奨される。

 

　典型的なカスタマイズでは、図表5のように複数のルールをポリシーに設定することで、データベース･アクセスの監視要件に必要なログの保管や、アラートによる確認の要請を実現する。具体的なルールを検討する際には、データベースやアプリケーションの設計者から協力を得て、条件設定の妥当性を確認する必要がある。

 

 

　ルールでとくに重要なのは、ログの保管を行うアクションである。ポリシーにはアクションを設定しなくても、アクティビティの基本的な情報をログに保管する非選択的な監査証跡という機能があり、簡単に利用できる。しかし監視要件に含まれないアクティビティは無視し、不正アクセスに関連する可能性のあるアクティビティログは詳細度を上げるなど、重要度に合わせてアクションにより調整するのが望ましい。

 

　またルールの条件設定では、アクティビティの情報に含まれるクライアントIPやユーザー名などが、事前に登録してあるグループに含まれているかどうかでも評価できる。グループを利用することで、ポリシーをシンプルに設定できるが、システム環境や運用担当者の変更に合わせてグループのデータメンテナンスも必要になる。このためデータベースとGuardium双方の運用部門の連携が重要である。

 

 

　アラートは、不正なアクセスあるいはその兆候があると評価された場合に、セキュリティオペレーターへ通知し、確認を要請する機能である。Guardiumのアラートには、次の2種類の方式があり、それぞれカスタマイズにより実現する。

 

　ポリシーによってアクティビティが不正なアクセスに関連していると評価された場合に、アクションにより発行される。

 

　ポリシーによって保管されたログを、後述するクエリによって指定期間を遡って検索し、条件に該当するログの件数が閾値を満たした場合に発行される。クエリによる検索は、スケジュールに基づいて定期的に行われる。「閾値アラート」と表現されることもある。

 

　不正なアクセスとしてアクティビティが評価される例としては、運用で定められたアクセス元以外からの特権ユーザーや管理コマンドの使用、規定のアプリケーション以外からのセンシティブ情報へのアクセスなどがある。これらを特定できる条件とアラートのアクションをポリシーのアクセス・ルールに設定することで、リアルタイムアラートとして通知される。

 

　また特定の例外が繰り返し発生している場合も、SQLインジェクションやパスワードの総当たりなどの攻撃が試行されている可能性があるので、例外ルールによるリアルタイムアラートまたは例外の件数に応じた相関アラートによる通知を設定することがある。

 

　ただしデータベースが通常の状態であっても、例外がある程度発生することは一般に珍しくはないので、十分に検討せずにこのようなアラートを設定した場合、大量の通知が発行されて運用業務を妨げる懸念がある。

 

　そのため例外に関するアラートを設定する場合は、データベース管理者やセキュリティ担当者を交え、データベースにおける例外ごとのエラーコードの意味と、その環境でのリスクの程度を踏まえながら、閾値を検討すべきである。

 

　なお、リアルタイムアラートは相関アラートに比べて処理の軽さと即時性の点で優れている。一方で相関アラートはクエリにより複雑なアラート条件を定義できるので、要件に応じて使い分けるのが望ましい。

 

 

　レポートは、セキュリティオペレーターやログのレビュアーがアクティビティログを参照し、不正なアクセスがないことを確認するための機能である。Guardiumのレポートは、参照者の確認の観点に合わせてログを抽出できるよう、クエリをカスタマイズしたうえで利用する。

 

　コレクタに保管されているログは、S-TAPがキャプチャした通信の生のデータ形式ではなく、エンティティとその属性からなる論理的なビューを通して参照する。レポートで使われる代表的なエンティティを図表6に示す。

 

　クエリは、ログからどの項目をどの条件で抽出するかを定めるもので、図表7のようにGUIツールでエンティティの属性を選択しながら設定できる。なおクエリは、相関アラートでのアラート対象アクティビティの件数取得にも利用される。

 

　アラートの通知を受けたセキュリティオペレーターは、レポートを参照して、関連したアクティビティが不正なアクセスに関連するかどうかを確認する。これは場合によってはデータベース・アクセスのログだけではなく、クライアント・アプリケーションや作業用端末のログなども含めて確認する必要があるので、外部ログを調査するうえで鍵となる情報も含んだクエリを設定しておくことが重要である。

 

　また特権ユーザーのアクセスを確認するためのレポートでは、その操作内容が承認された運用プロセスに対応しているのかをレビュアーが判断せねばならない。これには定期的に行われる定型作業だけでなく、変更管理に沿った1度だけの作業なども含まれるため、レビュアーに加えてデータベース運用部門のメンバーとも協力し、レビューの判断基準と合わせてクエリの項目を検討するのが望ましい。

 

　なお、特権ユーザーIDの割り当てを管理する「IBM Security Privileged Identity Manager」（以下、PIM）との統合により、PIMに保管されているデータベースへのアクセス申請ログと、Guardiumのデータベース・アクセスのログをマッピングさせたレポートも自動作成できる。レビュアーが確認すべき特権ユーザーアクセスの件数が多い場合は、これにより効率的なレビューが実現できる。

 

 

　監査プロセスは、レポートを使った定期的なレビュープロセスを支援する機能である。監査プロセス機能を用いると、スケジューラにより定期的にレポートが自動生成され、ワークフローで設定されたレビュアーにレポートの確認を促すよう通知される。

 

　レビュアーはレポートを確認し、GuardiumのGUI上でそれにサインオフ（署名）することで、監査プロセスとして履歴を残せる。

 

　また、レポートのレビューをGuardium外部で運用する場合には、レポートのファイルを外部データストアに定期的に転送するような設定も可能である。

 

＊

 

　以上、本稿ではGuardiumのデータベース・アクセス監視機能とその使い方を解説した。適切なデータベース・アクセスの監視には、データベースやクライアントの設計、システムの運用プロセスなどを把握しているメンバーの協力を得たうえで、アクティビティの評価やアラートの発行、レビューの確認観点などについて、環境に合わせた基準を設ける必要がある。

 

　とくに新規システムのデータベース･アクセス監視を検討する際には、構築段階でこれらの基準を適切に設けるのは難しいので、ポリシーやレポートの設計はシステムの実稼動と並行しながら進めることもある。

 

　データベース･アクセス監視の要点を理解し、適切な体制とスケジュールを設けながら、Guardiumを活用いただきたい。

 

◎「データベース・アクセス監視［前編］　～情報システムに関するセキュリティ対策の最新動向」はこちら

････････

 

 

アイデンティティ･アクセス･マネジメント、アプリケーション・セキュリティ、データ・セキュリティを中心としたセキュリティエリアでのシステム構築プロジェクトや技術支援活動に従事。近年はクラウド環境でのセキュリティ・ソリューション活用を推進するために活動中。