Amazon EKS上のF5 NGINX App Protectでセキュリティをシフトレフト

Fabrizio FiorucciNGINXソリューションアーキテクト | F5 (EMEA)

Thelen Blumシニアプロダクトマーケティングマネージャー、NGINX App Protect | F5

F5の「2022年版アプリケーション戦略の現状」レポートによると、企業のデジタルトランスフォーメーションは世界的に加速し続けています。ほとんどの企業は、複数のクラウドゾーンにまたがって200～1,000個のアプリを展開しており、現在のアプリはモノリシックアーキテクチャから最新の分散アーキテクチャへと移行しています。

Kubernetesが一般に利用されるテクノロジーとして登場したのは、わずか6年前の2016年です。しかし現在では、世界の組織の75%以上がコンテナ化されたアプリケーションを本番環境で稼働させており、2019年から30%増加しています。Amazon Elastic Kubernetes Service（EKS）を含むKubernetes環境における重大な課題の1つが、セキュリティです。多くの場合、セキュリティ対策はアプリケーション開発プロセスの最後に「後付け」され、コンテナ化されたアプリケーションがすでに稼働した後になって初めて導入されることさえあります。

COVID‑19のパンデミックによって加速した現在のデジタルトランスフォーメーションの波を受け、多くの企業はセキュリティをより包括的に捉え、「シフトレフト」戦略を検討せざるを得なくなっています。セキュリティのシフトレフトとは、ソフトウェア開発ライフサイクル（SDLC）の早い段階でセキュリティ対策を導入し、アプリケーション、コンテナ、マイクロサービス、APIのCI/CDパイプラインの各段階でセキュリティツールと制御を使用することです。これは、DevOpsプロセスにセキュリティを組み込み、最新のソフトウェアアプリケーションの開発とデリバリーに特有の迅速なリリースサイクルに統合する、DevSecOpsと呼ばれる新たなパラダイムへの移行を意味します。

DevSecOpsは、組織文化の大きな変革を意味します。セキュリティチームとDevOpsチームは、高品質な製品を迅速かつセキュアに市場へ投入するという共通の目的に向けて連携します。開発者は、ワークフローを中断させるセキュリティ手順にたびたび阻まれることがなくなります。セキュリティチームも、同じ問題への対応を繰り返す必要がなくなります。これにより、脆弱性や設定ミス、コンプライアンス違反またはポリシー違反を発生時に検出して防止し、組織の強固なセキュリティ態勢を維持できます。

セキュリティをシフトレフトし、セキュリティをコードとして自動化することで、Amazon EKS環境を初期段階から保護できます。大規模環境で本番運用に対応する方法を習得することは、Kubernetes基盤の構築において重要です。Amazon EKSを適切にガバナンスすることで、コストを管理しながら、ビジネス全体の効率性、透明性、説明責任の向上を促進できます。強固なガバナンスとセキュリティガードレールにより、クラスターの可視性と制御を高めるための枠組みを構築できます。これらがなければ、セキュリティ侵害のリスクが高まり、収益や評判への損害に伴う長期的なコストが発生するおそれがあります。

セキュリティファースト戦略への移行時に検討すべき事項について詳しくは、O’Reillyの最新レポート「アプリケーションセキュリティのシフトレフト」をご覧ください。

GitOpsによるAmazon EKSのセキュリティ自動化

自動化はDevSecOpsを実現するうえで重要な要素であり、開発とデプロイが急速に進む環境でも一貫性の維持に役立ちます。Infrastructure as Codeと同様に、Security as Codeのアプローチによる自動化では、宣言型ポリシーを使用して望ましいセキュリティ状態を維持します。

GitOpsは、自動化を促進し、アプリケーションデリバリとクラスター管理を支援・簡素化する運用フレームワークです。GitOpsの基本的な考え方は、KubernetesオブジェクトとKubernetes上で稼働するアプリケーションをコードとして定義し、その宣言型ポリシーをGitリポジトリに保存することです。自動化されたプロセスによって本番環境を保存済みのすべての状態記述と一致させることで、GitOpsのパラダイムが完成します。

このリポジトリは、セキュリティポリシーという形で信頼できる唯一の情報源として機能します。これらのポリシーは、CI/CDパイプラインプロセスの一環として、宣言型のConfiguration as Codeの記述から参照されます。たとえば、NGINXは、F5 NGINX App Protect用のAnsibleロールを含むGitHubリポジトリを管理しています。セキュリティのシフトレフトを目指すチームに、このリポジトリがお役に立てば幸いです。

