軟體架構圖是技術團隊的主要溝通工具。它彌補了抽象需求與具體實現之間的差距。然而，標準的架構圖通常僅關注功能與資料流。它經常忽略安全控制、信任邊界與威脅緩解策略等關鍵層面。當安全在設計階段被視為事後補救時，漏洞便在任何程式碼撰寫之前就已內建於系統之中。

C4模型透過一組層級圖表，提供了一種結構化的方法來記錄軟體架構。透過將安全考量整合至C4層級的每一層，架構師可以建立一種視覺化語言，明確傳達風險、合規性與保護機制。本指南探討如何在不依賴特定工具或供應商的情況下，將安全思維融入情境圖、容器圖、組件圖與程式碼圖中。

🔍 為何圖表中的安全可見性至關重要

安全通常在失效前都難以察覺。防火牆阻擋流量，加密混淆資料，驗證確認身份。這些機制至關重要，卻鮮少出現在標準設計文件中。當安全被隱藏時，審計變得困難，新成員難以理解，也難以應對不斷演變的威脅。

將安全融入架構圖中具有多項顯著優勢：

• 共識理解：安全團隊與開發團隊使用不同的語言。在與應用流程相同的圖表上呈現安全控制，能促使雙方理解一致。
• 威脅識別：圖表突顯資料流。每一條資料流都可能是潛在的攻擊向量。視覺化這些路徑，能更輕鬆地識別資料可能被暴露或遭竄改的位置。
• 合規審計：法規通常要求提供資料保護措施的證明。一張註解完善的架構圖，可作為設計階段安全控制的證據。
• 事件回應：在安全事件發生時，了解資料存放位置及其移動方式至關重要。圖表為隔離與修復提供了清晰的指引。

🏗️ C4模型層級概覽

C4模型是一種分層的軟體架構文件方法。它從整體視角逐步深入至實作細節。每一層針對不同受眾，提供不同程度的細節層級。在適當層級整合安全，可確保正確資訊傳達給正確的人。

1. 情境圖（第1層）：描述系統在其環境中的狀態。重點在使用者與外部系統。
2. 容器圖（第2層）：描述高階技術結構。顯示如網頁應用、行動應用與資料庫等軟體系統。
3. 組件圖（第3層）：描述單一容器的高階設計。顯示控制器、服務與儲存庫等構建模組。
4. 程式碼圖（第4層）：描述單一組件的實作。顯示類別與方法。此圖通常不會對外公開，但對內部安全審查至關重要。

🌍 第1層：情境圖安全

情境圖是起點。它定義了系統邊界。此層級的安全重點在信任邊界與身份認證。你必須明確區分信任範圍內與範圍外的內容。

🔑 身份與存取管理

在情境層級，最重要的安全要素是驗證。你必須清楚顯示哪些人被允許與系統互動。

• 人類角色：明確標示使用者。區分管理員與一般終端使用者。管理員存取通常需要更嚴格的控制。
• 外部系統： 這些通常是 weakest link。顯示它們如何進行身份驗證。它們是否使用 API 金鑰、OAuth 權杖或相互 TLS？
• 信任區域： 使用視覺提示來標示信任邊界。實線可能代表高信任度的內部連接，而虛線則代表低信任度的外部連接。

🔗 數據流安全

上下文圖中的每一條線都代表一個數據流。並非所有數據流都相同。有些傳輸敏感資訊，而其他則傳輸公開的狀態更新。

• 加密需求： 標記需要在傳輸中加密的數據流。使用如 HTTPS 或 WSS.
• 個人識別資訊處理： 如果資料包含個人識別資訊，請標記該數據流。這可確保下游團隊知道需採取額外保護措施。
• 身份驗證機制： 指出該數據流是否需要身份驗證。例如，Bearer Token 或 Session Cookie 身份驗證需求應標註在連接線上。

📦 第二層：容器圖安全

系統邊界確定後，容器圖會將其分解為可部署的單元。這正是技術安全控制變得可見的地方。容器通常為網頁應用、行動應用、微服務或資料庫。

