セキュリティ監査

概要

監査ログは、監査人が Foundry ユーザーによって実行されたアクションを理解するための主要な方法です。

Foundry の監査ログには、以下の情報が含まれています。

• 誰が アクションを実行したか
• 何の アクションが行われたか
• いつ アクションが行われたか
• どこで アクションが行われたか

場合によっては、監査ログには、名前やメールアドレスなどの個人を特定する情報（PII）を含むユーザーに関する文脈情報が含まれることがあります。そのため、監査ログの内容は機密性が高く、必要なセキュリティ資格を持つ者だけが閲覧すべきです。

監査ログは、通常、顧客が所有するセキュリティ監視のための専用システム（「セキュリティ情報イベント管理」または SIEM ソリューション）に取り込まれます。

このガイドでは、監査ログの抽出と使用について、以下の 2 つのセクションで説明します。

• 監査の配信：下流の SIEM やユーザーが監査ログを消費する方法。
• 監査スキーマ：Foundry 監査ログの内容。

監査の配信

監査ログは、顧客のセキュリティインフラストラクチャと SIEM 要件に応じて、いくつかのメカニズムを介して下流の消費のために配信されます。Foundry サービスが生成した監査ログのバッチは、コンパイルされ、圧縮され、24 時間以内にログバケットに移動されます（環境によっては S3 が一般的ですが、環境によって異なります）。ここから、Foundry は Foundry への監査エクスポート で顧客に直接ログを配信して消費することができます。

Foundry への監査エクスポート

監査ログは、組織ごとに、直接 Foundry データセットにエクスポートすることができます。設定のセットアップの一環として、組織管理者は、この監査ログデータセットが生成される Foundry ファイルシステム内の場所を選択します。

ログデータがデータセットに着陸したら、顧客は Foundry の Data Connection アプリケーションを介して外部 SIEM に監査データをエクスポートすることを選択できます。

監査ログの Foundry へのエクスポートの設定については、Palantir の担当者にお問い合わせください。

エクスポートの権限

監査ログをエクスポートするには、対象の組織に audit-export:orchestrate-v2 操作が必要です。これは、コントロールパネルの 組織の権限 タブの下にある 組織管理者 の役割を介して付与することができます。詳細については、組織の権限 を参照してください。

エクスポートの設定

Foundry への監査エクスポートの設定方法は以下の通りです。

1. Foundry コントロールパネルに移動します。
2. 左側のサイドバーで、ドロップダウンメニューを使用して関連する組織を選択します。
3. 左側のサイドバーで、組織設定 の下の 監査ログ を選択します。
4. データセットの作成 を選択して監査ログデータセットを生成します。このデータセットの場所を Foundry で選択します。デフォルトでは、監査ログデータセットは上記で選択した組織でマークされます。組織のマーキング を参照してください。
5. 任意で、指定された日付以降に発生するイベントに対してデータセットを制限するために開始日フィルターを設定します。
6. 任意で、このエクスポートデータセット内でログが保持される期間を制限する保持ポリシーを設定します。保持ポリシーは、ログエントリ自体のタイムスタンプではなく、エクスポートデータセットにログが追加されたトランザクションのタイムスタンプに基づいています。関連するトランザクション を削除するのに最大 7 日かかる場合があります。これは、実際には、最初のデータセットにあった 1 年分のデータではなく、過去 90 日間に追加されたログのみが保持されるようになります。実際には、90 日後に古いログが削除されると、データセットのサイズが大幅に減少します。
   • 例二：
     • 開始日：30 日前
     • 保持ポリシー：90 日間
     • このシナリオでは、エクスポートデータセットは過去 30 日間のログから始まります。新しいログが追加されると、データセットは最新の 90 日間のデータを持つローリングウィンドウに成長します。90 日間より古いトランザクションで追加されたログは、保持ポリシーに従って削除されます。

データセットが作成された後、数時間かかってデータセットが入力されることがあります。これは、監査ログのバックログを処理するパイプラインが期待される動作です。

監査ログの更新

ビルド時に、監査ログデータセットは、新しいログが利用可能になると、特定の条件に従って追加します（変更の可能性あり）。

• 監査ログがログバケットで利用可能になると、通常は 24 時間以内に、2 時間ごとにインジェストが実行され、それらのログがエクスポートデータセットの上流にある非表示の中間データセットに着陸します。
• 新しいログは、中間データセットからエクスポートデータセットに 10 分ごとに追加されます。各追加は最大 10 GB のログデータをプルします。監査ログデータセットが初めて作成されるときにのみ、10GB のログデータの追加が必要です。
• 新しいログデータが利用できない場合、エクスポートデータセットのスケジュールが 1 時間停止し、その後再開されます。
• ほとんどの場合、監査ログデータセットが完全に最新の状態になると、ジョブは 1 時間ごとに継続して実行されます。通常、3 つのジョブのうち 1 つが監査ログデータセットに新しいデータを追加するために実行され、他のジョブは追加のコンテンツが書き込まれずに中止されます。
• 各監査ログの追加の実行時間は、監査ログデータセットに追加される新しいログの数に直接比例します。
• エクスポートデータセットのビルドを制御するスケジュールは audit-export によって制御され、ユーザーの表示から隠されています。

監査ログデータセットの移動

監査ログデータセットを初期プロジェクトから別のプロジェクトに移動するか、ゴミ箱に移動すると、ビルドが失敗します。エクスポートデータの権限を変更する必要がある場合は、新しい監査ログデータセットを作成してください。

