不論是維持企業營運所需的內部核心系統，或是對外業務服務所需的線上系統，存放企業內部多數高敏感性資料的關聯式資料庫，可說扮演至關重要的角色。只是應用服務系統在傳統三層式（3-Tier）架構下，對於服務的安全性與可用性，往往較著重於前端應用層，最末端的資料庫卻只仰賴排程備份，讓系統發生損毀時得以及時回復。
Chalet Tech（玄力科技）台灣區總經理顏良修即觀察到，多數企業都認為資料庫相當重要，但是卻無法掌握其存取的細節情形。「單純就管理面來看，我遇到百分之七十的客戶都無法清楚回答究竟有多少人有權限登入？可以取得哪些表格（Table）內容？每天登入存取的帳號有哪些？取得哪些資料？諸如此類的問題。」
當資料本身是具體存在時，要進行管理較簡單，但是當資料在封包中傳遞，變得抽象時，要一一盤查就顯得困難。再加上IT系統在多數企業的定位並不屬於業務單位，必須仰賴每年編列預算執行，於是常見正常運行時被視為理所當然，只有在開始出現問題時，企業才會發現其重要性，包括資料庫系統也是。
庫柏資訊總經理林俊仁亦指出，現代企業的IT基礎架構大多外網與內網切割很清楚，但不表示內網的資料庫系統就不會被駭客攻擊，只是多數的客戶認為，實體切割架構比較不容易被入侵；另一方面，企業高階管理層往往擁有特權，資安控管機制根本無法生效，相較於駭客，源自內部的風險威脅才最難防範，日前爆發手機大廠研發部高層涉嫌洩密被收押就是典型的案例。因此不管是個資法，或是今年二月施行的營業秘密法修正案，都是針對資料由內而外流出的重罰法規。
除非事業主管機關有明定必須遵守的法規，像是銀行法、醫療保險可攜及責任法（HIPAA）等，已明確指出必須採取資料保護措施，自然有較周延的防護機制，至於其他企業則是隨著個資法實施後，才逐漸開始正視資料庫安全問題。
透視資料庫存取行為
加密與稽核是目前資料庫安全較常見的保護方式，其中因應稽核要求而生的資料庫活動監視（Database Activity Monitoring，DAM），讓抽象的存取行為變得可視化，是近年來台灣企業在法規遵循要求下較受關注的解決方案之一。
台灣IBM軟體事業處資深技術顧問張寅建指出，儘管如今談起個資法，許多人還在等待判例出現，以便決定法規遵循的措施應該實施的程度，但不管面對法規的態度與思維如何，基本都應該要有資料留存機制，萬一不幸遇到訴訟案件時，才能夠有相對應資料自我保護。
在開始以DAM監看資料庫行為之前，首先必須先了解資料庫本身可能的風險，之後定義敏感性資料並找到存放的位置，如此再執行監看機制才有其效益。監看動作就如同攝影機般，每個連線進入資料庫行使的活動，皆會被詳加記錄，一旦發生資安事件，才可查找事後資料來求證。當然，將記錄資料進一步轉化為可讀的報表，更是DAM中基本必備。亞利安科技資安技術支援部經理王添龍觀察導入DAM的客戶，多數在企業內部需維護多套不同廠商、不同版本的資料庫系統，因此藉由DAM來整合監看各系統的運作狀況，並且產出統計報表。
掌握誰在操作資料庫
就DAM解決方案的架構來看，Chalet Tech（玄力科技）、庫柏資訊（Cobrasonic）、iMPERVA等廠商，皆是採專屬設備搭配資料庫系統代理程式（Agent）的混合式架構，而IBM Guardium則是以純軟體式為主。張寅建說明，在傳統三層式架構下，為了提高應用傳輸效能，常在應用程式伺服器端建立Connection Pool，來加快跟後端資料庫之間的連線建立。但問題是，資料庫端接收到的Connection皆是預先建立，因此記錄的存取者皆為Application User，必須要有可識別機制。
市場上可識別的方法，一般是DAM設備藉由擷取用戶端與應用程式之間傳遞的封包，以及應用程式與後端資料庫之間傳遞的封包，兩者相互Mapping來判斷。但是，中間層應用程式本身並沒有任何機制來確認配對，必須仰賴時間戳記（Timestamp）來判斷。
「用時間戳記就有一個很大的問題，就是在同時連線數（Concurrent Session）過多的應用環境，很容易發生誤判或遺漏。而Guardium的方式是在應用伺服器端提供API，讓用戶端主動帶入資訊。」張寅建說。此API在實作上稱為虛擬（Dummy）SQL，不是真正的SQL語法，但是得以將參數帶到資料庫系統，此時DAM只要擷取Dummy SQL的參數值，即可將此連線行為跟前端使用者串在一起。
只是Dummy SQL必須被增加在應用程式端，因此必須修改程式碼。張寅建不諱言，多數企業對修改程式碼的動作皆有疑慮，擔心會因此變更既有的架構。若是Java環境就會單純許多，只要在Connection request上加入陳述式即可。以Oracle資料庫為例，只要增加「select‘GuardAppUser:id_ip’from dual;」，使用者一旦連線登入應用程式，輸入帳號與密碼，就會自動帶入該登入帳號與IP位址到資料庫系統，Guardium看到為「GuardAppUser」即可識別，並記錄為該筆應用程式連線的使用者名稱，且由於Guardium是依據session來記錄，之後所執行的SQL陳述式，皆會被記錄為該使用者名稱的存取行為。
甚至若需要更多登入者資訊，在「id_ip」之後可再增加，如「id_ip_hostname」，把主機名稱也帶入，有客戶用此機制，串了十多種資訊，雖然是連續的字串，但中間都有「_」分隔，即可依照該字串的格式擷取相對的資訊，成為完整的稽核記錄。「儘管Guardium需要修改程式碼才能做到完整記錄，但若需要到百分之百確認前端登入者，只有此方式串連的資料可信度最高。」張寅建強調。
至於庫柏資訊dbAegis的作法，林俊仁說明，主要是記錄SQL語法的Insert、Update、Delete...等指令，並解析網頁應用程式的Http語法，成為統計模型，來加快反應速度，並且會有學習機制。「其實各家DAM作法大致類似，差異只在於統計模型的方式、演算法、精準度。雖然統計模型發展至今日趨成熟，只是前端應用程式變化較快，誰能夠跟得上前端應用程式變化的腳步，才能維持其競爭力。」林俊仁強調。