監査ログ

監査ログは、Foundry で実行されたすべてのアクションを包括的に記録し、セキュリティチームが脅威の検出、インシデントの調査、コンプライアンスの確保、およびプラットフォーム全体での説明責任の維持を行えるようにします。監査ログは、プラットフォーム内でユーザーが実行したすべてのアクションの要点をまとめた記録と考えることができます。ログの詳細さと正確さは、多くの場合トレードオフの関係にあります。詳細すぎるログにはより多くの情報が含まれる可能性がありますが、その内容を理解し、判断することが難しくなります。

監査ログに記録される情報

Foundry の監査ログには、セキュリティ調査やコンプライアンスレビューで重要となる次の質問に答えるために十分な情報が含まれています。

• 誰がアクションを実行したか（ユーザーの属性、セッション、またはサービスアカウント）。
• 何を行ったか（種類と意図によって分類されたアクション）。
• いつアクションが発生したか（時系列分析のための正確なタイムスタンプ）。
• どこでアクションが発生したか（関係するリソースとシステム）。

監査ログには、氏名やメールアドレスなどの個人を特定できる情報（PII）を含むユーザーのコンテキスト情報や、機密性が高い可能性のあるその他の利用データが含まれることがあります。そのため、監査ログの内容は機密情報として扱い、必要なセキュリティ資格を持つ人だけが閲覧する必要があります。

監査ログの保持は、プライバシーに関するベストプラクティスです。説明責任を果たせるワークフローには、誰がアクションを実行し、何を行い、いつ発生したかを追跡できる記録が必要だからです。監査データ自体にも機密性がある可能性があるため、目的に基づく最小権限のアクセスを適用し、監視ワークフローを設計する際はプライバシーと市民的自由の実践を確認してください。

顧客が所有する、セキュリティ監視専用の別システム（「セキュリティ情報およびイベント管理」、すなわち SIEM ソリューション）が利用可能な場合、監査ログ（および関連する詳細情報）は通常、そのシステムで取り込み、分析する必要があります。そのようなシステムが用意されていない場合でも、Foundry 自体には十分な柔軟性があり、通常は SIEM で行う軽量なワークフローの一部を、代わりにプラットフォーム内で直接実行できます。

このドキュメントでは、Foundry の監査ログにアクセスし、取り込み、分析する方法を説明します。

• 監査ログの配信：ログを SIEM に取り込む方法、または分析のために Foundry にエクスポートする方法。
• 監査スキーマ：項目の定義や保証事項を含む、監査ログの構造と内容。
• audit.2 から audit.3 に移行する：既存の audit.2 の分析を新しい audit.3 スキーマに移行するためのガイダンス。

ほかにも、次のドキュメントを利用できます。

• カテゴリーに基づくクエリパターンについての監査ログのカテゴリーのドキュメント。
• 分析のベストプラクティスを含む、セキュリティ監査ログの監視に関するドキュメント。
• SIEM 統合のための list-log-files および get-log-file-content の監査 API ドキュメント。

監査ログの配信

Foundry は、多様なセキュリティインフラストラクチャと SIEM の要件に対応するため、監査ログを配信する柔軟な仕組みを提供しています。選択する配信方法は、組織の既存のセキュリティツールと分析ワークフローによって異なります。

配信方法を比較する

Audit.3 ログ（すべての新規実装で推奨）：

Audit.3 スキーマのログは、セキュリティ運用において大きな利点があります。

• 低遅延： イベントの発生から約15分以内に利用可能になり、タイムリーな脅威検知ができます。
• API による直接アクセス： Foundry を経由せずに、公開 API を通じて外部 SIEM に直接取り込めます。
• 構造化されたカテゴリー： 標準化されたカテゴリーの使用が必須のため、構造が予測可能で、自動分析に適しています。
• 将来の変更への対応： Foundry の新しい機能は既存のカテゴリーを自動的に使用するため、監視クエリを更新する必要がありません。

