F5のレポート「2022年版アプリケーション戦略の状況」によると、企業におけるデジタルトランスフォーメーションは、世界的に加速し続けています。ほとんどの企業は、200～1,000のアプリを複数のクラウドゾーンにまたがって導入し、今日のアプリケーションはモノリシックから最新の分散アーキテクチャに移行しています。
Kubernetesが技術部門のメインストリームで初めて使用されるようになったのは、わずか6年前の2016年からです。しかし現在では、2019年から30%の増加となる、世界の75%以上の組織が、コンテナ化されたアプリケーションを実稼働環境で稼働させています。Amazon Elastic Kubernetes Service（EKS）など、Kubernetes環境で重要視されている課題の１つはセキュリティです。セキュリティは、多くの場合、アプリ開発プロセスの最後に「ボルトオン」され、場合によっては、コンテナ化されたアプリケーションがすでに稼働している後でも対策されないこともあります。
新型コロナウイルス感染症によるパンデミックによって加速した現在のデジタルトランスフォーメーションの波により、多くの企業は、セキュリティに対してより全体的なアプローチを取り、「シフトレフト」戦略を検討することを余儀なくされています。セキュリティのシフトレフトとは、ソフトウェア開発ライフサイクル（SDLC）の早い段階でセキュリティ対策を行い、アプリケーション、コンテナ、マイクロサービスおよびAPIのCI/CDパイプラインのあらゆる段階でセキュリティツールおよびコントロールを使用することです。これは、セキュリティをDevOpsプロセスに組み込み、最新ソフトウェアアプリ開発と配信で一般的な高速リリースサイクルに統合する、DevSecOpsと呼ばれる新しいパラダイムへの移行を意味します。
DevSecOpsは、重要な文化的変化をもたらします。セキュリティチームとDevOpsチームは、高品質な製品を迅速かつ安全に市場投入するという共通の目的を持って協力します。開発者は、ワークフローを停止させるようなセキュリティ手順に悩まされることがなくなり、セキュリティチームは、同じ問題を繰り返し修正する必要がなくなります。これにより、脆弱性、設定ミス、コンプライアンス違反やポリシー違反が発生したときに、それを発見および防止することで、組織は強固なセキュリティ体制を維持できます。
セキュリティをシフトレフトし、コードとして自動化することで、Amazon EKS環境を最初から保護できます。大規模に実稼働環境の準備をする方法を学ぶことは、Kubernetes基盤を構築する上で大きな役割を果たします。Amazon EKS上でのガバナンスの強化は、ビジネス全体の効率性、透明性および説明責任を推進すると同時に、コストの抑制に役立ちます。強力なガバナンスとセキュリティガードレールにより、クラスタの可視化と制御を強化するフレームワークを作成できます。逆にこれがないと、セキュリティ侵害のリスクが高まり、それに関連する収益や評判への損害に伴うロングテールコストが発生する可能性も高まります。
セキュリティファーストの戦略に移行するときに考慮すべき点については、O’Reillyの最新レポート「Shifting Left for Application Security」をご覧ください。
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およびDoSモジュールをNGINX Ingress Controllerに組み込むことです。他では、このようなインラインソリューションをまとめて提供していません。同期化された技術で1つの製品を使用することで、計算時間の短縮、コストの削減、ツールの無秩序な増加の解消など、いくつかの利点を得ることができます。また、以下のような利点もあります。
- アプリケーション境界の保護 – 適切に設計されたKubernetes導入では、NGINX Ingress Controllerは、Kubernetes内で実行されるサービスに送られるデータプレーントラフィックの唯一のエントリポイントであり、WAFおよびDoS保護のための理想的な場所となります。
- データプレーンの統合 – WAFをNGINX Ingress Controller内に組み込むことで、個別の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は、OWASPトップ10攻撃からKubernetesアプリを保護し、高度なシグネチャと脅威保護、ボット防御、および個人識別情報（PII）の搾取に対するDataGuard保護を提供します。NGINX App Protect DoSは、レイヤー4と7で追加の防御ラインを提供し、ユーザーの行動分析とアプリの健全性チェックにより、高度なアプリケーション層DoS攻撃を軽減し、Slow POST、Slowloris、フラッド攻撃、Challenger Collapsarなどの攻撃から保護します。
このようなセキュリティ対策は、WebブラウザからアクセスされるREST APIとアプリケーションの両方を保護します。
APIセキュリティは、North-Southトラフィックフローに従いIngressレベルでも実施されます。NGINX App Protect WAFおよびDoSが組み込まれたNGINX Ingress Controllerは、サービスごとではなく、リクエストごとにAmazon EKSトラフィックを保護できます。これは、レイヤー7トラフィックのより有益なビューを提供し、SLAとNorth-South WAFセキュリティを実施するはるかに優れた方法です。
GigaOmの最新レポート「High‑Performance Web Application Firewall Testing」では、NGINX App Protect WAFが高性能と低遅延を維持しながら、アプリとAPIの強力なセキュリティを提供し、テストしたすべての攻撃率において他の3つのWAF（AWS WAF、Azure WAF、Cloudflare WAF）を上回ったことが紹介されています。
たとえば、図4は、WAFが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ミリ秒未満で達成した最高のスループットを示しています。NGINX App Protect WAFの処理スループットは19,000 RPSでしたが、Cloudflare WAFは14,000 RPS、AWS WAFは6,000 RPS、Azure WAFはわずか2,000 RPSでした。
NGINX App ProtectとNGINX Ingress ControllerをAmazon EKSに導入する方法
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が他のプロセスのリソースを浪費しないようにできます。これは、リソースの共有に依存し、潜在的に”noisy neighbor”問題に悩まされる可能性があるKubernetesなどのマルチテナント環境において、特に重要なことです。
NGINX CRDを使用したログの設定
NGINX App ProtectとNGINX Ingress Controllerのログは、セキュリティチームが通常DevOpsおよびアプリケーション所有者とは独立して行動することを反映して、設計上別々になっています。app-protect-security-log-destinationアノテーションのパラメータをsyslog PodのクラスタIPアドレスに設定することで、Kubernetes Podから到達可能な任意のsyslogを宛先としてNGINX App Protectログを送信できます。さらに、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: allNGINX CRDを使ったWAFポリシーの定義
APPolicy Policyオブジェクトは、宣言型アプローチに基づいてシグネチャセットとセキュリティ規則で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クラスタに適用されたら、log-violationsというAPLogConfオブジェクトを作成して、リクエストがWAFポリシーに違反したときにログに書き込まれるエントリーのタイプと形式を定義します。
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: illegalwaf-policy Policyオブジェクトは、NGINX App Protect WAFのsample-policyを参照して、アプリケーションがNGINX Ingress Controllerにより公開されるときの受信トラフィックにこのポリシーを適用します。また、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"Amazon EKSにアプリケーションを公開するようにNGINX Ingress Controllerを設定するVirtualServerオブジェクトがDevOpsにより公開されると、導入が完了します。
apiVersion: k8s.nginx.org/v1
kind: 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-upstreamVirtualServerオブジェクトは、Amazon EKS上で稼働するコンテナ化されたアプリを簡単に公開および保護するだけでなく、SecOpsがセキュリティポリシーの包括的なカタログを提供し、DevOpsがそれに依存してセキュリティをDay1からシフトレフトするという責任共有モデルに対応します。これにより、組織はDevSecOps戦略へと移行できます。
まとめ
長年構築されてきたレガシーアプリとセキュリティソリューションを使用している企業にとって、Amazon EKSでセキュリティをシフトレフトすることは、おそらく段階的なプロセスとなります。しかし、セキュリティチームが管理および保守し、DevOpsが利用するSecurity as Codeを見直すことで、サービスを迅速に提供し、実稼働環境に対応させることができます。
Amazon EKSのNorth-Southトラフィックを保護するには、レイヤー7でのポイント攻撃から保護するNGINX App Protect WAF、およびレイヤー4とレイヤー7でのDoSを緩和するNGINX App Protect DoSを組み込んだNGINX Ingress Controllerを活用できます。
NGINX App Protect WAFが組み込まれたNGINX Ingress Controllerに興味がある方は、AWS Marketplaceで30日間の無料トライアルを開始するか、具体的なユースケースについてご相談ください。
Amazon EKSでNGINX Ingress ControllerとNGINX App Protect WAFおよびDoSを使用して大規模にセキュリティ侵害を防止し、Kubernetesアプリを保護する方法については、eBook「Add Security to Your Amazon EKS with F5 NGINX」をダウンロードしてご覧ください。
NGINX App Protect WAFがAWS、AzureおよびCloudflareのネイティブWAFよりどのように優れているかについて詳しくは、GigaOmのレポート「High-Performance Web Application Firewall Testing」をダウンロードして、GigaOmアナリスト、ジェイク・ドレザル（Jake Dolezal）氏が結果をレビューする12月6日のウェビナー（英語版）をご参照ください。
