[架構師觀點] 資安沒有捷徑，請從根本做起!

問題與答案 (FAQ)

Q&A 類別 A: 概念理解類

A-Q1: 什麼是功能需求？

• A簡: 功能需求定義系統應提供的行為與輸出，採正向表列驗收，聚焦「能做什麼」與通過已知測試案例。
• A詳: 功能需求描述系統必須提供的具體能力與使用情境，例如註冊、登入、查詢報表等。它通常以使用者故事與驗收條件呈現，並以正向表列的方式測試：有列出的案例必須通過。功能需求的特徵是目標明確、可觀察與可驗證，屬於「有則可測」的項目。相較於品質要求，功能需求關注的是「做得到」而非「做得好」，但若忽略品質維度，即便功能可用，整體服務仍可能在安全、效能或可靠度上失靈。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q3, A-Q4

A-Q2: 什麼是品質要求？

• A簡: 品質要求是系統在極端或不利條件下仍應達成的約束，偏負向表列，聚焦避免錯誤與不該發生的行為。
• A詳: 品質要求（非功能性需求）涵蓋安全性、效能、可靠度、可擴充性等。其驗證多為負向表列：不得洩漏未授權資料、不得發生未處理例外等。品質要求的難點在於測試成本高、缺陷多源於設計根基，事後修補昂貴。因此品質需在設計期「內建」，透過結構化架構、標準化機制與嚴格工程紀律落實，而非只依賴最終測試來補救。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, A-Q3, A-Q20

A-Q3: 功能需求與品質要求差異？

• A簡: 功能關注「能做什麼」，品質關注「在各種條件下是否正確安全」。前者正向表列，後者以負向表列為主。
• A詳: 功能需求著重行為與輸出，驗收以通過已知測試案例為準；品質要求著重系統在異常、攻擊、壓力等條件下仍可預期運作，並避免不該發生的行為。設計上，功能可事後補加，品質多需自底層佈局。管理上，功能需求多由業務驅動，品質要求屬工程保證與風險治理的一環。忽略品質會造成一次通過、長期失敗的局面。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q4, A-Q20

A-Q4: 為何資安屬於品質要求？

• A簡: 資安保證「不發生不該發生的事」，需防洩漏、偽造、越權等，屬負向表列，必須從設計根本落實。
• A詳: 資安的核心是風險預防與信任建立。它不只是「有登入功能」的需求，而是要求「即使資料庫外洩也不致洩密」、「請求皆可驗真確權」。此類目標需在身分、授權、加密、金鑰管理、記錄等處理鏈上，採用標準機制與最小暴露面設計。因多數問題難以以單次測試完全覆蓋，故必須將資安視為品質要求，於架構與流程中內建。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q10, A-Q16, B-Q1

A-Q5: 什麼是「負向表列」？

• A簡: 負向表列以「禁止與避免」定義品質，如「不得洩漏未授權資料」、「不得出現未處理例外」等規範。
• A詳: 與功能測試「必須通過的案例」不同，負向表列關注「必須不會發生的情況」。在資安中，常見負向表列包含禁止未授權存取、禁止明文密碼、禁止未驗簽 Token、禁止脆弱加密等。此方法反映安全本質：攻擊面廣且未知，透過列舉風險與底線，要求系統在變化情境下仍維持安全邊界。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, B-Q14, D-Q6

A-Q6: 為什麼資安沒有捷徑？

• A簡: 安全依賴正確原理與嚴謹實作，非臨時補救。必須自設計起落實標準機制與紀律，方能可信。
• A詳: 資安是一門工程紀律：以公開驗證的演算法、適當金鑰長度、最小權限、完整驗證與審計構成防線。任何省略，如自製加密、跳過驗簽、UI 層授權、欠缺負面測試，都會形成永久隱患。捷徑常以「短期交付」為藉口，卻換得長期風險與修復成本。唯有「設計即安全」與「預設安全」的工程方法，才能建立持久信任。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q10, A-Q20, B-Q18

A-Q7: 為何密碼不可可逆儲存？

• A簡: 可逆儲存一旦外洩就等於洩密。應以加鹽雜湊不可逆保存，避免攻擊者還原使用者密碼。
• A詳: 密碼若以可逆加密保存，資料庫外洩即等同密碼外洩。正確作法是對每個密碼生成獨特 Salt，使用強雜湊（如bcrypt、Argon2）計算不可逆值，驗證時再以輸入密碼同法計算比對。此設計確保即使資料庫被竊，攻擊者仍難以從雜湊值得到原密碼，最大限度降低連動風險與法遵衝擊。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q1, B-Q2, C-Q1

A-Q8: 什麼是雜湊與加鹽？

• A簡: 雜湊是單向摘要；加鹽是為每筆資料加入隨機值再雜湊，抵禦彩虹表與相同密碼產生相同摘要。
• A詳: 雜湊函式將任意長度輸入映射到固定長度摘要，理想性質是不易逆向與碰撞困難。加鹽是在雜湊前加入獨特隨機 Salt，使同密碼在不同帳號產生不同雜湊，並阻止預先計算表攻擊。實務建議採用強化雜湊（含延遲成本），如bcrypt、scrypt、Argon2，並妥善儲存Salt與參數，以利未來升級與兼容。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q7, B-Q2, C-Q1

