共用方式為

保護您的雲端資產

  • 發行項

本文提供維護 Azure 雲端資產可靠性和安全性的最佳做法。 可靠性可確保您的雲端服務在最短的停機時間下維持運作。 安全性可保護您的資源的機密性、完整性和可用性。 對於成功的雲端作業而言，可靠性和安全性都很重要。

管理可靠性

可靠性管理牽涉到使用備援、複寫和定義的復原策略，將停機時間降到最低，並保護您的企業。 表 1 提供三個工作負載優先順序、可靠性需求範例（運行時間 SLO、最大停機時間、備援、負載平衡、複寫），以及符合服務等級目標（SLO） 的範例案例

表格 1. 工作負載優先順序和可靠性需求的範例。

優先權 業務影響 最小正常運作時間 SLO 每月停機時間上限 架構冗餘 負載平衡 數據復寫和備份 範例案例
高 （任務關鍵） 對公司聲譽或收入的立即和嚴重影響。 99.99% 4.32 分鐘 多區域 & 每個區域中的多個可用性區域 主動-主動 用於復原的同步跨區域數據複製 & 備份 任務關鍵基準
中等 可測量對公司聲譽或收入的影響。 99.9% 43.20 分鐘 多個區域 & 每個區域中的多個可用性區域 主動-被動 為復原而設的跨區域異步數據復寫 & 備份 可靠的 Web 應用程式模式
低 不會影響公司聲譽、流程或利潤。 99% 7.20 小時 單一區域 & 多個可用性區域 可用性區域備援 跨可用性區域同步數據複製 & 備份以便復原 App Service 基準
虛擬機基準設定

識別可靠性責任

可靠性責任會因部署模型而異。 使用下表來識別基礎結構 （IaaS）、平臺 （PaaS）、軟體 （SaaS） 和內部部署的管理責任。

責任 內部部署 IaaS （Azure） PaaS （Azure） SaaS
數據 ✔️ ✔️ ✔️ ✔️
程式代碼和運行時間 ✔️ ✔️ ✔️
雲端資源 ✔️ ✔️ ✔️
實體硬體 ✔️

如需詳細資訊，請參閱 可靠性共同責任。

定義可靠性需求

明確定義的可靠性需求對於運行時間目標、復原和數據遺失容錯至關重要。 請遵循下列步驟來定義可靠性需求：

  1. 排定工作負載的優先順序。 根據業務關鍵性和財務投資水準，將高、中或低優先順序指派給工作負載。 定期檢閱優先順序，以維持與商務目標的一致。

  2. 將運行時間服務等級目標 （SLO） 指派給所有工作負載。 根據工作負載優先順序建立運行時間目標。 優先順序較高的工作負載需要更嚴格的運行時間目標。 您的 SLO 會影響您的架構、數據管理原則、復原程式和成本。

  3. 識別服務等級指標 (SLI)。 使用 SLI 度量您的 SLO 的運行時間效能。 範例包括 服務健康狀態監控 和 錯誤率。

  4. 將復原時間目標 （RTO） 指派給所有工作負載。 RTO 會定義工作負載可接受的最大停機時間。 RTO 應該比您的年度容許停機時間更短。 例如，正常運行時間 SLO 99.99% 需少於 52 分鐘的年度停機時間（每月 4.32 分鐘）。 請遵循下列步驟：

    1. 估計失敗次數。 估計您認為每個工作負載每年可能會失敗的頻率。 針對具有作業歷程記錄的工作負載，請使用您的服務層級指標。 針對新的工作負載，請執行 失敗模式分析 以取得精確的估計值。

    2. 估計 RTO。 將每年允許的停機時間除以估計的失敗數目。 如果您估計每年發生四次失敗，則 RTO 必須是 13 分鐘或更少（52 分鐘/4 個失敗 = 13 分鐘 RTO）。

    3. 測試復原時間。 追蹤在故障轉移測試和實時失敗期間復原的平均時間。 從失敗中復原所需的時間必須小於「RTO」。 如果您的商務持續性解決方案需要數小時的時間

  5. 定義所有工作負載的恢復點目標 （RPO）。 判斷您的企業可以容忍的數據遺失量。 此目標會影響您復寫和備份數據的頻率。

  6. 定義工作負載可靠性目標。 針對工作負載可靠性目標，請參閱 Well-Architected 架構的 建議，以定義可靠性目標。

管理數據可靠性

數據可靠性涉及數據復寫（複本）和備份（時間點複本），以維護可用性和一致性。 如需與數據可靠性目標一致的工作負載優先順序範例，請參閱 表 2。

表 2. 具有範例數據可靠性設定的工作負載優先次序。

工作負載優先順序 正常運作時間 SLO 數據複寫 數據備份 範例案例
高 99.99% 跨區域同步數據復寫

