トラフィック管理ツールを使用してKubernetesを保護する6つの方法

Jenn GileNGINX製品マーケティング責任者

編集者注 – この記事は全10回のシリーズの一部です：

1. 本番環境対応のKubernetesで複雑さを軽減
2. 高度なトラフィック管理でKubernetesのレジリエンスを向上させる方法
3. Kubernetesの可視性を向上させる方法
4. トラフィック管理ツールを使用してKubernetesを保護する6つの方法（本記事）
5. Ingress Controller選定ガイド 第1回：要件の明確化
6. Ingress Controller選定ガイド、第2部：リスクと将来への備え
7. Ingress Controller選定ガイド 第3部：オープンソース、デフォルト、商用の比較
8. Ingress Controller選定ガイド、第4回：NGINX Ingress Controllerの選択肢
9. サービスメッシュの選び方
10. 動的なKubernetesクラウド環境におけるNGINX Ingress Controllerのパフォーマンステスト

一連のブログ記事をまとめた無料の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 Top 10およびサービス拒否攻撃を阻止
3. 認証と認可をアプリからオフロード
4. ガードレールを設けたセルフサービスを構築
5. エンドツーエンド暗号化を実装
6. クライアントが、信頼できる実装による強力な暗号を使用していることを確認する

セキュリティとアイデンティティに関する用語

ユースケースをご紹介する前に、この記事で使用するセキュリティとアイデンティティに関する用語を簡単に説明します。

• 認証と認可 – 適切なユーザーとサービスのみがバックエンドまたはアプリケーションコンポーネントにアクセスできるようにするために必要な機能：
  • 認証 – IDを検証し、リクエストを行うクライアントが本人であることを確認します。パスワードやJSON Web Token（JWT）などのIDトークンを使用して実行します。
  • 認可 – リソースまたは機能にアクセスする権限を検証します。セッションCookie、セッションID、グループID、トークンの内容など、レイヤー7属性を含むアクセストークンを使用して行います。
• Critical Vulnerabilities and Exposures（CVE） – 公開された欠陥、すなわち「ソフトウェア、ファームウェア、ハードウェア、またはサービスのコンポーネントに存在し、悪用可能な弱点に起因して、影響を受ける1つ以上のコンポーネントの機密性、完全性、または可用性に悪影響を及ぼすもの」を収録したデータベースです（https://www.cve.org/）。CVEは、ツールを管理する開発者、ペネトレーションテスター、ユーザーや顧客、またはコミュニティのメンバー（「バグハンター」など）によって発見される場合があります。悪意のある攻撃者を利することがないよう、脆弱性を公開する前に、ソフトウェア所有者がパッチを開発するための時間を設けるのが一般的です。
• サービス拒否（DoS）攻撃 – 悪意のある攻撃者が、Webサイトをクラッシュさせる目的で大量のリクエスト（TCP/UDPまたはHTTP/HTTPS）を送りつける攻撃です。DoS攻撃は可用性に影響を及ぼすため、主に標的の評判を損なう結果となります。分散型サービス拒否（DDoS）攻撃は、複数の送信元から同じネットワークやサービスを標的にする攻撃であり、攻撃元のネットワークが大規模になる可能性があるため、防御がより困難です。DoS対策には、攻撃を適応的に特定して防止するツールが必要です。詳しくは、分散型サービス拒否（DDoS）とは？
• エンドツーエンド暗号化（E2EE） – ユーザーからアプリへ、さらにアプリからユーザーへとデータが送受信される間、データを完全に暗号化する手法です。E2EEにはSSL証明書が必要であり、mTLSも必要になる場合があります。
• Mutual TLS (mTLS) – クライアントとホストの双方に対して、SSL/TLS証明書による認証を必須とする手法です。mTLSを使用すると、クライアントとホストの間でやり取りされるデータの機密性と完全性も保護されます。mTLSは、同じクラスター内の2つのサービス間において、KubernetesのPodレベルまで適用できます。SSL/TLSとmTLSの概要については、F5 Labsの「mTLSとは？」をご覧ください。
• シングルサインオン（SSO） – SSOテクノロジー（SAML、OAuth、OIDCなど）により、認証と認可を容易に管理できます。
  • 認証の簡素化 – SSOにより、リソースや機能ごとにユーザーが個別のIDトークンを持つ必要がなくなります。
  • 標準化された認可 – SSOにより、役割、部門、役職レベルに基づいてユーザーのアクセス権を設定しやすくなり、ユーザーごとに権限を個別設定する必要がなくなります。