Audit.3 ログは、API を通じて SIEM に取り込んで利用できます。また、必要に応じて監査ログを Foundry データセットにエクスポートして利用することもできます。

Audit.2 ログ（レガシー、過去の分析専用）：

過去の audit.2 スキーマのログは、約24時間以内に集約、圧縮され、環境ごとに異なるログアーカイブストレージ（たとえば S3 バケット）に移動されます。これらのログには、次の制約があります。

• 分析する前に Foundry データセットにエクスポートする必要があります。
• 外部 SIEM への API による直接取り込みをサポートしていません。
• カテゴリーの使用が任意で、構造が一貫していません。
• audit.3 への移行前の期間を分析する場合にのみ使用することが推奨されます。

Foundry は、アーカイブストレージから監査ログを Foundry にエクスポートすることで、audit.2 ログを顧客に配信できます。

監査ログを SIEM に直接取り込む

外部 SIEM は、Palantir の監査 API エンドポイントである list-log-files と get-log-file-content を使用して、ストレージから audit.3 ログを直接取り込めます。これらのエンドポイントを使用するために、監査ログのエクスポート用データセットを作成する必要はありません。この方法には次の利点があるため、専任のセキュリティオペレーションセンターと確立された SIEM プラットフォームを持つ組織に推奨されます。

• 遅延の最小化： 15分以内に SIEM でログを利用でき、迅速な脅威検知と対応ができます。
• ネイティブな統合： ログが既存のセキュリティツールとアラートワークフローに直接流れます。
• 仲介不要： 最初に Foundry を経由してログを転送する必要がなくなるため、アーキテクチャが簡素化されます。また、Foundry 自体にエクスポートして分析しない場合は、監査ログのストレージやコンピューティングにかかる可能性のあるコストも削減できます。
• 標準プロトコル： 主要な SIEM プラットフォームのほとんどと統合できる、使い慣れた API パターンを使用します。

SIEM への取り込みは、過去の audit.2 ログに対する audit.3 ログの利点です。audit.2 ログには、外部 SIEM が直接取り込める公開 API がありません（audit.2 ログは、まず Foundry データセットにエクスポートし、そこから SIEM にエクスポートする必要があります）。

SIEM への取り込みのためのページネーションとポーリング

list-log-files エンドポイントは、トークンベースのページネーションを使用します。nextPageToken フィールドは、新しいログファイルが利用可能でないことを示す、data フィールドが空または省略されている場合でも、レスポンスに必ず含まれます。

新しい監査ログを継続的にポーリングするには、次の手順に従います。

1. startDate と任意の endDate を指定して、最初のリクエストを送信します。
2. レスポンスの nextPageToken を保存します。
3. 以降のリクエストでは、保存した nextPageToken を指定して、前回の続きから再開します。前回のリクエスト以降に生成された新しいログファイルが返されます。
4. data フィールドが空の場合、新しいログはまだありませんが、nextPageToken は引き続き有効なため、次のポーリングサイクルのために保存してください。

この設計により、SIEM との統合では、ログの取りこぼしや重複受信なく、任意の間隔でポーリングできます。endDate パラメーターを省略すると、エンドポイントは常に利用可能な最新のログを返すため、終了日を定めない継続的なポーリングに適しています。

API アクセスの認証

監査 API エンドポイントにアクセスするには、SIEM のリクエストを認証する必要があります。一般的な推奨順に、次の方法を推奨します。ただし、最適な選択肢は、求めるセキュリティモデルによって異なります。

各 API リクエストに Authorization: Bearer <access_token> を含めてください。

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

Developer Console を使用したサードパーティアプリケーション（推奨）：

最も安全で保守しやすい方法は、Developer Console アプリケーションで、適切な監査ログの権限を持つサードパーティアプリケーションを作成することです。Developer Console では、オントロジー SDK と OAuth を使用して公開 API と通信するアプリケーションを作成および管理できます。

この方法には、次の利点があります。

• 監査ログへのアクセスに限定された権限。
• OAuth2 クライアント資格情報フローによるセキュリティの向上。
• 資格情報のローテーションと管理の容易化。
• どのアプリケーションがログにアクセスしているかを示す明確な監査証跡。

