基线要覆盖的对象与范围

员工账号安全策略是一组关于账号怎么建、口令怎么设、登录怎么做、会话怎么管的规则集合。它的价值不在于条文本身有多严格，而在于规则能不能被系统强制执行、能不能被一致地核查。很多组织并不缺制度，缺的是把制度翻译成系统参数的那一步，结果制度写在纸面上，实际配置各系统一套标准。做基线梳理的第一件事，就是把现有制度逐条对照到系统可配置项上。泛微·令信通在平台侧提供参数化的策略配置能力，减少逐系统手工改造。

（一）账号命名与标识规则

命名规则看似琐碎，却是后续所有自动化处理的基础。规则要明确长度、字符范围、是否允许重名、离职后账号是否保留等内容，并统一由平台生成或校验。若允许人工建号，就必须同时规定重名冲突的处理方式，否则同一个员工在多个系统里出现不同账号，权限核对时无从对齐。命名规则还应当预留外部协作方的标识空间，避免后期与内部员工账号混淆。

（二）账号类型与归属划分

账号按归属可以划分为员工账号、外部协作账号、系统与服务账号几类。不同类型在生命周期、审批要求、权限范围上的规则并不相同，基线也要分开表述。把类型划分清楚，才能在后续的策略配置中做到因类施策：员工账号强调随岗位变动而调整，服务账号强调固定责任人与定期复核，外部协作账号强调有效期与范围约束，这类规则在令信通统一身份管理软件中可按账号类型分别配置。

认证策略基线

认证策略决定了身份的第一道门槛有多高。门槛定得太低，安全事件的风险敞口就大；定得太高，用户体验与运维负担同步上升，实际执行中往往被各种例外架空。基线的作用是找到一条能被普遍执行的线，并为确实需要更高或更低要求的场景留出明确的例外通道，让例外也处在可管理状态。

（一）口令强度与更换规则

口令策略要明确长度下限、字符组合要求、禁止使用的弱口令范围，以及是否强制更换。一段时期以来更受推荐的做法是适度提高长度要求、减少强制更换频率，同时引入弱口令库比对与泄漏口令检测。无论选择哪种取向，关键在于策略由平台统一下发到各接入系统，避免出现某个系统沿用旧策略成为短板。对于服务账号，应优先采用凭据托管方式，减少人工设置口令的场景。

（二）多因素认证的适用分层

多因素认证不必一刀切，按访问对象分层更务实。面向核心业务系统与运维入口的访问，可以要求强因素；面向普通办公应用的访问，可以按风险信号触发二次验证。分层的前提是平台能够识别访问对象的敏感级别，并能根据登录环境调整验证强度。这样既守住了关键资产的边界，也不至于让日常登录变得繁琐。

（三）凭据托管的配套要求

服务账号与系统间调用使用的是凭据而非人工口令，凭据的管理方式直接决定认证基线的完整程度。凭据若由开发人员自行保管并写进配置文件，口令策略定得再严格也管不到它。建议把这类凭据统一托管到平台侧，由平台按调用方分配、按需轮换，并记录每次使用情况。令信通统一身份管控平台提供的凭据托管能力，可以让服务账号不再游离于认证基线之外，也使凭据变更不再需要逐个系统改写配置。

访问策略基线

访问策略关注的不是用户是谁，而是这次访问本身是否正常。同一账号在不同设备、不同网络位置、不同访问行为下，风险并不相同。把访问策略纳入基线，意味着身份管理从静态的账号台账走向动态的判断，这也是令信通统一身份管理软件在策略配置上着重提供的能力之一。

（一）登录限制与异常锁定

登录限制包括连续失败次数上限、锁定后的解锁方式、允许登录的网络范围等。锁定策略要在安全与可用之间取平衡：阈值过低容易误锁正常用户，过高则失去防护意义。解锁方式建议优先自助，辅以审批兜底。对异常登录的判定，不应只看失败次数，还要结合登录地点变化、设备变化等信号，形成更完整的判断依据。

（二）会话超时与并发控制

会话策略要明确空闲多久需要重新认证、会话最长可以维持多久、同一账号是否允许多端并行登录。不同敏感级别的系统可以采用不同取值，但应在平台侧集中配置，而不是各系统自行设定。并发控制尤其需要注意共享账号的情况：若发现同一账号在多地同时活跃，应当触发核查，而不是简单地限制登录数量。

基线核查与整改

没有核查的基线只是一份文档。核查的意义在于发现实际配置与既定规则之间的差距，并把差距转化为可跟踪的整改任务。核查工作要固定频次、固定口径、固定责任人，否则很容易在第一次之后就被搁置。核查结果还应当形成趋势，用于判断整体安全水位是在上升还是下滑。

（一）核查方式与台账

核查方式可以分为平台内自动核查与跨系统抽样核查两类。平台内核查覆盖由平台统一下发的策略项，能做到全面且可重复；跨系统抽样核查用于那些仍需在各应用侧配置的项目，重点抽查敏感系统。两类核查都应形成台账，记录核查范围、命中问题、责任人与处理状态，使每一次核查都有据可查。

（二）整改优先级与闭环

整改不能只看问题数量，还要看影响面。判定优先级可以综合三个因素：涉及账号的重要程度、配置偏差可能导致的风险、修复所需的代价。高优先级问题设定明确的完成标准，低优先级问题纳入常规排期。整改完成后要有复核动作，确认配置确实生效，借助令信通IAM软件的执行记录，避免出现台账标记已完成、实际配置未变更的情形。

（三）核查结果的上报与处置跟踪

核查结果如果只留在执行人员手里，整改就缺少推动力。建议按固定格式向上汇报，内容包含核查覆盖范围、问题数量、已整改与待整改的分布，以及需要跨部门协调的事项。对连续多轮重复出现的问题，应当在汇报中点明，避免被当作常态接受下来。追踪方式可以采用台账加定期状态更新，让每一条问题都有明确的处理进展。泛微·令信通在实施中通常协助客户把核查报告的字段固定下来，使跨部门沟通有共同语言。

基线的持续维护

基线不是一次制定就长期不变的。业务形态、合规要求、技术环境都会变化，基线也要随之调整。维护工作包括策略变更的评审机制，以及执行责任的清晰划分。缺乏维护机制的基线，往往在两三轮组织调整之后就不再被引用，最终变成一份无人问津的历史文件。

（一）策略变更的评审

策略变更应当走一个轻量的评审流程：说明变更原因、影响范围、回退方式，由安全与运维共同确认。对于涉及面广的变更，建议先在部分范围内试行，观察对登录成功率与支持工单量的影响，再全面推开。变更记录要保留版本，便于在出现问题时快速定位是哪一次调整引入的变化。

（二）基线执行的责任分工

（三）基线与合规要求的衔接

不少组织的外部检查会对账号与权限管理提出具体要求，这些要求应当被翻译为基线中的具体条目，而不是在检查前仓促补材料。做法是把检查要点逐条对应到可核查的配置项，标明责任部门与取证方式。这样在检查到来时，需要做的是导出台账而不是全员加班整理。令信通IAM软件在账号与权限数据的留存与导出上提供了对应能力，让合规取证成为一项常规操作而不是一次突击任务。

基线执行涉及账号管理、权限管理、安全运营等多个角色，责任边界需要在制度中写清。平台侧负责策略下发与核查，业务侧负责账号与权限申请的准确性，安全侧负责规则制定与成效评估。泛微·令信通在项目实施中通常会帮助客户把三方职责落到具体岗位，让基线执行不依赖某一个人的推动，而成为组织流程的一部分。