A-Q9: 雜湊與加密有何差異？

• A簡: 雜湊為單向不可逆，供完整性與驗證；加密為可逆，供機密性。密碼儲存應用雜湊，不使用可逆加密。
• A詳: 加密以金鑰將明文轉密文，授權方可還原，目的在保護資料機密性；雜湊將輸入映成摘要，無需金鑰且不可逆，常用於驗證資料是否被改動或密碼驗證。密碼儲存不可用加密，否則外洩即致命；應以加鹽雜湊保存。加密適用在傳輸或儲存機密資料時，並搭配完整金鑰管理。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q7, A-Q8, B-Q3

A-Q10: 為什麼要用公開演算法而非自製？

• A簡: 公開演算法具數學基礎與廣泛驗證，安全性來自金鑰；自製方案缺乏驗證，易藏致命弱點。
• A詳: 安全性不應依賴「別人不知道」，而應建立在可驗證數學難題與正確實作上（Kerckhoffs 原則）。公開演算法如RSA、AES、SHA家族經多年審視，安全性取決於金鑰長度與管理，自製算法常在統計特徵、隨機性或實作細節上出錯而不自知。採用標準方案可被審計、可互通，且易於配置強度與升級。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q4, B-Q3, A-Q6

A-Q11: 資安中的信任是什麼？

• A簡: 信任是可驗證的保證：遵循標準、妥善金鑰、正確實作，使他人可合理相信行為真實與資料安全。
• A詳: 信任建立在可證明與可審計的機制上，例如：不儲存密碼確保外洩不失守；用私鑰簽章確保訊息來源；雙方藉金鑰交換在不可信網路安全通訊。這些保證來自公開算法、足夠金鑰強度與嚴謹流程，而非口頭承諾或不透明的「土炮」實作。信任是系統長期生命力的資本。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, B-Q5, A-Q16

A-Q12: 金鑰與金鑰長度的重要性？

• A簡: 安全性主要由金鑰掌控；適當長度與妥善保管，決定在可接受時間內能否被暴力破解或冒用。
• A詳: 現代密碼學將安全性重心放在金鑰：算法公開、碼可審，金鑰秘密性與複雜度決定攻擊成本。金鑰長度需隨計算能力演進適時提高（如RSA 2048/3072+，對稱AES 128/256）。同時，金鑰儲存、輪換、權限與審計要完整，否則再強算法也形同虛設。管理不善的金鑰是最常見單點失效。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, B-Q3, C-Q3

A-Q13: 認證與授權差異？

• A簡: 認證確認「你是誰」，授權決定「你能做什麼」。兩者相輔相成，缺一會造成安全斷層。
• A詳: 認證（Authentication）藉帳密、憑證、OTP等機制確認身分；授權（Authorization）依角色、屬性、政策裁決可存取的資源與操作。正確流程是先認證，再授權，並在每次請求中以Token攜帶身分主張與進行驗簽。僅做UI層授權或僅檢身分不裁決權限，皆會導致越權與資料外洩。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q6, B-Q11, A-Q19

A-Q14: 什麼是 Session 與 Token？

• A簡: Session 表示已登入狀態；Token 是攜帶身分主張與簽章的憑證，用於跨請求與跨服務識別與信任。
• A詳: 登入後的存續狀態稱Session。實作方式可為伺服端儲存會話（ID+狀態），或發出含主張與簽章的Token（如JWT）。Token讓下游服務免回源驗證身分，改以驗簽與檢查過期等欄位快速信任，適合分散式架構；然而每次請求都需驗簽與授權裁決，避免未經授權之操作。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q6, B-Q7, A-Q16

A-Q15: 什麼是 JWT？

• A簡: JWT 是自包含的JSON憑證，含Header/Payload/Signature，透過簽章供快速驗證與跨服務信任。
• A詳: JSON Web Token由三部分組成：Header（算法/型別）、Payload（主張，如sub、exp）、Signature（簽章）。簽發者以對稱或非對稱金鑰簽章，下游透過驗簽確認未被竄改，並依exp等欄位判斷有效性。JWT可降低跨服務查詢成本，但必須嚴格驗簽、檢過期與權限，並防篡改與誤用算法設定。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q7, B-Q8, C-Q3

A-Q16: 為何每個請求都要驗證 Token？

• A簡: 每次驗簽可即時阻斷偽造與過期憑證，確保每次存取都安全；以CPU換通訊成本，總體更划算。
• A詳: 在零信任思維下，安全假設為「網路不可信、狀態可變」。每個請求驗簽與檢查exp/nbf等欄位，可立即發現被竄改或過期Token，避免依賴上游通訊確認造成延遲與單點；相較跨網路查詢，驗簽計算成本更可控且快數千倍。因此「每請求驗證」是分散式安全的基本功。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, B-Q8, D-Q6

A-Q17: 什麼是防偽設計的啟示？