セットアップ手順については、Developer Console のドキュメントとサードパーティアプリケーションのドキュメントを参照してください。

アプリケーションのクライアントIDとクライアントシークレットをクライアント資格情報グラントで使用して、api:audit-read スコープを持つアクセストークンを要求します。

OAuth2 クライアント資格情報：

Developer Console アプリケーションを使用できない場合、OAuth2 クライアント資格情報は、SIEM への自動取り込みに適した安全なプログラムによる認証方法です。

ユーザートークン（非推奨）：

管理者ユーザーのトークンには次の制約があるため、本番環境の SIEM との統合では使用を避けてください。

• 個人のユーザーアカウントに紐づいているため、運用上の依存関係が生じます。
• 必要以上に広い権限を持つ可能性があります。
• サービスを中断せずにローテーションすることが困難です。
• 自動化システムで使用すると、監査証跡が不明確になります。

Foundry への監査ログのエクスポート

audit.2 と audit.3 のログはどちらも、Control Panel の監査ログツールを使用して、組織ごとに Foundry データセットへ直接エクスポートできます。この方法は、現在 SIEM ツールを導入していないものの、監査ログを分析する必要がある組織に適しています。

監査ログデータが Foundry データセットに取り込まれると、Foundry で直接分析できます。Pipeline Builder はプロトタイプの作成や基本的な簡易分析に使用でき、Code Repositories は膨大なデータ規模に対応する長期的な分析に使用できます。監査ログデータセットは、事前に絞り込まないと Contour で効果的に分析できないほど大きい場合があります。Data Connection を使用して、Foundry から外部の SIEM にエクスポートすることもできます（監査ログ分析の最終的な宛先が SIEM の場合、audit.3 ログは公開 API を通じて直接取得する必要があります）。

エクスポート権限

監査ログをエクスポートするには、対象組織に対する audit-export:orchestrate-v3 操作権限（audit.3 用）が必要です。この権限は、Control Panel の組織権限タブで設定できる組織管理者ロールで付与できます。詳細については、組織の権限に関するドキュメントを参照してください。

エクスポートのセットアップ

Foundry データセットへの監査ログのエクスポートを設定するには、次の手順に従います。

1. Control Panel に移動します。
2. 上部のツールバーで、ドロップダウンメニューから該当する組織が選択されていることを確認します。
3. 左側のサイドバーで検索を選択し、監査ログを検索して選択します。
4. エクスポートデータセットを作成を選択します。
5. ログの種類を選択します。現在の監査ログの新しいスキーマを使用するには audit.3 を選択し、audit.3 スキーマへのアップグレード前の過去の監査ログを分析する必要がある場合は audit.2 を選択します。audit.2 から audit.3 に移行する際は、重要な制限事項を確認してください。
6. この監査ログデータセットを Foundry に保存するためのエクスポート先と名前を選択します。
7. マーキング を使用して、機密性の高い監査ログデータセットへのアクセスを制限し、PII や検索クエリなど、機密性を持つ可能性のある利用状況の詳細を閲覧できる、知る必要のある適格なプラットフォーム管理者を指定します。デフォルトでは、監査ログデータセットには上で選択した組織のマーキングがつきます。詳細については、組織のマーキングに関するドキュメントを参照してください。
8. 必要に応じて、開始日フィルターを有効にし、このデータセットを指定した日付以降に発生したイベントに限定します。
9. 必要に応じて、データセット固有の保持ポリシーを有効にし、このエクスポートデータセットでログを保持する日数を制限します（最大730日）。保持ポリシーは、ログエントリ自体のタイムスタンプではなく、ログがエクスポートデータセットに追加されたときのトランザクションのタイムスタンプに基づきます。該当するトランザクションの削除には、削除対象として指定されてから最大7日かかる場合があります。実際の動作を示す2つの例を以下に示します。
   • 例1：
     • 開始日: 2025-01-01
     • 保持ポリシー：90日
     • この場合、エクスポートデータセットには、最初は2025年1月1日以降のログが含まれます。データセットの作成から90日後に保持ポリシーが適用され、当初データセットに含まれていた2025年1月初め以降のすべてのログではなく、過去90日間に追加されたログのみが保持されます。実際には、90日後に古いログが削除されるため、データセットのサイズが大幅に減少します。
   • 例2：
     • 開始日：30日前
     • 保持ポリシー：90日
     • この場合、エクスポートデータセットには、最初は過去30日間のログが含まれます。新しいログが追加されるにつれてデータセットは増加し、直近90日間のデータを保持するローリングウィンドウになります。90日より前のトランザクションで追加されたログは、保持ポリシーに従って削除されます。
