ブログに戻る

フォロー&ご登録

英語のみで利用可能

このページは現在英語でのみ閲覧可能です。ご不便をおかけして申し訳ございませんが、しばらくしてからこのページに戻ってください。

組織のニーズに合わせて NGWAF を設計

Brooks Cunningham

Senior Security Strategist, Fastly

Travis Sanders

Principal Global Architect, Fastly

セキュリティ DevOps エンジニアリング

5年連続で業界から高い評価を得ている</u> Fastly の Next-Gen WAF (NGWAF) は、あらゆる種類の環境や組織にデプロイできます。セキュリティ対策に真剣に取り組んでいる組織が Fastly の NGWAF を選ぶ理由には、独自の Smartparse 機能</u>があります。この機能により、サービスに影響を及ぼすことなく、業界をリードするソリューションで攻撃からシステムを保護することができます。しかし同様に重要な点は、開発者が自社の組織構造に合わせて設計された既存の統合プラットフォーム上で作業が行えるよう、柔軟性の高いデプロイパターンを提供することです。

組織のニーズに合った方法で NGWAF をデプロイできる柔軟性は、これらのミッションクリティカルなアプリケーションを保護する上で欠かせません。Next-Gen WAF は、Kubernetes</u>、サーバーレス環境</u>、Fastly のエッジ</u>を含む、さまざまなテクノロジー</u>と簡単に統合することが可能です。Fastly は、お客様のアプリケーションを保護するのに特定のアーキテクチャを必要としないため、お客様の組織にとって最適なタイプのアーキテクチャを選べます。

このブログでは、NGWAF で Site</u> を Corp</u> 内にセットアップする際に利用可能なオプションをいくつか取り上げます。具体的には、Corp や Site を管理する設計パターンを紹介します。 

ちなみに、Fastly の NextGenWAF は、ほとんどチューニングや設定なしでお客様のアプリケーションの安全性を維持できるという点において、非常に独特です。例を紹介する前に、Fastly の NextGen WAF の仕組みにおいて見過ごされがちなメカニズムについて触れておきたいと思います。それは、この WAF によってお客様のアプリケーションに紐づけられる設定は HTTP ホストヘッダーに基づいていないということです。つまり、多くのさまざまなアプリケーションをグループ化して単一の NGWAF Site の設定に紐づけることができます。この柔軟性により、セキュリティ担当者は、グループ化されたアプリケーションのセキュリティ体制の管理や、設定管理に必要なオーバーヘッドの縮小、そして最終的に WAF の実装・管理コストの削減を実現できます。例えば、従来型の WAF では、数十個 (または数百個) の WAF インスタンスの設定を個別に管理する必要がありました。Fastly の NGWAF では、そのような負担からセキュリティチームを解放できます。

それでは、実際によく使われているデプロイオプションを見てみましょう。

パターン 1 : Corp 内に単一の Site をセットアップする

このセットアップは、Fastly の新規のお客様が採用することの多いデプロイパターンです。NGWAF のユーザーは、単一 Site を使用することで、一元的にすべての NGWAF の設定を管理することができます。オフィスの IP アドレスやテスト用の HTTP ヘッダーなどの条件を NGWAF のリクエストルールに追加して、テスト用にルールを設定することも可能です。このようにルールを設定することで、テスト基準と一致するトラフィックに対してのみ、NGWAF のリクエストルールで設定されたアクションが適用されます。

考えられるメリット :

  • すべてのトラフィックに対する簡単な一括設定

  • Site のカスタマイズ可能なダッシュボードを通じてすべてのトラフィックを可視化

  • 開発、ステージング、本番のすべての環境で同じ設定を適用してバージョン間のずれを回避

  • 管理に必要な人手を最小化

考えられるデメリット :

パターン2 : アプリケーションごとに異なる Site をセットアップする

機能ごとにアプリケーションをバンドルしてセグメント化された NGWAF Site をセットアップしているお客様をよく見かけます。このパターンでは、個々の Site に特定の設定が適用され、そのアプリケーショングループに対してのみ影響します。他のグループのアプリケーション用の NGWAF Site には影響しません。これは、開発段階とは無関係に同じ設定をアプリケーションに対して維持するひとつの方法です。これにより、開発者は本番環境に移行する前に問題を特定しやすくなります。また、ミッションクリティカルなアプリケーションをセグメント化して特定の NGWAF Site をセットアップすると同時に、一般的な広範囲にわたる WAF による保護を必要とする個々の社内アプリケーションの多くをまとめて別の NGWAF Site をセットアップすることも可能です。この場合、ミッションクリティカルなアプリケーションの WAF 設定と、社内アプリケーションの WAF 設定が互いに干渉することはありません。 

