架构
身份、租户与角色
LayerT 中的每一项操作都归属于您目录中的一个真实的人,而不是某台设备或某个共享登录。角色将配置规则的人与授予例外的人分开。
本文描述截至 2026年9月19日 已实现的 LayerT。尚未实现的内容均已标注。
您的目录是唯一可信来源
LayerT 运行一个 SCIM 2.0 服务器。您的身份提供商将人员和组推送到该服务器,并保持其更新。
- 用户和组:创建、读取、替换、更新和删除,并提供标准的发现端点。
- 筛选支持
eq和and,这正是身份提供商在预配时所使用的。 - SCIM 令牌由 LayerT 签发。它只显示一次,并仅以哈希形式保存。轮换令牌时,旧令牌会继续有效 24 小时,以免中断预配。
- 角色来自您在控制台中映射的目录组。没有映射的人获得“只读”角色。当多个映射同时适用时,以权限最高的那个为准。
LayerT 为 JumpCloud 构建。其他支持 SCIM 2.0 和 OpenID Connect 的身份提供商(例如 Okta、Microsoft Entra ID 和 Google Workspace)可能可以使用,但尚未经过认证。
登录控制台
控制台通过您的身份提供商使用 OpenID Connect 授权码流程:
- LayerT 根据电子邮件域名找到贵组织,然后携带一次性的
state和nonce将人员转到您的身份提供商。 - 返回的 ID 令牌会依据您的提供商公布的密钥进行校验:签发者、受众、有效期和 nonce。
- 人员必须已经通过 SCIM 存在于 LayerT 中。首次登录时不会创建任何人,已停用的人员会被拒绝。
- 控制台会话保存在服务器端,每次请求都会检查,包括人员当前的角色。吊销会话立即生效;更改某人的角色会使其退出登录,以便下次登录时使用新角色。
为每个浏览器颁发凭据
人员通过您的身份提供商从扩展程序登录一次。这会为浏览器颁发其自己的凭据:
| 凭据 | 有效期 | 说明 |
|---|---|---|
| 设备令牌 | 1 小时 | 随扩展程序发出的每次 API 调用一起发送。包含组织、人员和设备信息 |
| 刷新令牌 | 30 天,每次使用时轮换 | 仅以哈希形式保存。如果两次刷新同时发生,只有一次成功。刷新被拒绝时,浏览器会被取消注册 |
管理员可以在控制台中吊销设备。该设备会失去其 LayerT 凭据和对共享账号的访问权限,其上所有正在进行的共享账号会话都会结束。
人员离职时
当您的目录停用某人或将其从 LayerT 中移除时:
- 其控制台会话立即结束。
- 其共享账号请求和正在进行的会话会被吊销,其浏览器会在大约一分钟内退出这些账号的登录。
- 其未处理的访问请求会被关闭。
- 其浏览器无法刷新凭据,因此会在一小时内被取消注册。
- 任何人都无法再为其批准任何事项。
LayerT 不允许目录停用最后一位在职的所有者。它会保持该所有者的在职状态并告知其原因,以免组织把自己锁在门外。
将各组织相互隔离
- 每一条属于组织的记录都带有其所属组织,应用程序在每次查询时都会按组织进行筛选。
- 每个组织的策略单独签名,扩展程序会拒绝任何不属于自己组织的策略。
- 录制按组织分别存储在各自的前缀下。
- 测试会检查一个组织的凭据无法读取另一个组织的策略、审计事件、会话或录制。
数据库层面的隔离. 目前,隔离由应用程序执行。在数据库中增加行级安全作为第二层防护,已列入我们的计划。
LayerT 自己的员工
LayerT 员工无法浏览组织的数据。要查看某个组织的诊断信息,必须由一位具名的 LayerT 运营人员提出申请并说明原因,时长最多四小时。只有该组织的所有者才能批准。每一次查看都会记录在该组织自己的审计日志中。
角色
LayerT 有六个内置角色。它们的设计确保配置规则的人不是授予例外的人。
| 可以…… | 所有者 | IT 管理员 | 合规官 | 团队审批人 | 审计员 | 只读 |
|---|---|---|---|---|---|---|
| 发布规则 | ✓ | ✓ | ||||
| 审批请求和共享账号的使用 | ✓ | ✓ | ✓ | ✓ | ||
| 授予永久例外 | ✓ | ✱ | ✓ | |||
| 撤销例外 | ✓ | ✓ | ||||
| 管理共享账号密钥 | ✓ | ✓ | ||||
| 结束正在进行的会话 | ✓ | ✓ | ||||
| 观看录制 | ✓ | ✓ | ✓ | |||
| 批准查看密码的请求(两名审批人,其中一人为所有者或合规官) | ✓ | ✓ | ✓ | |||
| 开启录制(书面声明) | ✓ | |||||
| 吊销设备、紧急停止 | ✓(紧急停止:仅所有者) | ✓(设备) | ||||
| 查看整个组织的审计日志 | ✓ | ✓ | ✓ | ✓ | ✓ | 仅本人 |
| 导出审计日志 | ✓ | ✓ | ✓ | ✓ | ||
| 导出整个组织的数据 | ✓ |
✱ 默认不可以。所有者可以授予某一位指定人员(例如一位 IT 管理员)授予永久例外的权限。
- 任何人都不能审批自己的请求。 对于访问请求、共享账号的使用和密码请求,服务器都会拒绝这样的审批。查看已存储的密码需要另外两个人批准,其中一人必须是所有者或合规官。
- 所有者和 IT 管理员可以申请查看任何账号的密码。 其他人只能针对自己可以使用或负责的账号提出申请。
- 可选的双人审阅可以防止有人发布自己起草的规则。
- 角色变更会在两端都进行检查,因此 IT 管理员无法将所有者降级。
- 团队审批人目前可以处理整个组织的请求。将其范围限定在自己的团队内尚未构建 提议中。
- 访问审查每季度请每个共享账号的负责人确认谁仍然需要访问该账号。任何人都不能确认自己的访问权限,并且在审查人提交之前,任何人都不会失去访问权限。
审计日志
每一次阻止、请求、决定、登录、会话、录制观看和设置变更都会以通俗的文字写入同一个日志。
- 事件根据凭据关联到具体的人,从不依据请求自称的任何信息。
- 值默认可读。 如果某个个人地址被阻止,日志会显示该地址,以便审计人员核查这一决定。规则可以设置为在值到达时将其丢弃或部分遮蔽。
- 默认保留 365 天。每个组织都可以更改这一期限。
- 审批人和审计员可以看到整个组织的事件。其他人只能看到自己的事件。
- 日志可以按日期、人员、操作、结果、规则、账号、会话和设备进行筛选。屏幕上显示的任何内容都可以导出为 CSV 或 JSON Lines。除非导出者勾选相应选项,否则输入的值不会包含在导出中;导出操作会在文件开始生成之前写入日志。
尚未实现. 防篡改存储尚未构建。目前,日志的完整性依赖于访问控制、条目一经写入便无法编辑,以及报告和导出中的校验和。