AWS BuilderCardsで学ぶ、AWSセキュリティ基本の「き」 ~AWS BuilderCards日本語版開発者による、セキュリティ拡張パックの解説~

TL;DR

AWSのセキュリティサービスを利用して、脅威アクター＝ペットアクターからのいたずらと、その影響として発生するセキュリティインシデントに備え、Well-Architectedの柱のひとつ「セキュリティ」を体得しよう。

drawn by @komakichidev

$ whoami

coosuke と書いて、コースケ とか コスケ と呼ばれています。

intro_coosuke.json

{
    "Name":"Kosuke Enomoto",
    "Bio":"https://linktr.ee/coosuke",
    "Job":"PO of Global CCoE",
    "SNS":[
          {
              "LinkedIn":"https://www.linkedin.com/in/kosuke-enomoto/",
              "X (formerly Twitter)":"@coosuke",
              "mixi2":"@coosuke",
              "Instagram":"@coskenomoto"
          }
      ],
    "Communities":[
        "Organizer, JAWS-UG Chiba Chapter",
        "AWS Community Builder",
        "AWS BuilderCards 日本語版開発者"
    ],
    "My Family":[
        "Wife","Black cat(5yo)","Kid(4yo)"
    ],
    "Hobbies":[
        "Sauna","Cooking","Photography"
    ]
}

私の各SNSへのリンクは、以下に集約しております。ぜひソーシャルで繋がりましょう。

ここで書くこと、書かないこと

書くこと

• AWS BuilderCards はええぞ
• AWS BuilderCards セキュリティ拡張パック はええぞ

書かないこと

• AWSのセキュリティサービスに関する説明や実装方法
• AWS BuilderCards 基本パックの細かいルール

はじめに

今回は、私も日本語版開発者のひとりとして取り組んだ、AWS BuilderCardsの新作、セキュリティ拡張パックについて、ご紹介致します。

現在、米国・ラスベガスで開催されている、AWS re:Inventに、今年もBuilderCardsのブースがオープンしています。

AWS re:Invent 2025 における、AWS BuilderCardsブース

• 📍 Location: Caesar’s Forum (alcove, below the escalators)
• 🕐 Opening Hours:
  • Sunday, Nov 30, 10 AM – 6 PM
  • Monday, Dec 1, 9 AM – 5 PM
  • Tuesday, Dec 2, 9 AM – 5 PM
  • Wednesday, Dec 3, 9 AM – 5 PM
  • Thursday, Dec 4, 9 AM – 4 PM
• ブースには、日本語が話せるAWSのSAさんも対応して頂くとのことです！

現地参加されている皆様の中には、既にブースに立ち寄り、BuilderCardsを手に入れた方もいらっしゃると思います。この記事では、BuilderCards開発者目線(かつ、セキュリティはどちらかといえば素人)から、新作をご紹介致します。

AWS Well-Architected フレームワーク とは

まずは本題へ入る前に、そもそもWell-Architected フレームワークとは何かについて、改めて整理しましょう。

筆者の私見ですが、Well-Architected フレームワークとは、ずばり「クラウドのベストプラクティス集」です。クラウドのベストプラクティスとは何か、というと、「クラウドのユースケースやアーキテクチャは、ビルダー・開発チーム・企業によって最適解は変わるけれども、個々の事情に左右されない、普遍的で汎用度の高い、設計や実装のガイドブック」です。このフレームワークには強制力はありませんが、フレームワークに則ってビルドすることにより、ROIの高いシステムをビルドすることが出来る、と考えています。ちなみに、Well-Architected フレームワークは、AWSに限らず、Google CloudやAzureも、Well-Architected フレームワークを公開しています。それぞれのドキュメントを読み比べてみると、基本は同じだけど、大変面白いと考えています。

AWS Well-Architected フレームワークを構成する「柱」

AWSのWell-Architected フレームワークは、6つのPillars＝柱にブレークダウンされます。

• 運用上の優秀性(Operational Excellence)
• セキュリティ(Security)
• 信頼性(Reliability)
• パフォーマンス効率(Performance Efficiency)
• コスト最適化(Cost Optimization)
• 持続可能性(Sustainability)

今年の新作、「セキュリティ拡張パック」は、このうち「セキュリティの柱」を学習してもらうために、開発されました。

セキュリティの柱

