Oracle Data SafeでDedicated Exadata Infrastructure上のAutonomous AI DatabaseのセキュリティイベントをSIEMへリアルタイム配信する

※ 本記事は、German Viscusoによる”Real-Time Database Security Events from Autonomous AI Database on Dedicated Exadata Infrastructure to Your SIEM with Oracle Data Safe“を翻訳したものです。

2026年11月2日

Dedicated Exadata Infrastructure上のAutonomous AI Database（ADB-D）について話すとき、セキュリティチームからほぼ毎回聞かれる質問があります。「誰かがADMINのパスワードを試したり、強力な権限を付与したり、監査ポリシーを変更したりした場合、SOCはどれくらい早く把握できますか。」 私たちの回答は、現在利用しているSIEM上で、十分な関連情報とともに、1分を大きく下回る時間で確認できる、というものです。

この記事では、そのパイプラインを最初から最後まで構築します。Oracle Data Safeがデータベースを監視してアラートを上げ、OCI Eventsが構造化イベントに変え、OCI Streamingが永続バッファとして蓄積し、小さな転送プログラムがSplunk HTTP Event CollectorやHTTPSでJSONを受け付ける宛先へ送ります。すべてOCIコンソールかCLIを使い、記載した数値はADB-Dでの実測値です。

Oracle Data Safeとは

Oracle Data Safeは、OCI、他社クラウド、オンプレミスのOracle Database向けの統合セキュリティサービスです。一つのコンソールで、構成とユーザー権限の評価、操作監査、機密データの検出とマスキング、SQL Firewallの管理を行います。

この記事で重要なのは、次の3機能です。

• 操作監査： 統合監査証跡を継続収集し、最大12か月オンライン保存し、その後もアーカイブできます。
• アラートポリシー： 収集した各監査レコードを評価し、管理者のログイン失敗や権限変更などのルールに合えばアラートを上げます。
• ユーザー評価とセキュリティ評価： アカウントと構成のスナップショットを取得し、更新ごとに設定済みの基準と比較して差異を知らせます。

Data Safeのあらゆる操作は、OCI Eventsにイベントとして公開されます。16カテゴリ、310種類あり、この仕組みが以降の構成を可能にします。

ADB-Dでは、Data Safeはデータベースの契約に含まれるため、追加のライセンスなしで実施できます。

アーキテクチャの全体像

すべてのData Safeイベントを、1つのEventsルールで1つのストリームに送り、各利用側が自分の速度で読み取る、という設計です。

ADB-DのData Safeイベントパイプライン：1つのルール、1つのストリーム、複数の利用側

1. データベースが、ログオン、DDL、権限変更、構成変更の統合監査レコードを記録します。
2. Data Safeが数秒で収集してアラートポリシーを評価し、各アラート、基準との差異、操作に対してイベントを公開します。
3. OCI EventsルールがすべてのData Safeイベントをストリームに書き込みます。別の限定的なルールで、重大アラートを人に並行通知できます。
4. OCI Streamingが永続保存し、宛先ごとのコンシューマグループで読み取れるようにします。Splunk、別のSIEM、アーカイブは互いに干渉しません。
5. 転送プログラムがストリームを読み、SIEMへ送り、SIEMがバッチを受理してから読取位置を確定します。

EventsルールからSIEMを直接呼ばないのは、SIEMが保守中、低速、ファイアウォール変更の影響下にある場合に備えるためです。ストリームを最大7日保持することで、転送を停止位置から再開でき、イベントを失わないようにします。

手順に沿って構築する

ADB-D、コンパートメント内のData Safe、Streaming、Eventsを管理する権限、Splunk HECトークン（またはHTTPSコレクタ）が必要です。ストリームとルールを置くコンパートメントを<security-compartment>とします。

手順1：ADB-DをData Safeに登録する

OCIコンソールでOracle Database > Data Safe – Database Security > Target Databases > Register Databaseを開き、Autonomous AI Databaseから対象のADB-Dを選びます。Data Safeは、データベースのVCN内のData Safeプライベートエンドポイントで接続します。未作成ならウィザードが作成します。要求されるデータベース資格証明を入力してください。

完了後、対象はActiveになります。

手順2：監査収集の実行を確認する

Activity Auditing > Audit Trailsで、対象の統合監査証跡がCollectingであることを確認します。異なれば選択してStartを実行します。収集は連続的で、テストではSQL実行から2～32秒でレコードがData Safeに届きました。

手順3：監査ポリシーを設定する

Activity Auditing > Audit Policiesで対象を選び、少なくとも次を有効にします。

• Critical database activity： ユーザー、ロール、権限、プロファイル、監査ポリシーの変更とALTER SYSTEM。
• Database schema changes： テーブル、ビュー、プロシージャなどへのDDL。

