Kubernetes WAF とは？

Kubernetes WAF は、Kubernetes 環境で実行されるWeb アプリケーションと API を悪意のあるアプリケーションレイヤーのトラフィックから保護するために使用されるWeb アプリケーションファイアウォールです。これは Kubernetes セキュリティの重要な一部です。

Kubernetes を使用すると、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理が容易になりますが、SQL インジェクション、クロスサイト・スクリプティング（XSS）、コマンド・インジェクション、悪意のあるボット、その他の Web 攻撃などの脅威からそれらのアプリケーションを自動的に保護するわけではありません。WAF は、HTTP および HTTPS リクエストを分析するアプリケーション・セキュリティ・レイヤーを追加し、保護されたワークロードに到達する前に悪意のあるアクティビティを検出、ブロック、またはログに記録できます。

アーキテクチャによっては、WAF はネットワークエッジ、Kubernetes イングレスインフラストラクチャと並行する場所、または Kubernetes 環境自体の内部で動作できます。適切なアプローチは、組織のアプリケーション、トラフィックアーキテクチャ、パフォーマンス要件、セキュリティモデルによって異なります。

Kubernetes WAF はどのように機能しますか？

Kubernetes WAF は、Kubernetes にデプロイされたアプリケーションと API を保護する WAF です。従来の WAF は、ユーザーと Web アプリケーションの間に配置され、悪意のあるアクティビティがないか受信リクエストを分析します。同じ原則が Kubernetes にも当てはまりますが、WAF の背後にある環境は、動的に変化およびスケールする多数のコンテナ、ポッド、サービス、API、マイクロサービスで構成される場合があります。

Kubernetes アプリケーションには、次のようなリクエストパスがある場合があります。

ユーザー - CDN/エッジ - WAF - Kubernetes ingress または gateway - Service - Pod

WAF の正確な配置位置はさまざまです。一部の組織では、Kubernetes クラスタ内にセキュリティソフトウェアをデプロイしています。他の組織では、クラウドまたはエッジ WAF を使用して、トラフィックがクラスタに到達する前に検査しています。ハイブリッド・アプローチでは、複数の適用ポイントを使用できます。

目的は同じです。悪意のあるアプリケーションのトラフィックが Kubernetes ワークロードを悪用または妨害する前に、それを特定して阻止することです。

Kubernetes WAF の処理フロー
Kubernetes WAF は、アプリケーションレイヤーのリクエストを検査し、それらが保護されたワークロードに到達する前にセキュリティ・ロジックを適用します。

一般的なリクエストは、次の手順に従う場合があります：

ユーザーまたはクライアントが HTTP リクエストを送信します。そのリクエストは、Kubernetes 上で実行されている Webサイト、API、またはその他のインターネット向けサービス宛てである可能性があります。
WAF はリクエストを検査します。デプロイによっては、これはエッジまたは Kubernetes ワークロードにより近い場所で発生する可能性があります。
WAF はアプリケーションレイヤーの情報を分析します。URL、パラメータ、ヘッダー、Cookie、リクエストボディ、API ペイロードなどの要素を検査できます。
セキュリティルールと検出メカニズムがトラフィックを評価します。システムは、そのリクエストが正当なもの、不審なもの、または悪意のあるものに見えるかどうかを判断します。
アクションが実行されます。WAFは、リクエストを許可、ブロック、ログ記録、または設定された別のレスポンスを適用できます。
許可されたトラフィックは Kubernetes に引き続き送られます。その後、リクエストは適切なロードバランサー、ingress controller、または gateway を通過して Kubernetes サービスに到達し、最終的に関連する pod に送られます。

最新の WAF は、攻撃シグネチャを、振る舞い分析、脅威インテリジェンス、レート制限、ボット検知、またはその他のセキュリティシグナルで補完する場合があります。

Kubernetes 環境に WAF が必要なのはなぜですか？