ということで、セキュリティの柱を、読んでみましょう。ココで全部書くと長くなるので、Geminiに要約してもらいました。
(なんでGeminiやねん、というツッコミは、なしでｗ)

要約すると、7つの設計原則と、6つの重点分野(ベストプラクティス)に分かれます。

---

// Geminiの要約 ココから

7つのセキュリティ設計原則

クラウドセキュリティを実装する際の指針です。

1. 強力なアイデンティティ基盤の実装 (Implement a strong identity foundation):
最小権限の原則を適用し、職務分掌を徹底する。人へのアクセス許可ではなく、ロールベースや一時的な認証情報を使用する。

2. トレーサビリティの実現 (Enable traceability):
環境に対するすべてのアクションと変更を監視、アラート、監査する。ログとメトリクスを統合し、リアルタイムで調査できるようにする。

3. 全レイヤーでのセキュリティ適用 (Apply security at all layers):
境界防御だけでなく、VPC、サブネット、ロードバランサー、インスタンス、OS、アプリケーションなど、すべての階層で多層防御を行う。

4. セキュリティのベストプラクティスの自動化 (Automate security best practices):
コード（IaC）としてセキュリティルールを管理し、バージョン管理を行う。自動化により人的ミスを減らし、スケーリングに対応する。

5. 伝送中および保管中のデータの保護 (Protect data in transit and at rest):
データの分類（機密度に応じたタグ付けなど）を行い、暗号化、トークン化、アクセ制御などを用いてデータを保護する。

6. データへの人のアクセスを排除 (Keep people away from data):
データへの直接アクセスや手動処理を減らすためのツールやメカニズムを作成する。これにより、誤操作やデータの漏洩リスクを低減する。

7. セキュリティイベントへの備え (Prepare for security events):
インシデント対応プロセスを整備し、定期的にシミュレーション（ゲームデー）を行って、検知・調査・復旧のスピードと手順を確認する。

6つの重点分野（ベストプラクティス）

具体的な実装におけるカテゴリです。

① セキュリティの基盤 (Security Foundations)

• 責任共有モデルの理解: AWSと顧客の責任範囲を明確にする
• AWSアカウントの管理: ワークロードごとにアカウントを分離し、AWS Organizationsなどで統制する

② アイデンティティとアクセス管理 (Identity and Access Management)

• アイデンティティ管理: 人間（User）とマシン（Resource）の認証情報を一元管理する
• 権限管理: 必要な人に必要なときだけ権限を与える「最小権限」を徹底する

③ 発見的統制 (Detection)

• ログと監視: CloudTrail（API履歴）、Config（構成変更）、GuardDuty（脅威検知）などを有効化し、異常を即座に検知する仕組みを作る
• 通知: アラートを適切なチームに自動通知する

④ インフラストラクチャ保護 (Infrastructure Protection)

• ネットワーク保護: VPC、セキュリティグループ、WAFなどを用いてネットワーク境界を守る
• コンピューティング保護: OSのパッチ管理、脆弱性スキャン、コンテナセキュリティなどを実施する

⑤ データ保護 (Data Protection)

• データ分類: データの重要度（公開、社外秘、極秘など）を定義する
• 暗号化: KMSなどを利用し、保存データと通信データを暗号化する。バックアップデータの保護も含む

⑥ インシデント対応 (Incident Response)

• 準備: 連絡網や対応ツールの整備
• 運用: 自動化されたプレイブックを用いて、検知から封じ込め、復旧までを迅速に行う
• 学習: インシデント後の振り返り（ポストモーテム）を行い、プロセスを改善する
• アプリケーションセキュリティ (Application Security)
• 開発ライフサイクル全体にセキュリティを組み込む（Shift Left）
• 定期的なセキュリティテスト（SAST/DAST）を実施する

// Geminiの要約 ココまで

---

セキュリティ実装のポイント：4+1

いかがでしょうか。セキュリティを設計し、実装するポイントは、以下の 4点+1 に集約されるのではないか、と私は考えました。

1. アクセス管理：最小権限の法則に基づいた、認証と認可の管理
2. 防御：ネットワーク、データ、アプリケーション、それぞれのレイヤーで保護と防御を実装する、多層防御の考え
3. 検知：ログや監視から異常を即時に検知し、通知する仕組みづくり
4. 対応：インシデントの検知〜封じ込め〜復旧〜ポストモーテムまでの流れを設計
5. 学習：ポストモーテムによる改善、セキュリティテスト等によるインシデント対応シミュレーションの実施