Data Safeが、これらをデータベース内の統合監査ポリシーとして作成、有効化します。ログオン失敗を記録する事前定義済みのORA_LOGON_FAILURESはAutonomous AI Databaseで既に有効で、これも収集します。

手順4：アラートポリシーを適用する

Security Center > Alerts > Alert Policiesで、事前定義済みポリシーを対象に適用します。一致した監査レコードからアラートが生成されます。

独自のルールと重大度を持つカスタムポリシーも作成でき、同じイベント種別で届きます。

必要に応じて最新のUser AssessmentとSecurity Assessmentを基準に設定し、毎日更新します。基準と異なる更新ごとに差異イベントが発生します。

手順5：ストリームを作成する

1パーティションでData Safeの生成量を十分処理できます。1週間のSIEM停止でも失わないよう、保持を最大の168時間にします。保持期間は作成時に固定されます。

oci streaming admin stream create \
  --compartment-id <security-compartment-ocid> \
  --name datasafe-events --partitions 1 --retention-in-hours 168

手順6：OCI Eventsにストリーム書き込みを許可する

allow service cloudEvents to use stream-push in compartment <security-compartment>
allow service cloudEvents to read streams in compartment <security-compartment>

手順7：Eventsルールを作成する

次の条件は、現在と将来のすべてのData Safeイベント種別に一致します。対象と同じ、または上位のコンパートメントに置いてください。子コンパートメントのイベントにも一致します。

oci events rule create \
  --compartment-id <security-compartment-ocid> \
  --display-name datasafe-all-events --is-enabled true \
  --condition '{"eventType":"com.oraclecloud.datasafe.*"}' \
  --actions '{"actions":[{"actionType":"OSS","isEnabled":true,"streamId":"<stream-ocid>"}]}'

Criticalアラートを人にも通知するには、Notificationsアクションと次の条件を持つルールを追加します。

{"eventType": ["com.oraclecloud.datasafe.generateauditalert"],
 "data": {"additionalDetails": {"severity": ["Critical"]}}}

手順8：OCI Container Instancesで転送プログラムを実行する

付属の参照実装dsfwdはOCI SDKを使う小さなPythonサービスです。コンシューマグループで読み、Splunk HECのフィールドに対応付け、HECが受理した後だけ読取位置を確定します。バッチ中の1件が拒否されれば、それを分離して記録し、残りを送ります。

リポジトリのDockerfileでイメージを作成してOCI Container Registryへ登録し、SIEMへ外向き接続できるプライベートサブネットにコンテナインスタンスを作ります。Ampere A1の1 OCPUで十分です。環境変数は次のとおりです。

DSFWD_AUTH=resource_principal
DSFWD_STREAM_ID=<stream-ocid>
DSFWD_GROUP=splunk
DSFWD_HEC_URL=https://<your-splunk>:8088
DSFWD_HEC_TOKEN=<hec-token>
DSFWD_HEC_INDEX=oci_security

次に、そのコンテナインスタンスだけにストリームの読み取りを許可します。

allow any-user to use stream-pull in compartment <security-compartment>
  where request.principal.id = '<container-instance-ocid>'
allow any-user to read streams in compartment <security-compartment>
  where request.principal.id = '<container-instance-ocid>'

VM上のsystemdサービス（インスタンスプリンシパル使用）や、OCI APIキーを使える環境でも動きます。リポジトリには各方式のユニットファイル、環境テンプレート、IAM文が含まれます。

独自転送プログラムを運用しない場合は、Kafka互換エンドポイント経由のSplunk Distribution of the OpenTelemetry CollectorやSplunk Sink Connectorを使うKafka Connect、またはOCI Functionへ送るConnector Hubでも同じストリームを使えます。

動作を確認する

パイプラインを用意したら試します。誤ったパスワードでADMINに接続します。

$ sqlplus admin@proddb01_high
Enter password:
ORA-01017: invalid credential or not authorized; logon denied

数秒後、次のイベントがストリームに格納されます（識別子は短縮）。

{
  "eventType": "com.oraclecloud.datasafe.generateauditalert",
  "source": "DataSafe",
  "eventTime": "2026-10-26T17:33:25Z",
  "eventID": "3f6c2a9e-1b47-4d2a-9c58-7e0b4a1d6f23",
  "data": {
    "compartmentName": "DatabaseSecurity",
    "resourceName": "alert",
    "additionalDetails": {
      "ruleName": "Failed logins by admin user",
      "severity": "Critical",
      "operation": "LOGIN",
      "operationStatus": "Failed",
      "errorCode": "ORA-01017",
      "userName": "ADMIN",
      "clientIPs": "10.0.4.25",
      "clientHostname": "jump-host-01",
      "clientProgram": "sqlplus@jump-host-01 (TNS V1-V3)",
      "osUserName": "oracle",
      "targetName": "PRODDB01",
      "operationTime": "2026-10-26T17:04:55.145915Z",
      "alertURLInConsole": "https://cloud.oracle.com/data-safe/alerts/..."
    }
  }
}