監査ログデータセットの分析

監査ログデータセットには非常に大量のデータが含まれることがありますので、date 列を使用してこのデータセットを絞り込んでから、集計や可視化を実行することをお勧めします。この列でのフィルタリングは特にパフォーマンスが高く、特定の日付範囲にデータセットをすばやく絞り込むのに役立ちます。time 列でのフィルタリングには同じパフォーマンス最適化がないため、time の代わりに date を使用することをお勧めします。

日付以外のフィルタリングには、Pipeline Builder または Transforms を使用することをお勧めします。監査データセットは、まずフィルタリングせずに Contour で効果的に分析するには大きすぎる可能性があります。

監査スキーマ

Palantir 製品が生成するすべてのログは、構造化 ログです。これは、ダウンストリームシステムが依存できる特定のスキーマに従っていることを意味します。

Palantir の監査ログは、現在 audit.2 スキーマ で提供されており、一般的に "Audit V2" と呼ばれています。更新されたスキーマである audit.3 または "Audit V3" は開発中ですが、まだ一般に利用可能ではありません。

audit.2 および audit.3 スキーマの両方で、監査ログは生成するサービスによって異なる場合があります。これは、各サービスが異なるドメインについて推論しているため、それぞれ異なる懸念事項を記述する必要があるからです。このバリエーションは audit.2 でより顕著であることが説明されます。 サービス固有の情報は主に request_params と result_params フィールドに記録されます。これらのフィールドの内容は、ログを行うサービスとログされるイベントにより、その形状が変化します。

監査カテゴリー

監査ログは、プラットフォーム内でユーザーが行ったすべてのアクションの精緻な記録と考えることができます。これは多くの場合、詳細さと精度の間の妥協で、詳細すぎるログはより多くの情報を含むかもしれませんが、それについての推論がより難しくなるかもしれません。

Palantir のログには、少ないサービス固有の知識でログを理解しやすくするための 監査カテゴリー と呼ばれる概念が含まれています。

監査カテゴリーを使用すると、監査ログは監査可能なイベントの集合として説明されます。監査カテゴリーは、 data と metaData と logic などの一連のコアコンセプトに基づいており、それらのコンセプトに対するアクションを説明するカテゴリーに分けられます。例えば、 dataLoad （システムからのデータの読み込み）、 metaDataCreate （いくつかのデータを記述する新しいメタデータの作成）、 logicDelete （システム内のいくつかのロジックの削除、ここでのロジックは2つのデータの間の変換を記述します）。

監査カテゴリーも audit.2 ログ内の緩やかな形から audit.3 ログ内のより厳格で豊かな形へとバージョン変更を経ています。詳細は下記を参照してください。

利用可能な audit.2 と audit.3 のカテゴリーの詳細リストについては、監査ログカテゴリー を参照してください。

監査ログの帰属

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

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

監査ログの文脈化

audit.3 は、ログ配信の一部としてログの濃密化も提供します。つまり、監査配信パイプラインは、サービスによってキャプチャされ、ログバケットに保存された監査情報の上にメタデータ（通常はユーザーまたはリソースに関連する）を追加します。例えば、標準的な監査ログには特定のアクションを実行した uid が含まれています。文脈化されたログでは、ユーザーの名前やメールをログの内容に追加することがあります。ログラインの初期生成と配信パイプラインでの処理の間に経過した時間により、少量のズレが発生することがあります。

Audit.2 ログ

audit.2 ログには、リクエストとレスポンスパラメーターの形状についての サービス間の保証はありません 。したがって、監査ログについての推論は通常、サービスごとに行う必要があります。

audit.2 ログは、検索を絞り込むのに役立つ可能性のある 監査カテゴリー を提示する場合があります。ただし、このカテゴリーはさらなる情報を含まず、監査ログの残りの内容を規定しません。また、 audit.2 ログに監査カテゴリーが含まれていることは 保証されていません 。カテゴリーが存在する場合、それらは request_params 内の _category または _categories フィールドに含まれます。

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

Audit.3 ログ

audit.3 ログは、ログの内容について推論する際に特定のサービスを理解する必要性を減らすために、監査カテゴリーのより厳格な使用を確立します。 audit.3 ログは以下の保証を念頭に作成されます：

1. すべての監査カテゴリーは、それが適用する値/アイテムを明示的に定義します - 例えば、 dataLoad はロードされる正確な リソース を記述します。
2. カテゴリー内の各パラメーターは感度タグ付けされています。これにより、特定のタイプの機密データ（ユーザー入力など）をフィルター処理するか、それを他の場所に転送する前に削除することが可能になります。
3. すべてのログは、監査カテゴリーの合併として厳密に作成されます。これは、ログが自由形式のデータ、または感度がタグ付けされていないデータを含まないことを意味します。
4. 監査ログ内の特定の重要な情報は、 audit.3 スキーマのトップレベルに昇格します。例えば、すべての名前付きリソースとすべてのユーザーは、リクエストとレスポンスのパラメーター内だけでなく、トップレベルで完全に文脈化されたエンティティとして存在します。

これらの保証は、特定のログについて、（1）何の監査可能なイベントがそれを作成したか、および（2）それが正確に何のフィールドを含んでいるか、を語ることが可能です。これらの保証はサービスに依存しないものです。

以下に audit.3 スキーマを提供します。この情報は非包括的であり、変更の対象となります：