Data Virtualizationにおける監査ポリシーによるデータアクセスの監視

資料の英語版に戻る

Data Virtualizationにおける「Db2監査機能によるデータアクセスの監視

最終更新: 2024年11月26日

Data Virtualizationにおける監査ポリシーによるデータアクセスの監視

機密データへのアクセスを管理するために、認証とアクセス制御のメカニズムを使用して、データ・アクセスの規則と制御を確立できます。しかし、未知の動作や容認できない動作から保護したり、そのような動作を発見したりするために、Db2® 監査機能を使用してデータ・アクセスをモニターすることができます。

不適切なデータ・アクセスを正常にモニターして分析することにより、データ・アクセスの制御を改善し、データへの悪意のあるまたは不注意な無許可アクセスを最終的に防止することができます。システム管理処置を含む、アプリケーションおよび個々のユーザー・アクセスのモニターは、データベース・システムのアクティビティーの履歴レコードを提供します。

Db2監査機能を使用して、事前定義された一連のデータベース・イベントの監査証跡を生成および保守することができます。監査に使用できるイベントのカテゴリーごとに、カテゴリーの名前の後にカテゴリー・タイプを識別するために 1 語のキーワードが使用されます。監査のために使用可能なイベントの区分は次のようになります。

監査 (AUDIT)

監査設定が変更されるとき、または監査ログがアクセスされるときにレコードを生成する。

許可検査 (CHECKING)

Db2 データベース・オブジェクトまたは関数へのアクセスまたは操作の試行の許可検査中にレコードを生成する。

オブジェクト保守 (OBJMAINT)

データ・オブジェクトを作成またはドロップするとき、および特定のオブジェクトに変更を加えるときにレコードを生成する。

セキュリティー保守 (SECMAINT)

以下の条件のレコードを生成する。

オブジェクト特権またはデータベース権限の付与または取り消すとき。
セキュリティー・ラベルまたは免除の付与または取り消すとき。
LBAC セキュリティー・ポリシーのグループ許可、ロール許可、またはオーバーライドまたは制限属性の変更するとき。
SETSESSIONUSER 特権の付与または取り消し。
SYSADM_GROUP、SYSCTRL_GROUP、SYSMAINT_GROUP、または SYSMON_GROUP 構成パラメーターのいずれかに変更を加えるとき

システム管理 (SYSADMIN)

SYSADM、SYSMAINT、または SYSCTRL 権限を必要とする操作が実行されると、レコードを生成する。

ユーザー検証 (VALIDATE)　

ユーザーを認証しているとき、またはシステムのセキュリティー情報を検索しているときにレコードを生成する。

操作コンテキスト (CONTEXT)　

データベースの操作が実行されるとき、操作コンテキストを表示するレコードを生成する。この区分を使用すると、監査ログ・ファイルのより良い変換処理を可能にします。ログのイベント相関関係子フィールドを同時に使用することで、イベントのグループを 1 つのデータベース操作に戻って関連付けることができます。例えば、動的照会の照会ステートメント、静的照会のパッケージ ID、つまり CONNECT のような実行されている操作タイプのインディケーターは、監査結果を分析しているときに必要なコンテキストを提供できます。

実行 (EXECUTE)

SQL ステートメントの実行中にレコードを生成する。

上記に記載された区分のいずれにおいても、失敗、成功、またはその両方を監査できます。

データベース・サーバーに対する何らかの操作によって、いくつかのレコードが生成される可能性があります。監査ログに生成されるレコードの実際の数は、監査機能構成により指定された、記録されるイベントの区分の数によって決定されます。さらに、成功、失敗、またはその両方を監査するかどうかによっても異なります。監査対象のイベントを選択することが重要です。

この機能から生成されたレコードは、各表が各カテゴリーに対応する一連の AUDIT 表から表示できます。これらのレコードの分析で、システムの誤用を識別できる使用パターンを明らかにすることができます。誤用が識別されると、システムの誤用を削減または除去するための処置を取ることができます。

