治理反模式

發行項
03/22/2023

客戶通常會在採用雲端服務的治理階段遇到反模式。請花一些時間了解共同責任，可協助您避免這些反模式，因為是在現有的架構而不是您自己的架構上建立安全性策略。

反模式：誤解共同責任

當您採用雲端服務時，對於不同的服務模型，您不一定會清楚您的責任到哪裡結束，而雲端提供者的責任又是從哪裡開始。必須具備雲端技能和知識，才能針對使用不同服務模型的工作項目建立處理程序和做法。

範例：假設雲端提供者管理更新

公司人力資源 (HR) 部門成員會使用基礎結構即服務 (IaaS) 在雲端設定許多 Windows 伺服器。他們假設雲端提供者會管理更新，因為現場 IT 通常會處理更新安裝。 HR 部門不設定更新，因為他們並不知道 Azure 預設不會部署和安裝作業系統更新。因此，伺服器不符合規範且會造成安全性風險。

偏好結果：建立整備計劃

了解雲端的共同責任。組建和建立整備計劃。整備計劃可以為學習和發展專業知識創造持續不斷的動力。

反模式：假設現成的解決方案提供安全性

公司通常會將安全性視為雲端指定提供的服務。雖然這項假設通常是正確的，但大部分環境還是必須遵守合規性架構需求，而這可能與安全性需求不同。 Azure 提供基本的安全性，且 Azure 入口網站可透過適用於雲端的 Microsoft Defender提供更高階的安全性。但是，當您建立訂用帳戶時，強制執行合規性和安全性標準並不是現成可用的體驗。

範例：疏忽雲端安全性

某家公司在雲端開發新的應用程式。該應用程式會根據不同的平台即服務 (PaaS) 服務來選擇架構，再加上一些用於偵錯的 IaaS 元件。將應用程式發行至生產環境之後，該公司發現其中一個跳躍伺服器遭到入侵，且正在將資料擷取到未知的 IP 位址。該公司發現問題出在跳躍伺服器的公用 IP 位址和容易猜到的密碼上。如果該公司更多關注雲端安全性，就可以避免此情況。

偏好結果：定義雲端安全性策略

定義適當的雲端安全性策略。如需詳細資訊，請參閱 CISO 雲端整備指南，並請您的資安長 (CISO) 也參閱本指南。其中的內容說明安全性平台資源、隱私權與控制、合規性和透明度等主題。

深入瞭解 Azure 安全性效能評定中的安全雲端工作負載。使用網際網路安全中心發佈的 CIS Controls v7.1 作為建置基礎，並遵循美國國家標準和技術局的 NIST SP800-53，即可處理大部分的安全性風險和措施。

請使用適用於雲端的 Microsoft Defender 來識別風險、調整最佳做法，以及改善您公司的安全性狀態。

使用 Azure 原則和 Azure 藍圖來實行或支援公司特定、自動化的合規性和安全性需求。

反模式：使用自訂合規性或治理架構

推出的自訂合規性和治理架構不是以業界標準為基礎，因為難以將自訂架構轉換為雲端設定，所以會大幅增加雲端採用時間。這種情況會造成將自訂量值和需求轉換成可實作的安全性控制項所需的工作量增加。大部分公司都必須遵守類似的安全性與合規性需求組合。這樣一來，大部分的自訂合規性和安全性架構都只會與目前的合規性架構略有不同。有額外安全性需求的公司可以考慮建立新的架構。

範例：使用自訂安全性架構

公司的 CISO 指派 IT 安全性員工負責制定雲端安全性策略與架構的工作。 IT 安全性部門並不是依據產業標準來建立新的架構，而是以目前的內部部署安全性原則為基礎。完成雲端安全性原則之後，AppOps 和 DevOps 小組就無法實作雲端安全性原則。

Azure 提供更完整的安全性與合規性結構，與公司本身的架構不同。 CISO 小組認為 Azure 控制項與其本身的合規性和安全性規則不相容。如果是以標準化控制項作為架構建立基礎，就不會產生這種結論。

偏好結果：依賴現有的架構

在您建立或推出自訂公司合規性架構之前，請先使用或建立現有的架構，例如 CIS Controls v7.1 或 NIST SP800-53。現有架構可讓轉換至雲端安全性設定變得更容易且較可測量。如需架構實作的其餘相關資訊，請參閱 Azure 藍圖範例頁面。用於通用合規性架構的藍圖也適用於 Azure。