https://www.informationsecurity.com.tw/seminar/2021twcert/
https://www.informationsecurity.com.tw/seminar/2021twcert/

觀點

十個評估方向 找出你的資料庫安全需求

2010 / 08 / 23
田振宇
十個評估方向 找出你的資料庫安全需求

去年在國內外,發生了不少知名的資料外洩案件,從TJ Max資料外洩案件,成為美國個人資料保護法立案來最高的開罰金額,到國內知名購物台和多家電信業者的資料外洩案中可以看得出,目前國內外對資訊保護的欠缺。

 

Web 2.0興起也改變資料庫應用
與企業息息相關的智慧財產、客戶個人資料與財務記錄等,都儲存在資料庫中,都是企業的重要資產。各種資安設備的資訊防護,從防火牆到IDS/IPS到網頁應用程式防火牆,都在企業對外的管道上佈下層層關卡。但是面臨駭客在Web上的攻擊,加上各種瀏覽器的弱點與不安全的程式碼時,都無法確保資料的安全性。

從安全的角度來看待,這些設備目前所做的都是以一個已知的攻擊型態進行保護,並從這些攻擊型態中找出目前網路、應用程式及系統有什麼潛在性的危機並進行修正。很多相對的認證機制中,也對於一個應用程式從開發(Birth)到替換(Abortion)會進行詳細的版本更新以及替代的記錄。在CMMI等認證架構內,也可以很完整的輔助開發過程,但開發出來的程式是否可以抵抗外來的攻擊,則不是這麼絕對。主要原因在於程式語言的關係,由於系統漏洞會不斷的被發現。但在被發現後跟修補漏洞之間的空窗期,就產生了可能發生零時差攻擊(Zero-Day Attack)的機會。因此,對於被動性的依賴某系統去進行偵測和發現弱點,往往是一種消極的方式,而不是積極的處理。

 

但企業面臨的,不只是來自外部的問題。對於資料庫的資訊安全保護,目前僅能以Account Base來控管,但這些通過認證的合法使用者進到重要的資料庫後,到底做了什麼事,目前是很難得知的,尤其特殊權限使用者,具有對資料的修改及刪除的權限。雖然資料庫本身有權限控管的功能,但同時要如何去防範有特殊權限的人士或委外承包商等,變成不光是資料庫安全控管,也必須包含了帳號管理機制才能有效的管理資料庫的安全。而如何落實帳號管理,相信也是一個企業內所面臨的困擾。

 

不只是資料庫本身的權限控管,在Web2.0的環境中,我們對於最高權限使用者的認知是逐漸有所轉變的。在舊有的理念中,應用程式使用者並不會被納入管理的範圍,而在新的轉變中,只要有權力修改資料庫內的資料,就等同於最高權限使用者,現在的應用程式使用者(AP User)可以透過AP Sever連接到資料庫做一些內容上的修改,例如SQL Injection的攻擊就是這樣。因此,對於AP User,我們也需要知道怎麼去進行稽核和管理。

 

進行DBAP User的稽核、管理

而對於早期的資料庫安全,防禦重點不外乎是弱點偵測(Vulnerability Scanning)、入侵偵測(Intrusion Detection)這類防範侵入性行為的產品。這些傳統的評估方式往往會造成資料庫效能的影響,甚至如果操作不當,有可能造成資料庫全面斷線。除此之外,資料庫本身並沒有非常落實的機制,來做不正常活動的訊息回報。舉例來說,當資料庫發生使用者登入錯誤時,並不會主動記錄,當有存取錯誤發生時,同樣也沒有可靠的方法顯示錯誤的原因。所以,如果要落實資料庫的安全保護,最基本也最紮實的方式,就是由資料庫的活動稽核開始做起。

 

在每一個稽核過程當中,必須要能夠完整的達成5W的原則,才能夠瞭解資料庫整體的安全狀況。而所謂的5W原則,就是誰(Who)、用什麼方法(What)在什麼地方(Where)、什麼時間(When)、對你的資料庫做什麼事情(How)。在這個必要條件下,所呈現的稽核資料,才能夠完整的還原資料庫的活動行為,進一步的去做判斷。

 

可是面對資料庫的稽核工作時,IT人員往往會面臨到一個兩難。一方面希望能針對資料庫的活動做稽核,但另一方面當需要稽核時又必須將資料庫的稽核日誌功能開啟,造成資料庫的效能大減。即使開啟了資料庫的稽核日誌功能後,收集到的資料也需要大量的人力去進行分析。而這兩個動作,在所謂的稽核循環當中,是最初,也是最必須要落實的一環。但往往在追求效能不被影響的情況之下,絕大部分的企業都未將稽核日誌功能開啟,卻進一步的嚴重影響到資料庫本身的安全。

因此,從資料庫稽核循環中的前兩項目,對絕大部分的企業來說,已經是一個不可否認的痛處。可是即便今天忍痛的完成前兩項的需求,後續的缺失監控,以及監控後的稽核資料,和最終新的資安政策的執行,都難以達成。既使完成了上述的循環,也有可能因為「球員兼裁判」的關係,而造成稽核成果在不可否認性上的一個質疑。

 

