監査データが欠落している場合… (2026/07/24)

監査データが欠落している場合… (2026/07/24)

https://www.ateam-oracle.com/the-case-of-the-missing-audit-data

投稿者：Vinay Kalra | Principal Cloud Solution Architect

これは実話ですが、犯人を保護するために名前だけは変更されています。

OCI監査ログを（OCIストリーム経由で）セキュリティ情報イベント管理（SIEM）プラットフォームに送信することは、i/qsの一般的なユースケースであり、推奨されています。では、SIEMへの接続が数週間途絶えた場合、どうなるでしょうか？この記事では、その状況、失われた監査データの復旧方法、そして再発防止策について説明します。

犯罪現場

OCI で SIEM ソフトウェアを実行している仮想マシン (VM) が「終了」しました。監査レコードはOCI ストリーム経由で同じ VM に送信されるため、インスタンスを終了したのが誰なのかはまだわかりません。さらに重要なことに、何週間も管理者に通知されませんでした。監査データを OCI ストリームに送信するには、サービス コネクタをストリーム ターゲットに構成する必要があります。デフォルトでは、ストリームは 24 時間分の履歴データしか保存できませんが、これを 7 日まで構成できます。失われた何週間分のデータを取り戻すにはどうすればよいでしょうか?

修正

OCI は 365 日分の監査ログを保持します。OCI コンソールからログの一部をダウンロードできますが、コンソールでは最大 2 週間分の監査記録しか取得できません。大規模なデータセットの場合、ログを取得する最良の方法は REST/SDK または OCI CLI を使用することです。私は、設定可能な期間の監査ログを復元するための Python SDK を使用したスクリプトを作成しました。

このスクリプトを実行するには、Python OCI モジュールがローカルコンピュータにインストールされている必要があります。または、OCI CloudShell を使用することもできます。

このコードが行うこと

前提条件とスクリプトの実行方法の詳細については、README.md ファイルを参照してください。スクリプトが完了すると、レポートファイルが生成されます。このレポートには、各ログファイルのステータスと、各ログに含まれるイベント数が表示されます。

注：監査ログには多数のイベントレコードが含まれていることにご注意ください。このスクリプトの実行には時間がかかる場合があります。特に、監査イベントが発生するリージョンやコンパートメントが多い場合は、さらに時間がかかる可能性があります。

監査ログが取得できたので、SIEMが欠落したイベントを解析できるように、データをストリームにバックフィルして再生する必要があります。 

Steamを再プレイする際には、2つの選択肢があります。

  1. ほとんどのSIEMはファイルからデータを取得できるため、auditRecoveryスクリプトから取得したファイルをオブジェクトストレージや、SIEMがデータを取得できる任意のファイルシステムにアップロードできます。このオプションは、大規模なデータセットの場合に推奨されます。
  2. 監査データをストリームにアップロードする別のスクリプトを作成しました 。これは上記の AuditRecovery スクリプトと併用してください。このスクリプトは比較的大きなデータセットをアップロードできますが、上記のオプション 1 よりも処理速度が遅くなる可能性があります。これは、OCI Stream API の呼び出しごとのデータアップロード上限が 1MB であるためです。

このコードの動作：

  1. ディレクトリからファイルを読み込み、各ファイルを解凍します。詳細は上記の「AuditRecovery」スクリプトを参照してください。
  2. 1MB以下のイベントのバッチを計算し、（Base64エンコードして）送信します。
  3. 「report.log」ファイルと「report.state」ファイルを作成します。スクリプトが完了前に失敗した場合は、スクリプトを再実行すると、中断したところから処理が再開されます。新しいジョブを開始するには、「report.log」ファイルと「report.state」ファイルを削除してください。

それでは、実際にVMインスタンスを終了させたのは誰なのかを突き止めましょう…

防止

このような事態を防ぐために講じることができる対策がいくつかあります。少なくとも、インスタンスが終了する際には、管理者に直ちに通知されるようにする必要があります。

ポリシー執行

すべてのテナントには、「テナント管理ポリシー」と呼ばれるデフォルトポリシーが存在します。このポリシーは変更できず、以下の1つのステートメントのみが含まれています。

