在雲計算時代，需要快速擴展或部署基礎設施以滿足不斷變化的組織需求，新服務器和節點的配置是完全自動化的。作為基礎設施即代碼（IaC）或連續配置自動化（CCA）等過程的一部分，這是用機器可讀的定義文件或模板來完成的。
Palo Alto Networks的研究人員對從GitHub存儲庫和其他地方收集的IaC模板進行了一項新的分析，發現了近20萬個包含不安全配置選項的此類文件。使用這些模板可能會導致嚴重的漏洞，從而使IaC部署的雲基礎設施及其保存的數據面臨風險。
研究人員說：“就像你忘記鎖上汽車或關好車窗，攻擊者可以利用這些錯誤的配置繞過防禦系統。這個數字解釋了為什麼在之前的一份報告中，我們發現65%的雲事故是由於用戶的錯誤配置造成的。如果一開始就沒有安全的IaC模板，雲環境就已經具備了被攻擊的條件。”
廣泛的IaC問題
有多種IaC框架和技術，最常見的是Kubernetes YAML（39%）、Terraform by HashiCorp（37%）和AWS CloudFormation（24%）。其中，42%的CloudFormation模板、22%的Terraform模板和9%的Kubernetes YAML配置文件存在漏洞。
Palo Alto Networks的分析表明，使用AWS CloudFormation模板的基礎設施部署中有一半的配置是不安全的。報告進一步按受影響的AWS服務的類型進行了分類：Amazon Elastic Compute Cloud（Amazon EC2）、Amazon Relational Database（RDS）、Amazon Simple Storage Service（Amazon S3）或Amazon Elastic Container Service（Amazon ECS）。
例如，模板中定義的S3存儲桶有10%以上是公開的。而安全性不高的S3存儲桶是許多公開報告的數據洩露的根源。
缺少數據庫加密和日誌記錄（對於保護數據和調查潛在的未經授權的訪問非常重要），這也是CloudFormation模板中常見的問題。其中一半不啟用S3日誌記錄，另一半不啟用S3服務器端加密。
亞馬遜的Redshift數據倉庫服務也出現了類似的情況。11%的配置文件生成公開的Redshift實例，43%沒有啟用加密，45%沒有打開日誌記錄。
支持多個雲提供商和技術的Terraform模板並沒有表現得更好。大約66%的Terraform配置的S3 bucket沒有啟用日誌記錄，26%的AWS EC2實例將SSH（端口22）公開到因特網，17%的模板定義的AWS Security Groups默認允許所有入站流量。
在Terraform模板中發現的其他常見錯誤配置包括：
- AWS身份和訪問管理（IAM）密碼不符合行業最低標準（40%）
- 沒有CPU或內存資源限制的容器（64%）
- 具有公開SSH的Azure網絡安全組（NSG）（51%）
- 未啟用日誌記錄的谷歌雲平臺存儲（58%）
- 未啟用安全傳輸的Azure存儲（97%）
Kubernetes YAML文件的不安全配置最少，但都很關鍵。在發現的不安全的YAML文件中，有26%的Kubernetes配置以根用戶或特權帳戶運行。
Palo Alto Networks的研究人員說：“允許容器作為根目錄的配置為攻擊者提供了一個機會，讓他們幾乎擁有該容器的任何方面。這也使得執行容器轉義攻擊的過程更容易，從而使主機系統容易受到其他潛在威脅。安全和DevOps團隊應確保容器不使用根帳戶或特權帳戶運行。”
實際部署中反映的IaC錯誤配置
IaC模板錯誤配置的類型及其普遍性（缺少數據庫加密和日誌記錄或公開的服務）與Palo Alto Networks在過去的報告中發現並涵蓋的實際雲基礎設施部署中的問題類型一致：
- 76%的組織允許公共訪問端口22（SSH）
- 69%的組織允許公共訪問3389端口（RDP）
- 64%無法為其數據存儲啟用日誌記錄
- 62%不啟用數據存儲的加密
- 47%的組織不使用無服務器功能的跟蹤功能
這表明，在自動化基礎設施部署過程中使用IaC模板時，不首先檢查它們是否存在不安全配置或其他漏洞，是導致雲易受攻擊的一個重要因素。
網絡犯罪集團通常以雲基礎設施為目標，部署加密挖礦惡意軟件。有一些人還將被攻擊的雲節點用於其他惡意目的。
“很明顯，攻擊者正在使用由薄弱或不安全的IaC配置模板實現的默認配置錯誤，繞過防火牆、安全組或VPC策略，將雲環境暴露給攻擊者。shift-left安全性是指將安全性移到開發過程中可能的最早階段。在雲部署中始終如一地實施shift-left實踐和過程的組織可以迅速超過競爭對手。與DevOps團隊合作，將安全標準嵌入到IaC模板中。這是DevOps和安全的雙贏。”