在這層層關卡中,如何有效率,並在可信任的情況下完成稽核動作,排除「不可否認性」的一個質疑,是每個企業所必須面對的一個課題。反觀目前市場上所提供的產品,鮮少有人能提供上述的機制。所以找出一個能符合上列要求,並同時能做到安全控管的輔助工具,已經慢慢的開始變成每個需要達成稽核目標的企業當中一個”Must Have”。

 

從上述的幾個要求中,我們可以做幾個結論:

1)      該工具必須在不影響資料庫的前提下運作

2)      該工具必須要能夠達成資料的「不可否認性」

3)      該工具能有效的節省稽核所需的人力(稽核資料可被預先整理

該工具必須能夠做到稽核循環的要求

 

如何評選DAM(Database activity monitoring)解決方案?

在各種法規、法令的政策要求下,資料庫稽核與安全控管在近年來逐漸成為政府及企業在資訊安全上所關注的重點與熱門討論的話題。稽核人員尤其關心資料庫中與企業應用程式的管制資料,而個資法、SOXHIPAAPCI-DSS和其他法規條例更要求實施最佳控制措施來保護敏感資料。然而目前市面上,有關於資料庫稽核與安全控管的相關產品與解決方案不少,企業該如何評選適宜的產品與解決方案,以保護重要的機密敏感性資料庫。的確是一件需要謹慎思考的課題。以下有幾點評估方向可在評選產品與解決方案時列為重要參考與依據:

 

評估方向1:是否具備100%完整監控與分析所有資料庫活動的能力?

這是一個最根本的評估要項,若不能100%完整地監控與分析所有資料庫活動而有所遺漏,就無法清楚地瞭解不法存取行為活動、入侵與洩密等資安事件是如何地發生,更無法針對問題的癥結點,實施正確的規則與政策進行控管與稽核,在不法的存取活動發生時能即時、完整地記錄、發出警示或甚至進行阻斷。


是否完整監控與分析所有資料庫活動的能力?攸關企業組織在進行資料庫監控與稽核工作上,是否能符合資訊安全標準與法規要求。有些產品採用與傳統網路防火牆產品相同的規則式(Rule Based)設計方式,事先必須手動方式設定好一條一條的規則與政策,唯有符合預先所定義好的規則與政策的資料庫操作才會進行記錄,沒有符合規則的則不予記錄。此種設計根本無法完整地監控與記錄所有的資料庫活動與異動,這樣的設計方式在操作與設定上也許很容易讓人理解與熟悉(如同大家所熟知的防火牆),但在安全上卻有很大的疑慮。

 

首先,要思考的是「未符合規則而沒被記錄下來的資料庫操作(活動)是否是安全無風險的存取活動?」

第二,若要完整監控與分析所有資料庫活動,那得事先定義好多少條規則?

 

評估方向2:本機端的監控代理程式,是否有可能因為本身的故障造成資料庫無法運作?

對於發生於資料庫本機端的活動存取監控,大多會以安裝監控代理程式進行。值得注意的是,目前代理程式監控與取得資料庫活動資訊的技術,有幾種方式,如:TCP/IP RedirectShared MemoryNamed pipeIPC等,其中TCP/IP RedirectShared Memory的方式有可能因為監控代理程式的失效,造成資料庫無法正常運作。

 

評估方向3是否具備阻斷特權使用者在資料庫本機端(local access)的存取行為?

對於特權使用者在資料庫本機端(local access)的存取行為,多數產品無法加以約束控制,這是一個十分可怕的資安漏洞。特權使用者可以恣意地存取資料庫,並將資料予以外洩。

 

評估方向4是否具備高度的安全防護機制,以避免本身成為另一個資訊安全弱點、風險與漏洞?

資料庫安全控管與稽核的過程中,必須把所收集的稽核資料存放於設備當中做記錄與分析,而這些稽核資料可能包含著機密敏感性資料,如身份證字號、信用卡卡號、管理者帳號與密碼等等。倘若系統本身無高度的安全防護機制,則可能成為另一個資訊安全弱點、風險與漏洞。幾個重點需思考:所收集的稽核資料是否經過加密?還是以明碼(Plain-Text)的方式存放?機密敏感性的欄位資訊是否有遮罩處理(Mask)?還是毫無隱藏地呈現,可讓人一覽無遺?系統本身是否存在最高權限者,可將系統內的稽核資料或記錄進行竄改或甚至完全刪除?系統本身是否具備自我監控機制,稽核與記錄本身的所有的操作與活動?

 

評估方向5:是否具備妥善的資料儲存管理機制?

資料庫安全監控與稽核通常會收集並產生大量的稽核資料,且為了能重建過去所發生資料庫活動與事件,通常也需要將稽核資料做歷史性的長期歸檔存放(Archiving)。有些系統並無自動歸檔設計,一旦系統內部的儲存空間(如磁碟機)用盡,為了能持續收集的稽核資料,則勢必將較舊的資料刪除捨棄,別無他法。如此一來很可能會發生在資料庫流量極為忙碌的狀況下,系統內僅能儲存1天的稽核資料或甚至只有數小時的資料的窘境(視資料庫的負載而定)。另外,儲存稽核資料的方式或資料結構,也會大幅地影響系統的效能與耗用大量的儲存空間,使儲存空間的成本大幅攀升。舉例來說,有些Rule-Based設計的產品會針對每一條規則,產生一個相對應的檔案(如:csv格式的檔案)存放符合該條規則的稽核資料,在無壓縮、過濾與資料正規化(normalization)處理的狀況下,系統會將整個稽核資料收集下來,如此檔案很快就會爆滿,造成問題。較先進完善的系統在稽核資料儲存結構上,在系統內部則採用關聯式資料庫存放,並經過壓縮、過濾與資料正規化(normalization)處理。差異為何?採關聯式資料庫設計的系統在儲存空間效率、報表的產生速度、多樣化報表的種類、客製化報表的彈性、稽核記錄的細節程度與精確度等方面,是Flat-file檔案設計方式所無法媲美的。

 

評估方向6:是否具備與其他資安管理系統整合,達成資安通報的能力?

在法規與資訊安全政策的強烈驅使下,許多企業會建置安全資訊與事件管理系統(SIEM, Security Information and Event Management)如:ArcSightRSA enVision等,以統籌管理各項資安應用與設備、資訊安全通報,並自動地回應與解決資安事件。具備此項能力的系統,能將資料庫的稽核記錄以欄位對應的方式,將資料庫活動所發生的資安事件,自動送發警示至SIEM系統中,讓企業也能將資料庫安全納入整個企業資安通報系統當中,使資安管理更加完整。

 

評估方向7:是否符合稽核「不可否認性」的基本精神與原則?

超級使用者權限(rootadministrator)有機會可以新增、刪除或修改收集到的稽核資料,所以必須確認收集的稽核資料是最原始未被竄改過的。

 

評估方向8是否能支援所有的資料庫通訊協定與資料庫的傳輸加密?

資料庫系統所採用的通訊協定種類繁雜,如:TCPShared MemoryBequeathNamed PipesNetBIOS等。若無法完整支援所有資料庫系統所可能使用的通訊協定,則無法針對該通訊協定進行監控與分析,當然就無法進行稽核,如此便又造成一個漏網之魚。同樣,資料庫系統的傳輸過程也有可能加密的方式,如OracleASO(Advance Security Option)MS SQL server SSHIPSEC/SSH等,如無法支援,當然就無法進行稽核。

 

評估方向9是否具備自我稽核機制?

當佈署安全控管與稽核方案時,所收集到的資料也會包含企業機密敏感性資料。因此,對所收集到的資料也要有妥善的自我稽核機制。如此才能確保稽核資料的正確使用,而不會成為另一個資安漏洞。

 

評估方向10是否具備報表集中彙整(Aggregation)的能力?

當企業的資料庫系統龐大、數量眾多且分佈區域廣泛的狀況下,要完整監控與稽核所有的資料庫活動,可能就需要多台的設備進行分散式監控才能應付。分散式監控架構下,每台設備分別各自監控轄內的資料庫伺服器,並收集稽核資料。當管理者需要稽核資訊與報表時,需要到每台設備上去產生獨立稽核資料報表,但是無法從單一位置就能集中彙整所有稽核報表資訊,這在稽核工作與管理上是一大挑戰。

此外,由於每個獨立系統所產生的稽核資訊與報表彼此之間並沒有交互關連性,針對某一個資料庫活動或事件的稽核資訊,僅限於該設備所負責的範圍當中。倘 若想對某一個資料庫活動或事件的稽核資訊,自動產生一個彙整後的稽核分析報表,則必須以人工方式自行整理。

有些做法則是在架構上,在上層增加一個彙整報表的管理設備,自動地彙整每台下層設備所收集的稽核資訊與報表,並加以分析將某一個資料庫活動或事件相關聯的稽核資訊彙整成一份完整報表資訊,而無任何遺漏。因此管理者,只要在單一位置即能完整掌握所有稽核資訊,大幅地減輕稽核工作的負擔。

 

結論:

綜觀以上的重點,不難看出在於資料庫的稽核工具裡所必須具有的條件。系統所收集的資料保有的不可否認性及完整度,相對的影響在未來個資法中若需舉證的可信度。而對於稽核人員本身,也需要在沒有太多的技術背景中,能快速的找出資料庫中所需要稽核的重點,並能將這些問題反應給技術人員,做更細部的分析。能夠確定的是,在以往觀念中無法被稽核的資料庫系統,因為這些工具的出現,而能開始將一些過去所不知道的問題浮現在檯面上並正視。資料庫將不再是所謂的三不管地帶,而將成為每個企業裡要去保護的最後一塊淨土。

 

註:作者任職於資訊及網路產業,專長為資安稽核與規劃。