https://www.ibm.com/events/event/pages/ibm/f7x183mb/1581037797007001PJAd.html
https://www.ibm.com/events/event/pages/ibm/f7x183mb/1581037797007001PJAd.html

觀點

【導入篇】資料庫行為監控DAM 導入成功的9大關鍵

2013 / 07 / 18
廖珮君、張維君
【導入篇】資料庫行為監控DAM 導入成功的9大關鍵

資料庫行為監控(DAM)專案與防制資料外洩(DLP)不相上下,都是導入挑戰性相當高的專案,要導入成功,不是只要選擇好產品工具就行,而是企業本身需求、內部組織面,都需有一定的溝通與準備,加上有經驗的廠商才可能順利推動。本文從早期導入DAM的企業,以及廠商輔導經驗,整理以下DAM導入成功因素,提供讀者參考。

DAM導入成功的9大關鍵

企業在進行DAM專案時,哪些是成功關鍵?以下歸納出9點,包括產品面、管理面、組織面缺一不可:(1) 資料分類;(2)Policy警示與報表能力;(3) Sizing評估;(4) AP 使用者判斷;(5)Agent與Sniffer模式的選擇;(6)符合主管機關要求:資料異動前後的值;(7)需求一開始的規劃與整合;(8)組織部門配合、人員能力;(9)廠商溝通技術能力。

麟瑞科技技術經理陳志遠分析,目前DAM專案企業需求主要分為兩大類:一、為了符合個資法,滿足稽核要求,二、想看到異常資安問題。針對前者,DAM專案的評估重點功能有二,首先是應用程式使用者判斷(AP User tracking)以及做查詢結果的full response data,這會與資料庫、儲存設備的負載效能有關,使用者要清楚自己要錄甚麼。至於後者,DAM的評估重點則是要有良好的政策設定以發出警示,並能產出所需報表。

(1) 做好資料分類,想清楚要錄甚麼
研究DAM多年的安創資訊技術總監田振宇認為,DAM專案導入失敗的原因之一是企業資料沒有分類,使用者不懂要撈甚麼,「全都撈就變成全都找不到」他說。而某政府機關導入DAM相當順利成功,主要原因是需求範圍非常明確,就是DAM只針對所有對身分證字號查詢的動作留下記錄,例如有來自不正常IP的查詢就提出警示等。他也認為,現在許多為了符合個資法而開始評估DAM的企業遇到了一個難題—-所有個資的存取要留下記錄。這樣一來,需求範圍太大,這時解決方案應該讓企業可以限縮範圍,在下where查詢條件句時可更細化,例如:select*from personal_data; where id=”?” 只要記錄所有條件句並把符合結果的returning data保留下來即可。

IBM軟體事業處資深技術顧問張寅建提出建議,第一步企業應進行資料盤點,以個資法中對個資的定義為基準,再搭配主管機關與自身內稽內控規範去調整,描繪出企業內個資的分佈地圖,才知道DAM要收哪些Log。第二步則是思考哪些資料要留?哪些不要留?這部份可借助顧問服務來找出答案。

庫柏資訊總經理林俊仁則認為,使用者也許不知道自己要錄甚麼,但是廠商則可從另一角度來建議哪些不要錄,例如與人無關、批次作業、每日固定的作業、系統自己產出的不要錄。如此可大幅減少系統負荷。

 