• A簡: 如同車票防偽，憑證需使驗證者離線即可判斷真偽，透過簽章、編碼與規則即時辨識。
• A詳: 傳統實體票以紙質、章印、編碼讓查驗者現場識別真偽。對應到軟體，Token透過簽章與主張欄位讓下游在不回源下快速驗真，降低通訊依賴。啟示是：安全設計要將「可即時驗證」作為基本能力，並兼顧造假成本與驗證效率，使欺騙不經濟、驗證可擴展。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q15, B-Q7, B-Q8

A-Q18: 什麼是 RBAC、PBAC、ABAC？

• A簡: RBAC以角色授權，PBAC以政策規則裁決，ABAC以屬性組合判斷。成熟模型避免自製權限散亂。
• A詳: RBAC（基於角色）以角色集合權限，管理簡單；PBAC（基於政策）以規則語言描述存取條件；ABAC（基於屬性）以使用者、資源、環境屬性組合判斷，最靈活。選擇模型應依複雜度與治理能力，並集中化決策與審計，避免在每頁/每API自製分散檢查而出現不一致與漏洞。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q11, B-Q12, C-Q7

A-Q19: 為何 UI/選單層授權不足？

• A簡: UI 只能影響可見性，無法防止直接請求與繞過。授權須於API層與服務邊界強制執行。
• A詳: 僅在UI隱藏按鈕或入口，並不阻止使用者手工構造請求或透過其他入口直達共用資源。若API層未做授權，將形成越權漏洞。正確作法是在所有受保護端點統一執行認證與授權判斷，UI僅作提示，而非安全邊界。API Gateway或服務內中介層是執行點的首選。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q13, C-Q6, D-Q6

A-Q20: 為何說「品質是內建的，不是測試出來的」？

• A簡: 品質由設計與工程紀律決定；測試僅揭露缺陷，無法弭平結構性問題，必須從源頭正確設計。
• A詳: 測試能發現錯誤，卻無法將錯誤架構變良；資安、效能、可靠度多屬架構選擇與流程紀律的結果。若只在尾端補救，最多達到「堪用」，難以達到高品質。將資安視為品質要求意味著在需求、設計、實作、部署各階段建立標準化機制與檢核，使安全成為產品基因。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, B-Q20, C-Q9

Q&A 類別 B: 技術原理類

B-Q1: 密碼儲存的正確流程如何運作？

• A簡: 使用每筆獨特Salt與強雜湊保存摘要，驗證時對輸入同參數雜湊比對，不可儲存可逆密碼。
• A詳: 原理說明：以不可逆雜湊（如bcrypt/Argon2）對「Salt+密碼」計算摘要。關鍵步驟：1) 產生唯一Salt與成本因子；2) 計算雜湊並存儲{Salt, Hash, 參數}；3) 登入時以同參數重算比對。核心組件：安全隨機數、雜湊函式庫、參數版本欄位。此流程確保資料庫外洩仍難還原原文密碼，並可逐步提升成本因子。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q7, A-Q8, C-Q1

B-Q2: Hash+Salt 的原理與步驟？

• A簡: 將隨機Salt拼接密碼後以強雜湊計算，儲存Hash與Salt。登入時重現流程比較結果。
• A詳: 技術原理：Salt破壞彩虹表與同值特徵，計算成本因子提高暴力破解代價。步驟：1) 安全PRNG產生Salt；2) 以bcrypt/Argon2等計算Hash；3) 存Salt與Hash；4) 驗證時同法計算比對。核心組件：PRNG、Key Derivation/Hash函式、參數儲存。建議隨時間提升迭代/成本，保留參數版本以便升級。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q1, A-Q8, C-Q1

B-Q3: 公開金鑰/私鑰加密與數位簽章機制？

• A簡: 非對稱密碼學以公鑰加密、私鑰解密；簽章以私鑰簽、用公鑰驗證，確保機密性與不可否認。
• A詳: 原理：非對稱演算法（如RSA、ECDSA）使用成對金鑰。加密流程：發送者用接收者公鑰加密，接收者用私鑰解密。簽章流程：持有私鑰者簽署訊息摘要，驗證者用公鑰驗簽。核心組件：金鑰生成、密碼學函式、金鑰保管。常見應用：TLS、JWT（簽章）、軟體簽章、文件簽核。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q11, A-Q12, C-Q3

B-Q4: 為何公開演算法安全（Kerckhoffs 原則）？

• A簡: 演算法公開、碼可審，安全性依賴金鑰保密與計算難題，避免把安全建立在「祕密實作」上。
• A詳: 原理說明：Kerckhoffs 認為系統即使公開，仍應在金鑰不洩漏下保持安全。步驟與機制：公開算法→受學術與實務驗證→安全性由金鑰長度、隨機性與管理確保。核心組件：強隨機數、金鑰長度策略、輪換與撤銷流程。其價值在於可審計、可互通、可升級，避免自製算法不可見風險。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, A-Q12, B-Q3

B-Q5: 金鑰管理基本機制與信任鏈？

