監査ログを監視する

効果的なセキュリティ監視には、包括的でタイムリーな監査ログが不可欠です。このガイドでは、Foundry の監査ログを取り込んで分析し、ユーザーのアクティビティを継続的に把握し、セキュリティインシデントを検出して、組織のポリシーへの準拠を確保する方法を説明します。

概要

監査ログには、Foundry で実行されるすべてのアクションに関する重要な情報が記録され、次の内容を把握できます。

• 誰がアクションを実行したか（ユーザーの属性、セッション、またはトークン）。
• 何を実行したか（種類と意図に基づいて分類）。
• いつアクションが実行されたか（正確なタイムスタンプ）。
• どこでアクションが実行されたか（関係するリソース）。

これらのログには、名前やメールアドレスなどの個人を特定できる情報（PII）を含むコンテキスト情報が含まれる場合があります。アクセスは、セキュリティに関する適切な資格を持つ担当者に制限する必要があります。

監査ログの配信

Foundry は、多様なセキュリティインフラストラクチャやセキュリティ情報およびイベント管理（SIEM）の要件に対応するため、柔軟な配信方法を提供します。

配信方法を選択する

外部 SIEM との統合の場合（audit.3 のみ、推奨）： 外部 SIEM は、Palantir の監査 API エンドポイントを使用して、audit.3 ログを直接継続的にポーリングできます。list-log-files エンドポイントは、日付範囲で絞り込んだ利用可能なログファイルを一覧表示し、get-log-file-content エンドポイントは、特定のログファイルの内容を取得します。この方法は、専任のセキュリティオペレーションセンターと確立された SIEM プラットフォームを持つ組織に推奨されます。低遅延であるため、タイムリーな検出と対応が可能です。

Foundry で分析する場合： 専用の SIEM ツールを持たない組織や、より簡易な分析で十分な組織では、audit.2 と audit.3 の両方のログを、組織ごとの Foundry データセットにエクスポートできます。組織管理者は、セットアップ時にエクスポート先のファイルシステムの場所を設定します。エクスポートされたログは、Foundry で直接分析するか、Foundry の Data Connection アプリケーションを通じて外部 SIEM に転送できます。

API エンドポイントの詳細情報とエクスポートのセットアップ手順については、監査ログの配信のドキュメントを参照してください。

データの完全性

監査ログの生成から保存までの経路を構成するインフラストラクチャは、追加のみが可能になるように設計されており、監査証跡の完全性を確保しています。ログのアーカイブストレージへのアクセスは、厳しく制限されています。法的な理由により監査ログに記録された情報を削除する必要がある場合は、Palantir サポートと直接連携して、監査ログストレージ内にある、保存が許可されていないと疑われるデータをその場所から完全に削除するための是正計画を策定できます。

一般的な監視のユースケース

監査ログを取り込むと、セキュリティチームとコンプライアンスチームは通常、以下のセクションで説明するテーマに重点を置きます。

セキュリティ監視とインシデント対応

次のような潜在的なセキュリティインシデントを検出し、対応します。

• 侵害されたアカウント： 通常とは異なるログインパターン、地理的な異常、または移動時間から考えて不可能な場所からのアクセス。
• データ流出の試み： 大規模なデータの読み込みに続くエクスポート、特に通常の勤務時間外に行われるもの。
• 権限昇格： 予期しない権限変更や、通常の範囲を超えるリソースへのアクセス。
• 悪意のあるコードの実行： 不審なパターンで実行されるコードや、予期しないソースからのコードの実行。

調査ワークフローの例：

セキュリティ担当者が、あるユーザーアカウントによる通常とは異なるデータアクセスについてアラートを受信します。カテゴリーによる絞り込みを使用して audit.3 ログを調査します。

1. 特定の time フィルターの範囲内で、対象ユーザーの categories に dataLoad が含まれるすべてのログをクエリします。
2. resultFields を調べ、アクセスされたデータセットを正確に特定します。
3. categories に dataExport が含まれるログをクエリし、実際にデータがエクスポートされたかどうかを確認します。
4. users フィールドと entities フィールドを確認し、アクティビティの時系列を完全に把握します。
5. ユーザーに連絡して業務上の背景を把握し、そのアクティビティが正当なものだったかどうかを判断します。

構造化された監査ログのカテゴリーを使用すると、検索対象となる特定の Foundry サービスやイベント名を知る必要がなくなります。担当者は、システムアーキテクチャを調べるのではなく、行動の把握に集中できます。

説明責任とコンプライアンス

機密データや規制対象のデータを扱う組織では、次の用途があります。

• アクセス監査： データへのアクセスが、承認された範囲内で、正当な目的のためにのみ行われたことを確認します。
• 権限の濫用の検出： 権限を持つユーザーが、想定されたアクセスパターンを逸脱したときを特定します。
• 規制への準拠： 包括的な監査証跡を通じて、データ保護規制への準拠を示します。
• リーガルホールドの支援： 特定のユーザーやデータ資産に関する完全なアクティビティ記録を迅速に取得します。

コンプライアンスワークフローの例：

コンプライアンスチームが、患者データのエクスポートを行ったのは、適切な研修認定を受けたユーザーのみであることを確認する必要があります。