カオスエンジニアリングの視点で、擬似的にインシデントを起こして、検知〜封じ込め〜復旧をトレーニングすることも出来ます。しかしながら、本番環境でそんなことをやったら始末書もの(それ以上になっちゃうリスクも汗)だし、開発環境で起こすにしても、それ相応の周到な準備が必要になります。

でも、安心してください。AWS BuilderCardsなら、封を開けたその場で、机上でトレーニングが出来ます。

AWS BuilderCards とは

AWS BuilderCards(以下、BuilderCards)は、ボードゲーム形式で、AWS Well-Architected フレームワークを学習するためのツールです。大きく分けると、①基本パック と ②拡張パック の2種類に分類されます。

基本パック

基本パックはベースのゲームで、オンプレミスからクラウドリフト・クラウドシフトする過程を通して、Well-Architected フレームワークに則ったアーキテクチャを学習する事ができます。現在第1版と第2版の2バージョンがリリースされています。今回re:Inventで手に入るのは、第2版になります。

拡張パック

一方、拡張パックは、ベースのゲームにアドオンする形で、特定の領域を学習する事ができます。拡張パック単体でプレイすることはできません。拡張パックはこれまでに、生成AI(基本パック第1版の拡張パック)、レジリエンス(基本パック第2版の拡張パック)の2つをリリースしています。今回ご紹介する「セキュリティ拡張パック」は、この拡張パックの新作、という位置づけです。先程「カオスエンジニアリング」について少し触れましたが、レジリエンス拡張パックは、まさにこのカオスエンジニアリングを机上で体験できる拡張パックとなっております。

同時に、「Builder's Galore Expansion」という拡張パックも、今年のre:Invent会場でお披露目されます。Builder's Galoreは、最初からクラウドネイティブのシステムをビルドできる拡張パックです。オンプレミスからのクラウドシフトを考慮する必要がない分、よりゲーム性が高くなっています。個人的には「つよくてニューゲーム」だと思っています。

なぜ日本語版を開発したのか

もともとBuilderCardsは、ドイツAWSでGame techのSolution Architectをされている、David Heidtさんが開発しました。彼が2023年のre:Inventで紹介していたのを、日本から参加したAWS Heroが目にし、日本で広めるなら日本語化したいね、ということで、日本語版の開発を、原作者Davidや多くのコミュニティーの皆さんと協力して、進めてきました。

日本語化に込めた思いは、AWS Hero山口さんが執筆された記事や、過去の私たちの登壇資料をご覧ください。

基本的な遊び方

基本的な遊び方＝基本パックの遊び方については、数多くのブログで既にご紹介頂いているので、当記事では割愛させて頂きます。気になる方は、AWS公式ブログをご覧ください。

セキュリティ拡張パックで学ぶ、AWSセキュリティの基本の「き」

さて、ここからようやく本題です。ここまで読んで頂いて、ありがとうございます。先程、セキュリティ実装のポイントを「4+1」と説明しました。今回リリースされるセキュリティ拡張パックでは、この「4+1」の考え方に沿って、ゲームが設計されています。

セキュリティの脅威を正しく理解しよう

セキュリティの世界では、サイバー攻撃を実行する主体を「脅威アクター(Threat Actor)」と呼びます。セキュリティ拡張パックでは、4種類の動物が脅威アクター＝「ペットアクター」となって、プレイヤーが手札からビルドしたAWS環境を攻撃(いたずら)します。それぞれの動物を紹介しましょう。

ポリー・パケット(小鳥)：ネットワーク&インフラストラクチャー

ポリー・パケットは、ネットワークとインフラをいたずらするのが大好きな動物です。

かつてネットワークエンジニアの相棒として、数え切れないトラブルシューティングの通話を聞きながら、プロトコルのすべてを学んだ。今では、その知識を使ってネットワーク防御を探り、フレーズの代わりにパケット送信を繰り返す。「Pretty Payload!」と言いながらDDoS攻撃を繰り出すことで有名。弱点を見せるには、ときにネットワークを圧倒する必要があると信じている。

ゼロデイ・アライグマ：アプリケーション&ランタイム

ゼロデイ・アライグマは、アプリケーションとランタイムをいたずらするのが大好きな動物です。

