freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

统一身份管理方案:从解析到落地实录
2022-06-26 03:23:19
所属地 上海

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

一、概念解释

这里聊的统一身份管理方案,主要是指认证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)层层问责

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

五、结语

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

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

# 甲方安全 # 认证安全 # 权限管控
本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者
文章目录