分享方式：

治理反模式

  • 文章

您可能會在雲端採用的治理階段遇到反模式。 瞭解共同的責任，以及如何在現有的架構上建置安全性策略，以協助您避免這些反模式。

反模式：誤解共同責任

當您採用雲端時，不一定清楚您的責任結束位置，而雲端提供者的責任會從不同的服務模型開始。 需要雲端技能和知識，才能建置使用服務模型之工作專案的程式和作法。

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

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

慣用的結果：建立整備計劃

了解 雲端中的共同責任 。 建置並建立 整備計劃。 整備計劃可以創造持續學習和開發專業知識的勢頭。

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

公司通常會將安全性視為雲端服務固有的功能。 雖然此假設通常正確，但大部分的環境都需要遵守合規性架構需求，這與安全性需求不同。 Azure 提供基本安全性，Azure 入口網站 可透過 適用於雲端的 Microsoft Defender 提供更進階的安全性。 當您建立訂用帳戶時，您必須自定義解決方案，以強制執行合規性和安全性標準。

範例：忽略雲端安全性

公司會在雲端開發新的應用程式。 它會根據許多平臺即服務 （PaaS） 服務來選擇架構，再加上一些 IaaS 元件以供偵錯之用。 將應用程式發行至生產環境之後，公司發現其中一部跳躍伺服器已遭入侵，並將數據擷取至未知的IP位址。 該公司發現問題是跳躍伺服器的公用IP位址，以及容易猜測的密碼。 如果公司更專注於雲端安全性，公司可能會避免這種情況。

慣用的結果：定義雲端安全性策略

定義適當的 雲端安全性策略。 如需詳細資訊，請參閱 CISO 雲端整備指南。 請參閱本指南的首席資訊安全官（CISO）。 CISO 雲端整備指南討論安全性平臺資源、隱私權和控件、合規性和透明度等主題。

請參閱 Azure 安全性效能評定中的安全雲端工作負載。 以 來自因特網安全性中心的 CIS 控制 v7.1 為基礎，以及 國家標準與技術研究所的 NIST SP800-53 ，解決了大部分的安全性風險和措施。

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

使用 Azure 原則 和 Azure 原則 作為程式代碼解決方案，實作或支援公司特定的自動化合規性和安全性需求。

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

引進並非以業界標準為基礎的自定義合規性和治理架構，可大幅增加雲端採用時間。 這是因為從自定義架構到雲端設定的翻譯可能很複雜。 這種複雜性可以增加將自定義量值和需求轉譯為可實作的安全性控件所需的工作。 公司通常需要符合類似的安全性與合規性需求集。 因此，大部分的自定義合規性和安全性架構只會與目前的合規性架構稍有不同。 具有額外安全性需求的公司可以考慮建置新的架構。

範例：使用自定義安全性架構

公司的 CISO 會指派 IT 安全性員工來提出雲端安全性策略和架構的工作。 IT 安全性部門會建立以目前內部部署安全策略為基礎的新架構，而不是以業界標準為基礎。 完成雲端安全策略之後，AppOps 和 DevOps 小組難以實作雲端安全策略。

Azure 提供更完整的安全性和合規性結構，與公司自己的架構不同。 CISO 小組認為 Azure 控制件與自己的合規性和安全性規則不相容。 如果其架構是以標準化控件為基礎，則不會得出這個結論。

慣用的結果：依賴現有的架構

在您建立或引進自定義公司合規性架構之前，請先使用或建置現有的架構，例如 CIS 控件 7.1 版或 NIST SP 800-53。 現有的架構可讓轉換至雲端安全性設定更容易且更可測量。 如需架構實作的詳細資訊，請參閱 Azure 登陸區域實作選項。

下一步