Azure 上任務關鍵性工作負載的安全性考慮

  • 發行項

安全性是其中一個基本設計原則，也是必須視為任務關鍵架構程式內第一級考慮的重要設計領域。

假設任務關鍵性設計的主要焦點是將可靠性最大化，讓應用程式保持高效能且可用，因此此設計區域內套用的安全性考慮和建議將著重於降低影響可用性並阻礙整體可靠性的威脅。 例如，成功的拒絕服務 (DDoS) 攻擊已知會對可用性和效能造成重大影響。 應用程式如何減輕這些攻擊媒介，例如 SlowLoris 會影響整體可靠性。 因此，應用程式必須完全受到保護，以防止直接或間接危害應用程式可靠性的威脅，才能真正成為本質上的關鍵任務。

也請務必注意，通常會有與強化安全性狀態相關聯的重大取捨，特別是效能、作業靈活度，在某些情況下的可靠性。 例如，針對新一代防火牆 (NGFW的內嵌網路虛擬設備 (NVA) 包含內嵌網路虛擬設備) 功能，例如深層封包檢查，將會在延展性和復原作業與應用程式的效能降低、額外作業複雜度，以及可靠性風險。 因此，為了減輕重要威脅向量而設計的其他安全性元件和做法也是為了支援應用程式的可靠性目標而設計，這將會形成本節中所呈現建議和考慮的重要層面。

重要

本文是 Azure Well-Architected 任務關鍵性工作負載 系列的一部分。 如果您不熟悉此系列，建議您從 什麼是任務關鍵性工作負載開始？

GitHub 標誌Mission-Critical 開放原始碼 專案

參考實作是 GitHub 上提供 開放原始碼 專案的一部分。 程式代碼資產採用 零信任 模型來建構及引導安全性設計和實作方法。

與 零信任 模型對齊

Microsoft 零信任 模型提供主動式且整合的方法，可在應用程式的所有層級上套用安全性。 零信任 的指導方針致力於明確且持續驗證每個交易、判斷提示最低許可權、使用情報和進階偵測，以近乎即時地回應威脅。 其最終著重於排除應用程式周邊內外的信任，並強制驗證嘗試連線到系統的任何專案。

設計考量

當您評估應用程式的安全性狀態時，請從這些問題開始作為每個考慮的基礎。

  • 持續安全性測試，以驗證重要安全性弱點的風險降低。

    • 安全性測試是否作為自動化 CI/CD 程式的一部分執行？
    • 如果沒有，特定安全性測試的執行頻率為何？
    • 是否根據所需的安全性狀態和威脅模型來測量測試結果？

  • 所有較低環境的安全性層級。

    • 開發生命週期內的所有環境是否都有與生產環境相同的安全性狀態？

  • 發生失敗時的驗證和授權持續性。

    • 如果暫時無法使用驗證或授權服務，應用程式是否能繼續運作？

  • 自動化安全性合規性和補救。

    • 是否可以偵測到金鑰安全性設定的變更？
    • 是否自動補救不符合規範的變更？

  • 密碼掃描以在認可程序代碼之前偵測秘密，以防止透過原始程式碼存放庫洩漏任何秘密。

    • 驗證服務是否可行，而不需要將認證作為程序代碼的一部分？

  • 保護軟體供應鏈。

    • 是否可以追蹤已使用套件相依性內的常見弱點和暴露 () ？
    • 是否有自動化程式可更新套件相依性？

  • 數據保護金鑰生命週期。

    • 服務管理的金鑰是否可以用於資料完整性保護？
    • 如果需要客戶管理的金鑰，安全且可靠的金鑰生命週期如何？

  • CI/CD 工具應該需要 Microsoft Entra 具有足夠訂用帳戶層級存取權的服務主體，以協助對所有考慮的環境訂用帳戶進行 Azure 資源部署的控制平面存取。

    • 在專用網內鎖定應用程式資源時，是否有私人數據平面連線路徑，讓 CI/CD 工具可以執行應用層級部署和維護。
      • 這會引進額外的複雜度，而且需要透過必要的私人組建代理程式在部署程式內進行序列。

