平台能力

把「谁能在什么条件下访问什么」说清楚，并且真的执行下去

ztg 的每一项能力都建立在同一个前提上：授权决策与数据转发物理分离。控制面只回答该不该放行，数据面只负责把已放行的连接转过去。

01 / 决策输入

一次访问，六项输入

授权不是「认证通过就放行」。结论由六项输入共同决定，任何一项缺失都落到默认拒绝。

  • User

    用户

    经统一身份认证，身份即权限主体

  • Device

    设备

    平台签发的设备证书与设备状态

  • Session

    会话

    短时效令牌，绑定用户与设备

  • Resource

    资源

    被访问的应用、系统或数据对象

  • Action

    动作

    读取、写入、导出、打印等具体操作

  • Context

    环境

    时段、网络位置、风险评分等上下文

这六项输入构成的不是一次性的「入场券」，而是每一次访问都要重新回答的问题。建立加密通道只证明设备到达了网关，不产生任何资源权限。

02 / 决策模型

五个取值，覆盖真实的策略语义

把二次验证、人工审批、限制放行做成一等公民，策略就不必为了绕开二元模型的限制而写得扭曲。

  • ALLOW 放行

    策略条件全部满足。

    身份、设备、会话、资源、动作、环境六项输入齐备且均符合策略。

  • DENY 拒绝

    条件不满足，或任一环节信息缺失。

    默认结论。策略明确拒绝、输入不完整、评估服务不可用，都落到这里。

  • REQUIRE_MFA 二次验证

    风险等级要求追加身份验证。

    身份有效但当前环境的风险评分高于该资源的常规阈值。

  • REQUIRE_APPROVAL 人工审批

    敏感资源需要审批后才放行。

    资源被标记为高敏感，或动作属于高风险类别（如批量导出）。

  • RESTRICT 限制放行

    放行，但附加数据使用限制。

    访问本身合理，但数据分类要求对下载、打印、剪贴板等动作设限。

03 / 能力详述

六项核心能力

每一项都可以单独评估，也可以组合使用。

01

应用级访问控制

传统方案在用户通过认证后把他放进一个网络平面，此后能碰到什么取决于网络拓扑。ztg 的授权粒度是「谁、用什么设备、在什么环境下、对哪个资源、执行哪个动作」，结论精确到单次访问，而不是一次性的网络入场券。

  • 授权对象是资源与动作，不是网段
  • 同一用户对不同应用的结论可以完全不同
  • 新增应用不需要改动网络拓扑，只在控制面登记资源
02

设备身份绑定

身份不只是「谁」，还包括「从哪台设备」。设备持有由平台签发的 X.509 证书，经双向 TLS 完成接入认证；加密通道的建立被强制绑定到「用户 + 设备 + 会话」三要素，缺任意一项都无法成立。

  • 设备证书由平台签发，可单独吊销
  • 通道绑定三要素，缺少任一项即拒绝建立
  • 用户身份与会话令牌短时效，泄露窗口有限
03

五值决策模型

「放行 / 拒绝」不足以表达真实的访问策略。ztg 的决策模型有五个取值，把「需要二次验证」「需要人工审批」「放行但要限制」都变成一等公民，策略不必为了绕开二元模型的限制而写得扭曲。

  • ALLOW / DENY / REQUIRE_MFA / REQUIRE_APPROVAL / RESTRICT
  • 每个决策携带策略版本与判定理由，可追溯
  • 限制类决策直接下发数据面与端点的执行清单
04

策略引擎与策略数据分离

把授权规则放进代码仓库，意味着每次调整都要过一次发布；把判定引擎放进数据库，意味着没人能审出「这次访问为什么被放行」。ztg 把两者拆开：引擎是版本化的策略代码，租户策略是可版本化、可干跑、可回滚的数据。

  • 引擎与策略数据版本号强制对齐，不匹配即拒绝评估
  • 策略发布前可干跑，看到结论变化再决定是否生效
  • 完整版本历史与一键回滚
  • 策略缓存失效走推送通道，撤销即时生效
05

数据防泄漏与访问控制同源

访问控制和数据防泄漏如果分成两套系统，就会出现「放行了但没管住」的缝隙。ztg 让两者共享同一套策略：授权评估在给出结论的同时，按数据分类与动作产出限制清单，由端点侧执行。

  • 限制项：禁下载 / 禁打印 / 禁剪贴板 / 禁截屏 / 禁 USB / 强制水印
  • 深度内容检测走异步镜像通道，不拖慢转发路径
  • 命中严重策略时可异步撤销会话或设备
06

网络隐身

业务资源不向公网开放监听端口，攻击面收敛到网关本身。未通过授权的连接请求不会到达后端，端口扫描看不到可用服务——这是「先认证、后连接」的直接结果，不是额外的防护插件。

  • 业务系统无需暴露公网入口
  • 未授权连接在网关侧终止，不触达后端
  • 对内网横向移动同样生效
04 / 策略运营

改一条策略，不用发一次版本

判定引擎是版本化的策略代码，租户策略是控制面里的数据。调整授权规则走控制面，带完整的安全闸门。

  1. 草稿 策略改动先在草稿态编辑，不影响线上判定。
  2. 校验 结构、引用与语义检查，不合法的策略无法进入下一步。
  3. 干跑 对真实请求重放，看到结论变化再决定是否生效。
  4. 发布 生成新版本，通过推送通道让各网关的决策缓存失效。
  5. 回滚 保留完整版本历史，任意版本可一键回退。

引擎与策略数据的版本号强制对齐。 控制面把策略文档编好下发，引擎拿文档里的版本号跟自己那份比对，不相等即拒绝评估——防止新版引擎配旧版策略文档，两边互相看不懂。

05 / 管理控制台

给运维和审计的界面

控制台走统一身份认证登录，按角色划分权限。所有写操作都有审计记录。

  • 管理员

    身份、设备、资源、会话的完整管理权限

  • 策略管理员

    策略编辑、校验、干跑与发布

  • 审计员

    只读访问决策记录与操作日志

控制台只做控制面编排：查看状态、编辑策略、管理身份与设备。它不参与数据转发，也不接触业务流量。

想看看这套决策模型落在你的策略上是什么样？

带上你现有的访问规则，我们做一次映射，看看哪些能直接表达、哪些需要拆开。

预约演示 查看架构