隨著多云及混合云趨勢的發展，過去傳統的云安全策略顯然已不適應新的云環境。盡管，很多企業一直非常重視云安全問題，但其中很多風險點并沒有得到實際解決。大多數企業依然在采用過去本地環境下的云安全措施，導致企業出現云安全策略不一致，應用風險和漏洞增加的狀況!最嚴重的問題是，很多私有云部署環境下的安全問題，并不需要黑客高手侵入，而是缺乏安全常識!

很多安全問題都是防不勝防!即使在理想的環境下，還容易出現重大安全事故，更何況你系統本身就有問題，那等于是在給攻擊者開了一扇門。所以，為了確保云環境下的萬無一失，我們除了在云安全措施上下功夫，還要在安全常識問題上，提高警惕!

首先，不要忽略“僵尸負載”。

很多企業往往會忽略在系統架構上運行著的僵尸負載。尤其是在企業應用峰值期，一旦遇到嚴重的安全問題，會首先把“僵尸負載”排除在外，不予理會。

實際上，很多別有用心的人就是利用僵尸資源來竊取密碼。盡管僵尸工作負載并不重要，但是它構建于企業整體基礎設施之上，一旦疏于管理，會更容易遭遇入侵。SkyBoxSecurity 2018年的一份報告顯示，密碼劫持是主要的一種網絡攻擊手段。DevOps團隊要像托管加密貨幣一樣，要確保應用資源不受威脅，并采用有效的安全防范手段，來阻止一切惡意行為。

其次，對AWS S3 Buckets的泄露問題，要足夠重視。

AWS云服務，尤其是 S3 Buckets是年頭最長的云本地服務之一，還保持著過去的安全防護方式和規則，因此成為勒索軟件攻擊的主要目標。有統計數據顯示，7%的 Amazon S3 bucket 都未做公開訪問的限制，35%的 bucket 都未做加密，這意味著整個 Amazon S3 服務器中都普遍存在這樣的問題。

惡意參與者不僅可以通過S3 bucket訪問企業的敏感客戶數據，而且還可以訪問云憑據。很多具有災難性的數據泄漏，都是由于訪問了不受限制的S3 bucket造成的，因此要定期檢查AWS平臺上的公有云存儲字段是非常重要的一項工作。

其三，系統更新最好不要繞過CI/CD管道。

每個DevSecOps團隊都有一個慣性思維，認為系統程序更新時要通過CI/CD管道傳遞，這樣的系統部署才更加安全，但這并不意味著每次運行都要強制執行這一策略。加快部署速度，避免出現安全問題，開放人員往往通過使用開放源碼庫的形式繞過CI/CD管道。

雖然這種方式為開發人員節省了系統發布和更新時間，但卻給安全團隊帶來了更大的負擔，他們必須對異常工作負載進行額外掃描。長期下去，開發團隊會認為安全團隊沒有辦法阻止未授權的工作負載，只是簡單地接受和執行。最終，系統的安全狀況會逐漸惡化，以至于惡意入侵者可以在不引起注意的情況下運行有害的工作負載，但是到那時才發現，一切為時已晚。

其四，網絡訪問要設限。

許多DevOps團隊并沒有花費大量的時間，用在分段和單獨的訪問權限上，而是依賴于一套完整的網絡配置，同時這些配置遠遠不能滿足必要的訪問限制，他們通常將所有的工作負載都放在一個單獨的VPC中，這樣就可以通過第三方流程訪問。

沒有對公網訪問設限，安全團隊要想識別和隔離惡意行為，要花很長時間。即使在短時間內，DevSecOps團隊發現了一些嚴重的漏洞，也無法在安全配置文件中及時處理安全漏洞!

其五，使用微服務時，規則設置要正確

當DevOps團隊在容器中使用微服務時，會面臨更大挑戰，分得越細，意味著你就越有可能出現錯誤的規則設置。

即使是最熟悉的規則和集群，也會因疏忽產生大量漏洞。例如，如果允許開發人員使用特定的IP通過SSH遠程連接到生產環境時，就可能會在不知情的情況下，允許敏感區域接入無限制公網訪問。有時，這些錯誤的規則配置會被忽略長達數月之久。為了避免錯誤規則支持，使用Amazon Inspector的Agentless進行監控，或則采用其他網絡評估工具，進行定期審計，非常必要。