关于
ztg 想解决的是一个具体问题
企业网络的传统边界已经失效，但替代它的方案大多只是把边界挪了个位置。ztg 的做法是把「能不能访问」这个问题从网络拓扑里拿出来，交给身份、设备与策略共同回答。
01 / 定位
不做网络，做访问决策
ztg 不试图重新设计企业网络，也不试图取代既有的身份源与业务系统。它做一件事：在每一次访问发生之前，给出一个有依据的结论，并且保证这个结论被真正执行。
这件事听起来简单，难在两处。第一处是决策依据要足够完整——只看身份会漏掉设备， 只看设备会漏掉环境，只看环境会漏掉资源本身的敏感度。第二处是结论要被真正执行—— 写在文档里的策略和拦得住人的策略，中间隔着整套工程实现。
ztg 把这两处拆成两个独立的平面来做：控制面负责把决策做对，数据面负责把决策做快。 两边不共享运行时状态，因此可以各自演进，也不会互相拖垮。
02 / 原则
十条工程约束
这些是硬约束，不是设计倾向。它们存在的意义是：当系统在演进中面临「这样更快但会破坏边界」的选择时，答案已经写好了。
- 授权决策服务只做决策，不处理数据包。
- 代理层只做转发，不实现业务授权逻辑。
- 两者用标准接口对接，不改动代理源码，也不另造协议。
- 只有新连接进入授权路径；已建立的连接直接转发。
- 数据路径不访问控制面、数据库或缓存。
- 策略引擎只在授权决策时被调用，不进入转发路径。
- 深度内容检测走异步镜像通道，不拖慢正常转发。
- 客户端界面层只做控制面编排，不进入数据路径。
- 加密通道强制绑定用户、设备、会话三要素，缺一不可。
- 授权失败一律拒绝，不降级放行。
03 / 现状
做到哪一步了
把已完成和推进中分开写，比笼统说「已支持」更有用。
已实现并验证
- 控制面：身份、设备、资源、会话、策略与审计
- 授权决策服务：会话校验、上下文富化、策略评估
- 策略引擎：五值决策模型、默认拒绝骨架、数据限制规则
- 网关：代理配置、透明重定向与网络层脚本
- 客户端 SDK：五个平台的接入与端点侧限制执行
- 管理控制台：按角色的控制面编排界面
推进中
- 深度内容检测的独立服务实现（关键词、正则、指纹）
- 授权决策服务的多实例高可用部署
- 跨环境部署的自动化与回归检测
04 / 联系
怎么找到我们
商务与技术咨询：contact@zfsg.cn