• SSL（Secure Sockets Layer）/TLS（Transport Layer Security） – ネットワークに接続されたコンピューター間で、認証および暗号化された接続を確立するためのプロトコルです。SSL/TLS証明書はWebサイトの身元を認証し、暗号化された接続を確立します。SSLプロトコルは1999年に非推奨となり、TLSプロトコルに置き換えられましたが、これらの関連技術は現在も一般に「SSL」または「SSL/TLS」と呼ばれています。本記事では表記を統一するため、以降はSSL/TLSを使用します。
• Web Application Firewall（WAF） – リバースプロキシとして、アプリやAPIに対する高度な攻撃（OWASP Top 10やその他の高度な脅威を含む）を検知してブロックする一方、「安全な」トラフィックは通過させます。WAFは、機密データの窃取やシステムの乗っ取りによって標的に損害を与えようとする攻撃から防御します。WAFとDoS対策を同じツールに統合しているベンダーもあれば、それぞれを別のツールとして提供しているベンダーもあります。
• ゼロトラスト – 高度なセキュリティを必要とする組織でよく採用される一方、あらゆる組織に関係するセキュリティの概念です。保存時と転送時のすべての段階でデータを保護する必要があります。つまり、ユーザーやデバイスをデフォルトでは「信頼」せず、すべてのトラフィックを徹底的に検証することを組織として定めます。ゼロトラストアーキテクチャには通常、認証、認可、mTLSの組み合わせが含まれ、E2EEも実装されている可能性が高いと考えられます。

ユースケース：サイバー攻撃を回避するためにCVEへ迅速に対処

解決策：タイムリーかつプロアクティブにパッチ通知を行うツールを使用する

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

専任のエンジニアリングチームではなく、コミュニティのコントリビューターによって開発・保守されているツールでは、CVEの発表から対応までに数週間から数か月の遅れが生じる可能性があるため、組織がその43日間の猶予期間内にパッチを適用することは難しくなります。ある事例では、OpenRestyがNGINX関連のセキュリティパッチを適用するまでに4か月を要しました。そのため、OpenRestyベースのIngressコントローラーの利用者は少なくとも4か月間、脆弱性が残る状態に置かれました。実際には、オープンソースプロジェクトに依存するソフトウェアでパッチが利用可能になるまで、通常はさらに時間がかかります。

CVEパッチを最速で適用するには、トラフィック管理ツールを選定する際に、次の2つの特性を確認してください。

• 専任のエンジニアリングチーム – コミュニティのボランティアではなくエンジニアリングチームがツール開発を管理していれば、ツールの健全性を維持する専任の担当者がおり、パッチを可能な限り早くリリースできるよう優先的に対応します。
• 統合されたコードベース – 外部依存関係がないため（OpenRestyについて説明したとおり）、パッチはアジャイルスプリント1回でリリースできます。

CVEのパッチ適用について詳しくは、「NGINX Plusでセキュリティ脆弱性を迅速かつ容易に軽減」をご覧ください。

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

ソリューション：柔軟でKubernetesとの親和性が高いWAFおよびDoS対策を導入

Kubernetesアプリに適したWAFおよびDoS対策を選択する際は、機能に加えて、次の2つの要素を考慮する必要があります。

• 柔軟性 – Kubernetes内にツールをデプロイするのが最適な場合もあるため、Kubernetesの内外で実行できる、インフラストラクチャに依存しないツールが必要です。すべてのデプロイで同じツールを使用すれば、ポリシーを再利用でき、SecOpsチームの学習負担を軽減できます。
• フットプリント – 優れたKubernetesツールはフットプリントが小さく、スループット、1秒あたりのリクエスト数、レイテンシーへの影響を最小限に抑えながら、リソースを適切に消費できます。DevOpsチームは、アプリの動作が遅くなるという認識からセキュリティツールの導入に抵抗を示すことが多いため、フットプリントが小さい高性能なツールを選ぶことで、採用される可能性を高められます。

