Amazon EKS で F5 NGINX App Protect を使用してセキュリティをシフトレフトする

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 の最新レポート「Shifting Left for Application Security」をご覧ください。

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

自動化は DevSecOps の重要な実現手段であり、開発と展開のペースが速い場合でも一貫性を維持するのに役立ちます。 インフラストラクチャ アズ コードと同様に、セキュリティ アズ コードアプローチによる自動化では、宣言型ポリシーを使用して必要なセキュリティ状態を維持する必要があります。

GitOps は、自動化を促進してアプリケーションの配信とクラスター管理をサポートおよび簡素化する運用フレームワークです。 GitOps の主なアイデアは、コードとして定義された Kubernetes オブジェクトと Kubernetes 上で実行されているアプリケーションの宣言型ポリシーを保存する Git リポジトリを持つことです。 自動化されたプロセスにより、GitOps パラダイムが完成し、運用環境が保存されているすべての状態の説明と一致するようになります。

リポジトリは、セキュリティ ポリシーの形式で信頼できる情報源として機能し、CI/CD パイプライン プロセスの一部として、宣言型の構成コード記述によって参照されます。 たとえば、NGINX はF5 NGINX App Protect 用の Ansible ロールを備えた GitHub リポジトリを維持しており、これがセキュリティをシフトレフトしたいチームを支援するのに役立つことを期待しています。

このようなリポジトリを使用すると、新しいアプリケーションをデプロイしたり、既存のアプリケーションを更新したりするには、リポジトリを更新するだけで済みます。 自動化されたプロセスは、構成の適用や更新の成功の確認など、その他すべてを管理します。 これにより、開発者向けのバージョン管理システム内ですべてが確実に実行され、同期されてビジネスクリティカルなアプリケーションのセキュリティが強化されます。

GitOps を Amazon EKS で実行すると、セキュリティがシームレスかつ堅牢になり、人為的エラーが事実上排除され、時間の経過とともに適用されるすべてのバージョン変更が追跡されます。

NGINX App Protect と NGINX Ingress Controller は Amazon EKS のアプリと API を保護します

Kubernetes セキュリティ ポリシーの堅牢な設計では、SecOps と DevOps の両方のニーズに対応し、環境の拡張に合わせて適応するための規定を含める必要があります。 Kubernetes クラスターはさまざまな方法で共有できます。 たとえば、クラスターでは複数のアプリケーションが実行され、リソースが共有される場合がありますが、別のケースでは、1 つのアプリケーションのインスタンスが複数存在し、それぞれが異なるエンド ユーザーまたはグループ用である場合があります。 これは、セキュリティ境界が必ずしも明確に定義されているわけではなく、柔軟できめ細かいセキュリティ ポリシーが必要であることを意味します。

全体的なセキュリティ設計は、例外に対応できるほど柔軟で、CI/CD パイプラインに簡単に統合でき、マルチテナントをサポートする必要があります。 Kubernetes のコンテキストでは、テナントは、特定のビジネス ユニット、チーム、ユース ケース、または環境に関連付けられた Kubernetes オブジェクトとアプリケーションの論理的なグループです。 マルチテナントとは、複数のテナントが同じクラスターを安全に共有し、ビジネス ニーズに密接に関連する技術的なセキュリティ要件に基づいてテナント間の境界が強制されることを意味します。

Amazon EKS に低レイテンシーで高性能なセキュリティを実装する簡単な方法は、 NGINX Ingress ControllerにNGINX App Protect WAF および DoSモジュールを埋め込むことです。 当社の他の競合他社は、このタイプのインライン ソリューションを提供していません。 同期されたテクノロジーを備えた 1 つの製品を使用すると、計算時間、コスト、ツールの無秩序な増加の削減など、さまざまな利点が得られます。 ここにいくつかの追加の利点があります。

• アプリケーション境界の保護– 適切に設計された Kubernetes デプロイメントでは、NGINX Ingress Controller は、Kubernetes 内で実行されているサービスに流れるデータプレーン トラフィックの唯一のエントリ ポイントであるため、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 ベースの認可、ポッドとの外部インタラクションのきめ細かな制御と管理を提供します。 クライアントが HTTPS を使用している場合、NGINX Ingress Controller は TLS を終了し、トラフィックを復号化してレイヤー 7 ルーティングを適用し、セキュリティを強化できます。

