Cobrasonic 的資料庫稽查系統架構

而 Cobrasonic 所設計的系統則是比較貼近三層式伺服器的架構，而且他們是 在盡量不影響原本三層式伺服器的架構下，採取 UI 伺服器及資料庫封包拷貝後 送到第三方伺服器，以進行後續分析的方式，如圖 4 所示。

7

圖 4 Cobrasonic 資料庫稽查系統的架構

在 Cobrasonic 所設計的架構中，是在 UI 伺服器傳送 http 封包給 AP 伺服器 時順道拷貝一份然後傳送給第三方伺服器，然後在資料庫收到 AP 伺服器傳來的 SQL指令或是資料庫管理者執行資料庫操作動作時，也拷貝一份 SQL 指令給第三 方伺服器，之後在第三方伺服器上分析 SQL 指令與 http 封包的關聯性，以達到 對原系統架構影響最小卻又能達到資料庫稽查的效果。由於使用者在要求服務過 程中的 http 封包及之後資料庫上操作的 SQL 指令一開始就會送一份給第三方伺 服器，而且所有資料庫管理者在操作資料庫時也會同時把操作資訊傳送一份到第 三方伺服器，因此之後發生問題時，稽核人員便可以很迅速的找到問題的來源，

並加以解決了。

UI 伺服器伺服器伺服器伺服器

AP 伺服器伺服器伺服器 伺服器

8 1279180201 /aiad/pack01/ec/ec-login.asp pp 6 1279180201 /aiad/pack01/ec/in/pos-pass-check.asp passwd 1234567

表 3 發送帳號密碼的 http 封包

然後 AP 伺服器在收到 http 封包時，會送出 SQL 封包給資料庫，如表 4 所示。

時間郵戳 SQL Statement

1279180203 select userInfo from User where Password = “1234567”

表 4 與發送登入系統的 http 封包相對應的 SQL 封包

9

由上面的例子，我們可以看到 UI 伺服器送出的 http 封包內含有標籤名稱 為”passwd”及標籤數值為”1234567”的內容，而且後續對應的 SQL 封包內容也含 有數值為”1234567”的 Password 欄位，因此，我們很容易就可以發現它們是極有 相關性的。

這是個比較好比對的情形，然而有些 http 封包內，紀錄 passwd 的欄位可能 取名為 loginkey 或其他標籤名稱，而且同時間含有相同標籤數值的 http 封包可能 超過一筆，在這樣的情況下，簡單的標籤名稱及標籤數值比對，便無法找到相對 應的 SQL 封包與 http 封包了，而這也是 Cobrasonic 所設計的資料庫稽查系統困 難點的所在了。

另外，在一般的三層網路服務架構中，在使用者端與 UI 伺服器中間會存在 一個防火牆，過濾一些可疑來源送過來的封包，如圖 5 所示。

圖 5 在防火牆下的資料庫稽查系統

10

藉由這樣的方式，當使用者的服務要求送往 UI 伺服器時，很多沒有意義或 是來自可疑來源的封包都已經被防火牆擋掉了，也因此當 UI 伺服器後續傳送 http 封包到第三方伺服器時，才不會多了很多沒有用的紀錄檔，而導致儲存空間的大 量成長與後續 http 封包與 SQL 封包配對時造成大量的誤判情形。而由於資料庫 接收的 SQL 封包都是即將執行的命令，因此在這部分，我們是採取只要資料庫一 收到 SQL 指令，就全部送往第三方伺服器並加以記錄。藉由這樣的方式，我們在 http封包與 SQL 封包配對時，就不會因為 UI 伺服器端傳送太多沒有意義的 http 封包給第三方伺服器，而導致後續的配對錯誤了。

11 (Discretionary Access Control; DAC)、強制存取控制(Mandatory Access Control;

MAC)、角色基礎存取控制(Role Based Access Control; RBAC)等三種。

以自主存取控制來看，顧名思義就是使用者可以自行決定資料可以由哪些人 來存取，像是 BBS 或是社交網路平台(如:臉書、噗浪等)的使用者可以決定跟自 己相關的資訊(如:生日、手機號碼、相簿)可以給哪些朋友或是朋友的朋友存取。

這樣的存取控制方式是非常自由的，但如果使用者沒有完善的設定，那麼使用者 個人的隱私可能會在不自覺的情況下讓其他使用者一覽無遺。