WAFとDoS対策を統合したツールは効率的に見えるかもしれませんが、実際には、フットプリントが大きいためCPU使用率が高くなるほか、柔軟性にも問題が生じると考えられます。両方が必要でない場合でも、WAFとDoS対策を同時に導入しなければなりません。最終的に、これら2つの問題によってKubernetes環境の総所有コストが増加し、ほかの重要なツールやサービスの予算確保が難しくなる可能性があります。

組織に適したセキュリティツールを選定したら、次にその導入先を決定します。Kubernetesアプリを保護するためのアプリケーションサービスは、通常、次の4つの場所に導入できます。

• フロントドア（外部のロードバランサー（例：F5 NGINX Plus、F5 BIG‑IP）— 複数のクラスターにグローバルポリシーを適用できるため、「粗粒度」のグローバルな保護に適しています
• エッジで（Ingressコントローラー（例：F5 NGINX Ingress Controller）上）— 単一クラスター全体に標準で適用する「きめ細かな」保護の提供に最適
• サービスレベル（NGINX Plusのような軽量ロードバランサー上）– クラスター内の少数のサービスで固有のポリシーを共通して必要とする場合に、必要となる可能性があるアプローチです
• ポッドレベル（アプリケーションの一部として）– アプリ固有のポリシーが必要な場合に使用されることがある、高度にカスタマイズされたアプローチです

では、4つの選択肢のうち、どれが最適なのでしょうか。実は……状況によって異なります。

WAFの導入場所

まず、より慎重な検討が必要となることが多いWAFの導入方法について見ていきます。

• フロントドアとエッジ – 組織で「多層防御」セキュリティ戦略を採用する場合は、グローバルな保護とカスタム保護を効率的に両立するため、外部ロードバランサーとIngressコントローラーの両方にWAFを導入することを推奨します。
• フロントドアまたはエッジ – 「多層防御」戦略を採用しない場合は、1か所への導入でも問題ありません。導入場所は、セキュリティの担当チームによって異なります。従来型のNetOpsチームがセキュリティを担当する場合は、従来型のプロキシ（外部ロードバランサー）で管理する方が適していることがあります。一方、Kubernetesに精通し、セキュリティ設定をクラスタ設定の近くに配置したいDevSecOpsチームは、IngressレベルへのWAFの導入を選択できます。
• サービスまたはPod単位 – チームのサービスやアプリに固有の要件がある場合は、必要に応じてWAFを追加で導入できます。ただし、こうした場所への導入には、より高いコストが伴う点に注意が必要です。開発期間の長期化やクラウド予算の増加に加え、「どのWAFが意図せずトラフィックをブロックしているのか」を特定する場合など、トラブルシューティングに関連する運用コストも増加する可能性があります。

DoS対策の導入場所

DoS攻撃対策は、必要な導入箇所が1か所（フロントドアまたはIngressコントローラー）だけなので、よりシンプルです。フロントドアとエッジの両方にWAFを導入する場合は、最も広範囲をカバーするフロントドアWAFの前段にDoS攻撃対策を導入することを推奨します。これにより、不要なトラフィックがWAFに到達する前に削減され、コンピューティングリソースをより効率的に利用できます。

各導入シナリオの詳細については、「Kubernetesでのアプリケーションサービスの導入（パート2）」をご覧ください。

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

ソリューション：イングレス ポイントで認証と認可を一元化