10. データセット作成に伴うセキュリティ上の影響と、監査ログのエクスポートデータセットに適用する設定を理解したことを了承し、エクスポートを作成を選択します。

エクスポートデータセットを更新または無効化する

エクスポートデータセットの更新：

• 大規模な環境では、audit.2 データセットのビルドで、最初の数時間（またはそれ以上）に空の APPEND トランザクションが生成される場合があります。これは、パイプラインが蓄積された監査ログをすべて処理する間に生じる、想定どおりの動作です。audit.3 データセットの新しいエクスポートでは、この遅延は発生しません。
• 新しいログは、一定の間隔でエクスポートデータセットに追加されます。1回の追加で取得されるログデータは、audit.3 データセットでは最大100 GiB（かつ10,000ファイル）、audit.2 データセットでは最大10 GiB です。このような大規模な追加が必要になるのは、通常、監査ログデータセットを初めて作成するときだけです。
• 監査ログを追加する処理の実行時間は、監査ログデータセットに追加される新しいログの数に正比例します。
• エクスポートデータセットのビルドを制御するスケジュールは、audit-export サービスによって管理され、ユーザーには表示されません。
• Audit.3 エクスポートデータセットでは、スキーマ内の date 列を Hive パーティション列として使用します。つまり、date 列は通常のデータ列ではなくパーティションキーとして機能するため、クエリ時のデータの表示に影響します。たとえば、date の値は日時型ではなく日付型として書式設定されます。Hive パーティション分割の主要な利点は、アドホック分析で、タイムスタンプではなく date で最初に絞り込むと、Spark や通常のビルドでの参照が大幅に高速化されることです。

エクスポートデータセットの無効化：

Control Panel の監査ログアプリケーションから、監査ログのエクスポートデータセットを無効化できます。

• 該当する組織を選択し、監査ログページを開きます。
• エクスポートデータセットを見つけ、そのオプションメニューを開き、エクスポートを一時停止を選択してエクスポートを無効化します。
• 同じメニューからエクスポートを再開を選択すると、無効化したエクスポートデータセットをいつでも再開できます。

監査スキーマ

Palantir 製品が生成するログはすべて構造化ログです。つまり、特定のスキーマに従っており、下流システムはそのスキーマを前提として自動分析やアラートを行えます。

Palantir の監査ログは現在、従来の audit.2 スキーマと、改良された新しいスキーマである audit.3 の両方で配信されています。新しいイベントの Audit.2 ログは、まもなくエクスポートできなくなり、このスキーマで利用可能なのは過去のログのみになります。すべての新しいイベントは、audit.3 スキーマでのみエクスポートできるようになります。

audit.2 と audit.3 のどちらのスキーマでも、監査ログはログを生成する製品によって異なります。これは、各製品が異なる領域について推論を行い、そのため記述する必要がある事柄も異なるためです。この違いは、以下で説明するように、audit.2 でより顕著です。

製品固有の情報は、主に audit.3 ログの requestFields と resultFields（または audit.2 ログの request_params と result_params）に記録されます。これらのフィールドの内容は、ログを記録する製品と記録されるイベントの両方に応じて形式が変わります。

監査ログのカテゴリー

