雜湊函數

識本體需要來自相同的領域。PROMPT 合併本體論方法程序與 FCA-Merge 方法一樣為互動性的、人為介入的方式。

‧ 國

立 政 治 大 學

‧

N a tio na

l C h engchi U ni ve rs it y

19

SHA (Secure Hash Algorithm)、MAC (Message Authentication Code)和 HMAC (Hash-Based Message Authentication Code)，綜合以上，不論是何種 Hash Function，

都具備下列幾點特性：

• 輸入任意長度的訊息，產生固定長度的雜湊值輸出。

• One-Way Hash 之特性。

• 針對相同訊息進行計算，都會產生出相同結果。

• 雜湊訊息是無法還原成原訊息，因此演算法的設計上必須是不可逆。

本研究的資料為醫療資訊，也因為醫療資料屬於個人隱私的一部份，所以不 同資料來源之間可能會有重複性的產生，例如:一個病患去可能到多家醫院就診。

在資料交換的過程中，醫院是有權力不提供完整的個人醫療資訊，防止個人資料 被還原而辨識為唯一人，在無法辨識的狀況下，查詢出來的資訊可能不夠精確，

基於此，本論文將根據雜湊函數的特性，去實現匿名性資料的對齊，將個人資料 經由 Hash Function 計算得到固定長的雜湊值，再依據雜湊值的結果，進行資料 比對、刪除重複性資料，詳見 4.2.3 章節說明。

‧ 國

立 政 治 大 學

‧

N a tio na

l C h engchi U ni ve rs it y

20

第三章

相關研究 3.1 隱私還原保護

在過去的文獻，針對隱私保護提出各種解決方式，其中在[10][16]提出了兩 個情境資料，一個可顯示每位投票者的姓名、地址、郵遞區號、性別、生日，這 些資料可以和醫療資料中的性別、郵遞區號、生日相互做連結，以至於人們可以 利用上述的特性找到特地的個體，基於此，作者提出了資料保護的概念，其主要 做法是將這種連結不明確化，就可以阻撓資料還原。另一方面，。K-Anonymity 意即欲將 Table 中的資料化為多個群組，每個群組在敏感屬性上的值皆相同，例 如 Birthday, Gender, ZIP 為一個群組，而每個群組中有 K 個 Record，K-Anonymity 目的為將資料庫中資料表達到某一種隱私保護狀態，其主要的用意在於將敏感屬 性欄位的 Re-Identification 可能性降到最低，舉例而言，若有使用者惡意的利用 Birthday 和 ZIP 與其他的資料表進行結合比對，進一步地找出某筆紀錄實際上是 屬於哪個人，為防止上述的情形發生，K-Anonymity 主要的目的是要能夠消除這 種可能性，以達到資料隱私保護的狀態

另外，資料的隱私防護在傳統的作法是對資料進行存取控制，意即只要認為 是敏感資訊的欄位便將其值拿掉，這種方式或許是相當直覺且安全，但由於我們 除了進行隱私防護之外，還須具備有後續的關聯能力；而當敏感屬性欄位整個移 除時，敏感屬性欄位往往又是進行關聯時的關鍵欄位，所以這類的方式對隱私防 護是不可行的。

上述方式都是希望能夠將個人隱私資料達到保護的功能，而本研究與之差別 在於本研究利用雜湊函數實現個人資料匿名性的對齊，就算把敏感性欄位的值刪 除，資料依然具有後續的關聯能力；而我們也可以防止惡意使用者在兩個不同資

‧ 國

立 政 治 大 學

‧

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 醫院)整合而成的；DRP_c則是由 DHP_c所啟動的，是由 DRP_a (A 醫院)和 DRPb (B 醫院)整合而成的。

‧

Access Verify Policy

hasCondition 料使用情境，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，並且授權

就可以得知使用者是否有權限可以查詢資料以及使用者可以使用的查詢型 態。當使用者的資料使用情境符合 AccessVerifyPolicy 中所規範，則會將 Request 的 isEmpowered 屬性所關聯到的 Boolean value 設定為 1，並且授權

在文檔中 在語意式雲端環境上資料交換的保護 -以醫療病例為例 - 政大學術集成 (頁 18-0)