re:Invent 2025: AWS Network FirewallのSuricataルール自動化パイプライン構築事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Automating Suricata rules for AWS network firewall (DEV206)
この動画では、AWS Network FirewallのためのSuricataルール自動化パイプラインの構築事例が紹介されています。Network Firewallはレイヤー3から7までのルール定義をサポートし、最大100ギガビット毎秒までスケール可能なAWSマネージドサービスです。Suricata互換のルール文字列は強力ですが、構文の特殊性から手動管理がボトルネックとなっていました。解決策として、CSVファイルから自動的にSuricataルールを生成するLambda関数、バージョン管理されたS3バケット、検証機能を組み合わせたイベント駆動型の自動化ソリューションを実装しました。これにより、Suricata専門家への依存を減らし、チーム全体が自信を持って貢献できる、反復可能でテスト可能なプロセスを実現し、数百から数千のルールを数分で更新・デプロイできるようになりました。サンプルコードも公開されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
AWS Network FirewallとSuricataルールの基礎：なぜ自動化が必要なのか
皆さん、こんにちは。DEV206、AWS Network FirewallのためのSuricataルールの自動化へようこそ。本日は、ネットワークファイアウォールルールを開発し、投入するための自動化パイプラインを構築した私の経験、なぜこれを構築したのか、そのアーキテクチャ、そして得られたメリットについて皆さんと共有できることを嬉しく思います。ですが、本題に入る前に、ちょっとお聞きしたいのですが、挙手をお願いします。Network Firewallや他の種類のファイアウォールデバイスに精通している方はどのくらいいらっしゃいますか？素晴らしいですね。では、そのまま手を挙げていてください。これらのファイアウォールデバイスの設定に責任を持っている方は？素晴らしい。そして最後の質問です。実際にNetwork Firewallに入れるSuricataルールを書いた経験がある方、または扱ったことがある方はどのくらいいらっしゃいますか？
素晴らしい。この会場には様々な経験レベルの方がいらっしゃることが分かって嬉しいです。もしかしたら私が今、Suricataという言葉を作ったと思われた方もいるかもしれませんが、ご心配なく。この20分間で、皆さんはNetwork FirewallとSuricataルールの詳細に精通することになります。最後の質問で手を挙げられた方は、 この猫に少し共感できるかもしれません。Suricataルールセットを更新しなければならないという考えに怯え、さらに難しいタスクである、これらのルールが実際に意図した通りに動作することを確認することに恐怖を感じているこの猫に。このセッションの終わりには、このプロセスをより簡単にするために使えるツールとインスピレーションを持ち帰っていただければと思います。
本日は、まずAWS Network Firewallの簡単な背景から始め、次にファイアウォールルールとSuricata、つまりこれらのネットワークファイアウォールルールの背後にあるルールエンジンについて見ていきます。その後、自動化ソリューションの設計について深く掘り下げ、最後にこのソリューションを実装することで得られるメリットについてお話しします。ソリューションに入る前に、本当に簡単にお話ししたいのですが、 世の中にたくさんのファイアウォールオプションがある中で、なぜNetwork Firewallなのか？私たちの最終目標は、AWSクラウド環境にファイアウォールを追加して、クラウド環境からのエグレス接続を許可する際の柔軟性とコントロールを強化することでした。そして、それを実現するために様々なオプションを検討していました。
AWSのマネージドファイアウォールサービスであるNetwork Firewallは、AWSサービスと直接統合されており、管理と運用が非常に簡単です。さらに、稼働時間と処理されたトラフィックで構成される価格モデルは、エフェメラルワークロードを検討していた私たちにとって非常に便利でした。AWS Network Firewallについていくつか簡単に説明すると、先ほど申し上げたように、多くのAWS統合を提供しており、 ログ記録のためのCloudWatchとS3、そして集中管理とガバナンスのためのAWS Firewall ManagerとSecurity Hubとの統合があります。 さらに、本日はレイヤー7のルールについてお話ししますが、Network Firewallはレイヤー3からレイヤー7までのルール定義をサポートしており、ディープパケットインスペクションやドメインフィルタリングの機能も含まれています。
他のAWSネットワーキングサービスと同様に、AWS Network Firewallには優れたスケーラビリティオプションがあり、アベイラビリティゾーンあたり最大100ギガビット毎秒までスケールアップできます。これにより、この1つのファイアウォールデバイスがサポートできるトラフィック量に関して、非常に大きな自由度が得られます。そして最後に、Network Firewallは いくつかのデプロイメントオプションで展開できます。ノースサウスは、クラウド環境とパブリックインターネット間を行き来するトラフィックを検査するために使用され、イーストウェストは、クラウド環境の2つの部分間を行き来するトラフィックを検査するために使用されます。
本日は、このサンプルアーキテクチャを見ていきます。私たちの環境では、Network Firewallがnorth-south inspection architectureにデプロイされています。これは、Network Firewallが私たちのクラウド環境内で発生するトラフィックを検査することを意味します。このケースでは、いくつかのサンプルワークロードVPCがパブリックインターネットに向かい、集中管理されたinspection VPCにデプロイされたNetwork Firewallを通過します。そこで集中管理されたコントロールを設定し、トラフィックのセグメンテーションを有効にすることができます。つまり、これが私たちのクラウド環境内でルールが存在する場所です。
では、これらのnetwork firewallルールを構成するすべてのコンポーネントを簡単に見ていきましょう。各Network Firewallデバイスにはfirewall policyがあり、このfirewall policyには2つの大きなカテゴリのルールグループが含まれています：statefulとstatelessです。Statelessルールグループは、トラフィックの方向や同じフロー内の関連パケットを考慮しません。
したがって、statelessルールグループに実装されるルールは、かなり粗いものになります。本日は、トラフィックの方向やそれらの関連パケットが関係してくるstatefulルールグループを見ていきます。
Statefulルールグループには、2種類あります。 AWS managed rule groupsがあり、これらはAWSによってお客様に代わって提供されるルールです。すぐに使用でき、事前に設定されているため、徹底的なセキュリティカバレッジとAWSマネージドソリューションの利便性と専門知識を組み合わせています。しかし、これらはお客様の環境、業界、またはビジネスニーズに特化したものではありません。したがって、AWS Network Firewallの全機能を最大限に活用するには、それらの特定の要件に対応できるcustomer managed rulesを含めることも推奨されます。
Customer managed rulesには、3種類あります。最初はstateful standard rulesです。これらは、UI、API、またはCloudFormationを介して定義されるルールで、お客様が入力を提供し、AWSがそれらの入力を基礎となるルールに変換します。同様に、domain list rulesでは、許可または拒否したいドメインまたはサブドメインのリスト、およびHTTPまたはHTTPSトラフィックを提供すると、再びAWSがロジックを処理します。つまり、これらのルールは両方とも非常に便利ですが、AWSがお客様の入力をそれらの最終的なルールに変換する変換ロジックをコントロールしていることを知っておくことが重要です。
基盤となるSuricata IPSシステムの完全な柔軟性とパワーを活用するためには、Suricata互換のルール文字列を環境に組み込むことも推奨されます。これらは、Suricataルールを基盤となるファイアウォールデバイスに直接提供するルールです。これらすべてを全体的な視点で見ると、いくつかお勧めしたいことがあります。まず、AWSマネージドルールグループを使用することは素晴らしい出発点です。セットアップが簡単で、優れたベースラインレベルのセキュリティコントロールを提供してくれますが、アクティブな脅威防御タイプのルールを実装する場合は、コストに注意してください。しかし、先ほど共有したように、Network Firewallから本当に最大限のパワーを引き出したい場合は、Suricata互換のルール文字列も検討しましょう。
Suricataルールの課題と自動化パイプラインの全体設計
ただし、Suricata互換のルール文字列を使い始めると、あなたが運転席に座ることになります。そのSuricataルール構文を提供する責任はあなたにあります。Suricata構文の1行で、送信元、宛先、そして設定しているルールのタイプに基づく追加のフィルターを指定して、完全なトラフィック決定を定義できます。しかし、重要なのは構文が重要だということです。小さなミスでさえ、ファイアウォールの動作を完全に変えてしまう可能性があります。
いくつか例を見てみましょう。まず、セカンドレベルドメインevil.comに向かうトラフィックをドロップすることを意図したルールがあります。しかし、書かれている方法では、実際にはweevil.comやnottheevil.comなどの他のドメインに向かうトラフィックにもマッチしてしまいます。非常に似たルールですが、少し異なります。ピリオドとdotprefixモディファイアを含むルールがあり、このルールはevil.comのすべてのサブドメインに向かうトラフィックにマッチしますが、サブドメインのないevil.comにはマッチしません。
同じ特定性の必要性は、ルールの順序を見るときにも存在します。この最初のルールのペアでは、alertルールがdropルールの前にあるため、実際にドロップが発生する前に、どのトラフィックがドロップされるかについてのログを取得できます。しかし、誤ってこれらのルールの順序を入れ替えてしまうと、dropルールがalertルールが発動する機会を得る前に実行されるため、実際にどのトラフィックがドロップされたかについての可視性がすべて失われてしまいます。
これらは些細な変更に見えるかもしれませんが、精度と再現性がいかに重要であるかを示しています。Suricataルールは非常に強力ですが、手動で管理することが大きなボトルネックを生み出すことが明らかになっています。Suricataルールは、構文を理解する性質上、しばしばSuricata構文とルールに関する内部要件の両方に精通した少数のSuricataエキスパートへの依存に頼ることになります。
それに加えて、AWS Network Firewallの実装は、汎用的なSuricataが提供する機能のサブセットとなっています。つまり、すでにお持ちのルールやインターネット上で見つけたルールのすべてが、Network Firewallと互換性があるわけではないということです。そして先ほど見たように、 構文は非常に特殊で、小さな構文ミスでさえも、Suricataルールを変更して修正するという作業を何度も繰り返すことになってしまいます。 その結果、ルールセットの維持が困難になり、AWS Network Firewallの全機能を活用することが難しくなり、組織のセキュリティ体制が最適とは言えない状態になってしまいます。
だからこそ、私たちは自動化を選択しました。Suricataルール生成を、専門家だけができるプロセスから、反復可能で、テスト可能で、スケーラブルで、チーム全体が自信を持って貢献できるものへと変革するためです。では、これらすべての問題に対して私たちは何をしたのでしょうか？Suricataルールのライフサイクルのビフォーアフターを簡単に見てみましょう。すべてのルールは、生の要件、つまりIP、ドメイン、ルールで達成したいビジネス成果から始まります。以前は、エンジニア、Suricataの専門家が、手動でそのルールを直接作成しなければなりませんでした。
これが自動化されたLambda関数に置き換わりました。 この関数は、正しい構文、適切な順序、適切な修飾子を自動的に生成し、これらのルールが全体で一貫性を保つことを保証します。さらに、Network Firewallにはネイティブなバージョン管理システムがないため、もし悪い変更をしてしまったことに気づいて、 Suricataルールセットをロールバックする必要がある場合、どこかにローカルコピーを保存していたか、SlackやEmailの検索が本当に得意であることを祈るしかありませんでした。なぜなら、Suricataはロールバックしてくれなかったからです。新しいソリューションでは、これがバージョン管理されたS3バケットに置き換わり、すべての入力と出力が 保存されるため、障害が発生した場合でも簡単にロールバックできるようになりました。
最後に、Suricataは、ルールをNetwork Firewallに直接アップロードしようとすると、時々エラーを起こすことがありましたが、これは2つ目のLambdaに置き換わり、自動的に検証を行い、 これらのルールをNetwork Firewallデバイスにアップロードする際のエラーをキャッチします。それでは、さっそく本題に入りましょう。パイプラインとは何か、そして私たちはこれらすべての問題に対して何をしたのか？こちらが概要です。プロセスはユーザーから始まり、ユーザーはCSVファイルをGitリポジトリにアップロードし、その後これらの入力ファイルがバージョン管理されたS3バケットにプッシュされます。
これらのファイルがS3に配置されると、ルール生成Lambdaが呼び出され、Suricata構文が作成されます。この出力は同じS3バケットに戻され、再び2つ目のLambdaが呼び出され、 これらのルールがNetwork Firewallデバイスにプッシュされます。全体として、EventBridgeとCloudWatch Logsがソリューション全体を監視しています。 本質的に、このパイプラインは、AWSマネージドソリューションの使いやすさと、カスタムSuricataルールを活用する精度と柔軟性を融合させています。その結果、より速い反復、より少ないエラー、そしてファイアウォールルールを管理するためのより一貫性があり透明性の高いアプローチが実現されます。
CSVベースのルール生成システムの実装と得られたメリット
それでは最初のステップは、これらのルールをシンプルな構造化フォーマットでキャプチャすることです。私たちの場合は、CSVファイルを選択しました。各行は1つの論理ステートメントを表し、プロトコル、ポート、望ましいアクション、ドメインなどを指定します。このアプローチにより、チームの誰もが専門的な構文を気にすることなく、簡単に変更を提案できるようになります。CSVがアップロードされると、Lambdaがこれらを適切にフォーマットされたSuricataルールに変換します。
Lambdaは、alert、dropなどの正しいSuricataキーワードの適用を処理し、VPC IDをそれらのCIDRブロックに変換します。これはSuricataルール内での要件となっています。ロギングが有効になっている場合はクリーンなメッセージングを適用し、基礎となるアクションルールの前にそのロギングルールが作成されることを保証します。このシンプルな例では、このソリューションの利点がどこから来るのかを理解するのは簡単です。しかし、もっと複雑な例を見てみましょう。このソリューションにはサブドメインマッチングのための2つのワイルドカード機能が含まれています。
2つのアスタリスクワイルドカードオプションがあります。ダブルアスタリスクワイルドカードは、そのセカンドレベルドメインとそのすべてのサブドメインの両方へのトラフィックにマッチしますが、シングルアスタリスクはすべてのサブドメインへのトラフィックにマッチしますが、セカンドレベルドメイン自体にはマッチしません。これらのワイルドカードを使用することで、より複雑なルールセットを作成できます。
この例では、システムはまず最初のプロトコルであるTLSと、セカンドレベルドメインのevil.comにマッチするルールを生成し、それらすべてのVPC CIDRに対応します。さらに、HTTPトラフィック用の非常に似たルールを作成し、次にalsoevil.comのすべてのサブドメインにマッチするTLSルールを作成します。そして再び、HTTPの同等のルールも作成します。
ファイアウォールルールを生成した後、2つ目の検証Lambdaレイヤーが適用され、Suricataルールに不正な形式のエントリやその他の構文関連の問題がないかチェックします。また、ルールのコンパイル後の長さを評価し、Network Firewallデバイスで設定されたルールグループの長さと照合します。さらに、エラーを自動的にエンジニアに報告し、トラブルシューティングサイクルを短縮し、デプロイメントが続行される前に問題を修正できるようにします。
もし同様のワークフローを構築してみたいという方は、こちらのQRコードに最初のLambda、つまり生の入力を受け取ってSuricataルール文字列を生成するLambdaのサンプルコードがあります。ですが、いくつか覚えておいていただきたいことがあります。Suricataは強力ですが、精度が重要です。自動化により、構文ミスが引き起こすリスクやルールの順序の問題が発生する可能性を減らすことができます。さらに、ルールのインテントが信頼できる情報源となります。エンジニアは何が起こるべきかを記述し、パイプラインがそれを実現するためのSuricata構文を定義します。
イベント駆動型の自動化は安全性を向上させます。検証、バージョン管理、エラーハンドリングがすべて組み込まれています。AWSネイティブサービスによってソリューションを軽量に保つことができます。S3、Lambda、EventBridge、CloudWatch Logsを活用して、完全にサーバーレスなワークフローを実現しています。そして最後に、より速く、より安全なルール更新です。チームはSuricataの専門知識を必要とせずに、脅威に迅速に対応できます。
その結果、これらのSuricataルールを管理するための、セルフサービスで安全、かつ再現可能なプロセスが実現します。エンジニアはインテントに集中し、パイプラインが残りを処理します。これによりAWS Network Firewallの機能を最大限に活用でき、運用オーバーヘッドを削減し、ファイアウォールルールが最新かつ正確であるという確信を構築します。
このワークフローは単にルール作成を高速化するだけでなく、大規模なルールグループの管理を容易にします。たとえ単一のルールグループ内に数百、数千のルールがある場合でもです。自動化が順序付け、検証、一貫性を処理してくれます。その結果、ファイアウォール保護をスケールさせても、もはや運用負荷が増加することはありません。大規模で複雑なルールを数分で更新してデプロイできます。
本日午後、ご参加いただいた皆様、ありがとうございました。このソリューションについて、あるいはNetwork Firewall全般についてもっとお話ししたい方は、セッション終了後、あちらの黒いカーテンのところにおりますので、皆様のご質問にお答えできればと思います。モバイルアプリでセッションアンケートにご記入いただければ幸いです。それでは、皆様、素晴らしい午後の残りの時間をお過ごしいただき、re:Inventの残りをお楽しみください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion