1. 课程导入与评估工程定位

企业身份权限安全评估，不是一次性的“查漏洞”，而是一项以业务风险为起点、以身份与权限控制为落点的持续性工程。它的核心问题可以概括为一句话：在正确的时间，让正确的人，以正确的方式，访问正确的资源，并且这一切可被证明。当企业规模扩大、系统数量增多、人员流动频繁时，身份与权限往往成为最容易被忽视、却最容易造成横向移动和数据泄露的攻击面。本课程的目标，是帮助你把“评估”从零散检查升级为可复用的工程方法。

一、评估的目标与边界

身份权限安全评估的目标通常分为三层。第一层是合规与基线：确认账号、角色、权限、认证策略是否符合企业制度与外部监管要求，例如是否存在长期未登录的僵尸账号、是否存在离职未回收权限、是否启用了多因素认证。第二层是风险暴露：识别高权限账号、共享账号、越权路径、权限继承链中的薄弱点，判断攻击者一旦获得某个低权限身份，能否通过权限关系到达核心资产。第三层是工程改进：把发现的问题转化为可执行的治理动作，如权限收敛、角色重构、审批流程优化、自动化回收策略。

边界同样重要。评估不等于渗透测试，也不等于单纯的账号清理。它关注的是“身份—权限—资源”三者之间的映射关系及其治理机制。评估范围需要明确：覆盖哪些系统（如 AD、LDAP、SSO、云平台 IAM、业务应用）、哪些身份类型（员工、外包、服务账号、API 密钥、机器身份）、哪些权限维度（数据权限、功能权限、管理权限）。边界不清，评估就会变成无底洞；边界过窄，又会遗漏关键风险路径。

二、从业务风险到身份权限控制的认知框架

很多团队做评估时直接从账号清单开始，结果陷入“查了几万个账号，却说不清风险在哪里”的困境。更有效的做法是反向推导：先识别业务关键资产与关键流程，再追问“谁可以访问它、通过什么身份、拥有什么权限、经过哪些审批”。这条链路把业务风险翻译成身份权限控制点。

例如，财务系统的付款审批流程涉及“制单—复核—放款”三个职责。如果同一账号同时拥有制单和放款权限，就形成了职责分离冲突，属于典型的高风险权限组合。评估时不需要遍历所有权限，而是围绕这类关键流程建立“职责—角色—权限—账号”的映射，优先检查冲突点。这样，评估结果才能直接对应业务影响，而不是一堆无法排序的告警。

三、交付物与工程化方法

评估的交付物不应只是一份“问题列表”。一份可用的评估成果至少包含四类内容：身份权限资产清单（有哪些身份、哪些权限、分布在哪些系统）、权限映射与继承关系图（谁通过什么路径获得了什么权限）、高风险账号与冲突清单（按业务影响排序）、治理建议与优先级（先做什么、谁来做、做完如何验证）。

工程化方法的关键在于“可重复”。一次评估如果依赖某个专家手工导出数据、手工比对，就无法持续。更合理的做法是：定义数据采集接口（如从 AD 导出用户与组、从云平台导出 IAM 策略、从业务系统导出角色分配），建立映射模型（身份—角色—权限—资源），设定判定规则（如“同一账号同时拥有制单与放款权限”判定为高风险），最后把结果接入工单与变更流程。这样，评估就从“项目”变成了“能力”。

四、评估与日常安全运营的关系

身份权限评估不是孤立动作，它与日常安全运营形成互补。日常运营关注实时告警与事件响应，评估则关注“结构性问题”：权限模型是否合理、生命周期管理是否闭环、高权限是否被过度授予。评估发现的系统性问题，应转化为运营规则或自动化策略，例如“离职后 24 小时内回收所有系统权限”“服务账号密钥每 90 天轮换”“高权限账号必须启用多因素认证”。

同时，评估需要与变更管理联动。新系统上线、组织架构调整、外包人员入场，都会改变身份权限关系。如果评估只在年初做一次，年中就会失效。更现实的做法是：把关键权限变更事件作为再评估触发器，让评估结果始终反映当前状态。

五、本课程的学习路径

后续章节将围绕这条主线展开：先建立身份权限的资产视图与映射方法，再深入认证、授权、特权账号、生命周期管理等具体领域，随后进入数据采集、风险判定、治理方案设计与效果验证。每一节都会尽量给出可操作的参数、判断依据和示例成果，帮助你不仅“知道要评估”，而且“知道怎么评估、怎么落地”。

在开始之前，请先记住一个判断标准：好的身份权限评估，最终要能回答“谁在什么条件下可以访问什么，以及我们如何证明这一点”。如果评估报告无法回答这个问题，它就还停留在清单层面，没有形成真正的工程能力。