設計建議

  • 使用 Azure 原則 強制執行所有服務的安全性和可靠性設定，確保控制平面在設定時間補救或禁止任何偏差，協助減輕與「惡意系統管理員」案例相關聯的威脅。

  • 在生產訂用帳戶內使用 Microsoft Entra Privileged Identity Management (PIM) ，撤銷對生產環境的持續控制平面存取。 這可大幅降低「惡意系統管理員」案例透過其他「檢查和平衡」所造成的風險。

  • 針對支援此功能的所有服務使用 Azure 受控識別 ，因為它有助於從應用程式程式代碼中移除認證，並移除服務對服務通訊的身分識別管理作業負擔。

  • 使用 Microsoft Entra 角色型訪問控制 (RBAC) ，搭配支援功能的所有服務進行數據平面授權。

  • 使用應用程式程式代碼內的第一方 Microsoft 身分識別平台 驗證連結庫，與 Microsoft Entra ID 整合。

  • 如果所選的身分識別平台無法使用或僅部分可供應用程式授權使用，請考慮安全令牌快取以允許降級但可用的體驗。

    • 如果提供者無法發出新的存取令牌，但仍會驗證現有的存取令牌，則應用程式和相依服務可以在令牌過期之前運作，而不會發生問題。
    • 令牌快取通常是由驗證連結庫自動處理， (例如 MSAL) 。

  • 使用基礎結構即程式代碼 (IaC) 和自動化 CI/CD 管線來驅動所有應用程式元件的更新，包括失敗情況下。

    • 請確定 CI/CD 工具服務連線受到保護，作為重要的敏感性資訊，不應直接提供給任何服務小組使用。
    • 將細微的 RBAC 套用至生產 CD 管線，以減輕「惡意系統管理員」風險。
    • 請考慮在生產部署管線內使用手動核准網關，進一步降低「惡意系統管理員」風險，併為所有生產變更提供額外的技術保證。
      • 額外的安全性網關可能會因為靈活度而產生取捨，而且應該仔細評估，並考慮如何維持靈活度，即使使用手動網關也一般。

  • 為所有較低環境定義適當的安全性狀態，以確保可降低重要弱點。

    • 請勿套用與生產環境相同的安全性狀態，特別是在數據外洩方面，除非法規需求規定需要這麼做，因為這將會大幅危害開發人員的靈活度。

  • 針對包含任務關鍵性工作負載之資源的所有訂用帳戶，啟用雲端 (先前稱為 Azure 資訊安全中心) Microsoft Defender。

    • 使用 Azure 原則 強制執行合規性。
    • 針對支援此功能的所有服務啟用 Azure Defender。

  • 採用 DevSecOps ，並在 CI/CD 管線內實作安全性測試。

    • 測試結果應根據符合規範的安全性狀態來測量，以通知發行核准，是否為自動化或手動。
    • 在每個版本的CD生產程式中套用安全性測試。
      • 如果每個版本的安全性測試都會危害作業靈活度，請確定套用適當的安全性測試頻率。

  • 啟用原始碼存放庫中的 秘密掃描 和相依性掃描。

威脅模型化

威脅模型化提供安全性設計的風險型方法，使用已識別的潛在威脅來開發適當的安全性防護功能。 有許多可能的威脅具有不同的發生機率，在許多情況下，威脅可能會以非預期、無法預測的方式鏈結，甚至是混亂的方式。 這種複雜度和不確定性是傳統技術需求型安全性方法對於任務關鍵性雲端應用程式而言很不適合的原因。 預期任務關鍵性應用程式的威脅模型化程式十分複雜且不重要。

為了協助流覽這些挑戰，應套用分層防禦深入方法，以定義及實作模型化威脅的補償防護措施，考慮下列防禦層。

  1. 具有基本安全性功能和控件的 Azure 平臺。
  2. 應用程式架構和安全性設計。
  3. 內建、啟用且可部署的安全性功能，可套用至安全的 Azure 資源。
  4. 應用程式程式代碼和安全性邏輯。
  5. 作業程式和 DevSecOps。

注意

