NGINXでKubernetesアプリ向けゼロトラストセキュリティを設計

NGINX | 2022年9月26日

Ilya Krutovシニアプロダクトマーケティングマネージャー | F5 NGINX

サイバーセキュリティ攻撃は高度化し、その件数も急増しているため、オンプレミス、ハイブリッド、マルチクラウドのKubernetes環境にデプロイされたアプリが攻撃にさらされるリスクが大幅に高まっています。従来のセキュリティモデルは境界型であり、保護された環境の境界内にいるユーザーは信頼でき、ユーザー間の通信も安全であることを前提としています。しかし、今日の分散環境では、境界の内側を安全な領域とみなす考え方はもはや通用しません。環境の「内部」から発信される通信も、外部の脅威と同様に危険な場合があります。

このブログでは、Kubernetesインフラストラクチャのセキュリティを確保するためにゼロトラストモデルを導入するメリットと、NGINXがセキュリティ態勢の強化にどのように役立つかをご紹介します。

ゼロトラストとは

ゼロトラストは、場所ではなくアイデンティティに基づくセキュリティモデルです。リクエスト元がオンプレミス、リモート、クラウドのいずれにあるように見える場合でも、アプリケーション、データ、デバイスへのアクセスリクエストは攻撃である可能性があると想定します。

Zero Trustの3つの基本原則である「決して信頼せず、常に検証し、継続的に監視する」を実践するには、すべてのユーザー、サービス、アプリケーション、デバイスが、認証および認可の証明を継続的に提示する必要があります。動的なアクセスポリシーに基づき、最小権限の原則に従って、期限付きの権限が付与されます。

すべての通信は暗号化され、ポリシー決定ポイント／ポリシー適用ポイント（PDP/PEP）を経由します。PDP/PEPはすべての当事者を認証し、動的なアクセスポリシーに基づいて権限を付与します。さらに、セキュリティリスクを分析、評価、軽減するための監査、監視、レポート、ならびに自動化の機能が備わっています。

ゼロトラストでセキュリティ態勢を強化する方法

ゼロトラストは、さまざまな方法でセキュリティ態勢の強化に役立ちます。

不正なアクティビティを自動的にブロック
アクセス制御を適用し、攻撃にさらされる領域を縮小
行動の異常と侵害の痕跡を検出
アクセス時間を制限するリアルタイムの最小権限ポリシーを定義
継続的に認証とID検証を行い、進行中の攻撃を阻止

Kubernetes環境で稼働する最新のクラウドネイティブアプリにとって、Zero Trustは特に重要です。疎結合で移植性に優れた分散型のアプリとサービスはコンテナ化され、場所に基づくセキュリティを適用できないハイブリッドおよびマルチクラウド環境全体で稼働します。そのため、セキュリティには、IDと権限の継続的な検証、エンドツーエンドの暗号化、監視が不可欠です。

ゼロトラストセキュリティを実現する方法

ゼロトラストの原則を満たすには、Kubernetes環境で、ユーザー、アプリケーション、サービスを対象とした認証、認可、アクセス制御、ポリシー、暗号化、監視、監査などの重要なセキュリティ機能を提供する必要があります。

これを実現する方法の1つは、アプリ自体にセキュリティを組み込むことです。しかし、その場合、開発者は、信頼の確立と検証、ユーザーIDと証明書の管理、すべての通信の暗号化と復号など、複数のセキュリティ手順を実装する必要があります。また、TLSやシングルサインオン（SSO）などのサードパーティテクノロジーを理解し、統合しなければなりません。こうした対応は、すでに複雑なKubernetes環境のデプロイをさらに複雑にするだけではありません。開発者が本来集中すべき（そして集中したい）アプリのビジネス機能の最適化から注意をそらすことにもなります。

慌てる必要はありません。より良い方法があります。セキュリティやその他の非機能要件をKubernetesインフラストラクチャにオフロードするのです。Ingressコントローラーやサービスメッシュなど、Kubernetesクラスター向けの接続ツールは、ユーザー、他のアプリ、サービスのいずれから発信されたかを問わず、アプリとサービス間のすべての通信にPDPとPEPを提供できます。これにより、中核となるビジネスの専門知識と機能に注力しながら、アプリをより迅速かつ容易に提供できます。

F5 NGINXがどのように役立つか

次の図に示すように、Kubernetesの接続を保護するNGINXソリューションには、オンプレミス、ハイブリッド、マルチクラウドなど、あらゆる環境にわたって、ユーザー、分散アプリケーション、マイクロサービス、APIを大規模かつエンドツーエンドで保護するために必要な、インフラストラクチャに依存しないコンポーネントとツールがすべて含まれています。世界で最も広く利用されているデータプレーンを基盤とするこのソリューションは、以下を組み合わせています。