• A簡: 金鑰需安全生成、存放、輪換與撤銷，並建立信任鏈以驗證身分與授權，避免單點失守。
• A詳: 技術原理：信任來自對金鑰與憑證鏈的驗證。關鍵步驟：1) 安全生成金鑰；2) 妥善存放（權限隔離）；3) 定期輪換與吊銷；4) 建立信任鏈（CA/發行者）；5) 審計與告警。核心組件：金鑰庫、憑證基礎設施、審計記錄。缺一將使帳號冒用或簽章失效，破壞整體信任。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q11, A-Q12, C-Q3

B-Q6: Session Token 驗證流程？

• A簡: 每請求驗簽與檢核時效與受眾，確認未篡改與仍有效，再進行授權裁決，拒絕不合法憑證。
• A詳: 原理：以簽章與主張讓服務離線驗真。步驟：1) 解析Token；2) 驗簽（算法/金鑰/指紋）；3) 檢查exp/nbf/aud/iss；4) 取主張（sub/roles）；5) 授權裁決；6) 記錄審計。核心組件：Token處理庫、金鑰來源、策略引擎。每步缺漏均可能導致越權或接受偽造憑證。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q14, A-Q16, B-Q7

B-Q7: JWT 結構與驗簽流程？

• A簡: JWT由Header、Payload、Signature組成；以發行者金鑰簽章，下游據此驗真與檢查主張有效性。
• A詳: 技術原理：Header載演算法，Payload載主張（sub、iat、exp…），Signature為簽章。驗證步驟：1) Base64Url解碼；2) 確認alg與kid；3) 取得對應金鑰；4) 按alg驗簽；5) 檢核exp/nbf等；6) 交授權引擎判斷。核心組件：金鑰解析、JWKs、時間同步。常見風險是錯用alg與未驗簽。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q15, C-Q3, D-Q5

B-Q8: JWT 為何能減少跨服務通訊？

• A簡: 自包含主張與簽章讓下游離線驗真，免回源查詢，降低網路往返與耦合，提高擴展性。
• A詳: 原理：將身分與授權主張封裝於Token，由下游服務自行驗簽與檢核時效與範圍。關鍵步驟：標準化主張、嚴格驗簽、短時效、定期輪換金鑰。核心組件：JWKs端點、緩存金鑰、策略引擎。這以計算換通訊的模式，平均比跨網路查詢快數量級，特別適合微服務。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q16, B-Q6, C-Q6

B-Q9: Token 過期與刷新機制原理？

• A簡: 短期存取Token配合可撤銷的刷新Token，平衡安全與體驗，便於快速失效與延長會話。
• A詳: 原理：Short-lived Access Token降低憑證外洩窗口；Refresh Token可在受控條件下換新。步驟：1) 簽發短exp Token；2) 安全儲存Refresh Token；3) 刷新時驗證與旋轉；4) 黑名單或版本戳記撤銷。核心組件：Token服務、存放策略、撤銷名單。可兼顧即時失效與減少重登。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q5, D-Q4, B-Q6

B-Q10: 分散式服務的認證授權架構？

• A簡: 採集中簽發、分散驗證；網關或側車統一執行驗簽與策略裁決，服務內實施最小權限。
• A詳: 原理：將身分與策略統一管理，讓各服務專注業務。流程：1) IdP/OIDC 簽發Token；2) API Gateway/Sidecar 驗簽與授權；3) 下游服務執行資源級檢查；4) 審計資料匯總。核心組件：IdP、策略引擎、PDP/PEP、審計管線。此模式降低耦合與重複實作，並強化治理。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: C-Q6, B-Q11, B-Q12

B-Q11: 授權決策中心化與策略評估流程？

• A簡: 將授權裁決集中於策略引擎，以標準語法評估主張與資源屬性，確保一致與可審計。
• A詳: 原理：分離決策（PDP）與執行（PEP），使用策略語言（如Rego、Cedar）描述規則。步驟：1) 收集主張與上下文；2) 評估策略；3) 回傳允許/拒絕與說明；4) 記錄審計。核心組件：策略存儲、版本控管、測試框架。中心化可避免多入口不一致並便於變更管理。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q18, C-Q7, D-Q7

B-Q12: RBAC/PBAC/ABAC 架構如何設計？

• A簡: RBAC用角色映權限；PBAC/ABAC以策略引擎裁決屬性與規則，需中心化管理與審計支持。
• A詳: 原理：RBAC以角色簡化管理；ABAC以屬性組合裁決，PBAC以政策語法表達。設計：1) 定義資源與動作；2) 建立角色/屬性模型；3) 撰寫政策；4) 佈署PDP/PEP；5) 審計與測試。核心組件：目錄服務、策略引擎、快取。選型依複雜度權衡治理成本與靈活度。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q18, B-Q11, C-Q7

B-Q13: API 安全邊界與最小接觸面積原理？

• A簡: 將授權與敏感資料控制於少數可控端點，縮小暴露面，強化檢查與監控密度與品質。
• A詳: 原理：攻擊面越小，防護越有效。步驟：1) 收斂資料輸出入口；2) 網關統一驗簽與授權；3) 服務內再次資源級檢查；4) 移除不必要欄位與端點。核心組件：API Gateway、資源遮罩、日誌審計。此原則能降低遺漏檢查導致的越權與洩漏風險。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q19, C-Q6, D-Q6

B-Q14: 負面測試與滲透測試的角色？