A企業經驗談:DAM需搭配其他工具才可完整呈現原貌,需求規劃很重要
A企業導入DAM已1年多,當初是因為被稽核到DB沒做log,才開始評估第三方產品,由於不希望影響資料庫效能所以選擇側錄的方案。
A企業專案負責人:
> 當初開始做資料庫稽核也不太確定是要看哪些東西,只好全都錄。如果可以在專案前先做個資盤點,了解哪些資料表或欄位是重要、高風險的資料,也許有助於專案推行,但前提是個資盤點要夠全面。而專案一開始全都錄的做法,雖然資料量大,至少不會有漏失,一陣子後再來檢視哪些要錄、哪些不要錄,慢慢調整。
> 要做好資料庫稽核,不會是只有一台DAM,POC時要全盤考慮需求,現在因為受限於儲存設備空間有限,每6周就需要把log檔案archive出去,備份在磁帶保留1至2年。以後規畫要用LM來幫忙蒐集log,可以留存比較完整。
> 此外,許多AP都是使用共用帳號來查詢資料庫,做AP使用者判斷很重要,必須另外搭配一台WAF,或把前端Web server的log留下來,利用時間點來做比對。總之,DAM僅是一個工具,若要發揮其效能,須搭配其他稽核工具,如LM或WAF,方可完整呈現事件原貌。

(2) Policy警示與報表能力

陳志遠表示,企業是為了稽核需求或是為了資安在進行POC時所著重的部分有很大不同,若是為了看出特權使用者的異常行為,重點在於調整security policy與報表產出設定。許多廠商會強調可以為企業客製化產出各種所需報表,而Imperva則有20~30種條件設定可以組合,廠商可協助組合利用工具本身功能拉出符合企業所需的報表,不需進行客製化。

張寅建認為企業若要即早發現不法行為必須清楚界定DB使用者的職權範圍,如DBA只能Create/管理資料表,不能Select資料,而AP開發者雖然可以Select資料,但只能Select測試資料、不能看實際線上用的資料,至於現場服務客戶的使用者,雖然可以Select實際線上用的資料,但企業必須建立黃金基準線,也就是現場作業人員平均每幾分鐘會服務/查詢1位客戶資料,如此才能即早發現異常。舉例來說,現場作業人員每5分鐘服務1位客戶(亦即每5分鐘會Query一位客戶資料),假設某甲在20分鐘查了20位,每一次都只查一筆,乍看之下似乎正常,但把時間回溯來看就逾越了黃金基準線的範圍,這就是異常行為。

稽核異常警示分為2種,一是即時異常,另一則是回溯異常,稽核人員經由時間回溯發現的異常行為,例如上述某甲雖然一次只查詢1筆但查詢頻率非常密集。對此,IBM預設所有Log都錄下來,但一定會面臨資料過大的問題,此時再用Policy來過濾不需要的資料,如批次作業。建Policy非一觸可及,一定是一直做一直修改,一般約要3~6個月左右的時間,IBM預設的Policy有PCI-DSS、沙賓法案、資料保密(即各國個資法共通點),採GUI的介面,稽核人員透過拖拉或選單方式就能制定policy。

(3) Sizing評估
精誠資訊產品經理于子欣認為,可分成硬體與儲存兩個方面來看,企業在做POC時,因為與實際導入規模不一樣,所以很難估算出自身需要多大的設備才能夠支撐流量,再就儲存空間來說,return data可依需求設定為全都錄或是只錄一部份,還有保留時間,這些設定都會影響Storage儲存量,有些企業設定線上留一週或一個月,剩下的就archive到磁帶上,比較不容易出現爆量的問題。

目前,每一家DAM廠商估算size的方式不一樣,先就硬體設備來看,因為精誠代理的DAM是軟體,硬體是開放式架構,所以會先把CPU和RAM抓一個基本值,不夠就加RAM,至於Impreva和Guardium因為是Appliance,所以只要換比較大台的設備就可以。至於Storage的部份,則是以1天或1週的資料庫流量或是由transaction log去推估出需要的容量,當然還有上述的設定也要納入參考,也就是return data保留範圍和期間,至少要做到有備份時間,而不是1天就爆掉。