🛡️ 網路安全與區域

容器通常分散於不同的網路區域。可視化這些區域有助於理解網路區段。

• DMZ 位置： 顯示哪些容器暴露於公眾網際網路。這些需要最高程度的審查。
• 內部服務： 顯示哪些容器僅限內部使用。這些不應直接暴露於網際網路。
• 防火牆規則： 使用顏色編碼或註解來標示哪些容器允許彼此通訊。這可防止在遭受入侵時發生横向移動。

🔐 靜態數據保護

容器通常會儲存資料。無論是資料庫、檔案儲存或訊息佇列，儲存媒介都需要安全性。

• 靜態加密：指出容器中儲存的資料是否已加密。這對於合規性至關重要。
• 金鑰管理：顯示加密金鑰儲存的位置。是由容器本身管理，還是由外部金鑰管理服務管理？
• 資料分類：根據容器所持有的資料敏感程度對其進行標籤。公開, 內部, 機密，或受限.

📡 協定安全

容器之間使用的協定決定了內部通訊的安全狀態。

• 內部 API：確保內部 API 不使用純文字 HTTP。以HTTPS或gRPC 搭配 mTLS.
• 服務網格：若使用服務網格，請指出容器之間的流量會自動加密並驗證。
• 舊式協定：若使用 FTP 或未加密 SMTP 等舊式協定，請標示為需要修復的風險區域。

⚙️ 第三級：組件圖安全

組件圖深入單一容器內部，顯示邏輯構建模塊。這正是安全邏輯的實現處。

🧩 認證與授權邏輯

安全邏輯通常分散在各個組件中。顯示此邏輯位於何處至關重要。

• 認證處理常式：識別負責使用者登入的組件。這些是攻擊者高度關注的目標。
• 授權中間件：顯示存取控制檢查發生的位置。是在控制器層級還是服務層級執行？
• 權杖驗證：標示驗證安全權杖的組件。如果此驗證是集中的，則可降低安全政策不一致的風險。

🛑 輸入驗證與清理

安全漏洞通常從錯誤的輸入開始。組件圖應突出顯示輸入被處理的位置。

• 入口點：標示接收外部資料的組件。這些是防禦注入攻擊的第一道防線。
• 清理邏輯：顯示負責在資料儲存或處理前進行清理的組件。這可防止 SQL 注入與跨站腳本攻擊。
• 輸出編碼：標示資料在發送給使用者前進行編碼的位置。這可確保惡意腳本不會在瀏覽器中執行。

📊 日誌記錄與監控

安全運作依賴日誌。若無法看見發生了什麼，就無法偵測到入侵。

• 安全日誌：識別產生與安全相關日誌的組件。範例包括登入失敗嘗試、權限拒絕以及設定變更。
• 日誌聚合：顯示日誌發送至的位置。是否發送到中央化日誌服務？這可確保組件遭入侵時日誌不會遺失。
• 敏感資料遮蔽：標示日誌是否經過清理，以防止憑證或敏感資料外洩。

🧠 第四層：程式碼圖安全

程式碼圖是層級最詳細的。它顯示類別與方法。雖然這通常不會在開發團隊之外分享，但對於深入的安全審查至關重要。

🔒 加密運算

在此層級，你可以清楚看見加密運算的使用方式。

• 硬編碼的秘密：檢查程式碼結構中是否存在硬編碼的 API 金鑰或密碼。這些應被標示為嚴重漏洞。
• 演算法使用：確認使用強大的演算法。應避免使用 MD5 或 SHA1 等弱演算法。
• 隨機數生成：確保為會話 ID 和權杖使用密碼學隨機數生成器。

🧪 安全性單元測試

安全需求必須經過測試。程式碼圖示可顯示安全測試的定義位置。

• 安全性測試案例：識別專門用於安全性測試的方法。這些測試應涵蓋認證繞過、注入攻擊和存取控制。
• 整合測試：展示安全控制在整個系統環境中是如何被測試的。

🚧 信任區域與邊界