NGINX App Protect WAF と NGINX App Protect DoS を導入してセキュリティ ポリシーを適用し、軽量のソフトウェア セキュリティ ソリューションとしてレイヤー 7 でのポイント攻撃から保護することができます。 NGINX App Protect WAF は、OWASP Top 10 攻撃から Kubernetes アプリを保護し、高度なシグネチャと脅威保護、ボット防御、個人識別情報 (PII) の悪用に対する Dataguard 保護を提供します。 NGINX App Protect DoS は、レイヤー 4 と 7で追加の防御ラインを提供し、ユーザー行動分析とアプリのヘルス チェックによって高度なアプリケーション レイヤー DoS 攻撃を軽減し、Slow POST 、Slowloris、フラッド攻撃、Challenger Collapsar などの攻撃から保護します。

このようなセキュリティ対策により、REST API と Web ブラウザを使用してアクセスされるアプリケーションの両方が保護されます。 API セキュリティは、North-South トラフィック フローに従って Ingress レベルでも適用されます。

NGINX App Protect WAF および DoS を備えた NGINX Ingress Controller は、サービスごとではなくリクエストごとに Amazon EKS トラフィックを保護できます。これは、レイヤー 7 トラフィックのより便利なビューであり、SLA と north-South 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は、各WAFが100%成功時に達成した最高スループットを示しています（ 5xxまたは429各リクエストのレイテンシが 30 ミリ秒未満で、エラーが 1 件も発生しません。 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 やアプリケーション所有者から独立して動作することを反映するために、設計上別々になっています。 app-protect-security-log-destinationアノテーションのパラメータを syslog ポッドのクラスター IP アドレスに設定することで、Kubernetes ポッドから到達可能な任意の syslog 宛先に NGINX App Protect ログを送信できます。 さらに、 APLogConfリソースを使用して、重要な NGINX App Protect ログを指定し、暗黙的にどのログを syslog ポッドにプッシュするかを指定することもできます。 NGINX Ingress Controller のログは、すべての Kubernetes コンテナと同様に、ローカルの標準出力に転送されます。

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

apiバージョン: appprotect.f5.com/v1beta1 種類: APLogConf 
メタデータ: 
名前: logconf 
名前空間: dvwa 
仕様: 
コンテンツ: 
フォーマット: デフォルト 
max_message_size: 64k 
max_request_size: 任意 
フィルター: 
request_type: すべて

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

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

apiバージョン: appprotect.f5.com/v1beta1 種類: APPolicy 
メタデータ: 
名前: sample-policy
仕様: 
ポリシー: 
名前: sample-policy 
テンプレート: 
名前: POLICY_TEMPLATE_NGINX_BASE 
applicationLanguage: utf-8 
enhancementMode: ブロッキング 
signature-sets: 
- 名前: コマンド実行シグネチャ 
アラーム: true 
ブロック: true
[...]

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

apiバージョン: appprotect.f5.com/v1beta1 種類: APLogConf 
メタデータ: 
名前: log-violations
仕様: 
コンテンツ: 
フォーマット: デフォルト 
max_message_size: 64k 
max_request_size: 任意 
フィルター: 
request_type: 不正

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

apiバージョン: k8s.nginx.org/v1 種類: ポリシー 
メタデータ: 
名前: waf-policy 
仕様: 
waf: 
有効化: true 
apPolicy: "default/sample-policy" 
securityLog: 
有効化: true 
apLogConf: "default/log-violations" 
logDest: "syslog:server=10.105.238.128:5144"

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

apiバージョン: k8s.nginx.org/v1kind: VirtualServer
メタデータ:
名前: eshop-vs
仕様:
ホスト: eshop.lab.local
ポリシー:
-名前: default/waf-policy
アップストリーム:
-名前: eshop-upstream
サービス: eshop-service
ポート: 80
ルート:
- パス: /
アクション:
パス: eshop-upstream

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

結論

長年にわたりレガシーアプリとセキュリティソリューションを構築してきた企業にとって、Amazon EKS でのセキュリティの移行は段階的なプロセスになる可能性があります。 しかし、セキュリティを、セキュリティ チームによって管理および保守され、DevOps によって使用されるコードとして再構成すると、サービスをより迅速に提供し、本番環境に対応できるようになります。

Amazon EKS の North-South トラフィックを保護するには、レイヤー 7 でのポイント攻撃から保護するために NGINX App Protect WAF が組み込まれた NGINX Ingress Controller と、レイヤー 4 および 7での DoS 緩和のために NGINX App Protect DoS を活用できます。

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

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 アプリケーション ファイアウォール テストレポートをダウンロードし、12 月 6 日のウェビナーに登録して、GigaOm アナリストの Jake Dolezal が結果をレビューしてください。