跨可用性區域同步數據複寫		 高頻率、跨區域備份。 頻率應該支援 RTO 和 RPO。 任務關鍵性數據平臺
中等 99.9% 跨區域同步數據復寫

跨可用性區域同步數據複寫		 跨區域備份。 頻率應該支援 RTO 和 RPO。 Reliable Web App 模式中的資料庫和記憶體解決方案
低 99% 跨可用性區域同步數據複寫 跨區域備份。 頻率需要支援 RTO 和 RPO。 具有區域備援的基準 Web 應用程式中的數據復原能力

您的方法必須將數據可靠性設定與工作負載的 RTO 和 RPO 需求對齊。 請遵循下列步驟：

  1. 管理數據復寫。 根據工作負載的 RTO 和 RPO 需求，以同步或異步方式複寫您的數據。

    數據分配 數據複寫 負載平衡組態
    跨可用性區域 同步 （近乎即時） 大部分的 PaaS 服務會以原生方式處理跨區域負載平衡
    跨區域 （主動-主動） 同步 主動式負載平衡
    跨區域 （主動-被動） 非同步（週期性） 主動-被動設定

    如需詳細資訊，請參閱 複寫：資料備援。

  2. 管理數據備份。 備份適用於災害復原（服務失敗）、數據復原（刪除或損毀），以及事件回應（安全性）。 備份必須支援每個工作負載的 RTO 和 RPO 需求。 選擇符合 RTO 和 RPO 目標的備份解決方案。 偏好使用 Azure 的內建解決方案，例如 Azure Cosmos DB 和 Azure SQL Database 原生備份。 對於其他情況，包括內部部署資料，請使用 Azure 備份。 如需詳細資訊，請參閱 備份。

  3. 設計工作負載數據可靠性。 針對工作負載數據可靠性設計，請參閱 Well-Architected Framework 數據分割指南 和 Azure 服務指南 （從可靠性一節開始）。

管理程式代碼和運行時間可靠性

程式代碼和運行時間是工作負載責任。 遵循 Well-Architected 架構的 自我修復和自我保護指南，。

管理雲端資源可靠性

管理雲端資源的可靠性通常需要架構備援（重複的服務實例）和有效的負載平衡策略。 如需與工作負載優先順序一致的架構備援範例，請參閱 表 3。

表 3. 工作負載優先順序和架構備援範例。

工作負載優先順序 架構備援 負載平衡方法 Azure 負載平衡解決方案 範例案例
高 兩個區域 & 可用性區域 主動-主動 Azure Front Door （HTTP）

Azure 流量管理員 （非 HTTP）		 任務關鍵基準應用程式平臺
中等 兩個區域 & 可用區 主動-被動 Azure Front Door （HTTP）

Azure 流量管理員 （非 HTTP）		 可靠的 Web 應用程式模式架構指引
低 單一區域 & 可用性區域 跨可用性區域 Azure 應用程式閘道

新增適用於虛擬機的 Azure Load Balancer		 App Service 基準
虛擬機基準

