【技術e專欄】從應用系統的權限控管到隱私保護
近來不管是政府機關或是民間機構，都投入了大量資源來確保組織能夠符合新版「個人資料保護法（個資法）」的要求，本文將從應用系統的設計與開發角度，談一談如何落實對個人資料的隱私加以保護，以符合個資法保護個人隱私的主要精神。
防範組織內部的合法使用者之不當使用
首先，我們可依組織外部與內部這兩個資料竊取的管道來探討如何保護個人資料。外部指的是組織外部的非合法使用者，透過特殊手法入侵組織的網路，進而竊取組織內系統中的個人資料。
這部份的防範比較屬於防火牆、網管等系統面問題，不在本文的討論範圍。我們主要是聚焦於如何防範組織內部的合法使用者，不當使用應用系統內的客戶個人資料。 談到保護應用系統內的個資，開發人員第一個想到的可能是權限控管：透過適當的資料存取控管（Access Control）機制來保護個資。的確如此，存取控管機制是保護個資的基礎設施，但僅有傳統的存取控管機制，並不能完全落實個資法對隱私保護的要求。以下我們將仔細說明其中概念上的細緻差異，並概略勾勒實作上需要怎樣的機制來落實。
應用系統安全防護核心3A：認證、授權、紀錄 話說從頭，應用系統安全防護核心可分為三個面向：所謂3A或AAA ( Authentication, Authorization, Accounting )。認證(Authentication)是3A架構的第一道關卡，指的是要辨認使用者(可以是人員或程式)的身份；授權(Authorization)就是資源的存取控管(Access Control)，用以判定使用者是否有權使用特定的資源，授權是政策管理(Policy Administration)的核心工作項目，主要精神在於根據安全政策給予使用者所能擁有的權限；紀錄(Accounting)的工作項目包括量測(measuring)、監控(monitoring)、報告(reporting)各種資源使用量及事件紀錄（log），以提供後續的稽核(Audit)、計費(billing)、分析(analysis)與規則管理之用，因此紀錄的主要精神在於收集必要的使用者與系統之間互動的資料，最完備的作法就是「凡走過必留下痕跡」，鉅細靡遺地記錄所有的互動。
一般應用系統所謂的「一般應用系統所謂的「存取控管」多半是指的是「認證」與「授權」的管理，不含記錄部分[註1]。例如，Java平台企業版（Java EE）中的 Java Authentication and Authorization Service (JAAS)。」很明顯的，存取控管是個資保護的起點，所以以下我們將先從存取控管的細緻度（granularity）差異談起，再談為何細緻度高的存取控管仍不能完全落實保護個資隱私。
我們以<user, data="">三個層級的架構來分析應用系統使用者與系統間的互動與存取控管的需求，這裡要表示的是某user提出執行一系<user, data=""> 註1. 但這不代表記錄（log）不重要，文末我們會討論記錄的重要性。統功能（function）的要求，期間可能會存取某些data，透過這三個層級可以充份掌握不同細緻度的存取控管需求。首先，user層級表示控管規則只要求確認使用者的身份及可，屬於最粗的控管層級(coarse-grained)。其次，function層級次之，因為某些function的執行需要使用者滿足進一步的控管限制。最後，data層級最為細緻(fine-grained)，使用者跟所欲存取的資料之間必須符合特定的限制條件。
<user, data="">例如，在B2C應用程式中，商品瀏覽與選購是不需身份認證就可以執行的，但是要結帳下單就必須先確認其身份，這就是user層級的控管；下單後，訂單的刪除只有系統管理員才能執行，這屬於function 層級的管控；訂單的查詢瀏覽則只能限於屬於自己的訂單，而不能看別人的，這就是data或instance層級的控管。尤有甚者，顯示訂單內容時，應該將如身分證字號或信用卡號碼等敏感資料欄位隱藏，這是更細緻的欄位（field）層級的控管。
<user, data=""> 存取控管規則各有不同
<user, data=""> 有了以上的分析架構，我們可以用下列的形式化規則來模型化應用系統的存取控管需求：
Rule: <funName, dataName[-fieldNames], authType, constraint>
<user, data="">Rule: <funname, constraint=""> 這裡funName指的是被限制存取的功能函式名稱，dataName則是在函式中被存取的物件型態，fieldNames則是指明了哪些物件的屬性(欄位)是必須加以限制不讓使用者看到的，這些屬性的資料在呈現給使用者之前會被遮蔽(Mask) ; 如果沒有列出，則表示使用者可存取物件中所有的屬性。其次，authType表明執行此功能必須先通過的認證方式（password或digital certificate等)。最後的constraint是一個布林運算式，用來決定是否允許使用者的存取要求。它的內容主要是引用User、Data兩個物件外，以及一些基本的關聯運算子，像是等於(equals)、小於(less)，以及集合運算等，來表達存取控管規則的需求。其中User物件是包含使用者各項屬性的物件，Data物件則是規則中系統功能所存取的資料，例如：Order。我們可以在constrain運算式中引用這些物件的屬性來表達不同層級的存取控管條件。
<user, data=""><funname, constraint="">以下舉三個不同細緻度的範例說明此種規則格式，其中第二個就是常用的以角色為基礎的存取控管（Role-Based Access Control, RBAC），第三個則是最細緻的以資料內容為控管規則。
<user, data=""><funname, constraint=""> 範例一：使用者必須以密碼（password, PWD）登入後才能下訂單。
Rule： <createOrder, Order, PWD, True>
<user, data=""><funname, constraint=""><createorder, true="">範例二：使用者必須登入，且擁有管理員角色（ ＂admin＂）才能刪除訂單。
<user, data=""><funname, constraint=""><createorder, true="">Rule： <deleteOrder, Order, PWD,
<user, data=""><funname, constraint=""><createorder, true=""><deleteorder,> 範例三：使用者必須先登入後才能查詢訂單，而且只能瀏覽自己的訂單，並不得顯示信用卡號碼。
<user, data=""><funname, constraint=""><createorder, true=""><deleteorder,>Rule: <viewOrders, Order[-creditCardNumber], PWD,
<user, data=""><funname, constraint=""><createorder, true=""><deleteorder,><vieworders,> 還有一些更細緻的存取控管需求必須將環境（context）的限制納入考量，常見的這類需求是存取的時間與使用者登入系統的機器網址（IP）。我們可以在constrain運算式中，引入一個Context物件與一個系統參數物件（System）來表達此類的條件。例如：以下運算式限制存取時間必須是上班時間，而且是從某一部特定IP的機器。
<user, data=""><funname, constraint=""><createorder, true=""><deleteorder,><vieworders,>contains(System.getAttr(“WorkingHours＂),
<user, data=""><funname, constraint=""><createorder, true=""><deleteorder,><vieworders,>Context.getAttr(“time＂)) and
<user, data=""><funname, constraint=""><createorder, true=""><deleteorder,><vieworders,>equals(Context.getAttr(“IP＂), “65.2.5.8＂)
<user, data=""><funname, constraint=""><createorder, true=""><deleteorder,><vieworders,>個資的「使用目的」必須納入存取控管的考量
<user, data=""><funname, constraint=""><createorder, true=""><deleteorder,><vieworders,>但是即使有了以上如此細緻的存取控管規則，仍然還不能完全捕捉到個資隱私保護的需求。為什麼呢？這要從隱私權的基本概念談起。一般都以學者Warren 和 Brandeisy 在1890年於「哈佛法學評論」第4期所提出的「不受干擾的權利」（right to be let alone）（亦譯成獨處權）作為隱私權的理論基礎。 舉個例子，往來的銀行通常擁有我們的個資，包含電話號碼，因此我們常接到銀行行銷人員打來的電話，跟我們推銷各類金融商品。依照目前新版個資法的規定，我們可以明確告知對方，以後不願意再接到這類電話，這就是一種「不受干擾的權利」。
<user, data=""><funname, constraint=""><createorder, true=""><deleteorder,><vieworders,> 不過這樣的概念要如何連結到應用系統的設計與開發呢？我們可以從以上的例子找出一些端倪。雖然我們不願意接到商品推銷的電話，但是如果銀行來電是為了通知一些我們帳戶的權益問題或是客戶服務事項，我們應該是願意接這通電話的。這兩種情境，從應用系統的存取控管規則來看，都是要依使用者權限讀取客戶的電話號碼，無從分辨其差異性。但從隱私權看，其中細微差異在於銀行（廠商）取得我們的個資（電話號碼）後，所要執行的動作（播打電話）的「目的」（purpose）為何？如果目的是產品行銷，我們就不接受；但若目的是產品售後服務，我們就願意接受。也就是說，個資的「使用目的」必須納入存取控管的考量，這是個資隱私保護比一般存取控管要來的細膩之主因。
<user, data=""><funname, constraint=""><createorder, true=""><deleteorder,><vieworders,> 因此，應用系統的功能若是會使用到客戶個資，除了一般的存取控管規則外，都必須還要有「目的」這一詮釋屬性（metadata）。相對的，我們在取得客戶個資時（或是後來因應此項個資法規），也必須告知客戶我們的系統將會如何使用這些資料（目的），並取得客戶對那些功能的「目的」（intended purpose）是否同意（consented purpose），以作為應用系統執行時的個資存取控管依據。有了以上說明，我們可以將「目的」納入存取控管規則，採用下列結構的隱私權政策（ privacy policy）規則：
<user, data=""><funname, constraint=""><createorder, true=""><deleteorder,><vieworders,>< funName, purpose, dataName, authType, constraint >
<user, data=""><funname, constraint=""><createorder, true=""><deleteorder,><vieworders,>其意涵為「系統使用者若要執行某功能（funName）存取客戶資料（dataName），必須通過authType方式認證，滿足constraint的條件；此外，本功能之目的（purpose）必須為資料擁有者所同意的目的之一 。」
<user, data=""><funname, constraint=""><createorder, true=""><deleteorder,><vieworders,> 這樣的政策規則要如何落實到應用系統呢？多數的應用系統都有存取控管模組，以下我們將勾勒一個擴充具有存取控管的模組的系統架構，藉以落實以上的隱私權政策之規則。首先先界定一些背景名詞。對於應用系統既有的存取控管模組，我們採用業界標準XACML的用語區分成兩主要部分：政策落實點 （Policy Enforcement Point, PEP）與政策決策點 （Policy Decision Point, PDP）。我們稱欲存取客戶資料的應用系統使用者為data requester，其操作功能為action，客戶資料擁有者為data subject；客戶對自己的個資可以設定所同意之存取目的，我們稱為其隱私偏好（privacy preferences），每個action也必須要有其執行之目的（intended purpose）。根據這些，我們提出以下（圖一）的架構來落實隱私政策。
<user, data=""><funname, constraint=""><createorder, true=""><deleteorder,><vieworders,>簡要說明此架構之運作流程如下：使用者執行系統功能action來存取客戶資料時，存取控管之PEP 部分要進行權限檢查，這部份由PDP部分就使用者的角色等屬性依規則進行判斷是否放行。若通過，則控制權還要進一步轉移到「目的比對」模組，就此action的意圖目的（intended purpose）與客戶當初所同意的目的（consented purposes）進行比對，如果符合，才能允許使用者執行此一動作。圖中左側有一個Action Purpose Manager，它的目的是要讓系統管理員就系統既有的功能設定（追加）其意圖目的；對應右側的Client Privacy Manager則是要讓我們登錄客戶對其個資授權可使用的目的。
<user, data=""><funname, constraint=""><createorder, true=""><deleteorder,><vieworders,>難處是在於「目的」的制定
<user, data=""><funname, constraint=""><createorder, true=""><deleteorder,><vieworders,> 以上架構的技術面其實問題不大，主要的難處是在於「目的」的制定。有幾個必須考量的面向：理解性、細緻度與標準化。目的的用詞應該要簡單到讓客戶可以簡單理解，並且讓系統能夠容易實作。太粗糙不易確實保護隱私，太細緻則不易理解也不易實現。除了有一般的使用目的外，每個應用領域也會有自己特殊的目的用語，但若用語不標準化，不僅客戶困擾，系統實作也會有很大困難。
<user, data=""><funname, constraint=""><createorder, true=""><deleteorder,><vieworders,>面對這麼多困難，必須逐步去推動，分階段去克服會遇到的困難。過渡期間，或許可以加強記錄與稽核的功能。存取控管是一種事前防範的措施，記錄與稽核則是事後的補救作為。通常是能防範就防範，避免造成傷害，但是，防的太嚴，使用者也會反彈，例如醫療訊系統系統中，若對醫生設限太嚴，可能會影響病人權益。此外，防範的成本太高，若不能貫徹，可能更糟。所以搭配記錄與稽核或許比較可行。而且若記錄做的好，能達到「凡走過必留下痕跡」的程度，就能發揮嚇阻作用，相當程度的保障客戶隱私。