Monitor audit logs（监控审计日志）

Effective security monitoring depends on comprehensive, timely audit logs. This guide explains how to ingest and analyze Foundry audit logs to maintain oversight of user activity, detect security incidents, and ensure compliance with organizational policies.

Overview

Audit logs capture critical information about every action taken in Foundry, enabling you to understand:

• Who performed an action (user identity, session, or token).
• What the action was (categorized by type and intent).
• When the action happened (with precise timestamps).
• Where the action occurred (which resources were involved).

These logs may contain contextual information including Personally Identifiable Information (PII) such as names and email addresses. Access should be restricted to personnel with appropriate security qualifications.

Audit log delivery

Foundry provides flexible delivery mechanisms to support diverse security infrastructure and Security Information and Event Management (SIEM) requirements.

Choose your delivery method

For external SIEM integration (audit.3 only, preferred): External SIEMs can continuously poll audit.3 logs directly using Palantir's audit API endpoints. The list-log-files endpoint lists available log files filtered by date range, and the get-log-file-content endpoint retrieves the content of specific log files. This approach is preferred for organizations with dedicated security operation centers and established SIEM platforms, offering low latency for timely detection and response.

For Foundry-based analysis: For organizations without dedicated SIEM tooling or organizations with lighter analytical needs, both audit.2 and audit.3 logs can be exported to per-organization Foundry datasets. Organization admins configure the target file system location during setup. Once exported, logs can be analyzed directly in Foundry or forwarded to an external SIEM through Foundry's Data Connection application.

Refer to our audit delivery documentation for detailed API endpoint information and export setup instructions.

Data integrity

The infrastructure through which audit logs flow from generation to storage is engineered to be append-only, ensuring audit trail integrity. Access to log archival storage is aggressively restricted. If information captured in audit logs must be removed for legal purposes, you can work with Palantir Support directly to identify a remediation plan to eradicate the suspected disallowed data in place within audit log storage.

Common monitoring use cases

Upon ingesting audit logs, security and compliance teams typically focus on themes described in the following sections.

Security monitoring and incident response

Detect and respond to potential security incidents, including the following:

• Compromised accounts: Unusual login patterns, geographic anomalies, or impossible travel scenarios.
• Data exfiltration attempts: Large-scale data loads followed by exports, especially outside normal working hours.
• Privilege escalation: Unexpected permission changes or access to resources beyond normal scope.
• Malicious code execution: Code executed with suspicious patterns or from unexpected sources.

Example investigation workflow:

A security analyst receives an alert about unusual data access by a user account. Using audit.3 logs with category filtering:

1. Query for all logs within a certain time filter where categories contains dataLoad for the user in question.
2. Examine the resultFields to identify exactly which datasets were accessed.
3. Query for logs where categories contains dataExport to verify whether any data was actually exported.
4. Review the users and entities fields to understand the complete activity timeline.
5. Contact the user to understand business context and determine if activity was legitimate.

The structured audit log categories eliminate the need to know which specific Foundry services or event names to search for; the analyst can focus on understanding behavior rather than navigating system architecture.

Accountability and compliance

For organizations handling sensitive or regulated data:

• Access auditing: Verify data was accessed only within approved scope and for legitimate purposes.
• Privilege abuse detection: Identify when authorized users exceed their intended access patterns.
• Regulatory compliance: Demonstrate adherence to data protection regulations through comprehensive audit trails.
• Legal hold support: Quickly retrieve complete activity records for specific users or data assets.

Example compliance workflow:

A compliance team needs to verify that patient data exports only occurred for users with appropriate training certifications:

1. Query for all logs within a certain time filter where categories contains dataExport and resources match patient datasets.
2. Cross-reference the uid field against internal certification records.
3. Set up continuous monitoring to alert on any exports by users.
4. Generate periodic compliance reports showing all data access and export activity.

Work with audit categories

Audit logs are organized into audit categories that group related events by intent and action type. Categories provide a product-agnostic way to identify relevant events; for example, the dataExport category captures all data export events regardless of which Foundry application performed the export.

This abstraction enables security analysts to reason about user behavior without deep knowledge of Foundry's internal architecture. When investigating potential data exfiltration for example, simply filter for dataExport rather than enumerating dozens of product-specific event names. Categories frequently used in security monitoring and compliance workflows might include the following:

Category	Description	Example use case
authenticationCheck	Checks authentication status via a programmatic or manual authentication event, such as token validation.	Detect token validation patterns that suggest credential stuffing.
dataCreate	Indicates the addition of some new entry of data into the platform where it did not exist prior. This event may be reflected as a dataPromote in a separate service if it is logged in the landing service.	Track data creation patterns and enforce governance policies.
dataDelete	Related to the deletion of data, independent of the granularity of that deletion.	Alert on deletion of critical or protected resources.
dataExport	Export of data from the platform. Use for things like downloading data from the platform, such as a system external to Palantir, CSV file and more. If data was exported to another Palantir system, use the dataPromote category.	Alert on large exports, exports of sensitive data, or exports outside business hours.
dataImport	Imports to the platform. Unlike dataPromote, dataImport refers only to data being ingested from outside the platform. This means that a dataImport in one service could show up as a dataPromote in a separate service.	Monitor for malicious file uploads or policy violations.
dataLoad	Refers to the loading of data to be returned to a user. For purely backend loads, use internal.	Establish baseline normal access patterns and detect anomalous bulk data access.
tokenGeneration	Action that leads to generation of a new token.	Detect unusual token creation that could indicate preparation for bulk data access.
userLogin	Login events of users.	Monitor for failed login attempts, unusual login times, or geographic anomalies.
userLogout	Logout events of users.	Track session durations and identify abnormally long sessions.

For the complete list of available categories with detailed field specifications, refer to our full audit log categories documentation.

Performance note: Audit log datasets can contain very high volumes of data. Always filter using the time column before performing aggregations or visualizations to ensure performant queries.

Build category-based queries

Audit log categories enable powerful, maintainable queries that work across all Foundry products. In pseudo-code this would look like the following:

Monitoring all export activity:

categories contains "dataExport"

Investigating potential credential compromise:

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

Tracking permission changes on sensitive resources:

categories contains "managementPermissions" AND resource_id IN (sensitive_resource_list)

The category-based approach ensures queries remain valid even as new features are added. New export capabilities we develop will use the dataExport category without requiring query updates in your analyses.

Best practices for audit monitoring

Establish baseline behavior

Before implementing automated alerting, establish baselines for normal activity:

• Typical login times and locations for each user or user group.
• Normal data access patterns (which datasets, access frequency, volume).
• Expected export behavior (purpose, timing, data volumes).
• Standard permission change workflows.

Anomalies are only meaningful in context. Understanding normal behavior patterns and platform usage enables high-fidelity alerting with minimal false positives.

Implement defense in depth

Layer multiple detection mechanisms:

• Real-time alerting for critical security events (failed logins, sensitive data exports).
• Periodic analysis for trending and pattern detection (unusual access growth, permission drift).
• Incident response procedures for investigating alerts and coordinating response.
• Regular audits to verify monitoring coverage and alert effectiveness.

Optimize for performance

When working with large audit datasets:

• Always filter by time range first to reduce data volume.
• Use categories filters early in query pipeline before examining detailed fields.
• Pre-configure/index commonly filtered fields in your SIEM or analysis platform.

Coordinate with Palantir CIRT

As part of Foundry's shared security model, Palantir's Computer Incident Response Team (CIRT) monitors hosted customer platforms for security threats. CIRT maintains alerting and detection strategies ↗ targeted towards activity on our hosted customer platforms. If CIRT identifies suspicious activity on your platform, you will be contacted to reconcile the activity.

We encourage customers to implement their own audit log monitoring in accordance with their understanding of normal user behavior and organizational security requirements; you have the domain knowledge to identify anomalies that platform-level monitoring cannot detect. Only you can ensure that usage of your platform is appropriate and meets your own policies and obligations.

Getting started

For new implementations, follow the steps below that are discussed in detail throughout this documentation:

1. Choose a delivery method: Decide between direct API ingestion (for existing SIEM infrastructure) or Foundry export (for in-platform analysis).
2. Configure API access or Foundry export: Follow the setup instructions for your preferred method.
3. Identify priority categories: Determine which categories align with your security and compliance requirements.
4. Build initial queries: Start with broad category-based filters before adding specific field conditions.
5. Establish baselines: Run queries over historical data to understand normal patterns.
6. Implement alerting: Configure alerts for high-priority security events.
7. Iterate and refine: Adjust alert thresholds and add new detections based on operational experience.