Kubernetes は重要なインフラストラクチャとオーケストレーション機能を提供しますが、アプリケーションレイヤーのセキュリティに取って代わるものではありません。Kubernetes 環境で WAF が必要な理由は次のとおりです。

Kubernetes アプリケーションも依然として Web アプリケーションです。
アプリケーションをコンテナに移行しても、コード内の脆弱性がなくなるわけではありません。Kubernetes でホストされるアプリケーションも、SQL インジェクション、XSS、コマンドインジェクション、パストラバーサル、認証攻撃、API の悪用、その他の Web 脅威にさらされる可能性があります。

Kubernetes は分散アーキテクチャを推奨しています
Kubernetes はマイクロサービスや API 駆動型アプリケーションで一般的に使用されています。これにより、異なる機能、データアクセス要件、リスクプロファイルを持つ多数のアプリケーションエンドポイントが作成される可能性があります。その結果、APIは攻撃対象領域の重要な一部になります。

Kubernetes 環境は急速に変化します
Pod は自動的に作成、破棄、再スケジュールされる可能性があります。アプリケーションは、CI/CD パイプラインを通じて、1日に複数回更新される場合もあります。セキュリティアーキテクチャは、静的なインフラストラクチャの前提に依存するのではなく、この動的なモデルに対応する必要があります。

インターネットに公開されたワークロードは、継続的に標的にされています
公開アプリケーションと API は、バックエンドが Kubernetes、仮想マシン、または物理サーバー上で実行されているかどうかに関係なく、脆弱性スキャン、エクスプロイトの試行、認証情報への攻撃、悪意のあるボット、DDoS 攻撃トラフィックを受ける可能性があります。

WAF がどのように役立つか
Kubernetes のセキュリティには、いくつかの異なる懸念事項が含まれます。クラスタ設定、シークレット管理、ネットワークポリシー、ID とアクセス管理、コンテナ・セキュリティ、イメージスキャン、ランタイム・セキュリティ、WAF 保護は、それぞれ異なる問題を解決します。

WAFは、特にアプリケーションレイヤーの保護に役立ちます。これは、Kubernetesプラットフォーム自体の保護に代わるものとして扱うべきではありません。

Kubernetes WAF はどのような脅威からの保護に役立ちますか？

WAFによっては、アプリケーションレイヤーの保護で、次のような攻撃に対処できます：

SQL インジェクション
クロスサイトスクリプティング
コマンドインジェクション
パストラバーサル
悪意のある HTTP リクエスト
既知の脆弱性の悪用
API 攻撃
アプリケーションのスキャンとプロービング

補完的なテクノロジーと統合することで、組織は悪意のあるボット、認証情報への攻撃、スクレイピング、アプリケーションレイヤー DDoS 攻撃、およびその他の自動化された不正使用にも対処できます。

OWASP トップ10は、Web アプリケーションセキュリティリスクの主要なカテゴリを理解するための有用な参考資料です。ただし、一部の脆弱性にはアプリケーションの設計、認可、設定、またはビジネスロジックが関係しており、アプリケーション自体で修正する必要があるため、WAF によってすべての OWASP リスクを排除できると期待すべきではありません。

Kubernetes で WAF をデプロイするためのベストプラクティスとは？

WAF は、より広範な Kubernetes およびアプリケーション・セキュリティ戦略の一部を構成する場合に最も効果を発揮します。

1. 可能であれば、トラフィックがクラスタに到達する前にアプリケーションを保護する
エッジにデプロイされた WAF は、悪意のあるリクエストが Kubernetes のネットワーク、ingress、コンピューティング、アプリケーションのリソースを消費する前に識別できます。アップストリームで不要なトラフィックを削減することで、セキュリティとインフラストラクチャ効率の両方を向上させることができます。

2. Webページだけでなく API も保護する
Kubernetes 環境では、API 主導のマイクロサービスが頻繁にホストされます。外部からアクセス可能な API を把握し、従来のブラウザトラフィックだけを保護するのではなく、セキュリティポリシーが API エンドポイントを考慮していることを確認します。

