監査ログのカテゴリー

監査ログのカテゴリーを使用すると、Foundry のすべてのサービスで発生しうるイベント名を列挙する必要なく、何が起きたかに基づいて関心のあるイベントを特定できるため、セキュリティ監視が簡単になります。サービス固有のイベント名を何百も追跡する代わりに、カテゴリーを使えば、ログを生成した製品や機能に関係なく、データの読み込み、データのエクスポート、認証試行といった大まかなアクションに注目できます。

カテゴリーが重要な理由

従来の監査ログシステムでは、セキュリティアナリストが効果的なクエリを作成するには、すべてのサービスの実装の詳細を理解する必要があります。たとえば、データ流出の可能性を調査する際には、関連するイベント名が EXPORT_DATASET、DOWNLOAD_FILE、CREATE_EXTERNAL_CONNECTION、その他数十種類であることを把握し、新しい機能が追加されるたびにこの一覧を維持する必要があるかもしれません。

監査ログのカテゴリーは、抽象化によってこの問題を解決します。audit.3 スキーマでは、すべてのイベントを、一貫したリクエストパラメーターと結果パラメーターを備えた1つ以上の標準化されたカテゴリーで記録する必要があります。これにより、次のことが可能になります。

• サービスに依存しないクエリ： dataExport で絞り込むと、エクスポートを実行した Foundry 製品に関係なく、すべてのデータエクスポートイベントを検索できます。
• 将来の変更にも対応できる監視： 新しいエクスポート機能も dataExport カテゴリーでログに記録されるため、クエリを更新する必要はありません。
• 調査の迅速化： システム内部の理解に費やす時間を減らし、ユーザーの行動分析により多くの時間を割けます。
• 予測可能な構造： 各カテゴリーでは、どのリクエストフィールドと結果フィールドが含まれるかを明確に定義しているため、自動分析の信頼性が高まります。

audit.2 と audit.3 のスキーマの比較

audit.2 のログにはカテゴリー情報が含まれる場合がありますが、その使用は任意であり、強制されません。そのため、カテゴリー情報がまったく含まれない場合や、関連するリクエストパラメーターと結果パラメーターの構造が一貫していない場合があります。

一方、audit.3 スキーマではカテゴリーの使用が必須であり、次のことが保証されます。

• すべての監査ログで、カテゴリーを1つ以上指定する必要があります。
• すべてのカテゴリーで、含まれるリクエストフィールドと結果フィールドが明示的に定義されています。
• 標準パラメーターにより、サービス固有の知識がなくても分析できます。

フィールド名： パラメーター情報には、audit.3 では requestFields と resultFields を使用し、audit.2 では request_params と result_params を使用します。

スキーマの相違点と移行ガイダンスの詳細については、監査ログの概要のドキュメントを参照してください。

ワークフローの例

カテゴリーを使用した一般的なセキュリティ監視のワークフローは、次のようになります。

1. 関心のあるカテゴリーを特定する

セキュリティ要件に基づいて、関連するカテゴリーを特定します。たとえば、次のカテゴリーがあります。

• データアクセスの可能性の調査：dataLoad
• エクスポートの監視：dataExport
• ログインの確認：userLogin

2. カテゴリーでログをクエリする

外部の SIEM を使用するか、Foundry の監査ログエクスポートデータセットを Pipeline Builder で使用して、ログを絞り込みます。擬似コードでは、次のようになります。

allLogs.filter {log -> interestingCategories.any{log.categories.contains(it)}}

パフォーマンスに関する注記： 監査ログのデータセットには、非常に大量のデータが含まれる場合があります。クエリのパフォーマンスを確保するため、集計や可視化を行う前に、必ず time 列を使用して絞り込んでください。

3. 構造化されたパラメーターを分析する

一致するログごとに、requestFields と resultFields を確認します。これらには、ユーザーが送信した具体的な情報とシステムが返した具体的な情報が分けて格納されているため、次の違いを把握できます。

• リクエストフィールド（requestFields）：ユーザーが指定した内容（たとえば、要求したリソース）。
• 結果フィールド（resultFields）：システムが返した内容（たとえば、実際に読み込まれたリソース）。

たとえば、dataLoad カテゴリーのログには、そのインタラクション中に読み込まれたすべてのリソースの一覧が requestFields または resultFields に含まれるため、リクエストを処理した具体的な Foundry サービスを知らなくても、データアクセスのパターンをすぐに把握できます。

4. カテゴリーを照合する

多くのイベントでは、複数のカテゴリーを持つログが生成されます。インシデントの可能性を調査する際には、ユーザーのアクティビティに dataExport カテゴリーが含まれていないことを確認することで、そのユーザーが多くのデータセットを読み込んだ（dataLoad）一方で、実際のエクスポートは行われなかったことを確認できます。

利用可能なカテゴリー

利用可能な監査ログのカテゴリーは以下のとおりです。