安全在系統設計中不是事後補救；它是基礎支柱。當架構師與開發人員規劃系統中不同組件之間的互動時，他們通常專注於功能。然而，安全層——特別是驗證——需要同等重視。通訊圖為這些互動提供了清晰的視覺語言。透過將安全流程整合到這些圖表中，團隊能共同理解信任建立的位置、憑證如何處理，以及潛在漏洞可能出現的地方。
📊 為什麼要視覺化安全？
圖表是設計與實作之間的契約。當驗證流程被明確繪製時，會產生多項好處。首先，它突顯信任邊界。其次，它確保每次資料交換都經過仔細審查，以確認是否包含敏感資訊。第三，它有助於識別驗證邏輯中的漏洞。若缺乏視覺化呈現，安全需求可能被埋藏在文件中，導致實作錯誤。
🛡️ 理解信任邊界
通訊圖本質上是資料流動的地圖。要保護這張地圖，必須明確界定信任的起點與終點。信任邊界代表安全領域的邊界。任何跨越邊界的訊息都必須經過驗證或授權檢查。
- 內部邊界：同一安全區域內服務之間的通訊。這類通訊可能需要雙向驗證，但驗證要求較為寬鬆。
- 外部邊界：從公開網路跨越至私人伺服器的通訊。這類通訊需要嚴格的驗證、加密與輸入驗證。
- 第三方邊界：與外部系統的互動。這類互動通常涉及委託驗證流程。
繪製圖表時，應使用明顯的視覺提示來區分這些區域。這種視覺區隔迫使設計者問：「這則訊息是否需要安全金鑰？」如果答案是肯定的，圖表必須顯示金鑰交換的過程。
🔑 流程中的驗證機制
不同系統需要不同的方法來驗證身份。通訊圖應反映每次互動所使用的具體機制。通用的線條經常隱藏關鍵的安全邏輯。
1. 基本憑證交換
在較簡單的系統中，客戶端可能直接將使用者名稱和密碼傳送至驗證服務。此流程簡單明瞭，但在傳輸過程中需嚴格加密。
- 客戶端：發起登入請求。
- 驗證服務：對照資料庫驗證憑證。
- 客戶端：接收會話金鑰。
此流程適用於初次登入，但不應在每次後續操作中重複。圖表應顯示從憑證提交到金鑰接收的轉換過程。
2. 基於金鑰的驗證
現代架構通常依賴無狀態金鑰。客戶端在成功驗證後接收金鑰，並在後續請求中包含該金鑰。
- 請求標頭： 憑證是在特定的標頭欄位中傳遞的。
- 驗證： 接收服務會驗證憑證簽章。
- 失效： 服務會檢查憑證是否仍然有效。
可視化此過程需要顯示憑證從驗證服務傳遞到客戶端，再由客戶端傳遞到應用程式服務。這清楚表明應用程式服務不處理密碼，僅處理憑證。
3. 相互驗證
在高安全性環境中，雙方都必須證明其身份。這在服務對服務通訊中很常見。
- 憑證交換： 雙方都出示數位憑證。
- 金鑰驗證： 雙方各自驗證對方的金鑰。
- 會話建立： 只有在驗證完成後，才會開啟安全通道。
在圖示中，這需要在實際資料載荷傳輸前顯示雙向握手機制。這為互動的安全敘事增添了深度。
🔄 可視化憑證交換流程
憑證的流動是驗證圖示中最關鍵的部分。如果憑證的產生或驗證不清晰，系統容易遭受攻擊。
登入流程
從客戶端傳送憑證開始。不要將憑證繪製為純文字。應標示其為加密或雜湊過的資料。
- 步驟 1： 客戶端傳送
POST /login搭載加密的資料載荷。 - 步驟 2： 伺服器對照身份資料儲存庫進行驗證。
- 步驟 3： 伺服器產生一個唯一的憑證。
- 步驟 4： 伺服器將憑證回傳給客戶端。
將回傳訊息標示為 “「發行令牌」這表示密碼已不再系統中。
重新整理序列
令牌會過期。圖示必須顯示如何在不重新輸入憑證的情況下取得新令牌。
- 步驟 1：客戶端檢測到令牌過期。
- 步驟 2：客戶端將重新整理令牌傳送至驗證服務。
- 步驟 3：驗證服務驗證重新整理令牌。
- 步驟 4：驗證服務發行新的存取令牌。
此流程可防止使用者頻繁登出，同時維持安全性。在圖示中，請以不同的標籤或顏色區分存取令牌與重新整理令牌使用不同的標籤或顏色。
登出序列
安全性也包含終止。圖示應顯示如何使會話失效。
- 步驟 1：客戶端以目前的令牌傳送登出請求。
- 步驟 2：伺服器在會話儲存中標記該令牌為無效。
- 步驟 3：伺服器確認登出。
若缺少此步驟，竊取的令牌可能永遠有效。此圖示作為提醒，必須實作此清理邏輯。
📊 消息類型與安全影響
並非通訊圖示中的所有訊息都相同。有些攜帶敏感資料，而其他則為例行訊息。下表概述常見訊息類型及其安全需求。
| 訊息類型 | 安全需求 | 圖示符號 |
|---|---|---|
| 驗證請求 | 加密，輸入驗證 | 標籤：加密載荷 |
| 金鑰發放 | 安全通道，簽名 | 標籤：安全金鑰 |
| 資料檢索 | 授權檢查 | 標籤：需要驗證 |
| 設定更新 | 權限提升檢查 | 標籤：僅限管理員 |
| 記錄事件 | 清理（無個人識別資訊） | 標籤：已清理的日誌 |
在您的圖示中使用這些標籤，可為審查者建立快速參考。這迫使團隊思考哪些資料正在傳輸，以及是否受到保護。
🚫 錯誤處理與安全警告
安全性通常在失敗時受到測試。一個穩健的圖示應包含錯誤路徑。如果驗證嘗試失敗，系統不應透露過多資訊。
通用錯誤訊息
登入失敗時，圖示應顯示通用回應。不要表明是使用者名稱還是密碼錯誤。
- 錯誤：「使用者名稱未找到」。
- 正確：「憑證無效」。
這可防止攻擊者枚舉有效的使用者名稱。在圖示中，請明確標示錯誤回應，以確保開發人員不會意外暴露特定的錯誤代碼。
速率限制
暴力破解攻擊很常見。圖示應標示出速率限制發生的位置。
- 位置： 在 API 網關或驗證服務中。
- 動作： 在 N 次嘗試後阻止請求。
- 回應： 回傳通用延遲或錯誤。
顯示此流程有助於開發人員理解系統已受到自動化攻擊的保護。請為速率限制觸發點繪製一條側邊路徑。
🛠️ 繪製安全圖示的最佳實務
為保持清晰與準確，請在為您的通訊圖示加入安全元素時遵循以下指南。
- 一致的符號： 為安全元素定義圖例。為權杖、憑證和加密通道使用特定的形狀或顏色。
- 層級分離： 不要將安全流程與業務邏輯流程混合。應保持分離但相互連結。
- 專注於資料流： 展示敏感資料進入和離開的位置。強調資料的轉換（例如，雜湊、加密）。
- 包含逾時： 安全性通常取決於時間。在相關處顯示會話逾時和權杖到期時間。
- 定期審查： 隨著系統的演進，更新圖示。過時的安全圖示會導致過時的安全做法。
🧩 應避免的常見陷阱
即使經驗豐富的設計師在呈現安全架構時也會犯錯。請留意這些常見錯誤。
1. 隱藏權杖
有些圖示僅將權杖顯示為虛線。這會掩蓋權杖是必須保護的關鍵資料的事實。
- 解決方案： 將權杖繪製為帶有標籤的特定物件。
2. 忽略網路層
圖示可能只顯示應用層，卻忽略傳輸層。傳輸層（TLS）的加密至關重要。
- 解決方案：添加註釋，指出所有通訊均使用加密傳輸。
3. 假設隱式信任
內部服務通常假設自身是安全的。然而，即使內部服務被攻破，仍可能竊取憑證。
- 解決方案：將所有內部通訊視為可能具有敵意。驗證身份。
4. 視圖過於複雜
添加過多的安全細節會導致圖示難以閱讀。應專注於關鍵路徑。
- 解決方案：為高階流程與詳細的安全握手使用獨立的圖示。
📝 詳細場景：API 網關互動
考慮一個 API 網關處理入站請求的場景。此組件是第一道防線。圖示應顯示網關與驗證服務的互動。
- 客戶端請求：客戶端向網關發送請求。
- 憑證提取：網關從標頭中提取憑證。
- 驗證：網關調用驗證服務以驗證憑證。
- 轉發：若憑證有效，網關將請求轉發至後端服務。
- 拒絕：若憑證無效，網關返回 401 未授權響應。
此流程集中了安全邏輯。後端服務無需自行驗證憑證；它們信任網關。這可減少程式碼重複與潛在的安全漏洞。
📝 詳細場景：會話狀態管理
某些系統依賴伺服器端會話。圖示必須顯示與會話儲存的互動。
- 登入：使用者提供憑證。
- 會話建立：伺服器建立會話 ID 並儲存。
- 請求： 客戶端在後續請求中發送會話 ID。
- 驗證： 伺服器在儲存中查找會話 ID。
- 失效： 登出時，伺服器刪除會話。
確保會話儲存被顯示為一個獨立組件。這突顯了系統的狀態性以及保護儲存媒介的必要性。
🔍 安全圖示審查清單
在最終確定圖示之前，請逐一核對此清單，以確保安全特性得到充分體現。
- ✅ 所有外部邊界是否都明確標示？
- ✅ 是否為敏感資料標示了加密？
- ✅ 認證令牌是否以獨立物件顯示？
- ✅ 錯誤回應是否為通用且不透露資訊？
- ✅ 是否有登出或會話終止流程？
- ✅ 是否顯示了速率限制或流量控制機制？
- ✅ 每個服務的信任邊界是否已定義？
- ✅ 憑證是否從未以明文顯示？
🧠 將安全融入設計流程
安全圖示不應孤立創建。它們必須是迭代設計流程的一部分。在初期腦力激盪階段，繪製基本流程。在設計審查階段，加入安全層級。在實施階段，圖示可作為編碼標準的參考。
這種方法確保安全特性被融入系統的結構中，而非作為補丁添加。同時也促進了安全工程師與應用開發人員之間的溝通。當兩支團隊查看同一張圖示時，他們便擁有共同的語言。
🔎 文件的作用
圖示的價值取決於其附帶的文件。圖示展示的是「什麼」和「在哪裡」，而文件則解釋了「為什麼」和「如何」。
- 協定規範： 提供所使用協定標準的連結（例如：OAuth 2.0、OIDC）。
- 加密演算法： 指定雜湊演算法與加密套件。
- 金鑰管理： 描述金鑰如何儲存與輪換。
- 事件回應： 概述當令牌被竊取時應採取的措施。
將視覺流程與文字細節結合，可建立穩健的安全規格。這能減少歧義，並確保系統不同部分的實現一致。
🎯 最終想法
安全是一個持續的驗證與改進過程。通訊圖表是此過程中的強大工具。它們讓團隊能夠視覺化複雜的互動，並在撰寫程式碼之前識別潛在的弱點。透過專注於驗證流程、信任邊界與錯誤處理，架構師可以建立具備抗攻擊能力的系統。
請記住，圖表是一份活文件。隨著威脅的演變，其所代表的安全模型也應隨之更新。定期審查與更新可確保系統與最新的安全標準保持一致。運用圖表的視覺語言，讓安全變得透明、易於理解，並對專案中所有參與者都具備可操作性。
🛡️ 主要重點摘要
- 視覺化信任：明確標示信任邊界所在的位置。
- 顯示權杖：將驗證權杖視為關鍵的資料物件。
- 規劃錯誤：確保錯誤路徑不會洩漏資訊。
- 分離關注點：讓安全流程與業務邏輯保持分離。
- 徹底文件化：以詳細的安全規格來支援圖表。
遵循這些原則，團隊可以建立不僅僅展示資料流動，更能展現安全狀態的通訊圖表。這種清晰度對於在日益連結的世界中建立值得信賴的軟體系統至關重要。