近期想抽空聊点东西，忽然想起了前两年搞过的统一身份管理方案。个人以为这个对于业内日趋严格的标准化工作的推进，还是有点参考意义的。

一、概念解释

这里聊的统一身份管理方案，主要是指认证Authentication、授权Authorization、账号Account、审计Audit。

前几年做架构安全的时候，也做过认证/鉴权管控相关的治理项目。

那会儿是致力于架构整体治理出发，通过发掘中台脆弱性的方式，执行安全管控的整改子项。

现如今的各个重要行业，由于稽核监管风险驱动，加强重要系统的认证鉴权的安全标准化已是必选项。

正好朋友小Y之前在做专项治理的时候，跟我有过很多思路交流，所以治理的过程也有不少我给的idea。

这里他跟安全大老板取得了授权后，同意我拿他们的案例做个大致评述。

1、帐号（account）

一套合理的账号体系，需要强健的帐号密码策略、恰当的生存周期、便利的权限管理等等。

在复杂的情况下，业务方不仅有基础需求，还可能需要支持平台租户、多套体系并存等等。

2、认证(authentication)

认证解决方案不仅需要从便捷度考虑，实现用户认证的统一管理，以及信息资源访问的单点访问。

还需要2FA（2 Factor Authentication）乃至MFA（Multi-factor authentication），从多维度提升认证的强度。

3、权限(authorization)

通过元数据资源为支撑，实现对B/S、C/S应用系统资源的访问权限控制。

它可以是基于角色、组、接口、数据，也可以是基于平台租户乃至更多的需求，业务复杂度决定了权限管控需求的上限。

4、审计(audit)

将用户敏感操作日志和流量进行记录分析，不仅可以对风险行为进行实时监控，而且可以通过后期审计进行数据挖掘，完成事后安全事件的追溯。

二、现状剖析

上边简单聊完了概念，那么我们该谈谈针对现状的剖析了。

1、非标系统枚举

朋友小Y公司属于某央企子公司，这里姑且称之为Y公司，由于历史原因，有不少非标系统亟待处理。

1）外购系统

为了节省研发成本，Y公司不少重点项目采用了外购系统，这就有几个坑。

• 维保过期改造成本高：

合同维护也有过期的时候，供应商也无法第一时间处置安全整改问题，这样就很难持续有效保障。

• 无合同协议约束：

虽然目前认证/鉴权等选项，目前已经加入了安全评审的准入流程，但是之前很多存量产品的商业协议是没有这项的。

2）第三方系统

Y公司有部分第三方合作系统，这种是合作方供应商寄放在他们机房。

合作方多半是国企/央企/事业单位，没有研发迭代支持，只有使用支持。

如果是重要系统是万年不敢动的，出了问题让供应商兜底也不现实，况且版本统一也没法改。

3）开源系统

一些基础平台或者中间件，多半了采用开源系统，或者只是简单做二次开发。但是这类系统如果不单独投入可靠的人力的话，也很难做标准化的改造。

4）老旧系统

在稍微有点历史的单位，可能都会存在一些无法改造，又不能短期内下线的系统。这种系统每次在安全审计时都看着头大，但也不是所有场景都能走特殊例外流程。

2、风险修补

对于非标系统的现状，除了完整的体系化方案以外，我们还可以做一些修补方案。

1）元数据打标

梳理能够接入标准化方案的存量系统进行打标，后续的增量系统，则需要通过提醒研发申报以及自动化巡检的方式进行更新。

主要打标需求有：

（1）是否接入SSO认证

这是系统风险评估的重要环节，接入了认证才能纳入完整的统一身份管理方案，如果除了接入SSO还需要保留原有认证入口，那就需要标记为“并存”。

数据打标建议可选项：是/否/并存。

（2）是否涉及权限分级

首先，这类系统可能会出现越权漏洞，所以这个字段也是自动化扫描规则，以及人工安全测试覆盖的依据。

其次，这类系统如果涉及复杂的权限模型，自建一套权限体系成本高，而且对安全/风险团队是不透明的，不做好打标在审计和溯源的时候会走不少弯路。

数据打标建议可选项：是/否。

（3）是否接入权限管控

这是针对上一项“是否涉及权限分级”的补充，涉及权限分级的系统如果没有进行标准化管控，也是具有风险的。