NGINX Ingress Controllerは、KubernetesのIngressコントローラーであり、サードパーティのIDプロバイダーおよびSSOプロバイダーと統合するPDP/PEPとして機能します。NGINX PlusをベースとするNGINX Ingress Controllerは、高度な接続、監視と可視化、認証とSSOに対応し、APIゲートウェイとしても機能します。
NGINX Service Meshは、軽量で、すぐに導入でき、開発者にとって使いやすいサービスメッシュとして、Kubernetesクラスター内のサービス接続を保護します。各Kubernetesサービスと同じ場所に配置され、PDP/PEPとして機能するエンタープライズグレードのサイドカーは、NGINX Plusをベースとしています。
NGINX App Protectは、F5の市場をリードするセキュリティテクノロジーを基盤として、最新のアプリとAPIを包括的に保護します。モジュール型のアプローチにより、導入シナリオに応じた柔軟性と最適なリソース利用を実現します：
- NGINX App Protect WAF – OWASP Top 10に対する保護とPCI DDS準拠を実現する、堅牢で軽量なWAF
- NGINX App Protect DoS – クラウドやアーキテクチャを問わず、一貫性のある適応型の保護を提供する、振る舞いベースのDoS検知と緩和

NGINXソリューションでは、以下が可能です。

リリース速度を低下させたり、パフォーマンスを損なったりすることなく、分散環境全体に強力なセキュリティ制御を統合できます
継続的な認証、ID検証、行動異常の検知により、進行中の攻撃を自動的にブロック
リアルタイムの最小権限ポリシー、きめ細かなアクセス制御、エンドツーエンド暗号化、および複数チームにわたるガバナンスを実装
統合された堅牢なWAFとアプリレベルのDoS防御により、コードからお客さまへの提供までアプリを保護
詳細なリアルタイムおよび履歴メトリクスを活用して、Kubernetes環境のセキュリティ態勢を継続的に評価し、改善
テクノロジーの統合により、ユーザーとサービス間およびサービス間のセキュアな通信の導入と管理を簡素化

NGINXで包括的なゼロトラストセキュリティを実装

組織の規模が拡大するにつれ、ゼロトラストセキュリティ機能など、アプリの機能に固有ではない要件をアプリケーションレイヤーから切り離すことが重要になります。前述のとおり、これにより、開発者は各アプリでセキュリティロジックを構築、保守、複製する負担から解放され、代わりにプラットフォームレベルのセキュリティテクノロジーを容易に活用できます。NGINXでは、NGINX Ingress Controllerを使用してクラスタのエッジで、NGINX Service Meshを使用してクラスタ内で、Kubernetesのセキュリティポリシーを一元的に適用できます。アプリのセキュリティ要件に応じて、クラスタのエッジまたはクラスタ内にNGINX App Protect WAFおよびDoSを導入することで、高度なサイバー攻撃に対する高度なアプリケーション保護を追加できます。

Kubernetes環境に包括的なゼロトラストセキュリティを実装するために必要な機能が、NGINXソリューションにどのように組み込まれているかを詳しく見ていきましょう。

認証と認可

ゼロトラストセキュリティの主要原則の1つは、すべてのデバイス、ユーザー、サービス、リクエストを認証し、認可することです。認証とは、アイデンティティを検証するプロセスです。つまり、通信に参加する各当事者が、申告どおりの主体であることを確認します。認可とは、リソースまたは機能へのアクセスを要求している当事者に、そのアクセス権限があることを確認するプロセスです。

この原則に対応するため、NGINXソリューションでは、HTTP Basic認証、JSON Web Token（JWT）、およびOktaやAzure Active Directory（AD）などのアイデンティティプロバイダーとの連携によるOpenID Connectなど、認証と認可を実装するための複数のオプションを提供しています。また、NGINXソリューションは、アプリケーションユーザーに証明書形式のIDを発行するのと同様に、サービスにもセキュアなIDを発行します。これにより、サービスを認証し、Kubernetesクラスター全体でアクションを実行する権限を付与できます。NGINXソリューションは、ワークロードIDの処理に加え、公開鍵基盤（PKI）および認証局との組み込み連携により、証明書管理を自動化します。

NGINX Ingress Controllerは、クラスターに入るすべてのリクエストをすでに精査し、適切なサービスにルーティングしているため、ユーザーの認証と認可を一元化するうえで最も効率的な場所です。また、一部のシナリオでは、サービス認証にも最適です。

詳細については、F5のブログ記事「OktaとNGINX Ingress Controllerを使用したKubernetes向けOpenID Connect認証の実装」をご覧ください。

データの暗号化と整合性

ゼロトラストのもう1つの原則は、通信の当事者がどこにいても、すべての通信を保護し、機密性と完全性を維持しなければならないというものです。権限のない第三者によるデータの読み取りや、転送中のデータの改ざんを防ぐ必要があります。この原則を満たすため、NGINXソリューションでは、ユーザーとサービス間の通信にSSL/TLS暗号化を、サービス間の通信に相互TLS（mTLS）認証と暗号化を使用します。

アプリのアーキテクチャでKubernetesクラスター内のサービス間通信を使用しない場合、データの完全性に関する要件を満たすには、NGINX Ingress Controllerで十分な可能性があります。基本的な選択肢は2つあります。