誰が、どこから、どのプログラムで操作し、データベースがどう応答したかという、分析担当者に必要な情報がイベントに含まれます。OCIコンソールのアラートへ直接移動できるリンクもあります。DDLや権限変更ではcommandTextに実行文が入り、パスワードはマスクされます（create user APP_RO identified by *）。

転送時、_timeはData Safeイベント時刻、hostは対象名にし、系列別のsourcetype（oci:datasafe:alert、oci:datasafe:drift、oci:datasafe:audittrailなど）と、重大度や種別の索引フィールドを設定します。SOCの最初の検索は次の1行です。

index=oci_security sourcetype=oci:datasafe:alert severity::CRITICAL
| table _time host event.data.additionalDetails.userName
        event.data.additionalDetails.clientIPs
        event.data.additionalDetails.errorCode

4 ECPUの基本的なADB-D（Oracle AI Database 26ai）で、制御したSQLを実行し、各区間を測定した結果です。

Data Safeが生成したすべてのアラートが、宛先へ到達しました。転送プログラムを停止し、その間に3件のアラートを発生させてから再開するテストも行いました。次の未確定位置から読み取りを再開し、重複なく、その3件だけを配信しました。

セキュリティ状態の変化も同じ経路です。ユーザー作成後に評価を更新すると、userassessmentdriftfrombaseline、securityassessmentdriftfrombaseline、期限切れパスワードのアカウントを示すuserassessmentpasswordexpirydateが届きました。監査収集の停止と再開はstopaudittrail、resumeaudittrailが知らせるため、監査記録が途絶えたこともSOCが把握できます。

コスト

ADB-Dをご利用のお客様は、このデータパイプラインを非常に低コストで運用できます。Oracle Data Safeは、一般的なターゲットで生成されるデータ量であれば、データベースに付属する無償利用枠の範囲内で利用でき、その他のサービスについても、実際の使用量に応じた従量課金となります。

OCI外のOracle Databaseも保護できます。2027年2月28日までは、オンプレミス、コンピュートインスタンス上、Amazon RDS for OracleのData Safeサービス料金が免除されます（キャンペーン詳細）。監査レコードの月間無料枠超過は通常どおり課金されます。最新の定価はOracle Cloud Price Listをご覧ください。

次の2設定でData Safeの費用を予測しやすくできます。

• Paid usageは標準で有効で、月100万件以降も収集します。Autonomous AI Databaseでは有効のままにしてください。無効で無料枠に達すると翌月まで停止し、その月の記録を取り逃す場合があります。
• 監査ポリシーが量を決めます。 この記事は通常のアプリケーションクエリではなく管理とセキュリティ操作を監査するので、多くのADB-Dは100万件以内です。各対象のAudit Profileで収集量を確認でき、Data Safe自身のサービスアカウントの操作は件数から除外されます。

本番運用のヒント

1. パイプライン自体を監視する： SIEMでstopaudittrail.end、auditcollectionwarning、disabledtargetalertpolicyassociation、throttlealertgenerationと無通信を監視します。評価更新間隔を超えてイベントが来なければ、上流を調べます。
2. 宛先ごとにコンシューマグループを使う： Splunk、別のSIEM、アーカイブは独立して読みます。ある期間を再送するには時刻指定で新グループを開始すれば、本番に影響しません。
3. eventIDで重複排除する： EventsとStreamingは少なくとも1回の配信です。転送側は送信済みの重複を除外し、残りは相関検索でeventIDを使います。
4. 秘密情報はOCI Vaultへ： HECトークンを設定ファイルに書かず、Vaultシークレットとして保存してデプロイ時に渡します。
5. 適切な場所で絞る： SIEMにはすべて送り、呼び出し通知はCritical限定などのEventsルールにします。カスタムポリシーで、アプリケーション用以外のアカウントによる機密テーブル参照などを検出できます。
6. 長期保存はData Safeで計画する： SIEMにはリアルタイムアラートを送り、完全な監査履歴は調査とコンプライアンス報告用に最大7年保持します。

結論

Oracle Data Safe、OCI Events、OCI Streamingで、ADB-Dのセキュリティイベントを十分な文脈とともに1分未満でSIEMへ届け、SIEMが混雑しても失わずに済みます。既存のOCIサービスを組み合わせ、半日で設定でき、将来導入するセキュリティツールにも同じストリームを配信できます。

このパターンを皆様の環境でどう活用したか、ぜひお聞かせください。

追加資料

• Oracle Data SafeとData Safe FAQ
• Oracle Data Safeのイベント種別
• Data Safeアラートの概要
• 監査プロファイル：保持と有料利用
• OCI Events Service
• 転送の参照実装dsfwd