今年稍早,趨勢科技發布了一份報告 指出我們透過 Shodan 找到了 243,469 個暴露在外的 Kubernetes 節點。過程當中,我們也發現了 389 台暴露在外的開放政策代理 (Open Policy Agent,簡稱 OPA) 伺服器。OPA 是雲端原生運算基金會 (Cloud Native Computing Foundation,簡稱 CNCF) 底下的一個開放原始碼專案,使用 Go 程式語言開發,是許多政策貫徹工具的核心引擎,目前已累積超過 1.3 億次下載,其政策是使用一種名為「Rego」的特殊宣告式政策語言來撰寫。OPA 可用於各種系統和環境,如:Kubernetes、微服務、API 閘道,以及其他雲端原生工具。假使 OPA 伺服器未妥善保護,其政策將暴露在外,進而洩漏一些敏感資訊,包括使用者設定檔與使用中的服務。此外,這些暴露在外的政策還可能意外洩漏有關系統行為的資訊,讓駭客知道如何避開政策管制來發動攻擊。
本篇部落格討論我們在 Shodan 上找到數百台暴露在外的 OPA 伺服器時發現了什麼,還有暴露在外的 OPA 可能對您應用程式的整體安全帶來什麼負面影響。
政策程式碼 (PaC) 的必要性
在今日這個 Sprint、Scrum (註:Scrum 是一種軟體靈活開發方法,而 Sprint 則是此方法底下集中衝刺的一個循環階段)、容器、 DevOps 、 DevSecOps 以及 雲端大行其道的靈活世界裡,網路、資安與法規遵循團隊若不借助自動化的力量,實在很難跟上開發團隊與業務需求的腳步。這正是為何基礎架構程式碼 (IaC) 、GitOps 以及 資安程式碼 (SaC) 早已成為保護雲端環境及微服務的必要工具。以上這些方法可共同運作來實現雲端安全,讓資安從一開始就融入開發流程與部署當中,進而防範威脅和風險。
但法規遵循呢?您如何檢查、貫徹,並持續監控您的系統以確保符合最佳實務原則,以及最新的安全標準,例如:支付卡產業資料安全標準 (PCI-DSS)、健康保險可攜性與責任法案 (HIPAA) 以及系統與組織控管 (SOC 2)?這就是政策程式碼 (Policy-as-Code,簡稱 PaC) 能派上用場的地方,它可大幅加快法規遵循的建立、自動化與驗證程序。
政策程式碼 (亦稱「法規遵循程式碼」,Compliance-as-Code) 已成為一種建置、管理與追蹤系統政策變更的最佳方法,讓政策確實套用並落實到雲端原生系統四大單元 (4C):程式碼、容器、叢集以及雲端。
PaC 採用類似 IaC 與 SaC 作法,透過軟體開發所使用的各種優良工具和技巧來解決法規遵循的問題。例如,它採用 JSON 或 YAML 檔案格式或 Python 或 Rego 程式設計語言來定義及儲存政策。並且將這些政策儲存到一個像 Git 儲存庫這樣的地方來實現版本控制、追蹤與稽核。這樣一來,企業就能透過這些儲存庫,在政策發生變更時觸發一些流程及自動化程序。此外,PaC 也可以像程式設計一樣擁有程式碼審查、自動化測試、 持續整合/持續交付 (CI/CD) 流程,確保所有變更都通過適當的檢驗及測試之後才套用到線上營運系統。OPA 就是一套專為 PaC流程設計的開放原始碼熱門工具。它可用於許多不同的網站應用程式和系統,不過,其最主要的使用者是 Kubernetes 叢集的 Admission Controller (准入控制器),其中的 Gatekeeper 版本就是扮演守門員的角色,負責過濾試圖在叢集內執行的任何容器。
Shodan 上暴露在外的 OPA 伺服器
當我們在 Shodan 上搜尋暴露在外的雲端原生工具 (確切來說是暴露在外的 kubelet) 時,我們也發現了將近 400 台暴露在外的 OPA 伺服器 (在連接埠 8181 上),而且數量在過去幾個月內還在持續增加。連接埠 8181 是 OPA 伺服器預設的連接埠,而且這些伺服器還提供了無須認證和授權就能使用的 API 端點。根據我們的 Shodan 搜尋結果,美國、南韓及德國是最多 OPA 伺服器暴露在外的三個國家。
我們參考 OPA 官方文件的說明使用列舉政策的 API 端點來蒐集執行個體上安裝的所有政策模組相關資訊。接著,我們針對這 389 台暴露在外的 OPA 伺服器下達查詢來尋找、蒐集、分析它們的政策模組資訊可能暴露哪些敏感資訊。我們主要使用 Policy API 來列舉政策並分析資料。
我們首先使用「/v1/config/」API 端點來查詢這些伺服器安裝的 OPA 版本,如圖 3 所示,絕大多數暴露在外的伺服器都使用舊的 OPA 版本,如 0.34.2。截至本文撰稿為止,目前最新的 OPA 版本是 0.43.0。
以下是針對這台暴露在外的伺服器發送 GET 請求至「/v1/policies」API 端點所得到的結果:
我們將得到的 policies.json 檔案進行整理分析,光從這個政策檔就能看到一些有趣資訊:
- 這個暴露在外的 OPA 伺服器上有 5 條規則光從 ID 就能看出它們的用途:
第一條規則是預設規則,預設回傳值為「false」。
第二條是測試規則。我們可讀取該伺服器上的所有政策,包括原始 (raw) 和 Abstract Syntax Tree (AST) 兩種格式。
某些規則會洩漏應用程式角色,如「publisher」(發布者) 和「editor」(編輯者)。
有些 base64 編碼的資料解碼後代表「helpers」(輔助者)。
分析暴露在外的 OPA 政策
在蒐集和分析了將近 400 條來自這些 OPA 伺服器的規則之後發現:
- 至少 33% 的政策包含某種跟應用程式相關的敏感資訊,包括:使用者設定檔、使用中的服務、經由 Amazon Web Services (AWS) API 閘道觸發 API 的網址,甚至還有某些內部系統的網址。
- 這些政策有 91% 都包含某種關於系統該如何運作以越過現有政策限制的資訊。
以下是幾個光從政策本身就能看出服務與網址的範例,以及發送無驗證請求給它們時所收到的輸出結果:
使用適當的請求或 Token,駭客甚至可以從這些伺服器獲得更多資訊,並且尋找漏洞或其他的系統入侵點。我們強烈建議目前正在使用 OPA 作為 PaC 解決方案的企業應確保自己的 API 和政策沒有不小心暴露在網路上。有時候,企業甚至不曉得自己正在使用 OPA,因為許多 Kubernetes 託管服務供應商都採用 OPA 來貫徹政策。
請記住,基於道德因素,我們在查詢時只用了列舉政策的 REST API 端點。其實還有很多其他可用的 API 端點與方法不光會洩漏敏感資訊,還會讓駭客編輯、甚至刪除 OPA 伺服器的資料與物件,包括:
建立或更新政策 | PUT /v1/policies/<id> |
刪除政策 | DELETE /v1/policies/<id> |
修補文件 (Data API) | PATCH /v1/data/{path:.+} |
刪除文件 (Data API) | DELETE /v1/data/{path:.+} |
這些資訊全都可在 OPA REST API 說明文件中查到。
保護 OPA 伺服器
首先,OPA 不應該暴露在網際網路上。因此,您必須設定一些存取管制以免任何人都能透過 REST API 刺探您的 OPA 組態設定。在使用 OPA 作為認證機制的應用情境中,標準的部署方式是讓 OPA 和需要使用它來認證的應用程式放在同一台伺服器上執行。這樣一來,企業就不需將 OPA 暴露在網際網路或內部網路上,因為所有通訊都會經由 localhost (本地端主機) 介面來完成。而且,採用這種方式來部署 OPA,意味著企業通常不需要啟用 REST API 的認證/授權,因為唯有同一台電腦上運行的處理程序可以對 OPA 執行個體發出查詢。企業若要這麼做,可以在啟動 OPA 時使用「opa run –addr localhost:8181」這道指令來將它綁定 localhost 介面。
其次,當使用像 OPA 這類 PaC 工具時,很重要的一點就是要將政策妥善保存在一個類似原始碼管理系統 (SCM) 的地方。還有一點也很重要的是採取適當的存取控管來監控誰可以對這些政策做些什麼變更,例如使用分支保護與程式碼持有人機制。藉由 SCM 系統的協助,企業就能建立一套更簡單的政策變更審查與核准機制,確保原始程式碼中的政策內容與 OPA 營運伺服器上的政策內容一致。
TLS 與 HTTPS
如圖 4 中可以看到,這些暴露在外的 OPA 伺服器絕大多數都未啟用任何通訊加密功能,因為這並非一項預設啟用的功能。系統管理員若要啟用 TLS 和 HTTPS 加密,必須建立一個憑證和一個私密金鑰,然後使用以下指令列旗標來指定憑證和金鑰:
- TLS 憑證路徑:–tls-cert-file=<path>
- TLS 私密金鑰路徑:–tls-private-key-file=<path>
有關這項步驟的最新資訊,請參考 OPA 有關 TLS 和 HTTPS 的說明文件。
認證與授權
在預設情況下,OPA 的認證與授權機制是關閉的,這在 OPA 官方文件有提到,因此很重要的就是系統管理員與 DevOps 工程師要在安裝之後立即啟用這些機制。 依據 OPA 的說明文件,這兩項機制可透過以下指令列旗標來啟用:
- 認證:–authentication=<scheme>。
- 授權:–authorization=<scheme>。
有關這項步驟的更多詳細資訊,請參閱 OPA 官方有關認證和授權的說明文件。
雲端資安建議
Kubernetes 是目前最受開發人員青睞的平台之一,從它的採用率居高不下即可證明,而且短期內似乎沒有消退的跡象。 隨著使用者越來越多,企業必須妥善保護 Kubernetes 部署環境以防範各種可能的威脅和風險。為此,開發人員可採用一套 PaC 工具來建立自動化管控與驗證程序。
除了確實遵守一些基本管理原則 來確保 Kubernetes 叢集的安全之外,企業還可採用一些雲端專屬的資安解決方案,例如趨勢科技的 Hybrid Cloud Security 混合雲防護與 Trend Micro Cloud One™。
此外,趨勢科技也提供一些解決方案來協助 DevOps 團隊建構安全、快速交付、隨處執行。趨勢科技 Hybrid Cloud Security 混合雲防護解決方案可提供強大、簡化、自動化的防護 ,讓企業將防護融入 DevOps 流程 ,並藉由多重的 XGen™ 威脅防禦技巧來保障實體、虛擬及雲端工作負載的安全。此外更藉由 Cloud One™ 服務平台讓企業從單一介面保護整個混合雲環境,擁有即時的資安防護,包含以下服務:Network Security、Workload Security、Container Security、Application Security、File Storage Security 以及 Conformity 。
對於正在尋找執行時期工作負載、容器映像以及檔案與物件儲存防護軟體的企業, Deep Security™ 可讓您在開發流程當中隨時掃描工作負載與容器映像是否含有惡意程式及漏洞,在部署之前預先防範威脅。
Trend Micro™ Cloud One™ 是一套專為雲端開發人員設計的防護服務平台,能提供自動化的防護來保護雲端移轉、雲端原生應用程式開發,確保卓越的雲端營運。此外,也有助於提早發掘及解決資安問題,加速 DevOps 團隊的應用程式交付時程。這套平台包含以下服務:
- Workload Security:執行時期工作負載防護。
- Container Security:自動化容器映像與登錄掃描。
- File Storage Security:雲端檔案及物件儲存服務的防護。
- Network Security:雲端網路層 IPS 防護。
- Application Security:無伺服器 (Serverless) 功能、API 及應用程式的防護。
原文出處:What Exposed OPA Servers Can Tell You About Your Applications 作者:Magno Logan