目次


InfoSphere Guardiumによるアプリケーション・ユーザーの検出

データベース・アクティビティーに関連するアプリケーション・ユーザーを特定する5つの手法について

Comments

はじめに

InfoSphere GuardiumはIBMが提供するデータベース・アクティビティーをモニタリングするシステムです。本システムによって、システムに大きな負荷を与えることなく社内に存在するさまざまなデータベースの監査とセキュリティー管理を実現できます。本システムを活用することで、企業はシステムの負荷とパフォーマンスへの悪影響を最小限に抑え、精密なレベルでデータベース内で発生しているアクティビティーを管理できるようになります。

アプリケーション・ユーザーの検出機能とは、エンドユーザーがどのアプリケーションに基づいてどのデータベース・トランザクションを実行しているのかを見極めるプロセスを指します。本機能を使用するには、エンドユーザーのアクティビティー(アプリケーション・レイヤーからデータベースに至るアクティビティー)をトラッキングする必要があります。データベースの接続処理は比較的負荷の高い処理であるため、アプリケーション・ユーザーがログインするたびに新規のデータベース接続を構築するとパフォーマンスに大きな影響が生じます。この問題を回避するために、アプリケーション・サーバーは再利用可能な一連の接続を構築し、アプリケーションのトランザクション用にこれらの接続を繰り返し使用します。接続プールが構築されると、単一のベース・ユーザーを使用してデータベースにログインします。その後、アプリケーションは、接続プールのユーザー権限に応じて、データベースへのアクセスを行います。

図1. 接続プール経由でデータベースにアクセスする
図1. 接続プール経由でデータベースにアクセスする
図1. 接続プール経由でデータベースにアクセスする

接続をまとめることによって、アプリケーションのスピードを高速化することができます。しかしその一方で、特定のデータベース・トランザクションを実行したアプリケーション・ユーザーの情報が失われます。これは問題です。アプリケーションを使用するエンドユーザーを見極めることは、厳しい監査要件が設定されたあらゆるデータベース環境に必須の機能です。例えば医療業界においては、どのエンドユーザーが保護されるべき電子医療情報(EPHI)にアクセスしているのかを確認することは、アメリカの医療保険の相互運用性と責任に関する法律(HIPAA)を遵守する条件として設定されることがあります。財務処理においては、アプリケーション・ユーザーを明確に検出することによって財務処理のトラッキングと説明責任を改善できるため、2002年に制定されたサーベンス・オクスリー法(SOX)の遵守に役立ちます。

本記事はこの問題を解決するためにInfoSphere Guardiumの設定を行う5種類の手法を説明します。さらに、特定のアプリケーションに対して最適な方法を選択する方法についても検証します。

Guardiumのアプリケーション・ユーザーの検出を行う5種類の方法としては、大きく以下が挙げられます。

  1. 製品に組み込まれたアプリケーション・ユーザーの検出機能を使用する
  2. Guardiumのアプリケーション・イベントAPIによって、ユーザーのスイッチを検出する
  3. ストアード・プロシージャーにおいてパターンを分析する
  4. アプリケーション・サーバー・ベースのS-TAPエージェントを使用する
  5. データベース・サーバーとアプリケーション・サーバーのAPIを使用する

製品に組み込まれたアプリケーション・ユーザーの検出機能を使用する

Guardiumは、Oracle E-Business、PeopleSoft、Siebel、SAP、およびBusiness Objectsをはじめとするさまざまなパッケージ・アプリケーションをサポートします。Guardiumはこれらのアプリケーションについて研究を行い、アプリケーションが実行するSQLのパターンを検証しました。その結果、各アプリケーションがトランザクションの処理中に実行されるSQL文においてユーザーを検出していることが判明しました。SQLに含まれるこのようなパターンを見極めることによって、Guardiumはどのアプリケーション・ユーザーがデータベース・トランザクションを実行しているのか抽出することができます。

Siebelの場合

この機能について検証するために、本記事はSiebel CRMのアプリケーション・ユーザーの検出について詳細に説明します。Siebelでトランザクションが発生すると、影響を受けるテーブルにおいてエンドユーザーを示すフィールドが更新されます。Siebelのトランザクションの処理中にこの情報を抽出するようにGuardiumの設定を行うことができます。

例えば、Siebelで売上の数字を更新すると、以下のようなUPDATE文をGuardiumにおいて検出できます。

UPDATE SIEBEL.S_REVIN 
  SET DB_LAST_UPD_SRC='User'.DB_LAST_UPD=current timestamp-current timezone, 
  LAST_UPD='2-11-04-19.49.43.000000',LAST_UPD_BY='8SIA-7ZPPT',
  MODIFICATION_NUM=0000000000000000,ACCNT_ID='1-4YR' 
  WHERE ROW_ID='UA1-1V1TV AND MODIFICATION_NUM=0000000000000000

