NGINX Full Version

Kubernetesのセキュリティを向上させる6つの方法

この記事は10部構成の一部です。

  1. Reduce Complexity with Production-Grade Kubernetes（英語）
  2. 高度なトラフィック管理でKubernetesの耐障害性を向上させる方法
  3. Kubernetesの可視性を向上させる方法
  4. トラフィック管理ツールを使ってKubernetesを安全にする6つの方法（この記事です）
  5. Ingressコントローラーの選択ガイド, Part 1: 要件の特定
  6. Ingress Controllerの選択ガイド, Part 2 : リスクと将来性
  7. Ingress Controllerの選び方ガイド, Part 3：オープンソース / デフォルト / 商用版
  8. Ingress Controllerの選択ガイド, Part 4 : NGINX Ingress Controllerのオプション
  9. サービスメッシュの選び方
  10. Performance Testing NGINX Ingress Controllers in a Dynamic Kubernetes Cloud Environment（英語）

これらのブログ一式を無料のebookとして下記よりダウンロードいただけます。–Kubernetes のテスト環境から本番環境への移行

「スピードを落とさずにクラウドネイティブアプリをセキュアにする」で説明したように、クラウドネイティブアプリを従来のアプリよりも安全にするのが難しくなる3つの要因が観察されています。

  1. クラウドネイティブアプリの提供は、ツールの乱立を招き、エンタープライズグレードのサービスとして十分な一貫性が提供できない場合があります。
  2. クラウドネイティブアプリの提供コストは、予測不可能で高額になる可能性があります。
  3. SecOpsチームはクラウドネイティブアプリの保護に苦労しており、DevOpsと対立しています。

この3つの要素はすべて等しくセキュリティに影響を与えますが、3つ目の要素は、おそらく最も「人間的」であるため、解決が最も困難な問題になり得ます。SecOpsがクラウド・ネイティブ・アプリケーションを保護できない、あるいは保護する権限がない場合、いくつかの結果は明らかですが（脆弱性や侵入）、その他の結果は、アジリティの低下やデジタルトランスフォーメーションの停滞など、目に見えないものです。

その隠れたコストを深掘りしてみましょう。組織は、敏捷性とコスト削減を約束してくれるKubernetesを選択します。しかし、Kubernetes環境でセキュリティインシデントが発生すると、ほとんどの組織はKubernetesのデプロイメントを本番環境から撤退させます。それは、組織の将来にとって不可欠なデジタルトランスフォーメーションの取り組みを遅らせることになり、そしてエンジニアリングの努力と資金が無駄になることは、それ以降気にもとめられません。論理的に導き出した結論は、Kubernetesをテストから本番に移行させようとするならば、セキュリティは組織内の全員が所有する戦略的要素であると考える必要がある、ということです。

この記事では、Kubernetesのトラフィックを制御するツールで解決できる6つのセキュリティユースケースを取り上げ、SecOpsがDevOpsやNetOpsと連携して、クラウドネイティブアプリやAPIをよりよく保護できる手法を紹介します。これらの手法の組み合わせは、顧客への影響を最小限に抑えながらアプリやAPIを安全に保つように設計された包括的なセキュリティ戦略を作成するためによく用いられるものです。

  1. CVEを迅速に解決し、サイバー攻撃を回避
  2. OWASP Top10やDoS攻撃を阻止
  3. アプリからの認証・認可のオフロード
  4. 適切な権限管理によるセルフサービスの設定
  5. エンドツーエンドの暗号化の実装
  6. クライアントが信頼できる実装で強力な暗号を使用していることを確認

セキュリティとアイデンティティの専門用語

ユースケースに入る前に、この記事で出てくるセキュリティとアイデンティティに関する用語の概要を説明します。

ユースケース：CVEを迅速に解決し、サイバー攻撃を回避

ソリューション： タイムリーでプロアクティブなパッチ通知機能を持つツールを利用します。

Ponemon Instituteの調査によると、2019年、重要または優先度の高い脆弱性のパッチがリリースされてから、組織がその脆弱性を悪用した攻撃を確認するまでの期間が、平均43日であることがわかりました。F5 NGINXでは、この期間がその後の数年間で大幅に狭まる（「2021年のApple iOS 15の場合は０日(ゼロデイ攻撃)」となった）ことを確認しており、できるだけ早くパッチを適用することを推奨しています。しかし、トラフィックを制御するツールのパッチが、CVEが発表されてから数週間、あるいは数ヶ月間利用できない場合はどうでしょうか。

専任のエンジニアリングチームではなく、コミュニティのコントリビューターによって開発・保守されているツールは、CVEの発表から数週間または数カ月遅れる可能性があり、組織が43日間の期限内にパッチを適用できる可能性は低くなります。一つの例として、OpenRestyは、NGINX関連のセキュリティパッチを適用するのに4ヶ月を要しました。OpenRestyベースのIngress Controllerを使用している人は、少なくとも4ヶ月間は脆弱なままであり、オープンソースプロジェクトに依存するソフトウェアにパッチが適用されるまでに、さらに遅延が発生するのが実際のこととして発生するのです。

