エンタープライズで使われ続ける Db2 ～ Amazon RDS for Db2 Community Edition で監査ログ出力を検証する

Last updated at 2026-07-23Posted at 2026-07-23

こんにちは、インサイトテクノロジーの松尾です！

金融、公共、製造など、ミッションクリティカルな基幹システムで今なお現役稼働している Db2 は少なくありません。そうしたエンタープライズ環境で Db2 を運用する上で避けて通れないのが、誰が・いつ・何をしたかを記録する監査ログです。コンプライアンス要件を満たせるかどうかは、本番導入の可否を左右すると言っても過言ではありません。

そんな中、2026 年 6 月に Amazon RDS for Db2 で IBM Db2 12.1 のサポートが開始され、あわせて新しいエディション Community Edition (db2-ce) が追加されました。IBM ソフトウェアライセンス費用なしで使えるため、本番導入の前段階として、監査要件を満たせるかどうかを気軽に検証できる環境が手に入ったことになります。

本投稿では、この Community Edition を使って RDS for Db2 インスタンスを構築し、エンタープライズ利用で欠かせない監査ログ機能 (DB2_AUDIT) を実際に設定して、S3 に出力されたログの中身まで確認するところまでを、AWS マネジメントコンソールでステップバイステップで紹介します。技術者向けの投稿なので、IAM ポリシーや Db2 のストアドプロシージャ呼び出しなど、コードはできる限り貼るようにしています。なお、同じ構成を CloudFormation で自動構築する方法は、ボリュームの都合で続編の深掘り記事にまとめました。

1. はじめに

1.1. Amazon RDS for Db2 12.1 と Community Edition (db2-ce) とは

Amazon RDS for Db2 は、IBM Db2 をフルマネージドで運用できる RDS のデータベースエンジンです。2026 年 6 月に IBM Db2 12.1 のサポートが開始され、これに合わせて新しいエディションとして Community Edition (db2-ce) が追加されました。

RDS for Db2 では、これで 3 つのエディションから選べるようになっています。

エディション	エンジン識別子	推奨用途
Community Edition (new)	`db2-ce`	開発、テスト、非本番ワークロード
Standard Edition	`db2-se`	汎用的な本番ワークロード
Advanced Edition	`db2-ae`	より多くの CPU/メモリを必要とするミッションクリティカルなワークロード

Community Edition のポイントは、Standard/Advanced と機能面での差はなく、違いはリソースのエンタイトルメントだけという点です。具体的には、以下の制限が Db2 エンジンレベルで強制されます（裏で動いている EC2 インスタンスのスペックに関係なく、Db2 自体がこの上限までしかリソースを使いません）。

リソース	制限
メモリ	8 GB
CPU コア	4 vCPU

このため、Community Edition で使うインスタンスクラスはこの範囲に収まるものを選ぶのが基本です（例: db.t3.small / db.t3.medium / db.t3.large / db.m7i.large など）。範囲を超えるクラスを選んでもプロビジョニング自体はブロックされませんが、Db2 側の上限で頭打ちになるだけなので、コスト的にはあまり意味がありません。

ライセンス費用がかからないとはいえ、db2-ce を含むすべてのエディションで IBM Customer ID と IBM Site ID がパラメータグループに必須という点は要注意です。これは IBM 側が利用状況とエンタイトルメントを追跡するためのもので、IBM のサイトで無料登録すれば取得できます。

1.2. 本投稿のゴール

本投稿では、以下を実際に手を動かしながら進めます。

RDS for Db2 Community Edition のインスタンスを、コンソールでまず構築する
監査ログ機能 (DB2_AUDIT オプション) を有効化し、監査ポリシーを設定する
S3 に出力された監査ログを実際に確認し、どんな情報が記録されるかを見る

構築だけでなく、「監査ログをどう設計すればいいか」まで踏み込んで整理していきます。同じ構成を CloudFormation で自動構築する方法は、続編の深掘り記事で扱います。

2. 前提条件

本投稿で必要となるものと、以降で使用するリソース名をあらかじめ整理しておきます。