您的方法必須實作架構備援，以符合工作負載的可靠性需求。 請遵循下列步驟：

  1. 估計架構的運行時間。 針對每個工作負載，計算複合 SLA。 只包含可能導致工作負載失敗的服務（重要路徑）。 請遵循下列步驟：

    1. 請收集 Microsoft 的運行時間 SLA，以涵蓋工作負載關鍵路徑上的每個服務。

    2. 如果您沒有獨立的關鍵路徑，請將每個相關服務的運行時間百分比乘以計算單一區域複合 SLA。 如果您有獨立的關鍵路徑，請在計算之前移至步驟 3。

    3. 當兩個 Azure 服務提供獨立的關鍵路徑時，請將獨立的關鍵路徑公式套用至這些服務。

    4. 針對多區域應用程式，將單一區域複合 SLA （N） 輸入到多重區域運行時間公式中。

    5. 比較計算的正常運行時間與目標服務水準 (SLO)。 視需要調整服務層級或架構備援。

    用例 公式 變數 例 解釋
    單一區域運行時間估計 N = S1 × S2 × S3 × ... × Un N：單一區域關鍵路徑上 Azure 服務的複合 SLA。
    S：每個 Azure 服務的 SLA 運行時間百分比。
    n：重要路徑上的 Azure 服務總數。    		 N = 99.99% （應用程式） × 99.95% （資料庫） × 99.9% （快取） 包含應用程式（99.99%）、資料庫（99.95%）和快取（99.9%）的簡化負載位於單一關鍵路徑中。
    獨立關鍵路徑估計 S1 x 1 - [（1 - S2） × （1 - S3）] S：提供獨立關鍵路徑的 Azure 服務的 SLA 運行時間百分比。 99.99% （app） × （1 - [(1 - 99.95% 資料庫) × (1 - 99.9% 快取)]） 兩個獨立關鍵路徑。 資料庫 （99.95%） 或快取 （99.9%） 可能會失敗，而不會停機。
    多區域可用時間估算 M = 1 - （1 - N）^R M：多重區域運行時間估計值。
    N：單一區域複合 SLA。
    R：使用的區域數目。    		 如果 N = 99.95% 和 R = 2，則 M = 1 - （1 - 99.95%）^2 部署在兩個區域中的工作負載。

  2. 調整服務層級。 在修改架構之前，請評估不同的 Azure 服務層級 （SKU） 是否符合您的可靠性需求。 某些 Azure 服務層級可以有不同的正常運作時間 SLA，例如 Azure 受控磁碟。

  3. 新增架構備援。 如果您的目前運行時間估計低於 SLO，請增加備援：

    1. 使用多個可用性區域。 設定工作負載以使用多個可用性區域。 可用性區域如何提升您的正常運行時間可能很難評估。 只有少數幾個服務具有考慮可用性區域的運行時間 SLA。 當 SLA 計入可用性區域時，請在您的正常運行時間估算中使用它們。 如需一些範例，請參閱下表。

      Azure 服務類型 具有可用性區域 SLA 的 Azure 服務
      計算平臺 App Service、
      Azure Kubernetes Service、
      虛擬機
      數據存放區 Azure 服務總線，
      Azure 記憶體帳戶，
      Azure Cache for Redis
      Azure 檔案服務進階層
      資料庫 Azure Cosmos DB，
      Azure SQL Database，
      適用於 MySQL 的 Azure 資料庫、
      適用於 PostgreSQL 的 Azure 資料庫，
      適用於 Apache Cassandra 的 Azure 受控實例
      負載平衡器 應用程式閘道
      安全 Azure 防火牆

    2. 使用多個區域。 通常需要多個區域才能符合運行時間 SLO。 使用全域負載平衡器 （Azure Front Door 或流量管理員） 進行流量分配。 多區域架構需要仔細的數據一致性管理。

  4. 管理架構備援。 決定如何使用備援：您可以使用架構備援作為每日作業的一部分（作用中）。 或者，您可以在災害復原案例中使用架構備援（被動）。 如需範例，請參閱表 3 。

    1. 跨可用性區域的負載平衡。 主動使用所有可用性。 許多 Azure PaaS 服務會自動管理跨可用性區域的負載平衡。 IaaS 工作負載必須使用 內部負載平衡器，以跨可用性區域進行負載平衡。

    2. 跨區域的負載平衡。 根據可靠性需求判斷多區域工作負載是否應該執行主動-主動或主動-被動。

  5. 管理服務組態。 一致地將設定套用至 Azure 資源的備援實例，因此資源的行為方式相同。 使用 基礎結構作為程式代碼 來維持一致性。 如需詳細資訊，請參閱 重複的資源組態。

  6. 設計工作負載可靠性。 如需工作負載可靠性設計，請參閱 Well-Architected Framework：

    工作負載可靠性 指導
    可靠性支柱 高可用性多重區域設計
    設計備援
    使用可用性區域和地區
    服務指南 Azure 服務指南 （從可靠性一節開始）

如需詳細資訊，請參閱 備援。

管理商務持續性

從失敗中復原需要清楚的策略，才能快速還原服務，並將中斷降到最低，以維持用戶滿意度。 請遵循下列步驟：

  1. 準備失敗。 根據高、中、低優先順序為工作負載建立個別的復原程式。 數據可靠性、程式代碼和運行時間可靠性，雲端資源可靠性 是準備失敗的基礎。 選取其他復原工具以協助進行商務持續性準備。 使用 Azure Site Recovery 來處理內部部署和虛擬機器上的伺服器工作負載，例如。

  2. 測試和文件復原方案。 定期測試故障轉移和容錯回復程式，以確認您的工作負載符合復原時間目標 （RTO） 和恢復點目標 （RPO）。 請清楚記載復原計劃的每個步驟，以在事件期間輕鬆參考。 確認 Azure Site Recovery 等復原工具符合您指定的 RTO。

  3. 偵測故障。 採用主動式方法快速識別中斷，即使此方法可能增加誤報，也應使用此方法。 藉由將停機時間降到最低並維護使用者信任，排定客戶體驗的優先順序。

    1. 監控故障。 監視工作負載，以在一分鐘內偵測中斷。 使用 Azure 服務健康狀態 和 Azure 資源健康狀態，並使用 Azure 監視器警示 來通知相關小組。 將這些警示與 Azure DevOps 或 IT 服務管理 （ITSM） 工具整合。

    2. 收集服務等級指標 （SLA）。 定義並收集作為 SLA 的計量來追蹤效能。 請確保您的團隊使用這些指標來測量工作負載效能，並與您的服務等級目標（SLO）進行比較。

  4. 回應失敗。 讓復原回應符合工作負載優先順序。 實作故障轉移程序，以立即將請求重新導向至備援基礎設施和數據副本。 一旦系統穩定下來，請解決根本原因、同步數據，然後執行故障回復程序。 如需詳細資訊，請參閱 故障轉移和容錯回復。

  5. 分析失敗。 識別問題的根本原因，然後解決問題。 記錄任何課程並進行必要的變更。

  6. 管理工作負載失敗。 針對工作負載災害復原，請參閱 Well-Architected Framework 災害復原指南 和 Azure 服務指南（從可靠性一節開始）。

