网络通了但权限边界不清
通过代理或网关到达应用，不意味着用户已通过应用认证或获得业务授权。
场景解决方案 / 云端与内网数据连接解决方案
企业内网应用安全接入（网关 / 零信任 / 沙箱）
梳理人员或流程访问内网应用的身份、网络和应用校验链路，再确认各组件责任。
数犀集成平台、企业网关、零信任或沙箱的职责需要按实际部署拆分，不能将第三方能力归为数犀平台。
客户问题
打通内网访问时，连通、认证和业务授权不能混为一谈
链路中的每一层都要知道访问主体是谁、能到达哪里，以及由谁处理故障。
多组件同时参与却缺少责任图
网关、身份源、沙箱和业务应用的策略各自配置，异常时难判断是哪一环拒绝或失效。
整体思路
按访问路径拆分身份、网络与应用侧校验
先明确用户或流程、目标内网应用和现有安全组件，再绘制访问路径。数犀只承担经核实的身份或集成环节；网络通道、安全策略和应用业务权限由客户及对应组件管理员批准和维护。
- 01访问主体确认用户或服务身份
- 02企业安全组件按批准策略建立网络路径
- 03数犀（如适用）处理已确认的身份或集成步骤
- 04内网应用完成自身认证和业务授权
网关、零信任、沙箱、终端安全或故障切换能力均须注明提供方和版本；本页不把组合方案写成数犀单体产品。
核心任务
画清从入口到应用的责任链 · 验证允许、拒绝和故障路径
01 / 画清从入口到应用的责任链
为每一跳标注身份和策略
- 01入口与身份源确认访问人及认证方式
- 02网络组件标明网关或受控通道
- 03业务应用确认应用侧角色和数据权限
原来怎么处理
员工能够访问应用后，项目团队不清楚认证由哪个组件完成、流量经过哪些网络边界。
数犀如何处理
由企业网络、安全和应用团队共同绘制入口、身份源、网关或安全组件、数犀处理环节和目标应用；未确认组件由谁提供前不定义为数犀交付。
选择一个测试用户，从入口逐跳核对身份、网络策略、网关记录和应用角色，确保每个环节的实际负责方可辨认。
希望带来的变化
形成一张可执行的接入责任图，避免把网络连通当作全链路安全验收。
相关能力访问路径评估身份源衔接（范围待核验）连接流接入（如适用）
02 / 验证允许、拒绝和故障路径
确保异常时不扩大访问
- 01批准测试账号覆盖允许和禁止访问
- 02逐段检查确认策略命中与日志责任
- 03故障演练测试组件异常后的处理方式
原来怎么处理
系统只验证正常访问，未测无权账号、凭据过期或网关中断，风险路径无人负责。
数犀如何处理
在批准范围内测试允许与拒绝请求，检查身份、策略命中和应用响应；组件不可用时按客户安全方案关闭、降级或交由运维处理。
验证未授权用户被拒绝、凭据失效、目标应用无角色及安全组件中断；记录日志位置、告警责任人和恢复动作。
希望带来的变化
同时验证访问能否成立和不应访问时能否阻断，避免为“打通”而弱化控制。
相关能力策略联调拒绝路径测试故障与责任核验
改善与验证
用测试账号逐段核验访问与拒绝路径
选择一个内网应用，和企业安全团队、应用管理员联合验收。
| 常见处理 | 希望实现的变化 | 试点检查方法 |
|---|---|---|
| 访问链路责任不清通过代理或网关到达应用，不意味着用户已通过应用认证或获得业务授权。 | 希望实现的变化身份、网络策略与应用授权分别有明确提供方。 | 试点检查方法对照链路图实测一次访问，确认每段的认证对象、日志和责任团队。 |
| 异常时访问边界失控网关、身份源、沙箱和业务应用的策略各自配置，异常时难判断是哪一环拒绝或失效。 | 希望实现的变化无权用户或关键组件故障时按约定阻断或转入安全处理。 | 试点检查方法测试未授权、凭据过期和组件不可用，确认不会绕过应用侧权限。 |
在取得明确的组件分工、部署和验收资料前，本页只作为待评估场景；不宣称数犀独立提供完整零信任、沙箱或网络安全能力。