ネットワーク
- VPC、DB サブネットグループ用のサブネット（異なる 2 つの AZ にまたがるもの。今回は Multi-AZ 配置は行いませんが、RDS のサブネットグループ自体が最低 2 AZ 分のサブネットを要求するため用意します）
- セキュリティグループ（Db2 のポート 50000 で DB クライアントからの接続を許可）
IBM Customer ID / IBM Site ID
- db2-ce を含む全エディションでパラメータグループへの設定が必須です。IBM のサイトで無料登録すると取得できます。
  
  https://www.ibm.com/account/reg/us-en/signup?formid=urx-54367
監査ログ格納用の S3 バケット
- 同一リージョン内であること、パブリックアクセスは禁止であることが要件です（rds-db2-audit-logs-12345 として用意しました）
  
  https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Db2.Options.Audit.html
DB インスタンスへ接続して SQL / ストアドプロシージャを実行できる環境
- Db2 CLP (db2 コマンド) が使える環境、または JDBC 等で接続できるクライアント

以降の手順では、以下のリソース名を例として使用します（実際に構築する際は環境に合わせて置き換えてください）。

リソース	名前(例)
DB インスタンス識別子	`rds-db2-ce-audit-test`
データベース名	`TESTDB`
S3 バケット	`rds-db2-audit-logs-12345`
IAM ロール（監査ログ用）	`rds-db2-audit-role`
IAM ポリシー（監査ログ用）	`rds-db2-audit-policy`
オプショングループ	`db2-ce-audit-og`
パラメータグループ	`db2-ce-audit-pg`

では、早速構築していきましょう。

3. やってみよう：db2-ce インスタンスの構築

3.1. コンソールでの構築

まずはコンソールから構築してみます。Aurora and RDS > データベース > データベースの作成 と進みます。

エンジンのタイプで IBM Db2 を選択します。他のメジャーなエンジンと並んで選択肢に出てくるようになったのは地味に感慨深いですね。

データベース作成方法は フル設定、テンプレートは 開発/テスト を選びました。

エディションと AWS License Manager 設定

「設定」セクションに進むと、エディションの選択肢が出てきます。ここで各エディションのリソース制限が画面上に明記されていました。

IBM Db2 Community：8 vCPU と 8 GB の RAM に制限されます
IBM Db2 Standard：32 vCPU と 128 GB の RAM に制限されます
IBM Db2 Advanced：無制限です

ここで一つ注意点があります。AWS 公式のアナウンスブログでは Community Edition のリソース制限は 「メモリ 8 GB / CPU 4 vCPU」 と記載されているのですが、実際にコンソールの選択画面に表示されるのは 「8 vCPU と 8 GB の RAM」 でした。どちらが実際に強制される値なのかは負荷検証をしないと断定できないので、本稿では「ブログの記載とコンソール表示に差異がある」という事実だけ正直に記しておきます。実運用でシビアにリソースを見積もる際は、この点は要注意です。

ライセンスは Bring Your Own License (BYOL) と表示されます。Community Edition はライセンス費用がかからないはずですが、ライセンスモデルの表示自体はBYOL扱いのままなので、最初に見ると少し戸惑うかもしれません。

続いて AWS License Manager 設定 の名前入力を求められます。
ライセンス費用ゼロのCommunity Editionでも、この項目は入力必須でした。しかも名前のバリデーションが独特で、ハイフンが使えず英数字（a-z, A-Z, 0-9）のみという制約があります。前提条件で決めた rds-db2-ce-audit-test のようなハイフン入りの名前はここでは使えないので、Db2CeAuditTest のようなハイフン無しの名前に変更しました。

エンジンバージョンは 12.1.4.0.sb00085812.r1 が選べました。

DB インスタンス識別子は rds-db2-ce-audit-test、マスターユーザー名は dbadmin、認証情報管理は セルフマネージド + パスワードを自動生成 にしました。生成されたパスワードは、DB作成後にバナーの「認証情報の詳細を表示」から確認できます。

インスタンスクラスとストレージ

インスタンスクラスは、コストを最小限に抑えたかったので db.t3.small (2 vCPU / 2 GiB RAM) を選びました。

