はじめに
こんにちは！
SRE Platform Deliveryチームで内定者インターンをしているhagiです。
今回は9月3日に社内で開催されたAWS Jamに参加したので、その様子や感想をお伝えします！
そもそもAWS Jamって何？
AWS Jamの公式サイトから抜粋すると、次のように説明されています。
AWS Jam は、AWS のユースケースに沿って用意された様々なテーマの課題を解決しながら「AWS を楽しく学ぶ」実践型のイベントです。参加者は AWS やシステム開発の知識や経験を活用し、必要に応じてその場で情報を調べながら、与えられた複数の課題を AWS マネジメントコンソールなどを利用してクリアしていきます。
このようにチームでテーマを選択し、構築されたJam用の開発環境でAWSリソースを操作しながら、課題を解決するゲーム型のイベントになっています。
今回開催されたAWS Jamの方式
今回は株式会社システムシェアードさんに開催していただきました！
約30名がプレーヤーとして参加し、8チームに分かれて競い合いました。SREのメンバーだけでなく、アプリケーションチームの方も一緒に参加し、SRE・アプリケーション混合チームで行いました。
AWS Jamの取り組み方は主に下記のような3つの方法があります。
- ソロ型：メンバーそれぞれが異なる課題に取り組む
- ペア型：ペアプロ形式で課題に取り組む（4人チームの場合は2組のペアに分かれる）
- モブ型：3人以上が1組になって問題に取り組む（1人がドライバー、残りはナビゲーター）
今回は混合チームということもあり、スキル共有も兼ねてモブ型で実施しました。
テーマ（課題）の内容
テーマは合計11個用意されており、難易度別にポイントが設定されています。
- Easy
- 80点
- 合計3問
- 例：GravitonインスタンスにDBを安全に移行
- Medium
- 150点
- 合計6問
- 例：WAFを用いてALBを潜在的な攻撃から保護
- Hard
- 200点
- 合計2問
- 例：AWSリソースを用いたABテストの実現
テーマは好きな課題から取り組むことができ、時間内で多くのポイントを獲得したチームが1位となります。
今回のJamでは、初参加の人が多かったためEasy問題から解いているチームが多い印象でしたが、Hard問題から取り組んでいるチームもありました。（スゴイ、、、!）
Easy, Mediumは日頃の開発でも遭遇するようなケースがテーマとなっている印象で、改めて基本的なAWSリソースについて、実践的に学び直せる良い課題だと感じました。
Hard問題はAWSを利用する機会が多い人でも、あまり見たことがないような状況が課題となっており、SREチームのメンバーであっても、試行錯誤しながら楽しく取り組むことができる課題だと感じました。
特に勉強になった内容
今回のJamを通して、「CloudFrontのオリジンを保護するベストプラクティス」を学ぶことが出来ました。
これまでCloudfrontの構築経験はなかったため、新たな知見を得ることができ、大変有意義でした。
ここでは、その知見について共有したいと思います！
以下の図に、通常のセキュリティ対策を行う前の一般的なALB（Application Load Balancer）をオリジンとしているCloudFrontを用いたアーキテクチャを示しています。
ここで、ALBはユーザーからのリクエストを受け取り、バックエンドのEC2インスタンスやコンテナサービスにトラフィックを分配します。
一方、CloudFrontは世界中に分散するエッジロケーションを使ってユーザーにコンテンツを高速で提供し、ALBへのトラフィックを効率的に管理します。
しかし、このままでは悪意あるユーザーがCloudfrontを経由しなくてもALBにアクセスできる状態となっています。
ベストプラクティス①
まず初めに私が思いついたセキュリティ対策は、セキュリティグループの設定です。
AWSの経験がある人なら一番に思いつく方法であるとは思いますが、オリジンであるALBのセキュリティグループのインバウンドトラフィックをCloudFrontのIPに限定することでCloudFront経由外のアクセスのブロックを実現できます。
これによりL4（トランスポート）レイヤーでの保護を実現できます。
ベストプラクティス②
私は当初、対策①のセキュリティグループでオリジンのALBの保護を実現できると考えていましたが、それだけでは不十分でした。
なぜなら、CloudfrontはAWSマネージドサービスであるため、CloudfrontディストリビューションをもつAWSアカウントは全て同じネットワークアドレス空間を共有するためです。
つまり、下図に示すように悪意のあるユーザーが別のCloudfront経由でオリジン（ALB）にアクセス可能な状態となっています。
AWS Best Practice for DDoS Resiliency(DDoS緩和のためのベストプラクティス)を参照すると、
You can use the Origin Custom Headers, for example, the X-Shared-Secret header, to help validate that the requests made to your origin were sent from CloudFront.
（オリジンへのリクエストがCloudFrontから送信されたことを検証するために、例えばX-Shared-Secretヘッダーなどのオリジンカスタムヘッダーを使用することができます。）
このように記載されており、CloudFrontのカスタムヘッダー機能を利用することが推奨されています。
CloudFrontからALBへのトラフィックにカスタムヘッダーを追加し、オリジンサーバーのALB側でカスタムヘッダーの検証を行うことで、リクエストの正当性を確認できるようになり、L7（アプリケーション）レイヤーでの防御を実現できます。
このとき、別アカウントのCloudFrontからのアクセスはカスタムヘッダーが無い、もしくはカスタムヘッダーが異なるためにALB側でブロックすることが可能になります。
この手法により、想定していない別のCloudFront経由からのALB（Application Load Balancer）への不正なアクセスを制限することが可能になります。
まとめ
このように、AWS Jamを通して、CloudFrontのオリジンを保護するベストプラクティスを知ることが出来ました。
私はベストプラクティスの方法を知る中で、カスタムヘッダーを用いるだけで、オリジンの保護を実現できるのではないかと思いました。
しかし、ALBの費用は接続数やリクエスト数（LCU）に基づいて計算されるため、セキュリティグループでL4レイヤーでの接続をブロックすることで、不要なリクエストは処理されず、LCUの使用量にカウントされないため、セキュリティグループの限定も必要であることを再確認しました。
AWS Jamに参加した感想
AWS Jamに参加した振り返りとしては、率直に「楽しかった！」と思いました。
特に、普段触れないAWSリソースに多く触れながら、ゲーム形式で楽しく学べる点が良かったと思いました。
私自身はAWSの経験がまだあまりなく、特に課題にあったCloudfrontやWAFに関する知識が不足していため、課題を通して、それらのリソースをマネージメントコンソール上で操作することで、理解を深めることができました。
AWS Jam用の環境が課題ごとに生成されるので、自由にリソースをマネジメントコンソール上から操作できるので、検証しながら課題を進めることができます。
しかし、社内のエンジニアの方たちはTerraformを通してAWSリソースを操作することに慣れており、マネコン上から直接リソースに変更を加えることを普段行わないため、マネコン操作に苦戦している人もいました。（IaCの弊害…? 笑）
また、今回はモブプロ形式で取り組み、経験豊富な方にナビゲーターをしてもらうことで、チーム全体に知識が共有されメンバー全体のスキルの向上につながったと感じました。
おわりに
AWS Jamに参加することで、楽しくAWSについて学べたので、ぜひまた機会があれば参加したいと思いました！
開催していただきありがとうございました！