このようなリポジトリがあれば、新しいアプリケーションのデプロイや既存アプリケーションの更新は、リポジトリを更新するだけで行えます。設定の適用や更新の成功確認など、それ以外の処理はすべて自動化されたプロセスが管理します。これにより、すべての処理が開発者向けのバージョン管理システム上で行われ、同期されるため、ビジネスクリティカルなアプリケーションにセキュリティを適用できます。

Amazon EKS上で運用する場合、GitOpsによりセキュリティをシームレスかつ堅牢に確保できるほか、人為的ミスをほぼ排除し、適用されたすべてのバージョン変更を継続的に追跡できます。

NGINX App ProtectとNGINX Ingress ControllerでAmazon EKS上のアプリとAPIを保護

堅牢なKubernetesセキュリティポリシーを設計するには、SecOpsとDevOps双方のニーズに対応し、環境の拡張に適応できる仕組みを組み込む必要があります。Kubernetesクラスターは、さまざまな方法で共有できます。たとえば、1つのクラスターで複数のアプリケーションを実行してリソースを共有する場合もあれば、エンドユーザーやグループごとに1つのアプリケーションの複数のインスタンスを実行する場合もあります。つまり、セキュリティ境界が必ずしも明確に定義されるとは限らないため、柔軟できめ細かなセキュリティポリシーが必要です。

セキュリティ設計全体には、例外に対応できる十分な柔軟性、CI/CDパイプラインへの容易な統合、マルチテナンシーへの対応が必要です。Kubernetesにおけるテナントとは、特定の事業部門、チーム、ユースケース、または環境に関連付けられたKubernetesオブジェクトとアプリケーションを論理的にグループ化したものです。したがって、マルチテナンシーとは、複数のテナントが同じクラスターを安全に共有し、ビジネスニーズと密接に結び付いた技術的なセキュリティ要件に基づいてテナント間の境界を適用することを意味します。

Amazon EKSに低レイテンシーで高性能なセキュリティを容易に実装するには、NGINX App Protect WAF and DoSモジュールをNGINX Ingress Controllerに組み込みます。このようなインラインソリューションを提供している競合他社はありません。連携するテクノロジーを1つの製品で利用することで、コンピューティング時間やコストの削減、ツールの乱立防止など、さまざまなメリットが得られます。その他のメリットは次のとおりです。

• アプリケーション境界の保護 – 適切に設計されたKubernetes環境では、Kubernetes内で稼働するサービスに向かうデータプレーントラフィックの唯一のエントリーポイントがNGINX Ingress Controllerとなるため、WAFとDoS対策を導入するのに最適な場所です。
• データプレーンの統合 – NGINX Ingress ControllerにWAFを組み込むことで、個別のWAFデバイスが不要になります。これにより、複雑さ、コスト、障害点の数を削減できます。
• コントロールプレーンの統合 – WAFおよびDoSの設定はKubernetes APIで管理できるため、CI/CDプロセスの自動化が大幅に容易になります。NGINX Ingress Controllerの設定は、Kubernetesのロールベースアクセス制御（RBAC）のプラクティスに準拠しているため、WAFおよびDoSの設定を専任のDevSecOpsチームに安全に委任できます。

NGINX App Protect WAFおよびDoSの構成オブジェクトは、NGINX Ingress ControllerとNGINX Plusで共通です。マスター構成は簡単に変換していずれのデバイスにもデプロイできるため、WAF構成をコードとして管理し、任意のアプリケーション環境にデプロイする作業がさらに容易になります

NGINX App Protect WAFおよびDoSをNGINX Ingress Controllerに組み込むには、NGINX Plusと、NGINX App Protect WAFまたはDoSの両方のサブスクリプションが必要です。わずか数ステップで、統合されたNGINX Ingress Controllerイメージ（Dockerコンテナ）をビルドできます。イメージを（たとえば、手動またはHelmチャートを使用して）デプロイした後は、使い慣れたKubernetes APIを使用してセキュリティポリシーと構成を管理できます。

NGINX PlusをベースとするNGINX Ingress Controllerでは、認証、RBACベースの認可、Podとの外部通信をきめ細かく制御、管理できます。クライアントがHTTPSを使用している場合、NGINX Ingress ControllerはTLSを終端してトラフィックを復号し、レイヤー7ルーティングの適用とセキュリティの適用を行うことができます。

その後、軽量なソフトウェアセキュリティソリューションとしてNGINX App Protect WAFとNGINX App Protect DoSを導入し、セキュリティポリシーを適用することで、レイヤー7を狙ったポイント攻撃から保護できます。NGINX App Protect WAFは、KubernetesアプリをOWASP Top 10攻撃から保護するとともに、高度なシグネチャと脅威対策、ボット対策、個人を特定できる情報（PII）の悪用を防ぐDataguard保護機能を提供します。NGINX App Protect DoSは、レイヤー4および7に防御層を追加し、ユーザー行動分析とアプリの健全性チェックによって高度なアプリケーションレイヤーDoS攻撃を緩和します。これにより、Slow POST、Slowloris、フラッド攻撃、Challenger Collapsarなどの攻撃から保護します。

