關聯筆記:Google Cybersecurity Certificate > C5 課程總覽
C5W2 — 保護組織資產(Protect organizational assets)
Module 2: 從控制分類、隱私法規、加密技術到存取控制的完整防護體系
目錄
一、安全控制的三種類型
1. 安全控制是什麼
Security Controls(安全控制)= 用來降低特定安全風險的防護措施。跟你鎖門、裝監視器一樣,目的是在威脅發生前或發生後保護資產。
安全控制的設計要搭配最小權限原則:只給人完成工作所需的最低限度存取權。
2. 三種類型一覽
| 類型 | 定義 | 範例 |
|---|---|---|
| Technical(技術型) | 用技術方案保護資產 | 加密、防火牆、IDS、MFA |
| Operational(營運型) | 由人每天執行的流程 | 安全意識訓練、事件回應程序 |
| Managerial(管理型) | 管理風險的策略與行政方法 | 政策制定、風險評估、合規稽核 |
三者通常組合使用。例如一間銀行:
- 管理型:制定「客戶資料保護政策」
- 營運型:員工受訓知道不能分享客戶資料
- 技術型:系統設定只允許授權帳號存取資料庫
3. 最小權限原則(Principle of Least Privilege)
核心概念:任何使用者、程式或程序只該擁有完成合法任務所需的「最小存取範圍」。
好處:
- 限制對機密資訊的存取
- 降低意外修改或篡改的機率
- 支持系統監控與稽核
- 降低惡意攻擊的衝擊範圍
常見做法:
- 用使用者帳號(非 root/admin)做日常工作
- 在需要提權的系統中限制存取時間
易錯點
- Technical vs Operational 的判斷標準:技術型是「系統自動執行」,營運型是「人每天要做」
- Least Privilege ≠ Zero Trust:最小權限是「給最少」,零信任是「永不預設信任,每次都驗」
二、隱私與資料處理
1. 個人資訊分類
| 類型 | 全稱 | 範例 | 風險等級 |
|---|---|---|---|
| PII | Personally Identifiable Information | 姓名、地址、電話、email | 中 |
| SPII | Sensitive PII | 身分證號、銀行帳號、生物特徵 | 高 |
| PHI | Protected Health Information | 病歷、診斷、用藥紀錄 | 高(受 HIPAA 保護) |
PII 是大傘,SPII 和 PHI 是其中特別敏感的子集。
2. 資料生命週期
資料從出生到死亡經歷五個階段,每個階段都有對應的安全措施:
Collect(收集)
↓
Store(儲存)
↓
Use(使用)
↓
Archive(歸檔)
↓
Destroy(銷毀)| 階段 | 安全重點 |
|---|---|
| Collect | 只收必要的、取得同意 |
| Store | 加密、存取控制 |
| Use | 最小權限、記錄存取 |
| Archive | 保留政策、限制存取 |
| Destroy | 確保不可復原(crypto shredding、實體銷毀) |
3. Data Governance(資料治理)
Data Governance = 一組正式程序,管理資料在整個生命週期中的處理方式。
三個關鍵角色:
| 角色 | 職責 |
|---|---|
| Data owner(資料擁有者) | 決定誰能存取、編輯、使用或銷毀資訊 |
| Data custodian(資料保管人) | 負責資訊的安全搬運、傳輸和儲存 |
| Data steward(資料管家) | 確保資料治理政策被正確執行 |
4. 主要隱私法規
| 法規 | 範圍 | 重點要求 |
|---|---|---|
| GDPR | 歐盟公民的個資(全球適用) | 取得同意、資料可攜權、被遺忘權、72h 通報 |
| PCI DSS | 處理信用卡資料的組織 | 加密傳輸、限制存取、定期測試 |
| HIPAA | 美國醫療健康資訊 | PHI 存取控制、稽核軌跡、最小必要原則 |
易錯點
- GDPR 不只管歐盟公司:只要處理到歐盟公民的資料,全世界的公司都要遵守
- PCI DSS 不是法律:是產業標準(由 Visa/Mastercard 等組成的 PCI SSC 制定),但違規會被罰款或取消收單資格
- Data owner vs Data custodian:owner 決定「誰能碰」,custodian 負責「安全地搬」
三、加密技術
1. 加密的基本概念
Cryptography(密碼學)= 把資訊變成未授權者無法理解的形式。
明文 ──[加密演算法 + 金鑰]──→ 密文
密文 ──[解密演算法 + 金鑰]──→ 明文核心術語:
- Cipher(密碼):執行加解密的演算法
- Cryptographic key(金鑰):解開密文的機制
- Plaintext(明文):原始可讀資料
- Ciphertext(密文):加密後的不可讀資料
2. 對稱加密 vs 非對稱加密
| 特性 | 對稱加密(Symmetric) | 非對稱加密(Asymmetric) |
|---|---|---|
| 金鑰數量 | 1 把(加解密同一把) | 2 把(公鑰+私鑰) |
| 速度 | 快 | 慢 |
| 適用場景 | 大量資料加密(靜態資料) | 金鑰交換、數位簽章 |
| 安全瓶頸 | 金鑰如何安全傳遞 | 計算成本高 |
3. 常見演算法
對稱演算法:
| 演算法 | 金鑰長度 | 狀態 |
|---|---|---|
| 3DES | 192-bit | 已淘汰(2023 年 NIST 停用) |
| AES | 128/192/256-bit | 現行標準,最廣泛使用 |
非對稱演算法:
| 演算法 | 用途 | 特點 |
|---|---|---|
| RSA | 加密+數位簽章 | 基於大質數分解 |
| DSA | 僅數位簽章 | 不能用於加密資料 |
易錯點
- 對稱加密的弱點不是演算法本身,是「金鑰怎麼安全送給對方」
- RSA 能加密也能簽章;DSA 只能簽章不能加密
- AES-256 是目前最強的對稱加密,美國政府和軍方等級
四、PKI 與數位憑證
1. PKI 是什麼
Public Key Infrastructure(公鑰基礎設施)= 一套加密框架,用來安全交換線上資訊。它解決了「我怎麼確定對方的公鑰是真的」這個問題。
PKI 的兩大用途:
- 在網路上建立受信任的連線(HTTPS)
- 交換加密資料(email 加密、VPN)
2. PKI 的運作流程
① 產生非對稱金鑰對(公鑰 + 私鑰)
↓
② 把公鑰交給 CA(Certificate Authority,憑證機構)
↓
③ CA 驗證身分後簽發數位憑證
↓
④ 憑證內含:公鑰 + 擁有者資訊 + CA 簽章
↓
⑤ 對方收到憑證,用 CA 的公鑰驗簽章 → 確認合法3. 數位憑證(Digital Certificate)
Digital Certificate = 一份文件,驗證公鑰持有者的身分。類似數位世界的身分證。
憑證包含:
- 擁有者的公鑰
- 擁有者的身分資訊
- CA 的數位簽章
- 有效期限
瀏覽器的鎖頭圖示 = 該網站有合法的 SSL/TLS 憑證 = 連線已加密。
五、雜湊與不可否認性
1. 雜湊函式(Hash Function)
Hash Function = 把任意長度的輸入轉成固定長度的輸出(hash value),且不可逆。
跟加密的關鍵差異:
- 加密:雙向,能解回來
- 雜湊:單向,不能解回來
用途:驗證資料完整性(資料有沒有被改過)。
2. 常見雜湊演算法
| 演算法 | 輸出長度 | 狀態 |
|---|---|---|
| MD5 | 128-bit | 已不安全(容易碰撞) |
| SHA-1 | 160-bit | 已不安全 |
| SHA-256 | 256-bit | 現行標準 |
| SHA-512 | 512-bit | 更高安全性 |
3. 雜湊碰撞與彩虹表攻擊
- Hash collision(碰撞):不同輸入產生相同 hash value,代表演算法不夠強
- Rainbow table(彩虹表):預先算好的「明文 → hash」對照表,拿來反查密碼
4. 加鹽(Salting)
Salting = 在明文後面附加一段隨機字串,再做 hash。
password123 + salt(x7!mR9) → SHA-256 → 完全不同的 hash
password123 + salt(Kp2@qL) → SHA-256 → 又是另一個 hash好處:即使兩人用相同密碼,hash 也不同,彩虹表失效。
5. 不可否認性(Non-repudiation)
Non-repudiation = 資訊的真實性無法被否認。你做了就是做了,不能賴帳。
實現方式:數位簽章(用私鑰簽、用公鑰驗)。因為只有你有私鑰,所以只有你能產生那個簽章。
易錯點
- Hash ≠ Encryption:hash 不可逆、沒有金鑰;encryption 可逆、需要金鑰
- MD5 不安全但還在用:有些系統用它做 checksum(驗檔案完整),但絕不該用來存密碼
- Salting 防的是彩虹表攻擊,不是暴力破解(暴力破解靠的是限速和長密碼)
六、存取控制與 AAA 框架
1. AAA 框架一覽
| 字母 | 全稱 | 問什麼 | 白話 |
|---|---|---|---|
| A | Authentication(驗證) | 你是誰? | 確認身分 |
| A | Authorization(授權) | 你能做什麼? | 確認權限 |
| A | Accounting(稽核) | 你做了什麼? | 記錄行為 |
使用者請求存取
↓
Authentication:確認「你是誰」
↓
Authorization:確認「你能做什麼」
↓
Accounting:記錄「你做了什麼」2. 驗證的三種因子
| 因子 | 英文 | 範例 |
|---|---|---|
| 知識因子 | Knowledge(something you know) | 密碼、PIN、安全問題 |
| 持有因子 | Ownership(something you have) | 手機 OTP、實體金鑰、智慧卡 |
| 特徵因子 | Characteristic(something you are) | 指紋、臉部辨識、虹膜掃描 |
3. SSO(Single Sign-On,單一登入)
SSO = 用一組帳密登入一次,就能存取多個相關服務。
好處:減少密碼疲勞、提高使用者體驗。 風險:一組帳密被盜 = 所有服務都暴露。
常見協定:
- LDAP:多用於企業內網,維護目錄服務
- SAML:跨域 SSO,用 XML 在 IdP 和 SP 之間傳遞驗證資訊
4. MFA(Multi-Factor Authentication,多因子驗證)
MFA = 需要兩種以上不同因子來驗證身分。
- 2FA:兩種因子(例:密碼 + 手機 OTP)
- 3FA:三種因子(密碼 + OTP + 指紋)
MFA 要求「不同類型」的因子
密碼 + 安全問題 = 都是知識因子 = 不算 MFA 密碼 + 手機 OTP = 知識 + 持有 = 算 MFA
5. OAuth 與 API 認證
OAuth = 開放標準的授權協定,讓第三方應用在不知道你的密碼的情況下存取你的資料。
白話版:你按「用 Google 帳號登入」某個 App 時,Google 給那個 App 一把有時效的鑰匙(token),它拿鑰匙去拿你的名字和 email,但永遠不知道你的 Google 密碼。
API token = 一小段加密碼,包含使用者資訊,用來認證 API 請求。
HTTP Basic Auth = 把帳密直接塞進 HTTP header(Base64 編碼,不是加密)。如果不走 HTTPS,帳密等於明文曝露。
易錯點
- SSO 不等於 MFA:SSO 是「登入一次用多個」,MFA 是「用多種因子驗一次」,兩者常搭配但獨立
- OAuth 做的是授權(Authorization),不是驗證(Authentication):它讓 App 拿到存取權,不是確認你是誰(OpenID Connect 才做驗證)
- LDAP vs SAML:LDAP 管內網目錄查詢;SAML 管跨域 SSO 的驗證資訊傳遞
七、IAM 與授權模型
1. IAM 是什麼
Identity and Access Management(身分與存取管理)= 一套流程和技術,管理組織內的數位身分。
IAM 四大元件:
| 元件 | 功能 |
|---|---|
| Identification(識別) | 使用者宣稱自己是誰(帳號) |
| Authentication(驗證) | 證明宣稱屬實(密碼/MFA) |
| Authorization(授權) | 決定能做什麼(權限) |
| Accountability(可追蹤) | 記錄做了什麼(日誌) |
2. User Provisioning(使用者配置)
User Provisioning = 建立和維護使用者數位身分的流程。
五個關鍵時機:
- 新進:建立帳號、指派角色與權限
- 轉調:調整權限符合新角色
- 離職:停用帳號、撤銷所有存取
- 定期審查:確認權限仍然合理
- 特殊請求:臨時提權(需審批流程)
3. 三種存取控制模型
| 模型 | 全稱 | 誰決定權限 | 適用場景 |
|---|---|---|---|
| MAC | Mandatory Access Control | 作業系統/管理員(強制) | 軍事、政府機密 |
| DAC | Discretionary Access Control | 資源擁有者(自主) | 一般企業檔案共享 |
| RBAC | Role-Based Access Control | 依角色指派 | 最常見,企業標準 |
MAC(強制存取控制):
- 系統管理員設規則,使用者無法更改
- 最嚴格,常見於軍方
- 例:機密等級 Secret 的人看不到 Top Secret 的文件
DAC(自主存取控制):
- 資源擁有者自己決定誰能存取
- 最寬鬆,風險最高
- 例:Google Drive 的「分享給特定人」
RBAC(角色型存取控制):
- 依職位角色分配權限,不是依個人
- 業界最常用,管理方便
- 例:「會計」角色能看財務系統,「工程師」角色能進 CI/CD
4. Session Management(工作階段管理)
Session = 使用者登入後,系統用 session ID 和 session cookie 追蹤這次連線。
Session hijacking(工作階段劫持)= 攻擊者偷走你的 session token,冒充你繼續操作。
防護措施:
- Session 有時效(timeout)
- 敏感操作重新驗證
- 用 HTTPS 保護 cookie 傳輸
- cookie 設定 HttpOnly + Secure flag
易錯點
- MAC vs DAC 的判斷標準:誰有權改存取規則?管理員強制 → MAC;擁有者自己決定 → DAC
- RBAC 的「角色」不等於「人」:一個人可以有多個角色,權限是角色的聯集
- Session hijacking 不需要知道密碼:只要偷到 session cookie 就等於登入了
八、術語速查表
前文已詳細解釋的術語不再重複,請回對應章節查閱。
| 英文 | 中文 | 白話解釋 |
|---|---|---|
| API token | API 令牌 | 一小段加密碼,用來認證 API 請求 |
| Asymmetric encryption | 非對稱加密 | 用公鑰加密、私鑰解密的方法 |
| Basic auth | 基本驗證 | 把帳密塞進 HTTP header 的技術 |
| Brute force attack | 暴力破解 | 窮舉所有可能來猜密碼 |
| Cipher | 密碼演算法 | 執行加解密的演算法 |
| Data custodian | 資料保管人 | 負責資料安全搬運和儲存的角色 |
| Data owner | 資料擁有者 | 決定誰能存取資料的角色 |
| Digital certificate | 數位憑證 | 驗證公鑰持有者身分的文件 |
| Hash collision | 雜湊碰撞 | 不同輸入產出相同 hash 值 |
| Information privacy | 資訊隱私 | 防止資料被未授權存取或散佈 |
| Non-repudiation | 不可否認性 | 做了就不能賴帳的概念 |
| OAuth | 開放授權 | 讓第三方 App 安全取得有限存取權的協定 |
| PCI DSS | 支付卡產業安全標準 | 金融業制定的安全標準 |
| Principle of least privilege | 最小權限原則 | 只給完成任務所需的最小存取 |
| Session hijacking | 工作階段劫持 | 偷走 session token 冒充使用者 |
| Symmetric encryption | 對稱加密 | 加解密用同一把金鑰 |
| User provisioning | 使用者配置 | 建立和管理數位身分的流程 |
筆記建立日期:2026-07-12 | 最後更新:2026-07-12