図2は、このSQLがどのようにGuardiumで記録されるのかを示しています。

図2. 売上の数値を更新する際にSiebel CRMが実行するUPDATE文
図2. 売上の数値を更新する際にSiebel CRMが実行するUPDATE文
図2. 売上の数値を更新する際にSiebel CRMが実行するUPDATE文

Guardiumの設定を行うことによって、このSQL文に基づいてユーザーID (8SIA-7ZPPT)とユーザー名(FBROOKS)を抽出できます。抽出されたデータは、図3のとおりです。

図3: GuardiumがUPDATE文からユーザーIDを抽出し、ユーザー名にマッピングする
図3: GuardiumがUPDATE文からユーザーIDを抽出し、ユーザー名にマッピングする
図3: GuardiumがUPDATE文からユーザーIDを抽出し、ユーザー名にマッピングする

この例は、Guardiumを正確に設定することによって、監査人やコンプライアンス担当者がどのアプリケーション・ユーザーがどのデータベース・トランザクションを実行しているのか簡単に確認できるようになることを示しています。

コンフィギュレーション

Siebelの例について既に検証したので、次に製品に組み込まれたアプリケーション・ユーザーの検出機能の設定について説明します。Oracle E-Business、PeopleSoft、Siebel、SAP、およびBusiness Objectsの製品ごとに設定方法は異なるものの、コンフィギュレーションには一部共通のスレッドが含まれます。

最初のステップとして、Guardiumの管理コンソール内でユーザーの検出プロセスを設定します(図4を参照)。

図4: 管理コンソールに含まれるアプリケーション・ユーザーの検出を行うためのメニュー
図4: 管理コンソールに含まれるアプリケーション・ユーザーの検出を行うためのメニュー

「Application User Translation」パネルにおいて、アプリケーションのデータベースに関する一連のパラメーターを指定します。GuardiumがユーザーIDをユーザー名のマッピングにインポートするためにデータベースへの接続を必要とする場合は、データベースのユーザー名とパスワードを提供する必要があります(本情報はOracle E-BusinessとSiebelの場合に必要)。PeopleSoftとBusiness Objectsのような製品については、ユーザー名がSQLのパターンに直接現れている場合は、アプリケーションのIP番号とポート番号を指定するだけで済みます。

図5: Siebel、Business Objects、Oracle E-Business、およびPeopleSoftにおける設定例
図5: Siebel、Business Objects、Oracle E-Business、およびPeopleSoftにおける設定例
図5: Siebel、Business Objects、Oracle E-Business、およびPeopleSoftにおける設定例

Guardiumの管理コンソールにおいてこれらのパラメーターを入力すると、アプリケーション・ユーザーの検出機能を有効化するためにはGuardiumの監視エンジンを再起動する必要があります(図6を参照)。

図6: Guardiumの監視エンジンの設定
The Inspection Engine Control in Guardium. This is Where the Inspection Engines Would be Restarted
The Inspection Engine Control in Guardium. This is Where the Inspection Engines Would be Restarted

PeopleSoftとBusiness Objectsに関してはこれで設定が完了します。Oracle E-BusinessとSiebelの場合は、アプリケーション・ユーザーIDからアプリケーション・ユーザー名へのマッピングをインポートするための追加のステップが必要になります。マッピングをインポートするにはアプリケーション・ユーザーの検出機能のインポート・プロセスを実行する必要があり、その後も本プロセスを定期的に実行する必要があります。本プロセスの実行に関する制御機能は管理コンソール内にあります(図7を参照)。

図7: マッピングをインポートするためのコンフィギュレーション・ダイアログ
図7: マッピングをインポートするためのコンフィギュレーション・ダイアログ
図7: マッピングをインポートするためのコンフィギュレーション・ダイアログ

製品に組み込まれたアプリケーション・ユーザーの検出機能を設定し、本機能の実行が開始されると、事前に設定されたGuardiumレポートを参照することで、アプリケーション・ユーザーのアクティビティーを確認できます。例えば、Oracle E-Businessに関しては、EBS Processes Database AccessEBS Application Accessが提供されます。これらのレポートを正しく発行するためには、Guardiumにおいて一部のグループを事前に設定する必要があります。事前設定が必要なグループについては、図8のレポートのクエリーの定義をご参照ください。

