• 關於庫柏
  • 新聞中心
  • 媒體焦點

媒體焦點

網管人: 法規遵循需求推動 資料庫稽核市場穩步擴展

2013/10/21

呈現「人」的存取行為 稽核報表更具價值

法規遵循需求推動 資料庫稽核市場穩步擴展

洪羿漣
不論是維持企業營運所需的內部核心系統,或是對外業務服務所需的線上系統,存放企業內部多數高敏感性資料的關聯式資料庫,可說扮演至關重要的角色。只是應用服務系統在傳統三層式(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作法大致類似,差異只在於統計模型的方式、演算法、精準度。雖然統計模型發展至今日趨成熟,只是前端應用程式變化較快,誰能夠跟得上前端應用程式變化的腳步,才能維持其競爭力。」林俊仁強調。

引用出處:網管人http://www.netadmin.com.tw/article_content.aspx?sn=1310080004