3. オリジンへの直接アクセスを制限する
アプリケーションがエッジセキュリティレイヤーを介してインターネットトラフィックを受信することになっている場合、攻撃者が公開されたオリジンに直接接続するだけでそのレイヤーをバイパスできてはなりません。アーキテクチャで許可される場合は、オリジンへのアクセスを認可されたトラフィックパスに制限してください。

4. CI/CD にセキュリティを統合する
Kubernetes のデプロイは多くの場合自動化されているため、セキュリティも同じ運用モデルに適合する必要があります。コードとしてのインフラストラクチャ、バージョン管理されたポリシー、自動化されたセキュリティテスト、および反復可能なデプロイにより、設定のドリフトを減らすことができます。

5. 可視性から始める
トラフィックを積極的にブロックする前に、WAF が何を検出しているのかを把握します。監視モードまたはログモードは、新しいルールを適用する前に、チームが潜在的な誤検知を評価し、通常のアプリケーション動作を理解するのに役立ちます。

6. セキュリティポリシーを管理しやすく保つ
ルールを増やしても、必ずしもセキュリティが向上するとは限りません。過度に複雑なポリシーは、保守が難しくなり、誤検知を引き起こす可能性があります。価値の高い保護を優先し、古くなった例外を定期的に見直してください。

7. WAF とボット対策を組み合わせる
見た目は有効な HTTP リクエストでも、何千回も自動化されると悪意のあるものになる可能性があります。Bot Management は、クレデンシャルスタッフィング、スキャン、スクレイピング、アプリケーションの悪用などのアクティビティに関与する悪意のある自動化を特定することで、WAF を補完できます。

8. DDoS 攻撃から保護する
WAF は、サービス拒否攻撃に対する唯一の防御策であるべきではありません。適切なネットワークおよびアプリケーションレイヤーのDDoS Protectionを使用することで、Kubernetesまたはアプリケーションのリソースを使い果たす前に、攻撃トラフィックを軽減できます。

9. セキュリティイベントを一元的に監視する
必要に応じて、WAF のセキュリティテレメトリをロギング、SIEM、オブザーバビリティプラットフォームと統合します。開発、オペレーション、セキュリティチームは、個々のポッド間で情報を手動で関連付けることなく、攻撃を調査できる必要があります。

10. アプリケーションの脆弱性を修正する
WAF は重要な防御レイヤーを追加しますが、セキュアな開発に取って代わるものではありません。依存関係へのパッチ適用、アプリケーションのテスト、安全でない設定の修正、強力な認可の実装、脆弱なコードの修正を継続してください。

WAF は Kubernetes の内部と外部のどちらで実行すべきですか？

どちらのアプローチも可能です。

Kubernetes 内の WAF
WAF またはセキュリティコンポーネントは、Kubernetes 環境内またはその近くで動作し、イングレスインフラストラクチャまたはアプリケーションサービスと統合する可能性があります。このアプローチにより、組織は個々のワークロードに近い場所でデプロイの柔軟性とセキュリティコントロールを得られる場合があります。

ただし、クラスタ内のセキュリティ・インフラストラクチャはクラスタのリソースを消費する可能性があり、攻撃トラフィックに合わせてスケールする必要がある場合があります。

Kubernetesの外部のWAF
外部またはエッジのWAFは、リクエストがKubernetesに到達する前にそれを検査します。これにより、悪意のあるリクエストがクラスタ内のイングレス、ネットワーキング、コンピュート、アプリケーション・リソースを消費するのを防ぐことができます。また、保護対象のインフラストラクチャからセキュリティ適用レイヤーを分離します。

ハイブリッド・デプロイ
一部の組織では、エッジセキュリティとワークロードにより近い場所のコントロールを組み合わせています。適切なモデルは、組織のアーキテクチャ、コンプライアンス要件、運用プラクティス、アプリケーション、および脅威モデルによって異なります。