1. 特定の time フィルターの範囲内で、categories に dataExport が含まれ、リソースが患者データセットと一致するすべてのログをクエリします。
2. uid フィールドを内部の認定記録と照合します。
3. ユーザーによるエクスポートが行われるたびにアラートが発行されるよう、継続的な監視を設定します。
4. すべてのデータアクセスとエクスポートのアクティビティを示すコンプライアンスレポートを定期的に生成します。

監査カテゴリーを活用する

監査ログは、意図とアクションタイプに基づいて関連するイベントをまとめる監査カテゴリーに整理されています。カテゴリーを使うと、製品に依存せずに関連するイベントを特定できます。たとえば、dataExport カテゴリーには、エクスポートを実行した Foundry アプリケーションにかかわらず、すべてのデータエクスポートイベントが記録されます。

この抽象化により、セキュリティアナリストは Foundry の内部アーキテクチャに関する深い知識がなくても、ユーザーの行動を分析できます。たとえば、データ流出の可能性を調査する際は、製品固有のイベント名を何十個も列挙する代わりに、dataExport で絞り込むだけで済みます。セキュリティ監視やコンプライアンスのワークフローでよく使われるカテゴリーには、次のようなものがあります。

利用可能なカテゴリーの全一覧と詳細なフィールド仕様については、監査ログカテゴリーのドキュメントを参照してください。

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

カテゴリーに基づくクエリを作成する

監査ログカテゴリーを使うと、すべての Foundry 製品に対応する、強力で保守しやすいクエリを作成できます。疑似コードでは、次のようになります。

すべてのエクスポートアクティビティを監視する：

categories contains "dataExport"

資格情報が侵害された可能性を調査する：

categories contains "authenticationCheck" AND result = "FAILURE" 
GROUP BY uid
HAVING COUNT(*) > 5

機密性の高いリソースの権限変更を追跡する：

categories contains "managementPermissions" AND resource_id IN (sensitive_resource_list)

カテゴリーに基づくアプローチにより、新しい機能が追加されてもクエリの有効性が維持されます。今後開発される新しいエクスポート機能でも dataExport カテゴリーが使用されるため、分析のクエリを更新する必要はありません。

監査監視のベストプラクティス

行動のベースラインを確立する

自動アラートを実装する前に、通常のアクティビティのベースラインを確立します。

• ユーザーまたはユーザーグループごとの、通常のログイン時刻と場所。
• 通常のデータアクセスパターン（対象データセット、アクセス頻度、量）。
• 期待されるエクスポート動作（目的、タイミング、データ量）。
• 標準的な権限変更ワークフロー。

異常は、コンテキストがあって初めて意味を持ちます。通常の行動パターンとプラットフォームの利用状況を理解することで、誤検知を最小限に抑えた、精度の高いアラートを実現できます。

多層防御を実装する

複数の検出メカニズムを重ね合わせます。

• 重要なセキュリティイベント（ログインの失敗、機密データのエクスポート）に対するリアルタイムアラート。
• 傾向やパターンの検出（通常と異なるアクセスの増加、権限のドリフト）のための定期的な分析。
• アラートの調査と対応の調整のためのインシデント対応手順。
• 監視範囲とアラートの有効性を確認するための定期的な監査。

パフォーマンスを最適化する

大規模な監査データセットを扱う場合は、次の点に留意してください。

• データ量を減らすため、必ず最初に time の範囲で絞り込みます。
• 詳細なフィールドを調べる前に、クエリパイプラインの早い段階で categories フィルターを使用します。
• SIEM または分析プラットフォームで、絞り込みによく使うフィールドを事前に設定またはインデックス化します。

Palantir CIRT と連携する

Foundry のセキュリティ責任共有モデルの一環として、Palantir の Computer Incident Response Team（CIRT）は、ホストされた顧客のプラットフォームでセキュリティ脅威を監視しています。CIRT は、ホストされた顧客のプラットフォーム上のアクティビティを対象としたアラートおよび検出戦略 ↗を維持しています。CIRT がプラットフォーム上で不審なアクティビティを特定した場合、そのアクティビティの確認のために連絡します。

通常のユーザー行動に関する理解と組織のセキュリティ要件に基づいて、独自の監査ログ監視を実装することを推奨します。顧客自身が持つ業務分野の知識により、プラットフォームレベルの監視では検出できない異常を特定できます。プラットフォームの利用が適切であり、独自のポリシーや義務を満たしていることを保証できるのは、顧客自身だけです。

はじめに

新規に実装する場合は、このドキュメント全体で詳しく説明している次の手順に沿って進めてください。

1. 配信方法を選択する： API による直接取り込み（既存の SIEM インフラストラクチャ向け）と Foundry エクスポート（プラットフォーム内の分析向け）のどちらを使うか決めます。
2. API アクセスまたは Foundry エクスポートを設定する： 選択した方法のセットアップ手順に沿って進めます。
3. 優先するカテゴリーを特定する： セキュリティとコンプライアンスの要件に合うカテゴリーを特定します。
4. 初期クエリを作成する： まずカテゴリーに基づく広範なフィルターを使用し、その後で具体的なフィールド条件を追加します。
5. ベースラインを確立する： 過去のデータに対してクエリを実行し、通常のパターンを把握します。
6. アラートを実装する： 優先度の高いセキュリティイベントに対するアラートを設定します。
7. 反復して改善する： 運用経験に基づいてアラートのしきい値を調整し、新しい検出を追加します。

監査ログの監視に関する追加のサポートが必要な場合や、特定のユースケースについて質問がある場合は、Palantir サポートにお問い合わせください。