基于集群的水文数据安全性能提升对策

2021-01-20梁冰

水利信息化 2021年4期

梁冰

（辽宁省河库管理服务中心（辽宁省水文局），辽宁沈阳 110003）

随着水文数据量的不断增加，业务的不断扩展，在数据安全、访问效率、数据共享、数据挖掘、数据服务等方面暴露出一系列问题，现有数据管理及服务模式已无法满足水文现代化发展的迫切需求，改变现有数据及业务的服务模式是非常必要和有意义的。因此对现有数据库系统中存在的主要问题进行深入分析，并提出基于集群的解决方案，在对比各种集群技术后，最终选择 SQL Server Always On无域集群，将单实例数据库升级到数据库集群[1]，以提升水文数据安全性能。

1 主要问题

1.1 数据安全方面

雨水情数据库中有少量敏感数据，数据库在水利政务外网上运行，存在数据泄露风险；水文局对外提供数据的方式为业务系统直接访问水情数据库的形式，缺乏安全监管监控数据、跟踪数据流向的能力；现有数据库为单实例 SQL Server，存在不可用风险[2]。

1.2 访问效率方面

单实例 SQL Server 数据库存在访问效率不高的问题，一旦某应用系统访问量过大，将造成访问缓慢，甚至将数据库系统拖垮，那么基于此数据库系统的其他业务系统都将无法访问到数据库。

1.3 访问方式方面

业务系统直接访问雨水情数据库的形式有以下几个弊端：

1）安全性不高。数据库的地址、用户名和密码会储存在业务系统的缓存中，并且要求客户端具有能够直接访问数据库网络的链路，这种方式存在很大的安全隐患。

2）上层业务应用与数据库层耦合紧密。当数据库系统升级或迁移时，必然导致上层应用无法访问。

3）数据库层缺乏熔断机制。当数据库服务因为某种原因突然变得不可用或响应过慢时，没有一种有效机制中断调用数据库服务。

4）上层应用重复开发。基于雨水情数据库的多个业务应用系统，通常都会访问同一种类的常用数据，那么每个业务系统在开发时都会将访问这类数据的功能重新开发一遍，而且每个业务系统的开发模式不一，这对数据库性能优化极为不利。

2 解决方案

针对数据库存在的问题，基于国家及水文相关技术标准，以信息技术手段重点解决雨水情数据库数据同步、安全、访问等方面存在的问题，如：隔离敏感数据与非敏感数据，提高敏感数据的安全性；转变数据服务模式，从直接访问数据库方式向访问数据接口方式转变；加强对数据访问的监管；提高数据访问效率[3]。

2.1 隔离敏感数据与非敏感数据

因部分水文数据比较敏感，为保证数据的安全性，建立与水利政务外网物理隔离的局域网，实时数据通过单向网闸设备由水利政务外网向局域网中的数据库服务器推送，其中推送服务器可直连网闸，也可通过交换机连接，敏感数据只供内部人员使用，以保障数据安全。

2.2 建设数据审计监管系统

针对水文数据库 API 接口（应用程序接口）提供多种审计规则，监管水文数据安全，监控、跟踪水文数据流向。建设水文数据审计系统，在所有请求的策略底层处理上设置以下 2 种基础行为：

1）允许、拒绝行为。当发生请求时，任何审计行为都会触发该过程，依照策略判定后允许或者拒绝请求发生。

2）记录访问行为。当发生请求时，记录访问信息，请求人、应用 IP，发生时间，检索的数据量、组织范围、条件，系统的处理情况、状态，系统的访问源，接口处理时间，以及规则返回记录。

建设审计策略规则防火墙，包含的规则如下：1）访问通过规则。可以设定特定用户是否可以访问某个 Web API 请求。

2）访问时间规则。可以通过时间限定某个用户，在某个时间段是否可以访问。

3）访问请求单次数据量规则。在某个用户对特定 API 进行访问时，可以将一次请求中获取的数据量限定在允许值以内，规则处理方式可以设置为记录/拒绝/截断。

4）访问请求累计数据量规则。某个用户在一定时间周期内对特定 API 进行访问时，可以将累计请求数据量限定在允许值以内，规则处理方式可以设置为记录/拒绝/截断。

5）访问数据范围规则。可以设定以行政区域为单位的数据访问范围，从而限定用户只可以访问特定区域的数据。

6）访问数据类型规则。可以设定以测站类型为单位的数据访问范围，从而限定用户只可以访问特定测站类型的数据。

通过规则防火墙记录和限定用户请求行为实现水文数据审计业务，通过图表进行审计结果的图形化展示，可以便于管理者掌握了解水文数据使用的实际情况。

2.3 搭建水文数据库集群

随着水文数据量的不断增大，数据类型的不断扩展，用户需求不断增多，现有的单实例 SQL Server 数据库的承载能力已趋于饱和，为满足将来上层业务系统的需要，计划将现有数据库系统升级到 Oracle RAC 集群。但是现有的所有业务应用都是建立在 SQL Server 数据库服务之上的，所以短期内不可能完成 SQL Server 向 Oracle 的迁移。综合以上考虑：水文数据库先由单实例 SQL Server 数据库升级到 SQL Server Always On 无域集群[4]，使数据库服务具备高可用和负载均衡能力，以缓解当前数据库系统的压力；同时搭建 Oracle RAC 集群，对数据库进行集群管理及访问效率上的负载均衡，提高数据安全及访问效率，并逐步将已有的基于 SQL Server 的数据库服务迁移到基于 Oracle 的数据库集群上。

待搭建好数据库集群后，将数据写入地址变更为数据库集群地址，因为集群 IP 会自动绑定到主副本上，所以实际上数据是写入到集群的主副本中的。与数据库镜像技术相同，Always On 集群会在各个结点上维护 1 套数据副本，主副本上发生的数据变化，会同步到辅助副本上。所以 Always On 要完成 3 件事：首先把主副本上发生的数据变化记录下来，其次把这些记录传输到各个辅助副本上，最后把数据变化在辅助副本上同样完成 1 遍。Oracle RAC 集群也能提供类似的功能。

Always On 支持主副本和多个辅助副本。主副本上的数据库是可读写状态，可称为主数据库；辅助副本上的数据库是只读状态，可称为辅助数据库。如果发生故障转移，任意辅助副本都可转变为新的主副本。

客户端与主数据库的读写连接由主副本保障。数据同步是在数据库级别进行的，把主数据库的事务日志记录发送到辅助数据库，每个次要副本缓存事务日志记录，然后将它们应用到相应的辅助数据库，主数据库与辅助数据库进行独立的数据同步，因此，1 个辅助数据库可以挂起或失败而不会影响其他辅助数据库，1 个主数据库可以挂起或失败而不会影响其他主数据库。

部署 Always On 之前，需要先创建部署环境，即 Windows Server 故障转移群集（WSFC）。给定可用组的每个可用性副本必须位于相同 WSFC 的不同节点上。WSFC 将监视集群中的节点，以便评估主副本的运行状况。Always On 可用性组的仲裁针对WSFC 中的所有节点，而与某一给定群集节点是否承载任何可用性副本无关。从 Windows Server 2016开始，WSFC 可在无域服务器的条件下实现，大大简化了部署，并且避免了由域服务器产生的单点故障。所以本次 SQL Server Always On 集群的搭建全部基于 Windows Server 2016 的无域 WSFC。