在 Azure 登陸區域內部署時，請注意，透過布建集中式安全性功能的額外威脅防護層是由登陸區域實作所提供。

設計考量

STRIDE 提供輕量型風險架構，可評估主要威脅向量的安全性威脅。

  • 詐騙身分識別：利用授權模擬個人。 例如，攻擊者會使用其 來模擬其他使用者 -
    • 身分識別
    • 驗證
  • 竄改輸入：修改傳送至應用程式的輸入，或違反信任界限來修改應用程式程序代碼。 例如，攻擊者使用 SQL 插入來刪除資料庫資料表中的數據。
    • 資料完整性
    • 驗證
    • 封鎖清單/允許清單
  • 拒絕動作：能夠拒絕已採取的動作，以及應用程式收集辨識項並推動責任的能力。 例如，刪除重要數據，而無法追蹤惡意系統管理員。
    • 稽核/記錄
    • 簽署
  • 信息洩漏：取得受限制資訊的存取權。 例如，攻擊者會取得受限制檔案的存取權。
    • 加密
    • 資料外流
    • 中間人攻擊
  • 拒絕服務：惡意應用程式中斷以降低用戶體驗。 例如，DDoS Botnet 攻擊，例如 Slowloris。
    • DDoS
    • 殭屍網路
    • CDN 和 WAF 功能
  • 提高許可權：透過授權惡意探索取得特殊許可權的應用程式存取權。 例如，攻擊者操作 URL 字串以取得敏感性資訊的存取權。
    • 遠端執行程式碼
    • 授權
    • 隔離性

設計建議

  • 在每個短期衝刺內配置工程預算，以評估潛在的新威脅並實作風險降低。

  • 應套用有意識的心力，以確保在一般工程準則內擷取安全性風險降低措施，以推動所有應用程式服務小組的一致性。

  • 從服務等級威脅模型化服務開始，並藉由將線程模型合併到應用層級來統一模型。

網路入侵防護

防止未經授權的存取任務關鍵性應用程式，並包含的數據對於維護可用性及保護數據完整性至關重要。

設計考量

  • 零信任 假設有入侵的狀態，並驗證每個要求，就像來自未受控制的網路一樣。

    • 進階零信任網路實作採用微分割和分散式輸入/輸出微周邊。

  • Azure PaaS 服務通常會透過公用端點來存取。 Azure 提供保護公用端點或甚至讓公用端點完全私人的功能。

    • Azure Private Link/私人端點會使用私人IP位址和專用網連線，提供 Azure PaaS 資源的專用存取權。
    • 虛擬網路 服務端點提供從所選子網到所選 PaaS 服務的服務層級存取。
    • 虛擬網路 插入會針對支援的服務提供專用的私人部署，例如透過 App Service 環境 App Service。
      • 管理平面流量仍會流經公用 IP 位址。

  • 針對支持的服務，Azure Private Link 使用 Azure 私人端點可解決與服務端點相關聯的數據外泄風險，例如惡意系統管理員將數據寫入外部資源。

  • 使用私人端點或服務端點限制 Azure PaaS 服務的網路存取時，部署管線必須有安全的網路通道，才能存取 Azure 資源的 Azure 控制平面和數據平面，才能部署和管理應用程式。

    • 部署至專用網的私人自我裝載組建代理程式，因為 Azure 資源可用來作為 Proxy，透過私人連線執行 CI/CD 函式。 個別的虛擬網路應該用於建置代理程式。
      • 需要從 CI/CD 工具連線到私人組建代理程式。
    • 另一種方法是修改管線內資源即時的防火牆規則，以允許來自 Azure DevOps 代理程式公用 IP 位址的連線，並在工作完成之後移除防火牆。
      • 不過，此方法僅適用於 Azure 服務的子集。 例如，這不適用於私人 AKS 叢集。
    • 若要在應用程式服務跳躍方塊上執行開發人員和系統管理工作，可以使用。

  • 系統管理和維護工作的完成是需要連線至 Azure 資源數據平面的進一步案例。

  • Azure DevOps 內可以使用具有對應 Microsoft Entra 服務主體的服務 Connections，透過 Microsoft Entra ID 套用 RBAC。

  • 服務標籤可以套用至網路安全組，以利與 Azure PaaS 服務的連線。

  • 應用程式安全組不會跨越多個虛擬網路。

  • Azure 網路監看員 中的封包擷取限制為五小時上限。