このようなセキュリティ対策により、REST APIとWebブラウザーからアクセスするアプリケーションの両方が保護されます。また、南北方向のトラフィックフローに沿って、IngressレベルでもAPIセキュリティが適用されます。

NGINX App Protect WAFおよびDoSを備えたNGINX Ingress Controllerは、サービス単位ではなくリクエスト単位でAmazon EKSトラフィックを保護できます。これにより、レイヤー7トラフィックをより有用な観点から把握でき、SLAと南北方向のWAFセキュリティをより効果的に適用できます。

GigaOmの最新レポート「高性能Webアプリケーションファイアウォールのテスト」では、NGINX App Protect WAFが高いパフォーマンスと低レイテンシを維持しながら、アプリとAPIに一貫して強固なセキュリティを提供し、テストしたすべての攻撃レートで、他の3つのWAF（AWS WAF、Azure WAF、Cloudflare WAF）を上回ったことが示されています。

例として、図4は、WAFが1秒あたり500リクエスト（RPS）を処理するテストの結果を示しています。そのうち95%（475 RPS）は有効なリクエスト、5%（25 RPS）は「不正な」リクエスト（スクリプトインジェクションをシミュレーション）でした。99パーセンタイルでは、NGINX App Protect WAFのレイテンシは、AWS WAFの10分の1、Cloudflare WAFの60分の1、Azure WAFの120分の1でした。

図5は、各リクエストのレイテンシが30ミリ秒未満で、成功率100%（5xxまたは429エラーなし）を達成した際の各WAFの最大スループットを示しています。NGINX App Protect WAFは19,000 RPSを処理したのに対し、Cloudflare WAFは14,000 RPS、AWS WAFは6,000 RPS、Azure WAFはわずか2,000 RPSでした。

Amazon EKSにNGINX App ProtectとNGINX Ingress Controllerをデプロイする方法

NGINX App Protect WAFとDoSは、完全に宣言型の構成とセキュリティポリシーによるアプリケーション中心のセキュリティアプローチを活用し、Amazon EKS上のアプリケーションライフサイクルに対応するCI/CDパイプラインへセキュリティを容易に統合できるようにします。

NGINX Ingress Controllerは、Webアプリケーションセキュリティのあらゆる側面を管理し、責任共有モデルとマルチテナントモデルをサポートするために、複数のカスタムリソース定義（CRD）を提供します。CRDマニフェストは、組織で使用されている名前空間のグループ分けに従って適用できるため、複数の運用グループによる所有が可能になります。

Amazon EKSでアプリケーションを公開する際は、既存の自動化パイプラインを活用し、その上にWAFセキュリティポリシーを適用することで、セキュリティを組み込むことができます。

さらに、NGINX Ingress Controller上のNGINX App Protectでは、CPUとメモリの両方にリソース使用率のしきい値を設定し、NGINX App Protectがリソースを占有して他のプロセスに不足を生じさせないようにできます。これは、リソース共有を前提とし、「ノイジーネイバー」問題が発生する可能性のあるKubernetesなどのマルチテナント環境では特に重要です。

NGINX CRDを使用したログの設定

NGINX App ProtectとNGINX Ingress Controllerのログは、セキュリティチームが通常、DevOpsチームやアプリケーション所有者とは独立して業務を行う体制を反映し、設計上分離されています。Kubernetes Podから到達可能な任意のsyslog送信先にNGINX App Protectのログを送信するには、app-protect-security-log-destinationアノテーションのパラメーターにsyslog PodのクラスターIPアドレスを設定します。また、APLogConfリソースを使用して、必要なNGINX App Protectのログを指定できます。これにより、syslog Podに送信するログが決まります。NGINX Ingress Controllerのログは、すべてのKubernetesコンテナと同様に、ローカルの標準出力に転送されます。

このAPLogConfリソースのサンプルでは、悪意のあるリクエストだけでなく、すべてのリクエストをログに記録するよう指定し、ログに記録できるメッセージとリクエストの最大サイズを設定しています。

apiVersion: appprotect.f5.com/v1beta1 kind: APLogConf 
metadata: 
 name: logconf 
 namespace: dvwa 
spec: 
 content: 
   format: default 
   max_message_size: 64k 
   max_request_size: any 
 filter: 
   request_type: all

NGINX CRDを使用したWAFポリシーの定義

