[Workshop] Approaches to layered security on Amazon VPC に参加しました #NET303 #AWSreInvent

re:Invent 2024 現地参加組のカスタマーサクセス部 運用支援チームのいたくらです。

「NET303 | Approaches to layered security on Amazon VPC」に参加したのでレポートします。

セッション情報

• セッション ID : NET303
• タイトル: Approaches to layered security on Amazon VPC
• スピーカー: Chris King, Kimberley Clements
• レベル: 300 – Advanced

ワークショップの概要

In this workshop, discover practical guidance that can help you build a secure Amazon VPC. Using a hands-on approach, review Amazon VPC features such as subnets, security groups, flow logs, and routing. Then, learn how you can add on additional layers of security and how to securely ingress and egress VPC traffic with other services, such as Amazon Route 53 Resolver DNS Firewall, AWS Network Firewall, Amazon VPC Traffic Mirroring, AWS WAF, and more.

このワークショップでは、安全な Amazon VPC の構築に役立つ実用的なガイダンスを紹介します。実践的なアプローチを使用して、サブネット、セキュリティグループ、フローログ、ルーティングなどの Amazon VPC 機能を確認します。次に、セキュリティのレイヤーを追加する方法と、Amazon Route 53 Resolver DNS ファイアウォール、AWS ネットワークファイアウォール、Amazon VPC トラフィックミラーリング、AWS WAF などの他のサービスを使用して VPC トラフィックを安全に送受信する方法を学びます。

内容

アジェンダ

アジェンダは以下の通りです。
※ アジェンダのタイトルは英語でしたが、本ブログでは日本語訳で記載しています。

• 導入：マネージドプレフィックスリストの修正
• トラック A：DNS セキュリティ
  • ラボ A1：VPC アクティビティの可視性の向上
  • ラボ A2：DNS ファイアウォールの実装
• トラック B：ネットワーク分析
  • ラボ B1：VPC ネットワーク構成の分析
  • ラボ B2：VPC ネットワークトラフィックのミラーリング
• トラック C：AWS ネットワークファイアウォール（IPv6）
  • ラボ C1：ネットワークファイアウォールのルーティングの設定（IPv6）
  • ラボ C2：AWS ネットワークファイアウォールルールの設定
• トラック D：ゲートウェイロードバランサー（GWLB）を使用するサードパーティファイアウォール
  • ラボ D1：GWLB VPC での AWS ゲートウェイロードバランサーの設定
  • ラボ D2：AWS GWLB のルーティングの設定
• トラック E：Web アプリケーションファイアウォール
  • ラボ E1：Web アプリケーションの保護

スピーカーの方が「workshop の 2 時間では全てやりきれないと思います」と言っていた通り、自分は 導入～ラボ B2 までしか workshop 時間内に終えられませんでした。

そのため、本ブログでは ラボ B2 までの内容を紹介します。
また、個人的に勉強になったと思った部分を詳しく紹介します。

前提

下記構成図の AWS 環境が用意されていました。

workshop studio のドキュメント（手順書みたいなもの）と CloudWatch ダッシュボード上に用意されたタスク（課題）を確認しながら、各自タスクをこなしていく、という進め方でした。

この CloudWatch ダッシュボードが便利で、ラボの概要、最初に何をした方が良いかのヒント、何の AWS サービスを使用しているか、ラボを進めるときに便利なリンク集などがまとめて表示されていました。
さらにラボの進捗状況が確認できるようになっており、例えばラボ A1 の場合、ラボを開始した当初の CloudWatch ダッシュボードは以下の画面ですが、

ラボを進めてタスクをクリアしていくと、以下のようにラボの進捗状況が OK に変化しました。

導入：マネージドプレフィックスリストの修正

まず最初に WebAlb ロードバランサーが自端末経由で送信される HTTP トラフィック（TCP 80）を受信できるように、マネージドプレフィックスリストの修正を実施しました。

受信できるようになったかを確認するページにアクセスし、無事にページが表示されることを確認しました。

ラボ A1：VPC アクティビティの可視性の向上

DNS クエリログを有効にして、CloudWatch Logs Insights を使用したログ検索を実施しました。

DNS クエリログを有効にしたい VPC を選択して、クエリログ記録の設定を実施しました。
（クエリログ送信先に指定した「Route53Resolver」という CloudWatch Logs ロググループはあらかじめ用意されていたものです）

