第三章、 相關研究
3.3 隱私資料的存取控管機制
國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
21
料來源分別查詢後，再將資料進行比對，因本研究採用資料交換的特色是一次的 查詢可以查詢兩邊來源的資料，當兩邊資料來源可能造成 Re-Identification 的時 候，我們會進行資料保護的動作。避免敏感屬性欄位被 Re-Identification。
3.2 雲端委外語意式資料保護
雲端委外語意式資料保護[17]此論文在研究架構上，也是利用存取控管規範、
資料處理規範和資料釋放規範這三種規範的合作、分工，將法律上資料隱私的保 護與 Data Owner 的隱私偏好做一個結合，最後應用 Microdata 保護技術與 User 的 使用情境做比對，實際落實適當的 Microdata 保護技術去保護隱私和滿足 User 查詢資料的目的。
在此篇論文中只針對單一資料源的 Microdata 進行揭露保護的分析，並沒有 考量到在多資料源的環境下，Microdata 該如何保護、如何揭露才不會造成個人 資料因資料來源的不同，而導致個人資料被揭露的可能性，像是透過多資料源的 不同欄位資料查詢，可以辨別特定個人的身分。
本研究提出開放式的環境，在多個資料來源的情況下，要避免資料因外來資 料的加入而違反了隱私，例如:在原本的資料上查詢 Gender、ZIP 和 Birthday 的 釋放是不會違反隱私，但是若是再經由外來資料的加入，可能導致
Quasi-Identifiers 和 Confidential Attributes 的產生 (2.3 章節)，而造成資料被 Re-Identification。本研究資料的對應與流通是不會產生個人資料被揭露的狀況發 生。
3.3 隱私資料的存取控管機制
隨著雲端運算的發展，個人資料被收集到一個集中的企業或者組織手中是不 可避免的趨勢，因此資料隱私保護的需求變得相當重要。企業或組織必須擁有彈 性且強大的隱私資料保護方式才能讓資料擁有者信賴並且託付資料。文獻[18][19]
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
22
中提出三種本體論的規範去落實隱私保護。
• Access Control Policy:負責管理資料或服務的存取或釋放。
• Data Handling Policy:讓資料擁有者設定自己的隱私偏好並且在資料流向合 作企業時也一併流至合作企業，讓資料的使用滿足資料擁有者的預想。
• Data Releasing Policy:負責管理個人足以辨識身分的資料的揭露時機。
這三種規範的運用，使得企業的存取控管規範和資料擁有者設定的隱私規範 都能一起被落實。但是文獻中的 Access Control Policy 並沒有加入隱私保護相關 法律的概念，像是查詢的型態 Subject-based Query 和 Pattern-based Query；並在 資料揭露的時候也沒有適當資料保護方式可以落實。而本研究在設計三種規範時，
除了原先存取控管和隱私規範的概念外，加入了隱私保護相關的概念，並利用資 料交換的概念，落實不同資料來源時的保護，避免 Re-Identification 的發生。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
23
第四章
研究方法與架構 4.1 研究情境與架構
本研究以假設情境的方式，來實現不同來源的資料交換與匿名的個人資料 保護。以 A 醫院和 B 醫院的醫療資料為例，兩者資料皆受到個人資料保護法所 保護且存放在雲端環境資料庫中，研究中所提供 ACP、DHP、DRP 的流程如下:
首先使用者欲查詢兩間醫院來源的醫療病歷資料，會分為兩種查詢情境，第 一種為醫生為了診治病患所下的查詢指令，此類的查詢為 SBQ；第二種為研究 人員為了統計分析目的所下的查詢指令，此類的查詢為 PBQ。因為本研究是以 查詢兩間醫院為主要情境，所以將第一種的查訊型態標記為 SBQa∧ SBQb，主要 可以運用在病患轉院的時候，讓接任的醫生更加了解病患在之前的醫院的情形，
這樣不僅對醫生有好處，對病患而言也是一大福音；第二種的查訊型態標記為 PBQa∧ PBQb，主要的目的是可以得到更多的醫療資料來做分析，讓研究人員可 以得到更多的樣本數，增加統計結果的準確性。綜合兩種查詢型態，兩間醫院資 料的取的都是透過資料交換的技術去執行。
本研究中 ACP 控管使用者的權限並一併判斷使用者的查詢型態，查詢型態 是經由 ACP 的 MoreInfo 欄位判斷，MoreInfo 欄位表示使用者是否需要更多的資 訊，若 MoreInfo 欄位若為 1 表示需要多的資訊，此時才可以使用 A 醫院與 B 醫 院整合的 DHP 和 DRP；相反的，MoreInfo 欄位若為 0 則直接使用 A 醫院的 DHP 即可。在 DHP 中進行受到統計保護的資料比對與資料交換，利用雜湊函數 (MD5) 計算出個人資料的雜湊值，將兩間醫院分別計算出來的雜湊值做比對和刪除重複 性。最後，傳送符合條件的使用情境與符合條件的資料給 DRP，根據文獻[9]中，
說明各種情況的統計保護方式，釋放給使用者進行分析作業，整體架構如圖 4。
‧
Data Request /DHP
Data Response Sources 各自丟出資料來交換但是不能讓另外一方能夠還原 PII，但是 又可以讓他進行資料的對齊與整理，例如整合同一個人的資料，來確 保隱私保護的目的，但是卻可以完成有意義的統計分析目的。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
25
本研究可以在不違反個人資料保護法的情況下進行資料交換與流通。使用相 同雲端環境上，兩個不同來源的本體論來進行，本體論的建構對象為 A 醫院與 B 醫院資料庫，另外使用 Semantic Web Rule Language (SWRL) [20]作為規則語言，
運用本體論加規則語言實現雲端環境上不同資料來源的資料分享和資料保護。
4.2 本體論建構
4.2.1 ACP、DHP 和 DRP 設計
根據 4.1 章節所述，本研究會有 3 種 Policy 來進行資料的存取控管與隱私條 件的問題，每間醫院資料都會有內部設定的 ACP、DHP 和 DRP 存在，如圖 4 所 示，三者功能如下:
• Access Control Policy (ACP):主要判斷使用者是否有權限能查詢資料並且授 權其適當的查詢型態，包含可否去另一間醫院取得更多資訊的條件。假如 Access Control Policy 驗證使用者有權限使用查詢服務，則完成查詢模式的 授權後便會啟動 Data Handling Policy。
• Data Handling Policy (DHP):主要落實不同資料來源資料交換的技術，作為資 料交換後存放資料的中繼點，利用 Hash Function 來做隱私資料的對齊。
• Data Releasing Policy (DRP):根據查詢結果和授權的查詢方式釋放資料，並且 判斷那些資料同時給予會違反了個人的隱私條件。
本研究中 ACPa是單一入口處的存取控管，而 ACPa不僅僅只判斷是否可以 查詢 A 醫院的資料，還可以判斷是否可以一併查詢 B 醫院的資料，若許可將會 傳送資料到 DHPc，DHPc則是由 ACPa所啟動的，是由 DHPa (A 醫院)和 DHPb (B 醫院)整合而成的；DRPc則是由 DHPc所啟動的，是由 DRPa (A 醫院)和 DRPb (B 醫院)整合而成的。
‧
Access Verify PolicyhasCondition 料使用情境，Request 和 AccessVerifyPolicy 都有各自的 Condition，SWRL 規則 如下:
Request(?r) ∧ hasCondition(?r, ?c) ∧ Condition(?c) ∧ AccessVerifyPolicy(?avp)
∧ hasCondition(?avp, ?ac) ∧ Condition(?ac) ∧ sameAs(?ac, ?c)
∧ empower(?avp,?qt)∧QueryType(?qt)→ isEmpowered(?r, 1)∧ hasQueryType(?r,?qt) ---Rule 1
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
27
Rule 1 規則中，主要目的是用來判斷使用者的查詢需求是否與
AccessVerifyPolicy 相同，根據 Request 和 AccessVerifyPolicy 的 Condition，
就可以得知使用者是否有權限可以查詢資料以及使用者可以使用的查詢型 態。當使用者的資料使用情境符合 AccessVerifyPolicy 中所規範，則會將 Request 的 isEmpowered 屬性所關聯到的 Boolean value 設定為 1，並且授權 可以使用的查詢模式?qt。根據 isEmpowered 屬性所關聯到的 Boolean value 的值決定是否進入整合的 Data Handling Policy。如果 isEmpowered 屬性所關 聯到的 Boolean value 的值為 0，則會不會進入整合的 DHP。
查詢型態的可能狀況如表格一所示，確認查詢型態後將進入到 DHP。本研 究會有 4 種查詢型態的產生，當使用者為醫生在上班期間，想要進行讀取資料的 動作，主要目的是為了診病患，地點在醫院裡，就可以讓醫生去選擇是否想要更 多醫療資料，如果 MoreInfo 欄位為 Yes，則會給予 SBQa∧ SBQb的查詢型態；若 MoreInfo 欄位為 No，則會給予 SBQ 的查詢型態。當使用者為研究人員為了研究 統計分析想要進行讀取資料的動作，在適當的時間與適當的地點的情況下，一樣 可以讓研究人員去選擇是否想要更多醫療資料來增加資料準確性，如果 MoreInfo 欄位為 Yes，則會給予 PBQa∧ PBQb的查詢型態；若 MoreInfo 欄位為 No，則會 給予 PBQ 的查詢型態。
一、查詢型態
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
28
4.2.3 DHP 設計
為了使資料交換後，A 醫院能夠得到 B 醫院的資料，包含 A 醫院本身沒有 收集的資料，我們必須將兩邊的 DHP 整合，以利資料的存放。本研究使用 PROMPT[14]作為 DHP 的本體論整合方式，PROMPT 在本體論綱要(Schema)的 細部整合方法主要是採用字串比對與圖狀架構(Graph)對照的方式將兩者本體論 合併，而合併就是將兩個本體論合併成一個大型的本體論，而先前的兩個則不再 使用。在比較兩個本體論時，PROMPT 會依照字串比對所設定的參數以及類別 在整個本體論中的圖形架構位置來給與使用者合併的建議。
DHPc是由 DHPa (A 醫院)和 DHPb (B 醫院)整合而成，如圖 6、圖 7、圖 8，
分別表示 A 醫院、B 醫院和兩間醫院整合後的圖示，DHPa (A 醫院)和 DHPb (B 醫院)主要差別在於 Data 收集不同的欄位的不同。經由 Access Control Policy 驗 證授權完後，假如 Request 的 isEmpower 屬性值為 1 代表成立，則啟動 Data Handling Policy，反之則不進行。
‧
Cholesterol DH Birthday
B 醫院 DHP
‧
B MedicalInfo
Name ZIP
DH Chol Birthday Cost
QueryType
‧
等之欄位，差別於 B 醫院有 DH (Day in Hospital)、Blood Pressure…等欄位，而 A 醫院則無；A 醫院有 Cost 和 Doctor 欄位，而 B 醫院則無，B 醫院與 A 醫院收集
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
32
詢指令，執行 Mapping Rule (∑𝑠𝑡)的對應，找到 Source Schema 中與查詢條件相 符的資料欄位，進行資料回傳到 Target Schema 的動作；再根據回傳的資料向 Target Schema 做第二次對應，而 Target Schema 內部可能被分割成許多不同使用 者可以使用的資料庫，此時將利用 Mapping Rule (∑𝑡)去連接不同類別間相互的 對應關係及限制，以確認是否會產生 Weakly Acyclic [3]。
本研究將資料欄位分成三類，如表格三欄位類別分類表，第一類為 Source Schema 和 Target Schema 內皆有的可相互對應之欄位，本研究有 Name、Gender、
Birthday…等；第二類為 Target Schema A 醫院內部進行角色分類後研究人員可顯 示的欄位，本研究有 Disease、Cost、Gender 和 Medicine 四種欄位；剩下來的欄 位本研究將之統一歸納為第三類，本研究有 DH(Day in Hospital)、Blood Pressure、
Cost…等欄位，第三類欄位的產生主要是因為資料來源的不同，使得各自的資料 庫收集的資料不同。
三、欄位類別分類表
類別 欄位名稱
類別 欄位名稱