公開されたOPAサーバから流出するアプリケーション情報｜トレンドマイクロ

トレンドマイクロは2022年初頭、インターネットに公開されたKubernetesのノードが、オンライン検索エンジン「Shodan」上で243,469件発見されたことについて報告しました。この過程で、汎用ポリシーエンジン「Open Policy Agent（OPA）」のサービスについても検索したところ、脆弱性のあるサーバが389件発見されました。OPAはCloud Native Computing Foundation（CNCF）発のオープンソースプロジェクトであり、Go言語で開発されています。このポリシーエンジンは、多くのポリシー強化ツール用メインエンジンとして採用され、そのダウンロード件数は今日の時点で1億3千回を上回ります。OPAでは、宣言的ポリシー記述言語「Rego」を使用してポリシー情報を記述します。適用可能なシステムおよび環境としてKubernetes、マイクロサービス、APIのゲートウェイ、その他さまざまなクラウドネイティブサービスが存在します。このOPAサーバにセキュリティ不備があった場合、ポリシー情報が外部に流出し、そこからさらにユーザプロファイルや利用中のサービス一覧をはじめとするアプリケーションの機密情報も流出する可能性があります。また、ポリシーの詳細情報を窃取した攻撃者が、それを逆手に取って当該ポリシーによる制約を潜り抜けるためのシステム的な糸口を見出し、攻撃に発展させる可能性も考えられます。

本ブログでは、Shodanで発見された数百に及ぶ公開状態のOPAサーバを分析した結果について報告するとともに、公開されたOPAサーバがアプリケーションのセキュリティ全般に及ぼすリスクについて解説します。

コードによるポリシー管理（Policy-as-code）の必要性

スプリント、スクラム、コンテナ、DevOps（Development、Operations）、DevSecOps（Development、 Security、Operations）、クラウドをはじめとする技術や発想が次々と導入される中、ネットワークチームやセキュリティチーム、コンプライアンスチームが自動化技術なしで開発部門や業務要件の動向に追従していくことは困難なものとなりました。こうした過程で、コードによるインフラ管理（IaC：Infrastructure-as-Code）、GitOps、コードによるセキュリティ管理（SaC：Security-as-Code）といったアプローチが、クラウド環境やマイクロサービスを保護する上で大きな役割を果たすようになりました。これらのアプローチは全体としてクラウドセキュリティを確保するために協調して働き、デプロイまたはプロセスの開始時点から統合的なセキュリティを確立することによって、脅威やリスクを阻止します。

しかし、コンプライアンスについてはどうでしょうか。システムがセキュリティ上のベストプラクティスを敢行し、PCI-DSS（Payment Card Industry Data Security Standard）、HIPAA（Health Insurance Portability and Accountability Act）、SOC 2（System and Organization Controls）といったセキュリティ規格の最新版に準拠していることを継続的に確認、促進、監視していくためには、どのような手段を用いるべきでしょうか。こうした観点で特に役立つのが「コードによるポリシー管理（Policy-as-Code）」であり、コンプライアンスの構築、自動化、検証の作業を大幅に高速化することが可能です。

コードによるポリシー管理（またはコンプライアンス管理）は、システムで使用するポリシーの実装、管理、変更追跡を行う有力な手段であり、採用したポリシーがクラウドネイティブシステムの4C’s（Code：コード、Container：コンテナ、Cluster：クラスタ、Cloud：クラウド）上で適用・運用されていることを保証する上でも有用です。

コードによるポリシー管理では、ソフトウェア業界で使用されている既存の優れたツールや技術を駆使してコンプライアンス上の課題に対処するという点で、IaCやSaCと同様のアプローチが採られています。例えばポリシー情報の記述にはJSONやYAMLなどのファイル形式、またはPythonやRegoなどのプログラミング言語が使用されます。作成したポリシーはGitリポジトリに保存され、バージョン管理、変更追跡、承認プロセスの対象として扱われます。企業や組織はこの仕組みを導入することで、リポジトリ内のポリシーに対する変更をトリガーに自動起動するパイプラインを設計、配備することが可能です。ポリシーはプログラミング的に記述できるため、コードレビューや自動テスト、継続的インテグレーションとデリバリー（CI/CD：Continuous Integration and Continuous Delivery）のパイプラインに組み込むことも可能です。これにより、ポリシーの変更があった場合はまず適切な検証とテストを実施した後で本番環境に適用する、というフローがシステム的に保証されます。こうしたポリシーによるコード管理を実現する主要なオープンソースツールとして、OPAが挙げられます。OPAはさまざまなWebアプリケーションやシステムに適用可能であり、特にKubernetesクラスタ上でAPIリクエストを制御する「Admission Controller」はその最たる例と言えるでしょう。Admission Controllerとして動作するOPAのGatekeeper版は、クラスタ内で起動しようとするあらゆるコンテナを検査して、不正なものを追い出す警備員としての役割を果たします。

Shodan上で発見された公開状態のサーバ

