[架構師觀點] 資安沒有捷徑，請從根本做起!
摘要提示
- 品質優先: 資安屬於品質要求而非功能需求，需在設計階段內建，無法靠事後測試補救。
- 正確心態: 技術決策者需以法規與信任為底線看待資安，不能把它當成可裁減的需求規格。
- 密碼處理: 密碼應以加鹽雜湊儲存，驗證靠比對雜湊而非還原密碼，從根本消弭外洩風險。
- 信任與加密: 使用公開、經驗證的演算法與足夠金鑰強度，安全性來自金鑰保護而非程式保密。
- 土炮風險: 自行發明加密或權限機制易有漏洞（統計學、程式碼可見性），不可取。
- JWT與Session: 分散式認證可用簽章與Token減少通訊，但每次請求仍須嚴格驗證Token。
- 安全成本: 驗證帶來運算成本但可大幅減少網路往返，屬必要支出。
- 授權控管: 權限需以全域規範與成熟模型（RBAC/PBAC/ABAC）統一管理，避免「老鼠屎」漏洞。
- 接觸面控管: 收斂API介面、統一身分識別與授權檢核，降低資料外洩面積。
- 架構原則: 少標新立異，善用標準框架與設計樣式，將品質內建於系統。
全文重點
本文從近期資安事件與密碼儲存爭議切入，闡述資安的本質不屬於一般功能需求，而是品質與信任層面的要求。功能需求著重正向表列的驗收案例；品質要求則以負向表列避免不當行為為核心，需抵禦未知的極端情境，難以事後補救，必須從設計源頭正確決策。以密碼為例，正確做法是只儲存加鹽後的雜湊，驗證時比對雜湊值，不保存、不可還原，才能在資料庫外洩時依然確保使用者密碼安全。能「保證」安全的關鍵不在於測試清單，而在設計流程中落實正確處理方式。
資安是信任問題。對密碼、信用卡、交易與個資等重要資訊，唯有做「對的事」並可被驗證，外界才可能信任。例如不儲存密碼可消除因資料庫外洩導致的密碼外洩；以金鑰簽署交易和資訊可確保不可冒名。這些保障基於公開演算法與金鑰管理：公開演算法的安全性來自數學證明與金鑰強度，自己發明的加密法往往缺乏驗證、易被統計或流程弱點破解。另外，指望程式碼不被看到來達到安全是錯誤的，現代軟體工程強調可讀性與可維護性，安全應建立在金鑰與協定上，而非「祕密程式碼」。
在分散式系統的認證場景，JWT等標準可在減少跨服務通訊的同時維持安全，但前提是每次請求都要驗證簽章與有效期，才能信任Token中的身分與權限資訊。這如同驗票防偽：列車長靠票面防偽即時判定，而不是每次回溯售票端查驗。雖然簽章驗證增加CPU成本，卻能節省昂貴的網路往返，是必要且划算的安全投資。
授權方面，最大的風險來自分散在各功能中的「自製」檢核與特例，任何一處遺漏都會使整體失守。應建立全域一致的授權規範與模型（如RBAC、PBAC、ABAC），用標準框架統一實作；以模組層級定義通用規則，避免各頁面與API自行解讀。工程上要收斂外部接觸面、統一身分識別（例如以Token貫穿）、並在所有入口一致地做授權判斷，確保「你是誰」與「你能做什麼」始終被正確檢核。
最後，作者強調品質是內建的，不是測試出來的。資安與品質、架構類問題一律沒有捷徑，若在時程壓力下削弱安全設計，只是把風險延後，未來將付出更高代價。應避免標新立異，盡量採用成熟框架與公認模式；若必須自建，也要遵循標準化設計樣式，把安全與品質從系統根部做對，才能換來長期可靠與市場信任。
段落重點
功能需求 vs 品質要求
作者區分功能需求與品質要求：功能偏向正向表列的驗收清單，只需通過已知案例；品質則以負向表列為主，需確保不出現未授權資料揭露、未處理例外等不當行為，並能在壓力、攻擊與滲透下仍正常運作。品質難在驗證與修改成本高，往往在設計階段未妥善處理就埋下難以補救的坑。密碼儲存屬於品質要求，其目的在於即使資料庫外洩也不會泄露密碼；正確做法是只存加鹽雜湊並以雜湊比對進行驗證，讓系統根本不持有可還原的密碼，從設計上切斷外洩風險。這種保障源自正確設計，而非測試規格擺上幾條案例就能達成。
資安，是信任問題，你必須做 “對的事” 才能換來信任
資安的核心是信任，涉及密碼、金鑰、交易、個資等關鍵資訊的正確處置。只要做到「不保存密碼」、「以金鑰簽章與驗證身分」、「雙方各自妥善保管金鑰」，便能在不可信網路上建立可信互動。公開演算法之所以可信，因其安全性來自金鑰強度與數學基礎，可透過足夠金鑰長度對抗現今計算能力；反觀自製土炮加密既缺理論支撐，也易遭統計與行為分析攻破。將安全建立在程式碼不可見上也站不住腳，因團隊協作必然需要可讀可維護的程式碼。正確之道是按標準選擇演算法與金鑰管理，不在安全程序上「節省」，否則短視近利終將損害信譽。
其他資安案例: 登入 session (認證)
分散式環境下的Session管理是常見難題。使用者通過A服務驗證後，如何讓B服務信任該身分？若每次都向A查詢，通訊成本高昂；因此以JWT等標準透過簽章、到期時間與宣告內容（claims）實現跨服務信任，將網路往返換成本地計算。然而，使用JWT並不代表可以省略驗證：每次請求仍須驗證簽章與有效期，確認Token未被竄改，內容才可信。作者以驗票類比：列車長依票面防偽即時判斷票證真偽，而非回溯售票端查核。雖然簽章驗證會增加CPU負擔，但整體上比跨網路查核更有效率，且能消除安全死角，是必要投入。
其他案例: 功能的權限管控 (授權)
授權控管是資安大地雷。若僅在UI或入口頁檢查權限，或讓各功能各自實作，任一處疏漏都會導致整體失守（例如一頁面忘檢查就洩露全站資料）。解方是建立全域一致的安全規則，避免讓規格允許互相矛盾的權限組合；並儘量採用成熟模型如RBAC、PBAC、ABAC，或平台內建Authorization機制。授權規範宜在模組層級定義通用準則，減少例外並提升一致性。工程實務上需收斂API接觸面、統一身分識別（如用Session Token貫穿）、結合授權模型在每個入口一致執行檢核，確保「身分」與「行為」皆被正確判定，避免共用資源引出的權限繞過。
結論: 沒有捷徑，老老實實的實作才是上策
作者總結：品質是內建的，不是測試出來的。資安、品質與架構議題沒有捷徑，只能在設計與實作初期把基本功做好；在時程壓力下削減品質投入，只是把風險延後，最終付出更高代價。應儘可能採用標準框架、經驗證的模式與公開演算法，避免自創不成熟的安全機制；若必須自建，也要遵循公認的設計樣式與模式，將安全與品質當作系統基礎的一部分，藉由正確的工程方法與團隊文化，換取長期穩健與市場信任。
資訊整理
知識架構圖
- 前置知識：學習本主題前需要掌握什麼？
- 基本軟體工程概念：功能需求 vs 非功能/品質需求
- 加密與雜湊基礎：對稱/非對稱加密、Hash、Salt、數位簽章
- 驗證與授權：Authentication vs Authorization、Session/Token（如 JWT）
- 常見授權模型：RBAC、PBAC、ABAC 的差異
- 分散式系統基礎：跨服務通訊成本、攻擊面與接觸面積
- 核心概念：本文的 3-5 個核心概念及其關係
- 資安是品質要求不是功能需求：需在設計階段內建，非事後補救
- 信任建立於「做對的事」：採用經驗證的標準演算法與流程，而非土炮
- 密碼與金鑰管理為根本：密碼只存加鹽雜湊；安全性依賴金鑰保護與長度
- 分散式認證與授權要一致：以 token（如 JWT）+ 全域授權規範，統一身份與權限判斷
- 沒有捷徑：在每個請求與每個資料出入口落實驗證、授權、最小暴露面
- 技術依賴：相關技術之間的依賴關係
- 公開加解密演算法/雜湊（RSA、SHA-2/3、HMAC）→ 依賴金鑰與金鑰長度 → 依賴安全的金鑰管理/儲存
- Session/Token（JWT）→ 依賴簽章驗證與到期時間驗證 → 依賴每個請求的中介層驗證
- 授權決策（RBAC/PBAC/ABAC）→ 依賴可靠的身份識別（token）→ 依賴統一的授權中樞/策略
- API/頁面輸出 → 依賴統一的授權規範與共用程式庫 → 降低功能各自為政造成的漏洞
- 應用場景：適用於哪些實際場景？
- 儲存使用者憑證與登入流程的 Web/行動服務
- 微服務/分散式架構的跨服務認證、授權
- 處理敏感資料（密碼、個資、金流、交易）的系統
- 專案外包或高時程壓力情境下的資安基線落實
- 需要標準化治理（企業級平台、SaaS）的安全管控
學習路徑建議
- 入門者路徑：零基礎如何開始？
- 了解功能 vs 品質（非功能）需求差異與對測試/驗收的影響
- 學會正確儲存密碼：Salt + Hash（如 bcrypt/scrypt/Argon2），永不儲存可還原密碼
- 認識加密 vs 雜湊 vs 簽章差異，使用成熟套件，不自造演算法
- 以框架中介層加入 JWT 驗簽與過期檢查，練習每請求驗證
- 初步認識 RBAC，將權限檢查放在 API 層而非僅 UI
- 進階者路徑：已有基礎如何深化？
- 導入全域安全規範與策略（PBAC/ABAC），減少特例與灰色地帶
- 實作金鑰管理流程：金鑰輪替、權限分離、Secrets 管理（Vault/KMS）
- 設計跨服務認證授權：集中授權決策、共用 token 驗證元件
- 風險導向測試：滲透測試、錯誤處理一致性、未授權資料存取防護
- 性能與安全權衡：以運算換通訊，評估驗簽成本與快取策略
- 實戰路徑：如何應用到實際專案？
- 重構密碼流程：替換為 Argon2/bcrypt + per-user salt，導入密碼升級機制
- 在 API Gateway/服務加入 JWT 驗簽與要求範圍（scope/claims）檢查
- 建立統一授權策略層（RBAC → PBAC/ABAC），封裝為共用元件
- 縮減攻擊面：集中資料輸出通道、最小權限、白名單輸出
- 監控與稽核：記錄授權決策、token 驗證失敗率、異常存取告警
關鍵要點清單
- 資安屬於品質要求：需在設計階段內建，不能只當功能規格勾選 (優先級: 高)
- 密碼永不可還原儲存：只存 Salt + Hash（Argon2/bcrypt/scrypt） (優先級: 高)
- 使用公開驗證過的演算法：安全性來自金鑰與實作標準，而非隱藏演算法 (優先級: 高)
- 金鑰管理是核心：妥善保管、權限分離、輪替與長度選擇決定安全上限 (優先級: 高)
- 每請求驗證 token：JWT 驗簽與過期檢查不可省，運算成本換取安全 (優先級: 高)
- 分散式認證/授權一致性：統一身份識別與授權規則，避免服務各自為政 (優先級: 高)
- 授權做在後端/API：不要只靠 UI 或選單隱藏，避免繞過 (優先級: 高)
- 建立全域安全規範：採用 RBAC/PBAC/ABAC，減少特例與矛盾規格 (優先級: 中)
- 縮小接觸面積：集中出入口、共用安全中介層，降低攻擊面 (優先級: 中)
- 不自造安全輪子：避免土炮加密/授權，使用成熟框架與標準 (優先級: 高)
- 以演算法+金鑰保證信任：數位簽章可驗真偽與完整性，避免假冒 (優先級: 中)
- 以運算取代通訊開銷：本地驗簽優於跨服務查詢，性能/安全更均衡 (優先級: 中)
- 測試找缺點、品質需內建：僅修缺陷無法得到高品質，需要設計到位 (優先級: 中)
- 權限規則通用化：以可重複檢驗的規則覆蓋共用頁面/API，避免遺漏 (優先級: 中)
- 文化與治理重要：一次嚴重疏失影響信任，顯示團隊安全文化薄弱 (優先級: 中)