数据打标建议可选项：是/否/自建。

（4）是否接入操作行为审计

诚然在溯源系统时，进行操作行为审计的成本不算高。但是如果不针对安全告警的日志/流量用心进行日常建设，出事了是个很废人的活儿。

所以对于没有接入操作行为审计的重要系统，需要根据打标情况推动覆盖。

数据打标建议可选项：是/否。

（5）是否涉及合作方账号

如果内部账号出现风险，我们能很容易的定位到人/IP/设备。

但是如果涉及到合作方账号，比如集团总部/子公司/供应商/ZF单位等等，我们很难在第一时间进行有效溯源定位，那对于这种场景我们就需要考虑额外附加其他策略。

数据打标建议可选项：是/否。

2）暴露面防护

（1）堡垒机/VPN/远程桌面

从通道层面进行保护，可以缩小暴露面，进一步完精准控制。

这样类似于在统一身份管理方案外又套了一层壳子，不过缺点就是成本相对比较高。

（2）白名单/物理隔离

白名单一般指的是IP/端口白名单，属于常用的应急处置方案。

物理隔离属于高密级系统才采用，不过针对越来越盛行的HW行动来看，防控策略严格点也没什么毛病。

（3）规避办公网直接访问后端接口

如果我自己作为攻击方/黑客打进来，估计首先考虑搞的就是办公网。

但是系统如果不存在认证/鉴权的话，建议审慎开放给办公网的用户。

因为没有有效监控审计的手段的情况下，这相当于给攻击方/黑客留了一道后门。

生产机器的安全策略一般会比较严格，测试服务器也没啥东西，但是办公网PC拿1day一打一个准正好。

办公网PC是可能存在访问系统的白名单的，上面也保存了不少敏感信息，对攻击方/黑客是比较友好的，只不过在控制机器时得注意下杀软和终端监控。

三、方案设计

在实际情况下，我们需要因地制宜进行改造，借助统一身份管理方案进行安全强化。

1、认证管控

• 痛点现状：

针对非标类系统，无法很好的兼容或者接入SSO认证体系；针对标准系统，接入SSO认证体系的也有很多不规范的案例。

• 治理方向：

完成标准化的认证改造，保障基础安全策略，创建可信的体系。

1）认证改造

要求自家研发或者供应商做支持，加入对现有SSO认证体系的支持。

当然这个是成本最高的，原有登录体系可以不废弃作为降级使用，但是要求操作需要对接安全中台进行审计，纳入可控管制。

2）策略管控

通过下发制度规范，要求让研发进行整改，直至系统的基础安全策略符合安全的标准。

这属于管理层面的方案了，但是确实行之有效。能通过人力分派解决问题，也不失为一种好的方法。

3）证书验证

在内网建立可信的证书签发机制，采用证书中心进行统一验证，通过以后才能进行可信交互。

之前在研究Google的方案的时候觉得比较有意思，但是考虑到即使在内网实施也成本较高，所以只能排在中长期规划里去做。

4）认证隔离

目前Y公司内的SSO认证比较复杂，如果不完成存量的认证隔离，后面的治理工作会更麻烦。

（1）内网/外网

前面提到Y公司属于央企子公司，其集团总部也是有一套通用SSO认证的。

由于有部分系统是需要作为开放平台，提供给集团总部和其他子公司访问的，还有部分系统是业务需求必须放到公网的。

所以在治理环节，需要重点推动集团总部SSO认证覆盖外网的系统，而Y公司内网系统则推动自家SSO认证覆盖，如有必要推动双重SSO接入兼容。

（2）生产/测试

Y公司目前的系统环境有多种，但大致都可以纳入生产/测试两套内部SSO进行认证管理。

但是部分系统具有特殊性，可能并未严格按照环境要求进行隔离。生产环境的系统为了方便，违规装在了测试环境。

测试环境的权限安全级别一般放的比较开，这种情况显然对于生产数据的保护是很不利的，所以需要单独进行梳理和隔离。

实际情况里，并非所有的系统都能进行理想状态的区分。

部分系统由于本身属于工具平台类系统，需要跟生产/测试环境进行互通。而有的系统属于非标系统，也无法进行代码层面的改造。

所以这类特殊的场景，那就可以考虑从暴露面做隔离防护。

2、账号管控

• 痛点现状：

