本文說明如何管理 Azure 雲端資產，以確保運作健康情況。 您需要對雲端作業進行強大的系統管理控制，以確保雲端符合您的商務目標。
識別您的管理範圍
管理責任會因部署模型而異。 使用下表來識別基礎結構 （IaaS）、平臺 （PaaS）、軟體 （SaaS） 和內部部署的管理責任。
| 管理區域 | 內部部署 | IaaS （Azure） | PaaS （Azure） | SaaS |
|---|---|---|---|---|
| 變更 | ✔️ | ✔️ | ✔️ | ✔️ |
| 安全性 | ✔️ | ✔️ | ✔️ | ✔️ |
| 合規性 | ✔️ | ✔️ | ✔️ | ✔️ |
| 數據 | ✔️ | ✔️ | ✔️ | ✔️ |
| 程式代碼和運行時間 | ✔️ | ✔️ | ✔️ | |
| 雲端資源 | ✔️ | ✔️ | ✔️ | |
| 搬遷 | ✔️ | ✔️ | ✔️ | |
| 作業系統 | ✔️ | ✔️ | ||
| 虛擬化層 | ✔️ | |||
| 實體硬體 | ✔️ |
管理變更
變更是雲端中最常見的問題來源。 因此，您需要一種能夠追蹤變更及其核准的變更管理方法。 它也應該偵測未核准的變更，並將其還原為所需的狀態。 請遵循下列步驟：
開發變更要求程式。 使用正式系統，例如票證工具、提取要求（GitHub 或 Azure DevOps），或指定的表單。 變更要求程序必須擷取金鑰詳細數據，例如變更類型、要求者身分識別、目標環境、範圍和原因。 對於例行的服務要求，例如密碼重設，應保持獨立的程序。
評估與變更相關聯的風險。 指派明確的風險類別（高、中、低），以平衡部署速度與風險管理。 根據停機時間容錯（錯誤預算）和工作負載關鍵性等準則來評估每個變更。 若要協助判斷適當的核准工作流程，請使用下表作為範例：
風險層級 停機時間津貼 工作負載的關鍵程度 核准程式 範例變更 高 不允許停機 這些變更會影響任務關鍵性系統，這些系統需要持續可用性，且沒有任何停機時間。 多個資深工程師檢閱、自動化管線警示、 漸進式曝光模型，以及主動監視。 重大基礎結構更新 中等 允許短暫的停機時間 這些變更會影響停機時間有容忍度有限的重要系統。 自動化管線會標記變動。 如果監視引發警示，工程師會快速檢閱。 非關鍵系統更新，短期維護期間的功能增強 低 允許充足的停機時間 這些變更會影響可接受延長停機時間的非關鍵系統，而不會影響整體作業。 透過 CI/CD 完全自動化部署會執行預先部署測試和監視。 例行更新、次要原則更新 明確規範核准。 定義每個風險層級所需的核准準則和授權單位。 指定誰必須檢閱每個變更，無論是單一核准者還是審核委員會，並釐清檢閱者必須如何提供和解決意見反應。
標準化部署程式。 清楚概述建置、測試及部署已核准變更至生產環境的程式。 如需詳細資訊，請參閱 管理雲端資源。
標準化部署後程式。 若要確認變更成功，請實作監視和驗證步驟。 包含明確的復原策略，以在變更造成問題時快速還原服務。
防止及偵測未經授權的變更。 使用 變更分析 來偵測組態變更並說明其根本原因。 使用 Azure 原則來拒絕和稽核變更，效果包括 Deny、DenyAction、Audit，以及 auditIfNotExists。 如果您使用 Bicep，請考慮使用 Bicep 部署堆疊 以防止未經授權的變更。
管理安全性
身份是您的安全性邊界。 您必須驗證身分識別、限制許可權，以及維護安全的資源設定。 請遵循下列步驟：
管理身分識別。 使用 Microsoft Entra ID 作為統一身分識別管理解決方案。 藉由套用 角色型訪問控制 （RBAC）來明確定義許可權。 使用 Microsoft Entra ID Governance 來控制存取要求工作流程、存取權檢閱和身分識別生命週期管理。 啟用 特權身分管理 以授予即時特權存取。 此策略可減少過度的存取權限。 一致地管理這三種身分識別類型（使用者、應用程式、裝置），以確保適當的驗證和授權。
管理存取權。 使用 Azure 角色型存取控制 （RBAC） 和 屬性型存取控制 （ABAC） 來授與完成作業的最低許可權。 若要限制管理額外負荷，偏好根據 群組來指派角色。 在最小必要的 範圍授與權限，例如訂閱、資源群組或個別資源。 避免過於廣泛的許可權範圍，以避免非預期的許可權提升。 僅為每個使用者角色分配必要的權限。
管理資源設定。 使用 基礎結構作為程式代碼 （IaC） 以確保資源設定一致且可重現。 然後使用 Azure 原則 來強制執行特定 Azure 服務的安全設定。 如需可用安全性功能和最佳安全性設定的指引，請參閱 安全性基準。 作為附加功能，請在雲端版 Defender 中使用安全策略，以符合通用安全標準。
管理驗證。 確保使用者透過多重要素驗證 （MFA） 採用強式驗證，並使用 Microsoft Entra 多重要素驗證 （MFA）。 一律需要 條件式存取 ，以根據使用者身分識別、裝置健康情況和存取內容強制執行驗證。 設定 自助式密碼重設，並 排除弱式密碼。
管理安全性資訊。 使用 Microsoft Sentinel 進行安全資訊和事件管理（SIEM），以及安全編排、自動化和回應（SOAR）。
控制工作負載安全性。 如需工作負載安全性建議，請參閱 Well-Architected Framework 安全性檢查清單 和 Azure 服務指南（從安全性一節開始）。
管理合規性
合規性管理可確保 Azure 作業與已建立的治理原則和法規標準保持一致。 您必須藉由保護環境免於潛在的違規和設定錯誤來降低風險。 請遵循下列步驟：
瞭解治理原則。 治理原則會定義小組必須遵循的高階條件約束，才能保持符合規範。 檢閱貴組織的原則，並將每個需求對應至您的作業程式。 如果您沒有治理原則，請先 紀錄治理原則。
管理合規性。 強制執行合規性可確保您的環境與組織和法規標準保持一致。 如需原則建議，請參閱下表。
建議 詳情 從一般原則定義 開始 從 Azure 原則的一般定義開始，包括允許的位置、不允許的資源類型，以及稽核自定義 RBAC 角色。 與 法規標準 一致 使用符合法規標準的 Azure 原則免費內建定義，例如 ISO 27001、NIST SP 800-53、PCI DSS、歐盟 GDPR
如需詳細資訊，請參閱 在 Azure中強制執行合規性。
管理數據
在雲端作業中管理數據牽涉到主動分類、分割、保護存取，以及防止刪除。 您必須保護敏感性資訊、維護合規性，並確保在作業變更期間的數據可靠性。 請遵循下列步驟：
探索和分類數據。 根據敏感度和重要性識別和分類數據。 此分類會引導針對每個數據類型量身打造的控制件。 使用 Microsoft Purview 進行數據控管。 如需詳細資訊，請參閱 連線到 Microsoft Purview 數據地圖的數據源。
控制數據落地。 選取您 地理位置內的區域，例如美國或歐洲，以符合數據落地需求。 確認任何例外狀況，因為 某些 Azure 服務 可能會將數據儲存在所選區域之外。 定期檢閱 Azure 數據落地設定和合規性需求，以維持客戶數據的完整控制權。
隔離內部 （“Corp”） 和因特網對向 （“Online”） 工作負載。 使用管理群組來分隔內部和外部工作負載。 內部工作負載通常需要連線或混合式連線到您的公司網路。 外部工作負載通常不需要公司網路連線，而且可能需要直接輸入或輸出因特網存取。 例如，請檢閱 Azure 著陸區中的 “Corp” （內部） 和 “Online” （面向因特網） 管理群組。
強制執行訪問控制。 實作強固的訪問控制，例如 Azure RBAC 和 Azure ABAC，以確保只有授權的人員根據定義的分類存取敏感數據。
保護資料免於刪除。 使用暫時刪除、數據版本管理和不可變更性等功能。 實作資料庫版本設定和準備復原程式。 使用 Azure 原則來拒絕資料存放區的刪除，透過 拒絕 和 DenyAction 效果，或透過 稽核 和 auditIfNotExists 來稽核任何變更。 如果您使用 Bicep，請考慮使用 Bicep 部署堆疊 以防止未經授權的變更。 僅將 資源鎖 嚴格用於防止非預期的修改或刪除重要數據。 避免使用資源鎖定來保護組態，因為資源鎖定會使 IaC 部署複雜化。
管理工作負載資料。 請參閱 Well-Architected 架構的 資料分類建議。
如需詳細資訊，請參閱 強制執行資料控管。
管理成本
在雲端作業中管理成本意味著積極追蹤支出，集中監控和各個工作負載。 成本控制應提供支出的可見度，並鼓勵負責任的支出。 請遵循下列步驟：
管理和檢閱成本。 使用Microsoft成本管理工具來 監視雲端成本。 Azure 缺乏訂閱範圍的機制，無法將支出限制在某一閾值。 某些服務，例如 Azure Log Analytics 工作區，具有消費上限。 您的成本監視策略可作為管理費用的主要工具。
管理工作負載成本。 授予工作負載團隊的計費存取權。 請讓這些小組使用 Well-Architected Framework 的成本優化 檢查清單。
管理程式代碼和運行時間
管理程式代碼和運行時間是工作負載責任。 讓您的工作負載團隊使用 Well-Architected 框架的 運營卓越檢查清單，該檢查清單概述了 12 項用於控制代碼和運行時間的建議。
管理雲端資源
建立明確的部署通訊協議和主動式漂移和蔓延偵測策略，以維護環境之間的一致性。 本節涵蓋：
管理入口網站部署
定義入口網站部署的通訊協定和限制，以將生產問題的可能性降到最低。 請遵循下列步驟：
定義入口網站部署原則。 確保以入口網站為基礎的重大變更遵守已建立的變更管理程式。 主要針對開發和測試環境中的快速原型設計、疑難解答或次要調整使用入口網站部署。 避免非結構化入口網站變更，因為這些變更會導致漂移、設定錯誤和合規性問題。 相反地，依賴版本控制的基礎結構即程序代碼 （IaC） 範本來保持一致性。 如需詳細資訊，請參閱 管理程式碼部署。
區分不同的環境。 入口網站的變更應嚴格限制在非生產環境中。 在專用的開發或測試環境中，允許快速原型設計，並在生產環境中強制執行嚴格的控制。
限制入口網站許可權。 使用角色型訪問控制 （RBAC） 限制入口網站的部署功能。 預設情況下指派只讀許可權，僅在必要時提升權限。
授與 Just-In-Time 存取權。 使用 Privileged Identity Management （PIM） 來存取 Azure 和 Microsoft Entra 資源。 需要多個個人或群組的循序核准，以啟用 PIM。 針對緊急案例，保留特殊許可權角色 （“A0” 超級系統管理員角色）。
以作業模型為基礎的結構 RBAC。 針對作業小組量身打造的設計 RBAC 原則，包括支援層級、安全性作業、平臺、網路和工作負載。
稽核所有活動。 監視並記錄系統中的所有動作。 使用 Azure 原則來審核（審核 或 如果不存在則審核）變更。 此外，在 Azure 監視器中設定 警示，以在有人刪除 Azure 資源時通知項目關係人。 如果您使用 Bicep，請考慮使用 Bicep 部署堆疊 以防止未經授權的變更。
使用版本控制的範本。 若採用 IaC 部署，請將平台使用限制在緊急情況下。 門戶變更會導致 IaC 模板的配置漂移。 立即在版本控制的 IaC 範本中複寫所有入口網站型變更，例如 Bicep、Terraform或 ARM 範本。 定期匯出 Azure 資源設定，並將其儲存為 IaC，以維護符合已核准且可追蹤設定的生產環境。 請參閱如何將 Azure 組態導出為 Bicep、Terraform或 ARM 範本的指引。 如果使用 ARM 範本，請考慮 樣本規格。
工具 用例 肱二頭肌 易於管理、易於閱讀的 Azure 專用 IaC Terraform 多重雲端解決方案，更廣泛的社群支援 ARM 範本 完全掌控，對 JSON 感到自如
管理程式代碼部署
採用最佳做法，以自動化和控制程式代碼和基礎結構的變更。 請遵循下列步驟：
標準化工具。 使用一致的工具組將內容切換降至最低。 選擇開發人員工具（VS Code、Visual Studio）、程式代碼存放庫（GitHub、Azure DevOps）、CI/CD 管線（GitHub Actions、Azure Pipelines）和 IaC 解決方案（Bicep、Terraform或 ARM 範本）。
使用版本控制。 維護程式代碼的單一事實來源。 使用版本控制來減少設定漂移並簡化復原程式。
使用部署管線。CI/CD 管線 自動化建置過程、執行測試，並掃描程式碼，以檢查每個提取要求的品質和安全性問題。 使用 GitHub Actions 或 Azure Pipelines 來建置和部署應用程式程式代碼和 IaC 檔案。 強制執行「預提交鉤子」及自動掃描，以便早期識別未經授權或高風險的變更。
測試部署。 在你的 CI/CD 流水線中的階段核准，以漸進方式驗證部署。 遵循此順序：開發、構建驗證、整合測試、效能測試、使用者驗收測試（UAT）、預備階段、canary 發布、預生產環境，最後是生產階段。
使用基礎結構即程序代碼 （IaC）。 使用 IaC 確保一致性，並透過版本控制來管理部署。 將概念驗證從 Azure 入口網站為基礎的模式轉移到生產環境的基礎設施即程式碼 (IaC)。 使用 Bicep、Terraform或 ARM 範本來定義資源。 針對 Bicep，請使用 模組，並考慮 部署堆疊。 針對 ARM 範本的版本化部署，請考慮使用 範本規格。
套用程式代碼存放庫最佳做法。 遵循這些標準可減少錯誤、簡化程式代碼檢閱，並避免整合問題。 針對優先度高的生產環境：
要求 描述 禁用直接推送 阻止對主分支的直接提交 需要提交拉取請求 所有變更都需要通過拉取請求處理 需要程式碼審核 確保每個拉取請求都由作者以外的人檢查 強制程式碼覆蓋率閾值 確定程式代碼的最小百分比通過所有提取要求的自動化測試 使用驗證管線 設定分支保護規則以運行拉取請求的驗證流程 需要工作團隊上線檢查。 確認新的程式代碼基底和團隊符合標準、最佳做法和商務目標。 使用檢查清單來確認程式代碼存放庫結構、命名標準、編碼標準和 CI/CD 管線組態。
管理配置偏移
藉由識別並更正預定組態與即時環境之間的差異，以管理設定漂移。 請遵循下列最佳做法：
防止和偵測變更。 使用 變更分析 來偵測組態變更並說明其根本原因。 使用 Azure 原則來拒絕和稽核變更，效果包括 Deny、DenyAction、Audit，以及 auditIfNotExists。 如果您使用 Bicep，請考慮使用 Bicep 部署堆疊 以防止未經授權的變更。
偵測 IaC 設定漂移。當有人更新 IaC 檔案（刻意、無意）或在 Azure 入口網站中進行變更時，就會發生 Drift。 定期比較實時環境與您想要的設定，以偵測漂移：
儲存所需的組態和最新已知良好的組態。 將所需組態檔儲存在版本控制的檔案庫中。 此檔案會顯示原始的預定組態。 將最後一個已知良好的設定維持為可靠的回復參考和偏移偵測基準。
在部署之前偵測設定漂移。 使用 Terraform plan、Bicep what-if，或 ARM template what-if，然後在部署前預覽潛在變更。 徹底調查差異，以確保建議的變更符合所需的狀態。
偵測部署後漂移。 透過定期漂移檢查，定期比較實時環境與預期的設定。 將這些檢查整合到 CI/CD 管線中，或手動進行以維持一致性。 請參閱 Azure 原則和 Azure Pipelines 的範例。
回復至最後已知良好的配置。 開發明確的回復策略，以在 CI/CD 管線中使用自動化程式。 利用您最近一次已知良好的配置，快速復原不想要的變更，並將停機時間降低到最小。
最小化入口網站驅動的變更。 僅在緊急情況下進行非 IaC 變更。 強制執行嚴格的訪問控制，例如 Privileged Identity Management。 如果需要手動調整，以保留所需設定的正確性，請立即更新 IaC 檔案。
管理資源擴張
資源蔓延描述雲端資源的不受控制成長。 此成長會增加成本、安全性風險和管理複雜性。 請遵循下列步驟：
實作治理原則。 使用 Azure 原則 來強制執行整個組織 的資源布建 和 標記 標準。 建立清楚 的命名策略 ，以方便資源可見度。
有效地組織資源。 使用符合組織需求的管理群組和訂用帳戶，以階層方式建構資源。 此結構可改善可見度和資源管理。 如需經過證實的最佳做法，請參閱 Azure 登陸區域 指引。
限制部署許可權。 實作 Azure RBAC 和 Microsoft Entra RBAC 中所述的角色型存取控制 （RBAC） 最佳做法。 將適當的許可權指派給使用者。 使用讀取者角色將未經授權的資源建立風險降到最低。
定期進行稽核。 使用 Azure Advisor 來識別未使用或使用量過低的 Azure 資源。 使用 成本管理 來分析您的雲端支出，並移除造成不必要成本的無主資源。 請記住，並非所有 Azure 資源都會產生費用。 在 Azure Resource Graph 中執行查詢，以維護精確的資源清查。
管理搬遷
定期評估您目前的 Azure 區域，以判斷將工作負載重新放置其他地方是否可提升效率、降低成本或增強效能。
瞭解搬遷驅動因素。 瞭解搬遷驅動因素可確保每個搬遷都有有效的業務理由，因為搬遷涉及風險和成本。 搬遷的常見業務理由包括業務擴充、法規合規性需求，以及接近使用者。
管理重新配置風險。 管理重新配置風險可防止中斷並維持合規性。 定義可接受的停機時間視窗、與專案關係人溝通影響，並確保遵守組織原則和產業法規。
管理重新配置成本。 管理重新配置成本可防止在移轉期間花費不必要的費用。 一次傳輸數據、移除重複的環境，以及比較區域 Azure 價格。 檢閱 Azure 頻寬定價。
管理重新配置專案。 小型小組應一次移轉一個工作負載，並集中執行。 大型小組應同時重新放置多個工作負載，以透過協調規劃來達到效率。
如需詳細資訊，請參閱 重新放置工作負載。
管理作業系統
當您使用虛擬機時，也必須管理作業系統。 請遵循下列步驟：
自動化虛擬機維護。 在 Azure 中，使用 自動化工具 來建立和管理 Azure 虛擬機。 使用 Azure 機器組態 以程式碼的方式稽核或設定作業系統設定，用於 Azure 和混合環境中的機器。
更新作業系統。 您必須 管理客體更新和主機維護，以確保作業系統為安全目的而保持最新狀態。
監控虛擬機器內部作業。 使用 Azure 變更追蹤和清查服務 來強化虛擬機器內部作業的稽核和治理。 它會監視變更，並提供 Azure、內部部署和其他雲端環境伺服器的詳細清查記錄。
Azure 管理工具
| 類別 | 工具 | 描述 |
|---|---|---|
| 管理變更 | 變更分析 | 偵測組態變更並說明其根本原因 |
| 管理變更 | Azure 政策 | 強制執行、稽核或防止修改雲端資源 |
| 管理變更 | Bicep 部署架構 | 防止未經授權的變更。 |
| 管理安全性 | Azure 安全性基準 | 提供可用安全性功能和最佳安全性設定的指引 |
| 管理安全性 | Well Architected Framework 的安全性支柱 | 工作負載設計的安全性指引 |
| 管理安全性 | Azure 服務指南 （從 [安全性] 區段開始） | Azure 服務的安全性設定建議 |
| 管理安全性 | Microsoft Entra 身份識別 | 提供統一的身分識別管理 |
| 管理安全性 | 雲端防護者 (Defender for Cloud) | 將資源設定與安全性標準對齊 |
| 管理安全性 | Microsoft Sentinel | 提供安全資訊與事件管理（SIEM）和安全性協調、自動化與回應（SOAR） |
| 管理安全性 | Azure RBAC | 基於角色的指派提供安全的存取權限 |
| 管理安全性 | Azure ABAC | 根據屬性條件授與安全存取權 |
| 管理安全性 | Microsoft Entra 身分識別治理 | 管理存取工作流程和身分識別生命週期 |
| 管理安全性 | 特權身分管理 | 提供即時特權存取 |
| 管理安全性 | Microsoft Entra 多重驗證（MFA） | 強制執行多重驗證 |
| 管理安全性 | 條件式存取 | 強制執行以內容為基礎的驗證 |
| 管理安全性 | 自助式密碼重設 | 允許安全的用戶密碼重設 |
| 管理合規性 | Azure 政策 | 強制執行標準和保護資源設定 |
| 管理數據 | Microsoft Purview | 控管和分類敏感數據 |
| 管理數據 | Azure 政策 | 防止或稽核非預期的修改或刪除資源 |
| 管理數據 | 資源鎖定 | 防止非預期的修改或刪除 |
| 管理成本 | 監視成本 | 監視對於管理雲端成本至關重要 |
| 管理雲端資源 | Azure 政策 | 強制執行、稽核或防止修改雲端資源 |
| 管理雲端資源 （入口網站部署） | ARM 範本匯出 | 將資源組態匯出為 IaC 範本 |
| 管理雲端資源 （入口網站部署） | Azure 監視器警示 | 通知相關人員資源變更 |
| 管理雲端資源 （程式代碼部署） | 肱二頭肌 | 以程式碼管理 Azure 資源的基礎設施 |
| 管理雲端資源 （程式代碼部署） | Bicep 部署架構 | 支援版本控制的部署，並防止未經授權的變更 |
| 管理雲端資源 （程式代碼部署） | Terraform | 以程式代碼管理多重雲端基礎結構 |
| 管理雲端資源 （程式代碼部署） | ARM 範本 | 使用範本定義及部署 Azure 資源 |
| 管理雲端資源 （程式代碼部署） | ARM 範本規格 | 版本和管理ARM範本以進行一致性 |
| 管理雲端資源 （程式代碼部署） | GitHub Actions（GitHub 行動） | 自動化建置、測試和部署管線 |
| 管理雲端資源 （程式代碼部署） | Azure Pipelines | 自動化建置和部署流程 |
| 管理偏移 | Azure 政策 | 強制執行、稽核或防止修改雲端資源 |
| 管理偏移 | 變更分析 | 偵測並說明組態變更 |
| 管理偏移 | Bicep 假設情境 | 預覽潛在的設定變更 |
| 管理偏移 | Terraform 計畫 | 預覽 Terraform 部署前的潛在變更 |
| 管理偏移 | ARM 範本 What-If | 預覽潛在的設定變更 |
| 管理作業系統 | Azure 機器配置 | 稽核以及配置操作系統設定為配置即代碼 |
| 管理作業系統 | Azure 變更追蹤與庫存服務 | 監視和記錄操作系統的變更 |
| 管理作業系統 | 自動化工具 | 自動化虛擬機維護 |