1. 引言
在Internet急速发展的推动下，互联网的服务模式和传播渠道也随之日益丰富起来。更多的企业选择IDC来为自己分担，将网站托管、技术应用等相关的事务全部交给IDC去做，以便于将更多的资源转移到自己具有核心竞争力的业务上 [1] 。就目前来看，我国整体的IDC产业突飞猛进，网络数据中心在互联网产业链所占的比例也愈发难以忽视，因其管理着海量的业务数据，安全问题逐渐成为了IDC绕不过的难关。然而，根据电信部门实际的统计和调查，在数据中心的对外服务环节还存在着各种问题，例如欠缺防范意识、管理工作仍不到位、违法违规信息顽固存在以及日志信息无迹可寻等缺陷。所以建设一款IDC安全态势感知系统具有实际必要性。
2. 系统总体设计
系统建设的目的是为了便于电信部门(管局)与下级网络数据中心(企业)的经营者们对客户的基本信息、访问日志以及网络流量情况进行日常安全协调管理工作。其中，通信管理局侧的安全管理系统(SMMS)为上级，企业侧的ISMS为下级，双方通过信息安全管理接口(ISMI)进行指令的上传下发、任务调度以及其他通讯工作 [2] 。本文研究的IDC安全态势感知系统属于企业侧，简称ISMS系统。
从系统结构上来说，本文所研究的IDC安全态势系统主要包括以下三个单元：控制单元(CU)、执行单元(EU)以及存储单元(DU)。每个单元各司其职，完成自己任务的同时，还需要和其他的单元产生数据以及任务交互，共同完成访问日志管理、信息安全管理以及基础数据管理等任务。具备上述功能的ISMS架构见图1。
2.1. 系统单元
1) 控制单元(CU)
控制单元CU存在于功能区域所在的机房，任务是管理机房内的信息安全，并且利用ISMI与上级进行数据通信，并根据上级的要求向SMMS上报相应的数据反馈。同时，CU对各个执行点的EU设备进行集中管理，不仅要对各类管理指令做到调度、转发以及执行等操作，还要对各类数据和流量进行分析和汇总。
控制单元CU的主要功能包括：基础数据的管理、访问日志的管理、信息安全的管理、报表模块的管理、系统功能的管理以及系统其他的各项管理等。而且，CU还能够配置各种类型的结果上报以及相应
Figure 1. ISMS system architecture diagram
图1. ISMS系统架构图
的管理策略，并且将这些策略发送至EU设备。此外，CU还可以给网站备案管理系统提供各类接口，例如CU和EU的接口(U接口)，以便于实现各类相关信息的同步以及共享，从而给相关工作人员对系统进行管理和维护工作带来便利。
2) 执行单元(EU)
EU的主要功能是采集网络流量数据，分析整理以及存储，最终形成访问日志。一般情况下，考虑将其布置在出口链路，对链路中的网络流量予以采集，随后依照电信部门的有关安全机制以及经营者管理条例进行初步筛选处理，产生相应的访问日志。同时，为了满足系统的其他功能需求，EU也负责采集相关的各类数据，例如日志记录和基础信息等。对于其产生的各类访问日志以及业务内容，都需要在一定周期内根据系统需求上报至控制单元或是存储单元 [3] 。
在普遍的部署环境中，进入EU的网络流量需要再分配，也就是保证负载均衡。均衡地将网络负载分流到每一台EU设备上，分别进行监测等各项工作，从而降低处理延时，提高监管效率。这里的“均衡”是要求这些系统节点的承载量尽量相同，并且在某些结点出现高负载情况时进行负载迁移，重新保持节点之间的负载均衡状态。
3) 存储单元(DU)
DU主要用于存储EU侧收集到的客户访问日志，对这些流量数据进行压缩、转制、合并等操作，再分类或者是统一存储。此外，DU还提供查询功能，用来检索运营人员需要的访问日志。就数据库性能而言，应该能支持大数据的储存和检索。
2.2. 系统逻辑结构
系统存储方式采用的是分布式文件系统架构，也就是“服务器 + 硬盘”的模式。其任务是分析用户访问日志，采集、贮存、调度以及处置网络数据。系统的逻辑结构见图2。
在大数据量的环境下，合理地利用Hadoop平台可以为用户提供数据查询、业务分析、设备状态监测，异常IP监测、流量流向分析等应用场景建模，依据上级指令，完成任务的处理工作。
海量数据查询使用Hadoop分布式文件系统HDFS和分布式列式数据库Hbase实现，根据常用的查询条件设计索引，实现毫秒级的数据查询响应。同时，根据多维度数据分析、统计查询等需求，系统采用分层数据处理方式，首先对数据进行清洗和过滤处理操作；然后对处理逻辑组合进行优化 [4] ；最后，通过调整优化以后的客户端，进行更加灵活的查询操作。Hadoop平台数据处理层支撑应用功能架构说明见图3。
Figure 2. ISMS logical structure diagram
图2. ISMS逻辑结构图
Figure 3. Hadoop platform data processing layer supports application functional architecture
图3. Hadoop平台数据处理层支撑应用功能架构
2.3. 系统功能结构
系统从功能架构上分类可以分为四层，自上而下层次分别是：应用层，数据处理层、通信接口层以及数据采集层(EU)。其中的前三个层次属于系统功能部分，第四部分则是EU数据采集设备层。系统对应的功能结构见图4。
Figure 4. IDC security situational awareness system functional structure diagram
图4. IDC安全态势感知系统功能结构图
1) 应用层功能
应用层是IDC安全态势感知系统的应用部分。IDC安全态势感知部分包含主要的三部分功能：一是完成电信部门管理数据中心基础信息的任务，同时需要采集系统设备信息，以防服务器崩溃等重大安全事故的发生；二是异常IP的监测以及上报；三是提供违法违规网站或流量发现规则配置以及下发，并且接受违法违规信息的监测和过滤日志的及时上报 [5] 。
2) 报表生成功能
系统报表是统一通过系统报表引擎来实现的，而系统报表引擎的实现基于统一语义层。语义层对底层的异构数据源进行统一封装适配(异构数据源包括MySQL、Hadoop等)，这使得报表引擎能够基于较稳定的数据语义层进行开发，更加专注于业务报表展现方式的灵活配置。
3) 数据处理层功能
数据处理层主要负责应用层管理策略的格式转换以及静态数据的规则匹配，并且下发给EU设备。同时，接收来自于EU设备的用户上网记录数据和IDC信息安全管理的数据，并且对数据进行格式化处理随后统一存储。如果遇到需要上报的，还需要对数据进行汇总、格式转化、加密以及压缩等一系列处理，之后上报给相关应用和安全监控系统。
4) 通信接口层功能
通信接口层主要负责综合数据分析与应用，可以支持系统和EU设备之间的策略下发、策略同步请求数据的接收以及格式化转换处理等操作。同时，还需要负责访问日志数据以及信息安全监测日志数据的接收处理 [6] 。
2.4. 接口ISMI
IDC信息安全管理系统接口(ISMI)是IDC企业侧的信息安全管理系统(ISMS)与电信管理部门侧安全监管系统(SMMS)之间的接口，主要功能包括基础数据管理、访问日志管理、信息安全管理、代码表的发布等。
接口ISMI应该实现两种通道：命令通道和数据通道。命令通道由电信管理部门侧的系统使用，用来下发指令；数据通道由企业侧的系统使用，用来上传数据。其网络部署见图5。
Figure 5. Network deployment diagram in ISMI
图5. ISMI中的网络部署图
根据以上的分析，ISMI的设计应该实现如下几项功能，并且能够满足相应的条件部署。
1) 基础数据查询与上报接入
通过WebService接口接收SMMS下发的基础数据查询指令，并且重新将完整的基础数据通过FTP接口的方式上报与SMMS，完成ISMI接口–基础数据通道的实现 [7] 。
2) 基础数据异常上报接入
通过FTP接口的方式向SMMS上报基础数据异常数据，完成ISMI接口–异常IP数据通过的实现。
3) 访问日志查询上报接入
通过WebService接口接收SMMS下发的访问日志查询指令，按照指令内容要求将访问日志整理通过FTP接口的方式上报与SMMS，完成ISMI接口–访问日志查询上报通道的实现。
4) 信息安全记录上报接入
通过WebService接口接收SMMS下发的信息安全查询指令，按照指令内容要求将信息安全记录整理通过FTP接口的方式上报与SMMS，完成ISMI接口–信息安全记录上报通道的实现。
5) 处理能力及可靠性接入
这里采用大叠加策略，保证大批量数据持续稳定上报，确定ISMI接口的稳定性，保障系统的处理能力及可靠性。
2.5. 网络部署方式
串行接入方式需要用到光保护器，将其串接在数据中心的出口链路上，原有的链路会经过光保护器进入汇聚–分流设备。这一设备可以确保系统出现设备故障时，执行快速的网络恢复操作，将业务状态还原至事故前的网络连接，避免中断的出现。
相比于并行接入方式，串接的优点在于更为准确的控制网络流量，而且实现过程方便快捷。因为串接着光保护器，所有的流量都必须经过系统设备的处理才能进入转发流程，从而完成对流量的第一手控制，效果比并接方式更显著 [8] 。
但是缺点也存在同样的设备上，正因为数据链路不被复制，所以安全感知系统掌握着网络流量进出的唯一通道，这使得其存在着潜在隐患。当系统出现问题时，无论严重程度，对网络的运行的影响程度都将被放大 [9] 。而且，串接方案对于网络硬件设备的要求较高，可能会增加部署成本。串行接入方式网络结构见图6。
Figure 6. Serial access mode network structure diagram
图6. 串行接入方式网络结构图
3. 系统功能实现
3.1. 设备信息采集
Sigar (System Information Gatherer And Reporter)是包含于Hyperic-hq产品内的一款基础包，主要用于各类设备数据的收集工作，具备良好的兼容性，支持各类平台，例如目前主流的操作系统：windows、Linux、Mac OSX以及AIX等。
Sigar还拥有多语言支持的优势，具备各类语言(如C、C#以及java等)的API，实现本功能需要用到的API为java版本，即sigar.jar。其工作原理就是利用本地方法来调用当前操作系统对应的API来取得系统相关信息。例如：Linux操作系统下的df指令，可以用来检查文件系统的磁盘空间占用情况；Windows系统下的cmd命令diskpart，也可以用来查看磁盘的占用情况。而Sigar的调用可以自动适应系统所对应的操作系统，统一操作而且方便快捷 [10] 。
为了实现设备信息采集功能，需要利用这一便利的接口，采集以下两大类的系统设备信息：
第一类为静态数据，主要为：① 操作系统的各项信息。例如：内核类型、名称、版本号以及系统描述等。② CPU信息。例如：供应商、型号以及使用者等。
第二类为动态数据，主要为：① 内存信息。例如：内存总量、当前使用量以及当前交换区使用量等。② 磁盘信息。例如：磁盘已有分区、磁盘总大小、当前已使用量、文件系统类型以及资源利用率等。③ 网络信息。例如：主机域名、当前IP地址、网络流量、网络接口、配置信息以及路由等。
3.2. 异常IP逻辑判断
首先，需要确定异常IP的判断逻辑以及预警机制。通过访问日志(全省IDC网内的上行流量)中的目的IP与域名两个字段与基础数据中IP地址段与登记域名作匹配分析出异常IP数据，分三种情况，逻辑如下：
1) IP未登记
访问日志中的目的IP与机房信息IP地址段中的所有IP做匹配，如果访问日志中记录的目的IP没有在IP地址段登记，那么该日志信息为异常IP数据：IP未登记。
2) IP登记为保留，实际未启用
在基础数据机房信息IP地址段的IP登记信息中，IP的使用方式分为三种：静态，动态，保留。保留的意思为该IP已登记但是还未启用。那么访问日志中的目的IP与机房信息IP地址段中的所有IP做匹配，如果访问日志中记录的目的IP可以与IP地址段内登记的IP成功匹配，那么就继续看该IP的使用状态，如果IP登记状态为动态或者静态，则该日志信息正常；如果该IP登记状态为保留，那么该日志信息为异常IP：IP登记为保留实际未启用 [11] 。
3) IP登记，但域名有误
访问日志中的目的IP与机房信息IP地址段中的所有IP做匹配，如果访问日志中记录的目的IP可以与IP地址段内登记的IP成功匹配，并且登记状态无误，那么继续将该条记录的域名与在基础数据中该IP对应的域名进行比较，如果域名匹配不上，那么该日志信息为异常IP数据：IP登记但域名有误。综上，判断逻辑流程见图7。
3.3. 异常IP预警功能
1) IP地址在数据库中的存储
出于实际情况的考虑，即基础数据中IP地址段与登记域名过于繁多，首先需要考虑节省IP地址的存储空间。
常规的存储数据类型为varchar(15)，将IP地址作为字符数组来存储，这样做的好处是具有极高的可读性，但每个地址占用了7~15个字节，浪费存储空间这一缺点也十分明显。
进一步的改进是将字符串类型改成整数类型bigint，也就是将IP地址192.167.3.94存储为整数类型192167003094，占8个字节。这样虽然牺牲了数据部分的可读性，但是明显地节省了存储空间。
本文提出了进一步的优化存储方法，采用int数据类型，基本舍弃了数据的可读性，来保证将存储空间降到最低，仅为4个字节，并且有利于IP地址的排序，而且加快了目标IP的匹配和查找。以上三种数据类型的对比见表1。
2) 匹配步骤与实现
在基础数据库构建之初，就按照int类型存储全部的IP地址，然后对整数类型的数据值进行排序。在匹配目的IP之前，需要调用INET_ATON函数完成IP地址的类型转换，由string转为int型。或者自定义转换函数，类似于256进制数的转化，带点的IP地址转换规则如下：
Figure 7. IP abnormal state judgment flow chart
图7. IP异常状态判断流程图
Table 1. IP storage type comparison
表1. IP存储类型对比
IP Number = 16777216 * w + 65536 * x + 256 * y + z
where IP Address = w.x.y.z
随后，仅需要检测目标IP是否存在与数据库表中即可。当转换后的IP地址在数据库中已基本有序时，二分逼近查找是最高效的检索方法之一，其时间复杂度仅为O(logn)。
若不存在，则为异常IP，异常类型为“IP未登记”。若存在，再检测数据库中登记的状态标识码，若为保留，则为异常IP，异常类型为“IP未启用”；若为动态或者静态，则比较其相应的域名是否一致，来判断其属于正常IP，或是异常类型为“IP登记，域名有误”。
3.4. 报表引擎
报表引擎又分为四大部分，分别是：插件库、自定义报表、固定场景报表以及报表数据服务 [12] 。
1) 插件库
插件库是以第三方开源的展示插件为基础来实现的，其中主要的应用技术是jQuery。系统会参考市场使用规则形成统一的展现插件接口。对外而言，第三方展现插件处于封装状态；而对内而言，全部使用统一的展现接口。
2) 自定义报表
自定义报表归纳总结了日常的使用场景，有针对性的进行抽象操作，各类模块都是由最常用的场景抽象而来。在自定义报表里，可以自己选择布局和模块，组合成为个性化的业务报表。同时，可以将自定义报表发表在系统门户上。
3) 固定场景报表
固定场景报表是针对特定分析流程的报表场景来做设计实现的，它可以基于自定义流程的报表代码生成器，生成报表需要的基础框架代码，在生成的代码基础上进行简单程序开发，用于满足个性化报表或特定分析流程的报表需求。
4) 报表数据服务
报表数据服务是报表引擎获取业务数据的核心服务，它可以根据报表的配置信息从基础语义层获取业务数据，并以约定好的、统一的数据格式进行输出。同时，报表数据服务还负责对报表模板的配置信息进行管理。
综合上述报表引擎的结构，系统报表的功能结构见图8。
Figure 8. System report function structure diagram
图8. 系统报表功能结构图
3.5. 报表推送分析
报表推送在信息安全的监管中处于重要的一环，是对访问日志、异常设备信息、异常IP信息以及违法违规信息的总结和整理。同时，也是为了响应管局系统必须存在的一项功能，IDC需要定期向管局侧的系统发送这样的统计报表，以便于完成电信部门的监管要求。所以，报表推送功能应该包括以下部分统计内容。
1) 设备异常统计分析，也可以称为异常机房数量统计分析，根据存储的历史数据，从时间序列分析某一指标(正常/异常机房数)随时间的变化趋势，找出其规律的方法。可以用折线图来表示指标变化或发展的趋势。
2) 异常IP统计分析，按全省、各个地市维度进行过滤和统计异常IP数据，支持趋势和占比分析，以表格形式呈现。
3) 违法违规统计分析，对于采集到的网络流量进行数据过滤并且清洗等操作，去除无关信息。随后采用DFA算法进行违法违规信息的统计工作。下面将举例对DFA算法的执行过程进行必要的讲解。
首先，需要构建敏感词库，例如加入敏感词“武汉市”以及“武汉大学”，选择最适合的数据结构，构建一棵树或者森林。这样在判断某个目标词是否属于敏感词时就容易的多，很大程度上降低了检索匹配的工作量。例如要判断目标词是否是“武汉市”，根据第一个字符，就可以确定需要检索的是哪一颗树，之后再从这棵树中匹配关联。然后需要判断这个敏感词是否已经检索完毕，这就得用到标志位来完成 [13] 。
这部分功能使用HashMap实现，仍然以“武汉市”，“武汉大学”为例，构建敏感词的树，以便于关键词的过滤。
①查询“武”是否存在于HashMap，如果检索失败，证明这样的一棵树尚未构建，那么直接new这样的一棵树。转到步骤③。
②如果上一步检索成功，表示有“武”开头的敏感词，执行操作hashMap = hashMap.get(“武”)，转到步骤①，接下来继续匹配字符“汉”，“市”。
③这时需要判断是否是敏感词的最后一个字符，如果敏感词尚未终了，就定义标志位isEnd = 0，不然定义isEnd = 1。
完成统计操作后，进行汇总工作。按全省、各个地市维度进行过滤和统计违法违规数据，支持趋势和占比分析，以折线图或者饼状图形式呈现。
4. 系统测试
在系统的设计与实现完成之后，需要对系统进行一系列的测试工作，来确保系统的准确性和正确性。本文主要采用的是功能测试，性能测试以及安全性测试。
4.1. 功能测试
利用手工测试的办法对测试用例中的各项主要功能逐个查看，查看是否全部的按钮和链接都已经实现。使用等价类的测试方法，分别输入有效等价类和无效等价类，查看运行结果是否正常。主要测试重点如下。
1) 基础数据的本地管理
包括如基础数据的本地管理、查询和导入核验等相关功能。具体细项如下：IDC经营单位信息的本地添加、IDC业务客户数据的本地添加、IDC业务资源数据的本地添加、IDC经营单位信息的本地修改、IDC业务客户数据的本地修改、IDC业务源数据的本地修改、IDC经营单位信息的本地删除、IDC业务客户数据的本地删除、IDC业务资源数据的本地删除、基础数据的本地导入。
2) 信息安全管理
包括活跃资源监测，违法违规网站管理，违法信息监测、过滤，规则优先级验证等相关功能。具体细项如下：活跃资源监测功能、活跃资源监测记录内容、违法违规网站监测功能、违法违规网站监测记录内容、违法违规网站处置功能、违法违规网站处置记录内容、违法违规网站列表管理、违法信息监测发现功能(IP + 端口)、违法信息监测发现功能(域名)、违法信息监测发现功能(URL)、违法信息监测发现功能(关键词)、违法信息监测记录内容、违法信息过滤处置功能(IP + 端口)、违法信息过滤处置功能(域名)、违法信息过滤处置功能(URL)、违法信息过滤处置功能(关键词)、违法信息过滤记录内容、规则优先级与冲突校验。功能测试项目见表2。
4.2. 性能测试
本次性能测试首先模拟了实际应用中的软硬件环境以及常规的用户操作过程，尽可能地保证测试状态下的系统负荷与实际运行的情况下相同，查看此时的系统运行状态，一般用来参考的参数为响应时间，CPU，内存以及磁盘的占用率等。随后，通过延长单次系统运行时间，增加系统数据处理量等操作，再次查看系统的运行状态，此时参考的参数保持不变，以此来判断系统的可靠性以及性能状态。
主要的性能指标包括：规则容量、规则匹配准确率、数据更新时间、日志查询响应时间、时钟同步、数据备份与恢复等相关指标。
具体细项如下：信息安全规则容量、信息安全规则匹配准确率、信息安全记录查询响应时间、基础数据更新时间、基础数据查询响应时间、基础数据异常监测错漏率、访问日志记录入库时间、访问日志查询响应时间、访问日志记录错漏率、活跃资源监测记录错漏率、时钟同步测试、数据备份与恢复测试。
采用二分逼近法进行IP匹配具有较高的性能优势，在面对百万级的数据量时，匹配时间在0.1~0.9秒之间；即使面对千万级的数据量，匹配时间也可以控制在3.5秒以内，符合系统的性能要求。
当然，匹配时间也根据匹配结果是否成功而变化，所以在测试时，需要考虑各类结果输入测试用例。测试结果见表3。
Table 3. Abnormal IP match test result
表3. 异常IP匹配测试结果
Continued
测试环境：CPU i7-7700K + DDRC400 16 G + winlO X64。
4.3. 安全性测试
安全性测试需要验证用户类型是否对应其使用权限，能否访问权限外的信息。测试对象为具备不同用户类型的用户，参考其对应的权限执行操作，不仅要求可以访问权限内的内容，还要求禁止访问其他与权限不对应的信息，在访问系统前对用户身份进行校验来实现访问控制操作。而且，用户在一段时间间隔内不对系统进行任何操作时，应该撤销其登录状态，不能再对系统执行任何操作，并且需要重新登录。安全性测试项目见表4。
4.4. 测试结果
1) 软件功能
IDC安全态势感知系统功能需求中的基本功能已经全部实现，有部分功能还可以继续优化，进一步修改和完善。测试结果满足功能要求。
2) 软件安全性
已经从SQL注入、身份验证、用户权限访问以及系统超时身份认证等几个方面对系统进行了安全性和访问控制的测试，测试结果满足安全性需求。
3) 软件容错性
已经从数据库内数据的容错性进行验证，测试了超出规定数据类型的数据输入，超出规定数据范围的数据输入。系统界面的容错性，测试了非正常操作，频繁点击操作，非规定输入操作等。测试结果满足设计需求。
4) 软件性能
根据相应性能的策略完成了IDC安全态势感知系统性能测试。在测试的软件、硬件以及相关的配置环境下，该软件基本已经达到了预期性能指标和设计目标。测试结果满足软件性能要求。
5. 结束语
目前网络数据安全面临众多威胁，IDC的安全管理任重道远，本文利用Hadoop集成框架，完成各类大数据的流量管理任务，包括设备信息采集，异常IP预警，报表统计分析以及ISMI接口等功能，在数据存储和数据匹配方面加以改进和优化，提高了系统的运行效率。该系统已投入运行，效果良好。
参考文献
NOTES
*通讯作者