Palantir のログでは、製品固有の知識が少なくてもログを理解しやすくするために、監査ログのカテゴリーという概念を使用しています。カテゴリーを使用すると、セキュリティアナリストはサービス固有の何百ものイベント名を追跡する必要がなくなり、どの製品や機能がログを生成したかにかかわらず、データの読み込み、権限の変更、認証の試行といった高レベルのアクションに注目できます。この抽象化により、アナリストは実装の詳細を理解しなくても、すべての Foundry サービスで機能する監視クエリを作成できます。たとえば、dataExport で絞り込むと、データのエクスポートに使用された製品にかかわらず、すべてのデータエクスポートイベントを取得できます。

監査ログのカテゴリーでは、監査ログを監査可能なイベントの和集合として記述します。監査ログのカテゴリーは、核となる概念に基づいており、次のように、それらの概念に対するアクションを記述するカテゴリーに分類されています。

監査ログのカテゴリーにもバージョンの変更があり、audit.2 ログでの制約の緩い形式から、audit.3 ログでのより厳密で豊富な形式へと変わりました。audit.3 では、各ログにカテゴリーを1つ以上指定する必要があり、各カテゴリーで、どのリクエストフィールドと結果フィールドが存在するかが厳密に定義されているため、自動分析の信頼性が大幅に向上しています。

利用可能なカテゴリーとフィールド仕様の詳細な一覧については、監査ログのカテゴリーのドキュメントを参照してください。また、カテゴリーの使用に関する追加のガイダンスについては、セキュリティ監査ログの監視のドキュメントを参照してください。

監査ログの帰属

監査ログは、環境ごとに1つのログアーカイブに書き込まれます。監査ログが配信パイプラインで処理される際に、ユーザーIDのフィールド（以下のスキーマの uid と otherUids）が抽出され、ユーザーが対応する組織にマッピングされます。

特定の組織向けに実行される監査エクスポートは、その組織に帰属する監査ログに限定されます。サービスユーザー（人間ではないユーザー）のみによって実行されたアクションは、通常、どの組織にも帰属しません。これらのユーザーは組織のメンバーではないためです。例外として、クライアント資格情報グラントを使用し、登録した組織のみが使用するサードパーティアプリケーションのサービスユーザーは、その組織に帰属する監査ログを生成します。

Audit.3 ログ

新しいログのエクスポートや分析では、audit.2 ログではなく audit.3 ログを使用してください。

Audit.3 ログは、audit.2 ログと比べて多くの利点を持つ新しいログスキーマに基づいています。新しいスキーマと関連する配信パイプラインが監査ログの利用者にもたらす主な利点は、次のとおりです。

• より迅速な配信： 遅延が、24時間を超える可能性があった従来の状態から15分以下に短縮され、ほぼリアルタイムでの脅威検出が可能になります。
• 構造化されたカテゴリー： 文書化されたカテゴリーが強制されるため、分析に使用できる予測可能な構造が提供されます。これにより、ログの内容について推論する際に、個々の製品を理解する必要性が低減されます。特に、分析の対象がワークフロー全体に及ぶ場合（たとえば dataExport）に役立ちます。
• トップレベルフィールドの強化： product などの新しいフィールドにより、製品名による絞り込みが容易になります。1つの製品の使用状況に分析対象を絞るために、イベント名をマッピングする複雑なフィルターを用意する必要はありません。
• API への直接アクセス： Foundry を仲介させることなく、監査ログを外部の SIEM に取り込むための公開 API が利用可能になりました。
• コンテキストの充実： 配信時に抽出されたユーザー、リソース、および関係に関する追加のコンテキスト情報を利用できるため、下流の分析が容易になります。

スキーマの保証

Audit.3 ログは、次の保証を念頭に置いて生成されます。

