內容已複查
約 25 分鐘 · 6 張概念卡 · 13 題對應考古題

從 CIA 到 Zero Trust：把資安目標、身分與治理串起來

本頁為依教材與考古題整理的原創摘要；考古題答案經技術覆核，但不是官方答案。

第一次接觸也沒關係

這堂先懂這些詞

先記住白話意思，不必急著背英文。看到正文時，再把正式名稱接回來。

CIA 與零信任

也會看到：CIA triad、confidentiality、integrity、availability、Zero Trust、零信任

CIA 是機密性、完整性、可用性三個資安目標；零信任要求每次存取都持續驗證。

生活例子：
進辦公室不只看一次大門證件，進機房還要再驗身分與權限。
別搞混：
Zero Trust 不是完全不信任任何人，也不是買一套產品就完成。

身分驗證與權限管理

也會看到：identification、authentication、authorization、accountability、RBAC、SSO

先表明是誰、證明身分、判斷能做什麼，並留下可追查紀錄；RBAC 依角色授權，SSO 減少重複登入。

生活例子：
員工報名字、刷識別證、依職務開門，門禁再記錄誰何時進入。
別搞混：
Authentication 證明身分，不代表已獲得所有操作權限。

ISMS、隱私與稽核

也會看到：ISMS、ISO 27001、privacy、audit

ISMS 用持續管理流程控制資安風險；ISO 27001 提供要求，privacy 關注個人資料，audit 檢查制度與證據。

生活例子：
像餐廳不只貼衛生規則，還要定期執行、留紀錄並接受檢查。
別搞混：
通過稽核不是永久安全保證，也不代表所有個資使用都自然合法。

威脅、弱點與風險

也會看到：threat、vulnerability、risk

Threat 是可能造成傷害的來源，vulnerability 是可被利用的弱點，risk 則綜合發生可能與影響。

生活例子：
小偷是威脅，沒鎖的窗是弱點，被偷造成的機率與損失構成風險。
別搞混：
三者不是同義詞；沒有可利用弱點或影響時，風險判斷也會不同。

先用 CIA 與 risk 語言定義要保護什麼，再分辨 identification、authentication、authorization、accountability，最後以 RBAC、SSO、Zero Trust、ISMS、ISO 27001 與 privacy 建立持續治理。

先抓住這幾件事

  • 正確展開 CIA 並連結控制措施
  • 區分 threat、vulnerability 與 risk
  • 區分 IAAA、RBAC、SSO 與 Zero Trust
  • 說明 ISMS、ISO 27001、privacy 與 audit 的角色

先想像這個場景

新進員工取得研究資料權限

研究中心讓新進員工使用資料平台：櫃台先確認他是誰，系統驗證憑證，再依角色開放資料；所有操作都留下紀錄，管理者定期檢查風險與法規。

先別急著往下看，花十秒想一想：

員工已成功登入，是否就代表他可以下載所有研究資料？

把故事換成電腦語言

生活中的角色對應到技術概念
報上姓名或帳號Identification
出示可驗證的卡片、密碼或第二因素Authentication
依研究角色決定可看的資料與可做的操作Authorization／RBAC
操作有日誌，之後能追查責任Accountability／audit
即使人在內網也逐次評估身分、裝置與情境Zero Trust：never trust, always verify

題目出現這些字，先想到

  • CIA 的 A 是 Availability，不是 Accessibility。
  • 問可做哪些操作：authorization；問能否追責：accountability。
  • Ticket-based mutual authentication：Kerberos；一次登入多服務：SSO。
  • 看到政策、程序、風險管理框架：ISMS／ISO 27001；看到 EU 個資規則：GDPR。

1.CIA 是安全目標，不是產品清單

Confidentiality 限制未授權揭露，Integrity 防止未授權修改，Availability 確保授權者需要時可使用。控制措施通常同時影響多個目標，應依 threat、vulnerability、likelihood 與 impact 評估 risk。

  • Encryption 常支援 confidentiality
  • Hash/signature 可支援 integrity
  • Redundancy 與 recovery 支援 availability
  • Defense in depth 用多層控制降低單點失敗

