IERAE DAYS 2024 ワークショップを支えるインフラの仕組み

くまさか

更新日：2024.08.20

こんにちは、 SOCイノベーション事業部のあいはらとくまさかです。

今回は、弊社内製教育商材「サイバーセキュリティ攻守一体型演習」をどのようなインフラで実現しているかを、ご紹介します。

以降は、IERAE DAYS 2023 にて実施した体験会をベースに説明を行いますが、今年も9月に開催されるIERAE DAYS 2024にて体験会を実施します。こちらから体験会に応募できますので、興味のある方はぜひ応募してください！

サイバーセキュリティ攻守一体型演習とは

サイバーセキュリティ攻守一体型演習とは、GMOイエラエの攻撃の知見をわかりやすく学習できるサイバーセキュリティ入門向けのコンテンツです。

サービス紹介資料の画像

演習では、机上の学習だけでは理解の難しい攻撃について、実際に弊社ラボに対し攻撃演習を行います。
HTMLの確認方法のような基礎的な学習から実施し、徐々に攻撃に関係する分野への演習を行います。

コンテンツサンプル

演習の後半では、一度は耳にしたことがあるかもしれない、SQLインジェクションやRCE（任意のコード実行）に関して、実際の攻撃を行うと共に、より深く攻撃の仕組みを理解する内容です。

また、名前にもある攻守の通り、攻め方だけではなく、「どのようにすると守ることができるのか。」「どのようなポイントに気をつけなくてはいけないのか。」という内容を交えて学習を行います。
そのため、サーバ/インフラの運用担当者や開発者が気をつけるべき点を学習することにも有効です。

前身となるもの

GMOインターネットグループでは、GMOインターネットグループパートナー全員ホワイトハッカー計画 という、グループ全体のセキュリティ力を高める計画があります。
その計画の中で、普段セキュリティ業務に携わっていない方々に対しても、セキュリティに対する実体験と理解向上を目指せるように学習コンテンツの作成を行いました。
このコンテンツがサイバーセキュリティ攻守一体型演習の前身です。

そのため、本コンテンツは、普段セキュリティに馴染みのない方々にも、セキュリティを理解いただけるような要素が根幹にあります。

実際、多くのパートナーに学習いただけるようHackingNight#01 というグループ内イベントを実施した結果、机上の学習だけでは理解できない点に関して深く理解できたような声を多く受けました。
また、エンジニアではない方々からも、Webページの仕組みを理解することができ攻撃の一端を知ることができたというような声もありました。

このように、本コンテンツがグループ内から多くの高評価を受けたため、GMOインターネットグループ外のセキュリティを学習したい方や、技術的にセキュリティへの理解力を高めたい方へもコンテンツを提供できないかと準備を進めていきました。
実際に、CODEBLUE 2023 の弊社ワークショップや、TEDxUTOKYOのGMOワークショップのようなイベントでもコンテンツを提供しました。

各イベントでも大変多くのみなさまにご好評いただき、イベント以外でも多くの入門者へコンテンツを届けられるよう、本コンテンツを商材化しました。
最近では、モンゴルデジタル開発省サイバーセキュリティ専門家研修にて、本コンテンツを提供し、海外の方からも高い評価を得ることができました。

インフラを仕組み化

本演習では、入門向けということから、講師と共に演習を進める形をとります。
講師と密に議論をできる一方、攻守一体型演習のコストが上がる課題がありました。

そのため、より多くの皆様に本コンテンツを提供できる価格とし、本質であるセキュリティ部分を損なわないために、インフラ部分についてより安定的な仕組み化を行い、各種学習コンテンツにて、再利用可能な設計を行い、提供しております。

インフラの紹介

インフラのオペレーションは、大変シンプルな設計としています。
大まかには2つのステップのみです。

お申し込みいただいたコースに関係するマシンを設定ファイルとして記入します。
以下のコマンドを叩くと、お客様へご提供可能な状態となります。
- make deploy env=ieraedays2023

この2ステップで、コンテンツへアクセスできる環境が整います。

単純なオペレーション、洗練された設計

インフラは、AWSを利用し、以下のような構成をデプロイしています。

AWS 構成図

スコアサーバにはCTFイベントなどにもよく採用されているCTFd を採用しています。
演習参加者がスコアサーバにアクセスすると、取り組む問題の一覧が表示されます。

ctfdトップ画面

このCTFdをAmazon ECS(Elastic Container Service)とAWS Fargateを利用して構築しています。
AWSでCTFdをデプロイする場合、CTFd リポジトリ上のcompose.ymlをEC2上に展開する方法もありますが、より柔軟で適切なリソース設計が可能な形を目指すべく、ECSを用いています。
また、問題サーバについても似たような構成としています。ただし、問題の場合は、演習者の変更内容を恒久的に保存する必要がありません。そのため、CTFdと異なりデータベースやキャッシュサーバをコンテナ内部にまとめています。

そして、これらのAWSリソースはAWS CDKと呼ばれるIaCツールで構成しています。
構成ファイルの一部を変更することで、お客様に応じたコンテンツを提供することが可能です。
お客様ごとの環境を素早く自動展開したり、演習期間中のみデプロイすることで、インフラコストも最小限に抑えています。