考えられるメリット :

  • レート制限ルールの総数の拡大など、アプリケーション固有の設定が可能

  • 開発、ステージング、本番環境の間でバージョンのずれが生じるリスクを最小化

  • Site に関する広範囲の統計データを Corp Overview ページで確認

  • 開発者が NGWAF のコンソールで攻撃を確認し、積極的に保護対策に参加することが可能

  • 各サイトごとにロールが割り当てられているので、それぞれのアプリケーションの責任者が互いに影響を与えるリスクを回避

考えられるデメリット :

  • 似たような機能を持つアプリケーションが独立して管理される (Corp ルールを除く)

  • 各アプリケーションに対する可視性を得るには、個々の Site を確認する必要がある

パターン3 : アプリケーションのライフサイクル段階ごとに Site をセットアップする

アジャイルエンジニアリングでも、開発、ステージング、本番環境と同様のものが存在し、(問題がない限り) これらの段階を通じてデプロイが推奨されます。Fastly NGWAF は、このタイプのセットアップにも対応し、個々のアプリケーションに対して独自の NGWAF Site を各開発段階でセットアップすることができます。

考えられるメリット :

  • 開発環境から、ステージング、本番環境へと設定を移行できる

  • 似たような機能を持つアプリケーションをグループ化し、各 Site で同じルールを再度実装する手間を最小化できる

  • 開発者が NGWAF のコンソールで攻撃を確認し、積極的に保護対策に参加することが可能

考えられるデメリット :

  • このデザインでは、各サイト間で設定のずれが生じやすい

  • 多くの個々のアプリケーションに対して、多くの個々の NGWAF の Site が作成されるため、コンソールで可視性を得ることがより困難になる

各パターンの例

単一の開発チームの場合 (パターン1)

セキュリティツールに多くの時間を費やすことなく攻撃トラフィックからの保護を求めるお客様は、単一の Site を使用することをお勧めします。同一の Site でセキュリティ設定と可視性を管理することで、メリットが得られます。例えば調整が必要な場合、単一の Site で変更を一度実行するだけで済みます。

単一のセキュリティチームのみで、開発チームがアプリケーションセキュリティに関わらない場合 (パターン2)

通常、専門のセキュリティチームがアプリケーションセキュリティを管理している場合、NGWAF Site を機能ごとにグループ化できます。例えば、顧客のオンラインストアを運営する eコマースプラットフォームの場合、すべての顧客のストアサイトをグループ化して単一の NGWAF Site でセキュリティを管理することができます。こうすることで、「eコマースプラットフォームの顧客サイト」という機能グループに特定の設定を適用する必要がある場合、作業が非常に楽になります。同様に、eコマースプラットフォームのその他のアプリケーションをグループ化して別の NGWAF Site で管理できます。この例では、マネージドセキュリティサービスのプロバイダーが「セキュリティチーム」の役割を担い、顧客とより直接的に連携させることも可能です。

社内アプリケーションにおいては、開発チームとセキュリティチームとの間で、取り決めを定義することが重要です。これは開発、ステージング、本番のすべての段階で同じ NGWAF Site を使用してセキュリティを管理する場合、開発者は特定の調整が必要なときに、どのようにセキュリティチームに懸念を報告すべきか理解している必要があるためです。

多くのアプリケーションチームを抱える規模の大きな企業の場合 (パターン3)

特定のアプリケーションを運用し、それらのセキュリティに対して責任を持つ複数の独立したアプリケーションチームが存在する場合、それぞれ独自の NGWAF Site を使用してアプリケーションのセキュリティを管理することが望ましいです。これにより、チームは管轄のアプリケーションに関する知識を最大限に高め、そのアプリケーションのセキュリティ設定を適切に管理することが可能になります。このモデルは、複数の子会社や多くの開発チームを擁する大規模な組織や企業に最適です。また、アジャイル開発チームも3つ目のパターンを好むかもしれません。一方、複数のアプリケーションを通じて一貫した設定を適用したい組織にとっては、2つ目のパターンが望ましい場合もあるでしょう。

まとめ

この記事で取り上げた3つの異なるデプロイパターンは、今日、使用されている実際のデプロイ方法のほんの一例です。お客様のニーズや組織の構造に合わせて、異なるオプションを組み合わせたハイブリッドなアプローチを採用しているお客様も数多くいらっしゃいます。ただし一般的には、シンプルなデプロイオプションから始めて、後でより複雑なオプションへと移行することをお勧めします。 

NGWAF から Fastly エッジまで、セキュリティ設定の管理においてよりシンプルなアプローチをお求めのお客様は、Fastly のマネージドセキュリティサービス</u>もぜひご検討ください。 

私たちは、最も急を要するセキュリティ課題をお客様が克服できるよう、常にサポートします。私たちにできることがあれば、いつでもご連絡ください</u>。

Fastly
© Fastly 2025