为何客户总要求应用通过AD创建账号、依托AD安全组做安全管控？

从单应用的开发、维护成本角度算，接入AD的投入性价比确实不高——毕竟已经有成熟的本地角色机制、有应用专员负责权限配置，额外对接AD接口、适配域账号认证逻辑确实要额外花开发和维护成本。但所有RFP提的要求，从来不是站在单个应用的投入产出角度设计的，而是站在采购方全组织的安全、合规、运维视角提出的硬约束，具体原因有这几个：

具体强制要求的底层逻辑 #

• 合规审计的一票否决要求
  目前主流的等保、ISO27001、SOC2等合规框架，对账号管理的核心红线就是账号全生命周期可溯源、权限变更全留痕、离职人员账号即时失效。应用本地账号模式天然存在审计盲区：用户在应用内创建的本地账号，无法和HR的入转调离流程打通，极易产生无人管控的僵尸账号；应用专员零散配置的权限，也无法形成全链路的变更日志，一旦审计需要回溯“某用户某时间的权限是谁授予的”，根本拿不出完整的证据链，这类问题在审计环节是直接判定不合格的，没有任何通融空间。
• 全组织运维成本的摊薄逻辑
  对拥有几十上百个内部应用的企业来说，每个应用单独管账号、单独走权限申请流程的长期运维成本是天价：员工入职要在每个应用单独申请账号、员工离职IT要挨个应用排查销号、员工记几十套账号密码带来的密码重置工单成本，这些隐性成本远高于让所有应用统一接入AD的一次性改造成本。
  接入AD之后，企业可以实现一次配置全链路生效：入离职流程和AD账号绑定，AD侧账号状态同步后所有下游应用自动适配；AD安全组的权限规则标准化，比如“市场部数据导出权限”对应的安全组挂载到所有应用后，只要组内人员匹配，权限就自动生效，不需要每个应用重新搭建一套角色映射规则。
• 整体安全风险的兜底要求
  应用本地存用户凭证的模式本身就是高风险攻击点：一旦应用数据库被拖库，所有存储在应用内的用户密码就会直接泄露。接入AD之后，应用不需要存储用户的明文凭据，认证逻辑全部交由AD统一层处理，直接砍掉了应用侧的大量攻击面；同时AD侧可以统一强制MFA验证、密码复杂度校验、异常登录检测，这些安全能力如果让每个应用单独实现，单应用的开发和维护成本会高到无法接受。
• RFP模板的路径依赖
  多数甲方撰写RFP的安全要求时，不会针对单个应用的现有能力做定制化调整，而是直接套用踩过坑形成的通用安全模板——之前因为应用不接AD出现过僵尸账号越权、凭证泄露、离职人员违规访问的事件，索性直接把“必须基于AD实现账号创建、必须依托AD安全组做安全管理”写成硬性门槛，从源头避免后续落地再补安全窟窿。

内容的提问来源于stack exchange，提问作者Bob