• A簡: 負面測試驗證「不該發生」；滲透測試模擬攻擊找弱點，補足功能測試無法涵蓋的風險。
• A詳: 原理：安全需驗證系統在異常輸入與敵對行為下的表現。步驟：1) 列舉禁止行為；2) 實作負面用例；3) 自動化；4) 定期滲測與改進。核心組件：測試框架、掃描工具、報告與補救流程。此類測試將品質要求轉為可驗證工項，支撐「內建品質」實踐。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q5, C-Q10, D-Q6

B-Q15: 效能與安全運算成本如何取捨？

• A簡: 以計算換通訊，優先本地驗簽；控制Token時效與快取金鑰，平衡CPU負載與安全性。
• A詳: 原理：CPU運算（驗簽）通常遠快於跨網路查詢。步驟：1) 採短期Token降低驗證負擔；2) 金鑰快取+過期控管；3) 僅對敏感端點強化檢查；4) 監控延遲與容量。核心組件：驗簽庫、JWKs快取、指標監控。以數據觀測持續調優，達到安全與效能的合理平衡。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q16, B-Q8, C-Q6

B-Q16: 統計分析如何破解簡單替換加密？

• A簡: 透過頻率分析與語言特徵比對，推斷字元映射；自製替換法常因此被輕易還原。
• A詳: 原理：自然語言中字母/字元出現頻率具規律。步驟：1) 收集樣本分布；2) 比對密文頻率；3) 猜測映射；4) 迭代修正。核心組件：頻統工具、語料庫。此法說明非標準加密的脆弱，強化採用公開算法與金鑰保密的重要性，避免「安全藉祕密」幻覺。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, B-Q4, D-Q9

B-Q17: 代碼保密與金鑰保密的安全性比較？

• A簡: 代碼終將被看見與逆向；安全應依賴金鑰保密與標準算法，而非隱藏實作細節。
• A詳: 原理：程式碼為可被閱讀與逆向的資產，團隊合作亦需可讀性。保密代碼無法形成穩固安全假設。步驟與機制：1) 開源或可審計庫；2) 將安全焦點轉於金鑰與流程；3) 強化審計與測試。核心組件：金鑰管理、審計、標準庫。此比較印證「安全在金鑰，不在算法祕密」。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q10, B-Q4, B-Q5

B-Q18: 失效安全與安全預設原理？

• A簡: 系統在錯誤或未知狀態時應預設拒絕；預設關閉敏感功能，需明確授權才開放。
• A詳: 原理：失效安全（Fail Secure）要求在錯誤、逾時、未知時採取最保守決策；安全預設（Secure Default）讓系統上線即安全。步驟：1) 預設拒絕；2) 逾時自動失效；3) 僅白名單放行；4) 最小權限。核心組件：逾時計時、策略白名單、審計。能有效降低未知風險與誤配置。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q9, D-Q6, B-Q13

B-Q19: 安全機制共用與重用的設計考量？

• A簡: 將認證與授權抽象成共用組件或中介層，避免多入口不一致，提升維護與審計品質。
• A詳: 原理：重用可一致化與減少漏檢。步驟：1) 提取驗簽/授權中介；2) 共用策略庫；3) 在共用頁面/API 強制檢查；4) 版本化政策。核心組件：API中介、策略服務、SDK。能避免「一頁漏檢全站失守」的地雷，也是治理與合規基石。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q19, C-Q8, D-Q7

B-Q20: 品質治理的「左移」如何落實？

• A簡: 在需求與設計期導入威脅模型與安全規範，搭配自動化檢核，使安全成為交付前置條件。
• A詳: 原理：Shift-left 將品質檢核前置，減少後期昂貴補救。步驟：1) 需求期列負面表列；2) 設計期選標準機制；3) 實作期用共用庫；4) 驗收期做安全測試；5) 持續監測。核心組件：威脅建模、政策檢核、CI/CD Gate。此流程把「內建品質」轉為團隊日常。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q20, C-Q9, C-Q10

Q&A 類別 C: 實作應用類（10題）

C-Q1: 如何實作安全的密碼儲存？

• A簡: 以強雜湊（bcrypt/Argon2）與獨特Salt保存摘要，保留參數版本，便於未來提升成本與兼容。
• A詳:
  • 步驟：1) 生成隨機Salt；2) 使用bcrypt/Argon2計算Hash（含成本因子）；3) 儲存{Hash,Salt,Cost,Ver}；4) 登入時compare；5) 若成本過低，升級重算。
  • 程式碼：Node.js: const hash = await bcrypt.hash(pw,12); const ok = await bcrypt.compare(input,hash);
  • 注意：使用安全PRNG；每筆Salt不同；選用經驗證庫；保留參數版本；避免可逆加密；定期提升成本因子。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q1, B-Q2, D-Q1

C-Q2: 如何實作登入驗證流程？

