設計穩健的軟體系統不僅需要功能性邏輯，更需要以安全為基礎。當架構師視覺化基礎設施時，會使用UML部署圖來規劃硬體、軟體與通訊路徑。然而，標準圖表經常忽略保護所必需的關鍵安全層級。將安全考量直接整合至部署模型中，可確保在設計階段就識別出漏洞，而非等到生產階段才發現。
本指南探討如何將安全控制、信任邊界與合規要求嵌入UML部署建模中。透過將安全視為架構圖中的首要考量，團隊可從一開始就建構出具備抗威脅能力的系統。
🏗️ 理解部署環境
UML部署圖代表系統的物理架構。它呈現實體、節點以及它們之間的連接關係。若無安全註解，此視圖僅為純結構性。要使其具備安全性，必須理解各組成元件：
- 節點： 這些代表實體或虛擬的運算資源，例如伺服器、路由器或雲端實例。
- 實體： 這些是實體資訊，例如可執行程式碼、資料檔案或程式庫。
- 通訊路徑： 允許節點交換資料的網路連結。
在建模這些元件時，必須為每個節點應用安全背景。僅使用通用伺服器節點是不夠的。模型應區分公開面對的Web伺服器與內部資料庫伺服器。兩者的差異在於各自所需的安全部署策略。
🔒 保護節點與硬體
節點是軟體執行的實體或虛擬端點。在以安全為導向的模型中，每個節點都需具備關於強化與存取控制的特定屬性。
實體與邏輯節點
部署模型經常將實體硬體與邏輯實例混淆。安全建模必須將二者區分：
- 實體節點： 這些代表實際硬體，例如伺服器或物聯網裝置。安全考量包括實體存取控制、防篡改設計與環境控制。
- 邏輯節點： 這些代表虛擬機器、容器或雲端函數。此處的安全考量著重於隔離、虛擬化管理程式安全與執行時期環境。
硬體安全模組（HSM）
關鍵系統通常依賴專用硬體進行加密運算。在圖中，這些應明確建模為專用節點，以強調金鑰管理並非發生在軟體記憶體中，而是位於安全的硬體邊界內。
伺服器強化狀態
每個伺服器節點都應攜帶關於其安全設定的元資料，包括：
- 作業系統版本與補丁等級。
- 節點上啟用的防火牆規則。
- 防毒軟體或終端保護狀態。
- 啟用的記錄功能，以供稽核追蹤。
透過標註這些細節，架構師可確保最終基礎設施中無任何節點被遺漏更新或監控。
💾 保護實體與資料儲存
物件是部署到節點的檔案和組件。並非所有物件都具有相同的風險特徵。有些包含敏感資料，而其他則是公開的程式庫。安全建模需要根據敏感性和完整性要求來區分這些物件。
資料分類
部署模型中的資料儲存必須根據分類等級進行標記。常見的分類包括：
- 公開：僅確保可用性，無其他安全控制措施。
- 內部：僅可在組織內部網路中存取。
- 機密：需要加密與嚴格的存取控制。
- 限制：高度敏感的資料，須符合法規合規要求。
靜態資料加密
在建模資料儲存時，圖示應明確標示資料在儲存期間是否已加密。這對於合規性與資料保護至關重要。若某節點儲存限制資料，則物件儲存位置應標註加密符號或註解。
請考慮以下情境：
- 資料庫伺服器： 應標示完整磁碟加密，或針對敏感欄位使用欄位層級加密。
- 檔案伺服器： 可能需要針對特定文件類型進行加密。
- 快取伺服器： 通常儲存會話權杖；需具備嚴格的記憶體隔離。
物件完整性
確保已部署的程式碼未遭篡改至關重要。部署模型應反映物件驗證機制，例如數位簽章或雜湊值。這可確保僅受信任的軟體在節點上執行。
🔗 保護通訊路徑
節點之間的連接通常是系統中最薄弱的環節。穿越這些路徑的資料容易遭受竊聽、篡改或拒絕服務攻擊。部署圖必須明確定義通訊所使用的安全協定。
協定規範
節點之間的通用連線具有模糊性。每個連結都應明確指定協定與安全層級：
- HTTPS/TLS： 用於網路流量與API呼叫。
- SSH： 用於安全的遠端管理。
- IPSec： 用於站對站隧道。
- 未加密的 TCP： 應避免使用，若無法避免則應標示為風險。
埠管理
節點上開啟的埠定義了其攻擊面。在圖中，管理員應記錄哪些埠對外部網路開放，哪些埠對內部網路開放。這有助於識別不必要的暴露。
關鍵考量包括：
- 入口埠： 流量從哪裡進入節點？
- 出口埠： 流量從哪裡離開節點？
- 管理埠： 用於管理的埠絕不應對公眾網際網路開放。
頻寬與流量限制
安全也涉及可用性。拒絕服務攻擊針對通訊路徑。模型應考慮流量限制策略。雖然不一定會以圖示元素呈現，但架構應考慮負載平衡器或防火牆等機制，以緩解流量洪水。
🛡️ 定義信任邊界與區域
信任邊界在部署模型中至關重要。它們定義了信任的終點與驗證的起點。跨越信任邊界需要進行驗證與授權。可視化這些區域有助於利益相關者理解安全檢查發生的位置。
網路區段化
節點應分組為邏輯安全區域：
- DMZ（非軍事化區）： 對外服務與內部資源隔離。
- 內部網路： 用於核心業務邏輯的可信基礎設施。
- 管理網路： 專用網路用於管理任務，與使用者流量分離。
- 隔離區： 用於因安全風險而需要隔離的系統。
信任等級
每個區域代表不同的信任等級。從低信任區域移動到高信任區域的資料必須經過審查。部署圖應顯示資料跨越這些邊界時的流動情況，以及所涉及的安全閘門。
防火牆規則
防火牆是這些區域的執行點。在模型中，防火牆應被表示為區域之間的節點或網關。規則應被總結，以顯示允許通過的流量。
| 區域 | 信任等級 | 存取控制 | 加密必要 |
|---|---|---|---|
| 公眾互聯網 | 不可信 | 僅允許白名單 | 是（TLS 1.2+） |
| DMZ | 低 | 限制入口 | 是 |
| 內部網路 | 中 | 基於角色 | 可選（內部） |
| 管理區域 | 高 | 需要多重身份驗證 | 是（強） |
🆔 建模身份驗證與授權
安全性不僅僅是硬體問題；它涉及誰以及什麼可以存取資源。身份驗證（你是誰）和授權（你能做什麼）必須與基礎架構一同建模。
身份提供者
應呈現集中式身份管理。如果系統使用特定的身份提供者進行身份驗證，則此節點應與所有依賴服務連結。這突顯了依賴關係以及潛在的單點故障。
身份驗證機制
每個節點或服務都應指出其所支援的身份驗證方法：
- 單一登入（SSO）： 用於面向使用者的應用程式。
- API金鑰： 用於服務間通訊。
- 憑證： 用於機器對機器通訊。
- OAuth/OIDC： 用於委託授權。
授權策略
授權邏輯應在部署模型的註釋中記錄。例如，資料庫節點可能允許應用程式伺服器讀取存取，但拒絕寫入存取。這些權限定義了資料流的安全性。
⚖️ 合規性與法規對應
許多產業在嚴格的法規框架下運作。部署圖必須反映這些要求，以確保法律合規。未能建模合規性可能導致架構債務和法律處罰。
關鍵法規
根據產業不同，適用特定標準：
- GDPR： 要求在基礎設施內具備資料保護與被遺忘權的實現能力。
- HIPAA： 要求對健康資料的存取與儲存實施嚴格控制。
- PCI-DSS： 規範支付卡資料的處理與儲存方式。
- SOC 2： 重點在安全性、可用性與處理完整性。
資料留存
某些法規要求資料必須保留在特定地理範圍內。部署模型應標示節點的實際位置，以確保資料不會違反當地法律而跨越國界。
稽核追蹤
合規性通常需要記錄日誌。圖示應顯示日誌產生的位置與儲存位置。日誌儲存節點必須與運營節點分離，以防止日誌被篡改。
🐛 圖示中的弱點識別
結構良好的部署圖可作為弱點識別的工具。透過視覺化系統，架構師可在程式碼撰寫前發現弱點。
單點故障
若關鍵節點無備份或冗餘，則代表風險。圖示應突出顯示高可用性配置。叢集與負載平衡應清晰可見，以展現系統的韌性。
暴露的管理介面
管理介面（如 SSH 或 RDP）是攻擊者常見的入侵點。若圖示中這些介面暴露於網際網路，則為紅色警示。應透過堡壘主機或跳板機進行路由。
未加密的通訊頻道
圖表中任何沒有加密標記的線路都可能構成風險。安全審查應專注於這些線路，並強制要求升級加密。
🧠 整合威脅建模
部署建模是正式威脅建模的前驅。一旦基礎設施被繪製出來，團隊就可以應用 STRIDE 等方法論，識別針對架構的特定威脅。
威脅類別
將以下威脅對應到圖表元素：
- 偽造：攻擊者能否偽裝成節點或使用者？
- 篡改：傳輸中或靜止狀態下的資料能否被修改？
- 否認：使用者能否否認所採取的行動？
- 資訊泄露：敏感資料是否在日誌或記憶體中暴露？
- 拒絕服務：系統是否可能被擊潰？
- 權限提升：使用者能否獲得比授予更高的存取權限？
資料流分析
追蹤資料流經整個圖表的路徑。敏感資料的來源是哪裡？終止點在哪裡？在哪些節點上資料被轉換？每個轉換點都可能是潛在的漏洞。
🔄 維持安全完整性
部署圖表並非靜態文件。基礎設施會變更，補丁會被應用，新服務也會被加入。模型必須持續演進，以維持安全完整性。
版本控制
部署模型應與代碼庫一同進行版本控制。這使得團隊能夠比較架構變更的歷史，並審計安全更新。
自動化驗證
現代工具可以根據安全策略驗證圖表。如果新增節點未加密，工具應予以標示。這確保模型保持準確且安全。
定期審計
定期審查部署模型是必要的。安全團隊應確認實體基礎設施與邏輯模型一致。兩者之間的偏差會產生安全漏洞。
📝 最佳實務總結
將安全整合進 UML 部署建模是一項戰略性必要措施。這使安全從被動檢查轉變為主動設計要素。遵循這些指南，團隊可以建立天生安全的架構。
實施時的關鍵要點包括：
- 標註節點：為每一台伺服器和裝置定義安全狀態。
- 標示路徑：在所有連接上指定協定和加密方式。
- 定義區域：明確標示信任邊界與區段劃分。
- 建模驗證：顯示身分與存取權限的管理方式。
- 映射合規性：確保法規要求可見。
- 定期更新：保持圖示與環境同步。
安全是一項持續的過程。部署圖是這段旅程的指南。一張清晰、準確且以安全為導向的圖表，能確保整個旅程始終安全無虞。
