FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。
FreeBuf+小程序把安全装进口袋
那会儿是致力于架构整体治理出发，通过发掘中台脆弱性的方式，执行安全管控的整改子项。
现如今的各个重要行业，由于稽核监管风险驱动，加强重要系统的认证鉴权的安全标准化已是必选项。
正好朋友小Y之前在做专项治理的时候，跟我有过很多思路交流，所以治理的过程也有不少我给的idea。
一套合理的账号体系，需要强健的帐号密码策略、恰当的生存周期、便利的权限管理等等。
在复杂的情况下，业务方不仅有基础需求，还可能需要支持平台租户、多套体系并存等等。
认证解决方案不仅需要从便捷度考虑，实现用户认证的统一管理，以及信息资源访问的单点访问。
还需要2FA（2FactorAuthentication）乃至MFA（Multi-factorauthentication），从多维度提升认证的强度。
通过元数据资源为支撑，实现对B/S、C/S应用系统资源的访问权限控制。
它可以是基于角色、组、接口、数据，也可以是基于平台租户乃至更多的需求，业务复杂度决定了权限管控需求的上限。
将用户敏感操作日志和流量进行记录分析，不仅可以对风险行为进行实时监控，而且可以通过后期审计进行数据挖掘，完成事后安全事件的追溯。
上边简单聊完了概念，那么我们该谈谈针对现状的剖析了。
朋友小Y公司属于某央企子公司，这里姑且称之为Y公司，由于历史原因，有不少非标系统亟待处理。
为了节省研发成本，Y公司不少重点项目采用了外购系统，这就有几个坑。
虽然目前认证/鉴权等选项，目前已经加入了安全评审的准入流程，但是之前很多存量产品的商业协议是没有这项的。
Y公司有部分第三方合作系统，这种是合作方供应商寄放在他们机房。
合作方多半是国企/央企/事业单位，没有研发迭代支持，只有使用支持。
如果是重要系统是万年不敢动的，出了问题让供应商兜底也不现实，况且版本统一也没法改。
一些基础平台或者中间件，多半了采用开源系统，或者只是简单做二次开发。但是这类系统如果不单独投入可靠的人力的话，也很难做标准化的改造。
在稍微有点历史的单位，可能都会存在一些无法改造，又不能短期内下线的系统。这种系统每次在安全审计时都看着头大，但也不是所有场景都能走特殊例外流程。
对于非标系统的现状，除了完整的体系化方案以外，我们还可以做一些修补方案。
梳理能够接入标准化方案的存量系统进行打标，后续的增量系统，则需要通过提醒研发申报以及自动化巡检的方式进行更新。
主要打标需求有：
（1）是否接入SSO认证
这是系统风险评估的重要环节，接入了认证才能纳入完整的统一身份管理方案，如果除了接入SSO还需要保留原有认证入口，那就需要标记为“并存”。
数据打标建议可选项：是/否/并存。
（2）是否涉及权限分级
首先，这类系统可能会出现越权漏洞，所以这个字段也是自动化扫描规则，以及人工安全测试覆盖的依据。
其次，这类系统如果涉及复杂的权限模型，自建一套权限体系成本高，而且对安全/风险团队是不透明的，不做好打标在审计和溯源的时候会走不少弯路。
数据打标建议可选项：是/否。
（3）是否接入权限管控
这是针对上一项“是否涉及权限分级”的补充，涉及权限分级的系统如果没有进行标准化管控，也是具有风险的。
数据打标建议可选项：是/否/自建。
（4）是否接入操作行为审计
诚然在溯源系统时，进行操作行为审计的成本不算高。但是如果不针对安全告警的日志/流量用心进行日常建设，出事了是个很废人的活儿。
所以对于没有接入操作行为审计的重要系统，需要根据打标情况推动覆盖。
（5）是否涉及合作方账号
如果内部账号出现风险，我们能很容易的定位到人/IP/设备。
（1）堡垒机/VPN/远程桌面
从通道层面进行保护，可以缩小暴露面，进一步完精准控制。
这样类似于在统一身份管理方案外又套了一层壳子，不过缺点就是成本相对比较高。
（2）白名单/物理隔离
白名单一般指的是IP/端口白名单，属于常用的应急处置方案。
物理隔离属于高密级系统才采用，不过针对越来越盛行的HW行动来看，防控策略严格点也没什么毛病。
（3）规避办公网直接访问后端接口
如果我自己作为攻击方/黑客打进来，估计首先考虑搞的就是办公网。
但是系统如果不存在认证/鉴权的话，建议审慎开放给办公网的用户。
因为没有有效监控审计的手段的情况下，这相当于给攻击方/黑客留了一道后门。
生产机器的安全策略一般会比较严格，测试服务器也没啥东西，但是办公网PC拿1day一打一个准正好。
办公网PC是可能存在访问系统的白名单的，上面也保存了不少敏感信息，对攻击方/黑客是比较友好的，只不过在控制机器时得注意下杀软和终端监控。
针对非标类系统，无法很好的兼容或者接入SSO认证体系；针对标准系统，接入SSO认证体系的也有很多不规范的案例。
完成标准化的认证改造，保障基础安全策略，创建可信的体系。
要求自家研发或者供应商做支持，加入对现有SSO认证体系的支持。
通过下发制度规范，要求让研发进行整改，直至系统的基础安全策略符合安全的标准。
这属于管理层面的方案了，但是确实行之有效。能通过人力分派解决问题，也不失为一种好的方法。
在内网建立可信的证书签发机制，采用证书中心进行统一验证，通过以后才能进行可信交互。
之前在研究Google的方案的时候觉得比较有意思，但是考虑到即使在内网实施也成本较高，所以只能排在中长期规划里去做。
目前Y公司内的SSO认证比较复杂，如果不完成存量的认证隔离，后面的治理工作会更麻烦。
（1）内网/外网
前面提到Y公司属于央企子公司，其集团总部也是有一套通用SSO认证的。
由于有部分系统是需要作为开放平台，提供给集团总部和其他子公司访问的，还有部分系统是业务需求必须放到公网的。
所以在治理环节，需要重点推动集团总部SSO认证覆盖外网的系统，而Y公司内网系统则推动自家SSO认证覆盖，如有必要推动双重SSO接入兼容。
（2）生产/测试
Y公司目前的系统环境有多种，但大致都可以纳入生产/测试两套内部SSO进行认证管理。
但是部分系统具有特殊性，可能并未严格按照环境要求进行隔离。生产环境的系统为了方便，违规装在了测试环境。
测试环境的权限安全级别一般放的比较开，这种情况显然对于生产数据的保护是很不利的，所以需要单独进行梳理和隔离。
实际情况里，并非所有的系统都能进行理想状态的区分。
部分系统由于本身属于工具平台类系统，需要跟生产/测试环境进行互通。而有的系统属于非标系统，也无法进行代码层面的改造。
所以这类特殊的场景，那就可以考虑从暴露面做隔离防护。
Y公司的账号体系比较复杂，除了自身的基础账号体系，还需要对接集团总部和其他子公司以及合作方，难以对账号管理完成标准化处置。
推动非标系统的改造，加强对合作账户体系的数据适配，完善针对账号密码的管控。
针对有一定用户量又不容易改造的系统，不可能只使用原有账户体系，这样出现生产事故的话不易进行追溯。
如果确实无法接入统一身份管理方案，可以考虑把元数据平台的必需用户同步到本地，独立维护一套影子账户体系，这样的方案也相对更加轻量级。
对于存在特殊需求的系统，原有账户体系无法在短期内抛弃，但又可以进行部分研发改造的。
那我们可以通过维持两套认证并存的方式，对外开放使用SSO认证，必要时进行降级本地认证，但需要注意的是：
（1）原有账户体系需要遵循基础安全策略。
（2）认证并存的系统需要在元数据平台打标。
（3）定期对认证并存的系统进行安全审计。
在针对账号管理上，需要有着严格的密码策略。
（1）密码的生命周期不得超过XX天。
（2）新密码不能与最近N次密码相同。
（3）密码只能由字母、数字、特殊字符组成，且总长度和各自位数占比需要限制。
（4）不允许出现连续N位的字母、数字。
（5）不允许使用姓名拼音、常见英文单词作为密码组成部分。
针对合作方账号，也需要加强相应的规定：
（1）合作方账号的生命周期不得超过XX天，需要通过审批后才能继续使用。
（2）合作方账号需要堡垒机/VPN下/远程桌面下使用。
（3）合作方账号单独建组管控，保持权限相对最小化。
针多人共享账号的情况，也需要重点规范：
（1）加上令牌/OTP认证，限制账号混用的成本。
（2）制度明文宣导，共享账号属于违规操作。
（4）账号单次维活不超过xx分钟。
（5）账号维活超过xx小时，必须强制重新认证。
如果你单纯只是一个工具系统，可能连鉴权机制都不需要，安全边际的界定就成了一个很头疼的问题。权限管控的需求，主要视系统复杂度而定。如果系统属于开放平台或者集权中台，可能会涉及到比较多的管控需求。
选用标准化的权限管控产品，推动有权限分级需求且存在缺陷的系统进行整改。
对于自建权限体系的系统，需要整改到符合基础安全策略，当然也可以选择接入标准化权限管控产品。
如果系统涉及权限分级，那么最好的办法不是让他们自行整改，而是推动接入标准化权限管控产品。
此外，针对外部账户建立临时权限组，独立实施生命周期/角色/接口/数据访问等管控策略，能更方便IT部门进行维。这样能针对账号角色灵活赋权，又能做的相对权限最小化。
当然，选择接入标准化的权限管控产品，肯定是有其劣势的。
比如在兼容性问题上面，我们都知道任何产品都难以在生态上支撑所有应该接入的系统。
但是它可以通过本地缓存权限，以及数据同步的方式，变相为特殊情况的系统提供服务。
再比如，在权限管控产品出了漏洞以后，整个权限体系都会有沦陷的风险。
但是这种情况下，统一身份管理方案里的其他三大要素就可以站出来，起到平衡支撑的作用。
在实施统一身份管理方案时，由于运营缺乏和管控力量分散的原因，审计一直处于相对被忽视的状态。
通过丰富审计源和规则，及时发现异常的敏感信息操作行为，将监控工作落到实处。
在标准WEB日志里没有针对HTTPBODY的记录，但是不少系统的重要信息交互，确实只能基于HTTPBODY进行通信的。
我们可以针对通信流量里进行敏感信息筛查，比如探查流量里是否有弱口令传输。
同时，针对没有认证态而又含有敏感信息的流量，也需要进行日常巡检和复核，发掘可能泄露敏感信息的CASE。
当然，如果展开来可以扩展到UEBA或者其他网络层NAT之类的标准化审计产品，但详细产品介绍不属于本文讨论范围，就不多说了。
前面的内容简单讲了设计方案，但具体施行的时候，其实会遇到多样的阻力。
在专项开始执行前，对要纳入管控范围内的系统，尽量要有清晰的处置规划。
我们要启动安全专项不是拍脑袋就可以做，一定要有合理的背景才能讲好故事。
这个背景可以是行业常见风险，可以是多起同质化安全事件，也可以是稽核监管要求，但一定要合情合理才能获取到领导层的尚方宝剑。
如果出现无法整改的场景，应该纳入什么样的整改目标，应当进行怎样的流程处置，都是需要思考的。
当然在前期规划阶段，肯定存在无法预见的困难。但是只要有适当的应急预案，在有需要的时候也能很快的确认处置方案。
在内部进行专项治理，需要有制度规范做依据，针对权限管控标准化作为指导方针，需要有明确的条款要求。
对于复杂现状，做治理不能期待一步改造到位，需要分期执行做敏捷迭代。
（1）前期
主要花精力在试点系统整改指导上，周期可能会比预期稍长。在这个阶段需要着重收集研发反馈，进行流程和方案优化。
（2）中期
已经积累了相对成熟的经验和方案，属于快速改造期。在这个阶段主要把标准化方案推广可控的范围内，进行标准化收尾工作。
（3）后期
系统标准化改造差不多到了瓶颈。在这个阶段主要通过流程进行收口管理，运用风险补偿措施处置剩余的系统。
（4）收口
对于已经改造完成的系统，也不是一劳永逸。需要通过定期抽样的形式进行例检，核验长期工作是否符合标准的安全策略，如果有出现纰漏的系统同样会被要求继续进行整改。
（1）建立虚拟委员会
（2）建立周例会机制
（3）建立实施负责人机制
对于粗粒度的关键技术方案，也需要我们定期跟进评审验收。如果实施过程中出现偏差或者需要改进，也能短期内进行轨道修正。
（4）安排专员对接
每个业务线安排专员对接，定期统计上报进度数据，传达业务和研发的诉求。
同时，专员需要及时向研发反馈项目组给出的难点解决方案，重点宣导新的工作内容。
项目关键节点最好是自上而下进行推动，有了各领域负责人的支持，研发执行效果至少可以达到合格水准。
内部稽核和外部监管，会定期下发材料问询。即使研发在实施过程中存在问题，也至少会保证整改到稽核监管认可的程度。
通过汇报立项，争取加入研发线年度考核。利用绩效系数切实驱动研发保障实施的质量，从而对最终结果进行有效把关。
如果项目实施过程中，出现交付延期、质量失衡、执行不配合，需要通过逐级问责机制，将处罚落实到自然人个体。
以上就是针对统一身份管理方案的解析实施了，由于涉及到的面有些广，针对特定技术方案的设计描述可能没那么详细。