The APPolicyポリシーオブジェクトは、宣言型アプローチに基づき、シグネチャセットとセキュリティルールを使用してWAFセキュリティポリシーを定義するCRDです。このアプローチはNGINX App Protect WAFとDoSの両方に適用されますが、以下の例ではWAFに焦点を当てます。ポリシー定義は通常、SecOpsカタログの一部として、組織の信頼できる情報源に保存されます。

apiVersion: appprotect.f5.com/v1beta1 kind: APPolicy 
metadata: 
  name: sample-policy
spec: 
  policy: 
    name: sample-policy 
    template: 
      name: POLICY_TEMPLATE_NGINX_BASE 
    applicationLanguage: utf-8 
    enforcementMode: blocking 
    signature-sets: 
    - name: Command Execution Signatures 
      alarm: true 
      block: true
[...]

Amazon EKSクラスターにセキュリティポリシーのマニフェストを適用したら、リクエストがWAFポリシーに違反した際にログへ書き込まれるエントリの種類と形式を定義するため、log-violationsという名前のAPLogConfオブジェクトを作成します。

apiVersion: appprotect.f5.com/v1beta1 kind: APLogConf 
metadata: 
  name: log-violations
spec: 
  content: 
    format: default 
    max_message_size: 64k 
    max_request_size: any 
  filter: 
    request_type: illegal

次に、waf-policy Policyオブジェクトは、NGINX Ingress Controllerによってアプリケーションが公開された際に、受信トラフィックに対してNGINX App Protect WAFが適用するsample-policyを参照します。また、log-violationsを参照して、logDestフィールドで指定されたsyslogサーバーに送信するログエントリの形式を定義します。

apiVersion: k8s.nginx.org/v1 kind: Policy 
metadata: 
  name: waf-policy 
spec: 
  waf: 
    enable: true 
    apPolicy: "default/sample-policy" 
    securityLog: 
      enable: true 
      apLogConf: "default/log-violations" 
      logDest: "syslog:server=10.105.238.128:5144"

DevOpsが、Amazon EKS上でアプリケーションを公開するようにNGINX Ingress Controllerを構成する「VirtualServer」オブジェクトを公開すると、デプロイは完了です。

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
  name: eshop-vs
spec:
  host: eshop.lab.local
  policies:
  - name: default/waf-policy
  upstreams:
  - name: eshop-upstream
    service: eshop-service
    port: 80
  routes:
  - path: /
    action:
      pass: eshop-upstream

VirtualServerオブジェクトを使用すると、共有責任モデルを維持しながら、Amazon EKS上で稼働するコンテナ化アプリを容易に公開し、保護できます。このモデルでは、SecOpsが包括的なセキュリティポリシーのカタログを提供し、DevOpsはそれを活用して初日からセキュリティをシフトレフトします。これにより、組織はDevSecOps戦略へ移行できます。

まとめ

長年にわたって構築してきたレガシーアプリケーションやセキュリティソリューションを抱える企業にとって、Amazon EKSでセキュリティをシフトレフトする取り組みは、段階的に進めることになるでしょう。しかし、セキュリティを、セキュリティチームが管理・保守し、DevOpsが利用するコードとして捉え直すことで、サービスをより迅速に提供し、本番環境で利用できる状態に整えやすくなります。

Amazon EKSのノースサウストラフィックを保護するには、NGINX App Protect WAFを組み込んだNGINX Ingress Controllerを活用してレイヤー7でのポイント攻撃を防御し、NGINX App Protect DoSを活用してレイヤー4および7でDoS攻撃を緩和できます。

NGINX App Protect WAFを搭載したNGINX Ingress Controllerをお試しいただくには、AWS Marketplaceで30日間の無料トライアルを開始するか、ユースケースについてご相談いただくため、F5までお問い合わせください。

Amazon EKS上でNGINX Ingress Controller、NGINX App Protect WAFおよびDoSを使用し、セキュリティ侵害を防止してKubernetesアプリを大規模に保護する方法については、eBook「F5 NGINXでAmazon EKSのセキュリティを強化」をダウンロードしてください。

NGINX App Protect WAFがAWS、Azure、CloudflareのネイティブWAFをどのように上回るかについて詳しくは、GigaOmのレポート「高性能Webアプリケーションファイアウォールのテスト」をダウンロードし、GigaOmのアナリストであるJake Dolezalが結果を解説する12月6日の「ウェビナー」にご登録ください。

著者について

Fabrizio FiorucciNGINXソリューションアーキテクト | F5 (EMEA)

Fabrizio Fiorucciのその他のブログ記事

Thelen Blumシニアプロダクトマーケティングマネージャー、NGINX App Protect | F5

Thelen Blumのその他のブログ記事