クラウド環境
Kong API Gatewayの誤設定：APIゲートウェイのセキュリティに関するケーススタディ
本稿では、Kong API Gatewayのセキュリティ問題に焦点を当て解説します。
本稿では、Kong API Gatewayのセキュリティ問題に焦点を当て解説します。
APIゲートウェイは、三つの主要コンポーネント（ゲートウェイ本体、データベース、管理用API）により構成されます。Kong Gatewayは、メモリから設定へ直接アクセスすることで、データベースを介することなくAPIゲートウェイを実行することが可能です。その一方で、データベースを介さないために、特定の機能は使用が制限されます。
Kong Gatewayには、二種類のバージョン（Community及びEnterprise）が存在します。デフォルトのデータベースエンジンはPostgreSQLですが、旧バージョンではCassandraが使用されていました。また、追加のデータストア（Redis等）は「Communityプラグイン」を使用したキャッシングのために用いられます。なお、Communityバージョンでは、暗号化とVaultに関するサポートがEnterpriseバージョンと比較すると不足しています。
APISIXと同様にKong GatewayもNGINXをベースに構築されています。
システムの安全性は「Its weakest part（その最も脆弱な箇所）」を基準にして評価されるため、アーキテクチャの構築は大変重要な役割を果たします。そして、コンポーネントに脆弱性や誤設定が存在する場合には、組織全体が情報漏えい、APIゲートウェイの侵害、バックエンドの侵害、サプライチェーン攻撃などの危険にさらされる可能性があります。
Kong Gatewayは、複数の環境において展開することが可能です。APIゲートウェイの展開先（オンプレミス、クラウド、ハイブリッドクラウド）にかかわらず、各「アプリケーションコンポーネント」および「設定」が関連する環境のセキュリティに影響を及ぼします。セキュリティリスクを最小限に抑えるために、重要なコンポーネント（管理用API及びデータベース）へのアクセスは認可されたエンティティに限定することが大切です。
攻撃者がKong Gatewayのコンポーネントに不正アクセスするとゲートウェイ設定の読み取りが平文として可能になります。その結果、攻撃者による「設定の変更」がルートの追加や認証メカニズムの改ざんなどにより可能となるため、管理用APIのセキュリティ確保は大変重要となります。さらに、管理用APIが一般またはローカルネットワーク内において公開されるとバックエンドサービスが危険にさらされる恐れがあります。
通常、アクセスが許可されていない訪問者であっても「保護されたルート」にアクセスすることが可能です。そのため、攻撃者が不正な意図をもってアクセスした場合、ゲートウェイ設定に関連する情報が窃取、悪用される恐れがあります。さらに、認証情報の漏えいによりサービスへのアクセスが可能になります。
一度窃取された認証情報は今後のアクセス時に繰り返し使用されます。そして、これは攻撃者がAPI ゲートウェイのユーザを詐称する「なりすまし攻撃」の助長につながります。
懸念すべき点として、Kong Gatewayの管理用APIインスタンスがインターネット上で公開されていることが挙げられます（Shodan検索エンジンにより確認可）。
図4において「最初の数値」が示されている2021年後半以降、公開されているゲートウェイ数は増加傾向にあります。
公開されているゲートウェイの幾つかはハニーポットであるため、必ずしもすべてのゲートウェイが「Kong Gatewayの展開」とは関連しない点に注意が必要です。解析の結果、トレンドマイクロは、「Multiple Misconfigurations（複数の誤設定）」により構成された不正なデプロイパターンを確認しました。なお、このデプロイパターンは、クラウドの展開に際して使用されます。
Kong Gatewayは、コンテナ内において実行されます。また、管理用APIはSSL通信のためにポート番号8001または8443をリッスンします。そして、これらのポートはホストに転送されますが、コンテナを通じて同じネットワークが共有されるケースも存在します。なお、クラウドインスタンスにおけるファイアウォールルールの不備を原因とした不正アクセスが行われる可能性があります。
以下の章では、一般的な誤設定のケースについて解説します。
誤設定1：管理用APIの転送
管理用APIはローカルホストのみに割り当てることが推奨されます。管理用ポートの転送やホストとネットワークを共有することはセキュリティ上好ましくありません。
ゲートウェイの管理者は、アクセス時に認証情報を必要とする新ルートを設定することができます。この新ルートは、コンテナ外から直接管理用APIへのアクセスを可能とします。同様に、Enterpriseバージョンでは、トークン認証を必要とするRBAC（ロールベースアクセス制御）を適用することができます。
ユーザは、「デフォルト設定」の使用により、または「コンテナイメージリポジトリ内の例」を参考にして、上記シナリオを容易に実行することができます。
Kong Gatewayは、デフォルトとしてローカルネットワークインターフェースのみをリッスンします。それに対して、図７のDocker Hubイメージリポジトリは、デフォルトの保護機能の上書きや環境変数をバイパスする脆弱なパスワードの使用により、すべてのネットワークインターフェースをリッスンします。
このような事例は、セキュリティ面を考慮せずに「コピー＆ペースト」することの危険性を表しています。さらに、誤設定や隣接するシステムの危殆化によって、データベースエンドポイントへの侵入が可能になった際にはセキュリティリスクが高まります。侵入可能な状態とは、「機密情報にアクセスできる認証不要の手段」を攻撃者に提供している状態を意味します。
Kong Gatewayのドキュメントに、管理用 APIのセキュリティに関する詳細な説明が記載されています。
誤設定2：ファイアウォールルールの不備とインスタンス全体の公開
IPアドレスを「家のドア」に例えてみましょう。外とつながるドアがあるということは、攻撃者を含め誰もが、いつでもアクセスできることを意味します。安全を確保するためには、ドアの施錠や鍵共有の制限などの対策が必要であることは言うまでもありません。
これと同様に、クラウドインスタンスへのアクセスは「許可されたエンティティ」のみに制限することが重要です。また、セキュリティリスクを軽減するためには、公開されたポートへのアクセス制限（特定のIPアドレスまたはサブネットに限定）と認証メカニズムを併用することが大切です。
動的IP アドレスを使用してアプリケーションへアクセスする場合には、特に展開時において注意が必要です。セキュリティリスクを回避するために、動的IP アドレスの代わりに追加のアクセスベクタ（VPN等）を使用することが推奨されます。
APIゲートウェイのセキュリティに関する問題：機密情報とシークレットストレージ
保護されたリソース（管理プレーン、APIバックエンド、サーバーレスエンドポイント等）にアクセスする際には、通常「認証メカニズム」が要求されます。
APIゲートウェイのユースケースの一つとして「認証の簡素化」がありますが、これは組織の ID プロバイダが有効（API ゲートウェイによって識別可能）なトークンを発行することで実現されます。そして、API ゲートウェイは、事前に保存されたシークレットを用いて、保護されたリソースにリクエストを転送します。なお、設定はアプリケーションのメモリやデータベース内に保存されるシークレットの管理に影響を及ぼします。
従って、システム全体のセキュリティ面から見ると「シークレットの保護」は極めて重要となります。まず、データストアへのアクセスはAPIゲートウェイに限定することが推奨されます。次に、データベースにアクセスするための認証情報は推測されないこと、そして、デフォルトの設定などからコピーされないことが必須の条件となります。さらに、ゲートウェイの管理者は、オンプレミス展開に伴うネットワークのスニッフィングを阻止するためにTLSを使用することが大切です。
シークレットを転送する必要がない場合（ゲートウェイルート上でAPIキーやトークンのアクセスを設定するケース等）では、漏えい時における復元を阻止するために、機密情報を平文もしくは暗号化されたテキストのみで保存することは避けてください。代わりに、ハッシュメカニズムとソルティングを適用することで、仮にデータベースから情報が漏えいした場合であっても、攻撃者がシークレットを復元することはほぼ不可能となります。このような対策を講じることが困難な場合には、適切な暗号化の実施または外部Vaultストレージの使用を検討してください。
トレンドマイクロの調査において、特定のプラグインのみが機密情報の暗号化をサポートしていることが確認されました。そのため、サードパーティプラグインを使用する際には細心の注意が必要です。
Kong Gatewayは、デフォルトとしてデータベース内のすべてのシークレットを平文で保存します。加えて、鍵束（Keyring）が設定されたEnterpriseバージョンを使用する場合にのみ、特定のプラグインは追加の暗号化をサポートします。
「暗号化サポート」の検証は、ソースコードが存在するケースでは、プラグインソースコード内の暗号化されたパラメータをチェックすることによって実施されます。また、暗号が使用されているケースでは、データベースを検索する方法により手動で実施されます。
暗号化機能はKong GatewayのEnterpriseバージョンでのみ利用可能です。そのため、Communityバージョンにおけるシークレットは、平文で保存されます。なお、デフォルトの「key-authプラグイン」は、Enterpriseバージョンにおいても暗号化をサポートしていないため、代わりに「key-auth-secプラグイン」を使用する必要があります。
そして、「API キー認証プラグイン」は、ハッシュの代わりにシークレットを保存します。しかし、これはハッシュを用いる「basic-authプラグイン」の方針と矛盾しています。
平文で保存されたAPIキーがバックエンドに転送されずに、ゲートウェイにおける認証のみに使用されるケースは脆弱性として分類されています。
シークレットストレージに関しては、「機密情報保管のために設計されたソリューション」が担うことが重要です。そして、これについては、安全なメカニズムを採用しているVaultが単一のシークレットストレージを提供しています。
かつてKong Gatewayは、環境変数をVaultの一部としてリストアップ（図10）していました。その後、トレンドマイクロが情報共有を行った結果、当リストは既に変更されています。
環境変数は、Vaultの定義に当てはまらないため、公式ドキュメントに記載されているリストに誤解があったことが推測されます。なお、関連するセキュリティブログでは、環境変数にシークレットを保存すべきでない理由について解説を行っています。
暗号化サポートのケースと同様に、すべてのプラグインが機密情報を保管するためのVaultをサポートしているわけではありません（Enterpriseバージョンのみが外部Vaultをサポート）。これは、プラグインソースコードにおいて参照可能な引数を「true」に設定する必要があるためです。
このようにプラグインは追加機能を提供する一方で、時としてセキュリティ上の課題や脆弱性をもたらします。Kong Gatewayの機能の多くはプラグインによって提供されているため、このような負の側面はセキュリティ面における深刻な懸念材料となります。
本章では、セキュリティ上の課題として、スキーマ定義において必須要素が欠落している場合には、プラグインによる暗号化やVaultのサポートが実施されない可能性があることを解説しました。
ユーザ自身がデータやコードを入力する際には、常にセキュリティリスク（プラグイン関連のリスクを含む）が伴います。例えば、「request-」や「response-modifying」ポリシーは、DoS攻撃やRCE（リモートコード実行）を助長する可能性があります。
Kong Gatewayは 、サーバーレスコードの実行もサポートしています。Kong言語では、サーバーレスプラグインを用いてリクエストを処理する際に、設定によりカスタムLuaコードを実行することができます。また、デフォルトとしてLuaサンドボックス内でコードが実行されるため、より高いセキュリティが確保されています。
しかし、セキュリティの安全性が脅かされる可能性（設定の変更、サンドボックスの無効化、設定ファイル内における危険なインポートの許可等により）は常に残されています。
本稿で解説した誤設定は、Kong Gatewayの脆弱性を悪用した不正な実行を可能とします。不正実行の結果、攻撃者はAPIゲートウェイを完全に制御します。そして、機密情報を窃取することで、最終的にサプライチェーン攻撃を成功に導きます。その一方で、企業や組織は危険にさらされることとなります。
また、ゲートウェイの旧バージョンにも注意が必要です。旧バージョンでは、サンドボックスエスケープを許可している可能性があるためです。不要な場合には該当する機能をオフにすることやKong Gatewayの最新バージョンを使用することが推奨されます。
APIや一般的なウェブアプリケーションへのアクセスは、Authentication（認証）やAuthorization（認可）と密接に結びついています。そして、APIゲートウェイは、業界標準である「OAUTH 2.0」および「Open ID Connect」に対するサポートを行っています。これらのプロセスをしっかりと把握することは、APIのセキュリティ上大変重要となります。
さらに、Kong Gatewayは、サードパーティへのトークン発行と「サードパーティOAUTH 2.0メカニズム」の使用をサポートしています。「サードパーティOAUTH 2.0メカニズム」とは、ルーティングされたリソースの認証メカニズムです。
システムの安全性を確保するため、APIゲートウェイの管理者は、安全な設定が適用されていることを常に確認してください。安全な設定には、リダイレクト攻撃の回避や信頼できるIDプロバイダ（IdPs）のみへの許可が含まれます。
設定が正しく行われない場合には、ユーザへのなりすましや不正アクセスが実行される恐れがあります。そして、このようなセキュリティ侵害を検出することは容易ではありません。
発行されたトークンと認可フローの設定はデータベースまたはメモリに保存されます。そして、管理用APIまたはデータベースのセキュリティ確保に失敗すると同様の結果が生じる可能性があります。
まとめ
テクノロジーの利用は「諸刃の剣」と例えることができるでしょう。さまざまなメリットを提供する一方で、時としてセキュリティ上の課題をもたらします。そして、APIゲートウェイのような「複数の環境へのアクセスを集約するツール」は、侵害された際にこれらの環境すべてにセキュリティリスクをもたらします。
サイバーセキュリティには、コストが伴います。そのため、セキュリティソリューションを選択する前に、各製品の機能や導入時の影響を確認することが重要です。
複数のシークレットを単一のユーザまたはNamespace（名前空間）の下に集約することは、保存先（APIゲートウェイ、Vault等）にかかわらずセキュリティリスクが伴います。このようなセキュリティリスクを「脅威シナリオのモデル化」を用いて評価することで、より安全なアーキテクチャの構築やガイドラインの作成が可能となります。
参考記事
Kong API Gateway Misconfigurations: An API Gateway Security Case Study
By : Alfredo Oliveira and David Fiser
翻訳：新井 智士（Core Technology Marketing, Trend Micro™ Research）