CVEパッチを最速で適用するためには、トラフィックを制御するツールを選択する際に2つの特性を確認する必要があります。

CVEパッチの詳細については、「NGINX Plusによる迅速かつ容易なセキュリティ脆弱性の緩和」をご覧ください。

ユースケース：OWASP Top 10およびDoS攻撃の阻止

ソリューション： 柔軟でKubernetesに適したWAFとDoS防御の導入

Kubernetes上で動作するアプリケーションに適したWAFとDoS保護の選択は、（機能に加えて）2つの要素に左右されます。

WAFとDoS防御を統合したツールは一見効率的に見えますが、実際にはCPU使用率（フットプリントが大きくなるため）と柔軟性の両面で問題があると予想されます。WAFとDoS防御の両方を必要としない場合でも、一緒に展開することを余儀なくされるのです。結局のところ、この2つの問題はKubernetesデプロイメントに費やす全体のコストを押し上げ、他の重要なツールやサービスに対する予算の問題を引き起こす可能性があります。

組織に適したセキュリティツールを選択したら、次はそのツールをどこに配備するかを決定する番です。Kubernetesのアプリケーションを保護するためにアプリケーションサービスをデプロイできる場所は、通常4か所あります。

では、4つの選択肢のうち、どれが一番いいのでしょうか？それは、お客さまの機能要件と環境に依存します。

WAFを導入する場所

まずはじめに、定義した役割から利用することの多いWAFの導入方法について見ていきます。

DoS防御を導入する場所

DoS攻撃への対策は、フロントドアかIngress Controllerのどちらか1か所だけで済むので、より簡単です。フロントドアとエッジの両方にWAFを導入する場合、フロントドアのWAFの前にDoS防御を導入することをお勧めします。そうすれば、不要なトラフィックがWAFに到達する前に間引きされ、通信制御の処理に必要となるリソースをより効率的に利用できるようになります。

これらの各導入シナリオの詳細については、「Kubernetesでのアプリケーションサービスの導入、パート2」を参照してください。

ユースケース：アプリから認証・認可をオフロード

ソリューション： 入口での認証と認可の一元化

アプリケーションやサービスに組み込まれる非機能要件として、認証と認可がよく挙げられます。規模が小さい場合、アプリケーションの更新が頻繁ではない時における複雑さは管理可能であり許容できるでしょう。しかし、大規模になり、リリースの速度が速くなると、認証と認可をアプリに統合することが不可能になります。各アプリが適切に認証・認可を維持する場合には、アプリケーションのビジネス・ロジックの妨げになることがあり、さらに悪い場合、管理漏れが見落とされ情報漏えいにつながる可能性もあります。SSO技術を使用すればクレデンシャルを利用することで個別のユーザー名やパスワードの管理が不要となりセキュリティが向上しますが、開発者はアプリケーションのコードにSSOと連携するインタフェースを導入する必要があります。

より良い方法があります。：認証と認可をIngress Controllerにオフロードするのです。

Ingress Controllerは、すでにクラスタに入るすべてのトラフィックを精査し、適切なサービスにルーティングしているため、認証と認可を一元化するための効率的な選択肢となるのです。これにより、開発者はアプリケーション・コードでロジックを構築、維持、複製する負担がなくなり、代わりにネイティブなKubernetes APIを使用してIngress層でSSO技術を迅速に活用することができるようになります。

このトピックの詳細については、「Implementing OpenID Connect Authentication for Kubernetes with Okta and NGINX Ingress Controller」をご覧ください。

ユースケース：適切な権限管理によるセルフサービスの設定

ソリューション： ロールベースアクセスコントロール（RBAC）の導入

Kubernetesは、RBACを使用して、様々なタイプのユーザーに対し利用できるリソースの操作と制御が可能です。これは、管理者またはスーパーユーザーが、どのユーザーまたはユーザーグループがクラスタ内の任意のKubernetesオブジェクトまたは特定のネームスペースでどのような操作を許可するか決定できる、重要なセキュリティ対策となります。

Kubernetesの RBACはデフォルトで有効になっていますが、Kubernetesのトラフィックを制御するツールがRBACに対応し、組織のセキュリティニーズに合わせた利用について注意する必要があります。RBACを導入すると、ユーザーは、チケットを発行し作業が実施されるのを待つことなく、自分の仕事をするために必要な機能へのアクセス権を得ることができます。しかし、RBACが設定されていないと、ユーザーは必要のない、または権利のない権限を得ることができ、その権限が悪用されると脆弱性につながる可能性があります。

Ingress Controllerは、RBACを設定することで、多数の人やチームにサービスを提供できるツールの代表例です。Ingress Controllerはある単一のネームスペースであっても、細かなアクセス管理を実施することができ、RBACを利用してマルチテナントにおけるリソースの効果的な利用が可能となります。

例として、複数のチームがIngress Controllerを以下のように使用するとします。