公開されたクライドネイティブツールに関する調査において、当初着目していたkubeletsの他にも、ポート番号8181で起動するOPAサーバがShodan上で約400件確認されました。この件数は直近2ヶ月で上昇傾向にあります。8181はOPAサーバのデフォルト・ポート番号であり、今回発見した全てのOPAサーバは、未認証、未認可でもアクセス可能なAPIエンドポイントを公開していました。Shodan上で発見された公開状態のOPAサーバが最も多かった上位3国として、米国、韓国、ドイツが挙げられます。

図2：公開されたOPAサーバの数を検索サイトShodanからキーワード「port:8181 "policy-enable"」で集計した結果（2022年8月11日時点）

OPAサーバに登録されている全ポリシーの一覧を取得するため、OPA公式ドキュメントの「List Policies」に相当するエンドポイントを使用しました。次に、389個の公開された各OPAサーバを対象として、主に「Policy API」に相当するエンドポイントにクエリを送りました。返却された各種ポリシー情報をもとに、どのような機密情報を取得できるのかを分析しました。

また、対象サーバにインストールされているOPAのバージョンを調べるために、エンドポイント「/v1/config/」にクエリを送りました。図3に示す通り、ほとんどのOPAサーバでは、0.34.2などの古いバージョンが使用されていました。これに対し、調査時点での最新バージョンは0.43.0です。

図3：公開されたOPAサーバのバージョン別件数をShodanの検索結果から集計した結果

図4に、Shodan上で発見された公開状態にあるOPAサーバの一例を示します。このページからはクエリを送信できるだけでなく、入力データに対するサニタイジングやバリデーションが不十分の場合は、コマンドインジェクションを始めとする攻撃のエントリポイントに不正利用されるケースも考えられます。さらに、REST APIが認証なしで外部公開されている点も問題と言えるでしょう。

図4：Shodanで発見された公開状態のOPAサーバのうち、古いバージョン（0.29.3）が使用されていた例（本稿執筆時点の最新バージョンは0.43）

上記サーバのエンドポイント「/v1/policies」に対してGETリクエストを送信した結果は下図の通りです。

図5：公開されたOPAサーバのエンドポイント（/v1/policies）にアクセスして、有効なポリシー情報一覧を取得した結果

生成されたファイル「policies.json」の中身を整理して分析したところ、下記の特異な情報が確認されました。

この公開されたOPAサーバで有効なルールのうち、下記5つについては、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
このうち、1つ目はデフォルトルールであり、デフォルト値falseを返却する。2つ目はテスト用のルールである。
この公開されたOPAサーバ上で有効なポリシーは全てアクセス可能であり、無変換または抽象木（AST：Abstract Syntax Tree）の形式で取得できる。
一部のルールには、「publisher」や「editor」といったアプリケーション上の役割を示唆する情報が含まれる。
Base64でエンコードされ、デコード結果が「helpers」となるデータが存在する。

取得したポリシー情報の分析

公開された全OPAサーバから約400個のポリシーを取得してその内容を解析した結果、下記の事項が判明しました。

取得したポリシーの少なくとも33%（図6の機密情報）からは、アプリケーションに関する何らかの機密情報が得られる。例として、ユーザプロファイルや使用中のサービス、Amazon Web Services（AWS）のAPIゲートウェイを経由してAPIを実行するURL、システム内部で使用するURLなどが挙げられる。
取得したポリシーの91%（図6の関連情報）からは、当該ポリシーの制約をすり抜けるためには、システムに対して何をさせればよいのかというヒントが得られる。

図6：取得したOPAのポリシー情報のうち、機密情報と関連情報それぞれの割合を集計した結果

以下に、ポリシー情報を参照するだけで確認できたURLやサービスの例と、それに対して未認証のリクエストを送り得られた応答結果を示します。

Picture7b — 図7：OPAのポリシー情報を参照するだけで確認できたURLやサービスの例

上記では未承認のリクエストを用いましたが、正当なリクエストやトークンを送信できる攻撃者であれば、サービスに関するより多くの情報を窃取し、それをもとに脆弱性やエントリポイントを発見し、企業や組織が管理するシステムへの侵入手段に利用するケースが考えられます。OPAを用いてコードによるポリシー管理を行っている企業は、APIやポリシーを意図せずインターネット上に公開することがないよう十分に注意することを強く推奨します。Kubernetes上で提供されるサービスの中には、ポリシー強化の手段にOPAを用いているものも多く存在します。こうしたサービスを利用する企業、OPAを間接的に使用していることに気づかない状況も考えられます。

今回の分析では倫理上の観点から、REST APIの中でもポリシー情報を取得するエンドポイントしか使用しませんでした。しかし、他にも多くのエンドポイントや手段が存在し、機密情報の窃取にとどまらず、OPAサーバのオブジェクト編集や削除などの操作を攻撃者に許してしまうものも存在します。その例を下表に示します。