1. 明示的なカテゴリー定義： 各監査カテゴリーは、適用対象となる値や項目を明示的に定義します。たとえば、dataLoad は読み込まれるリソースを正確に記述します。
2. カテゴリーの和集合： 各ログは、厳密に監査カテゴリーの和集合として生成されます。つまり、ログには自由形式のデータが含まれず、予測可能な構造が保証されます。
3. 重要情報の昇格： 監査ログ内の特定の重要情報は、audit.3 スキーマのトップレベルに昇格されます。たとえば、名前付きリソースはすべて、リクエストおよび結果のフィールド内だけでなく、トップレベルにも存在します。

これらの保証により、どのログについても、（1）そのログを作成した監査対象イベント、および（2）含まれるフィールドを正確に把握できます。これらの保証は製品に依存しないため、セキュリティアナリストは、すべての Foundry サービスで機能する監視クエリを作成できます。

Audit.3 スキーマリファレンス

audit.3 ログスキーマを以下に示します。

特定のアプリケーションを分析する際には、通常、監査ログの絞り込みに不変の product スキーマフィールドを使用することを推奨します。service フィールドは、同じ製品の異なるインスタンスを区別して絞り込めるため、利用者にとって役立つ場合があります。特定のインシデントをより詳細に理解するうえでも役立つ可能性があります。

Audit.2 ログ

audit.2 ログは、新しい audit.3 ログの記録開始前の期間を分析する場合にのみ使用してください。audit.2 スキーマで新しいイベントをログとしてアーカイブする機能は、まもなく非推奨になるため、audit.2 から audit.3 に移行する際は、重要な制限事項を参照してください。Audit.2 ログでは、リクエストパラメーターや結果パラメーターの形式について、製品間での保証はありません。そのため、監査ログについての推論は、通常、製品ごとに行う必要があります。

Audit.2 ログには、検索の絞り込みに役立つ監査カテゴリーが含まれる場合があります。ただし、このカテゴリーには追加情報は含まれず、監査ログのほかの内容を規定するものでもありません。また、audit.2 ログに監査カテゴリーが含まれることは保証されません。カテゴリーが含まれる場合は、request_params 内の _category または _categories フィールドに格納されます。

audit.2 ログのエクスポートデータセットのスキーマを以下に示します。

audit.2 から audit.3 に移行する

現在、セキュリティ監視やコンプライアンスのために audit.2 ログを使用している組織は、分析を audit.3 スキーマに移行する必要があります。このセクションでは、監査ログのワークフローを移行し、audit.3 の改善点を活用するためのガイダンスを提供します。

audit.2 と audit.3 の違い

audit.3 スキーマは、audit.2 からの単なるバージョン更新ではなく、アーキテクチャの根本的な変更です。移行に影響する主な違いについて、以下のセクションで説明します。

フィールド名と構造の変更

• audit.2 の request_params と result_params は、audit.3 では requestFields と resultFields という名前になっています。
• requestFields と resultFields の内容は、通常、audit.2 の対応するフィールド（request_params と result_params）とは完全に異なります。
• audit.2 の request_params にあった情報が、audit.3 では resultFields に含まれている場合があり、その逆もあります。
• audit.3 で特定の情報を探すときは、必ず requestFields と resultFields の両方を確認してください。
• 最上位の type フィールドは、ログを生成したスキーマが "audit.2" と "audit.3" のどちらであるかを示します。

イベント名の変更

• イベント名（name フィールド内）はスキーマ間で異なる場合があり、パース処理が特定のイベント名に依存している場合、不一致が発生する可能性があります。
• audit.3 のイベント名は、より標準化されており、通常は（製品名）_（エンドポイント名）の構造で、すべて大文字のスネークケースになっています。例：DATA_PROXY_SERVICE_GENERATED_GET_DATASET_AS_CSV2。
• すべての audit.2 イベント名から audit.3 イベント名への直接的な1対1の対応付けがあるわけではありませんが、ほとんどの audit.2 ログイベント名は audit.3 に容易に対応付けることができます。
• 推奨される方法： 今後のクエリでは、特定のイベント名ではなく監査カテゴリーを使用します。カテゴリーは両方のスキーマで一貫した抽象化を提供します（ただし、audit.2 でのカテゴリーの使用は任意です）。

新しい機能

