2022 年 SaaS 安全調查7 大焦點
譯文受訪人統計
大多數受訪者(71%)來自美洲,另外17%來自亞洲,13%來自歐洲、中東和非洲。在這些參與者中,49%影響決策過程,39%管理決策過程本身。該報告調查了來自不同行業的組織,如電信(25%)、金融(22%)和政府(9%)。
雖然這項調查有很多值得借鑒的地方,但以下是我們排在前7位的焦點。
1:SaaS 錯誤配置導致安全事件
自 2019 年以來,SaaS 錯誤配置已成為組織最關心的問題,至少有 43% 的組織報告他們已經處理過由 SaaS 錯誤配置引起的一個或多個安全事件。然而,由于許多其他組織表示他們不知道自己是否經歷過安全事件,因此與 SaaS 配置錯誤相關的事件的數量可能高達 63%。與 IaaS 錯誤配置導致的 17% 的安全事件相比,這些數字令人震驚。

圖 1. 公司因 SaaS 配置錯誤而遭遇安全事件
2:缺乏可見性和過多的訪問部門被認為是導致SaaS錯誤配置的主要原因
那么,這些SaaS錯誤配置的原因究竟是什么呢?雖然有幾個因素需要考慮,但受訪者將其歸結為兩個主要原因——有太多的部門可以訪問SaaS安全設置(35%),以及對SaaS安全設置的變化缺乏可見性(34%)。這是兩個相關的問題,考慮到在采用SaaS應用程序時缺乏可見性是最重要的問題,而且組織中平均有多個部門可以訪問安全設置,因此這兩個問題都不足為奇。缺乏可見性的主要原因之一是,有太多部門可以訪問安全設置,而其中許多部門沒有接受過適當的培訓,也沒有關注安全性。

圖 2. SaaS 配置錯誤的主要原因
3:對業務關鍵SaaS應用程序的投資正在超過SaaS安全工具和人員
眾所周知,企業正在采用更多的應用程序——僅過去一年就有 81% 的受訪者表示他們增加了對業務關鍵型 SaaS 應用程序的投資。另一方面,SaaS安全性方面在安全工具(73%)和人員(55%)上的投入較低。這種不一致意味著現有安全團隊在監控SaaS安全性方面的負擔越來越重。

圖 3. 公司對 SaaS 應用、安全工具和員工的投資
4:手動檢測和修復 SaaS 錯誤配置使組織暴露在外
46% 手動監控其 SaaS 安全性的組織每月只進行一次或更少的檢查,而 5% 根本不進行檢查。發現錯誤配置后,安全團隊需要額外的時間來解決它。大約四分之一的組織在手動修復時需要一周或更長時間來解決錯誤配置。這個漫長的時間使組織容易受到攻擊。

圖 4. 公司手動檢查其 SaaS 錯誤配置的頻率

圖 5. 公司手動修復 SaaS 錯誤配置需要的時間
5:使用 SSPM 可以縮短檢測和修復 SaaS 錯誤配置的時間
另外,已經實施 SSPM 的組織可以更快、更準確地檢測和修復他們的 SaaS 錯誤配置。這些組織中的大多數 (78%) 使用 SSPM 每周或更多次檢查其 SaaS 安全配置。在解決錯誤配置方面,81% 的使用 SSPM 的組織能夠在一天到一周內解決它。

圖 6. SaaS 安全配置檢查的頻率

圖 7. 修復 SaaS 錯誤配置的時間長度
6:第三方應用程序訪問是最受關注的問題
第三方應用程序,也稱為無代碼或低代碼平臺,可以提高生產力,實現混合工作,并且對于構建和擴展公司的工作流程至關重要。但是,許多用戶快速連接第三方應用程序而不考慮這些應用程序請求的權限。一旦被接受,授予這些第三方應用程序的權限和后續訪問可能是無害的,也可能是惡意的。如果沒有對 SaaS 到 SaaS 供應鏈的可見性,員工將連接到其組織的關鍵業務應用程序,安全團隊對許多潛在威脅視而不見。隨著組織繼續采用 SaaS 應用程序,他們最關心的問題之一是缺乏可見性,尤其是第三方應用程序訪問核心 SaaS 堆棧的可見性 (56%)。

圖 8. 公司在采用 SaaS 應用程序時最關心的問題
7:提前規劃和實施 SSPM
盡管該類別在兩年前就被引入市場,但它正在迅速成熟。在評估四種云安全解決方案時,SSPM 的平均評級為“有些熟悉”。此外,62% 的受訪者表示他們已經在使用 SSPM 或計劃在未來 24 個月內實施。

圖 9. 目前使用或計劃使用 SSPM 的公司
結論
《2022 年 SaaS 安全調查報告》提供了有關組織如何使用和保護其 SaaS 應用程序的見解。毫無疑問,隨著公司繼續采用更多的業務關鍵型 SaaS 應用程序,風險也越來越大。為了直面這一挑戰,公司應該開始通過兩個最佳實踐來保護自己:
第一個是讓安全團隊能夠全面了解所有 SaaS 應用程序的安全設置,包括第三方應用程序訪問和用戶權限,這反過來又允許部門保持其訪問權限,而不會有進行不當更改而使組織易受攻擊的風險。
其次,公司應該利用自動化工具(例如 SSPM)來持續檢測和快速修復 SaaS 安全錯誤配置。這些自動化工具允許安全團隊近乎實時地識別和修復問題,從而減少組織易受攻擊的總體時間或防止問題一起發生。
這兩個實踐都為他們的安全團隊提供了支持,同時不會阻止部門繼續他們的工作。




