2.IAAA 依序回答四個問題

Identification 宣稱身分，authentication 驗證宣稱，authorization 決定權限，accountability 透過 logging/audit 讓行為可歸責。考題常故意把 authorization 寫成 accountability。

  • 密碼、token、生物特徵是 authentication factors
  • RBAC 把 permissions 配給 roles 再配給 users
  • Least privilege 只給完成工作所需最低權限

3.SSO、Kerberos 與密碼攻擊

SSO 降低重複登入與 password fatigue，但 identity provider 成為重要依賴。Kerberos 以 tickets 支援不安全網路上的 mutual authentication。Dictionary attack 嘗試字典詞，不等同枚舉所有字元組合。

  • SSO 不代表每個服務都用不同 identity
  • MFA 結合不同 factor categories
  • Rate limiting 與強密碼可降低猜測攻擊風險

4.治理把控制變成持續循環

ISMS 將政策、程序、風險處理、監控與改善制度化；考題將 ISO/IEC 27001 連結到 ISMS requirements。NIST Privacy Framework 則把 privacy 視為組織風險管理問題，不是只靠 encryption 就能解決。

  • Compliance 不等於 risk 歸零
  • Privacy risk 需要識別、評估、溝通與管理
  • GDPR 是 EU 個資保護規則；本課只保留這個考題識別層次
  • 治理需要定期 review，不是一次性文件

一起拆題目

範例 1：使用者輸入帳號、以 MFA 登入、系統依 analyst role 開放報表並記錄下載。逐項分類。

  1. 帳號是 identification。
  2. MFA 是 authentication。
  3. Role permission 是 authorization/RBAC。
  4. 下載日誌支援 accountability。

所以答案是：依序為 identification、authentication、authorization、accountability。

範例 2：勒索軟體可能使服務停擺；系統未離線備份。請以 risk 語言描述。

  1. 勒索軟體行為是 threat。
  2. 缺乏隔離備份是 vulnerability。
  3. 停擺影響 availability。
  4. Likelihood 與 impact 組成需處理的 risk。

所以答案是：以備份、分段、最小權限與演練形成 defense in depth，而非只裝單一工具。

這裡最容易選錯

  • 把 CIA 的 A 寫成 accessibility
  • 把 authentication 與 authorization 對調
  • 把 accountability 當權限決策
  • 以為 SSO 天然比多帳號安全而忽略集中風險
  • 把合規證書當成不會發生事件的保證

換你快速判斷

先在心中作答，再展開答案。答不出來時，回頭找本課的對照關係。

1CIA triad 的三個目標是什麼？

Confidentiality、Integrity、Availability。

Availability 不是 Accessibility；CIA 是安全目標，不是機構名稱。

2Threat、vulnerability 與 risk 如何串起來？

Threat 可能利用 vulnerability 造成 impact；risk 綜合發生可能性與影響。

Defense in depth 用多層控制降低單點失敗。

3Identification、authentication、authorization、accountability 如何區分？

依序是宣稱身分、驗證身分、決定權限、讓行為可追責。

題目說「允許哪些操作」是在問 authorization，不是 accountability。

4Zero Trust 的核心原則是什麼？

Never trust, always verify；不因使用者或裝置位於內網就預設信任。

它需要持續驗證與 least privilege，不是只用 biometric 或只靠 firewall。

5ISO/IEC 27001 與 ISMS 的關係是什麼？

ISO/IEC 27001 提供建立、運作、監控與改善 ISMS 的 requirements。

通過管理系統驗證不等於風險歸零。

6NIST Privacy Framework 為何不把 privacy 只當成 encryption 問題？

它把 privacy 視為組織需要識別與管理的風險，需納入產品、服務與企業治理。

Encryption 可是控制，但不能單獨回答所有 privacy risk。本卡依 NIST Privacy Framework，不掛只識別 GDPR 名稱的考題。

最後用考古題驗證

本課連結的題目都已通過可重現的技術覆核，可逐題練習與判分。

開始本課考古題練習

參考來源