目次


Guardium ポリシー作成の基礎知識

Guardium利用時のポリシー設定に関する基礎知識

Comments

はじめに

IBM InfoSphere Guardium (以下Guardium)は、監視対象データベース・システムに殆ど負荷を掛けること無く、DBAを含む全てのユーザーのデータベースへのアクセスを監視することができます。さらに、様々なデータベースのアクティビティーログを一元管理し、豊富な形式を用いて監査レポートの作成が行えます。

この記事では、Guardiumに関する基本的な操作や機能を理解していることを前提として、ポリシーの設定とその効果に関して説明します。事前に「InfoSphere Guardium アーキテクチャー」および「InfoSphere Guardium によるデータベースの監視を開始する」を参照してください。

Guardiumの構成とポリシーの影響

Guardiumはローカルアクセスを含む全ての経路から発行されるデータベース・アクティビティーログを監視し保管することが可能です。しかし、不必要なログの監視や取得は、エージェントとコレクター間のデータ転送量が過大になるためネットワーク帯域を消費し、ログ保管のためコレクターのディスク領域も大量に消費します。Guardiumコレクターに保管されたレポートを参照する場合でも、大量のログからのデータの抽出は多くの時間やリソースが必要となります。これを防ぐために、要件に合わせた最適なポリシーを設定することが重要となります。

以下の図1はGuardiumの利用環境におけるデータの流れと、設定したポリシーにより影響を受けるポイントを示しています。

図1.Guardium の一般的な構成と影響を受けるポイント
Guardium の一般的な構成と影響を受けるポイント
Guardium の一般的な構成と影響を受けるポイント

以下、ポリシーにおける設定項目に関して説明します。

1. エージェントからコレクターへの送付データの絞りこみ

無視アクションの利用

特に設定をしない場合には、エージェントは監視対象のDBのローカルアクセスを含むSQL実行ログをすべてコレクターに送付します。しかし、通常のお客様要件では、既定のアプリケーションやバッチ処理から実行されるSQLは事前に内容がわかっていること、アプリケーション側でユーザーの操作ログを別途取得していることから、Guardiumにてログを保管する必要がない場合が殆どです。このような接続に対しては、S-TAPからコレクターへのSQLやその応答結果の送信を抑制する「S-TAPセッションを無視」アクションを適用します。

無視アクションによりエージェントからコレクターへのデータ転送量が減少します。さらに、コレクターによる処理負担の軽減といった効果を期待できます。

図2.ルールにおける無視アクションの設定
ルールにおける無視アクションの設定
ルールにおける無視アクションの設定

無視アクションは、無視する対象に応じて柔軟に設定することが可能です。要件に合わせて適用するルールを選択してください。

表1.無視アクションとその内容
無視アクション内容
S-TAPセッションを無視SQLステートメントおよび応答結果(結果行、SQLコード等)をS-TAPからコレクターに送信しません。負荷削減効果を最も期待できます。
セッション毎に応答を無視コレクターへのSQL応答結果の送付を抑制します。SQLステートメントは送信されます。
セッション毎にSQLを無視コレクターへのSQLステートメントの送付を抑制します。SQL応答結果は送付されます。
セッションを無視SQLステートメントおよび応答結果はS-TAPからコレクターに送付されますがコレクターですべて無視されます。
コレクターへのデータの送信は行われることに注意してください。

なお、「セッションを無視」アクションは、セッション単位で判定され適用されます。DBセッションの接続時間が非常に短い環境では、「セッションを無視」アクションが適用される前にセッションが終了する場合があります。過多なセッションの貼り直しはDBへの負荷を無用に高める原因となりますので、コネクションプールなどの利用をご検討ください。

各アクションの詳細についてはGuardiumヘルプの「適切な無視アクションの使用方法(https://コレクターのIP:8443/help/html/how_to/topics/how_to_use_the_appropriate_ignore_action.htm)」を参照してください。GuardiumのヘルプはコレクターのGUIから利用することができます。

2. 処理の対象の絞り込み

クイック解析

コレクターは、エージェントから送信されてきたSQL文字列を解析し、そのSQLを実行したユーザー、対象となるテーブル/列/条件を詳細に分析します。クイック解析アクションは、コレクターによるSQLの解析を簡略化することでコレクターにより多くのSQLの解析処理を可能にする機能です。

例えば多くの場合、データベース管理者がアクセスしたテーブル情報は監視の観点から必要である一方、対象列などの情報は必要とされていません。このような場合には「クイック解析フィールドなし」アクションを利用することによりSQLの解析を抑制することが可能です。

図3.クイック解析アクションの設定
クイック解析アクションの設定
クイック解析アクションの設定

以下は「クイック解析フィールドなし」アクションが適用されたセッションを「全詳細ロギング」アクションでログとして取得したレポート例となります。

図4.クイック解析フィールドなしが適用されたSQLのレポート
クイック解析アクションの設定
クイック解析アクションの設定

「Full Sql」としてはSQL文全体が取得されていますが、「Sql」としては列や条件に関する情報がカットされていることが確認できます。

Guardiumで利用可能なクイック解析機能は以下のとおりです。

表2.無視アクションとその内容
解析アクション内容
クイック解析SQLステートメントの条件式を解析しません。
クイック解析フィールドなしSQLステートメントの列情報も解析しません。クイック解析よりも負荷削減効果を期待できます。
クイック解析ネイティブz/OS用 S-TAPでのみ利用するクイック解析機能です。

「クイック解析」アクションも「セッションを無視」アクションと同様に、セッション単位で判定され適用されます。セッションに対してクイック解析アクションが適用される前に実行されたSQLはクイック解析されないことに注意して下さい。

3. ログ対象データの絞り込み

デフォルト監査動作の決定

Guardiumでは、以下の様な値のないSQLステートメントをSQLの構造体と定義しています。

 
SELECT id, name, address FROM customer WHERE id = ?

コレクターは、エージェントから送信されてきたSQLを除外するルール(アクション)がポリシーに定義されていない限り、すべての SQL の構造体をログに記録します。これはポリシー作成時のデフォルトの動作であり「非選択的な監査証跡」ポリシーと呼ばれています。これに対して、「選択的な監査証跡」ポリシーはこの逆の動作となります。つまり、ルールで取得が定義されたSQL以外は、SQL の構造体を記録しません。結果として、不必要なログの取得を抑制することが可能になります。

Guardiumの導入段階においては受信確認を目的として「非選択的な監査証跡」を選択することは効果的ですが、運用においてポリシーが確定した場合には、「選択的な監査証跡」の利用をおすすめします。

図5.「選択的な監査証跡」の設定画面
「選択的な監査証跡」の設定画面
「選択的な監査証跡」の設定画面

まとめ

本稿では、Guardiumのポリシーの設定とその効果に関して説明を行いました。ポリシーにおける各アクションの効果を理解して最適なポリシー設定を行うことで、エージェントとコレクター間のデータ転送量だけでなく、コレクターのログ保管用ディスク領域も抑制できます。その結果として、品質の高いDB監査環境を実現できます。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=978359
ArticleTitle=Guardium ポリシー作成の基礎知識
publish-date=07312014