场景解决方案 · WEB-ITDR
业务访问
与身份防护
登录成功不代表访问可信。Web ITDR 接在业务入口上，把每一次访问放回账号、设备与会话的上下文里，判断它与该身份的既有行为是否一致，并按接入方式给出可执行的处置。
The Problem
用的是真账号，走的是正常入口
业务系统的登录与请求，在应用层看上去大多是合法的：账号是真的，密码是对的，请求也不带攻击特征。认证系统与请求层防护各管一段，中间那一段——「这次访问是谁、从什么设备和会话发起、和以前有什么不一样」——没有系统负责。
Where It Applies
三类 Web 入口，用同一套身份口径接入
覆盖对象是「通过 Web 或 API 发生的访问」。三类入口的接入方式相同，关注的问题不同——先确认要纳入哪一类，再决定接入方式。
- SSO 单点登录与 IAM / IDaaS 门户
- 自研认证服务与 OAuth2 / OIDC 端点
- 目录服务对外暴露的 Web 登录页
- OA、财务、邮件、CRM、ERP 等内部业务
- 面向客户的 Web 应用与移动端后台
- 对内与对外开放的业务 API
- 堡垒机、虚拟化平台与云管理控制台
- 容器编排平台与运维监控系统
- 数据库管理台与安全设备的 Web 界面
第三类说的是通过 Web 管理界面发生的那部分访问。端点内部的凭据活动、跨主机的远程执行与横向移动不在本方案范围，属 E-ITDR，见凭据滥用与横向移动防御。另外，可见字段的范围随接入方式变化：旁路镜像以观测为主，反向代理才具备执行访问策略的条件。
How It Works
一次访问从进入到留痕，中间发生了什么
下面这条链路是反向代理模式下的完整过程。旁路镜像模式走同样的识别与判断，只有处置那一段需要外部系统联动完成。
| 一次访问事件中的字段组 | 这一组用来回答什么 |
|---|---|
| 账号 | 业务系统登录账号与所属组织——这次访问挂在谁名下 |
| 设备与客户端 | 设备标识、客户端类型与请求特征——从什么东西上发起 |
| 会话 | 会话建立时间、来源与后续访问序列——进来之后做了什么 |
| 判断依据 | 触发的规则或特征，以及关联到的其他访问——为什么判为异常 |
| 处置结果 | 在代理防护条件下执行的动作与记录——做了什么、结果如何 |
结构说明，不是产品界面截图。实际可见的字段范围随接入方式与版本不同；旁路模式下最后一行记录的是告警与处置建议，真正的阻断需要由身份系统或网络侧完成。
Division of Responsibility
和现有的 IAM、WAF、SIEM 各做各的那一段
本方案补的是「访问主体判定与身份化证据」这一层，不替代已有投入。下表按环节写清楚谁做什么，也写清楚哪些动作本方案不做。
| 环节 | Web ITDR | 由现有系统负责 |
|---|---|---|
| 账号与授权管理 | 不做账号生命周期与权限授予 | IAM / SSO：账号、角色、授权与 MFA 策略 |
| 认证 | 观测认证过程与结果，识别异常登录 | IAM / SSO：完成认证本身 |
| 请求层攻击防护 | 检测与身份相关的 Web 攻击行为 | WAF：通用漏洞利用与规则防护 |
| 访问主体判定 | 区分人与自动化访问，关联账号、设备与会话 | 通常没有对应系统，这是本方案补的一层 |
| 处置执行 | 在代理链路上放行、验证或拦截 | 密码重置、MFA 提升、账号停用由身份系统执行；网络封禁由网络侧执行 |
| 告警汇聚与工单 | 输出身份化的告警与证据 | SIEM / SOC：跨系统汇聚与统一研判 |
| 端点侧行为 | 不覆盖 | EDR 与 E-ITDR：端点进程、凭据活动与横向移动 |
右侧一列写的是通常由谁承担，不构成对这些系统的能力评价，也不是产品对比。实际分工按客户既有架构确认；某些环节可能由同一套平台承担多项职责。
Rollout
先确认环境，再决定从哪一侧接入
按「确认环境与场景 → 小范围接入验证 → 按结果扩展」推进。两种模式可以在同一环境里分阶段使用：先旁路看清楚，再对确定要处置的应用改成代理。
- 梳理要纳入的应用、认证入口与 API
- 确认网络路径、TLS 终止位置与身份字段可见性
- 约定第一批验证场景
- 反向代理串联：具备执行访问策略的条件
- 旁路镜像：不介入业务链路，以观测告警为主
- 同一环境可按应用分别选择
- 先接一到两个应用
- 核对身份字段是否完整、告警是否可解释
- 确认策略动作与对业务的影响
- 扩展到其余应用与认证入口
- 沉淀策略与处置动作清单
- 与 SIEM、工单系统对接
| 项目 | 反向代理串联 | 旁路镜像 |
|---|---|---|
| 在链路中的位置 | 位于访问路径上 | 复制流量，不在访问路径上 |
| 对业务的介入 | 参与请求转发 | 不介入业务链路 |
| 可执行的处置 | 放行、验证、拦截等访问策略 | 以告警为主，阻断需要外部系统联动 |
| 需要核对 | 网络路径、证书与会话保持、故障预案 | 镜像点位、流量完整性、加密流量的可见性 |
| 常见用法 | 认证入口，以及需要当场处置的业务 | 可用性要求高的生产系统，或先期观测 |
两种模式的可见字段范围不同，接入方式变化时，检测结论的适用范围要跟着调整。具体接入方案按现场网络与业务条件确定，不存在一套适用于所有应用的默认接法。
Validation
用一次异常访问，把结论走完整
验证要看的不是告警多不多，而是一条告警能不能回答四个问题：为什么触发、依据是什么、做了什么、结果如何。四个都答得上，这条告警才是可运营的。
建议在试点前约定测试场景、时间起止、证据标准与运行条件；未完成测试前不填报效果数字。演示环境展示的是产品演示场景，用于说明证据如何支持判断，不是某一位客户的实际事件记录。
Expert Consultation
用您的一个业务入口，核对接入方式与可见字段
告诉我们要保护的应用、认证方式与网络条件，我们会给出对应的接入方案、可见字段范围与处置条件说明：
接入方式评估
反向代理与旁路镜像的取舍
可见字段核对
身份字段与请求证据的实际范围
处置条件说明
哪些动作由本方案执行、哪些由现有系统执行
飞书扫码，即可咨询