このログと CloudWatch Logs Insights を使用してログ検索を実施しました。
まずは以下のクエリを実施しました。

stats count(*) as numRequests by query_name
| sort numRequests desc
| limit 10

クエリ名（query_name）ごとにリクエスト数を集計、リクエスト数が多い順に並べ替え、上位10件のみを表示するというクエリです。
その結果が以下です。

ここで怪しいドメイン名（bad.sa-demos.net.）があることが分かります。
さらに以下のクエリを実施しました。

filter query_name = 'bad.sa-demos.net.'
| stats count(*) as numRequests by srcids.instance, query_type, answers.0.Rdata as Response
| sort numRequests desc
| limit 10

特定のドメイン（bad.sa-demos.net.）に対して、リクエスト元のインスタンス、DNS クエリタイプ、DNS 応答の組み合わせごとのリクエスト数を、多い順に上位10件表示するというクエリです。
その結果が以下です。

検索結果に EC2 インスタンス ID が表示されました。
クエリを使用して原因となるインスタンスを発見する方法を知らなかったので、とても勉強になりました。

ラボ A2：DNS ファイアウォールの実装

DNS ファイアウォールのルールグループを作成して、特定のドメイン（bad.sa-demos.net.）をブロックするルールを作成しました。
ルールグループを対象の VPC に関連付けし、DNS ルールグループが機能していることをクエリで確認しました。

クエリは以下を実施しました。

filter query_name = 'bad.sa-demos.net.' and rcode = 'NXDOMAIN'
| stats count(*) as numRequests by srcids.instance
| sort numRequests desc
| limit 10

特定のドメイン（bad.sa-demos.net.）への DNS クエリのうち、ドメインが存在しない（NXDOMAIN）応答だったものについて、リクエスト元インスタンスごとのリクエスト数を多い順に上位10件表示するというクエリです。
その結果が以下です。

当該インスタンスから特定ドメインへのクエリが正常にブロックされたことが確認できました。

ラボ B1：VPC ネットワーク構成の分析

インターネットから EC2 インスタンスへ到達できるすべてのトラフィックを識別する（WebAlb ロードバランサー経由のトラフィックは意図的に除外）ために、Network Access Analyzer を設定しました。

Network Access Scopes を作成し、分析をした結果（一部抜粋）が以下です。

詳細情報を知りたい場合は要素をクリックすると確認できます。

この結果より、EC2 インスタンスが 203.0.113.0/24 から SSH トラフィックを受信できることが分かったため、当該 EC2 のセキュリティグループからこれらの SSH インバウンドルールを削除しました。

ラボ B2：VPC ネットワークトラフィックのミラーリング

トラフィックミラーリングを実施するための手順を学びました。
まずはミラーターゲット、次にミラーフィルター、最後にミラーセッションを構成しました。
ハンズオン環境で設定してみることで、ミラーターゲット、ミラーフィルター、ミラーセッションのそれぞれの役割が理解しやすかったです。

• ミラーターゲット
  • コピーしたトラフィックの送信先を定義
• ミラーフィルター
  • キャプチャするトラフィックのフィルタリングルールを定義
  • 必要なトラフィックのみを選択的にミラーリング
• ミラーセッション
  • 実際のミラーリングプロセスを確立（ソース（監視対象のENI）、ミラーターゲット、ミラーフィルター）
  • トラフィックのコピー方法を定義

最後に

こちらのワークショップを通して、実践的なネットワークセキュリティの実装方法や分析方法を学ぶことができました。
理解しながら進めていたらラボ全体の半分しか終えられませんでした。
ドキュメントなどは workshop 終了後も閲覧可能とのことだったので、着手できなかったラボ C1 以降については帰国後に時間を見つけてチャレンジしてみようと思います。
https://catalog.workshops.aws/layered-vpc-security/en-US

この記事がどなたかのお役に立てれば幸いです。

アノテーション株式会社について

アノテーション株式会社はクラスメソッドグループのオペレーション専門特化企業です。
サポート・運用・開発保守・情シス・バックオフィスの専門チームが、最新 IT テクノロジー、高い技術力、蓄積されたノウハウをフル活用し、お客様の課題解決を行っています。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、アノテーション株式会社 採用サイトをぜひご覧ください。