クリップボードにコピーされました
エラー: コピーできませんでした
ALLOW GROUP Administrators to manage all-resources IN TENANCY

あなたが「管理者」グループに属している場合、スーパーユーザー権限が付与されます。インスタンスの終了を防止するためのポリシー記述を追加することはできません。

インスタンスの「管理」権限を持つ他の管理者については、ポリシーステートメントの「where」句を使用することで、インスタンスの終了を防止できます。方法は2つあります。

オプション1

クリップボードにコピーされました
エラー: コピーできませんでした
Allow group to manage instance-family in compartment where request.permission != 'INSTANCE_DELETE'

オプション2

クリップボードにコピーされました
エラー: コピーできませんでした
Deny any-user to manage instance-family in tenancy
where request.permission = 'INSTANCE_DELETE'

このオプションでは、拒否ポリシーにより、誰もインスタンスを削除できません (INSTANCE_DELETE)。

詳細はドキュメントを参照してください。

Cloud Guard

Cloud Guardを有効にしてください。これは、当社独自のクラウドセキュリティ態勢管理（CSPM）プラットフォームであり、インスタンスがダウンまたは終了した際に通知を受け取ることができます。Cloud Guardを使用すると、これらのイベントに対応したり、発生時に管理者に通知したりできます。設定方法の詳細については、ドキュメントとブログ記事をご覧ください。

Cloud Guardのヒント – 検知担当者と対応担当者

Cloud Guardのチューニングに関するヒント

OCIイベント

ほぼリアルタイムのイベント通知を実現するには、インスタンスが終了する際に管理者に通知するルールを設定できます。終了イベントを作成する方法は、コンピューティングノードの構成方法や種類によって様々です。

詳細については、ドキュメントを参照してください。

高可用性（HA）

単一インスタンスによる単一障害点のリスクを回避しましょう。アクティブ/パッシブ構成にはロードバランサーを使用してください。OCIがコンピューティングノードの堅牢性を向上させる方法について解説した優れた記事はこちらです。

監査データのバックアップ

もう1つの対策として、最新の監査ログをオブジェクトストレージに保存する方法があります。過去90日間の監査ログを保存するための別のサービスコネクタを作成します。サービスコネクタは履歴データをストリームに送信できないため、上記でOCI CLIスクリプトを使用して特定の期間の監査ログを取得しました。

まとめ

インスタンスへの接続が失われるのは問題ですが、そのことを何週間も知らないままではさらに悪いです。今回のケースでは、OCIインスタンスにSIEMソフトウェアがデプロイされていました。SIEMプラットフォームはOCIストリームから監査データを取得していましたが、インスタンスが停止してしまいました。数週間停止していても、OCIロギングサービスにはアクセスでき、失われた監査ログを取得できます。私が提供したスクリプトは、特定の期間の失われた監査データをすべてダウンロードします。復旧後、SIEMはOCIオブジェクトストレージ/ディスクからデータを取得できるはずです。もし取得できない場合は、私が作成した2番目のスクリプトを使用して、監査ログをストリームにアップロードし、SIEMが取得できるようにしてください。

読んでいただきありがとうございます！

それでは、誰がVMを終了させたのか見てみましょう……つづく？

コメント

コメントを投稿

このブログの人気の投稿

Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20)

イメージ
Oracle Database 19cサポート・タイムラインの重要な更新 (2024/11/20) https://mikedietrichde.com/2024/11/20/important-update-to-oracle-database-19c-support-timelines/ 長い沈黙は、私が隠れているという意味ではありません。つまり、今はとても忙しいということです。そして、より少ない旅行で、私はあなたのコメントにもブログと返信するより多くの時間を持っていることを願っています。それでも、Oracle Database 19cサポート・タイムラインの非常に重要な更新について説明します。 * 更新された内容 2024年11月19日現在、Oracle Database 19cのサポート・タイムラインが調整されています。 MOSノート: 742060.1 – 現在のデータベース・リリースのリリース・スケジュールを見ると、新しい日付が表示されます。 Premier Support、2029年12月31日まで 2030年1月1日から2032年12月31日までの拡張サポート 2033年1月1日から2034年12月31日までのアップグレード・サポート これは知ることがとても大切です。 他のリリースの更新はありますか。 MOSノートの終わりにある変更ログ: 742060.1 – 現在のデータベース・リリースのリリース・スケジュールでは、Oracle Database 21cの最新の更新も確認できます。このリリースのPremier Support期間は、2027年7月31日まで延長されました。 また、Oracle Database 23aiのパッチ適用終了日は2032年12月31日に設定されています。 Lifetime Support Policy 更新は、Oracle Technology Productsの Oracle Lifetime Support Policy (6ページ)でも確認できます。 From: Oracle Lifetime Support Policy for Oracle Technology Product s – page 6 – Nov 19, 2024 特に、次の表に示す制限事項に注意してください。 Oracle Database 1...
続きを読む

ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13)