• A簡: 以加鹽雜湊驗密碼，成功後簽發短期Token；失敗計數與延遲，防爆破，並記錄審計事件。
• A詳:
  • 步驟：1) 取帳號查Hash與Salt；2) 安全比較；3) 驗2FA（選）；4) 簽發短期JWT（含sub/exp）與Refresh Token；5) 記錄登入成功/失敗。
  • 程式碼：if(await bcrypt.compare(pw,hash)){ token=jwt.sign({sub:id},key,{expiresIn:’15m’}) }
  • 注意：統一錯誤訊息；限制嘗試次數；加入IP/UA風險評估；Token最小化主張；HTTPS傳輸。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q13, B-Q6, C-Q5

C-Q3: 在 .NET 如何簽發與驗證 JWT？

• A簡: 使用JwtSecurityTokenHandler簽發RS256，並以TokenValidationParameters設定驗簽、受眾與有效期。
• A詳:
  • 步驟：1) 讀取私鑰簽發JwtSecurityToken；2) 配置TokenValidationParameters（ValidateIssuerSigningKey、ValidateIssuer/Audience、ValidateLifetime）；3) 中介軟體驗證。
  • 程式碼：var token = handler.CreateToken(desc); handler.ValidateToken(jwt, params, out _);
  • 注意：偏好RS256；對時；設定ClockSkew；使用JWKs輪換金鑰；最小主張；短exp。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q7, B-Q5, D-Q5

C-Q4: 在 Node.js 驗證每個請求的 JWT？

• A簡: 以中介層解析與驗簽，檢查exp/iss/aud，失敗即拒絕，將主張注入req供授權裁決使用。
• A詳:
  • 步驟：1) 提取Authorization Bearer；2) 使用jsonwebtoken或jose驗簽；3) 檢查exp/nbf/iss/aud；4) 注入req.user；5) 交由授權中介。
  • 程式碼：app.use(async(req,res,next)=>{ const t=getToken(req); const payload=jwt.verify(t, pubKey, {aud,iss}); req.user=payload; next();});
  • 注意：拒絕”none”算法；快取JWKs；處理逾時；統一錯誤碼；加上審計日誌。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q16, B-Q6, D-Q3

C-Q5: 如何設計 Token 過期與刷新？

• A簡: Access Token短期、Refresh Token可撤銷且輪換，刷新時驗裝置/風險，出錯即整鏈失效。
• A詳:
  • 步驟：1) Access Token 15m；2) 簽發綁定裝置的Refresh Token；3) 刷新API驗證RT與風險評估；4) 成功後旋轉RT；5) 黑名單撤銷舊RT。
  • 程式碼：onRefresh(rt){ verifyRT(rt); issueNewAT(); rotateRT(); blacklist(oldRT);}
  • 注意：RT存放安全；失竊通報；設上限壽期；IP/指紋檢查；最小化權限與主張。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, D-Q4, C-Q2

C-Q6: 如何在 API Gateway 統一驗簽與授權？

• A簡: 在網關配置JWT驗簽與策略檢查，拒不合法請求，向後傳遞已驗主張，減少服務重複與漏檢。
• A詳:
  • 步驟：1) 啟用JWT驗證外掛；2) 配置JWKs與受眾；3) 導入策略引擎（OPA/自製）判斷；4) 注入經驗證主張標頭；5) 記錄審計。
  • 設定：kong/jwt、nginx lua-resty-jwt、Envoy/ext_authz。
  • 注意：僅信任內網標頭；防止標頭注入；強制TLS；版本化策略；監控拒絕率與誤判。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q10, B-Q13, D-Q6

C-Q7: 如何實作 RBAC 與策略檢查？

• A簡: 建立資源與動作模型，角色映射權限，於中介層讀取主張與角色，集中呼叫策略引擎裁決。
• A詳:
  • 步驟：1) 定義資源:action；2) 設計角色：權限集合；3) JWT含roles；4) 中介層PEP組裝請求；5) PDP以策略裁決；6) 封存審計。
  • 程式碼：decision=pdp.eval({sub,role,resource,action}); if(!decision.allow) deny();
  • 注意：角色爆炸風險；最小權限；版本控制；策略測試；資源與租戶隔離。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q18, B-Q11, D-Q10

C-Q8: 如何對共用 API 實施多入口一致授權？

• A簡: 將授權檢查內聚於共用API內或PEP，所有入口都走同一路徑，避免個別頁面遺漏檢查。
• A詳:
  • 步驟：1) 清點共用API；2) 在API層實施必經的驗簽與授權；3) UI只控制可見性；4) 廣泛測試不同入口；5) 加審計與阻擋日誌。
  • 程式碼：router.use(authzMiddleware(resource,action));
  • 注意：禁止繞過；去除舊入口；API契約固定；版本化；自動化安全測試覆蓋多入口。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q19, B-Q19, D-Q7

C-Q9: 如何設計安全預設與配置？

• A簡: 預設拒絕、最小權限、關閉敏感功能；以環境變數與配置檔管理，納入CI檢查避免誤開。
• A詳:
  • 步驟：1) 預設禁用管理介面/目錄；2) 權限預設最小；3) 必填TLS與驗簽開關；4) 配置白名單化；5) CI檢查不安全配置。
  • 設定：app.security.requireTLS=true；auth.jwt.validate=true。
  • 注意：禁止硬編碼密鑰；配置分環境；審計變更；啟用逾時；以宣告式策略取代程式旗標分散。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q18, B-Q20, D-Q6