Y公司的账号体系比较复杂，除了自身的基础账号体系，还需要对接集团总部和其他子公司以及合作方，难以对账号管理完成标准化处置。

• 治理方向：

推动非标系统的改造，加强对合作账户体系的数据适配，完善针对账号密码的管控。

1）数据同步

针对有一定用户量又不容易改造的系统，不可能只使用原有账户体系，这样出现生产事故的话不易进行追溯。

如果确实无法接入统一身份管理方案，可以考虑把元数据平台的必需用户同步到本地，独立维护一套影子账户体系，这样的方案也相对更加轻量级。

2）认证并存

对于存在特殊需求的系统，原有账户体系无法在短期内抛弃，但又可以进行部分研发改造的。

那我们可以通过维持两套认证并存的方式，对外开放使用SSO认证，必要时进行降级本地认证，但需要注意的是：

（1）原有账户体系需要遵循基础安全策略。

（2）认证并存的系统需要在元数据平台打标。

（3）定期对认证并存的系统进行安全审计。

3）密码策略

在针对账号管理上，需要有着严格的密码策略。

（1）密码的生命周期不得超过XX天。

（2）新密码不能与最近N次密码相同。

（3）密码只能由字母、数字、特殊字符组成，且总长度和各自位数占比需要限制。

（4）不允许出现连续N位的字母、数字。

（5）不允许使用姓名拼音、常见英文单词作为密码组成部分。

4）合作方账号

针对合作方账号，也需要加强相应的规定：

（1）合作方账号的生命周期不得超过XX天，需要通过审批后才能继续使用。

（2）合作方账号需要堡垒机/VPN下/远程桌面下使用。

（3）合作方账号单独建组管控，保持权限相对最小化。

5）共享账号

针多人共享账号的情况，也需要重点规范：

（1）加上令牌/OTP认证，限制账号混用的成本。

（2）制度明文宣导，共享账号属于违规操作。

（3）账号绑定MAC地址/IP地址，异地登录需要申报。

（4）账号单次维活不超过xx分钟。

（5）账号维活超过xx小时，必须强制重新认证。

3、权限管控

• 痛点现状：

如果你单纯只是一个工具系统，可能连鉴权机制都不需要，安全边际的界定就成了一个很头疼的问题。权限管控的需求，主要视系统复杂度而定。如果系统属于开放平台或者集权中台，可能会涉及到比较多的管控需求。

• 治理方向：

选用标准化的权限管控产品，推动有权限分级需求且存在缺陷的系统进行整改。

1）自建权限体系

对于自建权限体系的系统，需要整改到符合基础安全策略，当然也可以选择接入标准化权限管控产品。

2）涉及权限分级

如果系统涉及权限分级，那么最好的办法不是让他们自行整改，而是推动接入标准化权限管控产品。

实现权限管控统一标准化，不仅能够让风险变得透明可视，而且出现漏洞也能做到短时间统一修复。

此外，针对外部账户建立临时权限组，独立实施生命周期/角色/接口/数据访问等管控策略，能更方便IT部门进行维。这样能针对账号角色灵活赋权，又能做的相对权限最小化。

当然，选择接入标准化的权限管控产品，肯定是有其劣势的。

比如在兼容性问题上面，我们都知道任何产品都难以在生态上支撑所有应该接入的系统。

但是它可以通过本地缓存权限，以及数据同步的方式，变相为特殊情况的系统提供服务。

再比如，在权限管控产品出了漏洞以后，整个权限体系都会有沦陷的风险。

但是这种情况下，统一身份管理方案里的其他三大要素就可以站出来，起到平衡支撑的作用。

通过审计告警、认证升级、账号限制等手段，让权限体系即使短时间沦陷，也不至于落入不可控状态。

4、审计管控

• 痛点现状：

在实施统一身份管理方案时，由于运营缺乏和管控力量分散的原因，审计一直处于相对被忽视的状态。

• 治理方向：

通过丰富审计源和规则，及时发现异常的敏感信息操作行为，将监控工作落到实处。

1）操作行为日志审计

在接口层面进行代码埋点，对登录/登出及其他敏感操作行为进行记录，辅以风险审计规则进行监控，才保障在全流程中能够尽早发现异常。

2）流量监控

在标准WEB日志里没有针对HTTP BODY的记录，但是不少系统的重要信息交互，确实只能基于HTTP BODY进行通信的。

