保護您的雲端供應鏈
由於一次又一次的事件揭露了會構成重大企業風險的供應鏈弱點,使得供應鏈安全性成為了許多領導者的首要考量。像是 Log4j 和 等安全挑戰已經對所有規模的企業構成重大的風險,但恐怕連企業本身都不知道竟存在這些風險。當發生供應鏈攻擊時,光是軟體堆疊其中一個元件所產生的弱點就會對整個企業構成潛在威脅。
一份 Palo Alto Networks Unit 42® 的研究 發現,雲端供應鏈中一種會造成最大衝擊的風險類型 會是最主要的考量。我們的研究團隊發現有 63% 用來建立雲端基礎結構的第三方程式碼並不安 全。這些安全性風險包括會讓企業暴露在風險中的錯誤設定、未適當指派的權限和易遭攻擊的程 式碼程式庫。
究竟什麼是雲端供應鏈?
在大部分的時間,當人們談到供應鏈時都會想到從某個地點移動到另一地點的實體零件和貨物。目前許多企業還沒搞清楚的是這些實體貨物的移動通常都是由雲端中執行的應用程式所帶動。更進一步來說,若您的企業正在建立自身的雲端原生應用程式,代表您已經在供應鏈中取得供應鏈。
現代化雲端原生應用程式的建立和組成可分為三個高階步驟。第一個層級就是雲端基礎結構的佈建。第二個步驟就是建立 Kubernetes® 容器 協調服務,也就是用來部署應用程式的平台。第三個步驟就是部署其自身的應用程式容器映像。這三個層級中的任何一個都會有錯誤設定或易 遭攻擊的程式碼要素。
SBOM (軟體材料清單) 的設置
雖然雲端供應鏈安全性確實相當複雜,但我們也能利用這個機會讓它變得更簡單明瞭。對於雲端原生應用程式來說,容器幾乎是必定會使用的工具,因為它能讓企業更為輕鬆地追蹤應用程式的內容。
軟體材料清單 (SBOM) 的概念可藉由具有宣告性質的容器進一步簡化。使用者可在容器清單中逐條檢視,以了解容器內部的情況。
由於第第 14028 號行政命令 具體規範美國政府供應商對於 SBOM 的使用,讓 SBOM 也逐漸成為軟體供應鏈的一部分。
對於雲端供應鏈保護的建議
在考量到所有不同的層級、元件和來源後,雲端供應鏈確實是相當複雜。但即使如此複雜,我們還是可以透過包含四個步驟的策略性方法來管理雲端供應鏈安全性:
步驟 1:定義策略
關鍵的第一個步驟就是扼要敘述雲端供應鏈的整體策略,並從測試左移方法開始。測試左移的概念簡單說就是在整個程序中將安全性往前移, 也時候也稱為 DevSecOps。我們並不需要用大量的文件來闡述這個策略。一開始,我們真正需要做的是制定願景、角色和責任。然後每隔一 段時間再重複一次。
步驟 2:了解建立軟體的位置和方式
在這個階段中,您必須花點工夫來了解在企業中建立軟體的位置和方式。具體來說,就是記錄軟體從開發人員的筆記型電腦到進入生產雲端環境的整個過程。
步驟 3:確定並實作安全品質防護措施
在傳統的製造程序中,品質控制一直都是營運的一部分。然而,在進入雲端應用程式的階段後,情況可能就會有所改變。我們真正需要的是在軟體的建立過程中,找出企業可以設置主動檢查的位置。良好的安全控制必須包含越多的自動化程序越好,藉此補強無法自行擴展的人工程式碼審查流程。
步驟 4:認證的考量
我們之前提到的三個步驟主要是針對企業所開發的應用程式來建立安全性。除此之外,我們還需要針對應用程式及其所使用之雲端基礎結構的安全性進行驗證。認證將能在這個階段發揮作用。大型的雲端供應商通常會有非常多的第三方鑑定和認證機構。其中最常見的就是 SOC2 Typ II 和 ISO 27001,它們會識別供應商如何實作安全控制並獨立進行驗證。
請務必利用這些認證來了解供應商如何以系統方式因應及評估風險。這個程序相當重要,因為當您開始擴充雲端的使用時,供應商將會成為公司營運的延伸。
運用上述所有步驟有助於安全主管將企業建立在堅實的基礎上,不僅可以將安全測試左移,而且可以將安全性與開發劃上等號。隨著企業對於雲端和雲端原生應用程式的依賴與日俱增,我們也必須盡快實作雲端供應鏈安全策略。