C-Q10: 如何撰寫負面測試與簡易滲透腳本？

• A簡: 針對未授權、過期、篡改Token與越權資源撰寫自動化測試，搭配掃描工具找常見弱點。
• A詳:
  • 步驟：1) 列禁止行為用例；2) 編寫測試：無Token/過期/錯alg/錯aud；3) 測資涵蓋多入口；4) 用OWASP ZAP/nikto掃描；5) 納入CI。
  • 程式碼：expect(401) for requests without token; expect(403) for insufficient scope。
  • 注意：資料隔離；清理測試帳號；將發現導回策略；定期更新測試庫與字典。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q14, D-Q6, C-Q8

Q&A 類別 D: 問題解決類（10題）

D-Q1: 發現資料庫存放可逆密碼怎麼辦？

• A簡: 立即停用可逆儲存，強制重設密碼，改採加鹽雜湊；通報影響並建立長期修補與稽核。
• A詳:
  • 症狀：資料庫或備份中可讀出明文/可解密密碼。
  • 原因：錯誤設計使用可逆加密或儲存明文。
  • 解決：1) 緊急風險評估與隔離；2) 全體使用者強制改密；3) 切換至bcrypt/Argon2；4) 移除舊欄位與密鑰；5) 通知與合規。
  • 預防：設計審查、禁止明文/可逆密碼、定期稽核與測試。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q1, B-Q1, A-Q7

D-Q2: 使用者密碼外洩風險如何緊急處置？

• A簡: 啟動事件應變：封鎖可疑登入、強制改密與重登、開啟額外驗證並通報，用行為監測防二次傷害。
• A詳:
  • 症狀：異常登入、資料流出、外部通報。
  • 原因：資料庫外洩、釣魚、重複密碼連動。
  • 解決：1) 強制重設密碼；2) 撤銷Token；3) 臨時啟用2FA；4) 監控異常行為；5) 對外通報與合規。
  • 預防：強雜湊儲存、密碼政策、異常偵測、教育與祕密管理。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q7, C-Q2, B-Q9

D-Q3: JWT 驗證「signature invalid」怎麼排查？

• A簡: 檢查算法、金鑰匹配、JWKs載入、Token毀損與編碼；對時與受眾不符亦可致驗證失敗。
• A詳:
  • 症狀：驗簽失敗、返回401/403。
  • 原因：算法不符、錯誤金鑰、Token截斷、Base64Url錯誤、kid解析失敗。
  • 解決：1) 比對alg與程式設定；2) 確認公私鑰對；3) 檢查JWKs與快取；4) 檢查Token完整性；5) 日誌定位。
  • 預防：固定算法、金鑰輪換流程、健康檢查JWKs、完整端對端測試。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q7, C-Q4, C-Q3

D-Q4: JWT 未過期但服務判定過期？

• A簡: 多因時鐘不同步或ClockSkew未設定；檢查exp/nbf對時並調整容忍值與同步機制。
• A詳:
  • 症狀：使用者頻繁被登出、返回過期錯誤。
  • 原因：伺服器時間漂移、未設定ClockSkew、時區誤差。
  • 解決：1) 校正NTP；2) 設置ClockSkew（如±60s）；3) 觀察exp/iat；4) 檢測多節點時間一致性。
  • 預防：強制NTP、部署前時鐘檢查、監控時間漂移、短Token配合刷新。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q9, C-Q5, C-Q3

D-Q5: RS256/HS256 配置錯誤導致驗簽失敗？

• A簡: 混用對稱與非對稱算法會失敗；確保簽發與驗證一致，並安全管理私鑰與JWKs。
• A詳:
  • 症狀：跨服務或語言異常驗簽。
  • 原因：簽發用RS256，驗證卻用HS256或反之；kid解析錯誤。
  • 解決：1) 統一alg；2) 對應正確金鑰來源；3) 檢查JWKs kid；4) 加強日誌。
  • 預防：固定算法策略、契約測試、金鑰輪換演練、拒絕「none」算法。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q7, C-Q3, C-Q4

D-Q6: 部分 API 未驗 Token 導致越權怎麼辦？

• A簡: 立即封鎖或下線風險端點，於網關強制驗簽與授權，補齊測試，再恢復服務。
• A詳:
  • 症狀：未登入可存取敏感資料，或低權限越權。
  • 原因：入口分散、遺漏中介、UI層授權。
  • 解決：1) 網關設「必驗」；2) 盤點端點與套用中介；3) 增加負面測試；4) 審核日誌。
  • 預防：安全預設、共用中介、CI安全檢查、API清單治理。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q13, C-Q6, C-Q10

D-Q7: 共用頁面/多入口授權不一致漏洞？

• A簡: 因多入口共用資源但授權分散。集中化PEP/PDP，所有入口共享同規則與審計。
• A詳:
  • 症狀：A入口可看，B入口不該卻也能看。
  • 原因：授權邏輯分散於頁面或控制器。
  • 解決：1) 將授權移至共用中介；2) 資源級檢查；3) 用案例覆蓋多入口；4) 移除過時入口。
  • 預防：策略中心化、版本控管、契約化資源、定期滲測。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q11, B-Q19, C-Q8

