近年、企業からの個人情報流出が大きな社会問題となっている。その原因としては外部からの不正アクセスやコンピュータウイルス感染のほかに、内部の人間による操作ミスや意図的な漏洩による流出が増えている。
外部からの不正アクセスやコンピュータウイルスに対してはファイアウォールやアンチウイルスソフトなどの対策が効果的と考えられるが、内部の人間による正規アクセスからの漏洩には効果が薄い。それゆえ、情報を保存しているデータベースに対して日常的に監視できる環境を構築し、データへのアクセスを細かくチェックすることが重要である。
本稿ではそうしたデータベースの監視を、「IBM Security Guardium Data Protection for Databases」（以下、Guardium）を用いて実現する方法について、2回に分けて紹介する。今回は前編として、Guardiumの概要と全体構成、設計時の考慮点を解説する。
Guardiumの概要
Guardiumは、重要データが保管されているデータベースへのアクセスをリアルタイムに監視し監査する機能を提供する製品である。
機能としては、大きく分けて「記録」「警告」「集計・レポート」の3つがあり、データベースへのアクセス情報をGuardiumに記録し、アクセスに問題がある（Guardium側で指定した条件にヒットした）場合は、警告を発することができる。さらに蓄積したアクセス情報を表やグラフ形式に変換し、Webブラウザなどで監査・参照することも可能である。
製品のアーキテクチャ
Guardiumはアプライアンスとエージェントで構成され、データベースに導入したエージェント（「S-TAP」と呼ばれる）を介してデータベースへのアクセス情報をアプライアンスに取り込み、分析・保護を行う。
◆ アプライアンス
アクセス情報の分析やレポートを行うためのサーバーで、次の3種類に大別される。
● コレクタ
監視対象のデータベースへのアクセス情報をリアルタイムに監視し分析を行うのがコレクタである。そのアクセス情報を、データベースサーバーに配置されたS-TAPから受け取っている。
● アグリゲータ
アグリゲータは、コレクタにおけるレポート機能の負荷軽減や、複数のコレクタのレポートを結合する機能を提供する。情報は、S-TAPからではなくコレクタから受け取る。複数のコレクタを利用する場合、必須ではないものの、使用が推奨されている。大規模な環境では複数のアグリゲータを配置する場合もある。
● セントラルマネージャ
セントラルマネージャは、複数のGuardiumアプライアンスを管理するためのアグリゲータである。単一コンソールから、パッチのインストール、S-TAPなどのソフトウェアのアップデート、レポートに利用されるクエリやユーザーなどの管理を、Guardium環境全体に対して行える。必須ではないが、複数のコレクタを利用する場合、使用が推奨されている。
◆ エージェント
エージェントは監視対象のデータベースサーバーに導入するコンポーネントである。データベースサーバーからGuardiumアプライアンスへ通信する際に利用される。次の2つの機能がある。
・ S-TAP：監視とアクセス情報のGuardiumへの送付を行う。
・ GIM：エージェントのアップデートやインストールをアプライアンスから実施可能にする。
システムの全体構成
データベースの監視環境をGuardiumアプライアンスを用いて構築する場合、監視対象のデータベースサーバー（エージェントであるS-TAPを導入する）とGuardiumアプライアンスのほかに、DNSやNTP（Network Time Protocol）サーバーの用意が必要になる（図表1）。
また、Guardiumで発生したアラートを通知する先の監視サーバーや、データベースのアクティビティの記録を長期間保存するためのファイルサーバー、データベースユーザーの詳細を確認するためのActive Directory（任意）など、いくつかのコンポーネントが必要になる場合もある。
Guardiumアプライアンスの構成
Guardiumアプライアンスは、監視するデータベースを含むシステムの規模により、3タイプの構成が考えられる。
◆ 基本構成（スタンドアロン）
1つのデータセンター内にあるデータベースを監視する場合に使われる基本的な構成である。複数のS-TAPに対して1台のコレクタが対応し、監視・分析・ロギングを行う。レポーティング機能などについてもコレクタで行う（図表2）。
◆ 中規模構成
複数のデータセンターにまたがるデータベースを監視する場合に使われる構成。1つのデータセンターにあるS-TAPに対して1台のコレクタが対応し、監視・分析・ロギングを行う。また、各データセンターのコレクタをアグリゲータ（セントラルマネージャ）で横断的に管理する。レポーティングに関してもアグリゲータ側で実施する。
◆ 大規模構成
中規模環境よりもさらに大規模なシステムのデータベースを監視する場合に使われる構成。各データセンターのコレクタをアグリゲータで接続するところまでは中規模環境構成と同様だが、さらに複数のアグリゲータをセントラルマネージャで管理する構成となっている。
Guardiumコレクタの冗長化構成
コレクタは、エージェントから送付されたデータベースのアクティビティを記録し、監視・監査する製品である。コレクタが停止した場合、その間のデータベースに関わるアクティビティは記録されず、セキュリティや監査面で問題となる可能性が高い。そのため基本的に冗長化が推奨される。
冗長化についてもいくつかの構成が可能だが、一般的にはフェイルオーバー構成を用いる場合が多い（図表3）。
◆ フェイルオーバー構成
複数台あるコレクタに対しプライマリおよびセカンダリの設定を行い、平常時はプライマリ側に対してのみアクティビティの送付を行う。障害時はセカンダリ側に対してアクティビティを送付し、プライマリが復帰すると再びプライマリ側にのみアクティビティを送付するように切り替わる。
◆ ロードバランシング構成
複数台あるコレクタに対し、アクティビティを分散して送付する構成である。アクティビティは複数のコレクタに分散してしまうが、負荷分散が行えるメリットもある。
◆ ミラーリング構成
複数台あるコレクタに対し、すべてのアクティビティを送付する構成である。複数台あるコレクタの各々がすべてのアクティビティをロギングしているので、コレクタ障害時もすべてのログが確認できるが、負荷が最も高い構成となる。
エージェントのコンポーネント
エージェントがコレクタにデータベースのアクティビティ情報を送付する方法は複数あり、システムの要件によって使い分ける必要がある。
◆ K-TAP、A-TAP
K-TAPまたはA-TAPを利用した場合、データベースへのアクセス情報をOSの共有メモリやネットワーク層からキャプチャする（図表4）。
◆ DB2 EXIT
DBMSがDB2の場合、DB2 EXITの利用も可能である。DB2内の通信バッファ内でデータベースへのアクセス情報をキャプチャするため、ネットワーク層で通信の暗号化が行われている場合でもキャプチャできる（図表5）。
Guardium導入時のサイジングに関する考慮点
Guardiumアプライアンスのディスクなどをサイジングする場合、監視対象のデータベース数などから一意に計算する方法はない。データベースへのアクセス量のほかにも、次のような考慮点が考えられる。
◆ 監査対象のユーザー
特権ユーザーや特定のアプリケーションを利用するユーザーをGuardiumの監視対象とした場合、ロギングされる情報が増加する傾向がある。そのため、ロギングの容量を抑えたい場合は、実際の操作者（ユーザー）に限るなどの考慮が必要となる。
◆ 監査対象のデータ
データベース内に含まれるすべてのデータを監視対象とした場合、ロギングされる情報は膨大になることが予想される。監視対象を機密情報などの重要なデータに絞ることによってログの容量の抑制を考慮する必要がある。
ロギングに関して、Guardiumには選択的な監査証跡と非選択的な監査証跡の2つの選択肢がある。非選択的な監査証跡を選んだ場合、基本的には監視対象のデータベースへのアクセスに関わるすべてのログを取得することになる。Guardiumの環境構築時に受信確認の目的で非選択的監査証跡を選ぶこともあるが、実際の運用では選択的監査証跡を選び、条件に合致した情報のみをロギングし、ディスク使用量の増大を防ぐことが望ましい。
Guardium導入のロケーションに関する考慮点
◆ コレクタのロケーション
コレクタには、監視対象のデータベースサーバーからリアルタイムでアクティビティ情報が送付されるため、可能な限りデータベースサーバーに近いロケーションに配置し、LANの速度で通信できることが望ましい。
◆ アグリゲータのロケーション
アグリゲータは、コレクタと通信し、監視対象のデータベースサーバーとは通信を行わないため、データベースサーバーの近くに配置する必要はない。また、コレクタとの通信もリアルタイムではなくバッチ処理なので、必ずしも近くに配置する必要はない。
◆ セントラルマネージャのロケーション
セントラルマネージャはコレクタやアグリゲータの管理を行うコンポーネントで、監視対象のデータベースサーバーとリアルタイムで通信を行わない。そのゆえ、データベースサーバーやコレクタ、アグリゲータの近くである必要はない。
Guardiumのバックアップに関する考慮点
Guardiumの各アプライアンスでは、アクティビティ情報などのデータを保持するので、ログの増大に伴ってディスク容量が逼迫ひっぱくしてくる。そのため、システムのログの消失を防ぐにはデータのバックアップ・アーカイブが必要である。
バックアップにはさまざまな方法があるが、基本的には外部ストレージを用意し、スケジュールを組んで定期的にログを移動する。システム設計段階で日々増大するログのサイズを想定し、それに合ったバックアップ計画を策定すべきである。
Guardiumの拡張性に関する考慮点
アクティビティ情報などのデータが想定よりも多い場合や、将来的に監視対象のデータベースを増やす場合を考え、Guardiumの導入計画時には、現在のシステムで要求されるものよりも上のスペックを考慮する必要がある。
Guardiumの導入計画では、現在のデータベースへのアクセス情報の量だけでなく、どのユーザーがどのようなログを取得するか、さらにはGuardium自体の冗長性（社内のコンプライアンスを遵守するために、ログの欠損が許されない場合など）なども考慮する必要がある。システムによってGuardiumに要求される機能も変わるので、データベースへの各アクセス情報の特性に応じた監視の必要性の有無など、Guardium担当者、セキュリティ担当者、データベース担当者の3者が連携して慎重に判断してほしい。
◎参考資料：IBM Redbook『Deployment Guide for InfoSphere Guardium』http://bit.ly/is17_secu01
････････
著者｜伊藤 哲也 氏
日本アイ・ビー・エム システムズ・エンジニアリング株式会社
セキュリティ
ITスペシャリスト
2008年、日本IBMシステムズ・エンジニアリングに入社。入社以来、IBMセキュリティのアクセス制御に関するプロジェクトに参画し、技術支援を実施。2015年からはGuardiumを用いたデータベース・セキュリティに関する技術支援を行っている。