アプリやサービスに組み込まれる一般的な非機能要件の1つに、認証と認可があります。小規模な環境では、この方法によって増える複雑さは管理可能な範囲に収まり、アプリを頻繁に更新する必要がなければ許容できます。しかし、規模が拡大し、リリースの頻度が高まると、アプリに認証と認可を組み込む方法では対応しきれなくなります。各アプリで適切なアクセスプロトコルを維持しようとすると、アプリのビジネスロジックに集中できなくなる可能性があります。さらに悪いことに、対応が見落とされ、情報漏えいにつながるおそれもあります。SSOテクノロジーを使用すれば、個別のユーザー名とパスワードを廃止して1組の認証情報に統一できるため、セキュリティの向上に役立ちます。ただし、開発者は引き続き、SSOシステムと連携するためのコードをアプリに組み込む必要があります。

より優れた方法があります。認証と認可をIngressコントローラーにオフロードします。

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

このトピックの詳細については、「OktaとNGINX Ingress Controllerを使用したKubernetes向けOpenID Connect認証の実装」をご覧ください。

ユースケース：Guardrailsを備えたセルフサービスの設定

ソリューション： ロールベースのアクセス制御（RBAC）を実装

Kubernetesでは、RBACを使用して、ユーザーの種類ごとに利用可能なリソースと操作を制御します。管理者またはスーパーユーザーが、個々のユーザーやユーザーグループによる、クラスター内の任意のKubernetesオブジェクトまたは特定の名前空間に対する操作方法を指定できるため、セキュリティ対策として有効です。

Kubernetes RBACはデフォルトで有効になっていますが、Kubernetesトラフィック管理ツールでもRBACが有効であり、組織のセキュリティニーズに対応できることを確認する必要があります。RBACを導入すると、ユーザーはチケットの処理を待つことなく、業務に必要な機能に制限付きでアクセスできます。一方、RBACが構成されていない場合、ユーザーに不要な権限や付与対象ではない権限が与えられる可能性があり、それらが悪用されると脆弱性につながるおそれがあります。

Ingressコントローラーは、RBACを設定することで、多数のユーザーやチームに対応できるツールの代表例です。Ingressコントローラーで、単一の名前空間に至るまできめ細かなアクセス管理が可能な場合、RBACを使用してマルチテナンシーによるリソースの効率的な利用を実現できます。

たとえば、複数のチームが次のようにIngressコントローラーを使用する場合があります。

• NetOpsチーム – アプリケーションの外部エントリポイント（ホスト名やTLS証明書など）を設定し、トラフィック制御ポリシーを各チームに委任します
• DevOpsチームA – TCP/UDP負荷分散およびルーティングポリシーをプロビジョニング
• DevOpsチームB – 過剰なリクエストからサービスを保護するため、レート制限ポリシーを設定
• アイデンティティチーム – 認証および認可コンポーネントを管理するとともに、エンドツーエンド暗号化戦略の一環としてmTLSポリシーを設定します
• DevSecOpsチーム – WAFポリシーを設定

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

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

ソリューション：トラフィック管理ツールを使用する

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

最も一般的なシナリオ：Ingress Controllerを使用したE2EE

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

ステップ1：Ingressコントローラーが、サービス側証明書またはmTLS証明書を使用した暗号化SSL/TLS接続のみを許可するようにしてください。理想的には、受信トラフィックと送信トラフィックの両方に適用します。

ステップ2：Ingressコントローラーがアプリにトラフィックを送信する前に復号して再暗号化する必要がある、一般的なデフォルト設定に対処します。これにはいくつかの方法があり、使用するIngressコントローラーと要件に応じて選択します。

• IngressコントローラーがSSL/TLSパススルーをサポートしている場合、接続を復号したり、SSL/TLS証明書や鍵へのアクセスを必要としたりすることなく、Server Name Indication（SNI）ヘッダーに基づいてSSL/TLSで暗号化された接続をルーティングできます。
• または、SSL/TLS終端を設定することもできます。この場合、Ingressコントローラーがトラフィックを終端し、平文のまま、またはmTLSやサービス側SSL/TLSでトラフィックを再暗号化して、Kubernetesサービスのバックエンドまたはアップストリームにプロキシします。

一般的ではないシナリオ：Ingress Controllerとサービスメッシュを使用したE2EE