• audit.3 には最上位の categories フィールドがあり、標準化された値の使用が強制されます。
• audit.3 では、product、service、entities、users などの新しいフィールドを利用でき、絞り込みが容易になります。
• audit.3 では users フィールドを利用でき、ログエントリーに関連するすべてのユーザーのユーザーIDが含まれます。追加のユーザープロフィールフィールド（userName、firstName、lastName、groups、realm）はスキーマで定義されていますが、現在は値が設定されていません。必要に応じて、下流でこれらの情報を補完してください。

重要な制限事項

• 過去のデータのバックフィルなし：Audit.3 は、有効化された後に発生したイベントのみを記録します。過去のイベントは、引き続き audit.2 ログスキーマにのみ存在します。

• 同時ログ記録期間： 移行期間中は両方のスキーマでログが発行されるため、完全に切り替える前に検証できます。

移行手順

audit.2 ログに基づく既存の分析がある場合、移行方法は、現在どこで分析を実行しているかによって異なります。分析方法に該当する以下のセクションの手順に沿って進めてください。

外部 SIEM を使用している場合

Foundry のエクスポートデータセットを引き続き使用するのではなく、API から直接取り込む方法に移行することを強く推奨します。この方法には、次の利点があります。

• 大幅な遅延の削減：audit.2 では24時間以上かかるのに対し、約15分以下になります。
• よりシンプルなアーキテクチャ： Foundry を仲介として使用しなくなるため、遅延や障害が発生する箇所を減らせます。
• ネイティブの SIEM 統合： 完全なログが、既存のセキュリティツールに直接送られます。

移行手順：

1. list-log-files および get-log-file-content 監査 API エンドポイントから取り込むように SIEM を設定します。
2. 新しい audit.3 スキーマ構造に対応するようにパースルールを更新します（以下のセクションを参照）。
3. 可能な場合は、イベント名ではなくカテゴリーを使用するように検出ルールを更新します。
4. 検証期間中は、既存の audit.2 の取り込みと並列で実行します。
5. アラートと検出のワークフローを十分にテストします。
6. 検証が完了したら、audit.2 の Foundry エクスポートと SIEM への取り込みを非推奨にします。

Foundry でログを分析している場合

1. エクスポートのセットアップ手順に従って、Control Panel で新しい audit.3 エクスポートデータセットを作成します。
2. 移行期間中は、既存の audit.2 エクスポートデータセットの稼働を維持します。
3. PR をまとめて移行を実行するために、新しい Global Branch を作成します（必要に応じて、複数のコードリポジトリの PR をまとめます）。
4. Data Lineage アプリケーションを使用して、Foundry での audit.2 データの下流での利用状況を表示し、どの分析が非推奨になり、どの分析を移行する必要があるかを把握します。
5. 以下のリファクタリング手順に従って、分析を更新します。

カテゴリーに基づく分析パターンを特定する

イベント名ごとに分析を移行するのではなく、個々の製品のイベント名の代わりに、標準化された監査カテゴリーを使用するように分析をリファクタリングします。

従来の方法（audit.2）：

Copied!
1
2
3
4
# 変更に弱い：変更される可能性がある特定のイベント名に依存します
export_events = audit_logs.filter(
    col("name").isin(["EXPORT_DATASET", "DOWNLOAD_FILE", "CREATE_EXTERNAL_CONNECTION"])
)

新しい方法（audit.3）：

Copied!
1
2
3
4
# 変更に強い：  標準化されたカテゴリーを使用します
export_events = audit_logs.filter(
    col("categories").contains("dataExport")
)

このカテゴリーに基づく方法には、次の利点があります。

• 将来の変更への対応： 新しくリリースされるエクスポート機能は、dataExport カテゴリーを使用します。
• 網羅性： すべてのイベント名を列挙する必要なく、すべてのエクスポートの仕組みを網羅できます。
• 製品横断： すべての Foundry サービスで一貫して機能します。

移行期間中に検証する

同時ログ記録期間中に、次の作業を行います。

