從應用系統的權限控管到隱私保護 防範組織內部合法使用者，不當使用應用系統內的客戶個人資料

撰文 | 政大資科系教授 陳 恭

近來不管是政府機關或是民間機構，都投入

了大量資源來確保組織能夠符合新版「個

人資料保護法（個資法）」的要求，本文將從應

用系統的設計與開發角度，談一談如何落實對個

人資料的隱私加以保護，以符合個資法保護個人

隱私的主要精神。

防範組織內部的合法使用者之不當使用

首先，我們可依組織外部與內部這兩個資料竊取

的管道來探討如何保護個人資料。外部指的是組

織外部的非合法使用者，透過特殊手法入侵組織

的網路，進而竊取組織內系統中的個人資料。

這部份的防範比較屬於防火牆、網管等系統面問

題，不在本文的討論範圍。我們主要是聚焦於如

何防範組織內部的合法使用者，不當使用應用系

統內的客戶個人資料。

談到保護應用系統內的個資，開發人員第一個想

到的可能是權限控管：透過適當的資料存取控管

（Access Control）機制來保護個資。的確如此，

存取控管機制是保護個資的基礎設施，但僅有傳

統的存取控管機制，並不能完全落實個資法對隱

私保護的要求。以下我們將仔細說明其中概念上

的細緻差異，並概略勾勒實作上需要怎樣的機制

來落實。

應用系統安全防護核心 3A：認證、授權、紀錄

話說從頭，應用系統安全防護核心可分為三

個 面 向： 所 謂 3A 或 AAA ( Authentication,

A u t h o r i z a t i o n , A c c o u n t i n g )。 認 證

(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, function, data> 三個層級的架構來

分析應用系統使用者與系統間的互動與存取控管

的需求，這裡要表示的是某 user 提出執行一系

註 1. 但這不代表記錄（log）不重要，文末我們會討論

記錄的重要性。

| 叡揚e論壇 第71期 | APRIL 201344

技術 e 專欄 | Techno logy

統功能（function）的要求，期間可能會存取某

些 data，透過這三個層級可以充份掌握不同細緻

度的存取控管需求。首先，user 層級表示控管

規則只要求確認使用者的身份及可，屬於最粗

的控管層級 (coarse-grained)。其次，function 層

級次之，因為某些 function 的執行需要使用者滿

足進一步的控管限制。最後，data 層級最為細緻

(fine-grained)，使用者跟所欲存取的資料之間必

須符合特定的限制條件。

例如，在 B2C 應用程式中，商品瀏覽與選購是

不需身份認證就可以執行的，但是要結帳下單就

必須先確認其身份，這就是 user 層級的控管；

下單後，訂單的刪除只有系統管理員才能執行，

這屬於 function 層級的管控；訂單的查詢瀏覽則

只能限於屬於自己的訂單，而不能看別人的，這

就是 data 或 instance 層級的控管。尤有甚者，

顯示訂單內容時，應該將如身分證字號或信用卡

號碼等敏感資料欄位隱藏，這是更細緻的欄位

（field）層級的控管。

存取控管規則各有不同

有了以上的分析架構，我們可以用下列的形式化

規則來模型化應用系統的存取控管需求：

Rule : < funName, da taName[ - f i e ldNames] , authType, constraint>

這裡 funName 指的是被限制存取的功能函式名

稱，dataName 則是在函式中被存取的物件型態，

fieldNames 則是指明了哪些物件的屬性 ( 欄位 )

是必須加以限制不讓使用者看到的，這些屬性的

資料在呈現給使用者之前會被遮蔽 (Mask) ; 如果

沒有列出，則表示使用者可存取物件中所有的屬

性。其次，authType 表明執行此功能必須先通過

的認證方式（password 或 digital certificate 等 )。

最後的 constraint 是一個布林運算式，用來決定

是否允許使用者的存取要求。它的內容主要是

