監査ログを監視する

効果的なセキュリティ監視には、包括的かつタイムリーな監査ログが不可欠です。このガイドでは、ユーザーアクティビティの把握、セキュリティインシデントの検出、および組織のポリシーへの準拠の確保のために、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 に転送することもできます。エクスポートした audit.3 ログを検索して確認するには、Audit Explorer を使用します。

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) は、Palantir がホストする顧客のプラットフォームでセキュリティ脅威を監視しています。CIRT は、これらのプラットフォーム上のアクティビティを対象としたアラートと検出の戦略 ↗を維持しています。CIRT がお使いのプラットフォームで不審なアクティビティを特定した場合は、そのアクティビティの妥当性を確認するためにご連絡します。

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

はじめに

新たに導入する場合は、このドキュメント全体で詳しく説明している次のステップに沿って進めてください。

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

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