• audit.2 と audit.3 の両方のデータソースで分析を並列で実行します。
• 出力を比較し、audit.3 の分析で期待されるイベントが記録されていることを確認します。
• カテゴリーに基づくフィルターが、イベント名フィルターと同等以上の範囲を網羅していることを確認します。
• SIEM ユーザー向け：audit.3 データに対してアラートが正しく発動することを検証します。

切り替えを完了する

audit.3 の分析が同等以上の範囲を網羅していることを検証したら、次の作業を行います。

• 下流のすべての利用元を、audit.3 API またはデータセットを使用するように切り替えます。
• Foundry エクスポートを使用している場合は、Control Panel の監査ログアプリケーションで audit.2 エクスポートデータセットを無効にします。手順については、エクスポートデータセットの無効化を参照してください。
• 外部 SIEM を使用している場合は、SIEM から audit.2 の取り込みを削除します。
• 新しい audit.2 ログの生成を停止した後も、過去の audit.2 ログには引き続きアクセスできます。過去にさかのぼる分析や調査では、audit.2（過去）と audit.3（現在）の両方のログを個別にクエリする必要があります。詳細については、重要な制限事項を参照してください。

移行時によくある課題

課題：対応するイベント名がない

audit.2 の一部のイベント名には、audit.3 に直接対応するものがない場合があります。これは通常、次の場合に発生します。

• イベントが非推奨になったか、新しいエンドポイントに置き換えられた場合。
• イベントから得られる有用な情報が少なく、意図的に audit.3 に移行されなかった場合。

解決策

1. 現在の audit.2 ログで、そのイベントが引き続き発行されていることを確認します。
2. 発行されている場合は、audit.2 ログの traceId フィールドを使用して、audit.3 データセット内で関連する可能性のある監査ログを探します。
3. 対応するイベントが見つからない場合は、Palantir サポートチームにお問い合わせください。

課題：ネストされたリクエスト／結果フィールドの展開

requestFields と resultFields の構造は複雑で製品固有の場合があり、audit.2 と audit.3 で異なります。

解決策

• 分析で audit.2 の request_params または result_params を展開しており、その粒度の詳細が分析に重要な場合は、audit.3 の新しいフィールド構造に合わせてこのロジックをリファクタリングする必要があります。audit.2 と比べて情報がリクエストフィールドと結果フィールドの間で移動している可能性があるため、audit.3 では必ず requestFields と resultFields の両方を確認してください。
• 監査カテゴリーのドキュメントを使用して、各カテゴリーで保証されるフィールドを確認します。
• 可能な場合は、リクエスト／結果フィールドをパースするよりも、トップレベルのフィールド（entities、users、categories など）を優先して使用します。
• フィールドがない場合や想定外のフィールドがある場合にも適切に対応できる、堅牢なパースロジックを作成します。

課題：切り替え日をまたぐ連続性

過去の audit.2 データと現在の audit.3 データの両方にまたがる期間を分析する必要があります。詳細については、重要な制限事項を参照してください。

解決策

• SIEM での分析：移行中は並列で取り込みを維持し、その後は SIEM の履歴データ保持機能を利用して audit.2 ログを参照します。
• Foundry での分析：audit.2 データセットと audit.3 データセットの和集合を取る統合ビューを作成します。
• 必要に応じて、type フィールドを使用してスキーマ固有のパースロジックを適用します（たとえば、audit.3 では絞り込みにカテゴリーを使用し、audit.2 では name/result_params を使用します）。
• スキーマの違いにより、一部のメトリクスでは完全な連続性を確保できない場合があります。

追加リソース

• カテゴリーに基づくクエリパターンについては、監査ログのカテゴリーのドキュメントを確認してください。
• 分析のベストプラクティスについては、セキュリティ監査ログを監視するドキュメントを確認してください。
• SIEM 統合の詳細については、list-log-files および get-log-file-content の監査 API ドキュメントを参照してください。
• 製品固有の移行に関する質問がある場合は、Palantir サポートチームにお問い合わせください。