資料庫行為監控(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效能影響太大而泛人問津，如今隨著技術成熟，以及滿足法規要求，又開始引起市場關注，下篇文章將深入分析各種資料加密方案。