引用 User、Data 兩個物件外，以及一些基本的

關聯運算子，像是等於 (equals)、小於 (less)，以

及集合運算等，來表達存取控管規則的需求。其

中 User 物件是包含使用者各項屬性的物件，Data

物件則是規則中系統功能所存取的資料，例如：

Order。我們可以在 constrain 運算式中引用這些

物件的屬性來表達不同層級的存取控管條件。

以下舉三個不同細緻度的範例說明此種規則格

式，其中第二個就是常用的以角色為基礎的存取

控 管（Role-Based Access Control, RBAC）， 第

三個則是最細緻的以資料內容為控管規則。

範 例 一： 使 用 者 必 須 以 密 碼（password, PWD）登入後才能下訂單。

Rule： <createOrder, Order, PWD, True>

範例二：使用者必須登入，且擁有管理員角色

（ ＂admin＂）才能刪除訂單。

Rule： <deleteOrder, Order, PWD, contains(User.getAttr(“roles＂), “admin＂) >

範例三：使用者必須先登入後才能查詢訂單，

而且只能瀏覽自己的訂單，並不得顯示信用卡

號碼。

Rule: <viewOrders, Order[-creditCardNumber], PWD, e q u a l s ( U s e r. g e t A t t r (“N a m e＂ ) , D a t a .getAttr(“Owner＂))>

還有一些更細緻的存取控管需求必須將環境

（context）的限制納入考量，常見的這類需

求是存取的時間與使用者登入系統的機器網址

（IP）。我們可以在 constrain 運算式中，引入一

個 Context 物件與一個系統參數物件（System）

來表達此類的條件。例如：以下運算式限制存取

時間必須是上班時間，而且是從某一部特定 IP 的

機器。

APRIL 2013 | 叡揚e論壇 第71期 | 45

contains(System.getAttr(“WorkingHours＂),

Context.getAttr(“time＂)) and

equals(Context.getAttr(“IP＂), “65.2.5.8＂)

個資的「使用目的」必須納入存取控管的考量

但是即使有了以上如此細緻的存取控管規則，仍

然還不能完全捕捉到個資隱私保護的需求。為什

麼呢？這要從隱私權的基本概念談起。一般都以

學者 Warren 和 Brandeisy 在 1890 年於「哈佛法

學評論」第 4 期所提出的「不受干擾的權利」

（right to be let alone）（亦譯成獨處權）作為隱

私權的理論基礎。 舉個例子，往來的銀行通常擁

有我們的個資，包含電話號碼，因此我們常接到

銀行行銷人員打來的電話，跟我們推銷各類金融

商品。依照目前新版個資法的規定，我們可以明

確告知對方，以後不願意再接到這類電話，這就

是一種「不受干擾的權利」。

不過這樣的概念要如何連結到應用系統的設計與

開發呢？我們可以從以上的例子找出一些端倪。

雖然我們不願意接到商品推銷的電話，但是如果

銀行來電是為了通知一些我們帳戶的權益問題或

是客戶服務事項，我們應該是願意接這通電話

的。這兩種情境，從應用系統的存取控管規則

來看，都是要依使用者權限讀取客戶的電話號

碼，無從分辨其差異性。但從隱私權看，其中細

微差異在於銀行（廠商）取得我們的個資（電話

號碼）後，所要執行的動作（播打電話）的「目

的」（purpose）為何？如果目的是產品行銷，我

們就不接受；但若目的是產品售後服務，我們就

願意接受。也就是說，個資的「使用目的」必須

納入存取控管的考量，這是個資隱私保護比一般

存取控管要來的細膩之主因。

因此，應用系統的功能若是會使用到客戶個資，

除了一般的存取控管規則外，都必須還要有「目

的」這一詮釋屬性（metadata）。相對的，我們

在取得客戶個資時（或是後來因應此項個資法

規），也必須告知客戶我們的系統將會如何使用

這些資料（目的），並取得客戶對那些功能的

