論數(shù)據(jù)庫防火墻的自我修養(yǎng)之一丨高可用性

DT時代的到來，正在逐漸改變人類的行為模式。數(shù)據(jù)，這個時代最巨量的產物，從未如今天這般珍貴而無價。也因此我們看到，越來越多的企業(yè)和政府部門開始將安全的關注重點從傳統(tǒng)的邊界安全轉移到數(shù)據(jù)安全，保存核心數(shù)據(jù)資產的數(shù)據(jù)庫系統(tǒng)，毫無疑問的成為防護的關鍵。

數(shù)據(jù)庫防火墻，作為數(shù)據(jù)庫的最后一道防御工事，自然獲得了更多的關注，近年已越來越多的應用在關鍵系統(tǒng)的數(shù)據(jù)庫安全防護中。所謂能力越大、責任越大，這句話用來形容數(shù)據(jù)庫防火墻也許應該反過來理解，因其肩負數(shù)據(jù)庫防護重任，人們對于他的要求也更加嚴苛。

我們在說數(shù)據(jù)庫防火墻之前，需要先說明一個概念，了解了這一點，我們就更容易理解為什么用戶對數(shù)據(jù)庫防火墻的要求如此嚴苛。數(shù)據(jù)庫防火墻部署方式通常分為兩種：串聯(lián)或旁路，兩者差異很大。串聯(lián)模式部署在應用系統(tǒng)與數(shù)據(jù)庫之間，所有SQL語句必須經過數(shù)據(jù)庫防火墻的審核后才能到達數(shù)據(jù)庫，發(fā)起訪問、操作；而旁路部署呢，雖然有些廠商宣稱，可以通過發(fā)送reset（重置）命令進行重置會話，但內行人一想便知，在實際應用中，面對高壓力場景， 旁路分析勢必出現(xiàn)延遲，當數(shù)據(jù)庫防火墻發(fā)現(xiàn)風險操作時，數(shù)據(jù)庫早已執(zhí)行完成，而此時阻斷的基本上是其他不該被阻斷的正常操作了。因此，要想真正發(fā)揮防護效果，數(shù)據(jù)庫防火墻必須串聯(lián)在數(shù)據(jù)庫的前端，可以是物理的（透明串接）或邏輯的（代理）串聯(lián)。

串聯(lián)部署是發(fā)揮防護作用的必要前提，但這樣就在應用與數(shù)據(jù)庫之間增加了一個結點，如果把數(shù)據(jù)庫系統(tǒng)比作整個IT架構中的“心臟”，用戶更擔心這個結點會不會出現(xiàn)故障，一旦血流不暢通，突發(fā)心梗可是得不償失。

筆者多年來從事數(shù)據(jù)庫防火墻產品的開發(fā)、實施和維護，不能說閱盡天下防火墻，九成也是有的，在筆者心中，一個真正成熟有價值，更重要的是能夠勝任串聯(lián)部署重任的數(shù)據(jù)庫防火墻產品，應當具備以下7個特性：

1、高可用性—保障業(yè)務的安全性、可用性和連續(xù)性

2、高性能和可擴縮性—保障業(yè)務性能、吞吐量

3、詞法和語法分析—提供防護能力的基礎

4、防SQL注入和漏洞攻擊—防護來自應用側的攻擊

5、運維管控—內部運維控制

6、動態(tài)掩碼—防止敏感信息外泄

7、規(guī)則和腳本語言—高大上的數(shù)據(jù)庫防護能力

以上7點，排名確實分先后，先說高可用性，因為它在筆者心目中是凌駕于其他之上，最最重要的一點，甚至可以說是數(shù)據(jù)庫防火墻產品是否可以存在的先決條件。

串聯(lián)部署下的高可用，發(fā)揮最大價值還是給自己挖坑？

解釋了串聯(lián)部署的必要性，現(xiàn)在我們說回高可用性，由于數(shù)據(jù)庫在企業(yè)中往往承載著關鍵核心業(yè)務，其重要性不言而喻，企業(yè)會采用大量的技術來保證數(shù)據(jù)庫的高可用性，典型的有RAC、F5負載均衡、高可用網絡等；當在這樣的一個環(huán)境中串接一個新的節(jié)點時，對該節(jié)點的可用性要求甚至比數(shù)據(jù)庫本身的要求還要高。讓用戶放心實施防火墻串聯(lián)部署，高可用性的口號喊出去，會不會變成給自己挖坑？挑戰(zhàn)不小。

是軟件都會有bug，但別給業(yè)務系統(tǒng)惹麻煩！

