專業服務處商業智慧服務二部 陳運昌 Antonio Chen
資料保密這個課題,在封閉型作業系統(如大型主機系統)的時代不會是很重要的課題,除了人的操守問題之外,架構本身並不會造成大量的資料外洩,也沒有系統的漏洞可以洩漏資料,原因不外乎以下幾點:
- 封閉型系統的架構有獨特的硬體設計,除了透過終端設備,無法存取系統的資料,也沒有連到外界的通道。
- 封閉型系統的通常沒有資料庫設計,往往以檔案結構的方式儲存資料,且資料內容多半有壓縮格式;即使文字格式的資料,也很少有明碼的方式儲存;更有甚者,資料檔的內容如果沒有Copy book,幾乎是沒有辦法拆解出來。
- 各家的作業系統,通常有自己的編碼格式,中文碼編碼也不盡相同。
- 各家設計的程式語言也不盡相同,從RPG、COBOL、到PL/1,不一而足,意外存取的機會幾乎沒有。
- 各家設計出的應用系統,通常存取LOG的設計都很完善(多半是金融機構),列印出任何一個畫面,都會被記錄;登入系統,也通常都有雙簽設計,難以有意外洩漏的機會。
故封閉型系統的資料保密措施,多半放在防堵人為弊端的措施中,也是ISO 27001中有關內部組織部分主要的設計項目,如下:
- 資訊安全的角色與責任
⇒ 控制措施:所有的資訊安全責任應予明訂與分配
- 職務的區隔
⇒ 控制措施:相互衝突的職務與責任領域應加以區隔,以降低組織資產遭未經授權或非故意的修改或誤用之機會。
- 與權責機關的聯繫
⇒ 控制措施:應與相關權責機關維持適當聯繫
- 與特殊利害相關團體的聯繫
⇒ 控制措施:應與各特殊利害相關團體或其他各種專家安全性論壇及專業協會維持適當聯繫
- 專案管理的資訊安全
⇒ 控制措施:不論何種類型的專案管理都應依循資訊安全
詳細的條文與做法,可以參考相關組織的網站,不再贅述。
但自從開放式系統,特別是資料庫管理系統(DBMS)逐漸流行以後,雖然大幅增加了存取資料的方便性,以及設計上的標準化與便利性,但是也因為規格上的開放與透通,讓資料被竊取的機率大幅提高。其中,前三名的資料外洩原因分別為內部人員操作失誤、外部人員盜竊資訊資產、以及釣魚式攻擊。
因此,對於資料庫內容的管理,就變成了重要的課題。
除了基本的帳號密碼的保護外,對於資料內容的加密與遮蔽就變成首要的技術問題,主要的手段大致上有以下幾種:
- 部分遮蔽:
如姓名或地址,範例如下:
姓名:「王大明」->「王○○」或「王○明」
地址:「台北市大安區敦化北路207號」-> 「台北市大安區**********」
- ID轉換:
這部分與上述部分遮蔽的方式不一樣,因為要遮蔽的都是資料檔案的關鍵值(Key),而且往往都是主鍵值(Primary Key, PK),如果加密後沒有保持唯一性(Uniqueness),整個資料庫的連結就會大亂,也就失去了資料加密的意義。
有關這種加密方式,有許多資料庫廠商、資訊安全廠商,甚至ETL工具的廠商都有提出他們的做法,通常不外乎提出經過驗證的數學轉換式,將這樣的欄位轉換為另一個無法直接以肉眼辨認的格式,而且還可以保持唯一性;有些更健全的廠商還會提出定期更換加密金鑰的做法,可以讓有意竊取者無法解密。
以上實體加密的方式,提出已經有一段時間,也有一些客戶採用,但是會有幾個比較大的問題:
- 資料加密的時間過長:
如果是全資料庫加密,特別是資料倉儲系統,常常無法在日批次或月批次的時間內完全加密完畢,更不要說如果定期更換加密金鑰,對於系統會是一個極大的負擔;而且資料倉儲系統資料只會越來越多,加密的時間就會越來越長,這時候就必須花更大的成本去提升硬體,以改善加密的效能。
- ETL程式與Schema必須修改:
有時候加密後的資料型態會變,或是資料長度會變,這樣所有相關衝擊到的資料表與欄位就必須同步修改,或是建立新的資料表;也要配合修改或新增原有的ETL程序內容;有時候還要新增更多的儲存空間來因應資料轉換的需求。
- 應用程式必須配合修改:
當資料都變更加密後,因應資料加密後的型態改變,下游的應用系統也必須做相對應的修改,以免造成應用系統的問題,畢竟應用系統才是資料使用的目的。這一點會有相當的困難,有些應用系統並不是客製的,而是套裝軟體,而且如果應用系統年代久遠,可能原有的供應商都找不到了,或是不願意配合修改,都會讓資料加密失去意義。
- 資料加密轉換的過程冗長:
以上配合修改的程序非常多,資料轉換的過程也非常長,也不是一套系統就可以掌握全貌,而是整個資訊體制都要配合,可以說是對整個資訊系統的翻轉,工程非常浩大。
- 各個資料環境的加密要求不同:
以一般使用而言,正式環境資料通常不加密,但是也會針對不同的使用單位,針對不同欄位作加密或不加密的處理;更不要說UAT/SIT/DEV環境各有各的加密要求,有時候針對各個長短期專案需求也有不同的加密需求,整個加密環境會變得非常複雜。
以上的問題,其實對於資料加密來說都是很致命的,也讓衍生出的時間、人力、以及實體成本難以估計,有時候還會招致使用者的怨言等等,都讓資料實體加密的做法窒礙難行。
針對這個狀況,Informatica提出了一個革命性的做法:Dynamic Data Masking,不但加密機制建置快速,而且對於加密內容的設定還非常有彈性,好處如下:
- 大幅減少資料外洩的風險。
- 可以透過簡單的調整資料加密的組合,適應不同的法規或是商業需求。
- 可以同時支援外點單位、外包商、以及雲端使用者的使用需求。
- 支援大數據資料庫。
- 不影響使用者的生產力、底層資料庫架構與資料內容,以及查詢的效能。
實際做法如下:
- 提供豐富的加密機制:
加密的方式非常多元,從資料遮蔽、資料錯置、雜湊法、亂數法、部分遮蔽等不一而足,但是卻可以保存資料庫內資料原有的樣貌,也保持了資料的整體性(也就是文前提到的鍵值唯一性)。
- 以規則為基礎的管理方式(Rule-based access control , RBAC):
可以針對AD或LDAP中的角色(Role)做個人式資料加密設定,這些角色可以是真正的使用者,或是應用系統的帳號。
- 可擴充式的架構:
可以依實際資料庫的成長量與速度擴充資料加密系統,以支援數以百計的資料庫,上千的併行用戶。
- 建置簡單快速:
透過簡單的設定,幾天內即可完成相關的設計,而且內建的資料加密規則非常多樣,可以快速地透過簡單易懂的設定介面完成設計。
- 與現有的權限管理機制完整結合:
包含Microsoft Active Directory, LDAP 與IAM。
- 即時進行資料加密作業:
資料加密在存取指令下達的同時進行,原始資料的內容卻完全不會改變。
以下是實體技術架構圖:
上圖的技術做法主要是在介於最上層(User)以及最下層(Database)中間的這一層,就是這個加密產品的所在,可以看到他基本上是一個代理伺服器(Proxy Server)的角色,所有的加密原則都會設定在這裡,所有最上層 (不論是透過應用系統,或是資料庫操作介面) 的使用者,都不再直接連到資料庫,而是連到這一部代理伺服器中,也就直接的被這部代理伺服器管控。
所有原有的資料存取途徑被改變,從:
- User登入資料庫
- 將資料存取指令(如Select …From)下給資料庫
- 資料庫回覆查詢結果給User
變成
- User登入代理伺服器
- 將資料存取指令(如Select …From)下給代理伺服器
- 代理伺服器將資料存取指令根據權限下給指定環境(Prod/UAT/SIT/DEV)的資料庫及資料表(如果User有權限可以存取該資料)
- 資料庫回覆查詢結果給代理伺服器
- 代理伺服器根據之前針對該User的資料加密規則予以即時加密
- 代理伺服器回覆查詢結果給User
到這裡也許有人會開始質疑這個代理伺服器的機制會不會變成效能的瓶頸?這裡提供一份Benchmarking的資料:
- 測試設備:Red Hat Linux 64 bit 16 core Intel Xeon CPU with 32 GB RAM
- 軟體:Dynamic Data Masking 9.1.1
- 資料庫:Oracle 10g database
- 產生SQL的工具:安裝於Window client
- 測試情境:測試大量的Select指令,目標資料表設定了加密條件。
- 測試程序:
第一輪下查詢指令,但是直接連到資料庫,不透過Dynamic Data Masking,而且連跑三次。
第二輪下查詢指令,但是透過Dynamic Data Masking連到資料庫,也是連跑三次。
- 測試結果:
► Dyn amic Data Masking在0.15 millisecond內回應SQL指令。
► Throughput: 3,500 SQL requests per second
► 資源消耗:3% of the database server CPU utilization and less than 1 GB of memory
看到這裡,透過這套系統來實作資料加密,會是一個既省力又省工又省錢的解決方案,已經是無庸置疑的。問題就再度回到這樣的專案的本質了,如:
- 事前的資訊資產的盤點
- 各個資訊資產對各單位的使用權限的清點
- 權限變更的管道
- 實施與上線的順序
- 行政程序的調整
- 資安規範的修改
- 前端使用者的溝通與教育等
以上這些工作,才會是資料加密工作的本質。也就是說,透過這套簡明易用的軟體,讓從事資料加密的工作者能更加專注於資料保密工作的本質,而不被複雜的技術程序,佔去了真正思考的時間,回歸資料加密專案的本意:保護機敏性資料,又不影響正常的營業使用。