今回の検証は「エディションのリソース上限に当たるかどうか」を確かめるものではなく、あくまで「監査ログが正しく設定・出力できるか」に焦点を当てたものになります。リソース上限を検証したい場合は、上限に近いインスタンスクラス（db.m7i.large など）を選ぶ必要があります。

ストレージは汎用SSD (gp3) を 20 GiB（最小構成）、ストレージの自動スケーリングは無効にしました。

可用性・接続まわり

可用性と耐久性では、マルチAZ配置は 「スタンバイインスタンスを作成しないでください」 を選択しています。本稿では検証コストを抑えるためシングルAZ構成としました。マルチAZ構成に関する注意点は6章で改めて触れます。

接続設定では、VPCはデフォルトVPC、DBサブネットグループも適切なものを選択します。

パブリックアクセスは 「あり」 を選択しています。本来、本番環境ではパブリックアクセスなし＋踏み台サーバーやVPN経由での接続を推奨しますが、今回は検証環境としてローカル端末（DBeaver）から直接繋げるように、一時的にパブリックアクセスを有効化しました。ポート番号はDb2のデフォルトである 50000 です。

モニタリングと追加設定

モニタリングは「データベースインサイト - スタンダード」のままにしました。ここの「その他のモニタリング設定」にある ログのエクスポート（diag.log / notify.log） は、Db2の一般的な診断・通知ログをCloudWatch Logsに送る機能です。本稿でこれから設定する DB2_AUDITオプションによるS3への監査ログ出力とは別の機能なので、混同しないよう注意してください。

最後に「追加設定」です。ここに以下の重要な項目がまとまっています。

最初のデータベース名：TESTDB
DBパラメータグループ：「新しいパラメータグループを作成」を選択。BYOLライセンスのため、ここでIBM Customer IDとIBM Site IDを直接入力すると、RDSがカスタムパラメータグループを自動作成してくれます。パラメータグループ名は db2-ce-audit-pg としました
IBM カスタマー ID / IBM サイト ID：事前に取得しておいた値を入力（画像はマスキングしています）
オプショングループ：ここでは default:db2-ce-12-1 のままにしています。監査ログ用の DB2_AUDIT オプションを持つカスタムオプショングループは、S3バケットとIAMロールを準備してから4章で作成し、後付けで適用します
暗号化：今回は検証用途のためオフにしました。本番運用ではAWS KMSによる保存時暗号化を有効化することを強く推奨します
自動バックアップ：コスト最小化のためオフにしました

ここで一つ、地味に踏んだ罠を紹介します。パラメータグループの「説明」欄に日本語（例：「db2-ce-audit-pg (テスト用)」）を入力したところ、バリデーションエラーになりました。ASCII文字のみが許可されているようです。日本語話者の方は説明欄も英語で書く必要があります（db2-ce-audit-pg (test) のように）。

すべて入力すると、画面下部に概算月間コストが表示されます。今回の構成（db.t3.small + gp3 20GiB、シングルAZ）だと、DBインスタンス $40.88 + ストレージ $2.76 = 合計 $43.64/月でした。Community Editionを検証目的で少し動かしてみる分には現実的な金額だと思います。

内容を確認したら「データベースの作成」を押します。ステータスが 利用可能 になれば構築完了です。

3.2. 起動確認

ステータスが利用可能になったら、実際に接続できるかを確認します。本稿では DBeaver を使いました。

続いて DBeaver で新規接続を作成します。接続タイプの一覧には、MariaDB や MySQL、Oracle、PostgreSQL、SQL Server と並んで 「Db2 for LUW」 が「Popular」枠に表示されており、Db2 が主要なDBとして扱われていることが伺えます。

接続設定では、Host に DB インスタンスのエンドポイント、Port は 50000、Database は TESTDB、ユーザー名は dbadmin、パスワードは作成時に確認したものを入力します。

「テスト接続」で疎通確認をしたら接続完了です。接続ツリーを展開すると、Schemas の中に RDSADMIN と RDSDB が見えました。

4. やってみよう：監査ログ (DB2_AUDIT) の設定

