自动化访问权限审查软件详解

什么是用户访问权限审查？

用户访问权限审查，有时也称为访问权限复核或权限审查，是一项定期检查，用于确认每一个人员和每一个非人类账户是否仍然需要其所持有的访问权限。由具备相应职权的人员查看每一项权限，并决定保留、变更还是移除，这一决定会连同日期、审核人和理由一并记录。第三方访问只是问题的一半；对供应商本身的评估，请参阅如何开展第三方风险评估。

之所以存在这项义务，是因为访问权限会不断累积。人员调岗后仍保留着原来的权限。承包商的工作结束了，却没有人关闭其账户。为一次迁移而创建的服务账户，在迁移结束后又存在了四年。这些都不是疏忽，而是熵增；审查正是按计划扭转这种熵增的机制。

为什么登记册决定一切

几乎所有已发布的指南都把审查本身视为难点。实际上，一旦您清楚自己要审查的是什么，审查就很简单。真正的难点在于登记册：一份完整、及时的清单，列明哪些身份在哪些系统上持有哪些访问权限。

想一想基于电子表格的审查究竟确认了什么。有人从三个系统中导出用户，粘贴到一个工作簿中，发给各位经理，再收集批准结果。得到确认的是导出的数据，而不是实际的系统环境。没有人记得的系统不在文件里，因此不会被审查，而签字确认却表示一切正常。这比不做审查还要糟糕，因为您现在手里有一份文件，它断言了一种您从未核实过的状态。

登记册还必须包括人们容易遗忘的类别。服务账户，它们没有可以询问的经理。第三方服务提供商的访问权限，它们位于您的身份提供商之外。承包商，他们持有的权限往往比正式员工更敏感，离开时也不会触发人力资源流程。在上面的登记册中，得分最高的三个条目全部是非人类账户或第三方账户。

大多数指南在访问权限审查上错在哪里

有两个错误几乎随处可见，而且都会让审查的价值低于其所耗费的精力。

把每一项权限都同等对待。内部 wiki 上的只读账户和支付平台上的特权管理员占据同样的一行，得到同样的关注，于是审核人的精力被平均分配到后果截然不同的各个条目上。审核人随后便会走过场式地盖章批准，因为在任何人所拥有的时间内，一份四百行、毫无区分的清单根本无法真正审查。

审查时不记录决定当时的风险。六个月后，监管机构询问为什么一个第三方特权账户获得了批准。如果记录只写着“T. Weber 于 3 月 14 日批准”，您就无法还原当时掌握了哪些信息。如果记录写着“在风险评分为 7、已启用 MFA、已开启活动日志的情况下批准”，那么即使该结果后来被重新审视，这一决定也经得起质询。

访问权限审查软件实际必须做什么

究竟哪些环节被自动化

“自动化访问权限审查软件”这一说法涵盖了两种截然不同的产品。一种将审查周边的事务性工作自动化。另一种则声称能将审查本身自动化。只有前一种以监管机构能够接受的形式存在，因此在比较工具时，真正有用的问题是：软件替您承担了审查周期中的哪些部分，又把哪些部分交还给您。

以下按照上一节所列的审查周期各个环节，如实地加以划分。

目录能告诉您什么，不能告诉您什么

当登记册是从身份提供商构建、而不是手动录入时，值得准确了解哪些字段是推断出来的、又是如何推断的，因为这些字段决定着风险评分。例如，读取 Microsoft Entra ID 只能得到四项事实，仅此而已：

• 成员还是来宾。来宾属于外部方，因此会被映射到两种账户权重中较重的那一种，而不是较轻的那一种。
• 是否为特权账户。依据的是是否属于某个公认的管理角色，而不是任意角色。担任报表类角色不应让某人被标记为特权用户。
• 管理员还是普通用户。目录无法区分只读用户和普通用户，因此它从不声称能够区分。
• 已注册 MFA 还是仅使用密码。但有一个重要的前提：如果工具在某次运行中无法读取某人的身份验证方法，就必须将此人略去，而不是记录为未启用 MFA。把一次失败的 API 调用当作审计发现，会因为一个暂时性错误而抬高此人的风险评分。

这一行中的其他所有内容都来自您。数据分类以及系统是否支持关键职能，是资产的属性，而不是目录的属性。活动日志和密码策略，则是您如何运行该系统的属性。一个悄悄替您填写这些内容的工具是在猜测，而这种猜测最终会进入一个您必须为之辩护的评分中。

