雲安全應對常識

導讀	隨着多雲及混合雲趨勢的發展，過去傳統的雲安全策略顯然已不適應新的雲環境。儘管，不少企業一直很是重視雲安全問題，但其中不少風險點並無獲得實際解決。大多數企業依然在採用過去本地環境下的雲安全措施，致使企業出現雲安全策略不一致，應用風險和漏洞增長的情況!最嚴重的問題是，不少私有云部署環境下的安全問題，並不須要黑客高手侵入，而是缺少安全常識!

不少安全問題都是防不勝防!即便在理想的環境下，還容易出現重大安全事故，更況且你係統自己就有問題，那等因而在給攻擊者開了一扇門。因此，爲了確保雲環境下的萬無一失，咱們除了在雲安全措施上下功夫，還要在安全常識問題上，提升警戒!

首先，不要忽略「殭屍負載」。

不少企業每每會忽略在系統架構上運行着的殭屍負載。尤爲是在企業應用峯值期，一旦遇到嚴重的安全問題，會首先把「殭屍負載」排除在外，不予理會。

實際上，不少別有用心的人就是利用殭屍資源來竊取密碼。儘管殭屍工做負載並不重要，可是它構建於企業總體基礎設施之上，一旦疏於管理，會更容易遭遇入侵。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進行監控，或則採用其餘網絡評估工具，進行按期審計，很是必要。

本文轉自：https://www.linuxprobe.com/cloud-security-knowledge.html