天津电力行为安全审计系统建设与应用

0 引言

国网天津市电力公司（以下简称天津电力）现有信息系统的审计体系主要以综合审计系统、运维审计系统、统一权限平台为核心,并整合各业务应用、业务与数据库审计模块、桌面终端管理模块、I6000、网络基础设施日志、数据库审计日志,共同实现信息系统的安全管理。随着天津电力业务系统越来越多,设备规模越来越大,日常运维及安全监控工作的难度也愈来愈大。2016年在国家“十三五”信息安全技术提升要求下,天津电力积极推进信息系统行为安全审计建设,并顺利完成系统的部署和实施工
作^[1-2]。天津电力行为安全审计系统主要通过用户行为追踪、运维审计、应用日志采集和行为审计中心这四大功能模块,实现对信息系统用户行为的全生命周期管理,为安全审计提供统一的平台支撑。

 1 天津电力运维审计管理现状

自2012年以来,天津电力网络与信息系统的安全审计能力,主要通过将综合审计系统、运维审计系统、统一权限平台、各业务日志数据等整合后共同实现。虽然现有的安全审计模块能够满足基本的安全需求,但由于各应用建设时间较久、建设内容较分散,导致出现各业务应用间各自为阵、审计数据分散、标准不统一、缺乏统一平台支撑等问题,难以满足国家电网公司对用户行为“全过程记录、事前防范、事中控制、事后溯源”、审计“可控、可视、可分析、可追溯”的安全审计新要求^[3]。天津电力现有信息系统的安全审计体系主要存在以下几方面的问题。

1）运维账号权限不明确。运维账号行为无监管,针对主机、数据库、中间件、网络设备和安全设备等的操作无法做到行为审计,审计主体和审计客体无法实现关联。运维账号权限无限制、无告警,日常运维操作权限过大,出现问题无法短时间定位、恢复^[4]。

2）账号保密管理不严格。部分业务应用对其运维管理员账号的管理松散,账号管理未明确责任人,存在管理员账号盗用、借用、滥用的情况,一旦出现安全问题,无法溯源及定位责任人^[5]。

3）安全审计能力不完善。各业务系统及安全系统的用户行为日志格式不统一,难以实现集中分析与管理。日志采集信息过于单一,无法进行公司级的安全审计,不便于公司整体安全态势分析和安全策略调整。业务应用操作日志可被删除、篡改,容易形成行为追踪断点^[6]。

 2 天津电力行为安全审计系统建设

2016年,天津电力行为安全审计一期项目完成了4个主要功能模块的建设和实施工作,重点开展了系统蓝图设计和相关系统数据及接口的配置调试工作,并以已有安全审计系统中的数据为资源,整理了设备及运维人员数据10万多条,完成了行为安全审计系统的实施及对现有安全审计系统功能的整合工作。

行为安全审计系统是在成熟高效的技术基础上,以日常信息操作中实际的安全诉求为导向建设的一个对用户行为追踪、对账号密码集中管理、对运维人员运维权限管理、对安全审计功能标准化的统一的安全审计平台。系统的上线增强了安全审计数据的采集及分析能力,增强了公司信息系统的主动防护能力,并最终实现了公司级的统一安全审计平台^[7]。

 3 行为安全审计系统架构及其功能模块

3.1 系统架构

行为安全审计系统包含用户行为追踪模块、运维安全审计模块、应用日志采集模块和行为审计中心模块这四大功能模块,共同构成了行为安全审计系统的总体架构（见图1）。

图1 行为安全审计系统架构Fig.1 The general architecture of behavior security audit system

通过在客户端安装日志采集模块,记录收集用户访问各类信息资产（基础硬件、服务器、数据库、业务系统等）的操作日志,并将日志数据汇集到行为审计中心模块进行存储。用户行为追踪模块从行为审计中心模块读取数据,并通过内置搜索引擎进行用户行为信息检索和分析,从而实现用户行为全周期审计。通过在防火墙配置策略阻止客户端直接访问服务器,并开通运维审计堡垒机访问业务系统服务器的远程管理访问权限,实现对用户行为的全周期管控^[8]。

3.2 系统功能模块

3.2.1 用户行为追踪模块

用户行为追踪模块,以统一权限平台账号权限数据和行为审计中心模块为基础,支持用户权限访问控制、权限管理以及对用户行为记录的查询^[9]。用户行为追踪模块通过数据库MongoDB,满足对长久大量增长的审计日志（包括对业务应用日志、运维日志、终端日志、设备日志等）的持久化存储和快速查询的需求,并基于分布式存储架构通过动态扩展存储节点,满足海量数据递增带来的存储需求。同时为了提高用户行为追踪模块的快速响应性能,整合MapReduce和Storm,并对MongoDB中大规模日志数据的离线和实时分析处理,从而实现对可疑用户使用信息系统的行为进行快速追踪,以追踪到“何时、何人、何地、做何操作”,为后续的泄密、违规事件取证做支撑。

