軟體架構圖示是開發團隊的藍圖。它們傳達系統之間如何互動、資料流動的路徑，以及組件的結構方式。然而，標準的C4模型圖示通常缺少一個關鍵面向：安全性。若未視覺化安全邊界，架構師與開發人員可能無意間建立信任假設不清晰的系統，進而導致後期難以修復的漏洞。將安全邊界整合至C4容器圖示中，可確保風險管理在設計階段就已內嵌，而非事後才補上。
本指南探討如何在C4模型框架內有效呈現安全控制、信任區域與資料保護機制。透過遵循既定的規範，團隊可建立不僅結構清晰，且具備安全意識的圖示。此方法有助於提升安全工程師、開發人員與業務利害關係人之間的溝通效率。
🏗️ 安全性的C4模型背景
C4模型提供了一種層級化的軟體架構文件記錄方式。它包含四個層級：系統上下文、容器、組件與程式碼。針對安全性的視覺化，容器層級通常是最重要的層級。此層級呈現高階的軟體構建模塊，例如網頁應用程式、行動應用程式、API與資料庫。
引入安全邊界時，目標在於明確指出信任的終點與不受信任環境的起點。若容器圖示缺乏安全背景，可能僅顯示系統A與系統B通訊，卻無法揭示該連線是否加密、經過驗證，或穿越公開網路。加入安全邊界可彌補此資訊缺口。
- 第1層（系統上下文）：有助於識別外部依賴關係，以及您的系統與使用者或第三方之間的高階信任關係。
- 第2層（容器）：本指南的主要焦點。在此層級，您定義內部區域、網路區段與資料分類等級。
- 第3層（組件）：可用於呈現詳細的安全邏輯，例如驗證模組，但通常過於細節，不適合高階安全審查。
透過專注於容器層級，架構師可在抽象與細節之間取得平衡。這確保安全決策清晰可見，又不會因過多實作細節而使圖示過於混雜。
🧱 定義安全邊界
安全邊界代表信任關係發生變化的邊界。穿越邊界需具備特定控制措施，例如驗證、授權或加密。在圖示中，這些邊界將具有相同安全態勢或位於同一網路區段的容器歸為一組。
邊界的類型
理解不同類型的邊界，有助於選擇正確的視覺化呈現方式：
- 網路邊界：區分內部私有網路、公開網際網路存取，以及如DMZ（非軍事區）等隔離環境。
- 信任區域：區分完全信任的內部服務與部分信任的外部介面。
- 資料分類：將處理敏感資料（個人識別資訊、財務紀錄）的容器，與公開服務分開歸類。
- 合規區域：根據法規要求分離系統，例如需符合GDPR的系統，與一般運營工具之間的區分。
信任與資料流動
安全性根本上是關於信任。容器之間的每一項連接都隱含著信任關係。若容器A將資料傳送給容器B，代表A信任B能正確處理該資料。若B遭入侵，A便面臨風險。
視覺化這種信任至關重要。C4圖示中的箭頭代表資料流動，但也應暗示信任方向。邊界線表示穿越它需進行安全檢查。例如，從「公開區域到內部區域應觸發驗證步驟。
🎨 在容器圖中可視化邊界
視覺語言的一致性是有效文檔的關鍵。繪製安全邊界時，符號應直觀易懂。雖然沒有單一的通用標準，但業界已形成一些在C4模型中運作良好的慣例。
符號標準
大多數用於創建C4圖的工具都支援自訂形狀和樣式。為表示安全邊界，請考慮以下標準做法：
- 虛線：使用虛線包圍一組容器。這表示邏輯分組，而非實體牆壁。
- 陰影區域：淺色背景可表示一個區域。例如，淺紅色背景可能表示高風險的公開區域，而綠色則表示受信任的內部區域。
- 圖示：在邊界標籤旁添加一個小鎖或盾牌圖示，以表示安全控制已啟用。
- 標籤：明確命名邊界。使用以下術語：公開網路, 安全區域，或DMZ.
色彩編碼策略
色彩是一種強大的信號。然而，必須有目的地使用。避免隨意使用顏色。相反，應將顏色與安全狀態對應：
- 紅色/橙色：高風險，面向公眾，不可信的輸入來源。
- 黃色：中等風險，DMZ，或半受信任的介面。
- 綠色/藍色：低風險，內部，受信任的服務。
- 灰色：需要小心處理的舊系統或已棄用的組件。
確保顏色選擇具有可訪問性。除了顏色之外，還應使用圖案或標籤，以確保色覺缺陷的使用者也能讀懂圖示。
🔒 在圖示中實施安全控制
劃定邊界後，下一步是標註穿越這些邊界的連接。一條穿越安全邊界的線是一次安全事件，需要特定的控制措施。
加密與協定
用所使用的協定標註連接。這可讓讀者了解傳輸中資料的安全狀態。
- HTTPS/TLS：網頁流量的標準。若相關，請標示版本（例如 TLS 1.3）。
- mTLS：相互 TLS 在微服務架構中很常見。這表示強大的身份驗證。
- SSH： 用於管理存取或內部檔案傳輸。
- 未加密： 明確標註任何未加密的流量。這突顯出需要修復的風險。
認證與授權
使用者在哪裡進行認證？哪個服務驗證憑證？這些問題應能從圖示中獲得解答。
- API 網關： 通常作為進入點。標示它們為認證發生的邊界。
- OAuth/SSO： 展示使用者、網關與後端服務之間的憑證流動。
- 服務帳戶： 指出服務是否使用機器身份而非使用者憑證進行認證。
🔄 常見的架構模式
某些架構模式在現代軟體系統中經常出現。這些模式具有特定的安全邊界考量。
1. DMZ 模式
非軍事區位於公眾互聯網與內部網路之間。它托管必須對外可存取但不應直接存取敏感資料的組件。
- 邊界： 將網頁伺服器或負載平衡器封閉在 DMZ 區域內。
- 連接： DMZ 透過受限的埠或 API 端點與內部區域通訊。
- 安全目標： 若面向公眾的元件遭到入侵，限制影響範圍。
2. 使用服務網格的微服務
在微服務架構中，服務之間經常互相通訊。服務網格負責流量管理與安全性。
- 邊界： 每個服務都是獨立的容器。網格建立邏輯覆蓋層。
- 連線： 所有內部流量均經過加密（mTLS）。
- 安全目標： 零信任。每個服務都必須驗證其他每個服務。
3. 資料庫區隔
並非所有資料庫都應同等對待。敏感資料儲存應予以隔離。
- 邊界： 將敏感資料庫放置於專用子網或安全區域中。
- 連線： 僅特定的應用程式容器可連線至資料庫。
- 安全目標： 防止水平移動。若應用程式容器遭入侵，攻擊者無法直接存取資料庫。
📊 安全審查清單
在最終確定圖示前，執行安全審查。使用以下清單，確保所有必要的邊界與控制措施均已被呈現。
| 檢查項目 | 標準 | 為何重要 |
|---|---|---|
| 信任區域已定義 | 是否所有容器均已分配至信任區域？ | 明確指出需要安全控制的位置。 |
| 連線標籤 | 協定與加密方法是否已標示？ | 確保傳輸中的資料安全。 |
| 驗證點 | 驗證的入口是否明確？ | 識別存取控制發生的位置。 |
| 資料分類 | 敏感資料儲存是否已分離？ | 保護高價值資產。 |
| 外部依賴 | 第三方服務是否已標示？ | 突顯供應鏈風險。 |
| 管理員存取 | 管理員存取是否受到限制？ | 防止未經授權的系統控制。 |
此表格在程式碼審查或架構決策紀錄（ADRs）期間可作為快速參考。確保在設計階段不會忽略安全性。
⚠️ 安全反模式
避免錯誤與遵循最佳實務同等重要。以下反模式經常出現在缺乏安全邊界的圖示中。
- 平面圖示：將所有容器繪製在同一個框內而無區塊區分。這表示所有元件都受到同等信任，但這幾乎從未成立。
- 缺少加密標籤： 顯示箭頭但未明確標示 HTTPS。這會導致資料保護方式產生歧義。
- 過度信任： 將面向公眾的容器直接連接至資料庫容器，中間未設置任何中介。這是典型的漏洞向量。
- 靜態邊界： 當基礎架構變更時未更新圖示。顯示舊網路拓撲的圖示，甚至比沒有圖示更糟糕。
- 忽略資料流： 僅關注靜態結構，忽略資料如何跨越邊界流動。安全性是動態的。
📈 維護與演進
安全邊界並非靜態。隨著系統演進，新增服務，威脅亦會改變。圖示必須隨之演進。將圖示視為活文件，對長期安全至關重要。
版本控制
將圖示與程式碼一同儲存在版本控制中。這讓團隊能追蹤安全邊界隨時間的變動。當發生安全事件時，檢視圖示歷史可發現邊界是否遺漏或設定錯誤。
自動化生成
在可能的情況下，從代碼或基礎設施即代碼配置生成圖表。這可以縮小文檔與實際系統之間的差距。如果基礎設施發生變更，圖表會自動更新，確保安全邊界始終準確。
定期審計
安排定期審查架構圖表。在這些審查過程中，提出具體的安全問題：
- 是否新增了跨越邊界的依賴關係？
- 加密標準是否仍然最新？
- 信任區域是否仍然與當前的網絡拓撲一致？
- 是否存在應當移除以減少攻擊面的未使用容器？
🔍 結論
將安全邊界整合到C4容器圖表中，可使它們從簡單的結構地圖轉變為全面的安全指南。這種做法明確了信任關係，突出了數據保護要求，並促進了跨團隊之間更好的溝通。通過遵循一致的符號表示、標籤協議，並長期維護圖表，組織能夠建立更具彈性的系統。
安全不是一個產品；而是一個過程。圖表是這個過程中的工具。它們使看不見的變得可見，讓架構師能在風險演變為事件之前識別它們。投入時間製作準確且以安全為導向的文檔，將在降低漏洞風險和加快事件響應方面帶來回報。
從審計您當前的圖表開始。識別信任邊界缺失的位置。添加必要的區域、標籤和顏色。隨著時間推移，這種習慣將變得自然而然，將安全融入您描述架構時所使用的語言之中。