---
GA: G-RE98CFYS1Y
---
# 前言

最近可能因為某群人好不容易找到一個好像可以打的點 - 電信資料的應用，所以就開始朗朗上手個資理解。看了一下大概也沒多少人是真的有面對個資審查，或者從事相關工作。但事實上就算是金控資安長等級的大概理解也不見得都到位(這個我倒是蠻有自信真的不見得)，所以還是來寫個小測驗看看大家知道有多深。

# 個資法

個資詮釋一領域一個調性，所以我們還是用會被金融檢查當作有問題作為標準。至於醫療那裡的，我覺得有些地方還是太==彈性==，就不拿那裡來討論。

## 參考法源 - 第二條

https://law.moj.gov.tw/LawClass/LawAll.aspx?PCode=I0050021

一、個人資料：指自然人之姓名、出生年月日、國民身分證統一編號、護照號碼、特徵、指紋、婚姻、家庭、教育、職業、病歷、醫療、基因、性生活、健康檢查、犯罪前科、聯絡方式、財務情況、社會活動==及其他得以直接或間接方式識別該個人之資料==。
二、個人資料檔案：指依系統建立而得以自動化機器或其他非自動化方式檢索、整理之個人資料之集合。
三、蒐集：指以任何方式取得個人資料。
四、處理：指為建立或利用個人資料檔案所為資料之記錄、輸入、儲存、編輯、更正、複製、檢索、刪除、輸出、連結或內部傳送。
五、利用：指將蒐集之個人資料為處理以外之使用。
六、國際傳輸：指將個人資料作跨國（境）之處理或利用。
七、公務機關：指依法行使公權力之中央或地方機關或行政法人。
八、非公務機關：指前款以外之自然人、法人或其他團體。
九、當事人：指個人資料之本人。

## 實務狀況

以下是你拿到的原始資料與加工作業，請依序評估哪些是在金融領域是個資

### Case A

| 身分證字號 | 姓名 | 性別 | 特殊疾病 | 學歷 | 住址 | 職業 | 總資產 | email | cookie UID | device ID |
|-|-|-|-|-|-|-|-|-|-|-|
| A123456789 | 王大明 | 男 | 罕病A | 博士 | 新北市OO區XX路５樓 | 董事長 | 3兆 | [e-mail] | C12 | aaaa-bbbb-cccc|
:::danger
是，個資。 這個資料知道是誰(還有明確地址)
:::

### Case B

| 身分證字號 | 姓名 | 性別 | 特殊疾病 | 學歷 | 住址 | 職業 | 總資產 | email | cookie UID | device ID |
|-|-|-|-|-|-|-|-|-|-|-|
| A123456789 | 王O明 | 男 | 罕病A | 博士 | CCC | 董事長 | 3兆 | [e-mail] |C12 | aaaa-bbbb-cccc|
:::danger
是，個資。 因為身分證字號可以鎖定是誰
:::

### Case C

| 身分證字號 | 姓名 | 性別 | 特殊疾病 | 學歷 | 住址 | 職業 | 總資產 | email | cookie UID | device ID |
|-|-|-|-|-|-|-|-|-|-|-|
| one-way hash | 王O明 | 男 | 罕病A | 博士 | CCC | 董事長 | 3兆 | [e-mail] |C12 | aaaa-bbbb-cccc|
:::danger
是，個資。 因為有 Deivce ID 可以鎖定個體
:::

### Case D

| 身分證字號 | 姓名 | 性別 | 特殊疾病 | 學歷 | 住址 | 職業 | 總資產 | email | cookie UID | device ID |
|-|-|-|-|-|-|-|-|-|-|-|
| one-way hash | 王O明 | 男 | 罕病A | 博士 | CCC | 董事長 | 3兆 | [e-mail] |C12 | one-way hash|
:::danger
是，個資。 因為有 Cookie ID 可以鎖定個體
:::

### Case E

| 身分證字號 | 姓名 | 性別 | 特殊疾病 | 學歷 | 住址 | 職業 | 總資產 | email | cookie UID | device ID |
|-|-|-|-|-|-|-|-|-|-|-|
| one-way hash | 王O明 | 男 | 罕病A | 博士 | CCC | 董事長 | 3兆 | [e-mail] |one-way hash | one-way hash|
:::danger
是，個資。 因為特殊疾病 是特種個資，不管如何沒有特殊理由都不能出現
:::

### Case F

| 身分證字號 | 姓名 | 性別 | 學歷 | 住址 | 職業 | 總資產 | email | cookie UID | device ID |
|-|-|-|-|-|-|-|-|-|-|
| one-way hash | 王O明 | 男 | 博士 | CCC | 董事長 | 3兆 | [e-mail] |one-way hash | one-way hash|
:::danger
是，個資。 這個名字+性別＋學歷＋職業與總資產 全台灣可能只有一個。
:::

### Case F

| 身分證字號 | 性別 | 學歷 | 住址 | 職業 | 總資產 | email | cookie UID | device ID |
|-|-|-|-|-|-|-|-|-|
| one-way hash | 男 | D | CCC | E | 3兆 | [e-mail] |one-way hash | one-way hash|
:::danger
是，個資。 這個名字+性別＋學歷＋職業與總資產 全台灣可能只有一個。
:::

### Case G

| 身分證字號 | 性別 | 學歷 | 住址 | 職業 | 總資產 | email | cookie UID | device ID |
|-|-|-|-|-|-|-|-|-|
| one-way hash | 男 | D | CCC | E | 3兆 | [e-mail] |one-way hash | one-way hash|
:::danger
是，個資。 因為 email
:::

### Case H

| 身分證字號 | 性別 | 學歷 | 住址 | 職業 | 總資產 | email | cookie UID | device ID |
|-|-|-|-|-|-|-|-|-|
| one-way hash | 男 | D | CCC | E | 3兆 | one-way hash |one-way hash | one-way hash|
:::danger
是，個資。 因為 全台灣的 3兆男應該只有一個
:::

### Case I

| 身分證字號 | 性別 | 學歷 | 住址 | 職業 | 總資產 | email | cookie UID | device ID |
|-|-|-|-|-|-|-|-|-|
| one-way hash | 男 | D | CCC | E | 有序的編碼 | one-way hash |one-way hash | one-way hash|
:::danger
是，個資。 這些 one-way hash 如果有保留 mapping table 可以還原就是個資，但這是常見非金融業界會用的去識別化資料。
:::

### Case J

| 性別 | 學歷 | 住址 | 職業 | 總資產 |
|-|-|-|-|-|
| 男 | D | CCC | E | 有序的編碼 |

:::success
有限度過關，因為如果你的有序編碼只針對某一個人給了特殊編碼，就回到類似 I 的問題。
:::

## 總結

基本上，在金融定義的個資是跨到海邊，他的定義就是，==只要能夠鎖定不特定個體，即使現在你不知道他是誰，但這個資料可以鎖定一個人==，那麼就是個資。

至於被管到這樣還可不可以用，我想已經不是這些金融檢查人員想要管理的議題，反正他們對於產業發展也不是他們的最重要的任務。

如果有任何大大可以幫忙突破，都是拯救產業發展的貴人。

## 回到中華電信的人流比對問題

目前非金融業界常態都會使用到 case I 左右的做法，其實要能夠用 case I 就能夠辨識該筆資料或者紀錄是否為相同的人員擁有。

# 延伸考題

請問除了資料之外，還有什麼不是資料卻會碰到個資問題？
(這題是有明確實例，不會沒有，想想 AI)