NGINX を使用した Kubernetes アプリのゼロトラスト セキュリティの設計

サイバーセキュリティ攻撃の巧妙さと数は飛躍的に増加しており、オンプレミス、ハイブリッド、マルチクラウドの Kubernetes 環境に展開されたアプリが危険にさらされる重大なリスクが生じています。 従来のセキュリティ モデルは境界ベースであり、ユーザーが環境のセキュリティ保護された境界内にいる場合は信頼できる (およびユーザー間の通信が安全である) と想定しています。 今日の分散環境では、境界内の安全地帯という概念はもはや存在せず、環境の「内部」から発信される通信は外部の脅威と同じくらい危険になる可能性があります。

このブログでは、Kubernetes インフラストラクチャを保護するためにゼロ トラスト モデルを採用するメリットと、NGINX がセキュリティ体制の改善にどのように役立つかについて説明します。

ゼロトラストとは何ですか?

ゼロ トラストは、場所ではなく ID に基づいたセキュリティ モデルです。 アプリケーション、データ、デバイスへのアクセス要求は、要求者がオンプレミス、リモート、またはクラウド内にいるかどうかに関係なく、攻撃である可能性があると想定されます。

ゼロトラストの 3 つの基本原則 (決して信頼しない、常に検証する、継続的に監視する) を実装するには、すべてのユーザー、サービス、アプリケーション、デバイスが認証と承認の証明を継続的に提示する必要があります。 時間制限のある権限は、動的なアクセス ポリシーと最小権限に基づいて付与されます。

すべての通信は暗号化され、すべての関係者を認証し、動的なアクセス ポリシーに基づいて権限を付与するポリシー決定/実施ポイント (PDP/PEP) を介してルーティングされます。 さらに、セキュリティ リスクを分析、評価、軽減するための監査、監視、レポート、自動化機能も導入されています。

ゼロトラストがセキュリティ体制を改善する方法

ゼロ トラストは、いくつかの方法でセキュリティ体制を改善します。

• 不正なアクティビティを自動的にブロックします
• アクセス制御を実施して、攻撃にさらされる領域を減らす
• 行動の異常や侵害の兆候を検出します
• アクセス時間を制限するリアルタイムの最小権限ポリシーを定義します
• 継続的な攻撃をブロックするために、IDを継続的に認証および検証します。

ゼロ トラストは、Kubernetes 環境で実行される最新のクラウド ネイティブ アプリにとって特に重要です。 疎結合で移植可能な分散アプリとサービスはコンテナ化され、ロケーションベースのセキュリティが選択できないハイブリッドのマルチクラウド環境全体で実行されます。 セキュリティは必然的に、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 により、高度なサイバー攻撃から高度なアプリケーション保護を追加できます。

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

認証と承認

ゼロ トラスト セキュリティの重要な原則の 1 つは、すべてのデバイス、ユーザー、サービス、リクエストが認証され、承認されることです。 認証とは、本人確認を行うプロセスです。言い換えれば、通信に参加する各当事者が本人であることを確認することです。 承認とは、当事者がリソースまたは機能に対して要求しているアクセス権限を持っていることを確認するプロセスです。

この原則に対応するために、NGINX ソリューションは、Okta や Azure Active Directory (AD) などの ID プロバイダーとの統合を通じて、 HTTP 基本認証、 JSON Web Token (JWT) 、 OpenID Connectなど、認証と承認を実装するためのいくつかのオプションを提供します。 NGINX ソリューションは、サービスに対しても安全な ID を発行します (アプリケーション ユーザーに証明書の形式で ID が発行されるのと同じように)。これにより、Kubernetes クラスター全体でアクションを実行するために認証および承認を受けることができます。 NGINX ソリューションは、ワークロード ID の処理に加えて、公開キー インフラストラクチャ (PKI) および証明機関との組み込み統合により証明書管理を自動化します。

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

詳細については、弊社のブログの「Okta と NGINX Ingress Controller を使用して Kubernetes に OpenID Connect 認証を実装する」をお読みください。

データの暗号化と整合性

ゼロ トラストのもう 1 つの原則は、参加者の所在地に関係なく、すべての通信が保護され、機密性と整合性が維持される必要があるということです。 データは、許可されていない第三者によって読み取られたり、送信中に変更されたりしてはなりません。 この原則を満たすために、NGINX ソリューションは、ユーザーとサービス間の通信に SSL/TLS 暗号化を使用し、サービス間の通信に相互 TLS (mTLS) 認証と暗号化を使用します。

アプリ アーキテクチャに Kubernetes クラスター内でのサービス間通信が含まれていない場合は、NGINX Ingress Controller でデータ整合性のニーズを十分に満たすことができます。 基本的なオプションは 2 つあります。

• TLS パススルーを使用すると、NGINX Ingress Controller は、SSL/TLS で暗号化された接続を、暗号化解除したり SSL/TLS 証明書やキーにアクセスしたりすることなく、サービスに直接ルーティングします。
• 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 クラスターでの通信のセキュリティ保護の詳細については、弊社のブログの「NGINX Service Mesh の mTLS アーキテクチャ」をお読みください。

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

アクセス制御は、ゼロ トラスト モデルのもう 1 つの重要な要素です。 Kubernetes は、ロールベースのアクセス制御 (RBAC) を使用して、さまざまなユーザーが利用できるリソースと操作を制御します。 これは、ユーザーまたはユーザー グループがクラスター内の Kubernetes オブジェクトまたは名前空間と対話する方法を決定します。

NGINX Kubernetes 接続ソリューションは RBAC 対応なので、組織のセキュリティ ポリシーに簡単に適合できます。 RBAC を導入すると、ユーザーは IT チケットを提出してそれが完了するまで待つことなく、業務を遂行するために必要な機能に制限付きでアクセスできるようになります。 RBAC がないと、ユーザーは必要のない権限や権限のない権限を取得でき、権限が誤用された場合に脆弱性が生じる可能性があります。

NGINX Ingress Controller を使用して RBAC を構成すると、組織のアプリケーション開発および配信環境のさまざまなロールに合わせて権限を調整することで、多数のユーザーとチームのアクセスを制御できます。 きめ細かいアクセス管理ツールにより、複数のチームにわたるセルフサービスとガバナンスが可能になります。

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

可観測性

監査、監視、ログ記録、追跡、レポートは、ゼロ トラスト環境の重要な要素です。 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 保護をデプロイできます。

WAF と DoS 保護の導入の詳細については、弊社のブログの「より安全なアプリのためにセキュリティ ツールを移行する」をお読みください。

Kubernetes 向け NGINX ゼロトラスト セキュリティ ソリューションを使い始める

Kubernetes を使い始めたばかりの方でも、Kubernetes をしばらく本番環境で実行している上級ユーザーでも、NGINX は、お客様のニーズを満たし、セキュリティ体制を改善するための包括的なツールとビルディング ブロックのセットを提供します。

まずは、NGINX App Protect WAF および DoS を備えた NGINX Ingress Controller の30 日間無料トライアルをリクエストし、常時無料の NGINX Service Meshをダウンロードしてください。