開発者が捨てたコードの印刷物を、ダンプスターで漁るところから始まり、ゼロデイ・アライグマは他の誰も見逃していた脆弱性を見つける才覚を開花させた。夜に活動し、アプリケーションをテストしては、点在するコーヒーカップとキーボードの隙間のパンくずをのこしつつ、緻密なバグレポートを置いていく。「ゴミ箱は　 trash can (できる) であって、trash can’t (できない) じゃないのさ！」

インサイド・キャット：データ

インサイド・キャットは、データセンターとデータベースをいたずらするのが大好きなニャンコです。

データセンターのネズミ捕り猫としてキャリアを始めたが、やがて「ネズミ」より「データ」を捕まえることに関心が移った。システム同士のはざまに静かに座り込み、自分にデータが傍受できるなら他人にもできると証明してみせる。玄関先に露出データという「おみやげ」を残すことで知られる。お気に入りの昼寝場所は、最重要サーバーの真上。

バッド・ドッグ：アカウントとIAM

バッド・ドッグは、認証・認可とアカウント管理をいたずらするのが大好き。イタズラなワンコです。

長年、警備員が弱いパスワードを使い、「今回だけ」と視覚情報を共有するのを見てきて、ついに我慢の限界に。元はK-9(警備犬)として訓練されたが、今では認証システムを壊して「おやつ(treat)... いや、脅威(threat)...」がどれほど簡単に入り込めるかを示すことを専門とする。尻尾を振る愛想のよい顔を、人間がつい信用してしまうのは彼のせいだろうか？モットーは「悪い子は誰だって？俺さ… でも”正しい理由”のためにね！」

ペットアクターは、アクセス管理と防御に対する、脅威アクターである

ここまで読んで「ハッ」と気づかれたそこのあなた！流石です。動物たちは「4+1」の最初の2つ、アクセス管理と防御に対する、脅威アクター＝ペットアクターなのです。彼らペットアクターに対して、プレイヤーはどのように検知と対処をすべきか、次の項で説明します。

ペットアクターのいたずらを、AWSのセキュリティサービスで検知・対応せよ

現実世界において、AWSのセキュリティサービスには、脅威を検知(DETECTION)し、対応(RESPONSE)するサービスが数多く提供されています。

• DETECTION（検知）： 潜在的な脅威を発見する
• RESPONSE（対応）： 修正または予防のためのアクションを取る

つまり、セキュリティの脅威に対峙するためには、

①脅威を見える化して、いつでも発見できる状態にし、
②実際に脅威を発見した際に、その脅威に対抗する手段が取れている

この二つが肝要である、ということです。セキュリティ拡張パックでも、ペットアクターのいたずらを解消するためには、検知と対応の両方が出来ている状態にあることが望ましいでしょう。

セキュリティ拡張パックには、こうしたセキュリティサービスのビルダーカードが含まれてます。これらのビルダーカードが、プレイヤーがビルドしたアーキテクチャに含まれている場合、ペットアクターのいたずら(脅威と攻撃)を検知 または 対応することで、影響を小さくしたり、回避できたりできる場合があります。

ここでAWSのセキュリティサービスを一つずつ紹介したいところですが、これ以上長くなってしまうと申し訳ないので、代わりにAWSのホワイトペーパーを読んで、学習しましょう！

ペットアクターのいたずらと、検知・対応の一例

ペットアクターのいたずらは、プレイヤーがCloud-Adoption(購入)フェーズで、Well-Architected ポイントカードを購入するときに発生します。

写真はポリー・パケットが起こす、いたずらの一例です。セキュリティ拡張パックではこうしたいたずらを「イベントカード」と呼びます。

イベントカードは上から、

• イベントの名称
• イベントの内容＝いたずらの内容
• DETECTION
• RESPONSE
• IMPACT

の順に書いてあります。ここで注目してほしいのは、下の3つ、DETECTION・RESPONSE・IMPACT です。

現実世界でも、セキュリティ拡張パックでも、脅威(ペットアクターのいたずら)を解消するには、検知と対応の両方が肝要、と先に書きました。セキュリティ拡張パックでは、プレイヤーがビルドした手札の中に、DETECTIONまたはRESPONSEに記載されているサービスの、ビルダーカードが必要になります。

このイベントカードを例に取ると、