玄力科技總經理顏良修認為,最好的評估基準就是DB一天有多少交易量,但這個數字企業通常都不會知道,只知道DB多幾T的交易量,因此必須由DAM廠商幫企業評估,以玄力而言本身有一台專門設備,可以去幫企業測試並據此做為Sizing規劃的基礎。此外還要考量希望保留線上查詢時間有多長,是1個月或是半年?線上查詢時間主要受到2個因素影響:BOX的硬碟空間、一天有多少資料庫的查詢量,如果每天查詢量很大、希望線上查詢時間長,相對硬碟空間也要夠大才可以,如果硬碟空間不足,自然線上查詢時間也不可能太長。

顏良修指出DAM若要將Log全部留存,必須克服兩個挑戰:儲存成本、從封存資料取出的時間,玄力的資料儲存為雙重架構,可支援即時查詢與離線儲存,而在離線儲存的時候是以檔案方式匯入,因此相同容量的儲存空間,所能儲存的Log記錄會比競爭對手多出20倍。

田振宇則有一套簡單的估算方式,若企業無法正確評估可能需要的log儲存空間,建議可在評估階段先估瞬間流量(指全都錄的情況下)再乘上1.5倍。

張寅建認為評估Sizing時,必須以Policy為基準,若企業不知如何制訂policy顧問會建議從系統分析、作業流程改善再到政策制定,第二則是逐步過濾。也就是初期先把Log全部留下來,觀察1~2個禮拜後開始設Policy,把過去多餘資料清除掉,依此類推,繼續增加Policy與過濾資料,可避免儲存容量不夠的問題,也不必一開始就買到最大Sizing的產品。

倘若使用者有擴充儲存空間的需求,IBM的Appliance可以外接儲存設備,但通常不建議使用者這麼做,主要還是在於效率考量,外接儲存設備通常容量都很大(如:一個SAN就有5TB的容量),要從裡面抓資料速度當然會比較慢,與其如此,不如另外建一個Reporting System,而原本Appliance裡面留存的資料則專供即時/線上查詢之用。


B企業經驗談:return data無法留,Sizing評估很重要
B企業導入Agent mode解決方案已三年,大致上使用經驗還不錯,但由於維護合約價格昂貴,正考慮以後某些資料庫改用別的DAM,某些專屬的DB則繼續用。
B企業專案負責人:
該產品的多階層式架構,很符合需求,可確保大量記錄完整留存。但因為log全都留存下來,且log都只能存在該機器上面沒辦法外接SAN(編註:由於B企業屬於早期導入者,當時還無法做到外接SAN),所以沒辦法放太久,只能存1~3個月,這樣也就沒辦法做分析。此外,目前只能做到有下command都留,但搜尋結果return data就沒辦法留,這對未來個資法舉證可能會造成困難。即使其他DAM方案可以外接,但接下來還要考慮分析的效能問題,多久可以搜尋得到。同時DAM也要符合現在外部稽核需求,他們會要求提供存取異常的趨勢分析。

(4) 應用程式使用者判斷AP user tracking
對滿足法規稽核需求的企業而言,這是重要的功能。一般說來廠商提供多種解法,包括透過WAF整合DAM。或側錄DB及Web AP流量,依時間/內含值等條件將前端帳號對應至DB session。或於AP Server 安裝Agent等。側錄流量或安裝Agent方法雖對客戶影響不大,但Agent未必全部AP都支援或有客觀公正性上的疑慮。修改AP程式被認為是較精確的方式,于子欣指出將前端帳號代入DB session,此方法優點是支援所有AP且公正性及正確性無虞,缺點是客戶需花工修改,但技術難度不高,若客戶AP設計結構化佳則負擔可大符降低。

陳志遠指出要能找到系統的切入點在前面放initial query,initial query再帶出使用者資訊。在正常三層式架構系統中,處理順序是先進先出,A下完指令服務完才服務B,所以此類架構要判斷AP使用者不是問題,但是要在系統程序當中找到對的切入節點來放initial query,這樣才不需要在程式中的每一段都去放,例如驗證程序就是一個節點。「能不能找到這個點,對修改程式的複雜度有很大影響」他說。