ここからが本題です。db2-ceインスタンスを、エンタープライズ利用に欠かせない監査要件に応えられる状態（監査ログを取得できる状態）にしていきます。公式ドキュメントでは以下の6ステップで手順が示されているので、この順番で進めます。

S3バケットの作成
IAMポリシーの作成
IAMロールの作成とポリシーのアタッチ
オプショングループでDB2_AUDITを設定
監査ポリシーの設定
設定状態の確認

4.1. S3バケットの準備

監査ログの格納先となるS3バケットを作成します。要件は以下の3点です。

DBインスタンスと同じAWSリージョンにあること
パブリックアクセスを許可しないこと
バケットの所有者とIAMロールの所有者が同じAWSアカウントであること

S3バケット名はグローバルで一意である必要があるため、本稿では rds-db2-audit-logs-12345 として作成しました（12345部分は実際にはご自身の環境でユニークな文字列に置き換えてください）。

4.2. IAMポリシー・ロールの作成

RDSがDBインスタンスからS3バケットへ監査ログをアップロードするための権限を用意します。

IAMポリシーの作成

IAMコンソール → ポリシー → 作成 → JSON で以下を貼り付けます（バケット名は自分のものに置き換えてください）。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketAcl",
                "s3:GetBucketLocation"
            ],
            "Resource": [
                "arn:aws:s3:::rds-db2-audit-logs-12345"
            ]
        },
        {
            "Sid": "Statement2",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:ListMultipartUploadParts",
                "s3:AbortMultipartUpload"
            ],
            "Resource": [
                "arn:aws:s3:::rds-db2-audit-logs-12345/*"
            ]
        },
        {
            "Sid": "Statement3",
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

ポリシー名は rds-db2-audit-policy としました。

一点補足します。3つ目のステートメントにある s3:ListAllMyBuckets は、一見監査ログの転送には不要に見えるかもしれません。公式ドキュメントには以下のように理由が明記されています。

Amazon RDS needs the s3:ListAllMyBuckets action internally to verify that the same AWS account owns both the S3 bucket and the RDS for Db2 DB instance.

つまり、RDSが「指定されたS3バケットの所有者アカウントと、DBインスタンスの所有者アカウントが一致しているか」を内部的に検証するために必要な権限です。個別バケットへの権限だけでは所有者の照合ができないため、この一段広い権限が別途必要になる、という理屈です。省略しないよう注意してください。

なお、バケットをSSE-KMSで暗号化している場合は kms:GenerateDataKey / kms:Decrypt の権限も追加が必要ですが、本稿のバケットは暗号化なしのため省略しています。

IAMロールの作成

IAMコンソール → ロール → 作成 → 信頼されたエンティティタイプ：AWSのサービス → ユースケース：RDS → RDS - Add Role to Database を選択します。信頼ポリシーは以下のようになります。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": ["rds.amazonaws.com"]
            },
            "Action": ["sts:AssumeRole"]
        }
    ]
}

先ほど作成したポリシー rds-db2-audit-policy をアタッチし、ロール名は rds-db2-audit-role としました。

4.3. オプショングループで DB2_AUDIT を有効化

ここで、本稿で一番の発見を紹介します。

RDSコンソールの「オプショングループ」→「グループの作成」画面を開くと、エンジンの選択肢に db2-ae と db2-se しかなく、db2-ce が存在しません。これは日本語UIだけでなく、英語UIでも同様でした。
※ブログ執筆時点の情報なのでいずれ解消されるとは思いますが。

「あれ、db2-ceだと監査ログ機能自体が使えないのか？」と一瞬焦ったのですが、結論から言うとそうではありませんでした。AWS CLIを使えば、db2-ce向けのオプショングループを問題なく作成できます。

aws rds create-option-group \
  --option-group-name db2-ce-audit-og \
  --engine-name db2-ce \
  --major-engine-version 12.1 \
  --option-group-description "db2-ce audit test" \
  --region ap-northeast-1

