定義安全性策略
安全性組織的最終目標不會隨著雲端服務的採用而有所改變，但會改變達成這些目標的方式。 安全性小組仍必須專注降低遭受攻擊的商業風險，並努力將機密性、完整性和可用性保證建立於所有資訊系統和資料中。
將您的安全性策略現代化
隨著組織採用雲端並逐漸於雲端上運作，安全性小組需要將策略、架構和技術現代化。 雖然變更的規模大小和數量在一開始可能會令人望而生畏，但安全性計畫的現代化讓安全性得以擺脫一些與傳統方法相關的痛苦負擔。 組織可以暫時使用傳統策略和工具來運作，但這種方法很難跟上雲端和威脅環境的變化步調：
- 如果安全性小組採用傳統的「獨立」安全性思維，回答一律以「不」為開頭 (而不是在實現商務目標的同時與 IT 和商務小組合作降低風險)，則安全性小組可能會被排除在雲端採用決策之外。
- 如果安全性小組只使用舊版的內部部署工具，並僅遵守網路周邊專用的原則來進行所有防護和監視，則會難以偵測並防禦雲端攻擊。
以雲端規模監視和保護
雲端規模的防護是重大的轉型工作，會強制使用雲端原生偵測和自動化功能，並引進身分識別周邊來協助監視和保護雲端和行動資產。
- Microsoft 身分識別平台可協助您在應用程式中納入新式驗證和授權機制。
- Microsoft Sentinel 提供整個組織的雲端原生安全性分析和威脅情報，讓您能夠利用威脅情報的大型存放庫，以及幾乎無限制的雲端處理和儲存功能，來提供更完善的威脅偵測功能。
我們建議安全性小組採用敏捷方法來現代化安全性：迅速將策略中最重要的層面現代化、持續以遞增的方式進行改善，並向前邁進。
雲端安全性與來自雲端的安全性
當您的組織採用雲端服務時，安全性小組需朝向兩個主要目標努力：
- 雲端安全性 (保護雲端資源)：安全性應整合至雲端服務的規劃和操作，以確保這些核心安全性保證一致地套用至所有資源。
- 來自雲端的安全性 (使用雲端來轉換安全性)：應立即開始規劃安全性並思考如何使用雲端技術，將安全性工具和程序現代化，特別是原生整合的安全性工具。 安全性工具會逐漸裝載至雲端，並提供在內部部署環境中窒礙難行甚至無法進行的功能。
保護軟體定義的資料中心
許多組織一開始會將雲端資源視為另一個虛擬資料中心，是雲端安全性一個有效率的起點。 當組織使用來自雲端的安全性逐漸現代化時，大部分的組織都會發現這種思維模式快速遭到淘汰。 確保軟體定義資料中心的安全性，可提供內部部署模型所無法提供的功能。 裝載於雲端的安全性工具能提供：
- 快速啟用和調整的安全性功能。
- 高效率的資產詳細目錄和安全性設定檢疫探索。
部署適用於雲端的 Microsoft Defender 可讓您持續評估組織的安全性態勢和控制項。 這能增強雲端資源的安全性態勢，並透過其整合的 Microsoft Defender 方案，使用適用於雲端的 Defender 來保護在 Azure、混合式和其他雲端平台中執行的工作負載。 深入了解適用於雲端的 Microsoft Defender。
注意
Azure 資訊安全中心和 Azure Defender 現在稱為「適用於雲端的 Microsoft Defender」。 我們也已將 Azure Defender 方案重新命名為 Microsoft Defender 方案。 例如，適用於儲存體的 Azure Defender 現在稱為適用於儲存體的 Microsoft Defender。
適度的安全性衝突
安全性當然會產生讓流程變慢的衝突，因此請務必找出您 DevOps 和 IT 程序中的健康情況良好與不佳的元素：
- 良性衝突：就像運動中的阻力可讓肌肉更強壯，納入適度的安全性衝突，便可在適當的時機強迫進行批判性思考，進而強化系統或應用程式。 通常採取的形式是在設計 (稱為 威脅分析模型) 期間考量攻擊者可能會嘗試危害應用程式或系統的方式和原因，並檢閱、識別及在理想情況下修復攻擊者可在軟體程式碼、設定或操作實務中利用的潛在弱點。
- 狀況不良的衝突：對價值的妨礙大於保護。 當工具產生的安全性錯誤有較高的誤判為真率 (例如誤報) 時，或在探索或修正安全性問題上的努力遠超過潛在攻擊的影響時，這種情況就往往會發生。
獨立且整合的責任
提供機密性、完整性和可用性保證，需要安全性專家操作專用的安全性功能，並與組織中的其他團隊密切合作：
- 獨特的安全性功能：安全性小組會執行組織中其他地方沒有的獨立功能，例如安全性作業、弱點管理 (例如虛擬機器、容器) 和其他功能。
- 將安全性整合至其他功能：當組織中的其他小組和部門負責推動商務計畫、評估風險、設計或開發應用程式，以及操作 IT 系統時，安全性小組也可擔任他們的主題專家。 安全性小組向這些小組提供關於攻擊者、攻擊方法和趨勢、可能允許未經授權存取的漏洞，與風險降低步驟或因應措施選擇及其潛在優點或陷阱等相關專業知識及背景。 這項安全性功能類似於品質功能，因為它會交織在大大小小的各處，協助達成單一成果。
在執行這些職責的同時，要跟上雲端快速的變化步調和企業轉型，需要安全性小組將其工具、技術和流程現代化。
轉型、心態和期望
許多組織都是在組織中同時管理多項轉型。 這些內部轉換之所以會開始的常見原因，是因為幾乎所有的外部市場都會轉換成符合使用行動和雲端技術的新客戶喜好設定。 組織通常會面臨新新創公司的競爭威脅，以及傳統競爭者的數位轉型，而這些傳統競爭者可能會打亂市場。
內部轉型流程通常包括：
- 企業的數位轉型，以把握新的商機，並保持對數位原生新創公司的競爭力。
- IT 組織的技術轉型，以支援雲端服務的計畫、現代化的開發實務，以及相關的變更。
- 安全性轉型以適應雲端，同時應對日益複雜的威脅環境。
內部衝突的成本可能很高
變更會產生壓力和衝突，可能會使決策陷入停頓。 尤其是在安全性方面，安全性風險的責任通常錯放在主題專家 (安全性小組) 身上，而不是商務成果和所有其他風險類型負責的資產擁有者 (企業負責人)。 由於所有利害關係人都錯將安全性視為要解決的技術或絕對性問題，而非動態的持續性風險 (例如企業間諜和其他傳統的犯罪活動)，因此往往會發生這種責任錯置。
在此轉型期間，所有小組的領導者都必須積極減少衝突，因為這種衝突既可能會阻撓重要專案，也可能會鼓勵小組忽視安全性風險降低措施。 小組之間的內部衝突可能會導致：
- 安全性風險提升，例如可避免的安全性事件或受攻擊造成的業務損害增加 (特別是當小組因對安全性感到氣餒而忽視正常程序，或安全性方法老舊讓攻擊者輕易越過時)。
- 對企業或任務的負面影響，例如，當商務程序未啟用或更新的速度不夠快速以符合市場需求時 (通常是在安全性程序的關鍵商務計畫時)。
請務必留意小組內部和小組間的關係健康情況，以協助他們度過可能讓重要小組成員缺乏安全感且不安的變動性環境。 對於這些心態有耐心、理解並加以教育，並提供對未來的正向潛力，可讓您的小組更良好地度過這段期間，進而為組織推動良好的安全性成果。
領導者可透過下列具體的主動式步驟來協助推動文化變革：
- 公開示範其所期望的小組行為。
- 對變革所帶來的挑戰保持公開透明，包括強調領導者本身在適應上的掙扎。
- 定期提醒小組安全性現代化和整合的急迫性與重要性。
網路安全性復原
許多傳統的安全性策略一直都只專注於防止攻擊，但這種方法對新式威脅來說是不夠的。 安全性小組必須確保其策略不止於此，還能對攻擊快速偵測、回應及復原，以提升恢復能力。 組織必須假設攻擊者會入侵部分資源 (有時也稱為「假想缺口」)，並努力確保資源和技術設計在攻擊防護與攻擊管理之間取得平衡 (而不是僅嘗試防止攻擊的典型預設方法)。
許多組織已在此旅程上，因為近年來一直在處理數量與複雜度持續上升的攻擊。 這種旅程通常會從第一次重大事件開始，這可能會是一個情緒事件，人們不再認為侵害不會發生在自己身上，失去了安全感。 雖然不如失去生命般嚴重，但此事件可能會觸發類似的情緒，從否認開始，到最後以接受結束。 有些人對這種「失敗」的假設一開始可能會難以接受，但這與公認的「失效安全」(fail-safe) 工程準則很相似，而且這種假設可讓您的小組專注於定義更好的成功：復原能力。
NIST 網路安全性架構的功能是一份很實用的指南，說明如何在復原策略中平衡識別、保護、偵測、回應及復原等互補活動的投資。
關於網路安全性復原能力和網路安全性控制的最終目標，將在如何讓組織的風險降低中討論。
雲端如何改變安全性
轉移至雲端以獲得安全性，不單純只是一項技術變革，也是技術的世代交替，類似於從大型主機移至桌上型電腦，再至企業伺服器。 成功度過這場變革需要安全性小組在期望和思維上的根本轉變。 採取正確的心態和期望可減少組織內的衝突，並提高安全性小組的效率。
雖然這可以是任何安全性現代化方案的一部分，但雲端的快速變化使得採用這些計畫成為當務之急。
具有共同目標的合作關係。 在這個需快速決策且程序不斷演進的時代中，安全性不能再採取「獨立」的方法來核准或拒絕對環境所做的變更。 安全性小組必須與商務和 IT 小組密切合作，以建立有關生產力、可靠性和安全性的共用目標，並與這些合作夥伴共同合作來達成這些目標。
這種合作關係是「左移」(shift left) 的最終形式，也就是在程序早期中整合安全性的原則，讓修正安全性問題更加容易且更有效率的準則。 這需要所有參與者 (安全性、商務和 IT) 改革其文化特性，要求每個群組都必須了解其他群組的文化特性和規範，同時也讓其他群組了解自己的群組。
安全性小組必須：
- 了解商務和 IT 目標，以及各個目標重要的原因，以及他們打算如何在轉型過程實現這些目標。
- 分享安全性為何在這些商務目標和風險的背景下是重要的，其他小組可以做什麼來達成安全性目標，以及應該怎麼做。
雖然這不是一項簡單的工作，但對於要持續保護組織及其資產是不可或缺的。 這項合作關係可能會帶來良性的妥協，一開始可能只會符合最基本的安全性、商務和可靠性目標，但隨著時間推移，便會穩定地逐步改善。
安全性是持續性的風險，而不是一個問題。 罪行本身是無法被「解決」的。 就其核心而言，安全性只是一門風險管理學科，剛好著重於人類的惡意行為，而非自然事件。 就像所有風險一樣，安全性並不是解決方案可以修正的問題，而是從負面事件，也就是攻擊所造成的可能性和影響的組合。 這與傳統的公司間諜和犯罪活動最相仿，因為組織面對的是具有財務動機得成功攻擊組織的人。
生產力或安全性上的成功是兩者相輔相成的。 在現今「不創新就會被淘汰」的環境中，組織必須專注於安全性與生產力。 如果組織缺乏生產力，且沒有推動新的創新，便可能會失去市場中的競爭力，進而導致財務狀況不佳或終至失敗。 如果組織不安全，讓攻擊者奪去資產的控制權，便可能會失去在市場中的競爭力，進而導致財務狀況不佳或終至失敗。
沒有人是完美的。 沒有任何組織能完美地採用雲端，即使是 Microsoft。 Microsoft 的 IT 和安全性小組努力解決許多與客戶所面臨的相同挑戰，像是了解如何完善程序結構、平衡對舊版軟體與尖端創新的支援，及消除雲端服務中的技術缺口。 隨著這些小組學習如何更妥善地操作和保護雲端，他們也積極透過這類文件與 IT 展示網站上的其他人分享學習到的經驗，同時持續向我們的工程小組和協力廠商提供意見回饋，以改善其產品。
根據我們的經驗，我們建議讓小組遵循持續學習和改善的標準，而非遵循完美的標準。
轉型的機會。 請務必將數位轉型視為安全性的正向機會。 雖然很容易就看到這項變革所存在的潛在不利因素和風險，但同時也很可能會錯失重塑安全性角色並在決策桌上贏得一席之地的機會。 與商務合作可能會增加安全性投資、減少安全性方面的重複性工作，並因為與組織的使命更加相繫，而讓安全性工作更有成就感。
採用共同責任模型
在雲端中裝載 IT 服務，可為雲端提供者與客戶租用戶之間的工作負載分割營運和安全性責任，建立共同承擔責任的實際合作關係。 所有安全性小組都必須研究並了解這項共同責任模型，使其流程、工具和技能組合適應雲端新世界。 這有助於避免無意間在安全性態勢中產生差距或重疊，而導致安全性風險或浪費資源。
下圖說明在實質合作關係中，雲端廠商和雲端客戶組織之間的安全性責任如何分配：
由於雲端服務有不同的模型，每個工作負載的責任會有所不同，取決於其是否裝載於軟體即服務 (SaaS)、平台即服務 (PaaS)、基礎結構即服務 (IaaS) 或內部部署資料中心。
建構安全性計畫
下圖說明大部分安全性程式應遵循的三項主要安全性計畫，以調整其安全性策略和雲端安全性計畫目標：
在雲端中建立復原性的安全性態勢需要同時具備數個互補的方法：
信任但驗證： 針對雲端提供者所執行的責任，組織應該採用「信任但驗證」方法。 組織應該評估其雲端提供者的安全性做法，以及其所提供的安全性控制，以確保雲端提供者符合組織的安全性需求。
基礎結構和應用程式安全性的現代化：針對組織所控制的技術元素，優先考慮安全性工具和相關技能組合的現代化，以盡量降低雲端資源安全的涵蓋差距。 這是由兩個不同的互補性工作所組成：
基礎結構安全性：組織應該利用雲端，將其用來保護和監視許多應用程式所使用之通用組件的方法現代化，例如作業系統、網路和容器基礎結構。 這些雲端功能通常包括管理跨 IaaS 和內部部署環境的基礎結構元件。 最佳化此策略非常重要，因為此基礎結構受到在其中執行的應用程式和資料依賴，而這些應用程式和資料往往能達成關鍵的商務程序，並儲存重要的商務資料。
應用程式安全性：組織也應該將其所開發或為其開發的獨特應用程式和技術的安全性現代化。 隨著敏捷式 DevOps 程式的採用、開放原始碼元件的使用增加，以及引進雲端 API 和雲端服務來取代應用程式元件或互連應用程式，此專業領域正在快速變革。
因為這些應用程式往往能夠實現重要的商務程序，並儲存關鍵的商務資料，所以把握好這方面相當重要。
新式周邊：組織應有全方位的方法來保護所有工作負載的資料，組織應建立一致且集中管理身分識別控制項的新式周邊，以保護其資料、裝置和帳戶。 這會深深受到在 CISO 研討會的模組 3 中深入討論的零信任策略影響。
安全性與信任
在安全性中使用「信任」這個字眼可能會造成混淆。 本文件以兩種方式來提及這個詞，以說明此概念的實用應用層面：
- 「零信任」是一種常見的產業術語，指的是一種安全性策略，其假設公司或內部網路是敵對的 (需視為零信任)，並依此設計安全性。
- 信任但驗證是一種擷取本質的表達方式，指的是兩個不同的組織為達成共同的目標攜手合作，儘管可能各自有些其他的不同利益。 這簡單扼要地道出了組織與商業雲端提供者早期合作階段的許多細微差異。
雲端提供者及其實作和流程可能會負責達成合約和法規需求，而且可能會獲得或失去信任。 網路是一種無生命連線，在攻擊者的使用下，網路是不用面對後果的 (很像您無法要求道路或車輛替使用的罪犯負責)。
雲端如何改變安全性關係和責任
如同之前的轉換至新一代技術 (例如桌上型電腦運算和企業伺服器運算)，轉換至雲端運算會中斷長期建立的關係、角色、責任和技能組合。 我們過去數十年來已經習慣的工作內容無法完全對應至現在納入雲端功能的企業。 由於產業共同運作以正規化新的模型，組織必須盡可能專注于提供更清楚的心力，以協助管理在此變更期間模棱兩可的不確定性。
安全性小組會受到這些變革的影響，包括其所支援的商務和技術，以及其內部的現代化工作，以更完善地適應威脅者。 攻擊者正在積極演化，持續尋找組織的人員、程序和技術最容易被利用的弱點，而安全性必須發展能力和技術來處理這方面的問題。
本節將描述在雲端旅程上經常發生變化的重要關係，並提供將風險降至最低並採用改善機會的經驗：
在安全性與商務利害關係人之間：安全性領導階層需要提升與商務負責人的合作，使組織得以降低風險。 安全性負責人應能以安全性主題專家 (SME) 的身分來支援商務決策，並且應致力於成為受這些商務負責人信任的顧問。 這種關係有助於確保商務負責人在制定商業決策時考慮安全性風險、告知業務優先項目的安全性，並協助確保安全性投資與其他投資的優先順序受到適當的考慮。
在安全性領導階層和小組成員之間：安全性領導階層應將這些來自商務負責人的見解帶回其小組，以引導其投資重點。
藉由設定與業務領導者其團隊的合作基調，而不是傳統的「獨立」關係，安全性負責人可以避免產生對立的互動，阻礙安全性和生產力目標。
安全性負責人應致力於為其小組提供明確的解釋，使其了解如何做出在生產力和安全性間取捨的日常決策，因為這可能對其小組而言是新的概念。
在應用程式和基礎結構小組之間 (與雲端提供者)：因為 IT 和安全性產業中的多項趨勢，這個關係正在發生重大變革，目的在提高創新速度和開發人員的生產力。
舊的規範和組織部門已被打亂，但新的規範和部門也還在出現中，因此我們建議您暫且接受這種不確定性，並隨時掌握最新的思維，並嘗試適合您組織的做法，直到新的規範和功能都出現為止。 我們不建議在這方面中採用等待與觀望的方法，因為這可能會讓您的組織處於相當不利的競爭劣勢。
這些趨勢正挑戰著應用程式和基礎結構的角色和關係的傳統規範：
- DevOps 融合式領域：在其理想狀態下，這會有效地建立單一的高度功能性小組，將這兩套主題專業知識結合在一起，以快速創新、發行更新，及解決問題 (安全性和其他問題)。 雖然這種理想狀態需要花些時間才能實現，且其中的責任仍不明確，但組織已經從這個合作方式享受到了一些快速發行的好處。 Microsoft 建議將安全性整合到這個過程，以協助您了解這些文化特性、分享安全性經驗，並努力實現迅速發行安全可靠的應用程式這個共同目標。
- 容器化成為常見的基礎結構元件：應用程式逐漸由 Docker、Kubernetes 和類似技術的技術來裝載和協調。 這些技術擷取基礎作業系統設定和組態中的許多元素，可簡化開發和發行的過程。
雖然容器一開始是由開發小組所管理的應用程式開發技術，但卻即將成為共同的基礎結構元件，並逐漸移轉至基礎結構小組。 這個轉變在許多組織中仍在進行中，但這會是個自然且正面的發展，許多現有挑戰將得以透過傳統基礎結構技能組 (例如網路、儲存體和容量管理) 獲得完善的解決。
應為支援容器服務的基礎結構小組和安全性小組成員提供訓練、流程和工具，以協助管理、監視及保護這項技術。
無伺服器和雲端應用程式服務：目前業界的主流趨勢之一是減少建立或更新應用程式所需的時間和開發工作。
越來越多的開發人員也逐漸使用雲端服務來進行：
- 執行程式碼，而非在虛擬機器 (VM) 上和伺服器上裝載應用程式。
- 提供應用程式功能，而非開發自己的元件。 這個趨勢也帶來了無伺服器模型，即使用現有的雲端服務來執行一般功能。 雲端服務的數量和種類 (與其創新的步調) 也超過了安全性小組評估和核准使用這些服務的能力，讓他們只能有允許開發人員使用任何服務、嘗試防止開發小組使用未核准的服務，或嘗試找出更好的方法這幾種選擇。
- 無程式碼應用程式和 Power Apps：另一個新興的趨勢是使用無程式碼技術，例如 Microsoft Power Apps。 這項技術可讓沒有程式碼編寫技能的人員能夠建立可達成業務成果的應用程式。 由於這種低衝突、高價值的潛能，此趨勢可能會快速崛起，安全性專業人員最好能盡快了解其影響。 安全性工作應著重於人類在應用程式中可能犯錯誤的領域，也就是透過威脅模型化應用程式元件、互動/關聯性和角色權限，來設計應用程式和資產權限。
開發人員與開放原始碼元件作者之間：開發人員也可以使用開放原始碼元件和程式庫來提升效率，而非自行開發元件。 這種效率會帶來價值，但也會產生外部依賴性，以及需妥善維護和修補這些元件的需求，從而帶來安全性風險。 開發人員在使用這些元件時，實際上是承擔了安全性和其他錯誤的風險，且必須確保以自行開發程式碼的相同標準來有計畫地減輕這些風險。
在應用程式和資料之間：資料和應用程式安全性之間的界線越來越模糊，而新的法規則使資料/隱私權小組和安全性小組之間需要建立更密切的合作：
機器學習演算法：機器學習演算法與應用程式相似之處在於，它們是設計用來處理資料以取得結果。 主要差異包括：
高價值的機器學習：機器學習往往會帶來顯著的爭優勢，而且經常會被視為敏感性的智慧財產和營業秘密。
敏感度銘印：受監督的機器學習會使用資料集進行微調，將資料集的特性銘印在演算法上。 基於這個原因，調整過的演算法可能會因為用於訓練的資料集而被視為機密。 例如，使用祕密軍隊的基地資料集，訓練機器學習演算法在地圖上尋找祕密軍隊的基地，會使其成為機密資產。
注意
並非所有範例都如此顯而易見，因此請務必將小組與來自資料科學小組、商務利害關係人、安全性小組、隱私權小組和其他的適當利害關係人聚集在一起共同討論。 這些小組應有責任實現創新和責任的共同目標。 他們應該解決常見的問題，例如在不安全的設定中儲存資料複本的方式和位置、如何將演算法分類，以及您組織的任何疑慮。
Microsoft 已發佈負責任的 AI 準則，為我們的小組和客戶提供指引。
- 資料所有權和隱私權：GDPR 等法規增加了資料問題和應用程式的可見度。 應用程式小組現在能夠控制、保護和追蹤敏感性資料，層級與銀行和金融機構追蹤財務資料相當。 資料擁有者和應用程式小組必須對資料應用程式所儲存的資料和所需的控制項建立充分的了解。
組織與雲端提供者之間：當組織將工作負載裝載至雲端時，便是與每個雲端提供者建立了商務關係。 使用雲端服務通常會帶來商業價值，例如：
藉由減少新功能上市的時間，加速數位轉型計畫。
提高 IT 和安全性活動的價值：讓小組得以專注於更高價值 (商務相關) 的活動，而非執行由雲端服務能代表其更有效率進行的低層級日常工作。
增進可靠性與回應能力：相較於傳統內部部署資料中心，大多數新式雲端也會有很高的運作時間，並能可以快速縮放其規模 (例如，COVID-19 大流行期間)，並在雷擊等自然事件後提供復原能力 (對許多內部部署系統來說，這種事件會導致更長時間的停機)。
移轉至雲端雖然有其好處，但並不是沒有風險。 在組織採用雲端服務時，應考慮潛在的風險領域，包括：
商務持續性和災害復原：雲端提供者的商業模型是否財務健全，在貴組織使用服務的期間是否能維持存活及發展？ 如果雲端提供者遭遇財務困難或其他問題，供應商是否有制定條款以供客戶繼續使用服務，例如將其原始程式碼提供給客戶或設為開放原始碼？
如需有關 Microsoft 財務健康狀態的詳細資訊和文件，請參閱 Microsoft 投資人關係。
安全性：雲端提供者是否遵循業界最佳做法來執行安全性？ 是否已受到獨立法規機構的驗證？
- Microsoft Defender for Cloud Apps 可讓您探索超過 16,000 個雲端應用程式的使用情況，這些應用程式會根據 70 個以上的風險因素進行排名和評分，為您提供持續可見的雲端使用、影子 IT，以及影子 IT 為您的組織帶來的風險。
- Microsoft 服務信任入口網站為客戶提供法規合規性認證、稽核報告、滲透測試及其他服務。 這些文件包括許多內部安全性做法的詳細資料 (特別是 SOC 2 Type 2 報告和 FedRAMP Moderate 系統安全性計畫)。 適用於雲端的 Microsoft Defender 可管理安全性原則，並可顯示預先定義的產業和法規標準的符合層級。
商業競爭者：雲端提供者是您所在產業中的重要商務競爭者嗎？ 雲端服務合約中是否提供足夠的保護，或是否有其他方法來保護您的企業免於潛在的惡意行動？
請參閱這篇文章，以了解 Microsoft 如何避免與雲端客戶互相競爭。
多重雲端：許多組織都有事實上或刻意的多重雲端策略。 這可能是一個刻意的目標，以減少對單一供應商的依賴或取得獨特的優異功能，但也可能是因為開發人員選擇慣用或熟悉的雲端服務，或您的組織收購了另一家企業商務。 無論原因為何，此策略都可能會帶來需要加以管理的潛在風險和成本，包括：
- 因多重依賴所造成的停機時間：依賴多重雲端系統的架構會面臨更多的停機風險來源，因為雲端提供者 (或小組對其的使用) 的中斷可能會導致商務中止/中斷。 這種系統複雜性的增加也會提高中斷事件的可能性，因為小組成員不太可能完全了解一個更複雜的系統。
- 談判能力：較大型的組織也應該考慮單一雲端 (相互承諾/合作關係) 還是多重雲端策略 (能夠轉移企業) 能對其雲端提供者產生較大的影響力，使組織的功能要求獲得優先的考量。
- 維護開銷增加：IT 和安全性資源除了其現有的工作負載，還要跟上單一雲端平台帶來的變化，已經不堪負荷。 每個額外的平台都會進一步增加這種開銷，讓團隊成員無法從事更高價值的活動，例如，簡化技術程序以加速商務創新、向商務群組諮詢以更有效地運用技術等等。
- 人員配置和訓練：組織往往不會考慮到支援多個平台所需的人員配置需求，以及為保持對快速發行之新功能的了解和掌握所需的訓練。