(5) 代理程式與側錄模式的選擇
目前市場上主要解決方案除IBM Guardium是Agent模式外,其餘產品都可同時支援Agent與Sniffer模式。DAM架構必須配合使用者需求來看,但有時企業希望DAM不要影響DB效能,又希望能夠監控本地存取行為,這樣的需求就會彼此衝突,因為要監控本地行為就一定得在DB裝Agent,而Agent或多或少就會影響DB效能。于子欣建議如果可以透過行政命令來禁止Local使用就可讓架構單純化。

張寅建認為,sniffer模式有遺漏封包的風險,這是網路架構天生的問題,因為Sniffer模式是藉由Switch的Mirror port去複製封包,一旦遺漏就是遺漏。而Agent問題在於對DB效能的影響,至於影響程度多寡就看每一家廠商的技術而定,IBM保證對CPU效能的影響最多只有3~5%。至於不同種類/作業系統的資料庫在Agent管理上,只有第一次安裝設定時會比較麻煩,必須逐一設定。IBM的Agent是嵌在OS核心(Kernal)裡,即便一台主機裡有好幾個不同種類的DB,也只要1個Agent就可以,日後OS升級必須更換Agent的話,再重新設定即可。

于子欣指出,Sniffer模式把DB流量導出來,對資料庫效能的影響最小,而Agent模式又分成好幾種,有些不會嵌入至資料庫,只是透過網卡把封包複製一份出來,有些要咬進資料庫結構中,有些還要寫Table才能運作,而Agent與資料庫咬合程度越深,對DB效能的影響就越大。儘管Agent模式的DAM對DB效能可能會有影響,但並非完全不適合使用,在某些狀況下,例如企業開放Local使用權限但希望能監控,或者DB是VM(封包量太大)、DB與AP Server都是VM(所有流量都在同一台實體機,無法Mirror)、網路設備Switch本身mirror port已經被用完了,不得已就只能裝Agent等,因此企業在選擇時還是要看自身的DB與網路架構再來做決定。

玄力也認為應依企業環境來選擇,一般來說,Sniffer模式在佈署前期需要較多規劃與驗證測試,以確保封包不漏失。Agent模式則是在建置完成以後,必須在資料庫系統與主機升級更版時,進行變更管理,以避免影響系統穩定性。

C企業經驗談:希望早期發現特權使用者異常行為,能在本地作log過濾才符需求
C企業的關鍵重要系統分散在各外點還未集中,主要因為頻寬不足加上考量使用者執行效能與流暢度,因此系統留在外點讓本地可直接連線存取,但這麼一來就擔心各外點的系統管理者、super user是否確實照著規範操作,是否便宜行事而有資料外洩之虞。因此兩年前導入DAM主要需求在於能監控高權限使用者、DBA的使用行為,包括所下的查詢指令。然而導入後發現該產品無法區分何者為人為所下指令,何者為系統自動優化產生指令,只能將外點系統AP所有log全部傳回總部,但這麼一來很快儲存空間不敷使用,導致只能收部分外點的系統資料,若要收齊全部外點資料,必須另外加購設備,並且需要增加頻寬。而且屆時要做分析,也得把archive出來的log都倒資料回去。種種因素,目前決定重新評估DAM,首要需求就是能在各外點系統上直接過濾log。

C企業專案負責人:
> 依公司內的規定,對DB所下的查詢必須經過申請,因此對DAM的需求正是希望稽核是否有非授權查詢的行為。但目前所評估過各產品,要符合上述需求都必須要再微調系統,這麼一來不免擔心overfilter是否會掉資料…
> 廠商工程師不僅要懂產品,溝通能力也很重要,要能聽懂企業需求,才可能讓專案順利進行。


