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

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

　　OPA 架構概述

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

　　策略即代碼（Policy As Code）的需求

　　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 集群的安全之外，組織還可以使用特定于云的安全解決方案。