CTFd CLIにて問題を登録

CTFdでは、ctfcli というCLIツールがあり、問題に関する情報をYAMLフォーマットで管理できます。
また、CLIツールでは、トップページのコンテンツも管理可能であり、それらを一括で展開することが可能です。

攻守一体型演習の環境では、こちらのYAMLファイルに対して、デプロイ前に検査を行うスクリプトも用意しています。
コンテンツに対する誤りについて、設定ファイルを静的に確認することで事前に検査し、開発時の不要なリトライを削減しています。
また、YAMLファイルには、正しい答えも記録されているため、受講者が誤って問題を書き換えてしまった場合も、すぐに確認できる準備もしています。

submoduleを用い各問題を連結

攻守一体型演習のコンテンツは、コースという単元に別れています。
冒頭で紹介したサービス資料にも記載がある通り、Web基礎コースやWordPress基礎コースなどがあります。

これらのコースの管理は、gitリポジトリのsubmoduleを用いています。

コースごとに独立した課題があるため、それらを全体として管理することは、管理母体の肥大化や管理効率の低下を発生させます。
それらの理由から、コースごとにリポジトリを分割し、個別管理することで、効率的な管理を実現しています。
また、あらかじめ、コースのリポジトリについては構成ルールを定めています。
この設計により、誰かがコースのリポジトリを作成すると、すぐに攻守一体型演習のコンテンツとして利用できる設計としています。
GMOイエラエには、様々な攻撃の知見を持ったホワイトハッカーが多数在籍しています。攻守一体型演習を仕組み化することにより、それぞれの得意分野で作成したコンテンツをお客様にすぐに提供できるよう環境を整えました。

リポジトリ構成イメージ

AWSでもローカルでも容易に起動

もちろん、お客様へ提供する前に、GMOイエラエ側でもコンテンツの確認を行います。
その際の開発環境も極力安く抑えるために、必要に応じてAWSでも手元でも起動できるようにしています。

今回の仕組みでは、各サーバをコンテナとして起動するため、特にDockerイメージのAWS ECR(AWSのDockerリポジトリ)へのbuildおよびpushには、多少なりとも時間がかかります。

手元で起動できるようにすることで、時間的にもコスト的にも節約につながります。
前述した共通テンプレートのフォーマットに則り開発することで、各初期化スクリプトが程よく連携し、開発マシンへお客様ご提供環境相当を素早く上げる事も可能です。

先を見据えた検討

IERAE DAYS 2023では参加人数が事前に把握できるため簡易な構成にしていますが、執筆時点では幅広いニーズに対応できるような構成に強化および計画をしています。
細かい変更はいくつかあるのですが、ここでは構成変更などの少し大きい変更が発生したものについての紹介となります。

ECSにオートスケールの追加

一つ目はECSにオートスケールの設定を追加し、CTFdのコンテナ数が自動的に増減するようにしました。
参加者数の大小や長期間のイベントで夜間の接続が少ない場合などに応じて、オートスケールにより必要な課金額だけが発生するようになります。
オートスケールにはターゲット追跡ポリシーを利用しており、CPU使用率などの特定メトリクスを目標値にして、サービスが実行するタスク数を増減させます。

概要:	設定値例
必要なタスク数:	1
最小タスク数:	1
最大タスク数:	10
ポリシー1:	平均CPU使用率が70%になるまでタスク数を増やす。
ポリシー2:	平均メモリー使用率が70%になるまでタスク数を増やす。
ポリシー3:	平均リクエスト数がCTFdのWorker数*1000の70%になるまでをタスク数を増やす。

上記の設定は一定期間のメトリクスにおけるオートスケールとなるので、イベント開始の直後や終了の直前などにトラフィックのスパイクが発生した場合にはオートスケールが間に合わない可能性があります。そのような場合には、事前に手動でコンテナ数を増やすなどの対応が必要となります。

Aurora Serverless v2への変更

RDSの構成をインスタンスを利用したものからAurora Serverless v2に変更を計画しています。こちらはIaCとしては完了しているのですが、既存環境と比べて費用面などで有利かどうかを判断している段階です。
イベント内容や参加者数からインスタンスサイズを都度決定するのではなく、ある程度オートスケールに身を任せることで、デプロイ時の検討事項を一つ減らすことができるのではと考えています。

具体的には、Aurora Serverless v2のACUをオートスケールの対象とし、より利用量に応じた課金だけが発生するようになっています。
Aurora Serverless v2のスケールアップはECSのスケールアップより早いので0.5ACUでも基本的には問題ない範囲だと考えていますが、イベント次第で最小ACUをもう少し増やしてもいいかと思います。

概要:	設定値例
最小ACU:	0.5
最大ACU:	32

問題サーバの構成

現状は問題サーバ1台ごとにALB(Application Load Balancer)が作成されています。設定ファイルを読み込み、デプロイしたい問題サーバごとに繰り返し処理を行う都合でこのような構成になっているのですが、ALBを共通化することで不要なリソースを削減することができます。
また、CTFdと共通のALBを使うことや、問題サーバにはALBをアタッチしない構成も合わせて検討予定です。

共通ALB