図8: EBSアプリケーションに関するアクセス・レポートを発行するためのクエリーの定義
図8: EBSアプリケーションに関するアクセス・レポートを発行するためのクエリーの定義
図8: EBSアプリケーションに関するアクセス・レポートを発行するためのクエリーの定義

独自のレポートを作成することによって、アプリケーション・ユーザーのデータを表示することもできます。そのためには、レポートを作成し、App User NameAccess PeriodのエンティティーからApp User Nameフィールドを追加します。レポートを参照する際には、Aliasesが有効化されていることを確認してください。

SAPに関する注意事項

アプリケーション・ユーザーの検出機能のコンフィギュレーション・パネルでは、SAPは「Application Type」のオプション(SAP Observed)として設定されています。SAPのアプリケーション・ユーザーの検出機能が起動するためには、本パネルを使用した設定は必要ありません。本オプションは履歴の管理のみを目的として管理ソールで管理されています。SAPのアプリケーション・ユーザーの検出機能を設定するには、GuardiumにおいてSAP App ServersSAP DB Serversを事前に設定する必要があります(図9を参照)。

図9: SAPのアプリケーション・ユーザーの検出機能を有効化するために事前に設定する必要のある2種類のグループ
図9: SAPのアプリケーション・ユーザーの検出機能を有効化するために事前に設定する必要のある2種類のグループ
図9: SAPのアプリケーション・ユーザーの検出機能を有効化するために事前に設定する必要のある2種類のグループ

アプリケーション・サーバーとデータベース・サーバーのIPアドレスの設定が完了すると、アプリケーション・ユーザーの検出機能を有効化するには監視エンジンを再起動する必要があります。

データベースを使用した手法

SiebelとSAPに関しては、データベースを使用したユーザー検出機能という上記においてまだ説明していない追加のオプションがあります。

図10: SiebelとSAPに関して、管理コンソールでデータベースを使用したアプリケーション・ユーザーの検出機能を選択する
図10: SiebelとSAPに関して、管理コンソールでデータベースを使用したアプリケーション・ユーザーの検出機能を選択する
図10: SiebelとSAPに関して、管理コンソールでデータベースを使用したアプリケーション・ユーザーの検出機能を選択する

実際には、ここではユーザーの検出機能は実行されません。Guardiumはアプリケーションが既にキャプチャーした監査データをインポートするだけです。これは従来からの方法であり、システムにより大きな負荷を与えるため、アプリケーションごとに設定された手法を使用するほうが好ましいといえます。アプリケーションごとに設定された手法ではなくデータベースを使用した手法を採用する場合、SAPとSiebelの監査機能を有効化する必要があります。Siebelの場合は、Docking: Transaction LoggingパラメーターをTRUEに、SAPの場合は、rdisp/vb_delete_after_executionパラメーターを2に設定する必要があります。さらにSAPの場合は、DELETEを設定したrsm13002トランザクションを定期的に実行することによって、レポートを削除する必要があります。

InfoSphere Guardiumのアプリケーション・イベントAPIを使用する

製品に組み込まれたアプリケーション・ユーザーの検出機能について説明が完了したので、次にGuardiumのアプリケーション・イベントAPIについて説明します。製品に組み込まれたアプリケーション・ユーザーの検出機能とは異なり、Guardiumのアプリケーション・イベントAPIはあらゆるアプリケーションに対して使用することができます。ただし、セッションの制御があるアプリケーションから別のアプリケーションに変更された場合に当該アプリケーションがSQL文を実行するように設定または修正を行う必要があります。

アプリケーション・イベントAPIを呼び出す処理は、アプリケーションが接続プール内の接続をピックアップする前と後のタイミングで演算処理を伴わないSQL文をシンプルに実行します。この演算処理を伴わない呼び出し処理によって、Guardiumはどのアプリケーション・ユーザーが現在データベース・セッションを利用しているのかを把握できます。この呼び出し処理はデータベース変更を行わないものの、Guardiumは本処理を検出することができます。通常、このような演算処理を伴わない呼び出し処理は、DB2 LUWs SYSDUMMY1テーブルや「ORACLE DBs DUAL」テーブルのような1行の特別なテーブル上で実行されます。

アプリケーション・ユーザーの検出を行う場合、GuardiumによるAppEventAPIの呼び出し処理は通常以下の形態を取ります。

SELECT 'GuardAppEvent:Start',  'GuardAppEventUserName:user_name' FROM DUMMY_TABLE;
-- SQL Transactions related to the user named user_name
SELECT 'GuardAppEvent:Released'  FROM DUMMY_TABLE;

本手法は、データベースのコマンドライン・ツールを使用することで簡単に実行できます。DB2 LUWのコマンドライン・インターフェースで以下のSQL文を実行できます。