Azure 可靠性工具

用例 解決方案
數據復寫、備份和商務持續性 Azure 服務指南 （從可靠性一節開始）

快速參考：
Azure Cosmos DB
Azure SQL Database
Azure Blob 儲存體
Azure 檔案服務
數據備份 Azure 備份
商務持續性 （IaaS） Azure Site Recovery
多區域負載平衡器 Azure Front Door （HTTP）
Azure 流量管理員 （非 HTTP）
多重可用性區域負載平衡器 Azure 應用程式閘道 （HTTP）
Azure Load Balancer （非 HTTP）

管理安全性

使用反覆式安全性程序來識別並減輕雲端環境中的威脅。 請遵循下列步驟：

管理安全性控制

管理您的安全性控制，以偵測雲端資產的威脅。 請遵循下列步驟：

  1. 標準化安全性工具。 使用標準化工具來偵測威脅、修正弱點、調查問題、保護數據、強化資源，以及大規模強制執行合規性。 請參閱 Azure 安全性工具。

  2. 為您的環境建立基準。 記錄雲端資產的正常狀態。 監視安全性，並記錄網路流量模式和用戶行為。 使用 Azure 安全性基準 和 Azure 服務指南 來開發服務的基準組態。 此基準可讓您更輕鬆地偵測異常和潛在的安全性弱點。

  3. 套用安全性控制件。 實作訪問控制、加密和多重要素驗證等安全性措施，強化環境並減少入侵的可能性。 如需詳細資訊，請參閱管理安全性 。

  4. 指派安全性責任。 指定跨雲端環境進行安全性監視的責任。 定期監視和比較基準可讓您快速識別事件，例如未經授權的存取或不尋常的數據傳輸。 定期更新和稽核可使您的安全性基準在面對不斷演變的威脅時保持有效。

如需詳細資訊，請參閱 CAF Secure。

管理安全性事件

採用程式與工具，從安全性事件中復原，例如勒索軟體、阻斷服務或威脅執行者入侵。 請遵循下列步驟：

  1. 準備事件。 開發事件回應計劃，明確定義調查、風險降低和通訊的角色。 定期測試計劃的有效性。 評估和實作弱點管理工具、威脅偵測系統和基礎結構監視解決方案。 透過基礎結構強化和建立工作負載特定的復原策略，減少攻擊面。 請參閱 事件回應概觀 和 事件回應劇本。

  2. 偵測事件。 使用安全性資訊和事件管理 （SIEM） 工具，例如 Microsoft Sentinel，以集中您的安全性數據。 使用Microsoft Sentinel 安全性協調流程、自動化和回應功能 （SOAR） 自動化例行安全性工作。 將 威脅情報摘要 整合到 SIEM 中，以深入瞭解與雲端環境相關的敵人策略。 使用 Microsoft Defender for Cloud 定期掃描 Azure 是否存在漏洞。 Microsoft Defender 整合 與 Microsoft Sentinel，以提供安全性事件的統一檢視。

  3. 回應事件。 偵測到事件時立即啟動事件響應計劃。 快速啟動調查和風險降低程式。 啟用災害復原計劃以還原受影響的系統，並清楚地將事件詳細數據傳達給小組。

  4. 分析安全性事件。 在每個事件之後，請檢閱威脅情報，並根據從公用資源學到的經驗和見解來更新您的事件回應計劃，例如 MITRE ATT&CK 知識庫。 評估弱點管理和偵測工具的有效性，並根據事件後分析來精簡策略。

如需詳細資訊，請參閱 管理事件回應 （CAF Secure）。

Azure 安全性工具

安全性功能 Microsoft解決方案
身分識別和存取管理 Microsoft Entra ID
角色型訪問控制 Azure 角色型訪問控制
威脅偵測 適用於雲端的 Microsoft Defender
安全性資訊管理 Microsoft Sentinel
數據安全性和控管 Microsoft Purview
雲端資源安全性 Azure 安全性基準
雲端治理 Azure 原則
端點安全性 Microsoft Defender 適用於端點
網路安全性 Azure 網路監看員
工業安全性 Microsoft Defender 適用於 IoT