Kubernetes WAF が必要なのは誰ですか？

組織は、Kubernetes 環境でインターネット向けの Web アプリケーションまたは API をホストしている場合、WAF 保護を検討する必要があります。

SaaS プロバイダー
SaaS アプリケーションでは、攻撃者が標的にできるログインシステム、API、ダッシュボード、顧客向け機能が一般的に公開されています。

eコマース企業
Kubernetes でホストされるオンラインストア、チェックアウトシステム、検索機能、API は、インジェクションの試み、悪意のあるボット、アカウント攻撃、DDoS 脅威に直面する可能性があります。

ファイナンスサービス
金融情報や取引を扱うアプリケーションは、強力な認証、認可、暗号化、セキュアな開発に加えて、多層的なアプリケーションセキュリティのメリットを得られます。

メディア企業および出版企業
トラフィックの多いコンテンツ・プラットフォームは、脆弱性スキャン、スクレイピング、自動化された不正利用、突然のトラフィックスパイクに直面する可能性があります。

API ファーストの企業
多数の公開 API を運用する組織には、従来のネットワークセキュリティだけに依存せずにアプリケーションエンドポイントを保護できるコントロールが必要です。

マイクロサービスを導入するエンタープライズ
組織がモノリシックなアプリケーションを分散サービスに分割するにつれて、API とアプリケーションインターフェースの数が大幅に増加する可能性があります。WAF は、それらのアプリケーションが信頼できないトラフィックにさらされる場所で、追加のセキュリティレイヤーを提供できます。

Kubernetes セキュリティはアプリケーションセキュリティと同じですか？

いいえ。Kubernetesセキュリティには、次の領域を含む基盤となるコンテナ・オーケストレーション環境が含まれます。

クラスタアクセス
RBAC
Secrets
ネットワークポリシー
コンテナイメージ
Pod セキュリティ
ノードセキュリティ
ランタイム・セキュリティ
サプライチェーン・セキュリティ

アプリケーションセキュリティは、そのインフラストラクチャ上で実行されるソフトウェア（コード、API、認証、認可、ユーザー入力の処理を含む）に焦点を当てています。WAF は主にアプリケーションレイヤーの脅威に対処します。したがって、Kubernetes を実行している組織は、プラットフォームとその上で実行されるアプリケーションの両方を保護する必要があります。

Kubernetes WAF だけで API を保護するのに十分ですか？

短い答えは、いいえです。WAF は重要なレイヤーの1つですが、包括的な API セキュリティには通常、追加のコントロールが必要です。

組織は、次の点も考慮する必要があります：

強力な認証と認可
API の検出とインベントリ
スキーマと入力検証
レート制限
ボット対策
DDoS 対策
安全な API 開発
ログとモニタリング
ビジネスロジックの悪用に対する適切な保護

目的は、従来のWebエクスプロイトと、正当なAPI機能を悪用する攻撃の両方を防ぐことです。

Fastly は Kubernetes 環境をどのように補完しますか？

Fastly は、主要なセキュリティ適用ポイントをすべての Kubernetes クラスタ内に配置しなくても、Kubernetes でホストされるアプリケーションを保護できます。一般的なアーキテクチャでは、Kubernetes でホストされるアプリケーションの前段に Fastly の Edge Cloud Platform を配置できます。

ユーザー - Fastly エッジ - Kubernetes インフラストラクチャ - アプリケーションワークロード

受信したアプリケーション・トラフィックは最初に Fastly に到達し、許可されたリクエストが Kubernetes 環境に進む前に、そこで配信／デリバリーとセキュリティのコントロールを適用できます。このアーキテクチャは、悪意のある、または不要なトラフィックを Kubernetes インフラストラクチャから遠ざけるのに役立つとともに、クラスタとアプリケーション環境全体で一貫したセキュリティレイヤーを提供できます。