設計建議

  • 將公用網路存取限制為應用程式達到其商業目的所需的絕對最低存取，以減少外部攻擊面。

  • 處理私人組建代理程式時，絕不會直接開啟 RDP 或 SSH 埠到因特網。

    • 使用 Azure Bastion 提供 Azure 虛擬機器 的安全存取，以及透過因特網在 Azure PaaS 上執行系統管理工作。

  • 使用 DDoS 標準保護計劃來保護應用程式內的所有公用 IP 位址。

  • 使用 Azure Front Door 搭配 Web 應用程式防火牆原則來提供並協助保護跨越多個 Azure 區域的全域 HTTP/S 應用程式。

    • 使用標頭標識碼驗證來鎖定公用應用程式端點，使其只接受來自 Azure Front Door 實例的流量。

  • 如果額外的內嵌網路安全性需求，例如深層封包檢查或 TLS 檢查，則強制使用 Azure 防火牆 Premium 或 Network Virtual Appliance (NVA) ，請確定其已設定為高可用性和備援性上限。

  • 如果封包擷取需求存在，請使用 網路監看員 封包來擷取，儘管擷取視窗有限。

  • 使用網路安全組和應用程式安全組，以微區隔應用程式流量。

    • 避免使用安全性設備來篩選應用程式內部流量。
    • 請考慮使用 Azure 原則 來強制執行特定的NSG規則一律與應用程式子網相關聯。

  • 啟用 NSG 流量記錄，並將其饋送至流量分析，以深入了解內部和外部流量流程。

  • 使用 Azure Private Link/私人端點，其中可用，以保護應用程式設計內的 Azure PaaS 服務存取。 如需支援 Private Link 的 Azure 服務的相關資訊，請參閱 Azure Private Link 可用性。

  • 如果私人端點無法使用，且數據外泄風險可接受，請使用 虛擬網路 服務端點來保護從虛擬網路記憶體取 Azure PaaS 服務的安全。

    • 根據預設，請勿在所有子網上啟用虛擬網路服務端點，因為這會引進大量的數據外洩通道。

  • 針對混合式應用程式案例，請透過具有私人對等互連的 ExpressRoute 從內部部署存取 Azure PaaS 服務。

注意

在 Azure 登陸區域內部署時，請注意登陸區域實作會提供內部部署數據中心的網路連線能力。 其中一種方法是使用以私人對等互連設定的 ExpressRoute。

數據完整性保護

加密是確保數據完整性的重要步驟，最後是其中一項最重要的安全性功能，可套用以減輕各種威脅。 因此，本節將提供與加密和密鑰管理相關的重要考慮和建議，以保護數據，而不會影響應用程式可靠性。

設計考量

  • Azure 金鑰保存庫 對於密鑰和秘密具有交易限制，並在特定期間內針對每個保存庫套用節流。

  • Azure 金鑰保存庫 提供安全性界限，因為密鑰、秘密和憑證的訪問許可權是在保存庫層級套用。

    • Key Vault 存取原則指派可分別授與金鑰、祕密或憑證的權限。

  • 角色指派變更之後，最多 10 分鐘 (600 秒) ，才能套用角色。

    • 每個訂用帳戶有 2,000 個 Azure 角色指派的限制。

  • Azure 金鑰保存庫 基礎硬體安全性模組 (HSM) 具有 FIPS 140 驗證。

  • Azure 金鑰保存庫 提供高可用性和備援，以協助維護可用性並防止數據遺失。

  • 在區域故障轉移期間，金鑰保存庫 服務可能需要幾分鐘的時間才能進行故障轉移。

    • 在故障轉移期間，金鑰保存庫 會處於只讀模式，因此無法變更密鑰保存庫屬性，例如防火牆組態和設定。

  • 如果使用私人連結來連線到 Azure 金鑰保存庫，在區域故障轉移期間重新建立連線可能需要 20 分鐘的時間。

  • 備份會建立秘密、密鑰或憑證 的時間點快照 集，作為無法在 Azure 外部解密的加密 Blob。 若要從 Blob 取得可用數據，必須將它還原到相同 Azure 訂用帳戶和 Azure 地理位置內的 金鑰保存庫。

    • 秘密可能會在備份期間更新，導致不符。

  • 透過服務管理的金鑰，Azure 會執行金鑰管理功能，例如輪替，藉此減少應用程式作業的範圍。

  • 法規控制可能會規定客戶管理的金鑰用於服務加密功能。

  • 當流量在 Azure 資料中心之間移動時，基礎網路硬體會使用 MACsec 數據連結層加密，以保護 Microsoft 或代表 Microsoft 控制之實體界限外傳輸中的數據。