クラスター内でサービス間通信が行われる場合、E2EEを2つのプレーンに実装する必要があります。具体的には、Ingressコントローラーによるイングレス・エグレストラフィックと、サービスメッシュによるサービス間トラフィックです。E2EEにおけるサービスメッシュの役割は、特定のサービス間のみで安全に通信できるようにすることです。E2EE用のサービスメッシュを設定する際は、サービス間のmTLS（証明書を必須に設定）と、サービス間のトラフィックアクセス制御（通信を許可するサービスを指定）という2つの要素によって、ゼロトラスト環境を実現する必要があります。Kubernetesクラスター全体で真のE2EEセキュリティを実現するには、サービスメッシュとイングレス・エグレスコントローラーで管理されるアプリケーション間にもmTLSを実装することが理想的です。

ネットワーク上に露出したデータの暗号化について詳しくは、「NGINX Service MeshのmTLSアーキテクチャ」をご覧ください。

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

ソリューション：連邦情報処理標準（FIPS）に準拠

ソフトウェア業界でFIPSといえば、通常は暗号技術に特化した規格であるFIPS PUB 140-2「暗号モジュールのセキュリティ要件」を指します。これは米国とカナダが共同で策定したもので、機密情報を保護するために両国の連邦政府機関が採用する暗号モジュールの試験および認証を標準化しています。「でも、ちょっと待ってください」と思われるかもしれません。「北米の政府機関とは取引がないので、FIPSは関係ありません」しかし、FIPSは事実上、暗号技術のグローバルな基準でもあるため、業種や地域を問わず、FIPSに準拠することは賢明な選択となり得ます。

FIPSへの準拠は必ずしも難しくありませんが、オペレーティングシステムと関連するトラフィック管理ツールの両方がFIPSモードで動作できる必要があります。オペレーティングシステムをFIPSモードで実行するだけでFIPSに準拠できるという誤解がよくあります。オペレーティングシステムをFIPSモードで実行していても、Ingressコントローラーと通信するクライアントが強力な暗号スイートを使用していない可能性があります。FIPSモードで動作する場合、オペレーティングシステムとIngressコントローラーで使用できるのは、一般的なSSL/TLS暗号スイートの一部に限られることがあります。

Kubernetesデプロイメント向けのFIPS設定は、次の4つのステップで行います。

• ステップ1： オペレーティングシステムをFIPSモードに設定
• ステップ2： オペレーティングシステムとOpenSSLがFIPSモードになっていることを確認します
• ステップ3：Ingress Controllerをインストールします
• ステップ4： FIPSステータスチェックを実行して、FIPS 140-2への準拠を確認します

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

FIPSの詳細については、「NGINX PlusによるFIPS準拠の実現」をご覧ください。

NGINXでKubernetesのセキュリティを強化

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

• NGINX Ingress Controller – NGINX PlusをベースとするKubernetes向けIngressコントローラーです。高度なトラフィック制御とシェーピング、監視と可視化、認証とSSOに対応し、APIゲートウェイとしても機能します。
• F5 NGINX App Protect – F5の市場をリードするセキュリティテクノロジーを基盤とし、NGINX Ingress ControllerおよびNGINX Plusと統合することで、最新のアプリとAPIを包括的に保護します。モジュール型のアプローチにより、導入シナリオの柔軟性を高め、リソース利用を最適化できます：
  • NGINX App Protect WAF – OWASP Top 10をはじめとする脅威から保護し、PCI DDSに準拠した、堅牢で軽量なWAFです。
  • NGINX App Protect DoS – クラウドやアーキテクチャを問わず、一貫性のある適応型の保護により、振る舞いに基づくDoSの検知と緩和を実現します。
• F5 NGINX Service Mesh – NGINX Plusをエンタープライズ向けサイドカーとして搭載した、軽量で導入が容易な、開発者にとって使いやすいサービスメッシュです。

まずは、NGINX App Protect WAFおよびDoSを搭載したNGINX Ingress Controllerの30日間無料トライアルをお申し込みください。また、常時無料のNGINX Service Meshをダウンロードしてご利用いただけます。

著者について

Jenn GileNGINX製品マーケティング責任者

Jenn Gileのその他のブログ記事