Fastly Next-Gen WAF は Kubernetes とどのように連携しますか？

Fastly Next-Gen WAF は、Kubernetes でホストされている Web アプリケーションと API を保護できます。クラウド WAF の Fastly エッジでのデプロイや、アプリケーション・インフラストラクチャにより近い場所でのデプロイオプションなど、複数のデプロイモデルをサポートしています。これにより、組織はアプリケーション・セキュリティ検査をどこで実施するかを柔軟に決定できます。

Fastly の WAF は SmartParse テクノロジーを使用してリクエストパラメータを分析し、悪意のあるアプリケーションの動作を特定します。従来の正規表現ベースのルールだけに依存するのではなく、SmartParse はリクエストの背後にある意図を識別し、誤検知を減らすように設計されています。

Kubernetes アプリケーションでは、これは次のような攻撃クラスに対する保護を提供できます：

SQL インジェクション
クロスサイトスクリプティング
コマンドインジェクション
パストラバーサル
その他のアプリケーションレイヤー攻撃

エッジデプロイは、そもそも悪意のあるトラフィックが Kubernetes クラスタに到達する量を減らすことにも役立ちます。

Fastly は複数の Kubernetes クラスタを保護できますか？

はい。アプリケーションが複数のクラスタ、地域、またはインフラストラクチャプロバイダーにまたがる場合、エッジベースのセキュリティアーキテクチャが役立つことがあります。クラスタごとに完全に独立したインターネット向けセキュリティスタックを必要とする代わりに、トラフィックは適切なアプリケーションオリジンにルーティングされる前に Fastly を通過できます。

これは、次のような運用を行う組織にとって有用です：

複数の Kubernetes クラスタ
マルチ・地域・デプロイ
ハイブリッドクラウド・アプリケーション
マルチクラウド・アーキテクチャ
Kubernetes と Kubernetes 以外のインフラストラクチャ

正確な設定は、アプリケーションのネットワーク構成とオリジンアーキテクチャによって異なります。

Kubernetes WAF 保護を補完する、その他の Fastly セキュリティ機能にはどのようなものがありますか？

WAF による保護は、Fastly のより広範なアプリケーション・セキュリティ・ポートフォリオの一部です。

Fastly Bot Management
Fastly Bot Management は、自動化されたトラフィックの特定とコントロールに役立ちます。これは、脆弱性スキャン、認証情報攻撃、スクレイピング、アプリケーションの悪用に関与するボットに対する WAF 保護を補完できます。

DDoS Protection
DDoS Protection は、ネットワークまたはアプリケーションのリソースを圧倒するように設計された攻撃からアプリケーションを保護するのに役立ちます。エッジで攻撃を軽減することで、大量の不要なトラフィックがKubernetesインフラストラクチャに到達するのを防ぐことができます。

レート制限
レート制限は、機密性が高く計算コストのかかるアプリケーションエンドポイントの保護に役立ちます。Kubernetes アプリケーションでは、過剰なリクエストがバックエンドリソースを消費する可能性がある API、認証エンドポイント、検索機能、その他のサービスに対して、これは特に有用です。

CDN とキャッシュ
Fastly の CDN は、対象となるコンテンツをエッジでキャッシュできるため、Kubernetes ワークロードに到達する必要があるリクエストを削減できます。これにより、イングレス・コントローラー、サービス、ポッド、データベース、その他のオリジン・インフラストラクチャへの負荷を軽減しながら、アプリケーションのパフォーマンスを向上させることができます。

リアルタイムの可視性
Fastly は、セキュリティチームとオペレーションチームがトラフィックパターンを把握し、悪意のあるアクティビティを調査するのに役立つリアルタイムロギングとオブザーバビリティ機能を提供します。これは、トラフィックがクラスタに到達する前の可視性を提供することで、Kubernetes ネイティブのオブザーバビリティを補完できます。