D-Q8: 分散式服務過度回源查詢造成延遲？

• A簡: 以JWT自包含主張與本地驗簽取代頻繁回源，快取金鑰並監控延遲以優化。
• A詳:
  • 症狀：高延遲、放大流量、上游壓力大。
  • 原因：每請求都回認證服務確認。
  • 解決：1) 改用JWT離線驗簽；2) 金鑰JWKs快取；3) 僅在特定情況回源（撤銷/高風險）；4) 監控並壓測。
  • 預防：設計期選用自包含憑證、策略緩存、容量規劃。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q8, B-Q15, C-Q6

D-Q9: 自製簡單加密被破解如何補救？

• A簡: 逐步遷移至標準算法；重新加密資料與重建信任，公告變更並加強審計與測試。
• A詳:
  • 症狀：密文可被還原、外部報告突破。
  • 原因：替換式或弱隨機、不具數學基礎。
  • 解決：1) 立即禁用舊算法；2) 以AES/RSA等重構；3) 金鑰管理上線；4) 導入審計與滲測；5) 用滾動升級重加密。
  • 預防：僅用標準庫、設計審查、第三方審核、訓練團隊。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, B-Q16, A-Q10

D-Q10: 授權規則矛盾導致不可預期存取？

• A簡: 規則來源分散或衝突。建立中心化策略、優先序與測試，並版本管控與審計。
• A詳:
  • 症狀：同用戶在不同路徑結果不同。
  • 原因：多系統規則重疊、角色爆炸、例外濫用。
  • 解決：1) 收斂策略至PDP；2) 定義優先序；3) 改寫為可測政策；4) 加入回歸測試；5) 清理例外。
  • 預防：策略治理、審核流程、規則最小化、資源模型清晰。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q11, B-Q12, C-Q7

學習路徑索引

• 初學者：建議先學習哪 15 題
  • A-Q1: 什麼是功能需求？
  • A-Q2: 什麼是品質要求？
  • A-Q3: 功能需求與品質要求差異？
  • A-Q4: 為何資安屬於品質要求？
  • A-Q5: 什麼是「負向表列」？
  • A-Q6: 為什麼資安沒有捷徑？
  • A-Q7: 為何密碼不可可逆儲存？
  • A-Q8: 什麼是雜湊與加鹽？
  • A-Q9: 雜湊與加密有何差異？
  • A-Q13: 認證與授權差異？
  • A-Q14: 什麼是 Session 與 Token？
  • A-Q15: 什麼是 JWT？
  • A-Q16: 為何每個請求都要驗證 Token？
  • C-Q1: 如何實作安全的密碼儲存？
  • C-Q2: 如何實作登入驗證流程？
• 中級者：建議學習哪 20 題
  • A-Q10: 為什麼要用公開演算法而非自製？
  • A-Q11: 資安中的信任是什麼？
  • A-Q12: 金鑰與金鑰長度的重要性？
  • A-Q17: 什麼是防偽設計的啟示？
  • A-Q18: 什麼是 RBAC、PBAC、ABAC？
  • A-Q19: 為何 UI/選單層授權不足？
  • B-Q1: 密碼儲存的正確流程如何運作？
  • B-Q2: Hash+Salt 的原理與步驟？
  • B-Q3: 公開金鑰/私鑰加密與數位簽章機制？
  • B-Q6: Session Token 驗證流程？
  • B-Q7: JWT 結構與驗簽流程？
  • B-Q8: JWT 為何能減少跨服務通訊？
  • B-Q9: Token 過期與刷新機制原理？
  • B-Q13: API 安全邊界與最小接觸面積原理？
  • B-Q14: 負面測試與滲透測試的角色？
  • C-Q3: 在 .NET 如何簽發與驗證 JWT？
  • C-Q4: 在 Node.js 驗證每個請求的 JWT？
  • C-Q5: 如何設計 Token 過期與刷新？
  • C-Q6: 如何在 API Gateway 統一驗簽與授權？
  • C-Q10: 如何撰寫負面測試與簡易滲透腳本？
• 高級者：建議關注哪 15 題
  • B-Q4: 為何公開演算法安全（Kerckhoffs 原則）？
  • B-Q5: 金鑰管理基本機制與信任鏈？
  • B-Q10: 分散式服務的認證授權架構？
  • B-Q11: 授權決策中心化與策略評估流程？
  • B-Q12: RBAC/PBAC/ABAC 架構如何設計？
  • B-Q15: 效能與安全運算成本如何取捨？
  • B-Q16: 統計分析如何破解簡單替換加密？
  • B-Q18: 失效安全與安全預設原理？
  • B-Q19: 安全機制共用與重用的設計考量？
  • B-Q20: 品質治理的「左移」如何落實？
  • C-Q7: 如何實作 RBAC 與策略檢查？
  • C-Q8: 如何對共用 API 實施多入口一致授權？
  • C-Q9: 如何設計安全預設與配置？
  • D-Q7: 共用頁面/多入口授權不一致漏洞？
  • D-Q10: 授權規則矛盾導致不可預期存取？