AWS 上のネットワークトラフィックのためのファイアウォールオートメーションを試してみる
伊藤 拓己 (監修 : 山澤 良介, 笹原 悠馬)
みなさん、こんにちは。プロフェッショナルサービス本部の伊藤拓己です。
みなさんは「AWS ソリューションライブラリ」をご存知でしょうか ?
AWS ソリューションライブラリには、すぐにお客様の課題に対応できるように、導入手順や AWS CloudFormation のテンプレート等を含めた AWS ソリューション実装という実装パターンが多数掲載されています。
今回は AWS ソリューションライブラリの中から、ネットワークトラフィックのセキュリティにフォーカスを当てて、AWS Network Firewall に関するソリューションのご紹介をします。
ご注意
本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。
この記事のデモを無料でお試しいただけます »
毎月提供されるデベロッパー向けアップデート情報とともに、クレジットコードを受け取ることができます。
近年ネットワークセキュリティが重要視されています。ネットワークセキュリティを疎かにすると不正アクセスを許すことになってしまい、個人情報の漏洩やシステムの停止につながりかねません。情報漏洩やシステム停止のようなインシデントは企業や組織の業務やブランドイメージに大きな影響を与えるため、各企業でネットワークセキュリティを確保するための対策が行われています。
ネットワークセキュリティにおいては複数のコンポーネント間の通信を検査し、有害なトラフィックを検知したり、遮断することが重要です。このような目的を実現するために、ネットワークの入り口に配置し、不正な通信を遮断する仕組みとしてファイアウォールが利用されます。
AWS では外部からのアクセスを制御し、インフラ内のセキュリティを保つためのファイアウォール機能を担うサービスを複数提供しています。AWS のファイアウォールサービスと聞いて、多くの方が以下の 2 サービスを思い浮かべるのではないでしょうか？
セキュリティグループや NACL で、IP アドレスやポート番号を指定した通信の制御が可能です。しかしお客様によっては上記に加えて、以下のような要件が求められるケースが考えられます。
- Web 通信 (HTTP / HTTPS) を宛先ドメインベースで制御
- 侵入防止システム (IPS) など高度な通信の制御
- 通信の検査を行うセキュリティコンポーネントの一元的な管理
このような要件が求められるケースでは、AWS Network Firewall を利用することで課題を解決できます。AWS Network Firewall には以下のような特徴があります。
- ① ステートフル/ステートレスな制御、② L3 ~ L7 レイヤーでの通信の制御。③ Suricata 互換の IPS などきめ細やかな通信の制御が可能である。
- 専用の検査用サブネットにエンドポイントを作成し、他のサブネットからエンドポイントへのルーティング設定を行うことで通信を検査するため、一元的な管理が可能である。
また AWS Network Firewall と AWS Transit Gateway を組み合わせることで、数百または数千の Amazon VPC とアカウントを 1 つの AWS Network Firewall で検査することができます。この構成を利用することで、セキュリティ管理者の AWS Network Firewall の運用負荷を軽減させることができます。
さらに上記構成で AWS Network Firewall の設定に GitOps の仕組みを導入することで、以下のようなメリットがあります。
- AWS Network Firewall のルールをコード管理することで、ルールの運用を効率化し、過去バージョンの復元やデグレードの防止が可能
- プロビジョニング処理を自動化することで、ルールの更新負荷を軽減可能
今回、ご紹介する「AWS 上のネットワークトラフィックのためのファイアウォールオートメーション」は AWS Network Firewall と AWS Transit Gateway を組み合わせて一元的に複数の VPC やアカウント間の通信を検査する仕組みを簡単にデプロイすることができます。また Amazon VPC 間のトラフィックを検査するための一元的な AWS Network Firewall のプロビジョニング処理を自動化することで、AWS Network Firewall のルールの運用や更新作業を効率化することができます。
それでは、「AWS 上のネットワークトラフィックのためのファイアウォールオートメーション」がどんなソリューションなのか見ていきましょう。
「AWS 上のネットワークトラフィックのためのファイアウォールオートメーション」とは？
今回紹介するソリューションは「AWS 上のネットワークトラフィックのためのファイアウォールオートメーション」という複数の VPC 間の通信を検査するための AWS Network Firewall のプロビジョニング処理を自動化するソリューションです。
このソリューションでは複数の VPC やアカウント間の通信を検査する仕組みを一元管理でき、設定変更を自動化できます。
具体的には以下の 3 つの仕組みを実現できます。
- 「AWS Network Firewall に対する変更の自動デプロイ」：AWS CodeCommit リポジトリ内の AWS Network Firewall の設定パッケージを変更することで、AWS CodePipeline が自動的に呼び出され、検証とデプロイが実行されます。
- 「AWS Network Firewall の一元管理」：大量の Amazon VPC およびアカウントのトラフィックを 1 つの検査 VPC で検査できます。また AWS Network Firewall、ファイアウォールポリシー、およびルールグループを設定パッケージにて一元的に管理できます。
- 「AWS Network Firewall に対する変更の監査と追跡」：このソリューションでは GitOps ワークフローで AWS Network Firewall の設定をバージョン管理するため、設定変更の追跡・管理が容易になります。
上記 3 つの仕組みを実現することで、複数のAmazon VPC 間およびマルチアカウント間のトラフィックの検査するための AWS Network Firewall の運用負荷を軽減し、変更の迅速なデプロイができるようになります。
「AWS 上のネットワークトラフィックのためのファイアウォールオートメーション」のソリューションアーキテクチャの概要
アーキテクチャの全体像
本構成では以下のコンポーネントをデプロイします。
- 検査 VPC (Inspection VPC)
- 検査 VPC 内で作成される AWS Transit Gateway アタッチメント (Transit Gateway Elastic Network Interface)
- 検査 VPC 内で作成される AWS Network Firewall エンドポイント
- 検査 VPC のサブネットに関連付けるルートテーブル
- AWS Network Firewall の設定パッケージを管理する AWS CodeCommit リポジトリ
- 設定パッケージの検証・デプロイを行う AWS CodeBuild のビルドプロジェクト
- 検証・デプロイをパイプラインにするための AWS CodePipeline
- ログ出力先の Amazon S3 バケット / Amazon CloudWatch ロググループ
- オブジェクトやログの暗号化で利用する AWS Key Management Service の暗号化キー
- ビルドプロジェクトが利用する IAM ロール
※ 本ソリューションでは AWS Transit Gateway および スポークアカウントの VPC (以下スポーク VPC) は AWS CloudFormation スタックで作成されません。
各コンポーネントの概要
「AWS 上のネットワークトラフィックのためのファイアウォールオートメーション」ではソリューションのデプロイ先の AWS リージョンに、合計 4 つのサブネットを持つ検査 VPC をデプロイします。AWS CloudFormation スタック作成時にパラメータで既存の AWS Transit Gateway のID を指定すると、2つのサブネットにはアプライアンスモードが有効化された AWS Transit Gateway アタッチメントを作成します。残りの 2 つのサブネットには AWS Network Firewall のエンドポイントを作成します。
クリックすると拡大します
また以下の 2 種類のルートテーブルを作成します。
- AWS Transit Gateway アタッチメントを作成するサブネットに関連付けるルートテーブルとして、Firewall エンドポイントをデフォルトルートとするルートテーブルを作成します。
- Firewall エンドポイントを作成するサブネットに関連づけるルートテーブルとして、AWS Transit Gateway をデフォルトルートとするルートテーブルを作成します。
クリックすると拡大します
また AWS CodeCommit リポジトリとリポジトリ内に AWS Network Firewall の設定パッケージを作成します。設定パッケージの変更がコミットされた場合、AWS CodePipeline が起動され、以下の 2 つの AWS CodeBuild のプロジェクトを実行します。
- 「検証ステージ」：ドライランモードの AWS Network Firewall API で設定パッケージを検証します。このステージでは JSON ファイル構造をチェックし、設定で参照するファイルの依存関係を確認します。またデプロイ前にエラーが発生しないかを確認します。
- 「デプロイステージ」：このステージでは設定パッケージをもとに AWS Network Firewall、AWS Network Firewall ポリシー、ルールグループを作成/更新します。
クリックすると拡大します
また以下のリソースをデプロイします。
- オブジェクトの暗号化やログの暗号化のための AWS Key Management Service の暗号化キー
- AWS CodeBuild が S3 バケットにアクセスして、AWS Network Firewall リソースを管理するために必要となる AWS IAM ロール
- AWS Network Firewall のログ出力先の Amazon S3 バケット、または Amazon CloudWatch のロググループ
また AWS CloudFormation のパラメータにて AWS Network Firewall のログの出力先を手動で設定するように指定することも可能です。出力先として Amazon S3 バケット、Amazon CloudWatch Logs、および Amazon Kinesis Data Firehose を選択可能です。
クリックすると拡大します
また本ソリューションには含まれていませんが、Amazon GuardDuty を有効化することで、Amazon VPC を通過する通信を検査するだけでなく、AWS アカウントや AWS 環境で発生する脅威を検知することができます。そのため本ソリューションのデプロイと合わせて、Amazon GuardDuty を有効化することを推奨します。
コスト試算の例
このソリューションで発生するコストは、処理されるトラフィック量や AWS CodePipeline の実行時間に応じて異なります。詳細については、AWS の各サービスの料金表ウェブページを参照してください。
参考として東京リージョンで本ソリューションをデフォルト設定で構築し、1 日あたり 5 GB のトラフィックがある場合の推定コストは 2022 年 7 月現在で、1 か月 (30 日) あたり約 635.65 USD です。これには、AWS CodePipeline、AWS CodeBuild、Amazon Simple Storage Service (Amazon S3) に対する推定請求額は含まれません。
| AWSのサービス | ディメンション | 総コスト (１ヶ月あたり) |
| AWS Network Firewall (エンドポイント) |
2 つのエンドポイント/24 時間 (0.395 USD/エンドポイント/時間) |
568.80 USD |
| AWS Network Firewall (データ処理) |
5 GB (0.065 USD/GB) | 9.75 USD |
| AWS Transit Gateway (VPCアタッチメント) |
24 時間 (0.07 USD/時間) | 51.10 USD |
| AWS Transit Gateway (データ処理) |
10 GB (0.02 USD/GB) | 6.00 USD |
| AWS Code サービス (AWS CodePipeline、AWS CodeBuild、AWS CodeCommit) |
AWS CodePipeline の実行回数に基づく | |
| Amazon S3 | AWS CodePipeline の実行回数とAWS Network Firewall のログアクティビティに基づく | |
| 合計 635.65 USD | ||
デプロイ方法/設定方法
このソリューションの設定は ①「AWS Transit Gateway の作成 (事前準備)」、②「スタックの起動」の 2 つのステップがあります。本ブログでは東京リージョン (ap-northeast-1) にデプロイします。
※ 本ソリューションでは既存の AWS Transit Gateway を利用します。そのため本記事では事前準備として AWS Transit Gateway を作成します。
デプロイにおける注意事項
- Amazon VPC および関連リソースは AWS CloudFormation のスタック更新では設定値の更新ができません。VPC CIDR ブロックを更新するには Amazon VPC を削除してから再作成する必要があります。そのため本ソリューションのデプロイ後に VPC CIDR の変更が発生しないように、ネットワーク管理者と連携して、検査 VPC の CIDR ブロックを予め確保しておくことが推奨されます。
- 初回のデプロイ時は AWS Network Firewall のポリシーがで全ての通信を許可するため、既存のワークロードに影響を与えません。そのためソリューションのデプロイ後に設定パッケージを編集することで AWS Network Firewall の設定を更新することができます。
ステップ１：AWS Transit Gateway の作成 (事前準備)
このステップでは以下の作業を実施します。
- AWS Transit Gateway の作成
- スポーク VPC が参照する Transit Gateway ルートテーブルの作成
- 検査 VPC が参照する Transit Gateway ルートテーブルの作成
まず AWS Transit Gateway を作成します。AWS マネジメントコンソールを起動し、東京リージョン (ap-northeast-1) であることを確認します。Amazon VPC コンソールを起動します。
クリックすると拡大します
Amazon VPC コンソール上で「Transit Gateway」を選択し、「Transit Gateway を作成」をクリックします。
クリックすると拡大します
「名前タグ」に任意の名前 (例：network-firewall-automation-solutions-tgw) を入力し、「デフォルトルートテーブルの関連付け」と「デフォルトルートテーブ伝播」からチェックを外します。
クリックすると拡大します
「Transit Gateway を作成」を選択します。
クリックすると拡大します
続いて Transit Gateway ルートテーブルを作成します。Amazon VPC コンソールから 「Transit Gateway ルートテーブル」を選択し、「Transit Gateway ルートテーブルを作成します」をクリックします。
クリックすると拡大します
まずスポーク VPC が参照する Transit Gateway ルートテーブルを作成します。「名前タグ」に任意の名前 (例：spoke-vpc-tgw-route-table) を入力し、「Transit Gateway ID」で作成済みの AWS Transit Gateway を選択します。最後に「Transit Gateway ルートテーブルを作成」をクリックします。
クリックすると拡大します
次に検査 VPC が参照する Transit Gateway ルートテーブル (例：inspection-vpc-tgw-route-table) を同様の手順で作成します。
作成が完了すると「Transit Gateway ルートテーブル」で 2 つの Transit Gateway ルートテーブルが表示され、「状態」が「Available」になります。
クリックすると拡大します
最後に「Transit Gateway ID」と「Transit Gateway ルートテーブル ID」をメモします。
クリックすると拡大します
ステップ２：スタックの起動
本ソリューションで使用する CloudFormation テンプレートを実行するために、こちらのランディングページにアクセスします。
「AWS コンソールで起動する」を選択します。
CloudFormation コンソールが起動されて、スタックの作成画面になります。コンソール上部からリージョンを東京リージョン (ap-northeast-1) に変更します。
クリックすると拡大します
「前提条件 - テンプレートの準備」、「テンプレートの指定」は変更せずにそのまま「次へ」を選択します。
クリックすると拡大します
「スタックの名前」に任意の名前(例：network-firewall-automation-solutions-stack)を入力します。
クリックすると拡大します
下表に従い、パラメータを入力します。
| パラメータ名 | 値 |
| Provide the existing AWS Transit Gateway ID you wish to attach to the Inspection VPC | ステップ 1 で作成した AWS Transit Gateway の Transit Gateway ID |
| Provide the AWS Transit Gateway Route Table to be associated with the Inspection VPC TGW Attachment | 検査 VPC が参照する Transit Gateway ルートテーブル ID |
| Provide the AWS Transit Gateway Route Table to receive 0.0.0.0/0 route to the Inspection VPC TGW Attachment | スポーク VPC が参照する Transit Gateway ルートテーブル ID |
その他のパラメータは全てデフォルト値を指定します。
「次へ」を選択します。
クリックすると拡大します
各パラメータの詳細については、実装ガイドの 14 ~ 16 ページをご参照ください。
「スタックオプションの設定」のページで「次へ」を選択します。
クリックすると拡大します
「レビュー」ページで設定を確認します。「AWS CloudFormation によって IAM リソースが作成される場合があることを承認します。」のチェックボックスをオンにします。
「送信」を選択して、スタックをデプロイします。
クリックすると拡大します
スタックのステータスは、AWS CloudFormation コンソールの「ステータス」列で確認できます。約 7 分でスタックの作成が完了し、「CREAT_COMPLETE」ステータスが表示されます。
動作確認
このソリューションをデプロイすることで、複数の VPC やアカウント間の通信を検査する仕組みを一元管理し、AWS Network Firewall の設定変更を自動化する仕組みを導入できました。設定を変更する際は、AWS CodeCommit リポジトリ内の AWS Network Firewall の設定パッケージを更新することで、AWS CodePipeline が起動され、AWS Network Firewall 設定の検証とデプロイが実行されます。
動作確認ではまず 2 つの Amazon VPC (VPC A、VPC B) を作成し、AWS Transit Gateway に接続することで、VPC A と VPC B の間で疎通を確認します。次に AWS CodeCommit リポジトリ内の AWS Network Firewall の設定パッケージを修正し、AWS Network Firewall を通過する通信を遮断するように AWS Network Firewall ポリシーの設定を変更します。最後に AWS Network Firewall ポリシーの設定の変更により VPC A と VPC B 間で通信ができなくなったことを確認します。
本動作確認は大きく分けて ①「動作確認用リソースの作成」②「動作確認用 VPC の AWS Transit Gateway への接続と疎通確認」、③「AWS Network Firewall の設定変更と通信が遮断されるかの確認」の 3 ステップからなります。
クリックすると拡大します
クリックすると拡大します
クリックすると拡大します
クリックすると拡大します
ステップ1：動作確認用リソースの作成
まず動作確認のために 2 つの VPC (VPC A、VPC B) を作成します。マネジメントコンソールから Amazon VPC を起動します。
「お使いの VPC」から「VPC を作成」を選択します。
「名前タグ」に任意の名前を入力し、「IPv4 CIDR」 にアドレスレンジに重複がないように IP アドレスの範囲を入力します（入力例を下表に示します）。最後に「VPC を作成」を選択し、VPC を作成します。
クリックすると拡大します
| 名前タグ(例) | IPv4 CIDR (例) | |
| VPC A | network-firewall-automation-solutions-vpc-a | 10.0.1.0/24 |
| VPC B | network-firewall-automation-solutions-vpc-b | 10.0.2.0/24 |
2 つの Amazon VPC が作成されたことを確認します。
次に作成した 2 つの VPC に 1 つずつサブネット (VPC Aに Subnet A、VPC B に Subnet B) を作成します。
マネジメントコンソールの Amazon VPC から「サブネット」を選択し、「サブネットを作成」をクリックします。「VPC ID」で先ほど作成した VPC を選択します。「サブネット名」に任意の名前を入力し、指定した VPC の CIDR から 「IPv4 CIDR ブロック」を入力します (入力例を下表に示します)。（ここでは Subnet A は 10.0.1.0/28 を、Subnet B は 10.0.2.0/28 を指定します）最後に「サブネットを作成」を選択し、サブネットを作成します。
クリックすると拡大します
| VPC ID | サブネット名 (例) | IPv4 CIDR ブロック (例) | |
| Subnet A | VPC A の VPC ID | network-firewall-automation-solutions-subnet-a | 10.0.1.0/28 |
| Subnet B | VPC B の VPC ID | network-firewall-automation-solutions-subnet-b | 10.0.2.0/28 |
2 つのサブネットが作成されたことを確認します。
本動作確認では VPC A に Amazon EC2 インスタンスを起動し、疎通確認のために OS に接続します。接続の手順を簡素化するため、VPC A にインターネットゲートウェイを作成し、インターネット経由でインスタンスに接続できるようにします。
マネジメントコンソールの Amazon VPC から「インターネットゲートウェイ」を選択し、「インターネットゲートウェイの作成」をクリックします。
「名前タグ」に任意の名前(例：network-firewall-automation-solutions-igw) を入力し、「インターネットゲートウェイの作成」をクリックします。
クリックすると拡大します
インターネットゲートウェイの一覧から作成したインターネットゲートウェイを選択し、「アクション」から「VPC にアタッチ」をクリックします。
クリックすると拡大します
「使用可能な VPC」で VPC A の VPC ID を選択し、「インターネットゲートウェイのアタッチ」をクリックします。
クリックすると拡大します
次にそれぞれの Subnet に 1 つずつ EC2 インスタンス (Subnet A に Instance A、Subnet B にInstance B)を作成します。マネジメントコンソールから Amazon EC2 を起動します。「インスタンス」から「インスタンスを起動」を選択します。
下表を参考に設定値を入力します。(下表にない値はデフォルト値を利用します。)
| Instance A | Instance B | |
| 名前 (例) | network-firewall-automation-solutions-instance-a | network-firewall-automation-solutions-instance-b |
| Amazon マシンイメージ (AMI) | Amazon Linux 2 AMI (HVM) - Kernel 5.10, SSD Volume Type | Amazon Linux 2 AMI (HVM) - Kernel 5.10, SSD Volume Type |
| キーペア名 | キーペアなしで続行 (推奨されません) | キーペアなしで続行 (推奨されません) |
| VPC | VPC A | VPC B |
| パブリック IP の自動割り当て | 有効化 | 無効化 |
| インバウンドセキュリティグループのルール | 「任意の場所」からの「ssh」インバウンド通信を許可 | 「任意の場所」からの「すべての ICMP - IPv4」インバウンド通信を許可 |
「インスタンスを起動」を選択します。
参考：Instance A の起動画面
クリックすると拡大します
クリックすると拡大します
クリックすると拡大します
クリックすると拡大します
参考：Instance B の起動画面 (ネットワーク設定)
クリックすると拡大します
2 つの EC2 インスタンスが作成されたことを確認します。
ステップ2：動作確認用 VPC の AWS Transit Gateway への接続と疎通確認
次に VPC A と VPC B と AWS Transit Gateway を接続し、Instance A と Instance B で通信ができるようにします。
まず VPC A と VPC B に それぞれ Transit Gateway アタッチメントの作成を行います。マネジメントコンソールから Amazon VPC を起動し、「Transit Gateway アタッチメント」を選択します。「Transit Gateway アタッチメントを作成」を選択します。
クリックすると拡大します
まず VPC A にTransit Gateway アタッチメントを作成します。「名前タグ」に任意の名前 (例：network-firewall-automation-solutions-tgw-attachment-vpc-a) を入力します。「Transit Gateway ID」から自身がデプロイした AWS Transit Gateway の ID を選択します。「VPC ID」と「サブネット ID」から VPC A とサブネット A を指定します。「Transit Gateway アタッチメントを作成」を選択します。
クリックすると拡大します
同様に VPC B にも Transit Gateway アタッチメント (名前の例：network-firewall-automation-solutions-tgw-attachment-vpc-b) を作成します。
VPC A と VPC B それぞれでアタッチメントの作成が完了すると、検査 VPC に作成されたアタッチメントも含めて、合計 3 つの Transit Gateway アタッチメントが作成されることになります。
クリックすると拡大します
次に Transit Gateway アタッチメントと Transit Gateway ルートテーブルの関連付けを行います。マネジメントコンソールの Amazon VPC から「Transit Gateway ルートテーブル」を選択します。スポーク VPC が参照する AWS Transit Gateway ルートテーブルを選択し、「アクション」⇨「関連付けを作成」を選択します。
クリックすると拡大します
まず VPC A に作成した Transit Gateway アタッチメントと Transit Gateway ルートテーブルの関連付けを行います。「関連付けるアタッチメントを選択」から VPC A に作成した Transit Gateway アタッチメントを選択します。「関連付けを作成」を選択します。
クリックすると拡大します
同様に VPC B に作成した Transit Gateway アタッチメントとスポーク VPC が参照する Transit Gateway ルートテーブルの関連付けも行います。
次に VPC A と VPC B の情報を検査 VPC が参照する Transit Gateway ルートテーブルに登録します。関連付けの作成と同様に、マネジメントコンソールの Amazon VPC から「Transit Gateway ルートテーブル」を選択します。検査 VPC が参照する Transit Gateway ルートテーブルを選択し、「アクション」⇨「伝達の作成」を選択します。
クリックすると拡大します
まず VPC A の経路情報の伝播を行います。「伝達するアタッチメントを選択」から VPC A に作成した Transit Gateway アタッチメントを指定し、「伝達を作成」を選択します。
クリックすると拡大します
同様にして VPC B の伝播も作成します。
次にサブネット A について、VPC B の CIDR の宛先を Transit Gateway アタッチメントに、デフォルトルートの宛先をインターネットゲートウェイに設定します。マネジメントコンソールの Amazon VPC から「サブネット」を開きます。
まずサブネット A のルートを設定します。サブネット A を選択し、「ルートテーブル」から関連づけられているルートテーブルを選択します。
クリックすると拡大します
「ルート」⇨「ルートを編集」を選択します。
クリックすると拡大します
下表に従って VPC B の CIDR の宛先を Transit Gateway アタッチメントに、デフォルトルートの宛先をインターネットゲートウェイに設定します。
クリックすると拡大します
| ルート | 送信先 (例) | ターゲット |
| VPC B の CIDR のルート | 10.0.2.0/24 | VPC A に作成した Transit Gateway アタッチメント |
| デフォルトルート | 0.0.0.0/0 | VPC A に作成したインターネットゲートウェイ |
次にサブネット B のデフォルトルートの宛先を Transit Gateway アタッチメントに設定します。マネジメントコンソールの Amazon VPC から「サブネット」を開きます。
まずサブネット B のデフォルトルートの設定を行います。サブネット B を選択し、「ルートテーブル」から関連づけられているルートテーブルを選択します。
クリックすると拡大します
「ルート」⇨「ルートを編集」を選択します。
クリックすると拡大します
「送信先」に 0.0.0.0/0 を、「ターゲット」に VPC B に作成した Transit Gateway アタッチメントを指定します。「変更を保存」を選択します。
クリックすると拡大します
最後に疎通確認を行います。マネジメントコンソールから Amazon EC2 を接続します。まず Instance B を選択し、「詳細」⇨「プライベート IPv4 アドレス」から疎通確認先の Instance B のプライベート IPv4 アドレスをコピーします。次に Instance A を選択し、「接続」をクリックします。
クリックすると拡大します
「EC2 Instance Connect」を選択し、「接続」をクリックします。
クリックすると拡大します
接続に成功すると、次のようなターミナルが表示されます。
クリックすると拡大します
Instance A から Instance B への疎通を確認するために ping -c (Instance B のプライベート IPv4 アドレス) を実行します。実行すると Instance B から応答が返ってくるため、AWS Transit Gateway を介して、接続に成功したことが確認できます。
クリックすると拡大します
ステップ3：AWS Network Firewall の設定変更と通信が遮断されるかの確認
最後に AWS Network Firewall の設定パッケージの情報を変更し、VPC A と VPC B の間の通信を遮断するように AWS Network Firewall ポリシーを更新します。本動作確認では手順を簡素化するため AWS CodeCommit コンソールから設定パッケージを直接編集します。
マネジメントコンソールから AWS CodeCommit を開きます。「リポジトリ」から AWS CloudFormation で作成したリポジトリを開きます。
クリックすると拡大します
「firewallPolicies」ディレクトリを開きます。
クリックすると拡大します
「firewall-policy-1.json」を開きます。
クリックすると拡大します
「編集」を選択します。
クリックすると拡大します
StatelessDefaultActions を "aws:forward_to_sfe" から "aws:drop" に修正します（Policyの記述方法は CreateFirewallPolicy ドキュメントをご参照ください）。「main に対する変更のコミット」の「作成者名」に任意の名前を、「E メールアドレス」に任意の E メールアドレスを入力し、「変更のコミット」を選択します。
クリックすると拡大します
マネジメントコンソールから AWS CodePipeline を開きます。「パイプライン」を選択し、検証ステージやデプロイステージの進行状況を確認します。（右はデプロイステージの途中の画像です）
クリックすると拡大します
AWS Network Firewall コンポーネントのデプロイが完了すると、AWS CodePipeline のパイプラインの結果が右の画像のようになります。
クリックすると拡大します
次に AWS Network Firewall の設定が変更されたかの確認を行います。
AWS マネジメントコンソール上から、Amazon VPC を起動し、「AWS Network Firewall」の「ファイアウォールポリシー」に移動し、作成されたファイアウォールポリシー (Firewall-Policy-1-****) を選択します。
「ステートレスデフォルトアクション」の「完全なパケットに対するアクション」が「ドロップ」に変更されたことが確認できました。つまり AWS Network Firewall を通過した完全なパケットが破棄されることになります。
クリックすると拡大します
それでは、Instance A から Instance B に通信を送り、ファイアウォールによって通信が遮断されることを確認します。先ほどと同様に Instance A に EC2 Instance Connect で接続し、ping コマンドを実行することで、Instance B に対して通信を送ります。こちらに示した通り Instance B からは応答が返ってこないためファイアウォールによって通信が遮断されたことが確認できました。
クリックすると拡大します
このように AWS Network Firewall の設定パッケージの更新を AWS CodeCommit にコミットするだけで、複数の VPC の通信を制御するための AWS Network Firewall の設定を変更することができました。
ファイアウォールポリシー設定の記述方法の詳細は CreateFirewallPolicy ドキュメントをご参照ください。
また実際の運用では AWS Network Firewall のルールグループによりアクセス制御を行うケースが多くあります。ルールグループの設定を JSON 形式で記述し、AWS CodeCommit リポジトリに配置することで、AWS CodePipeline が起動され、ルールグループを作成することができます。ルールグループの設定の記述方法は、CreateRuleGroup ドキュメントをご参照ください。
AWS CodeCommit リポジトリ内のディレクトリ構造を含めて、本ソリューションの詳細は実装ガイドをご参照ください。
リソースの削除
- AWS マネジメントコンソールから AWS CloudFormation コンソールを起動します。
- このソリューション用のスタックを選択します。
- 「削除」を選択し、スタックの削除を行います。
- 以下のリソースはスタックの削除後も保持されます。これらは手動で削除を行います。
a. AWS CodeCommit リポジトリ
b. Amazon CloudWatch のロググループ
c. Amazon S3 にある AWS CodePipeline のアーティファクトバケット
d. Amazon S3 にある AWS CodeBuild のソースコードバケット
e. AWS Network Firewall
i. まず Transit Gateway サブネットのルートテーブルから Firewall エンドポイントへのルートを削除します。
ii. 次に AWS Network Firewall のログ設定を無効化します。
iii. 最後に AWS Network Firewall の削除を行います。
f. AWS Network Firewall のファイアウォールポリシー
g. AWS Network Firewall のルールグループ (本ブログでは作成しておりません)
h. 検査 VPC
i. 検査 VPC に作成した Transit Gateway を削除します。
ii. VPC を削除します。
- AWS Transit Gateway に関連するリソースの削除を行います。
a. まず Transit Gateway アタッチメントを削除します。
b. 次に Transit Gateway ルートテーブルの関連づけ、および伝播を全て削除します。
c. 最後に AWS Transit Gateway の削除を行います。 - 動作確認用の EC2 インスタンスを削除します。
- 動作確認用 VPC A と VPC B を削除します。
※ S3バケットの削除にあたっては、先にバケット内のオブジェクトを全て削除する必要があります。
※ AWS Network Firewall の削除にあたっては、ルートテーブルから Firewall エンドポイントへのルートを削除、ログ設定をオフにする必要があります。
※ AWS Network Firewall のファイアフォールポリシーの削除にあたっては先にAWS Network Firewall を削除する必要があります。
まとめ
いかがでしたでしょうか。「AWS 上のネットワークトラフィックのためのファイアウォールオートメーション」によりセキュリティ管理者の方は、Amazon VPC 間のトラフィックを検査するための一元的な AWS Network Firewall のプロビジョニング処理を自動化することができるようになりました。これにより管理の負担の軽減や、迅速な設定変更を実現できます。
ぜひ AWS Network Firewall の活用の一つのパターンとしてご検討ください。
筆者プロフィール
伊藤 拓己 (Takumi Ito)
アマゾン ウェブ サービス ジャパン合同会社
プロフェッショナルサービス本部 アソシエイトコンサルタント
プロフェッショナルサービスとして、エンタープライズのお客様の AWS への移行をご支援させていただいています。オンプレミスのサーバー管理をオフロードできるクラウドの魅力を知り、お客様にもこの魅力を知ってほしいと思い日々働いています。
監修者プロフィール
山澤 良介 (Ryosuke Yamazawa)
アマゾン ウェブ サービス ジャパン合同会社
ソリューションアーキテクト
ソリューションアーキテクトとして、業種業態を問わず様々なお客様を支援させて頂いています。
前職では主にネットワーク案件を担当していたため、好きなサービスは、AWS Direct Connect と AWS Transit Gateway です。
休日はスノーボードが大好きなので、シーズン中は毎週スキー場に行っております。
笹原 悠馬 (Yuma Sasahara)
アマゾン ウェブ サービス ジャパン合同会社
プロフェッショナルサービス本部 クラウドインフラアーキテクト
プロフェッショナルサービスとして、エンタープライズのお客様の AWS への移行をご支援させていただいています。お客様がクラウドにインフラストラクチャを構築し、ビジネスアウトカムを実現することをサポートしています。
AWS を無料でお試しいただけます