• 沒有找到結果。

4.3 規範的設計和資料查詢處理

4.3.2 Access Control Policy

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

32

4.3.1 研究情境說明

本研究假設使用者的使用情境的各項元素會自動對應到 ACP 和 DHP 中,下 面將以 a 醫院病患資料庫的一般使用者和統計分析使用者,也就是 SBQ 和 PBQ 分開說明。

假如有一名醫生在診斷目的下,想要查詢 ID 為 A239726214 的資料擁有者 膽固醇指數,經過醫院的 ACP 驗證後會授權 SBQ 給該醫生。接著將 DHP 裡的 使用情境與醫生的使用情境做比對,整合相同使用情境的委外資料。整合出完整 資料庫後,系統會將醫生的查詢條件,經由查詢改寫後下到整合出的完整資料庫 中挑選 ID 為 A239726214 的資料擁有者膽固醇指數。由於該醫生可使用 SBQ,

因此 DRP 會將該筆資料直接揭露給醫生。

假如有一名醫療研究人員,想要研究在地區、性別、年紀和膽固醇指數與疾 病的關聯性。經過醫院的 ACP 驗證後會授權 PBQ 給該醫療研究人員,接著系統 讓醫療研究人員勾選所需的欄位 ZIP、Gender、DoB、Cholesterol 和 Disease。SBQ 和 PBQ 的 DHP 處理步驟相同,會整合相同使用情境的委外資料並且藉由查詢改 寫將使用者所需的欄位挑選出來。由於該醫療研究人員是使用 PBQ,因此 DRP 必須會先判斷該使用者所使用的資料中是否會侵害隱私,而在本研究中 ZIP、

Gender 和 DoB 會構成 Quasi-identifiers 以及使用者查詢敏感性欄位 Disease,因 此必須要求該醫療研究人員從 ZIP、Gender 和 DoB 中挑選一欄位以 SDC 處理,

醫療研究人員可根據自身的需求來取捨哪個欄位以 SDC 處理,而醫療研究人員 挑選完欄位與 SDC 後,系統呼叫 SDC 處理結束才會揭露資料。

4.3.2 Access Control Policy

ACP 負責的是驗證使用者是否可以進入資料使用介面以及授權使用者能夠使

DataUser、Action 和 Purpose 等,每一種使用情境都有各自的使用情境構成要素 以及授權的查詢模式如 SBQ 或 PBQ,而本研究參考 P3P 和 APPEL 中的要素以

Action Purpose Location Time QueryType

Doctor Read Diagonosis Hospital Work SBQ Researcher Read Analysis Research

Center

Work PBQ

Researcher Read Analysis Research Center

(Instance)則代表一種使用情境或是一個使用情境要素,像是 Researcher 和 Doctor 為 DataUser 的實體而 Diagonosis 和 Statistics 為 Purpose 的實體。在上圖中,類別 跟類別之間的箭頭實線代表類別之間的關係,如使用情境和各個使用情境要素之 間有 hasPartOf 代表使用情境中包含各個使用情境要素的關係或者是

AcceessVerifyPolicy 或 Request 和 Condition 之間有 hasCondition 關係,代表使用 者和 ACP 都有各自的使用情境。在此本研究運用 hasPartOf 來代表使用情境包含 的各個資料使用情境要素,是一種結構的概念。而在語意網技術中除了以 hasPartOf 描述結構外,還有一種稱為 Functional Symbol 也能用來描述結構[24]。

但不同的是,Functional Symbol 代表的是一個函數的概念,而 hasPartOf 代表類 別的概念。

而箭頭實線如果不是位於類別之間則是代表類別對應到一種資料型態,像是 isEmpowered 將 Request 關連到 BooleanValue,BooleanValue 為 1 代表 Request 被驗證通過而 0 反之。Request 和 AccessVerifyPolicy 都有各自的 Condition,前者

‧ 國

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

35

為使用者在送出 Request 時的資料使用情境,而後者為資料控制者設定 ACP 的 各種資料使用情境。

本研究假設當使用者進入資料查詢系統時,系統會以各種方式蒐集使用者的 各種使用情境要素,像是 DataUser 使用帳號密碼驗證身分以及 Location 使用 IP 驗證,並自動對應到 ACP 中各種使用情境要素。當使用者和使用情境、使用情 境要素之間的對應皆完成後才會開始 ACP 的驗證和授權 SBQ 和 PBQ 的動作。

本研究運用 SWRL 規則來比對使用者和 ACP 的資料使用情境是否相同,假 如

相同則授權該使用情境能使用的查詢模式給使用者,SWRL 規則如下所示:

Request(?r) ∧hasCondition(?r, ?c) ∧Condition(?c) ∧Condition(?ac) ∧ hasCondition(?avp, ?ac) ∧AccessVerifyPolicy(?avp) ∧sameAs(?ac, ?c) ∧ empower(?avp,?qt) ∧QueryType(?qt) →

isEmpowered(?r, 1) ∧hasQueryType(?r,?qt)

在 SWRL 的規則中提供 sameAs 的 Atom 來進行限制 Instance 的相同。舉例來說,

假如有 Fred 和 Freddy 這兩個不同的實體,則 sameAs(Fred, Freddy)這個 Atom 便會不會成立。假如使用者的資料使用情境符合 ACP 中所規範的使用情境,則 Request 和 AccessVerifyPolicy 其中之一藉由 hasCondition 關係對應到的 Condition 的實體必會相同,因此運用 sameAs 的 Atom 來表達實體相同的限制,其概念如 下圖所示:

‧ 國

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

36

Condition Request

AccessVerify Policy

圖 六、透過 sameAs 限制實體相同的概念

在上述的 SWRL 規則中,假如使用者的資料使用情境符合 ACP 中所規範的 使用情境,則會將 Request 的 isEmpowered 關係所對應到的 BooleanValue 設定為 1,並授權可以使用的查詢模式?qt,最後啟動 DHP 去整合委外資料。而如果 BooleanValue 設定為 0,代表使用者不能使用資料,則會拒絕使用者查詢。

相關文件