(6) 符合主管機關要求:資料異動前後的值
由於金管會要求所轄產業在個資保護的部分,必須能夠記錄個人資料異動前後的值,以瞭解是惡意竄改或是無意改錯,因此金融業在評估時越來越重視此項需求。然而DAM的原始設計並沒有留存DB的原始資料,因此廠商有不同的應對建議。IBM與玄力建議應透過AP log來留存異動前的資料比較恰當。而庫柏則對此研發出新的Update Before&After模組,可記錄變更前後的資料。林俊仁也補充,資料異動前後的值如果不在資料庫做,透過變更管理(Change Management)是另一選擇。

(7) 需求一開始的規劃與整合
正如同A企業以過來人的經驗分享,要做好資料庫稽核不會是只靠單一工具就可解決,可能需要WAF或日誌管理LM的搭配,整體效益才會上升,因此企業需在評估時,做好整體需求規劃。
于子欣也舉例一開始需求與規劃的重要,當初某企業為了要保護帳務資料,而帳務資料會出現在DB、print server、前端操作電腦,由此來看,威脅點就有三個:管資料庫的人、管Server的人、前端客服人員,所以他們導入了DAM、DLP、並搭配Local操作記錄來達到防止資料外洩目的。

(8) 部門配合與人員能力
DAM專案絕不是可以簡單導入的專案,企業有些由安控部門或者由系統部門主導,但不論由誰主導,跨部門的合作協調都是必要,例如需要AP部門改寫程式並且要跟DB配合,而稽核則要能清楚說出報表要產出些甚麼資料。B企業專案負責人也說管理人員本身專業與稽核能力、邏輯分析能力需要很足夠才行,包括管理階層亦需對相關議題瞭解,方可對事件發生時有應變能力。
而在越大型企業中越容易有組織政治議題,部門間已經水火不容,這時DAM專案導入困難度更是高挑戰,在某家企業DAM甚至已經是最高層級主管直接任命的專案,在執行上專案負責人也仍然遇到許多需要磨合協調之處。

(9) 廠商溝通技術能力
除了使用端的人員能力,廠商的溝通、技術能力也很重要。DAM與一般資安設備不同,不是只要懂網路、懂產品就好,廠商工程師還必須具備資料庫技術才能與使用者溝通。此外,在專案需求驗證階段,許多時候使用者未必能清楚說出自己的需求,則仰賴工程師能引導、發掘使用者背後的真正需求,以將工具的功能完整呈現。C企業認為廠商派來的工程師是否能聽懂企業需求,也是影響評估專案的重要因素。

釐清真正需求 做好完整規劃

這兩年來,有些早期導入的企業在DAM專案上走過一些辛苦路,企業與廠商雙方都投入許多時間。因此,最後提醒未來企業在進行POC時應注意以下重點:
1. 從「資料保護」的角度出發,也就是資料盤點>>資料分級分類>>有哪些洩漏缺口>>需要哪些資安解決方案,釐清自己真正的需求。
2. 個資盤點後把每個職務(DB使用者)的權限劃分清楚。
3. 要抓出自家DB的活動量
4. Sizing和功能測試必須分開
5. 先鎖定自己比較熟/主要的DB,測試DAM所提供policy、report…等功能是否符合需求(也就是企業要看的是什麼),倘若POC階段納入太多DB進來,反而會變得太複雜,不容易找出符合需求的產品,倘若企業採用Agent模式,且自家DB有不同OS的話,只要1種OS挑1個DB出來即可。
6. 接下來才是sizing評估,切記此時千萬不能給測試環境,否則無法反映真實情況。
7. 最後才是架構討論:包括網路架構、DB種類、儲存空間…等。

林俊仁也提醒,使用者評估DAM功能時,應回歸到原點,思考根本需求是甚麼,也就是最重要要保護的資料表與欄位是甚麼,再針對這些目標被存取的行為來監控,要達到目的的方式不是只有一種,不需要太執著於過程。

最後除了DAM之外,資料庫加密也是近期詢問度越來越高的解決方案,過去因為對DB效能影響太大而泛人問津,如今隨著技術成熟,以及滿足法規要求,又開始引起市場關注,下篇文章將深入分析各種資料加密方案。