114 一般警察特考三等 警察資訊管理人員類別 網路安全與資訊倫理 考古題詳解

核心觀念

本題考查 SSL/TLS 在網路通訊中的定位、提供的安全功能，以及 HTTPS 如何運用 TLS 保護應用層資料。SSL 是早期協定，已遭淘汰；現今網路實務以 TLS 為主。HTTPS 則是將 HTTP 通訊透過 TLS 保護，讓瀏覽器與網站伺服器能在建立安全通道後交換資料。

TLS 位於應用層與傳輸層之間，提供應用程式可使用的安全通道。它不負責判斷網站內容是否正確，也不會自動讓伺服器端的資料庫或應用程式免於遭入侵。

主要功能

1. 機密性：使用對稱式加密保護傳輸中的資料，使未取得金鑰的第三人無法直接讀取內容。
2. 完整性：透過訊息驗證碼或 AEAD 加密機制，偵測資料遭竄改、插入或破壞。
3. 伺服器身分驗證：伺服器出示數位憑證，客戶端驗證憑證鏈、有效期間及連線網域等資訊，確認連線對象符合憑證所載身分。
4. 金鑰協商：客戶端與伺服器協商密碼套件及工作階段金鑰，供後續資料加密與驗證使用。
5. 客戶端身分驗證（選用）：伺服器可要求客戶端出示憑證，常見於需要雙向 TLS 驗證的環境。

解題方法：以 HTTPS 說明 TLS 如何運作

可依「建立連線、驗證身分與協商金鑰、保護資料傳輸」三階段作答。

一、建立連線並進行交握

使用者透過瀏覽器連線至 HTTPS 網站時，瀏覽器與伺服器先進行 TLS 交握。雙方協商 TLS 版本、密碼套件及後續使用的加密參數。實際交握訊息會依 TLS 版本及設定而異。

二、驗證伺服器並建立工作階段金鑰

伺服器傳送數位憑證。瀏覽器會檢查憑證是否由信任的憑證機構簽發、憑證鏈是否有效、是否仍在有效期間，以及憑證上的網域名稱是否符合使用者連線的網站。

核心觀念

OAuth（Open Authorization，開放授權）是一種授權框架，讓使用者授權第三方應用程式存取其在某服務上的特定資源，而不必把該服務的帳號密碼交給第三方。OAuth 本身不負責確認使用者身分；若應用程式還需要登入者身分資訊，常搭配 OpenID Connect（OIDC）。

作答重點有二：先說明授權流程中各角色與權杖如何傳遞，再分析權杖遭竊、授權流程遭竄改、權限過大等風險，並提出相對應的防護措施。

解題方法

以 OAuth 2.0 常見的**授權碼流程（Authorization Code Flow）**說明運作，再依「流程環節 → 安全風險 → 保護措施」逐項分析。主要角色如下：

• 資源擁有者（Resource Owner）：通常是使用者，決定是否授權。
• 用戶端（Client）：第三方應用程式，代表使用者提出存取要求。
• 授權伺服器（Authorization Server）：驗證使用者並核發授權碼或權杖。
• 資源伺服器（Resource Server）：保管受保護資源，依權杖授權內容提供存取。

以授權碼流程為例：

1. 用戶端導向授權伺服器，帶上用戶端識別、要求的權限範圍（scope）、回呼位址（redirect URI）、狀態值（state）及其他流程參數。
2. 使用者在授權伺服器登入並同意或拒絕授權。
3. 同意後，授權伺服器將一次性授權碼導回用戶端指定的回呼位址。
4. 用戶端以授權碼向授權伺服器交換存取權杖（access token）；若使用公開用戶端，應使用 PKCE 的 code_verifier 驗證交換請求。
5. 用戶端以存取權杖向資源伺服器請求資料；資源伺服器驗證權杖及其權限範圍後，才提供相應資源。

授權碼與存取權杖的差異：授權碼是短暫且一次性的交換憑證；存取權杖則用於呼叫資源伺服器，應限制其有效時間與可存取範圍。流程中第三方取得的是授權所需權杖，不是使用者在原服務的密碼。

安全風險與保護措施

核心觀念

本題比較兩套制度的兩個面向：個人資料處理以何種條件取得有效同意，以及資料傳往境外時，是否須符合特別的跨境移轉條件。以命題當年（民國 114 年）法規為準；當年 11 月 11 日公布的個資法修正條文於考試後公布，且施行日期另定，因此以下依考試時適用的修正前條文作答。

我國個人資料保護法（下稱個資法）第 7 條規範「同意」的要件；第 8、9 條規範蒐集時的告知義務；第 15、19 條規範公務機關與非公務機關蒐集、處理個資的合法事由；第 16、20 條則規範目的外利用。跨境傳輸主要看第 21 條。

GDPR 將同意列為個資處理的合法基礎之一。第 4 條第 11 款定義有效同意，第 6 條列出處理合法性依據，第 7 條規範同意條件；跨境移轉則適用第 44 至 49 條。

解題方法

依序比較「同意是否是唯一合法依據、有效同意須具備什麼條件、跨境傳輸的預設規則、同意在跨境制度中的角色」，即可避免把「處理個資的同意」和「允許資料傳到境外」混為一談。

取得使用者同意