{
    "OptionGroup": {
        "OptionGroupName": "db2-ce-audit-og",
        "OptionGroupDescription": "db2-ce audit test",
        "EngineName": "db2-ce",
        "MajorEngineVersion": "12.1",
        "Options": [],
        "AllowsVpcAndNonVpcInstanceMemberships": true,
        "OptionGroupArn": "arn:aws:rds:ap-northeast-1:XXXXXXXXXXXX:og:db2-ce-audit-og"
    }
}

さらに面白いことに、一度CLIでオプショングループを作成してしまえば、そのあとの「オプションの追加」操作はConsole上で問題なく行えます。 Console → オプショングループ → 作成した db2-ce-audit-og を開く → 「オプションの追加」→ DB2_AUDIT を選択すると、他のエディションと同じようにプルダウンから選べ、IAM_ROLE_ARN / S3_BUCKET_ARN の入力欄も普通に表示されます。

IAM_ROLE_ARN：4.2で作成した rds-db2-audit-role のARN
S3_BUCKET_ARN：arn:aws:s3:::rds-db2-audit-logs-12345

を入力して追加します。

つまり結論としては、「db2-ceでは監査ログ設定がConsoleで完結しない」ではなく、「オプショングループの新規作成という最初の一手間だけAWS CLI（またはCloudFormation/API）が必要で、それ以降はConsoleで問題なく完結できる」 ということです。これは公式ドキュメントのどこにも明記されていない、Console固有の制限でした。Oracleの標準監査パラメータのようにDBインスタンスの再起動が必要になるケースもありますが、DB2_AUDITオプションの追加自体は再起動不要で、オプショングループが有効になった時点ですぐに使える点も公式ドキュメント通りでした。

最後に、作成したオプショングループをDBインスタンスに適用します。こちらはConsoleで完結します。

RDSコンソール → データベース → 対象のインスタンスを選択 → 変更 → オプショングループを db2-ce-audit-og に変更 → すぐに適用 を選択 → DBインスタンスを変更

4.4. 監査ポリシーの設定

オプショングループの準備ができたので、いよいよデータベースごとの監査ポリシーを設定します。

公式ドキュメントには「監査ポリシーを設定するには、マスターユーザーで rdsadminデータベースに接続してから、ストアドプロシージャを呼び出してください」と明記されています。

db2 "connect to rdsadmin user master_user using master_password"
db2 "call rdsadmin.configure_db_audit('testdb', 'ALL', 'BOTH', ?)"

そのため、DBeaverで新しい接続を作成し、DatabaseにRDSADMINを指定して繋ぎ直してストアドプロシージャを実行します。エンドポイントやユーザー情報は、TESTDBに接続したときと同じです。

CALL RDSADMIN.CONFIGURE_DB_AUDIT('TESTDB', 'ALL', 'BOTH', ?)

なお、実行後にDBeaverの結果パネルに IndexOutOfBoundsException: Index -1 out of bounds for length 1 という表示が出て一瞬焦りましたが、これはSQLCODE/SQLSTATEを伴わないJavaの例外で、OUTパラメータの結果表示に関するDBeaver側の不具合でした。実際の処理は成功していたので、慌てずに後述の確認手順で成否を判断することをおすすめします。

さらに、4.6節で解説する設計方針に沿って、ALLには含まれない CONTEXT / EXECUTE / ERROR カテゴリも個別に追加しました。

CALL RDSADMIN.CONFIGURE_DB_AUDIT('TESTDB', 'CONTEXT', 'BOTH', ?)
CALL RDSADMIN.CONFIGURE_DB_AUDIT('TESTDB', 'EXECUTE', 'SUCCESS,WITH', ?)
CALL RDSADMIN.CONFIGURE_DB_AUDIT('TESTDB', 'ERROR', 'AUDIT', ?)

4.5. 設定状態の確認

設定が正しく反映されたかは、rdsadmin.get_task_status で確認できます。こちらも RDSADMIN 接続で実行します。

SELECT task_id, task_type, database_name, lifecycle,
    VARCHAR(bson_to_json(task_input_params), 500) AS task_params,
    CAST(task_output AS VARCHAR(500)) AS task_output
