ブログ | NGINX

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

NGINX-F5 水平黒タイプ RGB の一部
ジェン・ギル サムネイル
ジェン・ガイル
2021年12月20日公開

編集者– この投稿は10 部構成のシリーズの一部です。

  1. プロダクショングレードのKubernetesで複雑さを軽減
  2. 高度なトラフィック管理で Kubernetes の回復力を向上させる方法
  3. Kubernetes の可視性を向上させる方法
  4. トラフィック管理ツールを使用して Kubernetes を保護する 6 つの方法 (この投稿)
  5. Ingress コントローラーの選択ガイド、パート 1: 要件を特定する
  6. Ingress コントローラーの選択ガイド、パート 2: リスクと将来への備え
  7. Ingress コントローラーの選択ガイド、パート 3: オープンソース vs. デフォルト vs. コマーシャル
  8. Ingress コントローラーの選択ガイド、パート 4: NGINX Ingress コントローラー オプション
  9. サービスメッシュの選択方法
  10. 動的 Kubernetes クラウド環境での NGINX Ingress コントローラーのパフォーマンス テスト

また、ブログの完全セットを無料の電子書籍「 Taking Kubernetes from Test to Production」としてダウンロードすることもできます。

「速度を落とさずにクラウドネイティブ アプリを保護する」で説明したように、クラウドネイティブ アプリのセキュリティ保護を従来のアプリよりも困難にする 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 に関する用語の概要を簡単に説明します。

  • 認証と承認– 「適切な」ユーザーとサービスだけがバックエンドまたはアプリケーション コンポーネントにアクセスできるようにするために必要な機能:

    • 認証– リクエストを行うクライアントが本人であることを確認するためのID検証。 パスワードや JSON Web Token (JWT) などの ID トークンを通じて実行されます。

    • 承認– リソースまたは機能にアクセスするための権限の検証。 セッション Cookie、セッション ID、グループ ID、トークン コンテンツなどのレイヤー 7 属性などのアクセス トークンを通じて実現されます。

  • 重大な脆弱性と露出 (CVE) – 「悪用される可能性のある弱点に起因するソフトウェア、ファームウェア、ハードウェア、またはサービス コンポーネント内の、影響を受けるコンポーネントの機密性、整合性、または可用性に悪影響を及ぼす」公開された欠陥のデータベース ( https://www.cve.org/ )。 CVE は、ツールを管理する開発者、侵入テスター、ユーザーまたは顧客、またはコミュニティのメンバー (「バグハンター」など) によって発見される可能性があります。 悪意のある人物に有利な状況を与えないように、脆弱性が公開される前にソフトウェア所有者にパッチを開発する時間を与えるのが一般的な慣行です。

  • サービス拒否 (DoS) 攻撃– 悪意のある人物が Web サイトに大量のリクエスト (TCP/UDP または HTTP/HTTPS) を送りつけ、サイトをクラッシュさせることを目的とする攻撃。 DoS 攻撃は可用性に影響を与えるため、主な結果はターゲットの評判の損失です。 複数のソースが同じネットワークまたはサービスをターゲットとする分散型サービス拒否 (DDoS)攻撃は、攻撃者のネットワークが大規模になる可能性があるため、防御がより困難になります。 DoS 保護には、攻撃を適応的に識別して防止するツールが必要です。 詳細については、 「分散型サービス拒否 (DDoS) とは何ですか?」をご覧ください。

  • エンドツーエンド暗号化 (E2EE) – ユーザーからアプリへ、そしてアプリからユーザーへデータが渡される際に、データを完全に暗号化する方法。 E2EE には SSL 証明書と、場合によっては mTLS が必要です。

  • 相互 TLS (mTLS) – クライアントとホストの両方に認証 (SSL/TLS 証明書経由) を要求する方法。 mTLS を使用すると、クライアントとホスト間で渡されるデータの機密性と整合性も保護されます。mTLS は、同じクラスター内の 2 つのサービス間で、Kubernetes ポッド レベルまで実現できます。 SSL/TLS と mTLS の優れた入門については、F5 Labs の「What is mTLS?」を参照してください。

  • シングル サインオン (SSO) – SSO テクノロジー (SAML、OAuth、OIDC など) により、認証と承認の管理が容易になります。

    • 簡素化された認証- SSO により、ユーザーは異なるリソースや機能ごとに一意の ID トークンを持つ必要がなくなります。

    • 標準化された認証- SSO により、役割、部門、および役職レベルに基づいてユーザーのアクセス権の設定が容易になり、各ユーザーの権限を個別に構成する必要がなくなります。

  • SSL (Secure Sockets Layer)/TLS (Transport Layer Security) – ネットワーク化されたコンピュータ間で認証され暗号化されたリンクを確立するためのプロトコル。 SSL/TLS 証明書は、Web サイトの ID を認証し、暗号化された接続を確立します。 SSL プロトコルは 1999 年に廃止され、TLS プロトコルに置き換えられましたが、これらの関連テクノロジーを「SSL」または「SSL/TLS」と呼ぶことは今でも一般的です。一貫性を保つために、この記事の残りの部分ではSSL/TLS を使用します。

  • Web アプリケーション ファイアウォール (WAF) – アプリや API に対する高度な攻撃 ( OWASP Top 10やその他の高度な脅威を含む) を検出してブロックし、「安全な」トラフィックを通過させるリバース プロキシ。 WAF は、機密データを盗んだりシステムを乗っ取ったりしてターゲットに損害を与えようとする攻撃から防御します。 ベンダーによっては、WAF と DoS 保護を同じツールに統合しているところもありますが、WAF と DoS のツールを別々に提供しているところもあります。

  • ゼロ トラスト– 高度なセキュリティが求められる組織で頻繁に使用されるセキュリティ コンセプトですが、すべての人に関係し、保存と転送のすべての段階でデータを保護する必要があります。 これは、組織がデフォルトでユーザーやデバイスを「信頼」しないことを決定し、すべてのトラフィックを徹底的に検査することを要求することを意味します。 ゼロトラスト アーキテクチャには通常、認証、承認、mTLS の組み合わせが含まれ、組織が E2EE を実装する可能性が高いです。

使用事例： サイバー攻撃を回避するためにCVEを迅速に解決する

解決： タイムリーでプロアクティブなパッチ通知機能を備えたツールを使用する

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

専任のエンジニアリング チームではなくコミュニティの貢献者によって開発および保守されているツールは、CVE の発表から数週間または数か月遅れる可能性があり、組織が43 日間の期間内にパッチを適用できる可能性は低くなります。 あるケースでは、OpenResty が NGINX 関連のセキュリティ パッチを適用するのに 4 か月かかりました。 これにより、OpenResty ベースの Ingress コントローラーを使用しているユーザーは少なくとも 4 か月間は脆弱な状態になりましたが、現実的には、オープン ソース プロジェクトに依存するソフトウェアのパッチが利用可能になるまでには通常、さらに遅延が発生します。

サードパーティの NGINX ディストリビューションがセキュリティ パッチを適用するのに数か月かかる可能性があることを示す図

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

  • 専任のエンジニアリング チーム– ツール開発がコミュニティのボランティアではなくエンジニアリング チームによって管理されている場合、ツールの健全性に専念し、できるだけ早くパッチのリリースを優先できる人々のグループが存在することがわかります。
  • 統合されたコード ベース- 外部依存関係がないため (OpenResty で説明したように)、パッチはアジャイル スプリントですぐに適用できます。

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 保護を一緒に展開する必要があります。 最終的には、両方の問題により、Kubernetes デプロイメントの総所有コストが上昇すると同時に、他の重要なツールやサービスの予算上の課題が生じる可能性があります。

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

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

では、4 つのオプションのうちどれが最適でしょうか? まあ…それは状況によります！

WAF を導入する場所

まず、WAF の導入オプションについて見ていきます。これは、より微妙な選択になる傾向があるためです。

  • フロントドアとエッジ– 組織が「多層防御」のセキュリティ戦略を希望する場合は、外部ロードバランサーと Ingress コントローラーの両方に WAF を展開して、グローバル保護とカスタム保護の効率的なバランスを実現することをお勧めします。
  • フロントドアまたはエッジ- 「多層防御」戦略がない場合、単一の場所が許容され、展開場所は所有権によって異なります。 従来の NetOps チームがセキュリティを所有している場合、従来のプロキシ (外部ロード バランサ) でセキュリティを管理する方が快適である可能性があります。 ただし、Kubernetes に慣れている (そしてセキュリティ構成をクラスター構成の近くに置くことを好む) DevSecOps チームは、イングレス レベルで WAF を展開することを選択できます。
  • サービスまたはポッドごと– チームのサービスまたはアプリに特定の要件がある場合は、追加の WAF をアラカルト形式で展開できます。 ただし、注意してください。これらの場所ではコストが高くなります。 この選択により、開発時間の増加とクラウド予算の増加に加えて、「どの WAF が意図せずトラフィックをブロックしているか」を判断する場合など、トラブルシューティング作業に関連する運用コストも増加する可能性があります。

DoS 保護を展開する場所

DoS 攻撃に対する保護は、正面玄関または Ingress コントローラーのいずれか1か所でのみ必要なので、より簡単です。 フロントドアとエッジの両方に WAF を展開する場合は、最もグローバルなフロントドア WAF の前に DoS 保護を展開することをお勧めします。 こうすることで、WAF に到達する前に不要なトラフィックを削減できるため、コンピューティング リソースをより効率的に使用できるようになります。

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

使用事例： アプリから認証と承認をオフロードする

解決： 入口での認証と承認を一元管理する

アプリやサービスに組み込まれる一般的な非機能要件は、認証と承認です。 小規模な場合、この方法により、アプリが頻繁に更新される必要がない場合に許容できる程度の複雑さが追加されます。 しかし、大規模かつ高速なリリースでは、認証と承認をアプリに統合することが不可能になります。 各アプリが適切なアクセス プロトコルを維持していることを確認すると、アプリのビジネス ロジックが妨げられたり、最悪の場合、見落とされて情報漏洩につながる可能性があります。 SSO テクノロジを使用すると、個別のユーザー名とパスワードがなくなり、1 セットの資格情報で済むためセキュリティが向上しますが、開発者は依然として SSO システムとインターフェイスするためのコードをアプリに組み込む必要があります。

もっと良い方法があります。認証と承認を Ingress コントローラーにオフロードすることです。

Kubernetes の認証と承認を Ingress コントローラにオフロードする図

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

このトピックの詳細については、 「Okta と NGINX Ingress Controller を使用して Kubernetes に OpenID Connect 認証を実装する」をお読みください。

使用事例： ガードレールでセルフサービスを設定する

解決： ロールベースのアクセス制御（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 ポリシーの設定

異なる役割を持つエンタープライズ チームが同じ Ingress コントローラにポリシーを展開する方法を示した図

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

使用事例： エンドツーエンドの暗号化を実装する

解決： トラフィック管理ツールを使用する

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

最も一般的なシナリオ: イングレスコントローラを使用したE2EE

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

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

ステップ2: Ingress コントローラがトラフィックをアプリに送信する前に復号化して再暗号化することを要求する一般的なデフォルト設定に対処します。 これはいくつかの方法で実現できます。選択する方法は、Ingress コントローラーと要件によって異なります。

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

あまり一般的ではないシナリオ: イングレス コントローラとサービス メッシュを使用した E2EE

クラスター内でサービス間通信が行われる場合は、Ingress コントローラーを使用した入出力トラフィックと、サービスメッシュを使用したサービス間トラフィックの 2 つのプレーンで E2EE を実装する必要があります。 E2EE では、サービス メッシュの役割は、特定のサービスのみが相互に通信できるようにし、安全な方法で通信できるようにすることです。 E2EE 用のサービス メッシュを設定する場合は、サービス間の mTLS (証明書を要求するように設定) とサービス間のトラフィック アクセス制御 (どのサービスが通信を許可されるかを決定) という 2 つの要素を通じてゼロ トラスト環境を有効にする必要があります。 理想的には、Kubernetes クラスター全体で真の E2EE セキュリティを実現するために、アプリケーション (サービス メッシュと Ingress-Egress コントローラーによって管理される) 間にも 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コントローラをインストールする
  • ステップ4: FIPSステータスチェックを実行してFIPS 140-2への準拠を確認する

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

NGINX Ingress Controller と NGINX App Protect を使用して Kubernetes で FIP を実装した図

FIPS の詳細については、 「NGINX Plus による FIPS 準拠の達成」を参照してください。

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

これらのセキュリティ メソッドの一部 (またはすべて) を実装する準備ができている場合は、ツールにユース ケースをサポートする適切な機能があることを確認する必要があります。 NGINX は、本番環境に対応した Kubernetes トラフィック管理ツール スイートで役立ちます。

  • NGINX Ingress コントローラー– 高度なトラフィック制御とシェーピング、監視と可視性、認証と SSO を処理し、API ゲートウェイとして機能する、Kubernetes 用のNGINX Plus ベースのIngress コントローラー。

  • F5 NGINX App Protect – F5 の市場をリードするセキュリティ テクノロジーを基盤とし、NGINX Ingress Controller および NGINX Plus と統合された、最新のアプリと API を総合的に保護します。 モジュール式のアプローチを使用して、展開シナリオの柔軟性と最適なリソース利用を実現します。

    • NGINX App Protect WAF – PCI DDS に準拠し、OWASP Top 10 以上の脅威から保護する強力で軽量な WAF。

    • NGINX App Protect DoS – クラウドとアーキテクチャ全体にわたる一貫性のある適応型保護による動作 DoS 検出と軽減。

  • F5 NGINX サービス メッシュ– エンタープライズ サイドカーとして NGINX Plus を搭載した、軽量でターンキー、開発者向けのサービス メッシュ。

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

F5 NGINX に関するブログ投稿をもっと読む ›

「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"