> For the complete documentation index, see [llms.txt](https://academy.shade.inc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://academy.shade.inc/help-center/help-center-zh/security/shen-ji-ri-zhi.md).

# 审计日志

跟踪工作区中发生的事件，便于实时管理和监控。

### 概览

审计日志可全面追踪您工作区内执行的所有操作。该功能面向企业客户采用自愿启用模式，可按工作区单独开启。

### 访问审计日志

在为您的工作区启用后，可通过应用中的企业版部分访问审计日志：前往 **设置 > 企业版** 并选择 **查看审计日志**。该门户提供可搜索界面，您可以：

* 按时间顺序查看所有已记录事件
* 按操作类型筛选（例如，文件操作、用户管理、工作区变更）
* 按执行操作的用户筛选
* 按时间戳或日期范围筛选
* 查看每个事件的详细信息

### 将审计日志流式传输到 SIEM

除了在门户中查看和导出日志外，企业版工作区还可以将审计日志事件流式传输到 SIEM 或其他受支持的目标。前往 **设置 > 企业版 > 审计日志流式传输** 进行流配置。更多详情，请参阅 [SIEM 集成](/help-center/help-center-zh/security/shade-siem-documentation.md)

### 哪些会被记录

我们的审计日志会记录平台上经过身份验证的用户操作。针对您的工作区发出的每一条请求（无论是通过应用、Web、挂载还是 API），包括查看或列出文件等只读请求，都会被我们的日志系统捕获，并存储在审计日志提供方 WorkOS 中。每条日志记录包括：

* **操作**：执行的具体操作（例如，文件上传、权限变更）
* **执行者**：执行该操作的用户，包括其 IP 地址
* **目标对象**：受该操作影响的资源（文件、文件夹、用户等）
* **时间戳**：操作发生的时间
* **工作区上下文**：操作发生所在的工作区

### 哪些不会被记录

为保持性能并聚焦于与安全相关的事件，我们不记录：

* 内部系统操作
* 身份验证令牌刷新
* 未经身份验证的请求
* 少量常规后台查询（例如，列出您的工作区或根据其 URL 查找工作区）

### 安全与隐私

* 审计日志按组织隔离
* 仅记录您工作区内经过身份验证的操作
* 日志保留期限依据您的企业协议而定
* 仅工作区管理员可访问审计日志

### 启用审计日志

审计日志由我们的团队在工作区级别启用。请联系您的客户代表，为您的组织激活此功能。

***

如对审计日志有任何问题或需要申请启用，请联系您的客户经理或企业支持。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://academy.shade.inc/help-center/help-center-zh/security/shen-ji-ri-zhi.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.