FROM TABLE(rdsadmin.get_task_status(null, 'TESTDB', 'CONFIGURE_DB_AUDIT'))

実行結果です。4回の呼び出し（ALL / CONTEXT / EXECUTE / ERROR）すべて LIFECYCLE が SUCCESS になっていることが確認できました。

これで、先ほどDBeaverに表示されたエラーが実処理には影響していなかったことも裏付けが取れました。configure_db_audit実行後にDBeaverでエラーらしき表示が出ても、慌てずこのクエリでLIFECYCLEを確認するというのが実践的なTipsです。

念のため、TESTDB接続側でテスト用のSQLも実行しておきました。これは1時間後にS3のログ内容を確認する際の材料になります。

CREATE TABLE AUDIT_TEST (ID INT, NAME VARCHAR(50));
INSERT INTO AUDIT_TEST VALUES (1, 'test');
SELECT * FROM AUDIT_TEST;

4.6. 監査ログを設計する際の観点

ここまでで監査ログの「動かし方」は一通り確認できました。最後に、実際のエンタープライズ環境で監査ポリシーを設計する際の考え方を整理しておきます。

カテゴリ選定の観点

監査カテゴリは目的に応じて選ぶのが基本です。全部をBOTH（成功・失敗とも記録）にすると当然ログ量が増えるので、監査目的とカテゴリを対応づけて考えるとよいでしょう。

監査したいこと	対応カテゴリ
誰がログインしたか	`VALIDATE`
権限昇格・権限変更が行われたか	`SECMAINT`
テーブルやスキーマの作成・削除（DDL）が行われたか	`OBJMAINT`
管理者権限が必要な操作が行われたか	`SYSADMIN`
どんなSQLが実行されたか	`EXECUTE`

ALLの落とし穴

前述の通り、ALLを指定してもCONTEXT・EXECUTE・ERRORは含まれません。これらは相対的にログ量が増えやすい、あるいは入力データを含みうるカテゴリのため、意図的にALLから除外されていると考えられます。「監査要件をきちんと満たしたいなら、ALLを指定した上で、この3つを個別に追加する必要がある」ということを覚えておいてください。

STATUSの粒度設計

カテゴリごとにBOTH（成功・失敗とも）/FAILURE（失敗のみ）/SUCCESS（成功のみ）/NONE（記録しない）を選べます。例えば「ログイン監視は成功・失敗どちらも見たいのでVALIDATEはBOTH、権限チェックは失敗だけ分かれば十分なのでCHECKINGはFAILURE」のように、重要度に応じてログ量とコストのバランスを取るのが実践的です。

EXECUTE の WITH DATA / WITHOUT DATA 判断

EXECUTEカテゴリは、SQLの入力値（ホスト変数やパラメータマーカー）まで記録するかどうかをWITH/WITHOUTで選べます。調査のしやすさという点ではWITHが有利ですが、個人情報などがログに残るリスクや、ログ量の増大というトレードオフがあります。監査の目的が「不正アクセスの検知」なのか「操作内容の完全な追跡」なのかによって、この判断は変わってきます。

いずれにしても、これらの設計判断は一律の正解があるわけではなく、対象システムの要件・法令・社内ポリシーに照らして決めるべきものです。本稿ではあくまで「こういう観点で考えられる」という整理にとどめます。

5. 監査ログの中身を見てみる

5.1. テストSQLの実行

4.5節で実行した以下のテストSQLを材料に、実際にS3へ出力された監査ログの中身を確認していきます。

CREATE TABLE AUDIT_TEST (ID INT, NAME VARCHAR(50));
INSERT INTO AUDIT_TEST VALUES (1, 'test');
SELECT * FROM AUDIT_TEST;

5.2. S3でログを確認する

1時間待ってS3バケットを確認すると、db2-audit-logs/インスタンスのリソースID/日時(UTC)/ というフォルダの下に、監査カテゴリごとの .del ファイル(audit.del、checking.del、context.del、execute.del、objmaint.del、secmaint.del、sysadmin.del、validate.del)と auditlobs というファイルが出力されていました。