SELECT 'GuardAppEvent:Start',  'GuardAppEventUserName:fbrooks' FROM SYSIBM.SYSDUMMY1;
SELECT count(*) FROM ITEMS;
SELECT 'GuardAppEvent:Released'  FROM SYSIBM.SYSDUMMY1;
SELECT 'GuardAppEvent:Start',  'GuardAppEventUserName:kzuse' FROM SYSIBM.SYSDUMMY1;
SELECT count(*) FROM ITEMS; 
SELECT 'GuardAppEvent:Released'  FROM SYSIBM.SYSDUMMY1;
図11: DB2のコマンドライン(Linuxベース)からGuardiumのアプリケーション・イベントAPIを実行する
図11: DB2のコマンドライン(Linuxベース)からGuardiumのアプリケーション・イベントAPIを実行する
図11: DB2のコマンドライン(Linuxベース)からGuardiumのアプリケーション・イベントAPIを実行する

図12が示すとおり、Guardiumのセッションを見るとfbrooksのユーザーが最初のSELECT count(*)文に関連付けられていることが分かります。さらに、2つ目のSELECT count(*)文に基づいて、ユーザーがkzuseにスイッチしたことが分かります。

図12: SELECT count(*)文をアプリケーション・ユーザーに関連付ける
図12: SELECT count(*)文をアプリケーション・ユーザーに関連付ける
図12: SELECT count(*)文をアプリケーション・ユーザーに関連付ける

通常、アプリケーション・イベントAPIを使用するには、事前にアプリケーションを変更する必要があります。接続プールに含まれるあるセッションにおいてアプリケーション・ユーザーがスイッチした場合に演算処理を伴わないSQLを実行するには、お客様はアプリケーション・コードを修正する必要があります。しかしながら、一部の柔軟なアプリケーションを使用すると、コードを一切変更することなく演算処理を伴わないSQLの呼び出し処理を実行することができます。

ストアード・プロシージャーを使用してアプリケーション・ユーザーを検出する

ストアード・プロシージャーを使用したアプリケーション・ユーザーの検出機能は、SQL文を使用して単一のデータベース・セッション内でユーザー間の境界を規定するという点で、Guardiumのアプリケーション・イベントAPI(前セクションで解説済み)と似ています。この場合、SQL文ではなくストアード・プロシージャーが使用されます。接続プール内でアプリケーション・ユーザーがスイッチした際に事前設定に基づいてアプリケーションがストアード・プロシージャーを実行すると、Guardiumが本状況を検出しユーザーに対して属性を割り当てるよう設定することができます。

図13に示したとおり、単一のデータベース・セッション内でアプリケーションが一連のステートメントを実行するよう設定することができます。

図13: 「set_application_property」のストアード・プロシージャーを呼び出すことで、Oracleデータベースのセッションにおいてアプリケーション・ユーザーの境界を検出する
図13: 「set_application_property」のストアード・プロシージャーを呼び出すことで、Oracleデータベースのセッションにおいてアプリケーション・ユーザーの境界を検出する
図13: 「set_application_property」のストアード・プロシージャーを呼び出すことで、Oracleデータベースのセッションにおいてアプリケーション・ユーザーの境界を検出する

プールされた接続内でアプリケーション・ユーザーが変わるたびに、「user_name」のパラメーターを設定した「set_application_property」のストアード・プロシージャーの呼び出しが行われます。Guardiumの設定を行うことで、本ストアード・プロシージャーの呼び出しを検出のうえ、図14のとおり2つ目のパラメーター(現在のユーザー)を使用できます。

図14: アプリケーション・ユーザー間の境界としてストアード・プロシージャーを検出するように設定を行ったGuardiumシステムの出力結果
図14: アプリケーション・ユーザー間の境界としてストアード・プロシージャーを検出するように設定を行ったGuardiumシステムの出力結果
図14: アプリケーション・ユーザー間の境界としてストアード・プロシージャーを検出するように設定を行ったGuardiumシステムの出力結果

コンフィギュレーション

Guardiumが上記のとおりストアード・プロシージャーによってユーザーの検出を行うには、Guardiumの管理コンソールにおいてカスタムIDプロシージャーを新規に規定する必要があります。本プロシージャーの名前は、アプリケーション・ユーザーがスイッチする際にアプリケーションが呼び出すストアード・プロシージャーの名前であり、この場合はset_application_propertyという名前が付いています。最初のパラメーターとしてuser_dateを指定した同じプロシージャーに対する呼び出しを回避するために、user_nameの値の条件を指定することによって、最初のパラメーターが「user_name」でなければならない旨を指定することができます。最後に、2番目のパラメーターがアプリケーション・イベントのエンティティーにおいて「Username」フィールドとして機能するよう設定を行います。その後、レポートに「Application Event Username」フィールドに追加することによって、アプリケーション・ユーザーの情報を参照できます(図15を参照)。

