[[175367]]

當確保公共云數據與資源安全性時，不理解基本的安全概念或不知道如何使用特定的AWS安全特性將是弊大于利的。

成本和安全性已成為眾多企業使用公共云的障礙。企業用戶往往不會選擇由公共云供應商所管理的陌生IT環境，他們一般更趨向于投資內部IT團隊以求能夠實現內部控制的本地資源。但是，時間以及業界人士對于公共云的態度都已經發生了改變。

雖然諸如AWS這樣的公共云供應商已經花大力氣解決這些應用障礙來幫助提高用戶使用公共云的信心，為將資源遷入云提供方法，但還是存在著一些安全性方面的錯誤。漫不經心的安全性方法會帶來漏洞，而這些漏洞是任何管理服務或安全工具都無法填補的。

只要企業IT專業人士們能夠克服與工具相關的學習曲線并正確使用這些工具，那么AWS的安全服務套件就可用于保護云中的數據和資源。對于某些企業用戶來說，AWS中的共享安全模式是難以使用的，而可用的托管工具將進一步讓確保資源安全性的方法變得更為復雜。以下四個開發人員在AWS安全性方面易犯的特定錯誤是值得用戶密切關注其云運行的。

避免分擔責任

雖然AWS經常宣揚責任分擔的概念，但這并不意味著所有的AWS客戶都能夠理解這一理念。

本地和主機托管安全配置涉及不同水平的實踐工作。IT團隊承擔了確保數據與工作負載安全性中絕大多數或全部的責任。所以，當企業選擇使用AWS時，其中一些IT專業人士會誤以為是由云供應商來負責AWS中的所有安全性方面問題。這一誤解可能會導致遷移后針對滿足和維護客戶嚴格合規性需求的爭論。

“從風險管理策略的角度來看，很多客戶都沒有很仔細地審查他們的體系架構，他們都習慣性地持著一種‘確保系統安全性應當是供應商責任’的態度，”云安全聯盟CEO Jim Reavis在一封電子郵件中如是寫道。“這個問題在很多方面都有所體現，其中包括…忽視容錯和冗余功能，例如使用多個可用區域。”

不正確配置角色和AWS安全組

AWS的身份和訪問管理(IAM)控制著用戶對服務和資源的訪問。AWS安全性工具是集成整套服務和工具的基礎，但是這并不意味著所有的開發人員都能夠正確地進行集成操作。

首先，企業用戶可能無法真正地遵循最小權限的授權原則，在實際工作中往往是授權用戶對過多資源的過多訪問。

“安全組應當被認為是一個防火墻，他們應該秉承一個‘除非明確說明否則否認一切’的原則，”Reavis說。

此外，IT團隊通常會設置IAM角色和AWS安全組以滿足企業自身需求，然后放松對這些訪問控制的執行和更新。尤其是AWS安全組被證明是難以管理的——即便企業安排必要的人員和資源來解決這個問題，亦是如此。這有可能會導致跨整個云部署的漏洞。

企業需要建立一個合適的內部框架來對安全組和IAM策略進行定期評估。

日志功能的低效使用

日志記錄工具通?？梢詭椭芾砣藛T確定何時何地發生何種問題以及具體牽涉到哪一位用戶;很多IT團隊都能夠依靠這些工具作為AWS中的安全性組件。但是，開發人員很可能會不習慣使用這樣一些日志記錄功能。

亞馬遜CloudWatch日志服務會從彈性計算云實例和AWS CloudTrail事件中采集數據，這個服務讓開發人員能夠更深入地了解從應用運行性能到API調用的所有信息。CloudWatch日志服務為云部署提供了豐富的信息，而這些信息可用于在應對潛在問題中設置自定義警報或觸發AWS Lambda函數的其他服務。

一些客戶會使用一個記錄API調用日志的服務—— CloudTrail。“對于記錄所有AWS API調用來說，CloudTrail是一個非常有用的服務，”Reavis說。“它可以幫助企業用戶的管理人員積極主動地排查各種各樣的安全問題，它還有助于進行取證。但是很多客戶都不使用這個服務。”

缺乏加密

數據加密已成為一個業界內普遍性的話題。使用任何類型智能設備的最終用戶都可以使用加密功能來實現對個人數據的保護。

雖然企業用戶可以使用AWS中類似的加密功能，但并不是所有的客戶都愿意或習慣使用這類功能。AWS客戶可以轉而選擇使用AWS密鑰管理服務，或使用簡單存儲服務或彈性塊存儲中的內置加密功能。開發人員必須認真執行加密密鑰的創建和管理流程，并將其認為是一個不同于管理實際數據存儲的單獨任務。

“太多的信息要么是完全不加密，要么是加密工作做得不好，”Reavis說。“可選項有很多很多——其中一些是由AWS提供的，另一些則是由第三方提供。一些加密解決方案是在服務器端執行的;而另一些則是在數據傳輸至云之前在客戶端進行信息加密的，”他補充說。

AWS客戶需要考慮通盤考慮加密。“目前還沒有一個能夠適合所有應用的全能解決方案，”Reavis指出。但是正確區分存儲管理和加密密鑰管理就可以更好地保護AWS工作負載。