system: [SYSTEM]

user: 2. 系统架构 本节介绍了运维账号统一管理平台应实现的业务功能，在此基础上设计出平台整体架构，讲述了平台的使用流程，并就其核心关键技术(运维账号动态口令获取)进行探讨。 2.1. 平台功能及整体架构 如图1所示为平台整体工作流程图。 图1. 平台整体工作流程图 根据平台特点及业务需求，本系统核心功能包括以下七点： 1) 能够实现口令的集中管理。能够集中存储和自动化管理各系统平台(ZOS/AIX/UNIX/LINUX/ WIN/ESX/数据库/中间件/网络设备/安全设备/WEB应用维护用户/应用内嵌用户的ID口令，应根据实际需求配置自动化口令管理策略。 2) 能够实现单点登录和监控。为了进一步保证口令的安全性，软件需提供集中用户单点登录与监控。具体包括口令代填和实时监控两个要点。其中口令代填指的是在使用口令时不将口令的明文暴露给任何人员，通过口令代填的形式帮助管理人员打开客户端和填写口令。实时监控指的是在用户使用者在使用用户时，另一方人员可以同步登录系统查看用户使用情况与具体操作命令。 3) 登录主机时实现双因素认证。 4) 实现用户ID审批管理流程的整合。提供各平台系统用户口令的全生命周期管理，并与中心现有的系统用户申请流程整合，实现“一事一申请”的安全管理要求。 5) 实现系统系统用户的自动发现。对中心生产环境(ZOS/AIX/UNIX/LINUX/WIN/ESX/数据库/中间件/网络设备/安全设备/WEB应用维护用户)的系统用户能够自动探测、收集并纳入一体化访问控制平台进行集中管理，一体化访问控制平台能够针对用户的添加、删除进行差异化对比，统计出每天中心平台用户变化情况，规避和杜绝“幽灵用户”的出现。 6) 提供应用运行类用户管理。对内嵌在中间件数据库连接、应用程序代码、脚本以及配置文件中的应用运行类用户口令可以实现自动化修改，满足内外审计监管要求，真正保护敏感数据。 7) 提供精细化权限管理。针对开放平台操作系统中的运维账号进行精细化的权限管理以“最小权限分配”原则实现访问控制中的用户授权环节。 图2. 运维账号管理工具平台整体架构图 基于以上分析，以业内拥有数据中心和同城灾备中心结构 [ 7 ] 的模式为例，设计平台整体架构如图2所示。由图2可见，本系统运行于局域网内部，包括数据中心和同城灾备中心两部分，每一部分又包括平台数据库群集和平台前置群集。其中，平台前置群集和被管理的服务器之间直接通信，平台数据库群集用以保存运维账号管理平台中的动态用户口令。数据中心和同城灾备中心之间通过防火墙安全隔离，并通过令牌认证邮件的方式进行通信。 2.2. 平台整体使用流程 根据以上分析，设计平台工作架构如图3所示。具体描述如下。 歩骤1，IT管理员登录管理平台，可以利用AD/LDAP，附加RSA进行双因素认证。 歩骤2，IT管理员通过浏览器访问PVWA进行口令获取，口令管理，单点登录及审计等功能。 歩骤3，单点登录时，浏览器打开至PSM服务器的RDP连接，由PSM自动代填口令，为管理员打开至目标服务器的会话，包括SSH，RDP，XWindows，Oracle，DB2，FTP等。 歩骤4，审计人员通过PVWA查询在线会话后，亦可登录PSM进行同步监控在线会话。 歩骤5，会话结束后PSM服务器将相关录像及操作文本上传至口令保险库中。 歩骤6，如果存在口令被查询后，CPM会在一段时间后对目标服务器上的用户进行口令重置。 歩骤7，EPV Replicator作为EPV套件自带软件，将Vault数据以加口令形式定期导出，后续企业备份软件可以保存并导入磁带用于未来恢复。 图3. 系统工作架构 2.3. 技术原理 平台通过如下手段实现运维账号全生命周期管理： 1) 口令管理插件框架：在内部形成状态机(StateMachine)的机制，形成<行动，状态，下一步行动>的模型。 上述例子中是针对UNIX/Linux的部分登陆过程，其中LoginExtraUser是由普通用户登录UNIX/Linux，switchPass是切换至root用户(或者其他用户)的状态，此处有Password，InvalidLogin，AccountDisabled，NotAllowedLogin等多种状态。此处不再由代码直接固定写死每种设备类型的执行步骤，而是由状态机的配置规定了管理模式，这样内部人员今后通过修改配置文件就可以集成各种内部设备，而且这个模式下还可以调用外部程序来实现口令更改，形成通用的管理模式。2) 应用内嵌用户管理：应用程序内嵌用户管理就是通过SDK来获取动态口令，但是为了能在不重启应用的情况下面，使得应用能够更新使用到的相关口令，那么如何保持数据一致性成为管理思想的核心(见图4)。笔者的技术思路如下： 图4. 口令管理一致性示意图 a) 口令变更模块(Central Policy Manager)在处理修改之前3T分钟时向Vault发起口令更改请求，并作标签(ChangeNotBefore)，该标签中记录了之后口令更改的时间戳。 b) 位于应用服务器本地的代理程序(Provider)具有本地缓存，并且会周期性(T分钟)扫描Vault中的用户对象并刷新缓存，如果发现ChangeNotBefore标签时(如果里面为10:00 am)，即知晓本地缓存在10:00 am时可能有新的数据变更。Provider自然就不会在此时读取缓存。由于是周期性T分钟扫描，那么总能在Central Policy Manager修改之前刷新到ChangeNotBefore的标签。 c) 当10:00 am时，Central Policy Manager触发口令修改，此时Provider又向Vault发送查询口令时，Vault会锁住用户对象，不响应Provider的请求，一直等到Central Policy Manager完成口令更改请求，Vault再向Provider响应最新的口令值。 d) 在口令修改期间，应用仅仅有短暂的停顿。但是由于数据库口令修改时间仅为5~10毫秒，因此对数据库连接影响非常之小。 上述这个方法最大程度保障了口令在应用和数据库之间的一致性，同时也满足了口令动态修改的要求。 3) 权限管理：在传统的权限管理中，UNIX/Linux平台会依赖于SELINUX和普通的文件权限，windows平台中通过组策略或者权限组来设定，但是管理粒度仍旧很粗，而且存在管理难度高、实现复杂、排查不易的特点。因此笔者利用口令集中存储的优势，在IT人员接触操作系统时，为他进行临时提权，提权的机制是通过输入特权口令实现，但是执行的命令又受到“权限控制器”中的规则制约(见图5)。 上述为白名单模式，但是笔者在实践中，新建一个普通用户(UID不等于0)，授权其可以进行root提权，但是会将这样高危命令放入黑名单，如此，IT人员虽然用这个普通用户，仍旧可以执行大量root的特权命令，只是reboot命令不能执行。这样有效防范误操作和攻击，而且也无法像堡垒机那样，可以将命令放入shell来绕开现有管理机制。即使放入shell脚本中，也受到权限控制器的管理。并且口令提供器会将提权命令上传至Vault中，便于集中审计。 4) 特权威胁分析：除了访问控制之外，笔者认为还需要对被管理的设备上的日志与平台日志进行关联分析，以发现内网异常行为。 图5. 权限管理示意图 另外平台可以实现以下典型安全保护： · 哈希传递是系统用户登录的时候使用口令的哈希值代替口令来完成认证，很多Windows的协议都是需要用户口令哈希值，并不一定非得需要用户口令，黑客可以通过Windows上残留的用户的哈希值来代替口令进行认证、操作。解决方案：使用平台监控Windows AD域控的网络数据包，从抓包中获取到符合规则定义的可疑Over Pass Hash攻击操作，并结合Central Policy Manager组件，发现此类攻击后立即触发问题用户的口令修改，中断黑客手中Hash值的有效性以阻止攻击蔓延。 · 由于企业例行事务往往以月为单位，因此可以将过去2个月的历史数据作为基线，通过大数据分析IT管理员的使用习惯，对以下情况予以告警： o 当其访问口令频率超出正常水平 o 当管理员在非正常时间段访问 o 从非正常源IP地址访问 o 未通过特权用户平台访问 · 另外，对非纳入管理的用户，如果在被管理设备上存在访问日志，则主动将该用户重新纳入平台自动托管，形成管理闭环。 · 禁止未通过特权平台获取口令，直接访问目标主机。 · 禁止未纳管特权用户登陆目标主机。 · 禁止特权会话中有可疑的高风险操作，比如修改底层配置文件。 · 禁止可疑的口令修改操作。正常情况下所有口令由特权用户管理平台统一管理，如果被管理设备上存在口令管理操作，而特权管理平台不存在，则一定是有黑客入侵或者其他非正常渠道修改了口令。因此需要将特权用户口令再修改一次。