在 C4 模型的所有層級中，信任區域都是一個反覆出現的主題。信任區域是指安全控制一致且邊界明確的區域。

區域類型	信任等級	典型控制措施	圖示表示
外部互聯網	零信任	防火牆、WAF、TLS	虛線紅色邊框
DMZ	低信任	嚴格過濾、有限存取	虛線橙色邊框
內部網路	中等信任	網路區段化、認證	實線藍色邊框
安全核心	高信任	加密、金鑰管理、審計	實心綠色邊框

將這些區域可視化有助於利益相關者理解系統不同部分的風險概況。DMZ 中的漏洞不應危及安全核心。此概念稱為深度防禦。

🧩 C4 中常見的安全模式

某些安全模式在各類架構中經常出現。明確記錄這些模式可節省時間並減少混淆。

🔑 API 網關模式

API 網關作為所有客戶端請求的單一入口點。它負責處理驗證、速率限制和路由。

• 位置： 它位於外部使用者與內部容器之間。
• 安全角色： 它將安全邏輯從單個服務中卸載，確保策略執行的一致性。
• 圖示注意事項： 使用「驗證/授權」標籤標記網關。

🔒 數據加密模式

數據必須在靜止狀態和傳輸過程中都受到保護。這是基本模式。

• 傳輸： 所有網路通訊均使用 TLS。
• 靜止： 加密資料庫和檔案儲存。
• 金鑰： 將金鑰與數據分開儲存。

👁️ 審計日誌模式

每項關鍵操作都應記錄日誌。這對於事後調查至關重要。

• 應記錄的內容： 使用者操作、系統變更和安全事件。
• 日誌完整性： 確保日誌不會被攻擊者篡改。
• 保留： 定義日誌保留的時間以符合合規要求。

🔄 維護與演進

安全不是一次性的任務。系統會演進，威脅會改變，新的漏洞也會被發現。架構圖必須隨著它們一起演進。

📅 更新圖示

當系統發生變更時，圖示應隨之更新。這確保了文件始終是真實資訊的來源。

• 變更控制： 將圖示更新整合至部署流程中。
• 審查週期： 與安全團隊安排定期審查架構圖。
• 版本控制： 保留圖示的版本，以追蹤安全控制措施隨時間的變化。

🧪 威脅建模整合

威脅建模是識別潛在安全威脅的過程。它與C4圖示相輔相成。

• STRIDE模型： 使用STRIDE模型（偽造、篡改、否認、資訊外洩、拒絕服務、權限提升）來審查圖示中的每個元件。
• 資料流分析： 走過圖示中的每一筆資料流。詢問資料是否在每一步都受到保護。
• 資產識別： 在圖示中識別高價值資產。將安全資源集中於保護這些資產。

📝 安全圖示檢查清單

使用此檢查清單，確保您的C4圖示具備安全準備就緒。

• [ ] 是否清楚標示信任邊界？
• [ ] 所有資料流是否都標示了傳輸中的加密？
• [ ] 儲存容器是否標示了靜態資料的加密？
• [ ] 認證點是否已標示？
• [ ] 是否突出顯示敏感資料流？
• [ ] 外部依賴是否已識別並評估？
• [ ] 網路區段與區域是否已視覺化？
• [ ] 是否顯示記錄與監控點？
• [ ] 已知漏洞是否已記錄？
• [ ] 圖表是否隨著程式碼變更而保持更新？

💡 安全可視化的最終想法

建立安全系統不僅僅需要撰寫安全的程式碼，更需要安全的設計。C4模型提供了一個強大的框架，用於可視化這種設計。透過將安全思維嵌入到每個層級，從情境圖到程式碼層級，團隊可以建立出預設具備韌性的系統。

安全是共同的責任。當圖表能清楚傳達安全控制措施時，開發人員、運營人員和安全工程師能更有效地協作。這種共享的可見性能降低風險，並增強對交付軟體的信心。請記住，圖表是一份活文件，應像其所代表的程式碼一樣受到同等重視。