身份管理在網絡安全中的重要性
快速擴展的大量云服務為企業 IT 和安全團隊創造了一個永無止境且異常快速的變化周期。許多團隊都在爭先恐后地保護公共云中的數據，而且大多數組織都在使用過時的安全策略，這些策略在應用于 AWS、Azure 和 Google Cloud 等云環境時會失敗。
網絡安全和基礎設施安全局 (CISA) 的技術策略師 Jay Gazlay 最近告訴美國國家標準與技術研究院 (NIST) 信息安全和隱私咨詢委員會：“身份現在就是一切。我們可以談論我們的網絡防御，我們可以談論防火墻和網絡分段的重要性，但實際上，身份已經成為邊界，我們需要開始以這種方式重新定位我們的基礎設施。”
了解身份的重要性
Gazlay 的評估表明身份是新的邊界。安全團隊習慣于考慮使用網絡創建邊界，將安全堆棧放置在這些邊界相交的地方，并根據已知和鎖定的數據路徑對其進行配置。這根本不能作為云中的整體安全解決方案。相反，云安全團隊必須考慮他們控制哪些身份、這些身份可以用于什么以及他們可以訪問哪些資源。
現代攻擊周期始于身份。攻擊者尋求通過身份獲得訪問權限，然后在資源之間切換，發現憑據以及其他人和非人身份，從而使他們能夠更好地訪問關鍵數據并導致數據泄露。重要的是要了解身份將安全性擴展到企業的傳統壁壘之外，這就是為什么我們看到數據泄露是將舊的網絡安全策略應用于云時失敗的原因。
在評估他們的云安全職位時，安全團隊應該問自己以下問題：
- 我們是否將身份作為我們的邊界來管理？如果您的團隊仍在管理舊的網絡邊界，那么您的公司就會面臨風險。您的組織必須管理個人和非個人身份。
- 我們是否已確定云中的安全風險？云安全風險和漂移可能很快發生。身份、資源和服務配置錯誤可能導致嚴重的數據泄露。組織可以通過首先識別未經授權的身份和過多的權限來最大限度地降低風險。數據所有者和云運營、安全和審計團隊必須不斷評估風險，以最大限度地提高數據的控制管理、安全和治理。
- 數據暴露指標是否不足？在風險評估策略中，僅靠透明的云數據存儲是不夠的。雖然數據所有者可能會信任他們的 DevOps 來管理數據對象的存儲，但這并不能揭示外部方可訪問性和特權的全部范圍。云用戶必須完全了解他們的數據真正存在的位置、哪些身份可以訪問它、它是如何被訪問的以及它從哪里移入和移出。
- 我們的協調問題是什么？向單個團隊發送安全警報以進行分類和管理的過時范式根本不可行。在云運營模型中，不同的團隊同時使用環境，包括審計、DevOps 和安全團隊。在這里，過時的范式崩潰了。解決方案是將問題提交給創建它們的團隊，因為他們最有能力解決這些問題。
- 我們是否解決了云安全員工的技能差距？ 許多開發人員天生就不是安全專家，應該接受最佳網絡安全實踐培訓。不想為現有開發人員增加更多職責的組織可能需要一種新型的操作人員，將操作與安全 (DevSecOps) 相結合。未能提升員工技能意味著他們不具備保護當今組織所需的技能和知識。
是時候改進您的企業戰略了
云涉及多個賬戶、信任關系和權限繼承，使得數據所有者密切關注它變得極具挑戰性。以下是您可以用來改進策略的一些領域：
作為零信任策略的一部分，組織應采取措施轉移到最低權限，確定對安全影響最直接的活動，并制定實施計劃。這意味著投資于滿足零信任策略的解決方案，通過持續監控每個權限、訪問和身份來確定其有效權限、可以做什么以及可以訪問哪些數據。
在數據風險造成損害之前預防數據風險。像對待人一樣對待補救和預防機器人。發現的問題應該上報給正確的團隊或機器人（團隊跟蹤和審計）。這將為您的環境帶來高性能的合規性結構。制定預防規則并確保規則得到持續滿足。
不完全了解其在保護公有云中的身份和數據方面所扮演的角色的企業會采用可能導致災難性后果的過時策略承擔不必要的風險。
