新版個資法來勢洶洶，個資法施行細則修正草案也已經出爐，不久的將來，所有會接觸到個資的軟體／系統也將面臨前所未有的考驗，開發人員必須趕緊跟上腳步，除了釐清個資法帶來的影響外，還要進一步瞭解如何因應個資法所帶來的技術衝擊，以免當這些硬梆梆的法律條文出現時，反而不知道如何將個資法的種種要求落實在既有系統之中，這也是本文的宗旨，希望提醒各位開發人員，面臨新版個資法的衝擊，應該提早準備哪些必學的知識與技術。
新版個資法雖然訂有非常高額的罰款，同一原因事實造成多數人損害最高可處罰新台幣2億元，但這些損害賠償責任與罰則並非此法的重點，其重點在於希望民眾與企業建立「個資有價」之觀念，以及「資訊系統欠缺合理安全措施，即構成隱私權侵害」。「個資有價」之觀念是希望使用者建立起個資有價的意識，當個人資料外洩時，可以向企業要求賠償，不僅如此，企業還被要求負起舉證責任，對企業來說，這等於是一顆不定時炸彈，因為個資外洩造成的原因很多，要做到100%防堵幾乎是不可能。還好，新版個資法施行細則草案第九條，已經明確定義出「舉證責任」的範圍，只要企業能提出這些保護個資的部分或全部舉證資料，就能有效避免損害賠償責任與罰則的發生。
在這些必要措施中，很多都與開發人員沒有直接關係，但是第九點「資料安全稽核機制」與第十點「必要之使用紀錄、軌跡資料及證據之保存」，則是程式開發人員可以努力的部分，以下將針對這兩點提出各種可行的技術解決方案供開發人員參考。在這兩項必要措施裡，可用來進行個資保護的技術很多，主要有身份認證(Authentication)、角色授權(Authorization)與存取控制(Access Control)、資料加密、資料保護、安全設定、系統操作記錄、個資變更歷史記錄等等，以下將一一介紹需要注意的地方以及採用方式。
身份認證
資訊系統如果會牽扯到個資，最基本的防護原則就是要做到身份認證，不讓未經授權的人使用或進入該系統取得資料，開發人員絕不能假設系統網址只有自己人知道而不做出任何防護，要是被個資受侵害的使用者告上了，企業這方若無法提出任何身份認證的實作證據，那可是完全說不通的，只有乖乖挨罰的份了。
在ASP.NET中，最常見的身份驗證技術就是使用FormsAuthentication類別進行實作，當處理完基本的帳號、密碼驗證正確後，便可透過以下程式碼賦予目前使用者一個「已登入」的身份：
FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(1,
strUsername, // 登入帳號
DateTime.Now,
DateTime.Now.AddMinutes(30),
isPersistent,
userData,
FormsAuthentication.FormsCookiePath);
// Encrypt the ticket.
string encTicket = FormsAuthentication.Encrypt(ticket);
// Create the cookie.
Response.Cookies.Add(new HttpCookie(FormsAuthentication.FormsCookieName, encTicket)); |
而在你的系統中，要辨識出使用者是否已成功通過身份驗證，則可利用以下程式碼進行判斷：
if(User.Identity.IsAuthenticated)
{
Response.Write("您現在是已登入狀態。");
} |
更多實作細節可參考筆者另一篇文章〈概略解釋 Forms Authentication 的運作〉。此外，當認證控制措施發生錯誤時（例如當下連不上Active Directory無法進行驗證），也要能確保系統不會被任意存取，絕不可發生驗證失敗卻又能進入系統等情事。
以下幾點是開發人員在實作身份認證時可以參考的規則：
- 完整記錄身份驗證結果，包括登入成功與失敗的資訊，並定時追蹤登入失敗的資訊，確保系統安全。
- 將使用者密碼儲存至資料庫時，不應用明文儲存，開發人員應該將使用者的密碼作雜湊(Hash)處理，以免資料庫外洩而導致密碼被駭客擷取，進而引發個資外洩的疑慮。
- 在執行取得大量個資動作時（例如匯出會員資料），必須要求使用者重新認證一次，以確保為本人操作系統。
- 使用者登入一段時間且沒有任何使用記錄時，應該主動將使用者登出。
- 系統中所有認證資訊（例如連結資料庫的帳號密碼）都必須加密存放於應用程式之外，不可直接存放於原始碼中。
實作小叮嚀
筆者早期曾經遇過開發人員將「身份驗證」工作直接實作在「用戶端」，也就是直接以JavaScript驗證使用者輸入的帳號、密碼，這是完全行不通的作法，因為駭客可以很輕易地關閉或修改用戶端的JavaScript程式來跳過這個驗證需求。因此開發人員必須特別注意，所有認證控制措施都必須在「伺服端」進行，絕不可使用JavaScript在前端做認證。 |
角色授權與存取控制
當我們做到身份認證後，接下來就必須確保使用者只能存取權限內的系統功能與資料，以維護系統的完整性與機密性。從實務上來說，我們通常會在資訊系統中設定幾個特定的角色，並在設定系統操作權限時，將權限的設定都套用在角色上，最後再對登入系統的操作人員設定其隸屬的角色，如此一來可以簡化權限設定上的複雜度。
就Web應用程式來說，存取控制要注意的地方不僅僅是「特定功能可否使用」而已，有些存放在Web伺服器上的檔案也必須要控管，所以除了針對後台功能進行控管外，針對可以透過URL直接存取到的檔案也必須限制存取才行。舉個之前筆者曾經輔導過的一個案例，當時客戶網站裡的確有角色授權與存取控制機制，但是只針對特定頁面與功能做限制，卻忘了針對「靜態檔案」的部分做限制，當時他們網站後台有上傳檔案的功能，上傳路徑為網站根目錄下的/Uploads/File/目錄，這個目錄並沒有做任何的存取控制，而那些未經驗證的使用者雖然無法操作後台功能，卻能透過URL直接存取這些已經上傳的檔案，只要輸入「網址/目錄名稱/檔名」即可，如：http://xxx.com/Uploads/File/Member.xls，如果這些上傳的檔案內含個人資料的話，那就非同小可了。
你可能會覺得奇怪，「未經驗證的使用者」怎麼會知道這些可以直接下載檔案的URL是什麼呢？難道是這些已授權的使用者洩漏出去的嗎？許多使用者並不知道「未經驗證的使用者」其實還包括「搜尋引擎機器人」，假設你的瀏覽器安裝了搜尋引擎所提供的瀏覽器工具列(Browser Toolbar)，當你在瀏覽網站的同時，也會將你瀏覽的網址傳送回他們的伺服器，好讓他們能夠進一步檢索任何他們原本檢索不到的網頁，當然也包括這些未經身份驗證就能存取的「靜態檔案」。
要防止搜尋引擎機器人來抓取特定目錄下的資料是有業界標準的，我們只要在網站根目錄下新增一個robots.txt文字檔，並定義特定目錄不允許「搜尋引擎機器人」進行存取。假設我們預設允許所有搜尋引擎前來抓取網頁，但要限制特定目錄（/Uploads/）不允許存取的話，可參考以下robots.txt的內容範例：
User-agent: *
Disallow: /Uploads/
Allow: / |
這種設定方式只是禮貌性的告知搜尋引擎機器人限制抓取的路徑，事實上真的要抓取網頁檔案還是可以的，因此這個技巧也僅適用於「搜尋引擎」的部分而已，網站系統要真正做到安全，還必須更嚴格的限制其存取路徑。ASP.NET內建了一個非常簡單的方法，只要修改web.config設定檔，就能限制特定URL一定要先通過身份驗證才能存取該檔案。以下為限制/Uploads/目錄一定要先通過驗證才能存取的程式範例，如果你想這麼做，可以將此套用在網站根目錄下的web.config設定檔之中，但要注意，這種驗證設定必須使用ASP.NET標準的驗證模式才能生效，例如使用FormsAuthentication或透過Windows驗證的方式都可以。
<?xml version="1.0"?>
<configuration>
<location path="Uploads">
<system.web>
<authorization>
<deny users="?"/>
</authorization>
</system.web>
</location>
</configuration> |
人事行政局曾經發生過個資外洩事件，當時他們把僅限公務人員才能下載的資料放置在一個公開的FTP伺服器上，然後再把FTP的存取路徑設定在網站資料庫中，雖然該網站需要登入才看的到有哪些檔案可下載，但是卻沒注意到檔案放置在一個可公開存取的FTP伺服器上，還進一步被Google搜尋引擎建立了快取資料，即便檔案已儘速刪除，但Google搜尋引擎還是留存這些含有個資的資料。
等新版個資法正式生效後，諸如此類的資安事件若再度發生，將會導致企業或組織陷入危機，因此開發人員一定要先建立正確的資安防護觀念，才能真正確保系統無虞。在資安領域中我們常提到，一個資訊系統的資安強度，取決於系統中最脆弱的一環，在組織裡，即便有再多的個資政策與資安規範，只要開發人員不夠注意，資安人員又沒有掌握到這些細節，稽核人員又查不到這些地方時，個資外洩的風險就會大幅提升。
以下幾點是開發人員在實作存取控制時可以參考的規則：
- 關閉IIS中目錄瀏覽功能；
- 善用ASP.NET角色實作各類權限控管的機制；
- 確認使用者僅能存取權限內的服務；
- 所有存取控制措施必須在伺服器端強制執行；
- 所有存取控制的結果都必須被記錄，包括驗證成功與失敗都應記錄。
資料加密
開發一個安全的資訊系統，基本的資料加密工作不可或缺，但資料加密可以區分為幾個不同的範疇，其中較常見的有「網路傳輸加密」與「資料庫加密」兩個部分。「網路傳輸加密」是為了要確保個人資料在網路傳輸的過程中，不會被有心人士從中攔截，保護個人資料不會輕易外洩，要做到這點其實非常容易，只要在網站伺服器上安裝SSL憑證，就可以輕鬆完成這個任務，但是網站程式也必須特別修改，讓會牽扯到個資功能的頁面強迫進入HTTPS傳輸模式才行，以下是一段範例程式供參考：
protected void Page_Load(object sender, EventArgs e)
{
if (!Request.IsSecureConnection)
{
Response.Redirect(Request.Url.AbsoluteUri.Replace("http://", "https://"));
}
} |
「資料庫加密」就是在重要的機敏資料儲存至資料庫之前，先將資料加密過再進行儲存，確保資料庫的原始資料本身是加密過的，這部份依據不同的資料庫系統會有不同的解決方案，筆者在此以SQL Server為主要的資料庫系統作介紹。SQL Server已經內建完整的資料庫加密功能，其最主要目的在於，確保儲存在磁碟中的原始資料本身是加密過的版本，這也代表著任何一份資料庫備份中的資料都是加密過的，就算資料庫備份檔被駭客劫走，駭客也無法輕易解開裡面的內容，以達到保護的目的。
當然，在加解密的過程中會消耗掉一些CPU與記憶體資源，因此不建議將所有資料進行加密儲存，不過我們為了個資法的要求，開發人員可以選擇將牽涉到個人資料的欄位都改以加密方式儲存，確保這些個資都能夠被妥善保護。在個資法中已明確列出「個人資料」的欄位，包括自然人之姓名、出生年月日、國民身分證統一編號、護照號碼、特徵、指紋、婚姻、家庭、教育、職業、病歷、醫療、基因、性生活、健康檢查、犯罪前科、聯絡方式、財務情況、社會活動等等，但除了這些明訂的資料外，任何其他得以直接或間接方式識別該個人之資料也都包含在內，因此在規劃資訊系統的時候，還是要再次檢視哪些欄位可能被列為個資，並予以加密儲存，關於技術方面的主題可參考MSDN上〈SQL Server 加密〉文件。
實作小叮嚀
由於個資法要求企業擔負舉證責任，只要能盡可能地保護客戶資料不外洩，就越能證明有心想把個資保護做到最好。 |
資料保護
資料保護與資料加密的概念不太一樣，這裡講的是保護使用者的個人資料不會被輕易取得，開發人員應該建立一些資料保護的資安概念，才能寫出真正對使用者有保障的程式。在網站裡可能有很多敏感的個人資料並非儲存在資料庫中，而是儲存在檔案裡，舉例來說，網站執行過程中若會儲存一些追蹤資訊或是網站應用程式的錯誤處理記錄，這些追蹤資訊可能會包含個資，在這種情況下，你應該將這些檔案儲存在無法直接透過網站伺服器存取的目錄下，在ASP.NET裡有個特殊的App_Data目錄就是這個用途，對於這些牽涉到個資的檔案記錄，開發人員可以選擇將檔案儲存在這個目錄下，確保檔案不會直接透過瀏覽器下載。
在設計網頁表單時，很多瀏覽器都有表單自動完成功能，若使用者使用的是公用電腦，在網站表單上輸入個資的時候就會被自動記憶下來，如此一來就會有個資洩漏的風險。開發人員應該在網頁表單上設定關閉自動完成功能，來避免此類個資問題的發生。假設我們有個文字輸入框的HTML如下： <input type="text" id="textinput" />，要關閉自動完成功能，只要加上autocomplete屬性，並設定為off即可：<input type="text" id="textinput" autocomplete="off" />
網站伺服器一般來說都有記錄功能，可以將每個HTTP要求的摘要資訊都寫進記錄檔中，其中也包括了所有查詢字串(QueryString)，我們都知道表單的送出方法有好幾種，最常見的有GET與POST這兩種，如果你的表單使用GET方法送出的話，所有表單資料都會被串接到QueryString之中，代表這些資料全部都會被儲存到網站伺服器的記錄檔中，如果表單的內容牽涉到個資，那麼伺服器記錄檔將會是另一個個資洩漏的管道，因此開發人員在撰寫網頁表單時請務必記得調整為POST方法，才能確保個資不會被記錄到網站伺服器的存取記錄(Access Log)之中。
開發網站應用程式，無論如何資料都必須傳到用戶端才能顯示，你可以做到「網路傳輸加密」確保資料傳送的過程中不被擷取，但是資料畢竟還是會儲存到用戶端（瀏覽器）上，如果傳輸的內容包括個資，開發人員應該避免這些資料或頁面被快取在用戶端，如果個資必須儲存在用戶端進行快取，也必須實作加密機制，確保個資不會被有心人士輕易取得，而且當這些機敏資料無須使用或過期時，也應立即清除所有快取資料。
系統操作&個資變更歷史記錄
由於新版個資法要求保存必要之使用記錄與軌跡資料，因此保留完整的操作記錄非常重要，如此一來可以得知特定人員在特定時間取得了哪些資料。然而留下系統操作記錄不是什麼難事，怕的是記錄到的資料沒有證據力，那就白費功夫了。尤其系統使用記錄、軌跡資料與證據的保存，細則草案第九條都有明訂，開發人員需與MIS共同制定管理方式。
基本上，開發人員可依據「人、事、時、地、物」的原則來對系統進行規劃與設計，表1是可能需要記錄的欄位資料，舉例來說，記錄類型如果是「人」，可能需要記錄的資料有操作人員帳號或角色；記錄類型如果是「時」，可能需要記錄的資料有操作時間點。
表1、需要留下系統操作記錄的欄位資料表
| 記錄類型 |
記錄的欄位或資料 |
|
人
|
操作人員的帳號、角色 |
|
事
|
操作的功能與參數 |
|
時
|
操作的時間點 |
|
地
|
操作人員的來源IP地址、使用的主機名稱、伺服器的主機名稱 |
|
物
|
操作執行的結果（如成功或失敗）、查詢條件、資料回傳筆數、回應訊息內容 |
資料來源：本文作者整理，2011/12。
企業可以保留完整的系統操作記錄，但這些記錄應該不會儲存完整的查詢結果資料，如果我們因為個資法的歷史軌跡要求而將完整的查詢結果資料儲存在記錄檔中，將會導致記錄檔佔用了非常大量的磁碟空間，這樣的設計反而失去了系統的彈性。因此，實務上我們可以選擇儲存所有個資的變更歷史記錄，只要牽涉到個資的欄位發生變更時，一樣可以依據「人、事、時、地、物」的原則記錄這些變更歷史，到時只要交叉比對操作記錄與個資異動記錄，就能比對出當時特定人員所取得的個資為何，以達到證據保存之目的。
總結
開發人員為了因應這波新版個資法的衝擊，無論如何都必須做出一些改變，尤其是在思維上必須完全站在個資保護的立場來思考系統的規劃與設計，要打造出符合個資法規的網站系統，說難也不難，說簡單也可以很不簡單。
筆者認為，開發人員覺得難的地方在於不知道如何面對個資法的種種要求，這種不確定感會導致大家在開發系統時感覺十分徬徨，不知道怎樣做才是對的，但只要掌握住一些新版個資法的核心原則，相信能夠開發出符合個資法的系統，筆者在本篇文章中提出幾個可以注意的點，或許無法面面俱到，但只要所有企業都能適度的對新版個資法做出回應，開發人員都能理解並對個資法的要求做出一絲努力，相信就已達成當初立法的初衷，向全民推廣「個資有價」之目的。
（本文作者現任職於網路資源整合服務公司。如您對本文有任何感想，歡迎來信交流：isnews@newera.messefrankfurt.com。）