共用方式為

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

  • 發行項

安全性是基本設計原則之一，也是一個關鍵設計領域，必須被視為任務關鍵架構程式內的一流考慮。

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

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

重要

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

GitHub 標誌任務關鍵 開放原始碼 專案

參考實作是 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 識別符整合。

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

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

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

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

  • 為所有較低環境定義適當的安全性態勢，以確保可降低關鍵弱點的風險。

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

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

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

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

    • 測試結果應根據符合規範的安全性狀態來測量，以通知發行核准、自動化或手動。
    • 針對每個版本，將安全性測試套用為 CD 生產程序的一部分。
      • 如果每個版本的安全性測試都危及作業靈活性，請確定套用適當的安全性測試步調。

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

威脅分析模型

威脅模型化提供安全性設計的風險型方法，使用識別的潛在威脅來開發適當的安全性風險降低措施。 有許多可能的威脅具有不同發生機率，而且在許多情況下，威脅可能會以非預期、無法預測甚至混亂的方式鏈結。 這種複雜性和不確定性是為什麼傳統技術需求型安全性方法基本上不適合任務關鍵性雲端應用程式的原因。 預期任務關鍵性應用程式的威脅模型化程式會複雜且不屈不撓。

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

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

注意

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

設計考量

STRIDE 提供輕量型風險架構，以評估跨主要威脅媒介的安全性威脅。

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

設計建議

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

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

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

網路入侵保護

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

設計考量

  • 零信任 假設已入侵的狀態，並驗證每個要求，就好像它源自不受控制的網路一樣。

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

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

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

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

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

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

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

  • Azure DevOps 中可以使用具有對應Microsoft Entra 服務主體的服務連線，透過 Microsoft Entra 標識碼套用 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 或網路虛擬設備 （NVA），請確定其已設定為最大高可用性和備援性。

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

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

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

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

  • 使用 Azure Private Link/Private Endpoints，在應用程式設計中保護對 Azure PaaS 服務的存取權。 如需支援 Private Link 的 Azure 服務的相關資訊，請參閱 Azure Private Link 可用性。

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

    • 根據預設，請勿在所有子網路上啟用虛擬網路服務端點，因為這樣會導入大量的資料外流通道。

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

注意

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

數據完整性保護

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

設計考量

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

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

    • 金鑰保存庫 存取原則指派會分別授與密鑰、秘密或憑證的許可權。

  • 變更角色指派之後，套用角色的延遲最多為 10 分鐘（600 秒）。

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

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

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

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

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

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

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

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

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

  • 法規控制可以規定使用客戶管理的金鑰進行服務加密功能。

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

設計建議

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

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

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

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

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

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

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

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

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

  • 建立金鑰和憑證輪替的自動化流程。

    • 使用公用憑證授權單位自動化憑證管理和續約流程，以簡化管理。
      • 設定警示和通知，以補充自動憑證更新。

  • 監視金鑰、憑證和秘密使用方式。

原則導向的治理

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

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

設計考量

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

注意

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

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

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

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

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

  • 執行部署 If If Exist （DINE） 原則可能需要幾分鐘的時間才會發生。

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

設計建議

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

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

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

    • 例如，套用 Azure 原則 來強制對所有相關服務使用 可用性區域，確保區域內部部署設定可靠。

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

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

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

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

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

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

注意

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

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

如果應用程式已訂閱Microsoft任務關鍵支援，請確定套用的標記架構提供有意義的內容，以透過深入的應用程式了解來豐富支持體驗。

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

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

  • 將安全性資訊和事件管理與適用於雲端的 Microsoft Defender (先前稱為 Azure 資訊安全中心) 整合。

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

在需要使用 IaaS 虛擬機器 的情況下，必須考慮一些細節。

設計考量

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

設計建議

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

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

後續步驟

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

作業程式