会员体验
专利管家（专利管理）
工作空间（专利管理）
风险监控（情报监控）
数据分析（专利分析）
侵权分析（诉讼无效）
联系我们
交流群
官方交流：
QQ群： 891211   
微信请扫码    >>>
现在联系顾问~
首页 / 专利库 / 防辐射 / 纵深防御 / 一种市民卡系统

一种市民卡系统

阅读：647发布：2020-07-18

IPRDB可以提供一种市民卡系统专利检索，专利查询，专利分析的服务。并且本发明涉及一种市民卡系统，属于智慧城市技术领域。包括：应用接入层，用于部署各种应用前置服务，包括各种应用的WEB服务器和/或应用系统数据库服务器；应用交换层，用于部署各种数据服务的中间件及接口，并且提供作为数据核心层唯一可信源的内部应用服务；数据核心层，用于部署各种关键核心数据库、数据交换库、中心数据库、文件存储库。该系统在原政务数据中心、政务云、原医疗卫生云的基础上提升网络、安全、计算与存储能力，构建一个能更好为全市市民提供服务的“城市云中心”。，下面是一种市民卡系统专利的具体信息内容。

1.一种市民卡系统，其特征在于，包括：

应用接入层，用于部署各种应用前置服务，包括各种应用的WEB服务器和/或应用系统数据库服务器；

应用交换层，用于部署各种数据服务的中间件及接口，并且提供作为数据核心层唯一可信源的内部应用服务；

数据核心层，用于部署各种关键核心数据库、数据交换库、中心数据库、文件存储库。

2.根据权利要求1所述的一种市民卡系统，其特征在于，所述应用接入层包括：

政务专网外联区，用于接入市民云服务系统以及政务云服务系统；

卫生专网外联区，用于接入卫生云服务和医院云服务；

教育专网外联区，用于接入教育云服务。

3.根据权利要求2所述的一种市民卡系统，其特征在于，所述医院云应用服务器采用虚拟主机、通过应用负载均衡设备进行负载调度的方式提供应用服务器基础运行环境，集群搭建时使用选择两路中端服务器作为计算节点，并两两构建集群，其中服务器CPU选择2颗

12核Xeon E5-2600v3系列主频≧2.2G，内存选择256G，每个Hyper-V集群可用CPU48核、可用内存256GB(配置内存有一半预留故障迁移)，平均每核物理CPU配备5.33GB内存。

4.根据权利要求1所述的一种市民卡系统，其特征在于，所述数据核心层采用计算/存储融合一体的方式搭建2个Oracle 12C RAC集群，两两一组做RAC集群。

5.根据权利要求2所述的一种市民卡系统，其特征在于，市民云服务系统中心部署的城市核心系统、核心数据处理及服务系统基于Oracle数据库环境，采用Oracle 12C分布式数据库集群+闪存加速卡超融合存储解决方案通，设计3组云数据库RAC集群，共配备6台设备提供168核CPU、3072G内存；设计1个分布式高速存储集群，共3台设备共计37.2T、可用18.6T存储空间。

6.根据权利要求1所述的一种市民卡系统，其特征在于，所述数据核心层的管理策略包括：等级防护：以实现等级保护为基本出发点进行安全防护体系建设，并参照国家等级保护基本要求进行安全防护措施设计；

分区分层：为了体现电子政务、卫计、社保等业务管理的特点，采用分区分层进行系统建设，并依据应用系统结构及安全威胁分布情况，进行安全域划分，以实现不同安全域的独立化、差异化防护；

多层防御：在分域防护的基础上，将应用系统划分为数据接入、数据交换、数据核心三个层次进行安全防护设计，以应用接入层作为用户访问应用系统的唯一入口，各层次之间严格过滤，禁止跃层访问，避免大二层扁平化网络带来的应用层次模糊、安全防护手段难以实现等问题，最终实现层层递进，纵深防御的应用安全防护体系结构；

态势感知：在防护手段的基础上，将各系统及服务产生的日志、事件信息进行统一的采集、分析，对各网站系统进行统一的安全监控，以实现网络、网站各类安全事件可分析、可溯源；

风险管理：以风险管理为核心，持续性的安全风险监控、评估为抓手，配备专业的技术支撑人员队伍，以实现安全威胁得到有效抑制，安全弱点得到及时控制，安全事件得到及时处置。

7.根据权利要求1所述的一种市民卡系统，其特征在于，文件的存储基ParaStor200系统，包含四类组件：索引控制器oPara、数据控制器oStor、应用服务器oApp和管理控制器MGR；其中，索引控制器用于管理存储系统的命名空间和所有索引数据，对外提供单一的全局映像；数据控制器提供数据存储空间，并实现存取动作，支持多个数据副本；应用服务器即客户端，可以通过多种数据访问接口访问并行存储，并支持多种64位Linux操作系统和Windows系统；管理控制器提供统一的控制管理界面，管理员通过该节点管理整个系统。

说明书全文

一种市民卡系统

技术领域

[0001] 本发明涉及一种市民卡系统，属于智慧城市技术领域。

背景技术

[0002] 市民卡支撑平台是市民卡制发卡系统、卡管系统、卡应用系统的支撑平台，主要 负责支撑市民卡制发、卡管理、卡认证、卡应用的硬件平台。市民卡支撑平台建设包括 核心网络改造、市民卡云平台、数据库集群、数据存储系统、容灾备份系统、网络与信 息安全改造等部分。由于市民卡运行对支撑平台的计算能力、存储能力、安全性要求较 高，必须具备高可用和高可靠，以及高并发处理能力，确保市民卡7*24小时不要间断 运行。
[0003] 市民一卡通主要是解决城区市民人手只持有一张卡，建立一个以智能卡为载体， 覆盖城区、面向市民的政府社会保障和公共服务体系，统一发放市民办理各项社会保障 事务、享受政府公共服务，具有多功能、多用途的智能卡，打通政府各类社会保障和公 共服务系统之间的数据接口，实现社保卡、居民卫生健康卡、就诊卡、金融银联卡四卡 合一，并在此基础上对其它服务成熟一个移植一个，逐步建成市民“一卡通”。

发明内容

[0004] 本发明主要是解决现有技术所存在的技术问题，供了一种市民卡系统，该系统在 原政务数据中心、政务云、原医疗卫生云的基础上提升网络、安全、计算与存储能力， 构建一个能更好为全市市民提供服务的“城市云中心”。
[0005] 本发明的上述技术问题主要是通过下述技术方案得以解决的：
[0006] 一种市民卡系统，包括：
[0007] 应用接入层，用于部署各种应用前置服务，包括各种应用的WEB服务器和/或应用 系统数据库服务器；
[0008] 应用交换层，用于部署各种数据服务的中间件及接口，并且提供作为数据核心层 唯一可信源的内部应用服务；
[0009] 数据核心层，用于部署各种关键核心数据库、数据交换库、中心数据库、文件存 储库。
[0010] 优选的，上述应用接入层包括：
[0011] 政务专网外联区，用于接入市民云服务系统以及政务云服务系统；
[0012] 卫生专网外联区，用于接入卫生云服务和医院云服务；
[0013] 教育专网外联区，用于接入教育云服务。
[0014] 优选的，所述医院云应用服务器采用虚拟主机、通过应用负载均衡设备进行负载 调度的方式提供应用服务器基础运行环境，集群搭建时使用选择两路中端服务器作为计 算节点，并两两构建集群，其中服务器CPU选择2颗12核Xeon E5-2600v3系列主频≧ 2.2G，内存选择256G，每个Hyper-V集群可用CPU48核、可用内存256GB(配置内存有 一半预留故障迁移)，平均每核物理CPU配备5.33GB内存。
[0015] 优选的，所述数据核心层采用计算/存储融合一体的方式搭建2个Oracle 12C RAC 集群，两两一组做RAC集群。
[0016] 优选的，市民云服务系统中心部署的城市核心系统、核心数据处理及服务系统基 于Oracle数据库环境，采用Oracle 12C分布式数据库集群+闪存加速卡超融合存储解 决方案通，设计3组云数据库RAC集群，共配备6台设备提供168核CPU、3072G内存； 设计1个分布式高速存储集群，共3台设备共计37.2T、可用18.6T存储空间。
[0017] 优选的，所述数据核心层的管理策略包括：
[0018] 等级防护：以实现等级保护为基本出发点进行安全防护体系建设，并参照国家等 级保护基本要求进行安全防护措施设计；
[0019] 分区分层：为了体现电子政务、卫计、社保等业务管理的特点，采用分区分层进 行系统建设，并依据应用系统结构及安全威胁分布情况，进行安全域划分，以实现不同 安全域的独立化、差异化防护；
[0020] 多层防御：在分域防护的基础上，将应用系统划分为数据接入、数据交换、数据 核心三个层次进行安全防护设计，以应用接入层作为用户访问应用系统的唯一入口，各 层次之间严格过滤，禁止跃层访问，避免大二层扁平化网络带来的应用层次模糊、安全 防护手段难以实现等问题，最终实现层层递进，纵深防御的应用安全防护体系结构；
[0021] 态势感知：在防护手段的基础上，将各系统及服务产生的日志、事件信息进行统 一的采集、分析，对各网站系统进行统一的安全监控，以实现网络、网站各类安全事件 可分析、可溯源；
[0022] 风险管理：以风险管理为核心，持续性的安全风险监控、评估为抓手，配备专业 的技术支撑人员队伍，以实现安全威胁得到有效抑制，安全弱点得到及时控制，安全事 件得到及时处置。
[0023] 优选的，文件的存储基ParaStor200系统，包含四类组件：索引控制器oPara、数 据控制器oStor、应用服务器oApp和管理控制器MGR；其中，索引控制器用于管理存储 系统的命名空间和所有索引数据，对外提供单一的全局映像；数据控制器提供数据存储 空间，并实现存取动作，支持多个数据副本；应用服务器即客户端，可以通过多种数据 访问接口访问并行存储，并支持多种64位Linux操作系统和Windows系统；管理控制 器提供统一的控制管理界面，管理员通过该节点管理整个系统。
[0024] 因此，本发明具有如下优点：该系统在原政务数据中心、政务云、原医疗卫生云 的基础上提升网络、安全、计算与存储能力，构建一个能更好为全市市民提供服务的“城 市云中心”。