設計建議

  • 盡可能使用服務管理的金鑰進行數據保護，移除管理加密金鑰並處理金鑰輪替等作業工作的需求。

    • 只有在有明確的法規需求時，才使用客戶管理的密鑰。

  • 如果需要考慮其他加密機制或客戶管理的密鑰，請使用 Azure 金鑰保存庫 作為所有秘密、憑證和密鑰的安全存放庫。

    • 佈建已啟用虛刪除和清除原則的 Azure Key Vault，以允許對已刪除物件的保留保護。
    • 針對應用程式生產環境使用 HSM 支援的 Azure 金鑰保存庫 SKU。

  • 在每個區域部署戳記內部署個別的 Azure 金鑰保存庫 實例，透過當地語系化提供錯誤隔離和效能優勢，以及瀏覽單一 金鑰保存庫 實例所加加的調整限制。

    • 針對應用程式全域資源使用專用的 Azure 金鑰保存庫 實例。

  • 藉由將授權限制為永久刪除秘密、密鑰和憑證到特殊自定義 Microsoft Entra 角色，以遵循最低許可權模型。

  • 請確定已備份儲存在 金鑰保存庫 內的加密密鑰和憑證，在不太可能的事件中提供離線復本，金鑰保存庫變得無法使用。

  • 使用 金鑰保存庫 憑證來管理憑證採購和簽署。

  • 針對金鑰與憑證輪替建立自動化程序。

    • 透過公開憑證授權，將憑證管理和更新程序自動化，以簡化管理。
      • 設定警示和通知，以補充自動憑證更新。

  • 監視金鑰、憑證和祕密的使用情況。

    • 定義 Azure 監視器內非預期使用量的 警示 。

原則導向的治理

安全性慣例最終只有在所有應用程式服務和小組之間一致且全面地強制執行時才有效。 Azure 原則 提供一個架構來強制執行安全性和可靠性基準，確保持續符合任務關鍵性應用程式的一般工程準則。 更具體來說，Azure 原則 構成 Azure Resource Manager (ARM) 控制平面的重要部分，藉由限制獲授權用戶可執行的動作來補充 RBAC，並可用來跨已使用的平臺服務強制執行重要的安全性和可靠性慣例。

因此，本節將探索針對任務關鍵性應用程式使用 Azure 原則 驅動治理的重要考慮和建議，以確保持續強制執行安全性和可靠性慣例。

設計考量

  • Azure 原則 藉由強制執行安全性和可靠性慣例，例如使用私人端點或使用 可用性區域，來提供一種機制來推動合規性。

注意

在 Azure 登陸區域內部署時，請注意，在登陸區域管理群組和訂用帳戶的實作中，可能會套用集中式基準原則指派的強制執行。

  • Azure 原則 可用來推動自動化管理活動，例如布建和設定。

    • 資源提供者註冊。
    • 個別 Azure 資源設定的驗證和核准。

  • Azure 原則 指派範圍會指定涵蓋範圍和 Azure 原則 定義的位置，以通知自定義原則的重複使用性。

  • Azure 原則 有數個限制，例如任何特定範圍的定義數目。

  • 執行部署 If Not Exist (一次) 原則可能需要幾分鐘的時間。

  • Azure 原則 提供合規性報告和安全性稽核的重要輸入。

