標題：暴露的OPA 服務器可以洩漏應用程序的哪些信息

本文會介紹OPA 以及它的用途，並結合已發現的案例來說明通過Shodan 識別389 個暴露的OPA 服務器後發現了什麼，以及暴露的OPA 如何對用戶的應用程序的整體安全性產生哪些負面影響。

今年早些時候，趨勢科技發布了一份關於通過Shodan 發現243469 個暴露暴露的Kubernetes 節點的報告。另外，研究人員還發現了389 個易受攻擊的開放策略代理(OPA) 服務器。 OPA 是一個開源的雲本地計算基金會(CNCF) 項目，使用Go 編程語言開發，目前已被用作許多策略執行工具的主引擎，迄今為止下載量超過1.3 億次。它使用稱為Rego 的特定聲明性策略語言來設計其策略。 OPA 可用於各種系統和環境，例如Kubernetes、微服務、API 網關和其他雲本地工具。如果OPA服務器不受保護，它們的策略可能會洩露敏感的應用程序信息，包括用戶配置文件和正在使用的服務。這些暴露的策略還可能無意中洩露關於系統應該如何工作的信息，以繞過對已實現策略的限制，攻擊者可以利用這些限制進行攻擊。

OPA 架構概述

這篇文章討論了研究人員在通過Shodan 識別出數百個暴露的OPA 服務器後發現的問題，以及暴露的OPA 如何對你的應用程序的整體安全性產生負面影響。

策略即代碼（PolicyAsCode）的需求Policy As Code本質上都是讓原來對Policy 描述抽象成代碼，從而擁有代碼的特性（復用性、抽象性、可執行、可測試、版本化等），以此來獲得更高層次的抽象。

在當今包含sprint、scrum、container、DevOps 和DevSecOps 以及雲的運行環境中，如果不使用自動化，網絡、安全和合規團隊很難跟上開發團隊和業務需求。這就是為什麼基礎設施即代碼(IaC)、GitOps 和安全即代碼(SaC) 等方法在保護雲環境和微服務方面變得必不可少的原因。所有這些方法共同實現雲安全，目的就是幫助在流程和部署開始時集成安全性，以防止威脅和風險。

但是合規性呢？你如何檢查、執行和持續監控你的系統，以確保它們遵循安全最佳實踐並遵守最新的安全標準，例如支付卡行業數據安全標準(PCI-DSS)、健康保險流通與責任法案(HIPAA)，以及系統和組織控制(SOC 2)？這就是策略即代碼發揮作用的地方，可以顯著幫助加快合規性創建、自動化和驗證過程。

策略即代碼（或合規性即代碼）已成為實施、管理和跟踪系統策略更改並確保它們在雲本地系統4C 中應用和實施的好方法：代碼、容器、集群和雲。

使用與IaC 和SaC 類似的方法，策略即代碼使用軟件開發中已經使用的所有出色工具和技術來解決合規性問題。一方面，策略以特定文件格式（如JSON 或YAML）或使用特定編程語言（如Python 或Rego）創建和存儲。這些存儲在Git 存儲庫中，用於版本控制、跟踪和可審計性。這樣，組織可以在發生更改時在這些存儲庫上開發和触發管道和自動化。策略即代碼可以在代碼審查、自動化測試以及持續集成和交付(CI/CD) 管道中以編程方式實施，確保更改在到達生產系統之前得到適當的驗證和測試。 OPA 是可用於策略即代碼流程的領先開源工具之一。它可用於網絡上的許多不同應用程序和系統。儘管如此，它的主要採集者之一是Kubernetes 集群的准入控制器，其中它的Gatekeeper版本作為任何試圖在集群中運行的容器的安全器。

Shodan 上暴露的服務器在分析暴露的雲本地工具，特別是暴露暴露的kubelet 時，研究人員還通過Shodan 發現了近400 個暴露在8181 端口上的OPA 服務器，而且這個數字在過去幾個月中一直在增加。端口8181 是OPA 服務器的默認端口，它們都具有可用於未經身份驗證和未經授權的請求的API 端點。根據研究人員的Shodan 搜索，美國、韓國和德國是暴露OPA 數量最多的前三個國家。

研究人員使用列表策略端點來收集有關該實例中安裝的所有策略模塊的信息，如官方OPA 文檔中所示。然後，研究人員查詢了每389 個開放的OPA 服務器，以識別、收集和分析它們可以通過其策略模塊信息暴露的敏感信息類型。研究人員主要關注Policy API 來列出策略和分析數據。

首先，研究人員通過查詢/v1/config/端點來分析安裝在這些服務器上的OPA 的版本。如下圖所示，大多數暴露的服務器都使用過時的OPA 版本，例如0.34.2。在撰寫本文時，最新的OPA 版本是0.43.0。

根據在Shodan 上找到的數據，暴露的OPA 服務器數量及其版本

在上圖中，研究人員可以看到通過Shodan 找到的一個暴露OPA 服務器的示例。除了能夠通過此頁面查詢服務器之外，如果用戶輸入數據沒有得到適當的清理和驗證，它還可以作為命令注入攻擊的入口點。還有REST API 被暴露和未經身份驗證的問題。

在Shodan 上發現了一個過時(0.29.3) 和暴露的OPA 服務器的示例。截至撰寫本文時，此OPA 服務器的最新版本為0.43。

同時，這是對該暴露服務器的/v1/policies 端點發出GET 請求的結果：

從暴露的OPA 服務器訪問列表策略(/v1/policies) 端點以列出所有可用策略

