综论数据库防火墙的自我修养系列之一:高可用性

安全 数据安全
用户对数据库防火墙产品的高可用要求,就好比我们要求八达岭野生动物园的老虎兄弟,既希望它们不丧失原始的野性本能,同时又要保证它的安全性,不会伤害游客,要求这么高,稍有差池这不就出事儿了吗?活生生的老虎控制不了,可自己的产品还是能自己说了算的。

   DT时代的到来,正在逐渐改变人类的行为模式。数据,这个时代最巨量的产物,从未如今天这般珍贵而无价。也因此我们看到,越来越多的企业和政府部门开始将安全的关注重点从传统的边界安全转移到数据安全,保存核心数据资产的数据库系统,毫无疑问的成为防护的关键。

[[171215]]

  数据库防火墙,作为数据库的最后一道防御工事,自然获得了更多的关注,近年已越来越多的应用在关键系统的数据库安全防护中。所谓能力越大、责任越大,这句话用来形容数据库防火墙也许应该反过来理解,因其肩负数据库防护重任,人们对于他的要求也更加严苛。

  我们在说数据库防火墙之前,需要先说明一个概念,了解了这一点,我们就更容易理解为什么用户对数据库防火墙的要求如此严苛。数据库防火墙部署方式通常分为两种:串联或旁路,两者差异很大。串联模式部署在应用系统与数据库之间,所有SQL语句必须经过数据库防火墙的审核后才能到达数据库,发起访问、操作;而旁路部署呢,虽然有些厂商宣称,可以通过发送reset(重置)命令进行重置会话,但内行人一想便知,在实际应用中,面对高压力场景, 旁路分析势必出现延迟,当数据库防火墙发现风险操作时,数据库早已执行完成,而此时阻断的基本上是其他不该被阻断的正常操作了。因此,要想真正发挥防护效果,数据库防火墙必须串联在数据库的前端,可以是物理的(透明串接)或逻辑的(代理)串联。

  串联部署是发挥防护作用的必要前提,但这样就在应用与数据库之间增加了一个结点,如果把数据库系统比作整个IT架构中的“心脏”,用户更担心这个结点会不会出现故障,一旦血流不畅通,突发心梗可是得不偿失。

  笔者多年来从事数据库防火墙产品的开发、实施和维护,不能说阅尽天下防火墙,九成也是有的,在笔者心中,一个真正成熟有价值的数据库防火墙产品,必须能够胜任串联部署重任,同时具备良好的自我修养,如何体现?下面7项指标量化考评:

  1. 高可用性—保障业务的安全性、可用性和连续性

  2. 高性能和可扩缩性—保障业务性能、吞吐量

  3. 词法和语法分析—提供防护能力的基础

  4. 防SQL注入和漏洞攻击—防护来自应用侧的攻击

  5. 运维管控—内部运维控制

  6. 动态掩码—防止敏感信息外泄

  7. 规则和脚本语言—高大上的数据库防护能力

  以上7点,排名确实分先后,先说高可用性,因为它在笔者心目中是凌驾于其他之上,最最重要的一点,甚至可以说是数据库防火墙产品是否可以存在的先决条件。

  串联部署下的高可用,发挥最大价值还是给自己挖坑?

  解释了串联部署的必要性,现在我们说回高可用性,由于数据库在企业中往往承载着关键核心业务,其重要性不言而喻,企业会采用大量的技术来保证数据库的高可用性,典型的有RAC、F5负载均衡、高可用网络等;当在这样的一个环境中串接一个新的节点时,对该节点的可用性要求甚至比数据库本身的要求还要高。让用户放心实施防火墙串联部署,高可用性的口号喊出去,会不会变成给自己挖坑?挑战不小。

  是软件都会有bug,但别给业务系统惹麻烦!

  是软件,都会有缺陷、有bug,更别说一个具有深度的完整数据库协议分析、SQL语法分析再加上策略控制等复杂逻辑的数据库防火墙产品。怎么解决?答案很简单:

  数据库防火墙自身的缺陷,不应对操作数据库的业务行为产生任何影响;缺陷引起的故障对业务系统应当无感。

  这一目标,对于数据库防火墙这样的串联产品,比任何特性都重要,是用户能否接受“串联部署”的关键指标。只为这一目标,着实需要从产品的架构设计、容错能力和异常管理能力上费一番脑筋。

  高可用性的关键技术路线:

  1:采用类似Oracle数据库的多进程和共享内存架构

  对于每条数据库访问行为,相应的数据库防火墙对应一个完整的处理过程,包括完成全部计算和功能逻辑。处理完成后,整个进程关闭。

  优点:进程间完全独立,即使一个进程触发了软件缺陷,也不会影响其他访问行为处理,将影响降到最小。

  缺点:需要对进程的资源占用进行精细的管理和分配,避免消耗太多资源。

  2:对于进程的故障,实现软件旁路的容错机制

  当进程发生故障时,启动对进程的守护能力,接管通讯包,实现故障情况下的bypass旁路能力,从而“续上”应用与数据库的连接,让应用系统完全感受不到会话出现了异常。我们用安华金和数据库防火墙进行实际测试时模拟了此场景:在会话建立后,高压力运行SQL操作期间,“杀死”相应数据库防火墙进程,会话没有受到任何影响,持续稳定运行。

  设备、系统故障了?业务不能断!

  是设备,都有可能出故障,硬件故障、电源故障、系统故障、软件死锁……总之有任何可能性,让数据库防火墙的网络断开或僵死。,那用户可不干了,我的业务不能断!

  高可用性的关键技术路线:

  1: 采用硬件网卡ByPass,保障业务快速恢复

  通过网卡的ByPass能力,并结合“看门狗”机制,当发生设备断电、操作系统故障、数据库防火墙核心组件僵死等异常情况时,能够快速的自动开启硬件ByPass,重新打通网络连接,保证业务系统在数据库防火墙发生异常后,在几秒内恢复正常。

  2:采用双机HA网络,保障业务连续性

  在很多关键核心业务系统中,往往会采用高可用网络和负载均衡设备来保证极端情况下的业务连续性。作为串联接入的数据库防火墙设备,需要能够无缝的适应这样的高可用环境,能够提供全透明(无IP)的串接方式,就好比一根网线,当这根“网线”出现故障,无法连通时,通讯包会被自动串接到另外一条链路上的数据库防火墙设备,从而无缝的继续业务操作。

  忽然联想到,用户对数据库防火墙产品的高可用要求,就好比我们要求八达岭野生动物园的老虎兄弟,既希望它们不丧失原始的野性本能,同时又要保证它的安全性,不会伤害游客,要求这么高,稍有差池这不就出事儿了吗?活生生的老虎控制不了,可自己的产品还是能自己说了算的。

  于是,在数据库防火墙产品开发之初,我们先给自己制定了一个能达到的小目标:实现串联部署下的高可用性。今天,作为国内最为成熟的数据库防火墙产品——安华金和数据库防火墙,已成功应用于多个大型项目中,以串联部署的方式,保证业务系统在安全状态下正常、高效的运行,为用户提供了安全、无感的体验效果。

责任编辑:周雪 来源: 安华金和
相关推荐

2010-09-13 14:45:56

SQL Server

2017-03-15 15:14:03

MySQL数据库高可用性

2010-12-08 09:29:27

下一代防火墙

2022-05-09 09:42:24

高可用分布式数据库

2011-08-02 13:37:17

2022-12-19 13:03:32

2016-06-21 10:25:44

防火墙迁移企业安全风险管理

2011-02-28 09:14:36

2023-12-05 09:31:46

数据库架构

2020-11-18 13:03:10

云防火墙安全运营云安全

2021-07-29 10:37:13

漏洞管理自我修养漏洞

2015-10-28 13:39:25

2021-02-19 11:10:10

数据库

2018-05-17 23:07:12

2024-02-27 09:48:25

Redis集群数据库

2010-09-14 08:55:55

SQL Server

2016-09-28 15:02:39

数据库防火墙高性能

2011-07-13 08:52:25

2011-04-08 17:13:39

2020-11-02 17:59:19

防火墙数据库美创科技
点赞
收藏

51CTO技术栈公众号