NGINX Ingress ControllerでRBACを活用する方法については、「NGINX Ingress ControllerによるAdvanced Kubernetes Deployments」をご覧ください。このビデオの13:50から、RBACとリソース割り当てを活用してセキュリティ、セルフサービス、マルチテナンシーを実現する方法について、専門家が解説します。

ユースケース：エンドツーエンドの暗号化を実装

ソリューション： トラフィックを制御するツールの活用

機密情報や個人情報を扱う企業にとって、エンドツーエンドの暗号化（E2EE）はますます一般的な要件になりつつあります。金融データであれ、ソーシャルメディア上のメッセージであれ、消費者のプライバシーへの期待とGDPRやHIPAAなどの規制が相まって、この種の保護に対する需要が高まっています。E2EE を実現するための最初のステップは、SSL/TLS トラフィックを受け入れるようにバックエンドアプリ を設計するか、アプリから SSL/TLS 管理をオフロードするツール（セキュリティ機能、パフォーマンス、キー 管理などを分離するために望ましいオプション）を使用することです。その後、環境の複雑さに応じて、トラフィックを制御するツールを設定します。

最もよくあるシナリオ： Ingress Controllerを使用したE2EE

エンドポイントが1つだけのアプリ（シンプルなアプリや、Kubernetesに「リフト＆シフト」したモノリシックなアプリ）、またはサービス間通信がない場合、Ingress Controllerを使用してKubernetes内にE2EEを実装することが可能です。

ステップ1： Ingress Controllerは、サービス側またはmTLS証明書を使用した暗号化のためSSL/TLS接続のみを許可するようにし、理想的にはIngressとEgressの両方のトラフィックに対して許可するようにします。

ステップ2： アプリケーションに送信する前にIngress Controllerがトラフィックを復号化して再暗号化するために必要な設定を行います。これには、複数の方法があります。Ingress Controllerの要件に合わせて選択が可能です。

稀に必要となるシナリオ：Ingress ControllerとService Meshを利用したE2EE

クラスタ内でサービス間通信を行う場合、Ingress Controllerによる外部接続のトラフィックとService Meshによるサービス間トラフィックの2つのプレーンでE2EEを実装する必要があります。E2EEにおけるService Meshの役割は、特定のサービス同士の通信を許可し、安全な方法で通信できるようにすることです。E2EEのService Meshを設定する場合、サービス間のmTLS（証明書を必要とするように設定）とサービス間のトラフィックアクセス制御（どのサービスが通信を許可されるかを規定）の2つの要素によって、ゼロトラスト環境を有効にする必要があります。理想的には、Kubernetesクラスタ全体で真のE2EEセキュリティを実現するために、アプリケーション（Service Meshとingress egress Controllerによって管理される）間にもmTLSを実装することです。

やり取りされるデータの暗号化に関するさらなる詳細については、「NGINXService MeshのmTLSアーキテクチャ」をお読みください。

ユースケース：クライアントが信頼できる実装で強力な暗号を使用していることを確認

ソリューション： 連邦情報処理規格（FIPS）への準拠

ソフトウェア業界では通常、FIPSといえば、米国とカナダが共同で策定した「FIPS PUB 140-2 Security Requirements for Cryptographic Modules」という暗号技術に特化した出版物を指します。これは、米国とカナダの共同作業で、機密情報を保護するために両国の連邦機関が受け入れる暗号モジュールのテストと認証を標準化したものです。しかし、あなたは「私は北米の政府機関と仕事をするわけではないので、FIPSなんて関係ない」と言うでしょう。FIPSは事実上のグローバル暗号基準でもあるため、業界や地域に関係なく、FIPSに準拠することは賢明な行動と言えます。

FIPSへの準拠は難しいことではありませんが、オペレーティングシステムと関連するトラフィックを制御するツールの両方がFIPSモードで動作できることが必要です。FIPSへの準拠は、単にオペレーティングシステムをFIPSモードで動作させれば達成されるという誤解があります。オペレーティングシステムがFIPSモードであっても、Ingress Controllerと通信するクライアントが強力な暗号を使用していない可能性があります。FIPSモードで動作している場合、オペレーティングシステムとIngress Controllerは、一般的なSSL/TLS暗号のサブセットのみを使用することができます。

KubernetesのデプロイメントにFIPSを設定するのは、4つのステップからなります。

以下の例では、NGINX Plusが使用するオペレーティングシステムとOpenSSL実装の両方でFIPSモードを有効にすると、NGINX Plusとの間のすべてのエンドユーザー・トラフィックは、検証済みのFIPS対応暗号エンジンを使用して復号化および暗号化されます。

FIPSについては、「NGINX PlusでFIPS準拠を実現する」で詳しく説明しています。

NGINXでKubernetesの安全性を高める

これらのセキュリティ手法の一部（またはすべて）を実装する準備が整った場合、使用するツールがユースケースをサポートするための適切な機能と性能を備えているか確認する必要があります。NGINXは、本番環境に対応したKubernetesトラフィックを制御するツールについて支援することができます。

NGINX App Protect WAFとDoSを備えたNGINX Ingress Controllerの30日間無料トライアルをリクエストし、無料のNGINX Service Meshをダウンロードすることから始めましょう。