• 沒有找到結果。

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

26

本研究的研究情境是以 a 醫院的病患資料庫委外和使用為例。a 醫院會蒐集 大量的病患資料並建成病患資料庫但並沒有足夠的成本購買伺服器硬體、聘請資 訊人員,因此向雲端資料庫服務提供者承租雲端資料庫服務。在委外儲存病患資 料庫前,先以加密結合分割的方法處理資料,達成資料委外的隱私保護。接著利 用雲端資料庫服務提供者提供的資料存取介面建立資料查詢介面讓使用者查詢 資料。a 醫院同時也設計自己的 ACP、DHP 和 DRP,確保委外資料使用上的隱 私保護。

本研究採用 OWL DL 和 SWRL 以及 SQWRL 來描述跟落實 ACP、DHP 和 DRP。

在下面的 4.2 節會介紹企業在進行資料委外前如何運用加密結合分割的方式處理 資料;4.3 節分別描述 ACP、DHP 和 DRP 這三種規範設計的細節。

4.2 資料委外

4.2.1 委外資料的保護方式

委外資料的隱私保護的概念有分成兩個面向:保護資料本身和保護資料的關 聯性。保護資料本身是指讓資料本身處於不可識別的情況下而保護資料的關聯性 是指讓單一資料本身處於可識別但資料跟資料之間的關聯性處於不可識別的情 況。依據這兩種面向,資料委外保護的方式可分為加密、分割、自行保管資料與 加密結合分割這四種[4][21][22][23]。

 加密:運用加密函式將資料加密後變成密文再委外到外部資料庫。由於服務 提供者缺乏加密函式和加密、解密金鑰,因此能保護資料的隱私。但是資料 處於加密的情況下,資料的使用還必須經過資料解密的流程。為了正確查詢 資料,通常會將查詢條件轉換為密文或者是增加額外的欄位代表密文的特徵 值,否則便須將整個密文資料庫傳給服務租用者後才行解密,但這相當沒有

本研究假設 a 醫院的病患資料庫具有 ID、Name、Gender、DOB、ZIP、Disease、

Doctor 和 Cholesterol 等 8 個欄位,資料內容如下表所示:

表 2、a 醫院病患資料庫欄位與資料內容

ID Name Gender DOB ZIP Disease Doctor Cholesterol

A139181122 Tsai Ya Ting Male 790109 112 CAHD Huang Fu Yuan 203 A239726212 Yang Jing Yi Female 781222 105 CAHD Ma Huei Ming 231 A163190073 Tsai Ya Ping Male 790110 111 Allergy Wang Ho 148 A118814368 Chang Yu Yun Male 780422 111 CAHD Ma Huei Ming 210 A239726214 Li Guo Yuan Female 750422 103 Allergy Wang Ho 180 A118814369 Tsai Jian Hung Male 770102 111 CAHD Huang Fu Yuan 231 A239726213 Pai Yu Yun Female 780423 110 CAHD Huang Fu Yuan 199 A118814370 Yang Yu Yun Male 770712 110 CAHD Ma Huei Ming 232 A298663018 Yang Jian Hung Female 781022 106 Allergy Wang Ho 178

A192142787 Yang Guo Yuan Male 801012 100 Allergy Wang Ho 236 為了以加密、分割或結合加密和分割的方式處理資料,企業必須先行判斷欄位是 屬於單一欄位違反隱私、多個欄位違反隱私或不屬於上述兩類的欄位。判斷的依 據必須參考現實生活中可能發生的情況或者既有研究的內容。本研究參考文獻 [10]中分類方式,在 a 醫院的病患資料庫中,ID 屬於單一欄位違反隱私、Gender、

ZIP 和 DoB 為多個欄位違反隱私,而 Name、Disease、Doctor 和 Cholesterol 並不 屬於上述兩類。本研究採用以結合加密和分割的方式處理委外資料,原因在於如 重複出現。最後,額外在各個子資料庫增加欄位 IndexKey 以及 IndexKeyTable,

利用 IndexKeyTable 紀錄 IndexKey 值之間的關係代表

兩個子資料庫的資料之間的關聯性以便日後使用資料時可以還原資料。

委外資料處理的步驟流程和 IndexKeyTable 如下所示:

Encryption

表 3、IndexKeyTable 內容,代表不同子資料表之間 IndexKey 的對應關係

table1 table2

1. NON-COMMUNICATING SERVERS:企業將子資料庫分別委外儲存到不同 的雲端資料庫服務提供者所提供的雲端資料庫服務並且雲端資料庫服務提 供者之間並不互相知道該企業有將資料委外儲存到對方的雲端資料庫服務 中。

2. COMMUNICATING SERVERS:企業將子資料庫委外到同一個雲端資料庫 服務提供者所提供的雲端資料庫服務或者是不同雲端資料庫服務提供者所 提供的雲端資料庫服務並且雲端資料庫服務提供者彼此互相知道該企業將

‧ 國

立 政 治 大 學

N a tio na

l C h engchi U ni ve rs it y

31

資料委外儲存到對方的雲端資料庫服務中。

對於以加密處理資料而言,因為資料是以密文的形式儲存在雲端資料庫,並且加 密演算法和金鑰都是握在資料控制者手中,因此不同的資料委外模式並不會有 影響。而以分割處理資料而言,處理的細節就必須有所不同。這是因為資料被分 割成數個子資料庫,因此需要增加額外的欄位 IndexKey 來描述子資料庫資料之 間的關聯性。如果在 NON-COMMUNICATING SERVERS 下,IndexKey 欄位值 可以簡單的方式設定,像是 IndexKey 值相同,即代表同一筆資料。而在

COMMUNICATING SERVERS,由於雲端資料庫服務提供者彼此互相知道,所 以不能排除雲端資料庫服務提供者們可能會藉由交換資料庫的方式來得到完整 的資料庫,因此不能僅僅以 IndexKey 值相同就代表同一筆資料,而是以亂數的 方式設定 IndexKey 值並且再額外以 IndexKeyTable 紀錄 IndexKey值之間的關係,

以便整合出同一筆資料。

本研究是假設 a 醫院的病患資料庫委外到同一個雲端資料庫服務提供者所 提供的雲端資料庫服務,屬於 COMMUNICATING SERVERS,因此以 IndexKey 的方式記錄各個子資料庫資料之間的關聯性,以便整合出同一筆資料。不同的 是,

本研究並沒有實際使用 IndexKeyTable,而是將 IndexKeyTable 的關聯性紀錄和資 料擁有者的隱私偏好結合紀錄於規範中,以便達成只整合符合隱私偏好的委外資 料的目標。

相關文件