監査機能を使用すると、データベース・レベルでの監査が可能になります。管理者グループのすべてのメンバーは、監査ポリシーを構成して、そのような監査情報 (モニター許可 ID、データベース権限、トラステッド・コンテキスト、または特定の表など) を収集するタイミングを制御することができます。

クイック・スタート

AUDIT_ALL は、デプロイメント時に構成される事前定義ポリシーです。このポリシーは、すべてのカテゴリーの監査レコードのすべての成功と失敗を監査します。ニーズに合ったカスタム・ポリシーを作成することをお勧めします。
AUDIT_UPDATEは、監査記録を抽出し、AUDIT.*にロードする定義済みのプロシージャです。 tables.
AUDIT ステートメントを使用するには、ユーザーが SECADM 権限を保有している必要があります。 AUDIT.* のデータを表示するには、以下のようにします。表に対する SELECT 特権を付与されたユーザーは、それらの表にアクセスできます。

重要: 監査ポリシーが有効になっていて、監査タスクがスケジュールされている場合は、AUDIT.* 表は、システム上のスペースを累積します。 AUDIT.* テーブルによって使用されるストレージを管理する必要があります。 tables. 監査データを定期的にエクスポートしてオフラインで保管し、AUDIT.*テーブル内のデータをクリーンアップする必要があります。 tables.

各役割のサービス内のすべてのイベントを AUDIT がキャプチャーできるようにするには、以下のようにします。

AUDIT ROLE DV_ADMIN USING POLICY AUDIT_ALL;
AUDIT ROLE DV_ENGINEER USING POLICY AUDIT_ALL;
AUDIT ROLE DV_STEWARD USING POLICY AUDIT_ALL;
AUDIT ROLE DV_WORKER USING POLICY AUDIT_ALL;

最新の監査レコードを 15 分ごとに監査テーブルに取得するために、スケジュールされた監査更新タスクを作成する (更新の最小間隔)

CALL SYSPROC.ADMIN_TASK_ADD( 'AUDIT_UPDATE', NULL, NULL, NULL, '*/15 * * * *', 'AUDIT', 'UPDATE', NULL, NULL, 'Periodically update to audit tables' );

8 つの監査イベント・カテゴリーの監査レコードを表示するには、以下のようにします。

select * from AUDIT.AUDIT;

select * from AUDIT.CHECKING;

select * from AUDIT.CONTEXT;

select * from AUDIT.EXCUTE;

select * from AUDIT.OBJMAINT;

select * from AUDIT.SECMAINT;

select * from AUDIT.SYSADMIN;

select * from AUDIT.VALIDATE;

詳しくは、以下のリンクを使用してください。

監査ポリシーの作成
監査ポリシーの使用を開始する
カスタム監査ポリシーの構成
作成されたすべての監査ポリシーの表示
現在、どの監査ポリシーを使用しているかを確認する
データベース・エンティティーの監査の停止
グループの監査の停止
スケジュール・タスクを作成します
スケジュール済みタスクの変更
スケジュールされた監査更新タスクの状況をモニターします
最新の監査レコードを AUDIT.* にロードします。即時表

詳しくは、監査ポリシーを参照してください。

監査ポリシーの作成

CREATE AUDIT POLICY policy_name CATEGORIES category or ALL STATUS status ERROR TYPE NORMAL;

詳しくは、CREATE AUDIT POLICY ステートメントを参照してください。

監査ポリシー名

名前が固有であり、その目的が容易に識別できることを確認してください (例えば、AUDIT_SOC2_COMPLIANCEまたは AUDIT_LOGIN_ONLY)。この名前は、データベース内の内部システム名用に予約されているため、SYSで開始しないでください。

監査するカテゴリー

このポリシーは、監査するカテゴリーを決定します。このポリシーを他のデータベース・オブジェクトに適用して、それらのオブジェクトの使用を監査する方法を決定することができます。監査できるカテゴリーは 8 つあります。カテゴリーを多く設定するほど、監査される情報は多くなり、監査バッファに蓄積され、計算機スペースを占有するようになります。システムの計算スペースが過負荷にならないようにするには、目的を理解することが重要です。この要約では、使用可能な各カテゴリーについて説明します。 ALLがカテゴリー・オプションとして指定されている場合、他のカテゴリーを指定することはできません。