3.2.2 运维安全审计模块

运维安全审计模块主要通过设置一台堡垒机,使用户通过堡垒机跳转远程访问服务器。达到对运维人员登录系统账号的实名制统一授权管理、对资源账号密码的集中管理和对运维人员登录资源进行运维操作的统一管控、统一审计的目标。

1）模块架构。运维安全审计模块总体架构分为6个层面：展现层、业务逻辑层、服务交互层、持久化层、虚拟化层、外部系统接口层（见图2）。①用户通过展现层访问系统、维护系统。②业务逻辑层是核心功能模块,实现自然人与账号的关联、用户身份认证、账号权限管理、违规操作告警、用户行为审计等功能。它通过服务交互层实现全设备管控,并将数据通过展现层向用户展示。③服务交互层通过2种不同的接口类型实现对异构的资源进行管理。④持久化层采用LDAP、PostgreSQL数据库实现对资源信息的存储整理。⑤外部系统接口层帮助展现层和服务交互层实现与统一权限系统账号口令功能以及与I6000系统设备信息的集成。

图 2. 运维安全审计模块架构Fig.2 The architecture of operation audit module

2）应用虚拟化。为了保证运维的实时安全可控,在运维安全审计模块中使用了应用虚拟化技术,从而实现运维安全审计模块在服务端发布各应用程序,用户本地无需安装运维插件,只需通过身份认证确认有权限调用远程发布服务器应用,并通过模拟代填登入目标资源,过程中无需用户输入资源账号密码^[10]。在行为安全审计系统设计建设过程中,通过对比PCoIP和远程桌面协议（Remote Desktop Protocol,RDP）协议,发现独立计算架构（Independent Computing Architecture,ICA）协议更能满足电力系统中多操作系统类型、多设备类型的需求,且稳定性更好。此外ICA协议也是一种高效率的数据交换协议,采用数据压缩、加密和连接优化技术,结合数据存储采用3DES加密算法,防止人为因素带来的密码泄露或破坏,有效地保证运维信息安全。

3.2.3 应用日志采集模块

应用日志采集模块用于记录用户访问各类信息资产（如基础软硬件、服务器、数据库、业务系统）的行为日志数据^[11]。通过Agent采集数据,并通过Flume分布式日志采集系统进行存储整理。应用日志采集模块架构如图3所示。

图3 应用日志采集模块架构Fig.3 The architecture of application log collection module

1）数据采集方式。通过在用户客户端、外网业务应用、内网业务系统、桌面云终端等部署统一采集Agent,能适配各类日志来源和日志模型。对于用户客户端,通过采集内网用户终端上的图形化程序、文本程序、浏览器等操作内容,进行用户行为日志采集。对于外网业务应用,通过在外网应用网络节点部署旁路流量复制采集功能,进行日志采集。将应用日志采集模块以守护进程运行,实现用户行为日志采集的同时,能做到对业务系统运行性能几乎无影响,最终将所有采集日志数据汇集到行为审计中心
模块。

2）Flume分布式日志采集系统。应用日志采集模块采用Flume分布式日志采集系统,利用Flume支持各种接入资源数据的类型的优势从各种设备、终端中采集日志,并将其集中起来存储到分布式文件系统（Hadoop Distributed File System,HDFS）中^[12]。模块中将Flume和Zookeeper整合以确保传输的负载均衡,将Flume和Krafa整合,将Flume集群收集到的数据输送到Kafka中间件,以供用户行为追踪模块中的Storm去进行实时计算,然后将处理后的数据写入HDFS,并利用MapReduce进行离线分析处理。Flume的信息缓存机制也能够避免单点失效,从而保证了日志采集的可靠性。

3.2.4 行为审计中心模块

行为审计中心模块采用集中管理、两级应用模式,国网总部行为审计中心管理模块可对全网关键日志数据进行集中管理,天津电力行为审计中心模块只对本企业的所有日志数据进行集中管理。通过整合公司现有相关信息系统审计应用,实现各系统异源日志的全面收集、海量存储、分析源供应,并将整理后的数据提供给用户行为追踪模块进行数据分析使用^[13]。天津电力通过统一的数据交换平台来实现与总部的数据纵向贯通。数据交换平台实现了两端可配置的数据封装和解析功能,通过统一的数据交换标准、统一接入服务,实现了多种可配置的交换格式和数据格式^[