审计日志与支持访问：谁在何时改了什么

设想一下 Marta，一家拥有两层办公楼和一个停车场的 250 人公司的行政经理。周二上午 9:50，十分钟内有三个人给她发消息：他们的工位预订被当作未到场释放了，可他们和每周一样，9:40 就到了。有什么东西被改了，却没人记得改过。组织里有四名管理员，还有一个从公司目录同步用户的集成。问题很简单：谁在何时改了什么？

一周后，她的数据保护官在年度供应商审查中提出了另一个问题："软件供应商今年有没有查看过我们的数据？如果有，是什么时候？"这类问题常常用一份政策文件来回答。Marta 则希望用一份清单来回答。

本文一步步介绍 Desk & Park 审计日志如何回答这两个问题，以及它不做什么。

第 1 步：打开审计日志，找到那次变更

管理员可以在审计日志中找到它。顶部有三个计数器：过去 24 小时的事件数、警告数和严重事件数。下方是最近条目的表格，最新的排在最前，包含以下列：

• 时间戳：发生的时间。
• 严重级别：信息、警告或严重。
• 操作者：进行变更者的电子邮件地址，下方注明其角色；自动操作则显示为"system"。
• 操作和资源：做了什么，以及针对哪类对象。
• 详情：涉及的值，例如角色变更时显示 role: MEMBER → ADMIN。
• IP 地址：请求来自哪里。

Marta 在搜索框（"按操作者、操作或详情搜索"）中输入"policy"。记录就在那里：昨天 17:12，一名管理员修改了预订策略，缩短了签到截止时间。条目记录了变更前后的值，因此接下来的讨论是关于新的截止时间是否合理，而不是谁干的。（如果您正在调整这个截止时间，我们关于幽灵预订与自动释放的文章解释了其中的取舍。）

记录哪些内容

日志覆盖管理员可能需要复盘的所有变更：用户和角色、预订、空间和地图、办公地点、预订策略、集成、单点登录和 SCIM 设置、日历同步、访客、自助终端设备和备份。SCIM 开通自动做出的变更也会出现，因此"目录停用了此人"与"某位管理员停用了此人"可以区分开来。

每个条目都会存储操作者及其角色、操作及其涉及的对象、结果、变更前后的值、IP 地址以及浏览器的用户代理。

严重级别筛选

角色变更、停用和删除标记为警告。失败的操作标记为严重。按严重级别筛选是最快的每周审查方式：把筛选设为警告，扫一眼谁被提升了权限、谁被停用了，就完成了。

第 2 步：安全动态，合并在同一张表中

内容变更只是一半。同一张表还会显示安全动态：成功和失败的登录、多次失败后的锁定、要求和验证失败的双因素代码、开启或关闭双因素认证、密码重置和修改，以及已吊销会话令牌的重复使用。登录失败、锁定或令牌重复使用显示为严重；关闭双因素认证显示为警告。

对 Marta 来说，这意味着只需看一个地方。如果某个帐号在 7:00 被锁定、7:05 角色被更改，这两行会紧挨着出现。

第 3 步：回答数据保护官——支持访问记录在您自己的日志中

现在看第二个问题。当平台运营方（即运营 Desk & Park 的团队）为处理工单而打开贵组织的支持视图时，系统会在贵组织自己的审计日志中写入一条记录。它显示为 TENANT SUPPORT ACCESS，附有运营方人员的电子邮件地址、时间和 IP 地址。

于是 Marta 在搜索框中输入"support"，就以清单形式得到了答案：供应商一方的人何时打开过组织的数据，以及是谁。这就是"我们有一项政策"与"这是记录"之间的区别。这条记录写入的是您的日志，而不是只有供应商才能读取的日志。由于页面显示的是最近的条目，Marta 把这项检查变成了每月的习惯，并保存导出文件，而不是等到年度审查时才看。

日志存放在哪里，保存多久

在 Desk & Park 中，每个组织都有自己的 PostgreSQL 数据库和自己的数据库登录角色，审计日志就存放在那里，与您的用户、地图和预订放在一起。我们在《为什么您的办公场所数据需要独立数据库》中解释了这种架构为何重要。安全动态由平台的登录服务保存，并经过筛选后仅向您显示本组织的内容。

审计和安全条目默认保存 365 天，之后自动删除，与隐私政策中规定的保留期限一致。围绕日志，管理员对组织数据还拥有其他控制手段：

• 组织数据库的每晚加密备份，组织管理员可以将其关闭。
• 组织数据的 JSON 导出，供管理员使用。
• 针对整个组织的删除请求。

数据处理条款见 DPA。

实用建议

• 给每个人分配自己的管理员帐号。 共用的"admin@"登录会让操作者一列失去意义。一人一个帐号。
• 每周花五分钟审查。 先按警告筛选，再按严重筛选。留意意料之外的角色变更和反复失败的登录。
• 如需更长的历史，请自行保存副本。 导出 CSV 按钮下载的是页面当前已加载的条目，也就是最近的那些。如果您的审计人员需要一年以上的记录，请定期导出，并将文件与其他合规记录一起保存。
• 把支持访问纳入供应商审查。 每月搜索一次"support"，导出结果，归档以备年度审查。只需一分钟。
• 日志要配合强健的管理员登录。 日志告诉您发生了什么；每个管理员帐号都开启双因素认证，能降低坏事发生的可能。参见《SSO、通行密钥与双因素登录》。

适用范围：它不做什么

管理页面显示最近的条目，并提供针对这些条目的全文搜索和严重级别筛选，但不支持按日期范围筛选。CSV 导出覆盖页面上已加载的条目，而不是全年。不支持将审计事件流式传输到 SIEM。超过保留期限的条目会被删除，因此长期归档靠的是您的导出，而不是产品本身。此外，上文所述的隔离是每个组织一个独立数据库，而不是独立的硬件。

常见问题

谁能看到审计日志？

组织的管理员。该页面在一张表中显示内容变更（用户、角色、预订、地图、策略、集成）和安全动态（登录、失败、锁定、双因素认证和密码事件）。

我们能看到供应商的支持团队何时访问了我们的数据吗？

能。当平台运营方打开贵组织的支持视图时，一条带有运营方人员电子邮件、时间和 IP 地址的 TENANT SUPPORT ACCESS 记录会写入您自己的审计日志。搜索"support"即可列出最近的记录；如需全年记录，请定期导出。

审计条目保存多久？

默认 365 天；更早的条目会被自动删除。如需更长的历史，请定期将日志导出为 CSV 并自行保存文件。

可以按日期筛选审计日志吗？

在管理页面上不行。您可以按操作者、操作或详情搜索最近的条目，按严重级别筛选，并导出为 CSV 后在电子表格中进一步分析。

审计日志与其他客户分开存储吗？

是的。每个组织的审计日志都存储在该组织自己的 PostgreSQL 数据库中，与其用户、地图和预订放在一起。