附图说明

[0025] 附图1是本发明的系统原理图；
[0026] 附图2-11是本发明的网络架构流程图；

具体实施方式

[0027] 下面通过实施例，并结合附图，对本发明的技术方案作进一步具体的说明。
[0028] 实施例：
[0029] 一、系统设计
[0030] 本实施例主要包括以下内容：
[0031] 从城市云核心的角度，对原卫生云、政务云的“核心网络改造升级”；
[0032] “新建医院云、市民云(一卡通)”，包括：
[0033] (1)为医院云端系统、一卡通系统“新建虚拟化集群”；
[0034] (2)为医院云端系统、一卡通系统“新建数据库集群”；
[0035] “新建数据中心”，包括：
[0036] (1)针对城市核心系统、核心数据处理及服务的需求“新建大数据处理平台”；
[0037] (2)为医疗影像、文档一体化等系统的大量小文件“新建海量小文件存储系统”；
[0038] 进行“信息安全改造升级”，包括：
[0039] (1)进行原政务云一体化“容灾备份系统调整”，同时为医院云端系统、一卡通 系统的数据及文件提供备份服务；
[0040] (2)对新改造的城市云核心网络进行“核心网络安全加固”；
[0041] (3)因为各医院需要接入到医院云，为保障全局安全，对各接入单位具备的“共 性安全问题统一建设(新建)”，例如：统一单位接入安全网关、统一终端网络准入、统 一网络运维监控等；
[0042] (4)对医院个性的网络及安全问题提出建设建议和要求。
[0043] 关键技术
[0044] 业务逻辑架构采用“瘦核心、大外围”。鉴于现有技术的云中心基础架构已赋予了 越来越多平台化角色，不再单一承载某一项业务应用，信息敏感程度已不亚于金融单位 密级类别，因此，要将现有基础架构(含网络、应用、数据)逐步转变为“瘦核心、大 外围”模式，核心层仅做数据记录且访问途径严格受控。如图1所示。
[0045] 中心网络架构采用“三层分级”数据中心网络架构，从应用角色及业务架构需求 出发，基于权限最小化，以模块化扩展组合为原则，分为三个层面构建：1、应用接入 层；2、应用交换层；3、数据核心层。示意如图2所示。其中：
[0046] (1)应用接入层主要部署各种应用前置服务，包括各种应用的WEB服务器+一些 小型、非关键、测试、开发的应用系统数据库服务器；
[0047] (2)应用交换层主要部署各种数据服务的中间件及接口，包括：各种应用的数据 中间件、数据接口、数据逻辑服务等。同时应用交换层内的应用服务，作为数据核心层 唯一可信源；
[0048] (3)数据核心层部署各种关键核心数据库、数据交换库、中心数据库、文件存储 库等。原则上，数据核心层安全权限最高，可以基于需求，访问抵达应用交换层、应用 接入层，但反之则不可以。
[0049] 一卡通、医院云数据支撑采用“融合一体机”。中心机房通过技术验证和测试，借 鉴Exadata的架构，提出数据库融合一体机解决方案：利用Oracle 12C云数据库、x86 服务器、PCI-E SSD硬盘卡作为基础设施，采用计算/存储融合一体的方式搭建Oracle 12C RAC集群，让数据尽量靠近CPU，获取最佳的事务处理性能。
[0050] 大数据处理平台采用“分布式云数据库”。
[0051] 一卡通、医院云的数据库偏重于事务处理和快速查询(属于IO消耗型)，数据中 心偏重于计算和统计(属于CPU消耗型)。
[0052] 因此针对大数据处理平台需要利用Oracle 12C云数据库、x86服务器、PCI-E SSD 硬盘卡、Infiniband交换网等技术，形成的轻量级、低成本、高性能、可扩展的整体架 构，采用计算集群、存储集群分离的方式搭建分布式云数据库集群。
[0053] 这种可单独灵活扩展计算节点、存储节点的集群部署方式，可以为大数据处理提 供更高、更灵活的计算统计能力和数据存储能力。
[0054] 插入云端的数据库采用“Oracle Database 12c企业版”
[0055] Oracle Database 12c企业版包含500多个新特性，其中“多租户”特性包括一 种新的架构，可简化数据库整合到云的过程，客户无需更改其应用即可将多个数据库作 为一个进行管理。
[0056] 中心机房通过技术验证和测试，证明使用新的Oracle 12c多租户架构，无需更改 现有应用即可在一个集群上实现更多数据库的整合。
[0057] 高可用的虚拟主机平台采用“微软Hyper-V 2012”。中心机房根据成功使用微 软Hyper-V构建云计算平台的经验，本实施例采用微软Windows2012数据中心版软件， 构建高可用共享服务器的Hyper-V虚拟化环境。
[0058] 海量小文件存储平台采用“曙光ParaStor”。由于PACS系统、文档一体化系统都 是存储的几十KB到几MB的小文件，这需要专用的海量小文件存储系统支持。中心机房 根据在电子政务云、视频云成功使用曙光ParStor分布式存储的经验，因此利用X86服 务器独立搭建一套ParStor海量文件系统。今后，再有海量文件的输出需求，只要简单 的扩展数据节点、增加存储容量即可。
[0059] 容灾备份平台采用“赛门特克NBU”
[0060] 中心机房根据成功使用NUB备份系统成功构建政务云一体化容灾备份系统的经验， 拟在原政务云一体化备份系统基础上，继续使用NBU备份软件实现本期医院云端系统、 一卡通系统数据及文件的本地备份。
[0061] 总体架构
[0062] 网络总体架构设计如图3所示。下面分别进行介绍。
[0063] 应用接入层设计如图4所示。应用交换层的设计如图5所示。应用交换层的设计 如图5所示。数据核心层的设计如图6所示。
[0064] 核心网络设计包括：从城市云核心的角度，整合当前政务云和市民云网络体系架 构资源，对目前网络体系(含安全)进行改良设计。考虑到新数据中心与现有数据中心 资源融合部署。按照大数据中心的网络架构进行规划，分区域实现应用服务系统的部署 架构。将核心网络分为应用接入层、应用交换层、数据核心层三个层面进行构建。从应 用角色及业务架构需求出发，基于权限最小化，可模块化扩展组合为原则，分区域进行 不同级别、层次、权限的安全防护。
[0065] 目前政务云接入区核心网络设备为二台思科7606路由器。从2007年底运行至今， 办公系统从最初的少量发展到目前的34个部门的95个应用系统，9个县市的52个应用 系统。经过这些年的快速发展，原来的核心网络存在的架构及安全风险矛盾也日益突出： (1)核心路由与核心交换之间的骨干带宽仍停留在2007年的千兆传输通道。随着应 用系统的并发访问量逐渐增大；跨区域的数据迁移、备份操作的日常化，原有的千兆骨 干链路在高峰期会达到千兆峰值，延迟了数据的传输效率。(2)由于应用服务器的数 量不断增加，原有核心路由器下连的接入交换机数量已达6台且接入层级相对过多；随 着云计算虚拟化平台的迅速发展，应用服务器集群的接入端口需要直接前移至核心路由 端口上来，以优化虚拟化平台的数据转发效率。(3)目前的核心交换机下连的内部应 用服务器安全防护能力不足，缺少入侵防护、WEB应用防护的安全防护能力。综上分析， 将目前的政务云核心路由骨干网互联通道由原来的1G扩容至10G带宽。
[0066] 目前卫生云接入区已通过市电信、广电运营商建立了市人口健康信息化专网网络， 经运营商网络汇聚至卫生云二台H3C-s10508核心交换机上。通过运营商网络汇聚实现 与市卫计专网、市社保、省社保网络、市电子政务平台、市民云(市人口健康信息化专 网)及其他医疗相关单位互联互通城市市民云核心网络建设：从整个城市市民云核心网 络平台架构出发，整合当前政务云和市民云网络体系架构资源。利用原有卫生云二台 H3C-s10508核心交换机实现万兆扩容后，作为城市市民云核心网络平台。城市云核心网 络采用层次化网络架构设计，城市市民云核心网络分为数据接入区、数据交换区、数据 核心区三个区域。分区域实现应用服务系统的部署架构，并按不同级别、层次、权限做 安全防护。
[0067] 核心交换网建设：目前卫生云二台核心交换机型号为H3C-s10508。单机配置为： 一块4端口万兆业务板，2块48端口千兆电口业务板，一块48端口千兆光口业务板。 目前作为卫生云专网网络汇聚、市卫生新农合、市人口健康信息化应用系统的核心网络 交换平台，当前业务流承载流量较小，可综合使用于城市市民云核心网络交换平台。核 心交换网络规划应用接入层、应用交换层、数据核心层三个层面进行构建。
[0068] 应用接入层汇聚网建设：数据接入区作为城市市民云平台终端用户访问系统的统 一入口，本次项目规划整合市民云和政务云的各种应用前置服务，包括各种应用的WEB 服务器加一些小型、非关键、测试、开发的应用系统数据库服务器；物理服务器数量较 多，并要考虑到今后方便可扩展性，通过新增加二台汇聚层设备实现。
[0069] 应用交换层汇聚网建设：应用交换层主要部署各种数据服务的中间件及接口，在 原政务云WEB应用系统迁移至城市云应用接入层后，可利用原有政务云二台思科6509 核心交换机做为城市云应用交换层汇聚使用。同时原有二台思科6509通过增加业务板 实现万兆互联。
[0070] 数据核心层汇聚网、存储网建设：数据核心层部署各种关键核心数据库、数据交 换库、中心数据库、文件存储库等。需要新购置二台数据中心级的交换机，双机组成虚 拟化后做为新的数据中心核心层交换平台，数据中心级的交换机具备先进的CLOS多级 多平面交换架构，满足多块万兆业务板的全端口线速转发能力。
[0071] 医院云、市民云(一卡通)平台
[0072] 本实施例应用服务器采用虚拟主机、通过应用负载均衡设备进行负载调度的方式 提供应用服务器基础运行环境。数据库，同时对性能、高可用性、可扩展性都有较高要 求。基本架构如图7所示。
[0073] 集群搭建时，根据应用需求、测试情况及历史经验，设计使用选择两路中端服务 器作为计算节点，并两两构建集群，其中服务器CPU选择2颗12核Xeon E5-2600v3系 列主频≧2.2G，内存选择256G。这样每个Hyper-V集群可用CPU48核、可用内存256GB (配置内存有一半预留故障迁移)，平均每核物理CPU配备5.33GB内存。
[0074] 如果平均按每个虚拟主机需要4.34核CPU、17.8GB内存计算，每个集群可承载11 台虚拟主机。根据应用需求，本期需要采用8台两路中端服务器搭建4个Hyper-V集群， 承载34台虚拟主机。
[0075] 对于应用服务器压力较大的应用需求，可利用在不同集群部署多个虚拟主机副本、 同时通过应用负载调度的方式动态增加应用处理能力。
[0076] 因为虚拟化存储主要是做文件流的输出，考虑到磁盘的IOPS、高可用的需求，设 计使用两组阵列(可扩展)+多路径管理软件共同构建一个高可用的存储服务集群，文 件采用“1正本+1副本”的方式存储。
[0077] 每组存储陈列配备48块7200RPM 2T SATA磁盘、2个10Gb万兆网口、缓存≧32G 以上、支持iSCIC或FCP存储协议输出，如将磁盘做RAID5保护，每组阵列可用空间≧ 58T。
[0078] 这样2组存储阵列之间采用“1正本+1副本”，可提供58T的可用存储空间。按平 均每个虚拟主机1.24T磁盘计算，可支持47台虚拟主机的运行。
[0079] 如果今后由于虚拟主机增加导致存储空间不足，可再增加阵列主节点或增加扩展 柜的方式增加存储容量。
[0080] 医院云、一卡通业务系统、市民数据处理及服务的相关应用都需要使用Oracle数 据库，同时对性能、高可用性、可扩展性都有较高要求。
[0081] 如图8所示，采用计算/存储融合一体的方式搭建2个Oracle 12C RAC集群，让 数据尽量靠近CPU，获取最佳的事务处理性能。根据最佳实践，两两一组做RAC集群， 如果需要扩展，再一组一组的扩展。
[0082] 参考应用系统开发厂家提出的要求，结合实际调研、测试的结果，设计使用选择 两路高端服务器作为计算节点。CPU选择2颗14核Xeon E5-2600v3系列主频≧2.6G， 内存选择512G。较大的内存配置可发挥Oracle 12C的In Memory Option性能，提高统 计、查询速度。
[0083] 这样一个由两台两路服务器做的Oracle 12C RAC集群就具备56核CPU、1024G内 存。考虑到故障冗余一个RAC集群可用28核CPU、512G内存。
[0084] 这样从计算能力来说，一卡通、医院云的云数据库基础平台搭建时实际需要4台 服务器(2C16核/512G RAM/1.6TPCIe SSD/3.6T SAS)搭建两个计算/存储融合一体RAC 集群，共配备112核CPU、2048G内存、6.4T PCIe SSD、14.4TSAS资源。
[0085] 今后如果计算能力不够，只要再一组一组增加RAC集群后调整即可。
[0086] 数据库存储介质配备两种：一种是PCIe SSD卡，用作主数据库表空间存储。利用 其读写性能高、延时小的特点，极大的加速存储IO，满足数据库高性能要求；第二种是 SAS硬盘，利用读写性能适中、性价比高的特点，满足历史数据存储、归档日志数据存 储的需求。
[0087] 参考应用系统开发厂家提出的要求，结合实际调研、测试的结果，考虑到新系统 可能有更高数据存储容量的需求，实际的存储容量配置按计算需求的3倍考虑(工程经 验)。
[0088] 参考应用系统开发厂家提出的要求，结合实际调研、测试的结果，考虑到新系统 有更高数据存储的需求。设计使用选择1.6T容量PCIe SSD卡用作主数据存储，每个节 点配置一块，做“双活”；选择900G SAS磁盘作为日志及本机备份的数据存储，每个节 点配置四块，共3.6T，也做“双活”。较大的SAS磁盘配置可存储更多的历史、日志等 非热点数据。
[0089] 这样一个由两台两路服务器做的Oracle 12C RAC集群就具备3.2T PCIe SSD、7.2T SAS，共计10.4T的存储容量。考虑到“双活”故障冗余，一个RAC集群可用1.6T PCIe SSD、3.6T SAS，共计5.2T的存储容量。
[0090] 这样从存储能力来说，一卡通、一医院其它医院HIS、PACS系统的数据库部署， 用4台配备1.6T PCIe SSD卡、3.6T SAS磁盘的服务器，搭建2个RAC集群就能满足存 储能力的需求，共提供可用3.2T PCIe SSD、7.2T SAS，共计10.4T的存储容量。
[0091] 今后如果RAC集群存储能力不够，只要再在服务器上增加PCIe SSD卡或SAS磁盘 即可。
[0092] 数据中心
[0093] 大数据处理平台：当前中心部署的城市核心系统、核心数据处理及服务系统都是 基于Oracle数据库环境的。当面临海量数据处理时，Oracle RAC也需要解决数据库性 能优化这一关键问题。整个大数据处理平台的性能瓶颈可能出现在网络和处理器等多个 领域中，但最常见的来自于缓慢的硬盘驱动器。随着应用对更快的随机输入输出需求不 断地增加，这些机械硬盘驱动器更难满足这些需求。
[0094] 在此背景下，需要采用Oracle 12C分布式数据库集群+闪存加速卡超融合存储解 决方案通过降低业务交易时间以及TCO，大规模地提升Oracle RAC的性能。同时，此解 决方案可以通过动态添加节点的方式近乎线性的扩展容量和IO性能，使其成为满足当 今大数据中心要求的高效、灵活的解决方案的首选。
[0095] 系统结构如图9所示。设计3组云数据库RAC集群，共配备6台设备提供168核 CPU、3072G内存；设计1个分布式高速存储集群，共3台设备共计37.2T、可用18.6T 存储空间(其中PCIe SSD可用空间2.4T，SAS可用空间16.2T)。
[0096] 海量小文件存储：本方案将本期建设的海量文件系统作为一个公用的文件存储基 础设施，搭建独立的存储输出网络，与应用网隔离，这样可同时供多个不同网段的系统 使用。如图10所示。
[0097] 本期采购1个存储管理节点、3个存储索引节点、8个存储数据节点，每个数据节 点配备24块4TB SATA磁盘，“1正本+1副本”，这样可提供384TB的海量文件存储空间。
[0098] 网络与信息安全
[0099] 容灾备份系统：利用现有NBU一体化备份系统及设备，将原来的本地及异地备份 系统，分别用作数据核心层备份域本地备份、数据交换及接入层本地备份。同时利用现 有48T+24T的容量进行备份，如果备份空间不足，再进行扩展。
[0100] 基本架构如图11所示。本次项目建设涉及范围广，包括卫生医疗、社会保障、电 子政务、城市视频监控等各个方面的公共信息化服务，涉及政府各职能部门、公安、卫 计委、社保、银行等多家接入单位和用户，存放有政府职能部门、公共事业单位的各类 关键、重要数据，以及如人口档案、病历等涉及公民重要隐私的数据。因此必须从全局 上进行安全设计，以形成安全、高效率、可扩展、可延伸的信息安全系统。信息安全系 统将遵循以下策略进行设计：
[0101] 等级防护：以实现等级保护为基本出发点进行安全防护体系建设，并参照国家等 级保护基本要求进行安全防护措施设计；
[0102] 分区分层：为了体现电子政务、卫计、社保等业务管理的特点，采用分区分层进 行系统建设，并依据应用系统结构及安全威胁分布情况，进行安全域划分，以实现不同 安全域的独立化、差异化防护；
[0103] 多层防御：在分域防护的基础上，将应用系统划分为数据接入、数据交换、数据 核心三个层次进行安全防护设计，以应用接入层作为用户访问应用系统的唯一入口，各 层次之间严格过滤，禁止跃层访问，避免大二层扁平化网络带来的应用层次模糊、安全 防护手段难以实现等问题，最终实现层层递进，纵深防御的应用安全防护体系结构；
[0104] 态势感知：在防护手段的基础上，将各系统及服务产生的日志、事件信息进行统 一的采集、分析，对各网站系统进行统一的安全监控，以实现网络、网站各类安全事件 可分析、可溯源；
[0105] 风险管理：以风险管理为核心，持续性的安全风险监控、评估为抓手，配备专业 的技术支撑人员队伍，以实现安全威胁得到有效抑制，安全弱点得到及时控制，安全事 件得到及时处置。
[0106] 整网信息安全策略如下：
[0107] 依照整体信息安全策略，一些技术防护、审计及监控手段需要覆盖至整网，以达 到整体的防护及监测效果。整网信息安全建设思路如下：
[0108] 进行全网统一的网络管理与安全运维管控；
[0109] 将现有网络管理系统覆盖至全网，实时监控网络设备、服务器、数据库的使用状 态和性能指标，出现异常情况实时发出短信、声音等告警，通知7*24小时值班运维人 员进行事件处理；
[0110] 将现有堡垒机(网络运维审计系统)连接至核心网络交换，覆盖全网主机服务器、 网络设备及安全设备，所有运维行为必须经过堡垒机审计，规范网络运维操作，按照自 然人划分登陆账号并进行授权，对授权人员的运维操作进行记录、分析、展现，对敏感 违规操作行为进行限制、阻断，避免核心资产或数据信息遭受损失，保障业务系统的正 常运营；
[0111] 制订信息系统(网络/安全设备、操作系统、数据库、中间件)安全配置规范，作 为信息系统的入网标准，减少不必要的权限、服务及端口开放，提升信息系统的自身防 御能力。
[0112] 在全网新建部署统一的网络防病毒及终端准入系统，在管控区域内部署网络防病 毒总控端，并在核心网络边界部署集成准入网关功能的安全防护设备实现准入功能，以 提高设备利用率，避免重复投资；
[0113] 核心网络信息安全策略如下：
[0114] 核心网络作为连接卫生专网、政务专网的中心，应用系统各层进行数据交互、内 外部用户访问网站和应用系统的主要路径，因此核心网络的安全防护、高可用性显得至 关重要。其安全建设思路如下：
[0115] 网络边界的安全防护需求在边界上部署安全措施实现，细分安全区域安全策略由 区下设各层安全防护措施实现，以减少在核心网络线路上的防护设备堆叠，同时保持足 够的安全防护能力；
[0116] 卫生专网各接入医院、政务专网均存在互联网出口，面临互联网带入的安全威胁， 在此两处边界处需要具有入侵防御的功能，同时该处边界从总体安全策略上来看用户只 能对应用接入层内的应用进行访问，需要进行IP或端口级控制。因此在上述两处边界 应新建部署具备防火墙、准入网关功能的IPS入侵防御系统，以实现安全防护及准入的 需求；
[0117] 在核心网络上采取路由旁路的方式新建部署两台具备万兆处理性能的服务器负载 均衡设备，作为应用接入层的网关，用户访问应用系统首先经过服务器负载均衡进行代 理转发和负载分担，提升应用服务器的整体性能，提高应用访问效率。
[0118] 数据接入区信息安全策略如下：
[0119] 数据接入区作为终端用户访问系统的唯一入口，承担着来自互联网、内网用户访 问应用系统的需求，也面临着互联网及不安全的终端带入的Web安全威胁。其安全建设 思路如下：
[0120] 数据接入区至核心网络交换间新建部署两台WEB应用安全防火墙，对后端所承载 的WEB应用服务进行安全防护，防止XSS、SQL注入等各种形式的攻击；
[0121] 数据接入区下的各应用系统主机、Web容器依照基线规范进行加固配置，关键、重 要应用系统使用主机防火墙，以防止跳板攻击行为；
[0122] 对于从设计上采取二层部署的应用系统，如需提供对互联网的访问路径，通过在 数据接入区搭建互联网访问安全代理服务器进行转发，以防止分层次防护结构被破坏， 策略无法有效发挥作用。
[0123] 数据交换区信息安全策略如下：
[0124] 数据交换区主要承载着各应用系统的数据通讯接口软件，主要用于接收数据接入 区的安全请求，向数据核心区发送数据库增删改查询。其安全建设思路如下：
[0125] 数据交换区至核心网络交换间新建部署两台网络防火墙，对入站流量进行控制， 并对区内跨网段访问行为进行控制；
[0126] 在此区域部署一台数据库运维桌面，并与堡垒机进行联动，用于远程维护数据库 的行为审计，禁止远程直接对数据核心区的数据库进行操作；
[0127] 数据交换区下的各接口服务器、数据传输中间件依照基线规范进行加固配置，关 键、重要的接口服务器使用主机防火墙，以防止跳板攻击行为。
[0128] 数据核心区信息安全策略如下：
[0129] 数据核心区作为整个市民云、卫生云、政务云的数据核心，存放着政府职能部门、 公共事业单位的各类关键、重要数据，以及如人口档案、病历等涉及公民重要隐私的数 据。因此对于此区域的防护至关重要，其安全建设思路如下：
[0130] 数据核心区至核心网络交换间新建部署两台网络防火墙，对入站流量进行控制， 仅允许来自应用交换层访问的数据库流量及运维流量通过，并对区内跨网段访问行为进 行控制；
[0131] 利旧当前的数据库审计系统，对关键、重要应用系统的数据库进行数据库审计， 对关键、重要应用系统的数据库操作行为进行审计，发现违规操作数据库行为；
[0132] 数据核心区下的各数据库服务器、数据库依照基线规范进行加固配置，数据库服 务器使用主机防火墙功能，以防止跳板攻击行为。
[0133] 管控区域信息安全策略如下：
[0134] 管控区域主要的功能是作为提供公共支撑和边界统一安全管理等相关服务，其中 主要包括DNS服务、政务边界防火墙的统一管理、网络防病毒等。本区域安全建设思路 如下：
[0135] 利用原核心两台千兆防火墙进行管控区域至政务专网外联核心安全边界的控制， 仅向外提供最小化的端口，以减少风险的暴露；
[0136] 利用现有的IDS入侵检测系统，对外联核心上的特定接口进行端口流量镜像，侦 听各类安全威胁事件，为安全分析人员提供分析依据；
[0137] 利用现有的上网行为审计系统，对终端用户访问互联网的行为进行审计，发现违 法访问、滥用带宽等行为，为事后追查提供依据；
[0138] 管控区下的服务器，如DNS、防火墙统一管理服务器等依照基线规范进行加固配置， 按照服务最小化原则关闭不适用服务端口。
[0139] 视频云信息安全策略如下：
[0140] 视频云主要承载的是通过城市视频监控处理后的流媒体信息，由于流媒体所采用 的传输协议(如RTP、SIP、MMS等)不同于普通TCP协议，在协议解析效率上会低于普 通的TCP流量，如部署在核心网络中会增加应用安全防护设备的负荷；同时，对于访问 者而言，访问来源主要集中在电子政务专网边界、无线专网及互联网处，如在核心网络 中会增加相当的网络迂回流量。因此，本区域安全建设思路如下：
[0141] 视频云将需要提供对外部访问的流媒体信息通过安全边界、防火墙推送至外部流 媒体服务器上；
[0142] 用户仅能访问位于防火墙后端的外部流媒体服务器，无法访问处于安全边界后的 内部流媒体资源。
[0143] 接入单位信息安全策略如下：
[0144] 接入单位主要分为电子政务及医疗机构的接入，这些接入单位主要通过专线的方 式接入到核心网络边界处。其主要需求为各单位终端访问其所需的应用系统，以及市级 政府部门的终端访问互联网。
[0145] 对于电子政务相关单位的网络接入安全，安全建设思路如下：
[0146] 在各接入单位的终端上新建部署统一的网络防病毒及准入系统；
[0147] 对所有需要访问应用系统的终端进行准入，准入基本策略为检查是否安装规定的 防病毒软件并更新到较新的病毒库版本；
[0148] 对具有终端数量大、拥有信息化维护人员的单位，在其单位本地部署准入分发服 务器，以减轻接入线路的带宽压力，避免影响本单位的业务访问。
[0149] 对于各医疗机构的网络接入安全，安全建设思路如下：
[0150] 在各医疗机构的终端上部署统一的终端准入系统；
[0151] 在三甲医院连接核心网络的边界处部署具有防火墙、入侵防御、VPN接入及准入网 关功能的一体化安全网关，一方面作为连接核心网络的边界网络防火墙，进行准入控制 和入侵防御；另一方面，医院可利用该设备，对医院网络的安全区域进行自主隔离，并 实现互联网的VPN拨号接入功能；
[0152] 对三甲医院，或具有终端数量大、拥有信息化维护人员的医疗机构，在其单位本 地部署准入分发服务器，在满足基本准入策略的基础之上，此类医院可根据自己的个性 需求增强网络内部准入的方式及准入检查策略的要求。
[0153] 专网接入信息安全策略如下：
[0154] 此部分涉及的专网主要包括国家、省政务外网、银行专网、数据交换专网、卫生 专网、社保专网、无线专网、一卡通服务机构。这些专网主要的应用需求主要为用户的 业务访问、系统对接及数据的交换处理。本区域安全建设思路如下：
[0155] 所有专网进入核心网络边界均采用防火墙进行接入，并对访问目标进行控制；
[0156] 银行专网主要实现交易系统的数据对接，接入采取地址转换的方式以实现双向不 可信、地址不可见；
[0157] 国家、省政务外网，无线专网访问业务系统需要经过入侵防御系统进行应用层安 全过滤，并只能访问应用接入层，与接入单位用户访问应用路径的防护控制方法一致；
[0158] 卫生专网、社保专网及一卡通服务机构的接入需要经过入侵防御系统及安全网关 的过滤后访问核心网络；
[0159] 数据交换专网分为数据交换用途和接口应用用途，其中公安部门的一部分数据需 要通过使用接口应用，需要采取公安前置、安全边界、政务前置、防火墙的方式接入到 数据交换区进行接口调用；
[0160] 公安及其他各部门的数据交换则采取部门前置、安全边界、政务前置、防火墙的 方式，经交换专网交换机汇聚后，通过数据中心区具备双网卡的前置数据库与数据交换 专网进行连接。
[0161] 互联网区信息安全策略如下：
[0162] 互联网区域主要功能是提供终端用户访问互联网，实现对外网站应用的发布，进 行链路层的负载均衡，保持互联网的高可用性。本区域安全建设思路如下：
[0163] 维持现有主要线路安全防护手段不变，调整备用出口的安全防护措施，以提高互 联网主出口出现故障切换后的安全性和可用性；
[0164] 备用互联网出口在主出口正常时不做流量转发；
[0165] 利用DMZ区域的防DDoS设备至互联网备用线路出口处，防止来自备用线路的拒绝 服务攻击；
[0166] 利旧两台链路负载均衡设备至互联网备用线路上，部署于DDoS设备之后，采取双 机模式运行；
[0167] 调整现有互联网出口冷备防火墙，改为热备防火墙。
[0168] 安全管理策略如下：
[0169] “三分技术，七分管理”，管理的水平和能力直接影响着信息安全工作的开展程度。 在完善各边界、区域内部安全防护与监控手段的同时，还应该加强安全管理，规范安全 行为。其安全建设思路如下：
[0170] 建立以风险管理为核心的信息安全管理体系，调整、完善现有信息安全管理体系 中不适宜现状的部分，加强对外包单位的安全管理；
[0171] 建立信息安全配置基线规范，规范设备、系统入网流程，实行设备、系统及配套 组件上线准入机制，禁止不符合规范要求的设备、系统入网上线运行；
[0172] 建设和完善安全应急响应流程，重点是网站群的安全应急响应处置流程，并制定 定期的网站安全应急演练。
[0173] 二、具体建设包括：
[0174] 核心网络系统
[0175] 按照满足城市级的核心系统、核心数据处理及服务的需求，统一整合市卫生云、 政务云的网络基础设备资源进行设计规划。本项目建设的核心网络主要由政务云接入 区、卫生云接入区、城市市民云核心网络平台三部分组成。其中城市市民云核心网络平 台规划应用接入层、应用交换层、数据核心层三个区域。
[0176] 按照本项目设计思路，分别就以下各个区域做出以下设计。
[0177] 政务云接入区
[0178] 当前政务云接入区核心路由为二台思科7606设备。为满足主干10G带宽的扩容需 求，设计将二台思科7606设备分别增扩一块4端口万兆业务板。
[0179] 卫生云接入区
[0180] 卫生云接入区核心汇聚设备使用原市人口健康信息专网二台H3C-s10508核心交换 机设备。
[0181] 城市市民云核心网络
[0182] 城市市民云核心网络交换机物理上与卫生云接入区汇聚共一个核心网络平台设 备。城市市民云核心网络平台分应用接入层、应用交换层、数据核心层三个区域。
[0183] 核心交换网
[0184] 城市市民云二台H3C-s10508交换机需要分别与政务云接入区二台核心思科7606、 城市市民云应用接入层、应用交换层、数据核心层分别做万兆双线冗余，同时二台设备 本身需要升级IRF虚拟化万兆互联线路。设计在现有的二台H3C-s10508交换机上各增 配一块32端口万兆业务板用于万兆互联。
[0185] 应用接入层汇聚网
[0186] 应用接入层主要用于对外发布市民云与政务云的WEB应用服务。当前政务云及卫 生云区域应用系统部署以迁移需要一个平衡过渡期，并考虑到向上万兆双端口互联，向 下级联千兆应用交换机及今后的扩展需求，设计应用接入层新购置二台汇聚层接入交换 机，双机做虚拟化部署实现高可靠性。单机配置满足
[0187] (1)余主控板；冗余电源；业务板扩展槽位≥6；交换容量≥10.24Tbps；转发 性能≥2880Mpps；详见下节设备关键参数设计说明部分。
[0188] (2)≥120个千兆以太网电接口:用于市民云HPV2012应用12台、政务云HPV2008 应用25台、曙光CLOUDVIEW平台应用服务器20台，其它应用服务器20台。
[0189] (3)≥20个千兆以太网光接口，≥16个千兆光接口多模块(850nm,0.55km,LC)： 用IBM小机应用2台、IBM刀箱3台、现有千兆交换机联级6台及今后扩展性需求。
[0190] (4)≥4个万兆以太网光接口，≥4个万兆多模块(850nm,300m,LC)：用于上联 市民云核心交换机万兆互联。
[0191] (5)≥80Gb通道用于虚拟化或群集(配置相应电缆及光模块)：用于双机虚拟化 或群集部署，以及双机之间的数据高速存储转发。
[0192] (6)满足上述业务板接口全线速转发能力。
[0193] (7)设备入网证满足一年以上。
[0194] 应用交换层汇聚网
[0195] 数据交换区主要用于各应用系统中间件、APP接口、数据共享接口的服务器部署。 待政务云应用系统迁移至城市市民云应用接入层完成后，可利用现有的政务云二台思科 6509交换机做为城市市民云应用交换层汇聚设备使用。为满足与城市市民云二台 H3C-s10508核心交换机万兆互联，设计对二台思科6509交换机各配一块4端口万兆板。
[0196] 数据核心层汇聚网、存储网
[0197] 数据核心层部署各种关键核心数据库、数据交换库、中心数据库、文件存储库等。 本项目中主要涉及到：卫生云和市民云平台中的万兆磁盘阵列、万兆海量小文件存储、 现有各云平台的数据库集群等，物理服务器数量较多。考虑至今后的可扩展性，设计新 购置二台数据中心级交换机。数据中心级交换机设计单机配置满足：业务板扩展槽位≥ 10；含交流主机；冗余主控板；冗余交换网板；冗余风扇以及冗余电源；CLOS多级多平 面交换架构；满足多块万兆业务板的全端口线速转发；交换容量≥80Tbps；转发性能≥ 24000Mpps；≥80Gb通道用于虚拟化或群集(配置相应电缆及光模块)；≥48端口千兆 电口以太网接口；
≥48端口千兆以太网光接口；≥48端口万兆以太网；≥48光接口万 兆模块；≥16千兆光模块-SFP-GE-多模模块-(850nm,0.55km,LC)；含安装滑轨附件及电 源线；设备入网证满足一年以上。配置需求说明如下：
[0198] (1)、业务板扩展槽位≥10；含交流主机；冗余主控板；冗余交换网板；冗余风 扇以及冗余电源；CLOS多级多平面交换架构；满足多块万兆业务板的全端口线速转发； 交换容量≥80Tbps；转发性能≥24000Mpps；≥80Gb通道用于虚拟化或群集(配置相应 电缆及光模块):详见下节设备关键参数设计说明部分。
[0199] (2)、≥48端口千兆电口以太网接口：用于市民云4台数据库服务器、政务云6 台数据库服务器互联，及今后的扩展需求互联。
[0200] (3)、≥48端口千兆以太网光接口；≥16千兆光模块-SFP-GE-多模模块 -(850nm,0.55km,LC)：用于2台IBM小机数据库互联及今后数据库服务器扩展。
[0201] (4)、≥48端口万兆以太网；≥48光接口模块；主要用于市民云平台存储阵列 2台、海量文件服务器8台、备份主机2台、或8端口万兆双机虚拟化；并考虑到今后 政务云及市民云存储网的扩展性及设备业务板的冗余性。
[0202] (5)、≥80Gb通道用于双机虚拟化或群集(配置相应电缆及光模块)；
[0203] (6)、满足上述业务板接口全线速转发能力。
[0204] 设备关键参数设计说明
[0205] 为保障城市市云平台核心网络设备高可靠性设计目标，设计本项目中的数据接入 层汇聚交换机和数据中心级交换机单机配置均满足双电源、双引擎以上的基本配置需 求。同时对二种不同级别交换机的包转发率、交换容量、硬件架构分别给出了以下设计：
[0206] 注：对交换机包转发率及交换容量的重要参考指标说明
[0207] 交换机是负责将收到的数据以数据包形式转发出去的。因此包转发率标志了交换 机转发数据包能力的大小，是指交换机每秒可以转发多少百万个数据包(Mpps)。就像 道路交通一样，想通过能力高的话，要么路要宽(同时通过的能力强)，要么通过速度 快。而交换容量就相当于路宽，带宽越高，同时通过的数据包就越多，意味着所能处理 数据的能力就越强，使得包转发率越高。
[0208] 包转发率是以单位时间内发送64字节数据包的个数作为计算基准的。当以太网帧 为64字节时，需要考虑8字节的帧头和12字节的帧间隙开销。以千兆以太网为例，计 算方法为：1000Mbps/8b/(64+8+12)byte＝1488095pps，据此，一台交换机的包转发 速率计算公式如下：
[0209] 包转发率＝万兆端口数*14.88Mpps+千兆端口数*1.488Mpps
[0210] 交换容量代表了交换机各接口之间所能进行的数据交换的最大能力，单位为Gbps。 交换机总交换容量的计算机公式为：
[0211] 交换容量＝端口数*端口速率*2(全双工模式)
[0212] 应用接入层汇聚交换机
[0213] (1)考虑到目前国内主流厂家品牌对该型产品选型搭配不同，业务板槽位可能 需要3－5块，并估计到后期可能的扩展性，设计选型具备6槽位以上业务板。
[0214] (2)数据包转发速率指标
[0215] 设备中的双机虚拟化或群集满足80G端口(双机虚拟化使用)全线速转发能力计 算；六个业务槽位按满足48个千兆端口+4个万兆端口全线速转发能力计算。则整机需 要具备的包转发能力指标计算公式如下：
[0216] 包转发率＝2*4*14.88Mpps+6*(4*14.88+48*1.448)Mpps＝893Mpps
[0217] 交换机包转发率越高，表示交换机对数据包的转发能力越好。本项目中实际采购 应用接入层汇聚交换机包转发性能满足≥2880Mpps
[0218] (3)设备交换容量指标
[0219] 依前述公式整机需要具备的交换容量指标计算公式如下：
[0220] 交换容量＝((2+2)*40G+6*(44*1G+4*10G))*2＝1.168T
[0221] 交换机交换容量越高，表示该型设备数据总交换能力越大。本项目中实际采购应 用接入层汇聚交换机交换容量满足≥10.24Tbps
[0222] 数据中心级交换机
[0223] (1)设备硬件架构具备CLOS多级多平面交换架构：能够配置独立的交换网板与 独立的主控板，交换网板与主控板硬件槽位分离，业务板卡与交换网板采用完全正交设 计,多块交换网板同时分担业务流量。设计单机配置主控板2块，交换网板采用具备冗 余能力，同时满足双机虚拟化功能。考虑到目前国内主流厂家品牌对数据中心级产品选 型不同，所选业务板槽位估计需要10块以上，并估计到后期可能的扩展性，设计选型 数据中心级设备具备10槽位以上业务板。
[0224] (2)数据包转发速率指标
[0225] 本项目中数据中心级交换机按满足10个业务槽位扩展及冗余能力设计，每个业 务槽位按满足48个万兆端口全线速转发能力计算,则整机需要具备的包转发能力指标计 算公式如下：
[0226] 包转发率＝10*48*14.88Mpps＝1190.4Mpps
[0227] 交换机包转发率越高，表示交换机对数据包的转发能力越好。本项目中设计实 际采购数据中心级交换机包转发性能满足≥24000Mpps
[0228] (3)设备交换容量指标
[0229] 依前述公式整机需要具备的交换容量指标计算公式如下：
[0230] 交换容量＝万兆端口数*10G*2*槽位数＝48*10G*2*10＝9.6T
[0231] 交换机交换容量越高，表示该型设备数据总交换能力越大。本项目中实际采购数 据中心级交换机交换容量满足≥80Tbps。
[0232] 医院云、市民云(一卡通)平台
[0233] 云计算平台设计采用Windows Server 2012来搭建。相较于Windows Server 2008， Windows Server 2012对于云计算平台进行提升。
[0234] 多租户的安全与隔离：Windows Server 2012通过Hyper-V可扩展交换机技术提 供了新的安全与隔离功能。
[0235] Hyper-V可扩展交换机(Hyper-V Extensible Switch)是一种第二层上的虚拟网 络交换机，可提供编程式的管理和扩展功能，让虚拟机通过借助策略强制实施的安全与 隔离设置连接到物理网络。
[0236] 在Windows Server 2012中，可以配置Hyper-V服务器对任何隔离组强制实施 网络隔离，而这样的隔离组通常可为特定客户或一组负载专门指定。
[0237] Windows Server 2012通过下列新功能为多租户环境提供隔离与安全：通过私有 虚拟LAN(PVLAN)隔离多租户虚拟机。
[0238] VLAN技术通常用于划分网络，并为共享同一物理基础架构的不同组提供隔离。 Windows Server 2012开始支持PVLAN，这种技术可与VLAN配合使用在同一VLAN的 不同虚拟机之间，借此即可实现隔离。
[0239] 如果虚拟机不需要与其他虚拟机通讯，即可使用PVLAN将其与数据中心 内的其他虚拟机隔离。通过将每台虚拟机分配到PVLAN，会创建一个主要 VLAN ID以及一个或多个从属VLAN ID，可以将这些从属PVLAN设置为下列 三种模式之一。这些PVLAN模式决定了一台虚拟机可以与同PVLAN中的哪 些其他虚拟机通讯。如果想要隔离某台虚拟机，只要将其设置为隔离模式即 可。
[0240] PVLAN模式描述：
[0241] 隔离(Isolated)被隔离的端口无法在第二层与其他端口交换数据包。
[0242] 混合(Promiscuous)混合模式的端口可与具有相同主要VLAN ID的任何其他端 口交换数据包。
[0243] 公共(Community)位于相同VLAN ID的公共端口可在第二层交换数据包。
[0244] 保护防范地址解析协议(Address Resolution Protocol)/邻居发现(Neighbor Discovery，ARP/ND)仿冒。
[0245] Hyper-V可扩展交换机可防范恶意虚拟机通过ARP仿冒方式从其他虚拟机处盗用 IP地址(在IPv4中这种做法也叫做ARP投毒)。通过这种类型的中间人攻击，恶意 虚拟机即可发送假冒的ARP信息，并将自己的MAC地址与自己不具备的IP地址相关 联。可信虚拟机会将网络通讯发往恶意虚拟机的MAC地址所对应的IP地址，而不是 最初想要联系的目标。对于IPv6，Windows Server 2012也针对ND仿冒提供了相似 的保护。
[0246] 保护防范动态主机配置协议(DHCP)仿冒与DHCP防护。
[0247] 在DHCP环境中，伪造的DHCP服务器可以拦截客户端DHCP请求，并提供错误 的地址信息。伪造的DHCP服务器可能会导致通讯被路由到恶意中间方，而这样的中间 方可以首先嗅探所有通讯，随后才将其转发到合法目的地。为了防护这种特殊的中间人 攻击，Hyper-V管理员可以指定DHCP服务器所能连接到的Hyper-V可扩展交换机端 口。来自其他Hyper-V可扩展交换机端口的DHCP服务器通讯会被自动丢弃。Hyper-V 可扩展交换机已经可以保护防范伪造的DHCP服务器尝试提供可能导致通讯被重新路由 的IP地址。
[0248] 数据中心
[0249] 按照云中心承载的业务分类，一部分是轻型的前端应用(如web、小型app等)， 目前已经基本迁移部署到基于虚拟化技术的基础架构云平台上；另外个别数据量较大、 系统及IO负载比较高的中型应用(主要是结构化的数据库)，当前还分布在传统的IOE 系统架构上，比如公务员门户系统。另外还有近百个轻量的数据库应用部署在虚拟化技 术的基础架构云平台上。
[0250] 目前核心数据处理及服务的数据库部署存在两个方面的问题：
[0251] (1)在虚拟主机中运行的数据库，其IOPS及计算处理能力受到虚拟化平台的限 制，随着部分系统的业务处理量增加，已出现访问瓶颈；
[0252] (2)传统的IOE架构方案技术成熟、系统稳定可靠；但该架构延续了差不多将近 二十年时间没有大的变化更新，基本只能靠纵向扩展(升级换代)满足业务扩展性需求， 难以横向扩展(严重依赖特定应用)，同时整个架构中SAN存储是整个系统的性能瓶颈 和故障单点，难以灵活的扩展系统(存储)性能；且该架构与目前业界“去IOE”潮流 和unix转linux趋势(u2l)相违背。
[0253] 由于城市核心系统、核心数据处理及服务等系统的需要，需要搭建一套可扩展的 高性能大数据处理基础平台。按照最新的研究成果可采用Oracle 12C云数据库技术， 利用多租户架构以及可插拔的数据库技术，实现业务数据库的“云”化并支持大数据处 理。
[0254] 对于云数据库平台，由于业务数据库多、数据总量大，数据统计分析计算量大， 因此对于存储的要求和数据库服务器的要求都非常高。如果基于传统架构构建云数据库 平台会存在如下的问题：
[0255] (1)数据库节点需要高性能主机，成本高。对于多节点RAC数据库，由于节点间 的通信带宽通常为1Gbps，较高的为10Gbps，这个数量级的带宽使得节点间的并发处理 能力没有充分利用。
[0256] (2)数据库的瓶颈通常在IO上面，传统的磁盘阵列受限于控制器的处理能力和 FC端口带宽，IO吞吐量通常只能几百MB/s，在大数据量处理时，IO消耗的时间过长。
[0257] (3)传统存储扩展能力较差，在容量增加时，性能没有相应提高。同时扩容成本 高。
[0258] 随着信息惠民及智慧城市建设的深入与发展，云中心承载的业务种类与量越来越 大，同时业务增长和变化的速度也越来越快，这对整个中心数据平台的架构建设提出了 更高的要求。
[0259] 为了提高整个云平台的资源分配的灵活能力，提升技术创新能力和践行安全自主 可控的技术路线，参照目前业界技术趋势，有必要探索和构建基于标准x86硬件与分布 式软件技术构建x86高性能分布式云数据库融合系统。
[0260] 该融合系统架构是近年随着数据库技术、Flash存储技术和server san架构兴起 的一种新的体系架构(融合系统)，其系统即是通过标准x86 PC服务器、工业标准存储 系统(内部硬盘、外部存储系统)、高速互联网络、底层存储管理软件构建x86高性能 融合系统平台，提供运行应用所需要的计算资源和存储资源及网络接口。
[0261] Exadata一体机的大量成功案例，证实了以x86服务器为基础、使用闪存卡、 Infiniband交换网可以使Oracle RAC达到很高的处理能力和IO吞吐量。
[0262] 中心机房通过技术验证和测试，借鉴Exadata的架构，提出云数据库解决方案： 采用Oracle 12C云数据库、x86服务器、PCI-E SSD硬盘卡、Infiniband交换网形成的 轻量级、低成本、高性能、可扩展的整体解决方案。
[0263] 当前中心部署的城市核心系统、核心数据处理及服务系统都是基于Oracle数据库 环境的。当面临海量数据处理时，Oracle RAC也需要解决数据库性能优化这一关键问题。 整个大数据处理平台的性能瓶颈可能出现在网络和处理器等多个领域中，但最常见的来 自于缓慢的硬盘驱动器。随着应用对更快的随机输入输出需求不断地增加，这些机械硬 盘驱动器更难满足这些需求。
[0264] 在此背景下，需要采用闪存加速卡超融合存储解决方案通过降低业务交易时间以 及TCO，大规模地提升Oracle RAC的性能。同时，此解决方案可以通过动态添加节点的 方式近乎线性的扩展容量和IO性能，使其成为满足当今大数据中心要求的高效、灵活 的解决方案的首选。
[0265] ParaStor200系统包含四类组件：索引控制器oPara、数据控制器oStor、应用服 务器oApp和管理控制器MGR。其中，索引控制器用于管理存储系统的命名空间和所有索 引数据，对外提供单一的全局映像。数据控制器提供数据存储空间，并实现存取动作， 支持多个数据副本。应用服务器即客户端，可以通过多种数据访问接口访问并行存储， 并支持多种64位Linux操作系统和Windows系统。管理控制器提供统一的控制管理界 面，管理员通过该节点管理整个系统。
[0266] 整个数据集合均匀地分散在不同的数据控制器上，用户访问索引控制器得到文件 位置信息后，直接访问数据控制器读写数据。这种控制路径和数据路径分离的方式，分 散了索引控制器的负载，可获得极高的聚合带宽，也大大提高了系统的扩展性。
[0267] 每个组件通过多条独立的网络链路相互访问，支持千兆、万兆以太网和Infiniband 高速网络等。
[0268] 存储系统的索引数据，包括目录和文件副本信息等数据描述信息的关键数据。索 引控制器提供索引数据的访问服务。
[0269] ParaStor实现了多索引控制器架构，所有控制器同时使用，从而提供几乎不受限 制的单一命名空间和很高的索引数据服务能力。索引控制器成组使用，按组扩展。每个 组包含2台索引控制器，它们之间不使用任何共享设备，但通过互为备份，保存着完全 相同的内容。2个节点之间互发心跳，一旦判断到对方失效，立即接替失效节点，使用 本地存储的全部数据，对外提供服务。
[0270] 索引数据以普通文件的方式存储于索引控制器的本地存储设备上，通过日志，实 现组内数据同步，以确保索引数据的可靠性。
[0271] 利用弹性的目录索引技术，实现文件路径到索引数据位置的快速映射，可使每个 目录支持的子目录或文件数目达到千万级，而解析操作仍保持良好的响应时间范围内。
[0272] 数据控制器集群中的成员以全对等方式，提供数据存储服务。每个控制器在自已 的存储设备上保存整个命名空间的一部分数据，直接对用户提供数据读写功能。数据控 制器之间通过多套网络互联，既提高系统带宽，也提高网络系统的可用性。数据控制器 之间不共享任何部件。
[0273] 采用多副本方式提高数据可用性，同一个文件的多个副本存储在不同的服务器上， 即使整个控制器失效，也会由其它控制器的上副本数据对外提供服务。
[0274] 大型数据分成若干片段(对象)存储在不同的设备上，所有这些数据对象的存储 和访问的细节都由数据控制器本地实现。这种存储空间分层管理的设计减轻了软件管理 元数据的复杂程度，相比StorNext等SAN存储系统大大提高了系统的扩展性和单一命 名空间的容量。
[0275] ParaStor采用24盘位的曙光I640存储服务器作为数据控制器，采用1TB、3TB、 4T的SATA磁盘及各种规格的SAS磁盘，每个控制器可以提供近100TB的存储空间。
[0276] 网络与信息安全
[0277] 按照当前所承载的业务及功能分类，主要分为核心网络、数据接入区、数据交换 区、数据核心区、管控区域、视频云区、互联网区、专网接入区及各接入单位区。其中， 各功能区所面临的安全威胁各不相同，需要依据等级保护三级的相关要求规划各功能区 的安全区域，确定安全边界或安全区域内的信息安全防护需求，采用不同的安全产品实 现整体的信息安全，配合配套的安全服务实现安全产品的最大效率利用，形成纵深防御 的网络安全体系架构。
[0278] 在信息安全总体建设思路上，同时还需要考虑到控制信息安全建设成本，优化信 息安全资源配置，简化区域内部结构，提升管理效率，保留设备可扩展空间等方面的问 题，并保持信息安全策略的一致性、全局性和可扩展性。
[0279] 在运维管理、客户端准入、防病毒、日志事件收集与分析，以及配套安全服务方 面，涉及面覆盖全网，具有整网建设的必要性，需要从全局上统筹考虑建设。
[0280] 目前，在政务云中部署有一套网络管理系统(以下简称“美信云”)及网络运维安 全审计系统(以下简称“堡垒机”)，已实现网络设备、服务器及数据库的性能及可用性 监控，对远程运维行为的全过程审计。
[0281] (1)将现有美信云通过管理网络覆盖至全网，实时监控网络设备、服务器、数 据库的使用状态和性能指标，出现异常情况时实时发出短信、声音等告警，通知7*24 小时值班运维人员进行事件处理；
[0282] (2)将现有堡垒机连接至核心网络，并且对所需运维的资源进行网络端口控制， 即所有运维行为需通过堡垒机登陆操作，按照自然人划分登陆账号并进行授权，对授权 人员的运维操作进行记录、分析、展现，对敏感违规操作行为进行限制、阻断，避免核 心资产或数据信息遭受损失，保障业务系统的正常运营。
[0283] 结合提供的安全风险评估报告，建立网络/安全设备、操作系统、数据库、中间 件安全配置基线规范，作为系统入网的强制要求，系统资源自分配起应满足配置基线规 范。
[0284] 对于已上线系统，制定各类网络设备、系统的配置安全加固方案和组网结构的调 整方案，并在业务影响最小化的原则下对加固方案进行实施。
[0285] 对因威胁态势发生变化导致现有安全配置不足以防护的系统需要可修复风险评 估，应制定修复加固方案，确保在不影响系统正常运行的情况下进行有效的修复。
[0286] 对未能及时修复的系统进行安全加固，通过调整细化安全防护设备策略，对重要、 基础服务资源按照“端口最小化”原则进行访问控制。
[0287] 终端的安全主要体现在两个方面，一方面是终端自身的安全性，当前终端主要面 临的威胁来源是病毒、木马，而大量的客户端如遭到病毒、木马感染或入侵，就会形成 僵尸网络，给终端用户自身的终端和业务应用带来安全隐患；另一方面是客户端接入网 络的可信，如何保证可信的客户端来访问业务应用。
[0288] 当前，越来越多的客户端普遍遭到病毒、木马的感染，甚至沦为僵尸网络，对数 据中心内的业务安全、网络可用性带来了相当大的威胁和挑战。同时，多套防病毒软件 的使用也会造成运维效率的下降、管理成本的上升，也会存在软件兼容性的风险，因此 本方案设计在全网范围内针对终端进行统一的网络防病毒及准入系统。
[0289] 通过部署网络防病毒系统，可以有效地缩小僵尸网络的范围，保护终端用户本地 资源的安全；采取网络准入，一方面可实现可信终端访问所需应用系统，同时利用网络 准入可检查防病毒软件安装率和病毒库更新率，侧面提升了终端安全。
[0290] 网络防病毒及准入系统采取相互捆绑、分布式方式部署，通过在核心网络管控区 域中部署网络防病毒及准入系统总控制端，实现对策略集、病毒库的统一更新与各分发 服务器的集中管控；在核心网络边界部署准入网关，实现对接入终端的准入控制，同时 对访问区域内的深层攻击行为进行准确的分析判断并对威胁到系统内应用的攻击行为 进行实时阻断；各接入单位部署防病毒及准入策略分发服务器，终端上安装防病毒及准 入一体化客户端，实现在满足基本准入要求之上，面向各接入单位的策略自定义、网络 远程诊断等需求；对于较小规模的接入单位缺乏独立的服务器资源，缺少运维人员的情 况，在管控区域内可根据终端规模分别部署多台虚拟服务器作为分发服务器，以减轻总 控制端的压力。
[0291] 由于政务云和医疗云所涉及终端数量巨大，考虑到终端用户的使用体验，以及大 量终端用户如集体访问准入服务器下载防病毒和准入客户端软件，会对核心网络造成重 大冲击，因此本次网络及防病毒采取按照接入单位分区分片进行部署，对于尚未部署的 接入单位节点，在准入网关上采取白名单方式进行临时排除。
[0292] 而在医疗云中，各二三甲医院、社区医疗机构中的终端计算机有强烈的防病毒、 终端准入及网络远程诊断需求存在，因此需要先期实施各二三甲医院、社区医疗机构的 终端防病毒及准入。
[0293] 网络防病毒及准入系统由客户端、服务端、准入网关组成，具体部署方式如下：
[0294] a)客户端：
[0295] 通过人工现场安装的方式部署网络防病毒及准入一体化客户端，未安装客户端的 终端在访问受控区域时，由准入网关重定向至客户端下载区强制要求客户端。
[0296] 对于用户重装系统、硬件发生变更的终端用户，将在变更后首次访问应用系统时 提示下载网络防病毒及准入一体化客户端，客户端可采取自动化静默安装方式进行，以 减少用户参与度。
[0297] b)服务端：
[0298] 在管控区部署网络防病毒及准入系统总控制端，制订总体准入策略、从互联网获 取最新病毒特征库，分发至各分发服务器。
[0299] 分发服务器在各接入单位本地或在管控区域建立虚拟服务器托管，由总控服务器 统一进行权限管理和策略下发，各本地建设有分发服务器可基于策略之上进行自定义策 略。
[0300] 其他不具备本地分发服务器的接入单位由部署在管控区域的分发服务器直接对终 端进行策略下发和软件推送。
[0301] c)准入网关：
[0302] 三甲医院至卫生云网络出口位置部署一体化安全网关，其他接入单位在连接核心 网络边界处部署具有准入网关功能的IPS入侵防御系统，对需要访问数据中心应用系统 的终端进行行为审计、安全基线核查，对受威胁的终端访问核心数据等资源时进行控制。
[0303] 在市民云中，由于部分医院拥有自建的网络防病毒系统，在考虑保护前期投资的 前提下，设计防病毒及准入系统采取弱捆绑方式、分布式部署，在政务云核心网络下部 署网络防病毒及准入总控服务器。
[0304] 对于三甲医院，在连接市民云的网络边界处配套部署一体化安全网关进行准入控 制，在终端访问数据通过准入网关时进行终端的安全基线进行核查，对不满足要求和未 安装网络客户端的终端禁止接入市民云平台。同时一体化安全网关还具备入侵防御功 能，可对访问区域内的深层攻击行为进行准确的分析判断并对威胁到系统内应用的攻击 行为进行实时阻断。
[0305] 对于二甲医院及各分散医疗机构，在市民云核心区域出口串行部署万兆IPS入侵 防御系统，同时作为二甲医院和各分散医疗机构终端网络准入网关使用。通过对访问区 域内的深层攻击行为进行准确的分析判断并对威胁到系统内应用的攻击行为进行实时 阻断。
[0306] 其他医疗机构在卫生专网汇聚后，连接卫生云的网络边界部署入侵防御系统，对 需要接入市民云应用的终端进行行为审计、安全基线核查，对受威胁的终端访问核心数 据等资源时进行控制。
[0307] 核心网络作为连接卫生专网、政务专网的中心，应用系统各层进行数据交互、内 外部用户访问网站和应用系统的主要路径，接入核心网线路众多，必须清晰划分安全边 界，制定访问控制策略。另外，卫生专网、政务专网均存在互联网出口，面临互联网带 入的安全威胁，因此核心网络的边界安全防护、核心高可用性显得至关重要。
[0308] 在卫生云出口边界部署一台万兆IPS入侵防御系统，配置防火墙、准入网关等功 能。通过准入控制来要求接入单位终端必须达到安全基线来访问内部网络，并进行严格 的安全策略访问控制和入侵防范监控，原则上只允许接入单位终端访问数据接入区，对 其他区域的数据请求全部拒绝。
[0309] 在政务云核心路由和核心交换机之间部署两台万兆IPS入侵防御系统，A-A模式互 为热备。对来自互联网终端和政务网接入单位的终端进行严格的安全策略访问控制和入 侵防范监控，原则上只允许互联网终端和政务网接入单位终端访问数据接入区，对其他 区域的数据请求全部拒绝。
[0310] 在核心交换机旁挂方式部署两台万兆应用负载均衡设备，A-A模式互为热备，作为 应用接入层的网关，用户侧访问应用系统首先经过服务器负载均衡进行代理转发和负载 分担，提升应用服务器的整体性能，提高应用访问效率。
[0311] 网络接入控制管理系统能够强制提升网络终端的接入安全，保证网络保护机制不 被间断，使网络安全得到更有效提升。与此同时基于设备接入控制网关，还可以对于远 程接入企业内部网络的计算机进行身份、唯一性及安全认证。通过网络接入控制管理 系统可以满足企业要求，将设备接入控制扩展到超出简单远程访问及路由器、专有协议 和已管理设备的限定之外；能够覆盖到企业网络的每一个角落，甚至是当使用者拿着他 们的移动设备离开企业网络时，仍能有效的提供设备接入控制的执行。网络接入控制管 理系统针对所有的网络架构工作，并且不必进行昂贵的网络架构改造
[0312] 数据接入区拥有近百套应用系统程序，涉及宜昌**市政府各个部门，绝大多数以 Web应用为主。而Web应用的迅速发展也引起黑客们的强烈关注，接踵而至的就是Web 安全威胁的凸显，黑客利用网站操作系统的漏洞和Web服务程序的SQL注入漏洞等得到 Web服务器的控制权限，轻则篡改网页内容，重则窃取重要内部数据，更为严重的则是 在网页中植入恶意代码，使得网站访问者受到侵害。
[0313] 在核心交换机和数据接入区汇聚交换机之间部署WEB防火墙系统，A-A模式互为热 备，保持会话同步，在单路出现故障时能够快速收敛。主要针对Web服务器进行 HTTP/HTTPS流量分析，防护以Web应用程序漏洞为目标的攻击，有效拦截目前网络中存 在的大量SQL注入等威胁，并针对Web应用访问各方面进行优化，以提高Web或网络协 议应用的可用性、性能和安全性，确保Web业务应用能够快速、安全、可靠地交付。
[0314] 应用接入层作为用户访问应用系统的唯一入口，必须在核心区IPS入侵防御系统 上针对数据接入区配置严格的访问控制策略，针对远程客户端控制其只能访问相应系统 的相应端口。
[0315] 结合前期的安全风险评估报告，建立操作系统、网站程序、中间件配置基线规范， 作为系统入网的强制要求，系统资源自分配起应满足配置基线规范。对于已上线系统， 制定系统的配置安全加固方案和组网结构的调整方案，并在业务影响最小化的原则下对 加固方案进行实施。对因安全攻防环境变化导致现有配置不足以防护的系统需要可修复 风险评估，制定修复规范，确保在不影响系统正常运行的情况下进行有效的修复。对未 能及时修复的系统进行安全加固，通过调整细化安全防护设备策略，对重要、基础服务 资源按照“端口最小化”原则进行访问控制。
[0316] 作为应用接入层和数据核心层的桥梁，数据交换区部署有各种应用的数据中间件、 数据接口、数据逻辑服务器。主要用于接收数据接入区的安全请求，向数据核心区发送 数据库增删改查询等。
[0317] 根据以上描述，安全建设如下：
[0318] 网络安全：数据交换区至核心网络交换间新建部署两台万兆网络防火墙互为备份， 透明桥模式接入。主要针对区域内的数据中间件、数据接口等服务器进行访问控制，原 则上相应的程序只允许来自应用接入层的请求数据，其他区域的数据请求则一概拒绝； 同时开放该区域中间件程序向数据核心区发送的数据库操作请求。
[0319] 数据库安全：域划分、分区分层后通过访问控制策略已经严格控制终端用户直接 请求数据核心区数据资源，但有时IT运维人员会对数据库进行日常维护的需求，根据 安全策略原则只有数据交换区有访问核心数据区资源的权限。故在此区域部署一台数据 库运维桌面，并与堡垒机进行联动，用于远程维护数据库的行为审计，禁止远程直接对 数据核心区的数据库进行操作。
[0320] 主机安全：结合前期的安全风险评估报告，建立操作系统、中间件配置基线规范， 作为系统入网的强制要求，系统资源自分配起应满足配置基线规范。对于已上线系统， 制定系统的配置安全加固方案和组网结构的调整方案，并在业务影响最小化的原则下对 加固方案进行实施。对因安全攻防环境变化导致现有配置不足以防护的系统需要可修复 风险评估，制定修复规范，确保在不影响系统正常运行的情况下进行有效的修复。对未 能及时修复的系统进行安全加固，通过调整细化安全防护设备策略，对重要、基础服务 资源按照“端口最小化”原则进行访问控制。
[0321] 应用核心区信息安全建设内容：据核心区作为整个市民云、卫生云、政务云的数 据核心，存放着政府职能部门、公共事业单位的各类关键、重要数据，以及如人口档案、 病历等涉及公民重要隐私的数据，只接受数据交换区的数据请求，其他区域的请求一概 拒绝。
[0322] 根据以上描述，安全建设如下：
[0323] 安全：数据核心区至核心网络交换间新建部署两台万兆网络防火墙互为备份，透 明桥模式接入。主要针对区域内的数据库服务器进行访问控制，原则只接受数据交换区 的数据请求，其他区域的请求一概拒绝。
[0324] 安全审计：利旧当前的数据库审计系统，旁路部署在数据核心区汇聚交换机上， 通过交换机端口镜像对关键、重要应用系统的数据库进行数据库审计，对关键、重要应 用系统的数据库操作行为进行审计，发现违规操作数据库行为。
[0325] 主机安全：结合前期的安全风险评估报告，建立操作系统、数据库配置基线规范， 作为系统入网的强制要求，系统资源自分配起应满足配置基线规范。对于已上线系统， 制定系统的配置安全加固方案和组网结构的调整方案，并在业务影响最小化的原则下对 加固方案进行实施。对因安全攻防环境变化导致现有配置不足以防护的系统需要可修复 风险评估，制定修复规范，确保在不影响系统正常运行的情况下进行有效的修复。对未 能及时修复的系统进行安全加固，通过调整细化安全防护设备策略，对重要、基础服务 资源按照“端口最小化”原则进行访问控制。
[0326] 本文中所描述的具体实施例仅仅是对本发明精神作举例说明。本发明所属技术领 域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式 替代，但并不会偏离本发明的精神或者超越所附权利要求书所定义的范围。
相关专利内容
标题 发布/更新时间 阅读量
一种核电站控制室故障降级运行方法及系统-专利编号CN110570960A 2020-05-13 167
一种智能网联汽车信息安全保护方法-专利编号CN109088848A 2020-05-18 822
一种电力二次系统主动安全防御系统-专利编号CN104333551A 2020-05-16 313
一种基于云端的智能安全防御系统和方法-专利编号CN103118036A 2020-05-15 792
攻防一体抓捕叉-专利编号CN110779383A 2020-05-14 490
一种基于SDN的工业控制系统动态防御方法及装置-专利编号CN109862045A 2020-05-17 628
一种海上作战防空部署优化设计方法-专利编号CN108520312A 2020-05-19 877
一种基于软件定义网络的安全防御系统及防御方法-专利编号CN104023034B 2020-05-20 351
一种有效应对APT攻击的纵深防御系统-专利编号CN107659582A 2020-05-11 567
一种有效应对APT攻击的纵深防御系统-专利编号CN207518625U 2020-05-12 859
高效检索全球专利

IPRDB是专利检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。

我们的产品包含105个国家的1.26亿组数据，专利查询、专利分析。

电话：13651749426

侵权分析

IPRDB的侵权分析产品是IPRDB结合多位一线专利维权律师和专利侵权分析师的智慧，开发出来的一款特色产品，也是市面上唯一一款帮助企业研发人员、科研工作者、专利律师、专利分析师快速定位侵权分析的产品，极大的减少了用户重复工作量，提升工作效率，降低无效或侵权分析的准入门槛。

立即试用

纵深防御热门专利
热门文章

IPRDB

最新中国发明专利 最新美国发明专利 技术领域 专利库 专利分类库 国际专利分类库

热门服务

会员版试用 API 数据接口 找代理 知嘟嘟专利交易 排行榜 大学排行榜 专利百科

关于我们

平台介绍 战略合作 网站地图

友情链接

知嘟嘟专利交易 国家知识产权局 中国商标网

联系方式


©2019-2023 上海吉码数字技术有限公司 版权所有，并保留所有权利 沪ICP备20016256号-6 沪公网安备31011702005475号