共同的責任模型

作者：Mark Nunnikhoven（雲端研究副總）

我經常被問到雲端環境所面臨最大的網路威脅是什麼。當人們提出這問題時，似乎期望著如同好萊塢電影情節那樣的答案。不過事實要簡單得多。

當前雲端環境的頭號威脅是雲端服務配置不當。

儘管雲端環境有清楚的運營模式，但是團隊仍會犯上簡單錯誤或忽略正確設定雲端所用服務這一簡單任務。

雲端安全性是用共同的責任模型運作。這個模型會指示誰該負責雲端內的哪項操作任務，安全性只是這些任務的一部分。

模型本身很簡單。

有六個領域跟日常運作有關。從實體基礎設施（系統所在的建築物是否安全，付款購買等）一直到基礎設施、虛擬化、作業系統、應用程式和資料。

在傳統的本地端布署環境，你的組織負責這所有六個領域。通常會將工作分成數個團隊，但最終全都都會匯報給組織內的同一個人，通常是資訊長（CIO）。

當你移轉到雲端時，至少有一半的職責會分散到你的雲端服務商身上。

像是執行實例或虛擬機這樣的基礎設施（IaaS）等級服務，你會接手作業系統這個層級。作業系統的設定和維護完全取決於你和你的團隊。

所以你想的話是可以將管理員密碼或root密碼設為password，但不要。你有能力這麼做，但這也會是你的責任。

當你轉向更抽象化或SaaS類型的服務時，你的責任會減少。這表示你可以專注在較少的領域來改善安全狀態。

信任但要驗證

任何名符其實的資安專家都不會輕易地相信雲端服務商說自己有履行該模型所規範的職責，也不該這麼做。

這裡就是合規性證明起作用的地方。三大雲端服務商都擁有大量的稽核證據來展現自己是如何提供世界一流的安全性。

從完全的本地端合規性框架到廣泛適用的框架（如PCI-DSS或SOC1或ISO 27001）都應該減少對雲端服務商是否遵循模型規範的擔憂。

你可以更進一步地向服務商索取針對特定合規性框架的稽核結果副本。事實上，時間到了你的合規性報告也會需要這份報告。

配置不當從何而來？

回到配置不當這個主要雲端威脅，主要來自兩個不同地方。首先是對誰該對什麼負責的誤解。

在這些情境裡，建構在雲端的團隊期望自己的服務商建立安全控制並監控特定問題，而實際上這些問題是團隊的責任。

一個常見而令人遺憾的例子是，團隊在雲端環境用預先配置的部署服務來使用虛擬機或執行實例。在這些案例中，雲端服務商簡化了通用配置在雲端啟動和執行所需的步驟。

這很好，但問題是，一旦這配置被啟動並執行，團隊便該負起建構解決方案來加以修補、強化和維護該配置的責任。

你的服務商帶給你領先優勢並不代表你不用參加剩餘階段的比賽！

配置不當會出現的第二個地方是簡單錯誤。雲端是團隊的放大器。只要一個API呼叫，你就幾乎可以啟動整個資料中心。壞處就在於較小的團隊要負責更加廣泛的技術組合和服務。

團隊不可避免地會犯一些簡單錯誤，從而導致不必要的風險。解決此問題的一種關鍵方法是採用”用系統而非人工（Systems over people）”的軟體原則。

用系統而非人工（Systems Over People）

這原則很簡單。雲端解決方案的大部分工作應由系統完成而非人工。自動化是成功的關鍵。

假設你的團隊所用系統的作業系統需要部署一個新的修補程式。團隊成員應該修補虛擬機的原始範本，然後讓建置系統重新部署生產環境，而不是靠人去修補生產環境內的所有虛擬機。

事實上，團隊成員甚至不該有登入生產環境伺服器的能力。生產環境應該要盡可能地穩定，只能由你安裝的系統進行管理。

這可以在整體上減少錯誤，而且會出現的錯誤都會一致而更容易解決。

安全性是品質問題

了解共同的責任模型是能夠在雲端取得成功的關鍵。儘管想像復雜而有如科幻場景的威脅很有趣，但今日就有著相當嚴峻的配置不當問題。

除了要了解模型，將服務配置當作另一組軟體測試可以在這些不當配置進入生產環境前先加以發現。使用雲端服務商所提供的自動化工具或配置管理工具讓你可以充分利用服務商所提供讓你安全使用這些服務的功能。

擁抱”用系統而非人工（Systems over people）”原則以及擁有一套涵蓋你雲端責任的自動化功能，讓你可以在雲端環境保持強大的安全狀態，同時又可以讓業務團隊快速前進。