「目的」（intended purpose）是否同意（consented

purpose），以作為應用系統執行時的個資存取

控管依據。有了以上說明，我們可以將「目的」

納入存取控管規則，採用下列結構的隱私權政策

（ privacy policy）規則：

< funName, purpose , da taName, au thType,

constraint >

其 意 涵 為「 系 統 使 用 者 若 要 執 行 某 功 能

（funName）存取客戶資料（dataName），必

須通過 authType 方式認證，滿足 constraint 的條

件；此外，本功能之目的（purpose）必須為資

料擁有者所同意的目的之一 。」

這樣的政策規則要如何落實到應用系統呢？多數

的應用系統都有存取控管模組，以下我們將勾勒

一個擴充具有存取控管的模組的系統架構，藉以

落實以上的隱私權政策之規則。首先先界定一些

背景名詞。對於應用系統既有的存取控管模組，

我們採用業界標準 XACML 的用語區分成兩主要

部分：政策落實點 （Policy Enforcement Point,

PEP） 與 政 策 決 策 點 （Policy Decision Point,

PDP）。我們稱欲存取客戶資料的應用系統使用

者為 data requester，其操作功能為 action，客戶

資料擁有者為 data subject；客戶對自己的個資可

以設定所同意之存取目的，我們稱為其隱私偏好

（privacy preferences），每個 action 也必須要有

其執行之目的（intended purpose）。根據這些，

我們提出以下（圖一）的架構來落實隱私政策。

簡要說明此架構之運作流程如下：使用者執行系

統功能 action 來存取客戶資料時，存取控管之

| 叡揚e論壇 第71期 | APRIL 201346

技術 e 專欄 | Techno logy

PEP 部分要進行權限檢查，這部份由 PDP 部

分就使用者的角色等屬性依規則進行判斷是否

放行。若通過，則控制權還要進一步轉移到

「目的比對」模組，就此 action 的意圖目的

（intended purpose）與客戶當初所同意的目

的（consented purposes）進行比對，如果符

合，才能允許使用者執行此一動作。圖中左側

有一個 Action Purpose Manager，它的目的是

要讓系統管理員就系統既有的功能設定（追

加）其意圖目的；對應右側的 Client Privacy

Manager 則是要讓我們登錄客戶對其個資授權

可使用的目的。

難處是在於「目的」的制定

以上架構的技術面其實問題不大，主要的難處

是在於「目的」的制定。有幾個必須考量的面

向：理解性、細緻度與標準化。目的的用詞應

該要簡單到讓客戶可以簡單理解，並且讓系統

能夠容易實作。太粗糙不易確實保護隱私，太

細緻則不易理解也不易實現。除了有一般的使

用目的外，每個應用領域也會有自己特殊的目

的用語，但若用語不標準化，不僅客戶困擾，

系統實作也會有很大困難。

面對這麼多困難，必須逐步去推動，分階段去

克服會遇到的困難。過渡期間，或許可以加強

記錄與稽核的功能。存取控管是一種事前防範

的措施，記錄與稽核則是事後的補救作為。通

常是能防範就防範，避免造成傷害，但是，防

的太嚴，使用者也會反彈，例如醫療訊系統系

統中，若對醫生設限太嚴，可能會影響病人權

益。此外，防範的成本太高，若不能貫徹，可

能更糟。所以搭配記錄與稽核或許比較可行。

而且若記錄做的好，能達到「凡走過必留下痕

跡」的程度，就能發揮嚇阻作用，相當程度的

保障客戶隱私。

圖一：隱私落實架構

PDP

Access ControlDataRequester

Consentedpurposes

Audit Log

Privacy Module

DataSubject

PEPClientDataAct ion

PurposeMatch?

ActionPurposeManager

IntendedPurpose

SystemAdmin

PrivacyPreference

Client Privacy Manager

APRIL 2013 | 叡揚e論壇 第71期 | 47