让自动化安全可靠的规则

这类软件最重要的一项设计决策，是当目录与登记册不一致时软件如何处理。覆盖登记册是最显而易见的做法，也是错误的做法。这些字段是风险评分的输入，因此改写它们会让一项已经签字确认的审查所依据的评分发生变动，最终您会得到一行显示“已批准”、但对应的分数却从未有人批准过的记录。更糟糕的是，一个已在目录中被禁用的账户，看起来像是在提示您将该权限标记为已撤销，但撤销需要一个日期，而目录并不记录账户是何时被停用的。编造这个日期，就等于在审计记录中放入了一个捏造的事实。

因此，安全的模式是：提出新条目，报告偏差，标记那些背后已没有任何对应对象的账户，并把每一项变更都留给人来决定。自动化的价值在于从四百个条目的登记册中找出需要关注的十二个，而不是替您对它们采取行动。

为访问风险评分，让审查经得起质询

只有能够解释的评分才有用。大多数工具只呈现一个红色、黄色或绿色的标记，却不公布评分模型，这样就无法回答审计师提出的第一个问题：这是怎么计算出来的？

Venvera 在数据库中根据权限本身所记录的属性，计算出 0 到 11 分的评分。

这里有两个重要特性。评分是确定性的，因此两个人为同一项权限评分会得到相同的结果，没有人会为此争论。而且补偿性控制措施会减分，这意味着该模型奖励的是您修复根本问题，而不仅仅是更频繁地审查。一个能够访问机密数据、支持关键职能的第三方特权管理员，得分为 11。启用 MFA、日志记录和密码策略后，同一项权限的得分为 7。这就是一项审计发现与一项受控风险之间的区别。

审查状态应自动推导

在访问权限审查计划中，过时数据最常见的来源是一个需要有人维护的状态列。它总是错的，因为它取决于当天的日期，而没有人会每天更新电子表格。

Venvera 按行推导状态，而不是存储状态：没有审查日期的为从未审查，不足 335 天的为有效，335 至 365 天之间的为即将到期，超过 365 天的为逾期，已撤销的条目则为不适用。年度周期遵循监管机构对访问权限审查所期望的惯例。由于状态是推导得出的，登记册在您打开的那一刻就是准确的。

如何逐步开展一轮审查周期

1. 在审查任何内容之前，先建立登记册

先列举系统，再列举每个系统中的身份。要明确纳入服务账户、第三方服务提供商的访问权限以及承包商，因为它们都不会经过入职流程。如果您已经有导出文件，可以从 CSV 导入。

2. 记录补偿性控制措施

按每项权限记录 MFA、活动日志和密码策略。正是这些信息让登记册不至于满屏红色，也让评分具有意义。

3. 界定周期范围

覆盖全部内容的周期，是一个永远没人能完成的周期。可以按风险评分、按系统或按状态界定范围。每季度审查一次评分在 6 分及以上的条目，再每年全面审查一次，是一种经得起质询的模式。

4. 指派具备职权的审核人

审核人必须能够说“不”。一个无法撤销权限的审核人，只是一个挂着职位头衔的橡皮图章。

5. 逐项作出决定，并附上理由

批准、修改或撤销。每一项决定都必须填写理由字段，包括批准在内，因为日后受到质疑的恰恰是那些批准决定。

6. 落实撤销操作，并加以证明

从未落实到系统中的撤销决定，正是审计师要找的失效模式。请形成闭环，并记录日期。

7. 导出证据包

周期的产出是一份注明日期的文件，显示范围、审核人、各项决定、理由，以及每项决定作出时的风险评分。

电子表格、IGA 套件还是合规平台

坦率地说明其中的取舍：IGA 套件可以连接您的身份提供商并自动发现权限，而合规模块通常做不到这一点。合规模块给您的则是：审查直接以其所满足的控制措施为依据形成证据，以及一条短得多的路径，让您完成一轮经得起质询的首次审查周期。

哪些框架要求开展访问权限审查

实际要点在于：一个登记册和一个周期就能同时为上述所有框架提供证据，前提是证据被映射到每个框架的控制措施，而不是按框架分别归档。这与我们在 NIS2 与 ISO 27001 对比一文中提出的复用论点相同。

最佳实践