For additional assistance with audit log monitoring or questions about specific use cases, contact Palantir Support.

---

中文翻译

监控审计日志

有效的安全监控依赖于全面、及时的审计日志(Audit logs)。本指南介绍如何摄取和分析 Foundry 审计日志，以持续监督用户活动、检测安全事件并确保符合组织策略。

概述

审计日志记录在 Foundry 中执行的每个操作的关键信息，使您能够了解：

• 何人执行了操作（用户身份、会话或令牌）。
• 何种操作（按类型和意图分类）。
• 何时发生（具有精确的时间戳）。
• 何处发生（涉及哪些资源）。

这些日志可能包含上下文信息，包括姓名和电子邮件地址等个人身份信息(Personally Identifiable Information, PII)。应仅限具备相应安全资质的人员访问。

审计日志交付

Foundry 提供灵活的交付机制，以支持多样化的安全基础设施和安全信息和事件管理(Security Information and Event Management, 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，而无需枚举数十个特定于产品的事件名称。安全监控和合规工作流中常用的类别可能包括：

类别	描述	用例示例
authenticationCheck	通过编程或手动身份验证事件（如令牌验证）检查身份验证状态。	检测表明存在凭证填充攻击的令牌验证模式。
dataCreate	指示向平台添加了一些以前不存在的新数据条目。如果在登陆服务中记录，此事件可能在单独的服务中反映为 dataPromote。	跟踪数据创建模式并执行治理策略。
dataDelete	与数据删除相关，与删除的粒度无关。	对关键或受保护资源的删除发出警报。
dataExport	从平台导出数据。用于从平台下载数据等操作，例如下载到 Palantir 外部的系统、CSV 文件等。如果数据导出到另一个 Palantir 系统，请使用 dataPromote 类别。	对大规模导出、敏感数据导出或非工作时间的导出发出警报。
dataImport	导入到平台。与 dataPromote 不同，dataImport 仅指从平台外部摄取数据。这意味着一个服务中的 dataImport 可能会在另一个服务中显示为 dataPromote。	监控恶意文件上传或策略违规行为。
dataLoad	指加载要返回给用户的数据。对于纯后端加载，请使用 internal。	建立基线正常访问模式并检测异常的批量数据访问。
tokenGeneration	导致生成新令牌的操作。	检测可能表明正在准备批量数据访问的异常令牌创建。
userLogin	用户的登录事件。	监控失败的登录尝试、异常的登录时间或地理位置异常。
userLogout	用户的登出事件。	跟踪会话持续时间并识别异常长的会话。

有关可用类别的完整列表及详细的字段规范，请参阅我们的完整审计日志类别文档。

性能说明： 审计日志数据集可能包含海量数据。在执行聚合或可视化之前，务必先使用 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 计算机事件响应团队 (CIRT) 会监控托管客户平台的安全威胁。CIRT 维护针对我们托管客户平台活动的警报和检测策略 ↗。如果 CIRT 在您的平台上发现可疑活动，将会联系您以核实该活动。

我们鼓励客户根据其对正常用户行为和组织安全要求的了解，实施自己的审计日志监控；您具备识别平台级监控无法检测到的异常的领域知识。只有您才能确保平台的使用是适当的，并符合您自己的策略和义务。

入门

对于新实施，请按照以下步骤操作，本指南对这些步骤进行了详细讨论：

1. 选择交付方式： 在直接 API 摄取（适用于现有 SIEM 基础设施）和 Foundry 导出（适用于平台内分析）之间做出决定。
2. 配置 API 访问或 Foundry 导出： 按照您首选方式的设置说明进行操作。
3. 确定优先类别： 确定哪些类别符合您的安全和合规要求。
4. 构建初始查询： 先使用广泛的基于类别的过滤器，然后再添加特定的字段条件。
5. 建立基线： 对历史数据运行查询以了解正常模式。
6. 实施警报： 为高优先级安全事件配置警报。
7. 迭代和优化： 根据运营经验调整警报阈值并添加新的检测。

如需有关审计日志监控的额外帮助或对特定用例有疑问，请联系 Palantir 支持团队。