図15: Guardiumのストアード・プロシージャーのコンフィギュレーション・ウィンドウ
図15: Guardiumのストアード・プロシージャーのコンフィギュレーション・ウィンドウ
図15: Guardiumのストアード・プロシージャーのコンフィギュレーション・ウィンドウ

本手法によるアプリケーション・ユーザーの検出機能は、頻繁にストアード・プロシージャーを使用するアプリケーションや、ストアード・プロシージャーを呼び出すことによってユーザーの境界を規定するアプリケーションには最適なソリューションです。またアプリケーションによっては、柔軟性に欠けるため、演算処理を伴わないSELECT文を呼び出すことによってGuardiumのアプリケーション・イベントAPIを活用することはできないものの、適切なストアード・プロシージャーを呼び出すように設定することができるアプリケーションが存在します。そのようなアプリケーションの場合も、本手法は理想的なソリューションと言えます。

アプリケーション・サーバーのS-TAPを使用する

アプリケーションのソースコードを変更することは不可能または好ましくないため、Guardiumのアプリケーション・イベントAPI使用できない場合があります。ユーザーの境界を規定するために、アプリケーションがストアード・プロシージャーを使用しない場合もあります。このような場合においては、GuardiumのS-TAPによるネットワークのモニタリング機能を使用することで、アプリケーション・ユーザーの検出ができます。この場合、S-TAPを使用して、アプリケーション・ユーザーとデータベース・アクティビティーの関連付けができます。S-TAPは、データベース・サーバーではなくアプリケーション・サーバーをホストするマシンにインストールされます。その後、S-TAPを設定することによって、アプリケーション・サーバーに提供されるHTTPトラフィックをモニタリングし、ユーザー名を除外し、アプリケーション・サーバーのセッションIDを通じてユーザー名とデータベース・アクティビティーの関連付けができます。Guardiumにおいては、本プロセスをアプリケーション・ユーザーの検出機能またはアプリケーション・サーバーのS-TAP機能と呼びます。

本手法を実施するにあたりアプリケーションの変更やアプリケーション・サーバーの再設定は不要なため、非常に迅速かつ簡単にソリューションを実現できるという大きなメリットがあります。本手法のデメリットとしては、あらゆるエンタープライズ・アプリケーションをサポートするわけでないことが挙げられます。発生する可能性のある問題としては、ユーザー名の暗号化とハッシュ値の作成を行う認証メカニズムに整合性がないことが挙げられます。アプリケーション・サーバーのS-TAPは、特定の種類のフォーム・ログインの認証を使用した標準のJava Enterpriseアプリケーションに対して最も効率的に機能を提供できます。

アプリケーションを分析する

アプリケーション・サーバーのS-TAPを設定する際の第1のステップは、監査の対象となるアプリケーションを分析することです。

以下の3種類の項目を確認する必要があります。

  • アプリケーション・サーバーのHTTPポートはどれか?
  • ユーザーのログイン中にHTTPトラフィックに含まれるアプリケーション・ユーザー名の検出はどのようにして行うことができるか?
  • ユーザー名と関連付けられるJava Session IDの検出はどのようにして行うことができるか?

Webトラフィックを分析するためにはさまざまなツールが存在しますが、最も使いやすいツールの1つとしてLive HTTPヘッダーと呼ばれるFirefoxプラグインがあります。本プラグインをインストールすると、Webへのログイン中に提供されたHTTPトラフィックを簡単に確認することができます(図16を参照)。

図16: Plants by Websphereアプリケーションのログイン画面
図16: Plants by Websphereアプリケーションのログイン画面
図16: Plants by Websphereアプリケーションのログイン画面

本記事のために、Plants By WebSphereというデモ・アプリケーションを使用します。jon@doe.comというユーザー名で本アプリケーションにログインすると、HTTPヘッダーのウィンドウでHTTPトラフィックを確認できます(図17を参照)。

図17: ログインに関するHTTPトラフィック
図17: ログインに関するHTTPトラフィック
図17: ログインに関するHTTPトラフィック

Plants By WebSphereのアプリケーションにおいては、確認すべきHTTPリクエストはAccountServletに対するPostリクエスト(action=loginのパラメーターを設定済み)です。ユーザー名がHTML POSTリクエストのコンテンツとして提供されることが分かります。実際のユーザー名には、プレフィックスとして「userid=」、ポストフィックスとして「&」が付加されています。