• 对高风险尾部条目的审查频率要高于其他条目。每季度审查评分 6 分及以上的条目，每年审查整个登记册。
• 按名称将服务账户纳入范围。它们没有经理，没有离职流程，而且在大多数环境中持有最敏感的权限。
• 批准时也要求填写理由，而不仅仅是撤销时。受到质疑的恰恰是批准决定。
• 记录作出决定时的风险评分。正是它让过去的决定经得起质询。
• 修复底层控制措施，而不是更频繁地审查。启用 MFA 能降低真实风险；再多一轮审查周期只是把风险记录下来。
• 在源系统中完成撤销并记录日期。一项未落实的撤销，就是一个迟早会出现的审计发现。

在 Venvera 中完成这项工作

访问权限审查（Access Reviews）功能包含在 Venvera 的每一个套餐中，包括入门级套餐。您将获得：登记册；在数据库中计算的上述评分模型，因此不会偏离公布的权重；自动推导的审查状态；已界定范围的审查周期，支持逐项决定和理由；在每项决定作出时标记的风险评分；以及映射到其所满足的 ISO 27001、SOC 2、欧盟 NIS2 指令和欧盟《数字运营韧性法案》（DORA）控制措施的证据。

在自动化方面，登记册可以通过两种方式自动填充。连接 Microsoft Entra ID 后，Venvera 会读取您的账户、管理角色和 MFA 状态并提出条目建议，在写入任何内容之前向您准确展示它发现了什么。对于没有可读取目录的系统，您可以将访问权限矩阵作为电子表格上传，每一行都会按照与手动录入条目相同的规则进行验证。如果目录日后与登记册不一致，Venvera 会报告差异，并把变更留给您决定，原因如上文所述。

常见问题

什么是自动化访问权限审查软件？

这类软件维护一份登记册，记录哪些身份在哪些系统上持有哪些访问权限；为每项权限进行风险评分；并定期运行审查周期，由具名审核人批准、修改或撤销访问权限，同时记录决定及其日期和理由。

访问权限审查中的哪些部分真正可以自动化？

从您的身份提供商建立登记册、为每项权限评分、推导某项审查是仍然有效还是已经逾期、检测自上次审查以来发生变化的权限，以及在周期结束时汇编证据包。决定本身无法自动化，也没有任何框架要求将其自动化：DORA、ISO 27001 和 SOC 2 都要求由一位具名人员作出一个可以明确指认的判断。

访问权限审查应多久开展一次？

每年一次是常见的基准，也是大多数框架通常被解读为所期望的频率。风险较高的权限，尤其是特权账户、第三方账户和服务账户，通常每季度审查一次。按风险评分界定范围，而不是以相同节奏审查所有内容，是更有效的模式。

用户访问权限审查应包括哪些内容？

身份、系统、访问级别、该访问是否为特权访问或远程访问、数据分类、是否支持关键职能、现有的补偿性控制措施、上次审查日期，以及决定及其理由。

服务账户需要进行访问权限审查吗？

需要，而且它们是最常被遗漏的类别。它们没有经理，也不会触发离职流程，往往持有管理员权限，而且由于是非交互式账户，常常没有启用 MFA。在大多数登记册中，它们的得分最高。

用电子表格做访问权限审查够吗？

对于规模很小的公司，它可以支撑第一轮审查周期。但规模扩大后它会失效，原因有三：它确认的是导出的数据而不是实际环境；它没有评分，因此审核人的注意力被平均分散；它也不会保留作出决定时所掌握信息的历史记录。

什么是访问权限复核？

这是同一项活动的另一种说法：定期确认现有访问权限是否仍然恰当，并在不恰当时予以移除。

如何向审计师证明已开展访问权限审查？

提供一份注明日期的导出文件，显示周期的范围、谁审查了什么、每个条目的决定、理由，以及决定作出时的风险状况。审计师还会检查撤销操作是否已在源系统中落实。

哪些框架要求开展用户访问权限审查？

ISO 27001 通过附录 A 的访问控制主题提出要求，SOC 2 通过逻辑访问相关的通用准则提出要求，NIS2 依据第 21(i) 条，DORA 依据第 9 条，PCI DSS 依据要求 7。一个登记册和一个周期就能为所有这些框架提供证据。

访问权限审查软件能取代身份治理吗？

不能。身份治理套件可以自动化权限开通，并能从已连接的系统中发现权限。合规平台模块则专注于登记册、审查和证据，能让您快得多地完成一轮经得起质询的审查周期。