ほとんどのセキュリティー標準に準拠するために、以下のリストの推奨カテゴリーは、アクセス制御、認証、および特権アクセスのモニターに対応します。これらのカテゴリーを使用してポリシーを構成すると、セキュリティーを維持しながらオーバーヘッドを最小限に抑えることができます。

EXECUTE WITHOUT DATA -アクセス制御
VALIDATE -認証
SECMAINT-特権アクセスのモニター

さらに、カテゴリーごとに、成功シナリオと失敗シナリオの両方を監査し、エラー・タイプは SQL コード・エラーのみをログに記録する必要があります。

STATUS BOTH
ERROR TYPE NORMAL

監査ポリシーの使用を開始する

AUDIT database_entity USING POLICY policy_name;

詳しくは、AUDIT ステートメントを参照してください。

カスタム監査ポリシーの構成

カスタマイズされた監査ポリシーを構成して、認証要求と正常に実行された SQL コマンドを収集し、有効にすることができます。

CREATE AUDIT POLICY AUDIT_VALIDATE_EXECUTE CATEGORIES VALIDATE STATUS BOTH, EXECUTE STATUS SUCCESS ERROR TYPE NORMAL;

監査するデータベース・オブジェクト: データベース全体を監査すると、計算スペースが過負荷になります。どの表および関連するマテリアライズ照会表 (MQT) にポリシーを適用するかを指定することをお勧めします。
注: 表に適用される監査ポリシーは、その表に基づくマテリアライズ照会表 (MQT) には適用されません。監査ポリシーを表と関連付ける場合はそのポリシーをその表に基づく MQT にも関連付けることをお勧めします。 SQL ステートメントが基本表を参照していても、コンパイラーは MQT を自動的に使用する可能性があります。ただし、基本表で使用されている監査ポリシーは引き続き有効です。

推奨されるもう 1 つの構成は、グループまたは役割にポリシーを適用することです。この構成を使用して、どのグループおよび役割のどのユーザーが予期しないアクションを実行したかをモニターできます。データベース全体にポリシーを適用する場合、ポリシーがすべてのカテゴリの記録を保持しないことを確認してください。

表の監査ポリシーを有効にする

AUDIT TABLE CUSTOMTABLE USING POLICY AUDIT_VALIDATE_EXECUTE;

また、認証要求 (成功と失敗の両方) のみをキャプチャーして有効にするように、カスタマイズした監査ポリシーを構成することもできます。

CREATE AUDIT POLICY AUDIT_VALIDATE_ONLY CATEGORIES VALIDATE STATUS BOTH ERROR TYPE NORMAL;

作成されたすべての監査ポリシーの表示

select * from SYSCAT.AUDITPOLICIES;

次の出力例は、前述の SELECT ステートメントを実行した結果です。


AUDITPOLICYNAME              AUDITPOLICYID CREATE_TIME                ALTER_TIME                 AUDITSTATUS CONTEXTSTATUS VALIDATESTATUS CHECKINGSTATUS SECMAINTSTATUS OBJMAINTSTATUS SYSADMINSTATUS EXECUTESTATUS EXECUTEWITHDATA ERRORTYPE REMARKS

---------------------------- ------------- -------------------------- -------------------------- ----------- ------------- -------------- -------------- -------------- -------------- -------------- ------------- --------------- --------- -------

AUDIT_VALIDATE_ONLY                    108 2018-07-23-21.00.57.024758 2018-07-23-21.00.57.024758 N           N             B              N              N              N              N              N             N               N         -

AUDIT_ALL                              106 2018-07-23-20.51.18.017062 2018-07-23-20.51.18.017062 B           B             B              B              B              B              B              B             N               N         -

  2 record(s) selected.

現在、どの監査ポリシーを使用しているかを確認する

select * from SYSCAT.AUDITUSE;

次の出力例は、前述の SELECT ステートメントを実行した結果です。