Java Session IDが本リクエストのクッキー内に含まれて提供され、プレフィックスとして「JSESSIONID=」、ポストフィックスとして&が付加されています。

アプリケーション・サーバーのS-TAPを設定する

アプリケーション・サーバーのS-TAPを有効化するには、HTTPストリームから受領した情報に基づいてGuardiumコレクターの設定を行う必要があります(図18を参照)。

図18: Guardiumの管理コンソール
図18: Guardiumの管理コンソール
図18: Guardiumの管理コンソール

設定を行う際には、Guardiumの管理コンソールで行います(「Administrative Console」→「Local Taps」→「S-TAP control」とクリック)。本画面においては、S-TAPに対して主要な設定の全てを行うことができます(図19を参照)。この設定を完了するには、S-TAPの設定を行う際に、データベース・サーバーではなくアプリケーション・サーバーをホストするマシンにS-TAPをインストールする必要があります。

図19: アプリケーション・サーバーのS-TAPを設定する
図19: アプリケーション・サーバーのS-TAPを設定する
図19: アプリケーション・サーバーのS-TAPを設定する

図19では、Plants by WebSphereのサンプル・アプリケーション用にアプリケーション・サーバーのS-TAPを設定をする例を示しています。これらの設定項目は、HTTPトラフィックに含まれる値と一致しています。「Ports」の値は、本アプリケーションをホストするアプリケーション・サーバーのHTTPポート番号をさします。提供されるアプリケーション・ユーザー名には、プレフィックスとしてuserid=ポストフィックスとして&がアプリケーションによって設定されます。アプリケーション・ユーザーの関連付けを行う必要のあるセッションIDについて、プレフィックス(JSESSIONID=)とポストフィックス(&)が設定されたデータベース・アクセス情報がHTTPのクッキーとして提供されます。Guardiumはこれらのパターンに関する値を使用して、HTTPストリームのロケーションを検証します。

パラメーターの変更が完了した後、変更内容を適用する必要があります。その後S-TAPの再起動を行うと、使用可能になります。

図20: アプリケーション・サーバーのS-TAPによるレポート
図20: アプリケーション・サーバーのS-TAPによるレポート
図20: アプリケーション・サーバーのS-TAPによるレポート

アプリケーション・ユーザーの検出機能の設定完了後、Guardiumはアプリケーション・ユーザー名をApplication Userフィールド(Access Periodのエンティティーに含まれる)に保存します。本フィールドをレポートに加えることもできます。上記の図20では、データベース・ユーザー名(JDBC Datasourceと関連付けられたユーザー名)とアプリケーション・ユーザー名(ログインの際に使用された実際のアプリケーション・ユーザー名)がレポートに含まれていることが分かります。

アプリケーション・サーバーのS-TAPに関するまとめ

アプリケーション・サーバーのS-TAPを使用すると、Guaridiumに組み込まれた機能が使用できない場合に、Javaアプリケーション・サーバーのアプリケーション・ユーザーを簡単に検出することができます。S-TAPを使用するにあたっては既存のアプリケーションを一切変更する必要がないため、非常に魅力的なソリューションであると言えます。ただし、いくつかのポイントを考慮する必要があります。

アプリケーション・サーバーのS-TAPが機能するためには、HTTPストリームにおいてユーザー名をクリアテキストで提供する必要があります。通常のHTTPベースの認証機能をはじめとする一部の認証メカニズムでは、HTTPベースの認証データはハッシュ値に変換されるか、Base64に基づいてエンコードが行われているため、サポートされません。通常、フォーム・ログインの場合は、ユーザー名をクリアテキストで提供します。

この手法は全てのアプリケーションで機能するとは限りません。接続プールが使用されている形態によって、機能するかどうかが決まります。例えば、データ―ベースに対するアクセスは同期通信に基づく必要があり、HTTPリクエストを処理する際と同じプロセスまたはスレッドを使用する必要があります。この例としては、サーブレットがHTTPリクエストを処理し、本プロセスにおいてデータベースにアクセスするための接続データを接続プールから受領するようなサーブレット・ベースのアプリケーションが挙げられます。

HTTPS接続はサポートされません。S-TAPはアプリケーション・サーバーにインストールされるため、通常本件は大きな問題とはなりません。通常のエンタープライズ・コンフィギュレーションでは、Webサーバー上のトラフィックのみがHTTPSベースの暗号化が行われており、Webサーバーとアプリケーション・サーバー間の接続は標準のHTTPに基づいているためです。

データベース・サーバーとアプリケーション・サーバーのAPIを使用する