イメージ
ミリ秒の問題: BCCグループとOCIが市場データ・パフォーマンスを再定義する方法(AWSに対するベンチマークを使用) (2025/11/13) https://blogs.oracle.com/cloud-infrastructure/post/milliseconds-matter-bcc-group-and-oci-vs-aws 投稿者： Steven Riley | Senior Cloud Architect William Bierds | Business Analyst and Systems Engineer - BCC Group International Travis Liles | Master Principal Cloud Architect Puru Patel | Cloud Architect - FSI これは、BCC グループと Oracle Cloud Infrastructure (OCI) 間の市場データ パートナーシップを紹介するブログ シリーズの第 2 部です。   はじめに 金融市場データアプリケーションは、トレーダー、金融機関、そして市場参加者が情報に基づいた意思決定を行えるよう、リアルタイムデータを提供することで、取引エコシステムにおいて重要な役割を果たしています。 前回のブログ で述べたように、取引環境において最適なパフォーマンスを確保するには、市場データを超低レイテンシかつ高い信頼性で配信する必要があります。 今日の急速に変化する金融市場において、クラウドは市場データ・アプリケーションにとって強力な推進力として台頭しています。適切なネットワークとインフラストラクチャがあれば、企業は実行時間の短縮、可用性の向上、そして堅牢なセキュリティを実現できます。しかし、企業によるクラウド導入は遅れており、ワークロードのクラウド移行計画を中止しているケースもあります。そこで、BCCグループとOracle Cloud Infrastructure（OCI）のパートナーシップが注目されています。 BCCグループは、主力市場データアプリケーションであるONE PlatformをOCI上に導入しました。このブログでは、以下の点について説明します。 このパートナーシップがなぜこれほど相乗効果をもたらすのかを探る OC...
続きを読む

OCI Object Storageアクセス制御ポリシーの構成 (2024/04/25)

イメージ
OCI Object Storageアクセス制御ポリシーの構成 (2024/04/25) https://blogs.oracle.com/cloud-infrastructure/post/configuring-oci-object-storage-access-control-policies 投稿者： Ashutosh Mate | Sr. Principal Solutions Architect Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM)ポリシーは、OCI Object Storageサービスのデータを含むOCIリソースへのアクセスを制御するために使用される強力なツールです。OCI IAMポリシーは、常に直感的に構成できるわけではないため、このブログ投稿では、OCI IAMポリシーを使用してOCI Object Storageのバケットおよびオブジェクトへのアクセスを制御する方法について説明します。正確なポリシーを設定するのに役立つサンプル・ポリシーとヒントを提供します。 OCI Object Storageを保護するためのポリシーの使用 に関する記事を読んで、基本的な知識を身に付けましょう。この投稿では、OCIオブジェクト・ストレージを保護するための特定のアクセス制御ポリシー設定について説明します。 概要 OCI IAMポリシーにより、OCIクラウド・リソースへの安全なアクセスが可能になります。OCI IAMポリシーでは、なんらかのアクションを実行できます。クラウド・リソースには暗黙的な拒否設定があります。つまり、ポリシーがリソースに適用されるまでは、デフォルトではアクションは許可されません。次の基本的なポリシー構文では、アクションが許可されます。 Allow <subject> to <verb> <resource-type> in <location> where <conditions> 図1: ポリシー形式 subject subjectは、動詞で説明されているアクションを実行できるユーザーを指定します。ポリシー・サブジェクトはグループである必要があります。セキュリティ・プリンシパルま...
続きを読む