.delはDb2ネイティブの区切りテキストエクスポート形式の拡張子です。auditlobsは後述しますが、EXECUTE WITH DATAで記録される実際のSQLテキストなどを格納する領域です。

タイムスタンプから面白いことが分かりました。フォルダ名は 2026-07-19_10:00:00_UTC(UTC10時ちょうど)、ファイルの更新日時は 2026-07-19 07:00:05 PM JST(UTC 10:00:05)で、UTCの毎正時から数秒後というタイミングで書き出されていることになります。公式ドキュメントには転送間隔の明記がありませんが、この実測データから「UTCの毎時0分を境界とした1時間ごとのバッチ処理」と推測できます。DB2_AUDITはAWS側の完全マネージドな仕組みとして、おそらく1時間単位のバッチで動いているようです。

5.3. インスタンスレベル vs データベースレベル

validate.delやsysadmin.delの中身を開くと、ヘッダー行なしのカンマ区切りで、こんな行が並んでいました。

"2026-07-19-10.00.03.730089","SYSADMIN","GET_SNAPSHOT",3,0,"","rdsdb","RDSDB",,,"*LOCAL.rdsdb.260719100028","db2bp",,,,,,,,,,,,,,,,"rdsdb","ip-10-7-1-58",

ユーザー名はrdsdb、データベース名はRDSDBばかりで、自分で作ったTESTDBやdbadminの操作はほとんど見当たりません。GET_SNAPSHOTというアクションが約30秒おきに大量に記録されており、RDS基盤自体がインスタンスを監視するために内部的に発行しているトラフィックだと考えられます。

これは実務上重要な示唆です。ALLで監査を有効にすると、自分のアプリケーションの操作だけでなく、RDS基盤の内部管理トラフィックまでノイズとして大量に記録されるということです。ログの保管コストを見積もる際や、監査ログから不正操作を調査する際は、この内部トラフィックと自分のアプリケーションの操作を区別してフィルタする必要があり、ログの肥大化をどう防ぐかの検討が必要そうです。

このノイズが混ざっていたのは、ここまで見ていたインスタンスレベルのログだったからです。ドキュメントによれば .../date_time_utc/db_name/ という一段深いデータベースレベルのログも別途出力されるとのことで、実際に1時間後のフォルダを見ると TESTDB/ サブフォルダが追加されていました。

こちらを開くと、objmaint.delにテストで作成した AUDIT_TEST テーブルの作成イベントがそのまま記録されていました。

"2026-07-19-10.11.54.043305","OBJMAINT","CREATE_OBJECT",5,0,"TESTDB","dbadmin","DBADMIN",,,"::ffff:xx.xx.xx.xx.60838.260719101136","DBeaver","NULLID","SYSSH200",0,"DBADMIN","AUDIT_TEST","TABLE",,,,,,,"      `","                    ",,"192.168.3.12","DBeaver 26.1.2 - SQLEditor <Script-4.sql>",...

ユーザー名dbadmin、接続元アプリケーションDBeaver(バージョン・スクリプト名まで)、接続元IP192.168.3.12、対象オブジェクトAUDIT_TESTと、まさに自分の操作そのものです。インスタンスレベルはRDS基盤自身のノイズだらけ、データベースレベルは自分のアプリケーションのクリーンな監査証跡 という棲み分けだと分かりました(なお、最初の1時間分でこのイベントが空だったのは、カテゴリ設定完了(UTC 10:09)とテストSQL実行(UTC 10:11)がバッチの境界をまたいでいただけで、設定ミスではありませんでした)。

最後にexecute.delも覗いてみると、EXECUTEをSUCCESS,WITH(成功時のみ、入力データも記録)で設定した通りに動いていて、実際にSQLの実行が記録されていることまでは確認できました。ただし、WITH DATAで記録される実際のSQLテキストはexecute.delにインラインで入っておらず、auditlobsという別ファイルへのポインタ参照になっていて、これを正しく読み解くにはDb2のEXPORTユーティリティが使う独自の仕組み(LOB Location Specifier)の理解と、それを解決するちょっとしたスクリプトが必要でした。この部分は本題からは一歩踏み込んだ内容になるので、別記事として深掘りする予定です。