With TLS Passthroughを使用すると、NGINX Ingress ControllerはSSL/TLS暗号化接続を復号せず、SSL/TLS証明書や鍵へのアクセスも必要とせずに、サービスへ直接ルーティングします。
With SSL/TLS終端では、NGINX Ingress Controllerがリバースプロキシとして動作し、リクエスト元とのTLS接続を終端した後、mTLSまたはサービス側のSSL/TLSを使用して、Kubernetesサービス（バックエンドサーバーおよびアップストリームサーバー）への新しい接続を暗号化します。

クラスター内でサービス間通信を行うアーキテクチャの場合、データの完全性を確保するには、NGINX Ingress ControllerとNGINX Service Meshの両方が必要です。NGINX Service Meshは、特定のサービス間でのみ通信を許可し、mTLSを使用してサービスを認証するとともに、サービス間の通信を暗号化します。NGINX Service Meshを使用すれば、mTLSを「ゼロタッチ」で実装できます。つまり、開発者はアプリケーションに証明書を後付けする必要がなく、相互認証が行われていることを意識する必要もありません。

Kubernetesクラスター内の通信のセキュリティ確保について詳しくは、F5のブログ記事「NGINX Service MeshにおけるmTLSアーキテクチャ」をご覧ください。

アクセス制御とアクセスポリシー

アクセス制御も、ゼロトラストモデルにおける重要な要素です。Kubernetesでは、ロールベースのアクセス制御（RBAC）を使用して、ユーザーごとに利用可能なリソースと操作を制御します。これにより、ユーザーまたはユーザーグループが、クラスター内のKubernetesオブジェクトや名前空間をどのように操作できるかが決まります。

NGINX Kubernetes connectivity solutionはRBACに対応しており、組織のセキュリティポリシーに容易に適合できます。RBACを導入すると、ユーザーはITチケットを申請して対応を待つことなく、業務に必要な機能に制限付きでアクセスできます。RBACがない場合、ユーザーに不要な権限や付与対象ではない権限が与えられる可能性があり、それらの権限が悪用されると脆弱性につながるおそれがあります。

NGINX Ingress ControllerでRBACを構成すると、組織のアプリケーション開発・デリバリー環境におけるさまざまな役割に権限を対応付け、多数の担当者やチームのアクセスを制御できます。きめ細かなアクセス管理ツールにより、複数のチームにわたるセルフサービスとガバナンスが可能になります。

NGINX Ingress ControllerでRBACを活用する方法については、DevNetworkのウェビナー「NGINX Ingress Controllerによる高度なKubernetesデプロイ」をご覧ください。13:50から、セキュリティ、セルフサービス、マルチテナンシーのためにRBACとリソース割り当てを活用する方法をF5のエキスパートが解説します。

可観測性

監査、監視、ログ記録、トレース、レポート作成は、ゼロトラスト環境の重要な要素です。Kubernetesアプリケーションインフラストラクチャの状態に関する情報をより多く収集し、より効果的に関連付け、分析、評価することで、セキュリティ体制をさらに強化できます。

Kubernetes環境では、すでに監視ツールを使用しており、新たなツールは必要ないかもしれません。クラスター内部の状況を包括的に把握できるよう、NGINX Plus APIから、JSONに対応する任意のサードパーティ製ツールへメトリクスを簡単にエクスポートできるようにしたほか、OpenTelemetryやGrafanaおよびPrometheusなどの一般的なツール向けに構築済みの統合機能を提供しています。詳細なトレースにより、アプリケーションの接続性に関する的確なインサイトを得て、リクエストがエンドツーエンドでどのように処理されるかを把握できます。NGINX Ingress Controllerはクラスターと外部クライアント間の接続性に関するインサイトを提供し、NGINX Service Meshはクラスター内のコンテナ化されたマイクロサービスベースのアプリケーションおよびサービス間の接続性をカバーします。

WAFとDoS攻撃対策

NGINX App Protectは、OWASP Top 10やレイヤー7のサービス拒否（DoS）攻撃などの脅威から分散アプリケーションを保護し、そのセキュリティをさらに強化します。エンドツーエンドのNGINXセキュア接続ソリューションに不可欠なコンポーネントであるNGINX App Protectは、基本的なシグネチャにとどまらず、高度な脅威に対して俊敏でアプリケーション中心のセキュリティを提供します。F5が培ってきた業界をリードする信頼性の高いセキュリティ専門知識を活用しながら、リリース速度とパフォーマンスを損ないません。また、セキュリティテレメトリをサードパーティの分析および可視化ソリューションへ容易に転送でき、信頼度の高いシグネチャと自動化された振る舞い分析によって誤検知を低減します。

NGINX App Protectはモジュール式の設計を採用しているため、ニーズに応じて、WAFとDoS防御の一方または両方を、同じインスタンスにも別々のインスタンスにもデプロイできます。たとえば、NGINX Ingress Controllerとともにクラスターのエッジにデプロイすれば、単一クラスター全体で一貫したきめ細かな保護を実現するのに最適です。一方、クラスター内の複数のアプリにアプリ固有のポリシーが必要な場合は、WAFやDoS防御をサービスまたはPodレベルでデプロイできます。

WAFおよびDoS保護の導入について詳しくは、F5のブログ記事「セキュリティツールのシフトレフトでアプリをより安全に」をご覧ください。