アプリケーション・ユーザーがデータベース・レイヤーからアプリケーション・レイヤーに広範に存在するため、ユーザー情報の監査に関する問題が発生しているのは、Guardiumだけではありません。データベースが提供するネイティブの監査機能の多くで同じ問題が発生しています。これらのソリューションは、システムにAPIを追加することによってこの問題の解決を図ろうとしています。これまで、アプリケーション開発の手間を最小限に抑えながら監査を実施するために、アプリケーション・サーバーはこのようなAPIを活用するように設計されてきました。Guardiumのメリットとしては、GuardiumはこのようなAPIの使用を検出することによって、APIに基づいた適切なアプリケーション・ユーザー名の割り当ができることが挙げられます。

DB2の場合

本プロセスを詳述するために、IBM DB2 LUWデータベースとWebSphere Application Server (WAS)を使用した例について説明します。最初の例として、標準のJDBCベースのConnection.setClientInfoのAPIを使用したDB2 LUWのシステムを挙げます。以下のようなsetClientInfoのAPIを使用するアプリケーションが存在するとします。

Class.forName("com.ibm.db2.jcc.DB2Driver");
Properties props = new Properties();
props.setProperty("user", "guard");
props.setProperty("password", "password");
Connection  connection = DriverManager.getConnection("jdbc:db2://10.10.9.28:50001/orders"
, props);

connection.setClientInfo("ClientUser", "fbrooks");
execSelectOnItems(connection);

connection.setClientInfo("ClientUser", "kzuse");
execSelectOnItems(connection);

上記は、多少複雑なシステムの例であると言えます。実際のアプリケーションでは、このようなユーザー名のハードコーディングは発生しません。通常は、アプリケーション・ユーザーは変数として挿入されます。ユーザーはセッションIDを通じて検出されることになります。fbrooksとkzuseの定数については、コンセプトを説明する目的のためにのみここで使用しています。execSelectOnItemsを使用した手法は、ITEMSという名称のテーブル内でレコードの数を管理するデータベースに対して単純なSELECT文を実行します。Guardiumはデータベース・トラフィックを検出し、setClientInfo("ClientUser", "fbrooks")のリクエストの後に実行されるあらゆるSQLをfbrooksユーザーに割り当てます。図21が示すとおり、設定は一切必要ありません。

図21: Guardiumのシステムに表示されるsetClientInfoのリクエスト
図21: Guardiumのシステムに表示されるsetClientInfoのリクエスト
図21: Guardiumのシステムに表示されるsetClientInfoのリクエスト

2つ目の例は、トラステッド・コンテキストを使用してDB2の接続プールを使用します。トラステッド・コンテキストによって、IPとユーザー名のペアを信頼できるようにDB2 LUWを設定できます。その後、データベース・ユーザーのユーザー名のスイッチの段階で再認証と再接続のプロセスをスキップすることができます。setClientInfoのAPIとは異なり、トラステッド・コンテキストに基づいてユーザー名をスイッチすることによって、DB2は該当するユーザーに関連するアクセス制御を実現できます。この場合、実際にDB2ユーザーのスイッチが行われます。トラステッド・コンテキストを使用することで、最新のデータベースで提供されるアクセス制御メカニズムの全てを活用するために必要な高いパフォーマンスと機能を実現することができます。トラステッド・コンテキストを活用するもう1つのメリットは、Guardiumがユーザーのスイッチを検出できることです。Guardiumは、このスイッチを特別なConnect文として検出します。この状況を確認するために、アプリケーション・サーバーで実行される以下のコードを参照してください。

Object[] objects = new Object[6];
Properties properties = new Properties();
byte[] cookie = new byte[1];
Connection con;
DB2ConnectionPoolDataSource ds1 = 
new DB2ConnectionPoolDataSource();	      
ds1.setServerName("10.10.9.28");
ds1.setPortNumber(50001);
ds1.setDatabaseName("orders");
ds1.setDriverType (4);
	 
objects = ds1.getDB2TrustedPooledConnection("guard", "password", properties); 
DB2PooledConnection pooledCon = (com.ibm.db2.jcc.DB2PooledConnection)objects[0];
cookie = (byte[])objects[1];
con = pooledCon.getDB2Connection(cookie, "fbrooks", null, null, null, null, properties);
execSelectItems(con);
con = pooledCon.getDB2Connection(cookie, "kzuse", null, null, null, null, properties);
execSelectItems(con);

アプリケーション・サーバーにおける本コードの実行状況は、Guardium内においては図22の例のように確認できます。