AUDITPOLICYNAME           AUDITPOLICYID OBJECTTYPE SUBOBJECTTYPE OBJECTSCHEMA  OBJECTNAME        AUDITEXCEPTIONENABLED

------------------------- ------------- ---------- ------------- ------------- ----------------- ---------------------

AUDIT_VALIDATE_ONLY                 108                          -             CURRENT SERVER    N

  1 record(s) selected.

データベース・エンティティーの監査の停止

データベース・エンティティーの監査を停止するには、ポリシーを削除する必要があります。

AUDIT database_entity REMOVE POLICY;

詳しくは、AUDIT ステートメントを参照してください。

グループの監査の停止

AUDIT GROUP BLUUSERS REMOVE POLICY;

スケジュール・タスクを作成します

詳しくは、 ADMIN_TASK_ADD プロシージャー-新規タスクのスケジュールを参照してください。

20分ごとに最新の監査レコードを監査テーブルに取得する監査更新タスクのスケジュールを作成するには、以下のようにします。

CALL SYSPROC.ADMIN_TASK_ADD( 'AUDIT_UPDATE', NULL, NULL, NULL, '*/20 * * * *', 'AUDIT', 'UPDATE', NULL, NULL, 'Periodically update to audit tables' );

詳しくは、スケジュール形式について UNIX cron 形式を参照してください。

頻度

監査ログをアーカイブする定義済みタスクの実行頻度は、このテストの範囲外でしたが、実際のお客様の状況から収集した推奨事項は、注目に値します。大規模なデータベースでは、アーカイブ・タスクを毎日 15 分間実行することをお勧めします。これにより、予期しないパフォーマンスの問題が発生した場合に、データベースをリカバリーすることができます。ポリシーが推奨どおりに構成されている場合、監査バッファーはその時間枠内にワークロードを格納できるはずです。パフォーマンス・テストで示されているように、複雑な照会が監査レコードのアーカイブと並行して実行される場合、予期されるパフォーマンスの問題があります。

スケジュール済みタスクの変更

詳しくは、ADMIN_TASK_UPDATE プロシージャー-既存のタスクの更新を参照してください。

スケジュールされた監査更新タスクを変更して、20 分ごとに最新の監査レコードを監査テーブルに入れるには、以下のようにします。

CALL SYSPROC.ADMIN_TASK_UPDATE( 'AUDIT_UPDATE', NULL, NULL, NULL, '*/20 * * * *', 'Periodically update to audit tables every 20 minutes' );

スケジュールされた監査更新タスクを削除するには、次のようにします。

CALL SYSPROC.ADMIN_TASK_REMOVE( 'AUDIT_UPDATE', NULL );

詳しくは、ADMIN_TASK_REMOVE プロシージャー-スケジュールされたタスクまたはタスク状況レコードの除去を参照してください。

スケジュールされた監査更新タスクの状況をモニターします

select * from SYSTOOLS.ADMIN_TASK_STATUS;

次の出力例は、前述の SELECT ステートメントを実行した結果です。


  NAME          TASKID  STATUS     AGENT_ID     INVOCATION  BEGIN_TIME                 END_TIME                   SQLCODE  SQLSTATE SQLERRMC RC
  ------------- ------- ---------- ------------ ----------- -------------------------- -------------------------- -------- -------- -------- -----
  AUDIT_UPDATE        1 COMPLETE          16433           1 2018-07-23-21.50.00.135211 2018-07-23-21.50.10.584127        0          x''          0
  AUDIT_UPDATE        1 RUNNING           16448           2 2018-07-23-21.55.00.608060 -                                 - -        -            -

    2 record(s) selected.

最新の監査レコードを AUDIT.* にロードします。即時表

CALL AUDIT.UPDATE();

注: このプロシージャー呼び出しを実行した後に、以下のメッセージが表示される場合があります。

SQL1307N  An error occurred during invocation of the security audit facility.  Reason Code: "9".

このメッセージは、監査表にデータがロードされた最後の時点以降、アクティビティーがなかったことを示します。システム・エラーを示すものではありません。