ポリシーの作成または更新	PUT /v1/policies/<対象のポリシー識別子>
ポリシーの削除	DELETE /v1/policies/<対象のポリシー識別子>
ドキュメントの修正（データAPI）	PATCH /v1/data/{path:.+}
ドキュメントの削除（データAPI）	DELETE /v1/data/{path:.+}

上記は全て、OPAによるREST APIのドキュメントから確認できます。

OPAサーバの保護

第一に、OPAサーバをインターネット上に公開しないことを推奨します。こうすることで、REST APIを手当たり次第に叩いてOPAの設定情報を窃取しようという企みを阻止することができます。認証ユースケースにおけるOPAの標準的なデプロイ方式では、OPAとOPAに判断を委ねるアプリケーションを同じ端末内で稼働させます。これによってOPAとアプリケーション間の通信は当該端末内に限定されるため、OPAサーバをインターネットや内部ネットワーク向けに公開する必要性が生じません。さらに、OPAのREST APIを呼び出せるのは当該端末内のアプリケーションに限定されるため、REST APIの認証認可を設定する必要性も、通常は生じません。以上の環境を構築する場合、OPAを下記コマンドで起動することで通信用インターフェースをローカルホスト内部に限定できます。

opa run --addr localhost:8181

第二に、コードによるポリシー管理をOPAなどのツールによって行う場合、ポリシー情報のファイルをソースコード管理（SCM：Source Code Management）システムなどで安全に管理することを推奨します。また、「ブランチ保護」や「コードオーナー」などの機能を使用して、ポリシー内のどの情報を誰が変更できるのかといったアクセス制御を適切に設定し、監視することも重要です。企業や組織はSCMシステムの強力な機能を用いることで、ポリシーのさまざまな変更に対するレビューや承認プロセスをさらに円滑化し、そのソースコードの内容をもれなく本番環境のOPAサーバに反映させるための手続きを確立することが可能です。

TLSとHTTPS

図4の「Not Secure」という表示の通り、Shodan上で発見された公開状態のOPAサーバは、通信暗号化を行わないものが大半を占めていました。デフォルト設定においても、通信暗号化は有効化されていません。TLSやHTTPSを使用する場合、システム管理者側で証明書と秘密鍵を作成し、下記のコマンドラインオプションを指定する必要があります。

TLS証明書のパス：--tls-cert-file=<パス>

TLS秘密鍵のパス：--tls-private-key-file=<パス>

この手順に関する最新情報については、OPAのTLSとHTTPSに関するドキュメントをご参照ください。

認証認可

OPAの公式ドキュメントで記載されている通り、認証認可の仕組みはデフォルトで無効化されています。セキュリティの観点上、システム管理者またはDevOpsのエンジニアはOPAのインストールが完了次第、迅速に認証認可を有効化することを推奨します。

OPAのドキュメントによると、認証認可は下記のコマンドラインフラグで設定することが可能です。

認証：--authentication=<スキーム名>
スキーム名としてBearer型トークン（--authentication=token）またはTLSクライアント証明書（--authentication=tls）を使用可能

認可：--authorization=<スキーム名>
OPA内でどのユーザが何を実行できるのかを、Regoで記述したポリシーによって設定できる。この設定は、OPAのスタートアップ時に「--authorization=basic」のオプションを指定し、最小認可のポリシー情報を指定することで有効に機能する。

この手順に関する詳細情報については、OPAの認証認可に関する公式ドキュメントをご参照ください。

クラウドセキュリティの推奨事項

Kubernetesは開発者の間で最も人気のあるプラットフォームの1つであり、その高い使用率から今後も拡大していくことが予想されます。ユーザベースが拡大し続けるKubernetesであるからこそ、デプロイ周りの設定や環境をセキュアな状態に保ち、脅威やリスクを阻止することが強く求められます。その1つの手段として、「コードによるポリシー管理ツール」が挙げられます。開発者はこれらのツールを使用することで、制御の実装や手順の検証をより簡単に、自動で行うことが可能になります。

Kubernetesクラスタを保護するための基本ルールを徹底して遵守する他、企業や組織は「Trend Micro™ Hybrid Cloud Security」や「Trend Micro Cloud One™」など、クラウドセキュリティに焦点をあてたソリューションをご利用いただけます。

トレンドマイクロは、DevOpsチームによるソフトウェアのセキュアなビルド、円滑な納品、場所を選ばない実行をサポートします。「Trend Micro™ 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：クラウドのネットワーク層における侵入防止システム
Application Security：サーバーレス機能、API、アプリケーションのセキュリティ

参考記事：
• 「What Exposed OPA Servers Can Tell You About Your Applications」
By: Magno Logan

翻訳：清水浩平（Core Technology Marketing, Trend Micro™ Research）

タグ

公開されたOPAサーバから流出するアプリケーション情報

執筆者

リソース

サポート

会社概要

リソース

サポート

会社概要

The Americas

Asia Pacific

Europe, Middle East & Africa