図22: Guardium上で確認できる、トラステッド・コンテキストに基づくユーザーのスイッチ
図22: Guardium上で確認できる、トラステッド・コンテキストに基づくユーザーのスイッチ
図22: Guardium上で確認できる、トラステッド・コンテキストに基づくユーザーのスイッチ

「DB User Name」フィールドは、もともとアプリケーション・サーバーにログインを行ったユーザー名を指します。本データは、トラステッド・コンテキストに基づく信頼性の高いユーザーです。「Application User」フィールドは、接続プールで現在使用されているユーザー名を指します。ここで、データベース・ユーザーとアプリケーション・ユーザーの違いは若干不明瞭になります。というのも、kzuseとfbrooksは実はデータベース・レベルの特権を有するデータベース・ユーザーであるものの、アプリケーション・ユーザーでもあるためです。その他のデータベースについても同様のAPIが存在し、GuardiumはこのようなAPIのほとんどを検出することができます。

上記で説明したトラステッド・コンテキストの例とsetClientInfoを使用した例では、アプリケーションが直接APIにアクセスできる例について説明しました。ほとんどのエンタープライズ・アプリケーションでは、アプリケーション・サーバーがこのようなリクエストを行います。そこで、このようなリクエストができるアプリケーション・サーバーの1つとしてWebShereを挙げることができます。以下においては、DB2のトラステッド・コンテキストを自動的に使用するWebSphereについて説明します。

WebSphereの場合

WebSphere 7の設定を行うことによって、アプリケーションのリソース参照のログイン・コンフィギュレーションにおいてDB2のトラステッド・コンテキストを使用することができます。本設定を行うと、WebSphereは自動的にトラステッド・コンテキストを活用できます(図23を参照)。本設定方法に関する詳細情報は、参考文献のセクションにあります。

図23: トラステッド・コンテキストを使用するために、WebSphereにおいてデータソースのリソース参照を設定する
図23: トラステッド・コンテキストを使用するために、WebSphereにおいてデータソースのリソース参照を設定する
図23: トラステッド・コンテキストを使用するために、WebSphereにおいてデータソースのリソース参照を設定する

さらに、WebSphereの設定を行うことによって、Guardiumのアプリケーション・イベントAPIやデータベースAPIを呼び出すためのデータ・ストア・ヘルパーのプラグインを使用できます。参考文献のセクションにあるdeveloperWorksの記事「WebSphereで特別なDataStoreHelperプラグインを開発することによって、Pre SQLとPost SQLを挿入する」は、本件に関して詳述しています。WebLogicも同様の機能を提供します。WebLogicのCredential Mappingの機能を設定する方法については、参考文献のセクションで情報を提供しています。

結論

データベースの監視ソフトウェアで発生する問題の1つとして、データベース・アクティビティーに関連するアプリケーション・ユーザーの特定が困難であることが挙げられます。この問題が発生するのは、パフォーマンス上の理由からアプリケーション・サーバーがデータベースの接続プールを実装しているためです。

Guardiumでアプリケーション・ユーザーの特定を行うためのさまざまな手法について説明しました。各手法にはメリットとデメリットがあり、以下をはじめとする状況に適用できます。

  • SiebelやSAPなどのサポート対象のアプリケーションの場合は、勿論製品に組み込まれたアプリケーション・ユーザーの検出機能が最適なソリューションとなります。
  • アプリケーションのSQLリクエストを変更できる場合は、アプリケーション・ユーザーのトラッキングを行うためには、Guardiumのアプリケーション・イベントAPIが最も堅牢かつ安定した手段となります。
  • ユーザー管理のためにストアード・プロシージャーの呼び出しを行う多くのアプリケーションでは、ストアード・プロシージャーのパターンを分析することは適切なソリューションです。
  • アプリケーションのソースコードの変更ができず、対象となるアプリケーションが標準のJava Enterpriseアプリケーションである場合は、アプリケーション・サーバーのS-TAPを使用することが問題を解決する迅速かつシンプルな方法である場合があります。
  • アプリケーション・サーバーとデータベースがAPIによるアプリケーション・ユーザーの検出機能をサポートしている場合、当該機能を有効化することができます。

本記事においては、データベースの監査ソフトウェアにおけるアプリケーション・ユーザーの検出に関する問題について説明しました。Guardiumで提供されるアプリケーション・ユーザーの検出テクノロジーについて概要を説明し、本テクノロジーの導入方法について例を挙げて説明しました。各テクノロジーをどのような場合に使用すべきか、ガイドラインも提供しました。


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


関連トピック


コメント

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Information Management
ArticleID=855143
ArticleTitle=InfoSphere Guardiumによるアプリケーション・ユーザーの検出
publish-date=01302013