我们可以针对通信流量里进行敏感信息筛查，比如探查流量里是否有弱口令传输。

同时，针对没有认证态而又含有敏感信息的流量，也需要进行日常巡检和复核，发掘可能泄露敏感信息的CASE。

当然，如果展开来可以扩展到UEBA或者其他网络层NAT之类的标准化审计产品，但详细产品介绍不属于本文讨论范围，就不多说了。

四、落地实施

前面的内容简单讲了设计方案，但具体施行的时候，其实会遇到多样的阻力。

那么在这里就再补充下，如何把管理措施落地的问题。

在专项开始执行前，对要纳入管控范围内的系统，尽量要有清晰的处置规划。

1、合理事件驱动

我们要启动安全专项不是拍脑袋就可以做，一定要有合理的背景才能讲好故事。

这个背景可以是行业常见风险，可以是多起同质化安全事件，也可以是稽核监管要求，但一定要合情合理才能获取到领导层的尚方宝剑。

2、标准化方案先行

拿到项目启动的授权后，制定好标准化方案是必不可少的，可靠的测试验收报告也是重要背书一。

此外，还需要经过多方权威评审授权，确认该方案能够具备推行的条件。

3、异常场景处置

如果出现无法整改的场景，应该纳入什么样的整改目标，应当进行怎样的流程处置，都是需要思考的。

当然在前期规划阶段，肯定存在无法预见的困难。但是只要有适当的应急预案，在有需要的时候也能很快的确认处置方案。

4、制度规范跟进

在内部进行专项治理，需要有制度规范做依据，针对权限管控标准化作为指导方针，需要有明确的条款要求。

如果没有现成的条款的话，就需要向相关领域负责人申请授权修订，并依照最终条款进行立项实施。

5、专项拆解

1）分期执行

对于复杂现状，做治理不能期待一步改造到位，需要分期执行做敏捷迭代。

（1）前期

主要花精力在试点系统整改指导上，周期可能会比预期稍长。在这个阶段需要着重收集研发反馈，进行流程和方案优化。

（2）中期

已经积累了相对成熟的经验和方案，属于快速改造期。在这个阶段主要把标准化方案推广可控的范围内，进行标准化收尾工作。

（3）后期

系统标准化改造差不多到了瓶颈。在这个阶段主要通过流程进行收口管理，运用风险补偿措施处置剩余的系统。

（4）收口

对于已经改造完成的系统，也不是一劳永逸。需要通过定期抽样的形式进行例检，核验长期工作是否符合标准的安全策略，如果有出现纰漏的系统同样会被要求继续进行整改。

2）领域分工

（1）建立虚拟委员会

委员会需要加入相关团队的接口人和Leader，通过实现A/B角色互为backup，保障执行通道的顺畅。

（2）建立周例会机制

定期核对项目进度，适时对遇到的困难进行处置方案讨论。在遇到不可抗拒的阻力的时候，上报领导层申请更多的资源和授权许可。

（3）建立实施负责人机制

对于粗粒度的关键技术方案，也需要我们定期跟进评审验收。如果实施过程中出现偏差或者需要改进，也能短期内进行轨道修正。

（4）安排专员对接

每个业务线安排专员对接，定期统计上报进度数据，传达业务和研发的诉求。

同时，专员需要及时向研发反馈项目组给出的难点解决方案，重点宣导新的工作内容。

6、多维度驱动

1）自上而下推动

项目关键节点最好是自上而下进行推动，有了各领域负责人的支持，研发执行效果至少可以达到合格水准。

2）稽核监管压力

内部稽核和外部监管，会定期下发材料问询。即使研发在实施过程中存在问题，也至少会保证整改到稽核监管认可的程度。

3）硬性指标考核

通过汇报立项，争取加入研发线年度考核。利用绩效系数切实驱动研发保障实施的质量，从而对最终结果进行有效把关。

4）层层问责

如果项目实施过程中，出现交付延期、质量失衡、执行不配合，需要通过逐级问责机制，将处罚落实到自然人个体。

五、结语

以上就是针对统一身份管理方案的解析实施了，由于涉及到的面有些广，针对特定技术方案的设计描述可能没那么详细。

后面如果有机会碰到更有意思的内容会继续更新，谢谢！