設計建議

  • 將法規和合規性需求對應至 Azure 原則 定義。

    • 例如，如果有數據落地需求，應該套用原則來限制可用的部署區域。

  • 定義常見的工程準則，以擷取所有已使用之 Azure 服務的安全性和可靠組態定義，以確保此準則會對應至 Azure 原則 指派，以強制執行合規性。

    • 例如，套用 Azure 原則 來強制執行所有相關服務的 可用性區域 使用，以確保區域內部部署組態可靠。

任務關鍵性參考實作包含廣泛的安全性和可靠性中心原則，可定義並強制執行範例一般工程準則。

  • 使用 Azure 原則，監視相對於常見工程準則的服務組態漂移。

對於在專用管理群組下具有多個生產訂用帳戶的任務關鍵性案例，請在管理群組範圍內優先指派。

  • 盡可能使用內建原則，將維護自定義原則定義的作業額外負荷降至最低。

  • 如果需要自定義原則定義，請確定定義會部署在適當的管理群組範圍，以允許跨包含的環境訂用帳戶重複使用，以允許跨生產環境與較低環境重複使用原則。

    • 將應用程式藍圖與 Azure 藍圖對齊時，請使用可用的 Microsoft 資源來探索重要自定義定義是否可納入為內建定義。

注意

在 Azure 登陸區域內部署時，請考慮在中繼公司根管理群組範圍內部署自定義 Azure 原則 定義，以便在更廣泛的 Azure 資產內的所有應用程式重複使用。 在登陸區域環境中，某些集中式安全策略預設會在較高的管理群組範圍內套用，以在整個 Azure 資產強制執行安全性合規性。 例如，應該套用 Azure 原則，以透過 VM 擴充功能自動部署軟體設定，並強制執行符合規範的基準 VM 設定。

  • 使用 Azure 原則 在整個應用程式中強制執行一致的標記架構。
    • 識別所需的 Azure 標籤，並使用附加原則模式以強制使用。

如果應用程式已訂閱 Microsoft Mission-Critical 支援，請確定套用的標記架構提供有意義的內容，以透過深入的應用程式了解來擴充支持體驗。

  • 將 Microsoft Entra 活動記錄匯出至應用程式所使用的全域 Log Analytics 工作區。
    • 請確定 Azure 活動記錄會封存於全域記憶體帳戶內，以及長期保留的作業數據。

在 Azure 登陸區域中，Microsoft Entra 活動記錄也會內嵌到集中式平臺 Log Analytics 工作區中。 如果全域 Log Analytics 工作區中仍然需要 Microsoft Entra ID，則必須在此案例中進行評估。

  • 整合安全性資訊和事件管理與先前稱為 Azure 資訊安全中心) 的 Cloud (Microsoft Defender。

使用 虛擬機器 時的 IaaS 特定考慮

在需要使用 IaaS 虛擬機器 的情況下，必須考慮一些特定專案。

設計考量

  • 部署后，映像不會自動更新。
  • 匯報 不會自動安裝到執行中的 VM。
  • 映像和個別 VM 通常不會立即強化。

設計建議

  • 不允許透過公用因特網直接存取，藉由提供 SSH、RDP 或其他通訊協定的存取權來 虛擬機器。 請一律使用 Azure Bastion 和 jumpbox，並限制對少數使用者群組的存取權。
  • 使用網路安全組、 (Azure) 防火牆或應用程式閘道 (層級 7) 來篩選和限制輸出流量，以限制直接因特網連線。
  • 針對多層式應用程式，請考慮使用不同的子網，並使用網路安全組來限制兩者之間的存取。
  • 盡可能優先使用公鑰驗證。 將秘密儲存在安全的地方，例如 Azure 金鑰保存庫。
  • 使用驗證和訪問控制來保護 VM。
  • 套用與任務關鍵性應用程式案例所述的相同安全性做法。

遵循並套用上述任務關鍵性應用程式案例的安全性做法，以及 Azure 中 IaaS 工作負載的安全性最佳做法。

後續步驟

檢閱任務關鍵性應用程式案例作業程式的最佳做法。

作業程序