**我國個資法：**第 7 條第 1 項規定，依第 15 條第 2 款、第 19 條第 1 項第 5 款以同意作為蒐集、處理依據時，應先告知個資法所定應告知事項，再取得當事人允許的意思表示。同意原則上不以書面為必要；法律另要求「書面同意」時，才須符合書面形式。蒐集時應告知的事項，依第 8 條通常包括蒐集者、蒐集目的、個資類別、利用期間、地區、對象及方式、當事人權利，以及不提供資料對權益的影響。

同意不是個資法規定的唯一合法依據。例如，非公務機關得依第 19 條第 1 項所列其他事由蒐集或處理個資；目的外利用則須符合第 16 條或第 20 條所列例外。不能因為個資法要求告知，就推論每次蒐集都必須取得同意。

**GDPR：**第 4 條第 11 款要求同意必須是自由、特定、知情且明確的意思表示，透過聲明或明確肯定行為表示同意。依第 7 條，控制者須能證明當事人已同意；同意請求若與其他事項一併呈現，須清楚區隔、易於理解，並使用清楚淺白的文字；當事人得隨時撤回，且撤回不影響撤回前依同意所為處理的合法性。若處理涉及敏感個資等情形，GDPR 另有明示同意等特別要求。

**比較：**兩者都重視告知與當事人的有效意思表示；GDPR 對「自由、特定、知情、明確」、控制者舉證、請求方式及撤回權的規範更明文而細緻。兩套制度也都不以同意作為所有個資處理的唯一合法基礎：GDPR 第 6 條另有契約、法律義務、公共任務及合法利益等依據；我國則依個資法第 15 條、第 19 條所列事由判斷。

資料跨境傳輸

核心觀念

本題考查人工智慧（AI）自動化決策的資訊倫理原則，以及決策造成錯誤與損害時的法律責任歸屬。作答時應掌握兩個核心觀念：

1. **AI 是決策工具，不是法律責任主體。**系統不具備法律上的人格，不能單獨承擔賠償、行政或刑事責任；應依各方的實際角色與過失，判斷由開發者、提供者、部署者、使用機關或人員負責。
2. **自動化不代表免除人的審查責任。**越是涉及人民權利、重大利益或高風險的決策，越應確保可理解、可覆核，並讓受影響者有提出異議與尋求救濟的管道。

**法規時點：**以下法律分析以命題當年（民國 114 年）法規為準。題目未指定適用法域，以下以我國法制說明。民國 114 年 12 月 23 日《人工智慧基本法》才經立法院三讀通過，晚於本題命題時點，不宜當作命題當時已施行的直接法源；作答可用來說明我國後續 AI 治理方向。民國 114 年個人資料保護法亦有後續修法，以下仍依命題當年適用規定分析。

解題方法

建議按「倫理原則 → 法律規範 → 責任主體 → 救濟與治理」作答。

先說明自動化決策可能涉及個人資料、平等權、隱私、程序正義及生命財產等權益；接著整理應遵循的原則；再依決策發生於私人部門或政府機關，套用民事、個資及行政法規範，最後說明責任須依因果關係及各方行為判斷，而非一概歸給 AI 或單一角色。

一、資訊倫理應考慮的原則

（一）公平與不歧視

訓練資料若含有歷史偏見，或特徵選取、模型設計造成特定群體受到不利對待，系統可能放大歧視。例如，授信、招募或治安風險評估模型，可能對特定性別、族群、年齡或社經背景產生不公平結果。

因此應檢查資料代表性、錯誤率及不同群體的影響，避免以不適當代理變數間接形成歧視，並設置人工覆核與申訴機制。

（二）透明與可解釋

決策受影響者應能知道是否使用 AI、AI 在決策中扮演的角色，以及影響結果的主要因素。若系統只輸出分數或標籤，卻無法說明結果如何產生，當事人就難以判斷資料錯誤、偏見或模型失準，也難以有效救濟。

透明不必等於公開全部原始碼或揭露商業機密；但至少應提供足以理解及質疑個案決策的理由。

（三）隱私與個人資料保護

使用個人資料進行分析或決策，應遵守個人資料保護法關於蒐集、處理、利用及安全維護的規定，包括確認特定目的及法定依據、採取必要的安全措施，並避免蒐集超出目的所需的資料。敏感資料與大規模資料分析尤其應注意資料外洩、再識別及目的外利用風險。

（四）人類自主與適當的人為監督

AI 可協助整理資訊、預測風險，但不應讓使用者把判斷責任完全交給模型。涉及重大權益或需要專業判斷的決策，應由有權責的人員檢視關鍵資料、理解模型限制，並能在有理由時推翻系統建議。

（五）可靠、安全與比例原則

應依系統用途與風險程度，進行測試、驗證、監控及更新，評估錯誤率、資料漂移、資安漏洞及故障時的影響。系統的精確度、使用範圍與資料量，應與其目的及風險相稱；對於錯誤可能造成重大損害的用途，應採取更嚴格的控管。

（六）問責與可追溯

應明確指定誰負責資料品質、模型驗證、系統部署、人工覆核及事故處理，並保留適當的決策紀錄，使事後能查明資料來源、模型版本、操作人員及決策流程。問責不能只停留在「系統算出來的」這種說法。

二、法律責任分析

（一）私人機構或企業的民事責任