在美化生成的policy.json文件並分析其內容後，研究人員從policy文件本身中發現了一些特殊的信息：

在這個暴露的OPA 服務器上有五個可用的規則，其ID 提供了有關其用途的線索；

'systems/ea2c8e2dbfa748608077be0d6fd45369/rules/rules.rego'；

'systems/ea2c8e2dbfa748608077be0d6fd45369/test/test.rego'；

'systems/ea2c8e2dbfa748608077be0d6fd45369/product/manager/rules/rules.rego'；

'systems/ea2c8e2dbfa748608077be0d6fd45369/product/rules/rules.rego'；

'systems/ea2c8e2dbfa748608077be0d6fd45369/backoffice/rules/rules.rego'；第一條規則是默認規則，默認返回值設置為false。第二條規則是測試規則；

研究人員可以訪問此暴露的OPA 服務器上可用的所有策略，這些策略可以以原始和抽象語法樹(AST) 格式訪問；

一些規則可以揭示內部應用程序角色，例如“發布者”和“編輯者”；

一些base64 編碼的數據轉換為“助手”。

分析暴露的OPA策略在從所有這些暴露的OPA 服務器收集和分析了近400 條策略之後，研究人員能夠找到以下信息：

這些策略中至少有33%的策略包含與應用程序相關的某種敏感信息，包括用戶配置文件、正在使用的服務，以及將通過Amazon Web Services (AWS) API 網關觸發API 的URL，甚至是一些內部系統URL。

這些策略中有91% 包含有關係統應如何運行以繞過基於已實施策略的某些限制的某種信息。

在收集的OPA 策略中找到的相關和敏感信息的百分比

以下是一些服務和URL 示例，僅通過查看策略和它們為未經身份驗證的請求提供的輸出即可找到：

僅通過查看OPA 策略即可找到的服務和URL 示例

通過適當的請求或令牌，攻擊者可以獲得有關這些服務的更多信息，並尋找漏洞或其他入口點以進入組織的系統。研究人員強烈建議目前將OPA 用作其策略即代碼解決方案的公司，以確保他們不會無意中在線暴露其API 和策略。在某些情況下，公司可能會在沒有意識到的情況下使用OPA，Kubernetes 託管服務的多個提供商依賴OPA 來執行策略。

出於安全考慮，研究人員僅從REST API 查詢列表策略端點。但是，還有許多其他可用的端點和方法，它們不僅列出了敏感信息，而且還允許攻擊者編輯甚至刪除暴露的OPA服務器中的數據和對象。其中包括：

所有這些都可以在OPA REST API 文檔中找到。

保護OPA 服務器首先，OPA 服務器不應該暴露在互聯網上。因此，有必要限制該訪問，以避免任何人通過REST API 繞過你的OPA 配置。對於授權用例，OPA部署的標準模式是讓OPA與請求它做出決策的應用程序運行在同一台設備上。這樣，組織就不需要將OPA 暴露給互聯網或內部網絡，因為通信是通過localhost 接口執行的。此外，以這種方式部署OPA 意味著組織通常不需要為REST API 啟用身份驗證/授權，因為只有在同一台設備上運行的進程才能查詢OPA 實例。為此，可以使用“opa run --addr localhost:8181”啟動OPA，使其僅綁定到localhost 接口。

其次，當使用策略即代碼工具(如OPA)時，在源代碼管理(SCM)系統等位置保護策略是很重要的。通過分支保護和代碼所有者等特性，擁有適當的訪問控制來監視可以更改這些策略中的哪些內容也是至關重要的。有了SCM系統的強大功能，組織可以創建對這些策略的任何更改的更精簡的審查和批准過程，確保源代碼中的任何內容也反映在生產OPA服務器中。

TLS 和HTTPS如上所述，在Shodan 上發現的這些暴露的OPA 服務器中的大多數都沒有使用任何類型的通信加密，因為默認情況下沒有啟用這種加密。要配置TLS 和HTTPS，系統管理員需要創建證書和私鑰，並提供以下命令行標誌：

TLS 證書的路徑：--tls-cert-file=

TLS 私鑰的路徑：--tls-private-key-file=

有關此過程的最新信息，請參閱有關TLS 和HTTPS 的OPA 文檔。

身份驗證和授權默認情況下，OPA 身份驗證和授權機制是關閉的。這在OPA 的官方文檔中有所描述，系統管理員和DevOps 工程師在安裝後立即啟用這些機制至關重要。

根據OPA 文檔，這兩種機制都可以通過以下命令行標誌進行配置：

身份驗證：--authentication=

這可以是不記名令牌(--authentication=token) 或客戶端TLS 證書(--authentication=tls)。

授權：--authorization=

這使用Rego 策略來決定誰可以在OPA 中做什麼。它可以通過在OPA 啟動期間設置--authorization=basic 標誌並提供最小授權策略來啟用。

有關此過程的更多詳細信息，請參閱OPA 關於身份驗證和授權的官方文檔。

雲安全建議Kubernetes 是開發人員中最受歡迎的平台之一，其高采用率證明了這一點，並且沒有任何很快放緩的跡象。隨著用戶基礎的不斷擴大，Kubernetes的部署需要確保安全，免受威脅和風險。為此，開發人員可以將策略作為代碼工具，它可以幫助以自動化的方式實現控制和驗證過程。

除了努力應用一些基本的內務管理規則來保證Kubernetes 集群的安全之外，組織還可以使用特定於雲的安全解決方案。