产品功能
当您把合规计划迁移到 SaaS 平台时，您交给平台的是真正敏感的材料：您的风险登记册、事件记录、ICT 服务提供商合同、审计证据、差距评估。这类数据是监管机构会询问的，也是竞争对手想看的。因此，对任何供应商提出一个简单问题是合理的：在你们那边，谁可以看到我的数据，什么时候可以看到？
对于大多数 SaaS 产品，坦率的答案是“支持和工程人员可以，只要他们认为有需要”。Venvera 的做法相反。默认情况下，没有任何 Venvera 工程师可以打开您组织的工作区。通过支持“view as”路径打开您的组织，只会在您自己的某位组织管理员批准一项具体且有时间限制的请求后发生。本文说明该流程如何运作，以及为什么我们把产品设计为默认关闭的起点。
默认关闭
Venvera 是多租户平台。每个组织的数据在数据库层通过行级安全实现隔离，因此每一次查询都限定在单一组织范围内运行。在此基础上，通过支持“view as”路径打开客户组织还受到门控：除非该组织存在一个有效且已批准的访问授权，否则平台会拒绝启动会话。
起点是关闭的。 控制这一点的组织标志对每个客户组织默认开启；只有 Venvera 自己的内部和演示组织保持开放。如果没有有效且已批准的授权，工程师尝试通过 view-as 路径打开您的组织会被拒绝，会话根本不会启动。
对于一个保存合规数据的平台，这是正确的默认设置，但它不能覆盖全部情况。支持工作偶尔确实需要查看真实组织。
我们也应坦率说明其中的取舍，因为这是真实存在的。默认关闭会让支持变慢。原本可以快速查看某个组织的工程师，必须写明理由，并等待您这边的人员阅读。我们认为，对于一个保存您的风险登记册和事件记录的平台，这是应付出的合理代价；但如果您正在比较供应商，可以预期那些具有常设访问权限的供应商会更快关闭某些工单。请决定您到底希望合规工具具备这两种属性中的哪一种。
临时访问如何运作
有些问题只有使用您的实际数据才能复现：依赖特定配置的 bug、卡住的导入、计算出的数字看起来不对的关键风险指标 (KRI)。针对这些情况，Venvera 采用了类似云服务提供商所称 customer lockbox 的请求与批准流程。它分为四个阶段，而第二阶段的门由您控制。
除非组织管理员在第二阶段主动批准，否则第三和第四阶段不会发生。在该流程中，不存在自动授予访问权限的超时机制，不存在绕过您的升级路径，也不存在请求工程师批准自己请求的方式。
工程师必须请求哪些内容
工程师不能悄悄地、宽泛地或批量请求访问权限。请求表单要求他们以书面形式承诺三项具体内容。
- 批准人。 来自您组织的一名指定管理员。工程师选择的是为您工作的真实个人，而不是 Venvera 邮箱，也不是通用支持队列；平台会拒绝任何不是您组织管理员的人。
- 原因。 至少八个字符的自由文本，并按原文存储。批准人会逐字看到该原因，它也会作为请求记录的一部分被捕获到您的组织审计日志中，因此含糊或复制粘贴的原因会一直对您可见，并保留在记录中。
- 时长。 以分钟计量，最高 1440，即 24 小时，请求表单和数据库约束都会强制执行。如果工作持续更久，工程师必须提交新的请求，并由您再次批准。
请求提交后，被选择的批准人会收到通知。没有其他人可以代替他们批准，而此时工程师仍然没有访问权限。
指定一个人而不是共享队列，原因并不光鲜。任何人都能清理的队列，往往会被最不可能阅读理由的人清掉。必须查看书面理由的指定批准人是一道较慢的门，但也是好得多的一道门。
从仪表板或通过电子邮件批准
批准人可以通过两种方式操作。在 Venvera 内，请求会显示在他们的仪表板上，他们可以直接批准或拒绝。离开应用时，他们会收到一封包含一次性链接和六位数字代码的电子邮件。仅打开链接本身还不够：批准人必须以自己的身份登录 Venvera，然后输入代码。这种两段式检查意味着，自动点击的邮件扫描器，或被转发到错误收件箱的链接，都无法批准任何内容。
为什么需要两个渠道？ 仪表板渠道是已在 Venvera 中工作的管理员的快速路径。电子邮件渠道的存在，是为了在批准人尚未登录时仍可完成批准，而且它不会削弱检查：仅点击链接本身不会授予任何权限。
有时限，并且可随时撤销
已批准的授权在起止两端都有边界。
| 典型 SaaS 支持访问 | Venvera 工程师访问 |
|---|---|
| 支持和工程团队对客户数据持有常设访问权限。您信任的是一项策略，而且通常无法看到该访问权限何时被使用。 | 没有常设访问权限。每次授权都是一项已批准的请求，包含开始时间、到期时间，以及您这一侧具名的批准人。 |
| 访问权限一旦授予，往往会持续存在。移除它是一项手动清理任务，而这类任务经常不会发生。 | 访问权限会自行结束。工程师获得的查看会话以授权到期时间为上限，因此不能被延长到您批准的时间窗口之外。 |
| 撤销访问权限意味着向供应商提交工单，并等待有人处理。 | 任何组织管理员，而不仅是原始批准人，都可以从访问仪表板立即撤销一个正在生效的授权。 |
任何单个请求最多只能申请 24 小时。更短的时长很常见：用于快速复现问题的 1 小时授权很常见。重点是，访问权限从一开始就内置了结束时间，而不是依赖某个人记得把它收回。
请求及其决策都会进入您的审计日志
您不必仅凭信任来接受这一流程，因为请求及其每一次决策都会记录在您自己的组织审计日志中，并在您的访问仪表板上与实时状态并列显示。
- 原始请求，包括所请求的原因和持续时间。
- 批准或拒绝，包括使用的是哪个渠道，是应用内还是电子邮件。
- 撤销（如有），包括是哪位组织管理员撤销的。
每项授权都带有自己的开始时间、到期时间和具名批准人，因此您可以准确看到时间窗口何时打开、何时关闭，以及由谁授权。这是请求及其决策的记录。位于 /tenant-access 的访问仪表板可在一个位置显示待处理、有效和已结束的请求。
为什么这对 NIS2 和 DORA 很重要
如果您运行合规计划，对您数据的第三方访问正是您自己的框架要求您治理的事项。根据 欧盟 NIS2 指令，供应链安全是一项明确义务。根据 欧盟《数字运营韧性法案》（DORA），您的 ICT 第三方服务提供商及其持有的访问权限，应纳入您的信息登记册和监督安排。ISO 27001 附录 A 也以同样精神覆盖供应商关系和特权访问。
Venvera 本身也是面向其客户的 ICT 服务提供商。这里描述的批准流程，是让您能够用具体内容回答这些框架中供应商访问问题的一部分：通过支持路径的访问默认被拒绝，仅按请求授予，有时限，可撤销，并在您这一侧记录日志。这比供应商策略文件中的一段文字有力得多。
请向每一家持有您受监管数据的 SaaS 供应商提出同样的问题，并留意其回答的形式。“访问权限仅限于我们安全策略下的授权人员”描述的是一种意图。您可以从自己的审计日志中查看、撤销和导出的逐请求批准，描述的是一项控制措施。只有后者能为评估人员提供可抽样的内容。
审计师会问。 “您如何控制 SaaS 供应商对您受监管数据的访问？”这是 NIS2 或 DORA 评估中的常见问题。能够展示按请求、限时、带审计日志的批准流程，是一个清晰的回答。
它是什么，以及它不是什么
值得精确说明这项控制措施的边界。该批准流程是一个程序性关口。Venvera 的应用层持有对您的数据进行操作所需的按组织密钥，组织管理员的批准会打开通过该层的支持路径。该流程保证该路径默认关闭，仅在获得您明确且已记录的同意后打开，并在时间窗口结束时自动再次关闭。
它不会把解密密钥交到您手中。由客户持有、连 Venvera 员工也无法使用的密钥，是另一项控制措施，而此流程并未声称提供该能力。此流程提供的是一个默认关闭、按请求开启、有时间限制并记录审计日志的门禁，用于通过支持场景下的 view-as 路径控制员工访问。
如果供应商告诉您，客户管理的密钥会让员工访问变得不可能，请仔细阅读小字条款，确认哪些操作仍然在其平台内部运行。密钥托管和访问治理是彼此独立的控制措施，而且多数提供前者的产品仍然需要后者。我们宁愿把边界讲清楚，也不愿让您带走一个我们并未作出的保证。
对于这一路径，默认规则不变：您的组织数据仍归您所有，Venvera 员工只有在您同意时才会打开，并且只在您同意的时长内打开，请求及其批准都会留有记录。