とはいえ、ここまでで「監査ログが実際に機能し、自分のアプリケーションの操作(テーブル作成やSQL実行)がデータベースレベルのログにきちんと記録される」ことは確認できました。エンタープライズの監査要件を満たせるかどうかという、本稿のそもそもの目的は達成できたと言えそうです。

6. ハマりどころ・Tips

ここまでの各章で触れた実機ならではの発見を、チェックリスト的に振り返っておきます(詳細は各節を参照してください)。

Community Edition のリソース制限を超えるインスタンスクラスを選んでも作成自体は止められない(3.1節)。Db2エンジン側で上限に頭打ちになるだけなので、コスト面で選ぶ意味は薄い
AWS License Manager 設定は db2-ce でも入力必須(3.1節)。しかも名前にハイフンが使えず英数字のみという制約がある
公式ブログとConsole表示でリソース制限の数値が食い違う(3.1節)。「4 vCPU」(ブログ)と「8 vCPU」(Console)
DBパラメータグループの「説明」欄は日本語不可(3.1節)。ASCII文字で書く必要がある
オプショングループの新規作成だけはConsoleでdb2-ceが選べない(4.3節)。CLIで作成すれば、以降のオプション追加はConsoleで問題なく完結する
監査ポリシーの設定(configure_db_audit)はRDSADMINデータベースへの接続が必須(4.4節)。TESTDB接続内でスキーマが見えていても呼び出せない
DBeaverでconfigure_db_audit実行時にIndexOutOfBoundsExceptionが出ることがある(4.4節)。クライアント側の表示不具合で、実処理は成功していることが多い。get_task_statusのLIFECYCLEで確認するとよい
ALLだけではCONTEXT/EXECUTE/ERRORは監査対象に含まれない(4.4節)。個別に追加が必要
監査ログのS3反映には最低1時間かかる(5.2節)。転送間隔は非公開だが、実測ではUTC正時を境界とした1時間バッチと推測される
インスタンスレベルのログにはRDS基盤自身の内部トラフィックが大量に混ざる(5.3節)。自分のアプリケーションの操作を追うならデータベースレベルのログを見る

加えて、記事中では詳しく触れていませんが、今回の検証で判断を保留にした点も正直に書いておきます。

Multi-AZ構成について、今回はコスト最小化のためシングルAZで検証しましたが、本番でMulti-AZを検討する際はどのようにリソース制限がかかるのかなど注意が必要です。
フェイルオーバー時にDB2_AUDITオプション(S3への監査ログ転送設定)がスタンバイ側にどう引き継がれるかは、公式ドキュメントに明記がなく今回は検証していません。本番導入を検討する際は、ここは別途確認が必要です

本番運用を見据えた場合、今回触れなかった検討事項として、監査ログの長期保管をどう設計するか(S3のライフサイクルポリシーでGlacier等へ移行するなど)、Community EditionからStandard/Advanced Editionへのアップグレードパス(インプレースで変更可能とドキュメントにはあります)、といった点も本番導入前には確認しておく価値がありそうです。

7. 終わりに

本稿では、Amazon RDS for Db2 Community Editionを使って、エンタープライズ運用に欠かせない監査ログ機能(DB2_AUDIT)を実際に構築・設定し、S3に出力されたログの中身まで確認しました。

ライセンス費用を気にせず試せるCommunity Editionのおかげで、監査要件を満たせるかどうかという「本番導入前に一番気になる部分」を気軽に検証できたのは大きなメリットだと感じました。監査ログのS3転送については、DB2_AUDITオプションとして公式にサポートされている点は運用者にとってありがたいポイントです。

一方で、Consoleだけでは完結しない部分(オプショングループの新規作成)があったり、ドキュメントの記載とConsoleの実際の挙動に差異があったりと、実際に手を動かしてみないと分からない発見も多くありました。本稿がこれから同じ検証をされる方の参考になれば幸いです。

記録される監査ログファイルからのSQLテキストの読み解き方、および、同じ構成を CloudFormation で自動構築する方法については、ボリュームの都合で別稿に譲ります。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up