• このイベントを検知(DETECTION)するには、Amazon CloudWatch が必要
• このイベントに対応(RESPONSE)するには、以下のいずれかが必要
  • AWS Shield Advanced
  • AWS Network Firewall
  • Amazon EventBridge ＋ AWS Lambda
• ※箇条書きのリストはOR条件です
• ※ "+" はAND条件を意味します

ということです。

そして、その下のIMPACTは、このいたずらに対する結果が記載されています。これはプレイヤーがビルドした手札の中に、検知または対応に対応するカードが含まれていたかどうか、で結果が変わる仕組みです。このイベントカードを例に、ポリー・パケットのいたずらに対する結果を見てみましょう。

• ❌ = DETECTION と RESPONSE どちらも無い場合、PWNEDカードを一枚取る
• = DETECTION と RESPONSE のどちらか一方だけ含まれている場合、次のターンでは手札が4枚になる(通常は5枚)
• ✅ = DETECTION と RESPONSE の両方とも含まれている場合、Cloud-Adoption(購入)をもう1回できる

PWNED!! ペナルティは？

pwnとは、CTF(Capture the Flag)という、サイバーセキュリティの技術を競うコンテストで出題されるカテゴリーの一つです。アプリに仕組まれた脆弱性をとっかかりに、サーバーを乗っ取ってフラグを獲得する課題が出されます。

pwnにはもう一つの意味があります。それはネットゲームのスラングで「打ち負かす」という意味です。
どちらにせよ、PWNED = PWNされた、ということは、乗っ取られた、あるいは、ペットアクターに打ち負かされた、という意味が込められている、と筆者は考えています。

セキュリティ拡張パックでは、検知と対応の両方とも出来なかった場合に、ペナルティとして獲得するのが、PWNEDカード です。このカードを獲得してしまうと、それまでに獲得した Well-Architected ポイントが1点減点されるので、ご注意ください。またイベントによっては、PWNEDカードを一度に2枚獲得してしまう場合もあります。

学習しよう - BuilderCardsとセキュリティ拡張パックで、あなたの環境を危険に晒すことなく安全に

「4+1」の最後のピース＝「学習」です。

BuilderCardsはゲームではなく、学習ツールである

BuilderCardsは、ある種のボードゲーム要素があり、ゲームのルールを知ってしまえば、一定楽しめる設計となっています。しかしながら、日本語版開発者として推奨するのは、基本パックでいえばWell-Architected フレームワークを、拡張パックであればそのパックがカバーする技術領域を、それぞれ基本をまずは学習されてから、プレイすることをオススメしています。セキュリティ拡張パックは、セキュリティの基本レベルの知識を必要としています。セッションレベルでいうと、Level 200〜300くらいになると、筆者は見ています。

これからAWSを、そしてセキュリティを経験を積むために、BuilderCardsをプレイしたいという方は、まずはぜひゲームで紹介されている技術を学習してみてください。その後にBuilderCardsをプレイし、仲間とアーキテクチャについて議論することは、アウトプットにも繋がります。インプットとアウトプットを繰り返すことで、

ここでは、筆者の独断と偏見で探した、セキュリティの基本を学習できるコンテンツをご紹介します。

セキュリティ拡張パックのルールブックを公開しました

私も運営に参加しているJAWS-UG千葉支部で、re:Inventに合わせて、セキュリティ拡張パックのルールブックを作成しました。

今回はセキュリティの基本を押さえていただくために、BuilderCardsやセキュリティ拡張パックのルールはあまり詳しく書けなかったのですが、ラスベガス現地でもルールブックを公開していますので、ぜひセキュリティ拡張パックを入手して、このルールブックと一緒に、セキュリティの脅威・検知・対応を学習されることを心待ちにしております。

BuilderCardsやセキュリティ拡張パックは日本でも手に入るのか？

結論、日本のAmazonでは手に入らないが、JAWS-UGのイベントで頒布されることがある。

海外では、BuilderCards基本パックを、Amazonで購入できる国も増えてきましたが、日本では投稿時点においては、まだAmazonで販売されていません。

しかしながら、JAWS-UGが開催するBuilderCards体験会で、頒布されることもありますので、ぜひJAWS-UGの各種SNSをフォローしてみてください。イベントの予定は、JAWS-UGやAWSコミュニティマネージャーのSNSで確認できます。

• X：@jawsdays
• JAWS-UGイベントカレンダー
• AWSコミュニティマネージャー 沼口さんの note