是軟件，都會有缺陷、有bug，更別說一個具有深度的完整數(shù)據(jù)庫協(xié)議分析、SQL語法分析再加上策略控制等復雜邏輯的數(shù)據(jù)庫防火墻產品。怎么解決？答案很簡單：數(shù)據(jù)庫防火墻自身的缺陷，不應對操作數(shù)據(jù)庫的業(yè)務行為產生任何影響；缺陷引起的故障對業(yè)務系統(tǒng)應當無感。

這一目標，對于數(shù)據(jù)庫防火墻這樣的串聯(lián)產品，比任何特性都重要，是用戶能否接受“串聯(lián)部署”的關鍵指標。只為這一目標，著實需要從產品的架構設計、容錯能力和異常管理能力上費一番腦筋。

高可用性的關鍵技術路線：

1：采用類似Oracle數(shù)據(jù)庫的多進程和共享內存架構

對于每條數(shù)據(jù)庫訪問行為，相應的數(shù)據(jù)庫防火墻對應一個完整的處理過程，包括完成全部計算和功能邏輯。處理完成后，整個進程關閉。

優(yōu)點：進程間完全獨立，即使一個進程觸發(fā)了軟件缺陷，也不會影響其他訪問行為的處理，將影響降到最小。

缺點：需要對進程的資源占用進行精細的管理和分配，避免消耗太多資源。

2：對于進程的故障，實現(xiàn)軟件旁路的容錯機制

當進程發(fā)生故障時，啟動對進程的守護能力，接管通訊包，實現(xiàn)故障情況下的bypass旁路能力，從而“續(xù)上”應用與數(shù)據(jù)庫的連接，讓應用系統(tǒng)完全感受不到會話出現(xiàn)了異常。我們用安華金和數(shù)據(jù)庫防火墻進行實際測試時模擬了此場景：在會話建立后，高壓力運行SQL操作期間，“殺死”相應數(shù)據(jù)庫防火墻進程，會話沒有受到任何影響，持續(xù)穩(wěn)定運行。

在實際應用中， 安華金和數(shù)據(jù)庫防火墻被串聯(lián)部署在了承載核心業(yè)務的Oracle RAC和核心交換機（萬兆）之間，每天的吞吐量達到上億SQL操作；上線運行18個月，沒有發(fā)生業(yè)務系統(tǒng)的異常投訴，未出現(xiàn)主備切換，真正做到了讓用戶無感。

設備、系統(tǒng)故障了？業(yè)務不能斷！

是設備，都有可能出故障，硬件故障、電源故障、系統(tǒng)故障、軟件死鎖……總之有任何可能性，讓數(shù)據(jù)庫防火墻的網絡斷開或僵死。，那用戶可不干了，我的業(yè)務不能斷！

解決方案

1：采用硬件網卡ByPass，保障業(yè)務快速恢復

通過網卡的ByPass能力，并結合“看門狗”機制，當發(fā)生設備斷電、操作系統(tǒng)故障、數(shù)據(jù)庫防火墻核心組件僵死等異常情況時，能夠快速的自動開啟硬件ByPass，重新打通網絡連接，保證業(yè)務系統(tǒng)在數(shù)據(jù)庫防火墻發(fā)生異常后，在幾秒內恢復正常。

2：采用雙機HA網絡，保障業(yè)務連續(xù)性

在很多關鍵核心業(yè)務系統(tǒng)中，往往會采用高可用網絡和負載均衡設備來保證極端情況下的業(yè)務連續(xù)性。作為串聯(lián)接入的數(shù)據(jù)庫防火墻設備，需要能夠無縫的適應這樣的高可用環(huán)境，能夠提供全透明（無IP）的串接方式，就好比一根網線，當這根“網線”出現(xiàn)故障，無法連通時，通訊包會被自動串接到另外一條鏈路上的數(shù)據(jù)庫防火墻設備，從而無縫的繼續(xù)業(yè)務操作。

忽然聯(lián)想到，用戶對數(shù)據(jù)庫防火墻產品的高可用要求，就好比我們要求八達嶺野生動物園的老虎兄弟，既希望它們不喪失原始的野性本能，同時又要保證它的安全性，不會傷害游客，要求這么高，稍有差池這不就出事兒了嗎？活生生的老虎我們控制不了，可自己的產品還是能自己說了算的。

于是，在數(shù)據(jù)庫防火墻產品的開發(fā)之初，我們先給自己制定了一個能達到的小目標~ 就是實現(xiàn)串聯(lián)部署下的高可用性。今天，作為國內最為成熟的數(shù)據(jù)庫防火墻產品——安華金和數(shù)據(jù)庫防火墻，已成功應用于多個大型項目中，以串聯(lián)部署的方式，保證業(yè)務系統(tǒng)在安全狀態(tài)下正常、高效的運行，為用戶提供了安全、無感的體驗效果。

生成海報

免責聲明：本網站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網站出現(xiàn)的信息，均僅供參考。本網站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網站中的網頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。