Slide 1

Slide 1 text

「遊んで終わり」にさせない! AWS BuilderCards セキュリティ拡張パックで実装する、組織の脅威検知カルチャーとアーキテクチャ @coosuke AWS Community Builder AWS BuilderCards 日本語版開発者 Security-JAWS DAYS

Slide 2

Slide 2 text

アジェンダ 01 AWS Well-Architected Frameworkとセキュリティ W-Aの概要・セキュリティの柱・実装の「 4+1」ポイント 02 BuilderCards セキュリティ拡張パックとは ペットアクター・ゲームメカニクス・検知と対応の仕組み 03 盤上のロジックをクラウドへ カードを現実のAWSアーキテクチャにマッピングする 04 組織カルチャーへの実装と結び 共通言語・Takeaway・Call to Action Security-JAWS DAYS

Slide 3

Slide 3 text

このセッションで話すこと・話さないこと ● AWS BuilderCardsセキュリティ 拡張パックの紹介 ● AWS BuilderCardsと Well-Architected Framework の関係(特にセキュリティ ) 話すこと ✅ ● AWSセキュリティサービスごとの 詳細な説明 ● AWS BuilderCards 基本パック の詳細なルール説明 話さないこと 🚫 Security-JAWS DAYS

Slide 4

Slide 4 text

$ whoami { "Name": "Kosuke Enomoto", "SNS": "@coosuke", "Job": "Scrum Master of Cloud, Global Infra", "Communities": [ "Organizer, JAWS-UG Chiba", "AWS Community Builder (Serverless)", "AWS BuilderCards JP Authorizer" ], "My Family": [ "Wife", "Black cat (5yo)", "Kid (4yo)" ], "Hobbies": [ "Sauna", "Cooking", "Photo" ] } Security-JAWS DAYS

Slide 5

Slide 5 text

AWS Well-Architected Framework クラウドのベストプラクティス集 個々の事情に左右されない、普遍的で汎用度の高い設 計・実装のガイドブック。強制力はないが、則ってビルド することでROIの高いシステムを実現できる。 運用上の優秀性 セキュリティ 信頼性 パフォーマンス効率 コスト最適化 持続可能性 クラウド各社の W-Aフレームワーク AWSに限らず、各社がWell-Architectedフレームワー クを公開しており、基本は同じ。読み比べると大変面白 い。 AWS Well-Architected Framework 6本の柱 Google Cloud Architecture Framework 6つの原則 Azure Well-Architected Framework 5本の柱 Security-JAWS DAYS

Slide 6

Slide 6 text

セキュリティの柱 クラウドセキュリティの「 7つの領域」 Security-JAWS DAYS セキュリティイベントの準備 管理ポリシー導入、対応シミュレーション実行、自動化 クラウドのセキュリティ設計原則 強力なアイデンティティ基盤を実装する 最小特権・職務分離・一元管理・静的認証情報の排除 トレーサビリティの維持 リアルタイム監視・監査、ログとメトリクス収集の自動化 すべての層にセキュリティを適用する ネットワーク、データ、アプリ、コードなどでの多層防御 セキュリティのベストプラクティスの自動化 コード化されたテンプレートによる安全なアーキテクチャ実装 転送中・保管中のデータの保護 機密レベル分類、暗号化、トークン化、アクセス制御 人をデータから遠ざける 直接アクセスや手動処理の排除による人的ミスのリスク軽減 セキュリティ基盤 AWSアカウント管理と分離、ワークロードの安全な運用 Identity and Access Management ID管理、アクセス許可の管理 検出 予期しない、望ましくない設定変更の検知、想定外の動作の検知 インフラストラクチャの保護 多層防御、ネットワークやコンピューティングの保護 データ保護 機密レベルに応じた分類、暗号化、アクセス制御 インシデントへの対応 検出 → 分析 → 封じ込め → 根絶 → 復旧 → ポストモーテム アプリケーションのセキュリティ DevSecOpsの設計、実装、運用

Slide 7

Slide 7 text

セキュリティの柱を具体化する、 4+1メソッド セキュリティ実装の「 4+1」ポイント 1 アクセス管理 最小権限の法則に基づく認証・認可の管理 2 防御 NW・Data・Appの各レイヤーの多層防御 3 検知 ログや監視から異常を即時検知し通知する仕組み 4 対応 検知〜封じ込め〜復旧〜ポストモーテムの設計 +1 学習 ポストモーテム改善・インシデント対応シミュレーション Security-JAWS DAYS

Slide 8

Slide 8 text

The Gap — 抽象と具象のギャップ W-Aが言うこと(抽象) 「発見的統制を実装せよ」 「インシデント対応を自動化せよ」 「最小権限の原則を適用せよ」 「すべてのレイヤーでセキュリティを適用せ よ」 ? 現場が思うこと(具象への壁) 「具体的にどのAWSサービスを使えばいい?」 「どう自動化すれば良い?」 「最小権限を満たすIAMポリシーとは?」 「自分のシステムで本当に機能するか?」 抽象的なW-Aの言葉を、具体的なAWSサービスの組み合わせに脳内変換するコストは非 常に高い Security-JAWS DAYS

Slide 9

Slide 9 text

AWS BuilderCards Security-JAWS DAYS

Slide 10

Slide 10 text

AWS BuilderCards : 要はどんなゲームかというと Security-JAWS DAYS ● AWSのサービスを表すカードを自分の手札に集める ● 自分の手札に集めたAWSサービスのカードでアーキテクチャをビルド してクレジット得る ● クレジットを使ってWell-Architectedポイントを獲得する ● Well-Architectedポイントカードがなくなるか、あらかじめ設定した制 限時間が来たらゲーム終了で、ゲーム終了時点で獲得した Well-Architectedポイントが一番多い人が勝ち

Slide 11

Slide 11 text

AWS BuilderCards : セキュリティ拡張パックの概要 Security-JAWS DAYS ● AWSサービスのカードが追加になりました ● Well-Architectedポイントを獲得する際にサイコロを振ってペットアク ターの攻撃(セキュリティインシデント)を受ける ● ビルドしたアーキテクチャを利用してDetect、Response判定を行う (AWS Security Hub+AWS LambdaはどれでもResponse OK判定) ● 判定に失敗した場合にペナルティあり 成功するとベネフィットあり(ベネフィットは次のターンに有効)

Slide 12

Slide 12 text

脅威アクターとして振る舞う、 4匹のペットアクター達 Security-JAWS DAYS ポリー‧パケット ネットワーク&インフラ ゼロデイ‧アライグマ アプリケーション &ランタイム インサイド‧キャット データ保護 &プライバシー バッド‧ドッグ アカウント管理 (認証‧認可) ペットアクターの好物は、 4つのレイヤーに分かれている

Slide 13

Slide 13 text

4つのレイヤーの 多層防御 — マッピング全体像 ※ 以下に記載の AWSサービスは代表的な例です。実際には多くのサービスが組み合わせて使われます。 脅威レイヤー / ペットアクター DETECTION(例) RESPONSE(例) バッド・ドッグ アカウント & IAM Amazon GuardDuty AWS CloudTrail AWS IAM AWS IAM AWS Secrets Manager AWS Config ポリー・パケット ネットワーク & インフラ Amazon CloudWatch Amazon VPC AWS CloudTrail AWS Network Firewall AWS Shield Advanced Amazon Route 53 インサイド・キャット データ & ストレージ Amazon GuardDuty AWS CloudTrail Amazon CloudWatch AWS Config Amazon S3 AWS KMS ゼロデイ・アライグマ アプリ & ランタイム Amazon CloudWatch Amazon GuardDuty Amazon Inspector AWS WAF Amazon Detective AWS Fargate Security-JAWS DAYS

Slide 14

Slide 14 text

ペットアクターのいたずらへの対抗策 - 検知+対応 W-Aでいう「発見的統制」と「インシデント対応」が、手で触れるカードになった DETECTION(検知) 潜在的な脅威を早期に発見する 不正アクセスの兆候を検出 設定ミスや脆弱性の発見 通常と異なるAPIコール検知 + RESPONSE(対応) 修正または予防のアクションを取る 不正アクセスの遮断・隔離 IAMポリシーの緊急修正 データ漏洩時の即時ブロック Security-JAWS DAYS

Slide 15

Slide 15 text

検知 or 対応 出来なかった時のペナルティ = PWNED Security-JAWS DAYS ペナルティが発生すると、 手元のWell-Architectedポイントから、 1点減点 他、ペットアクターのいたずらによって次の ターンで制約が色々あり

Slide 16

Slide 16 text

盤上の試行錯誤 = アーキテクチャ設計のシミュレーション Security-JAWS DAYS 何が問題か、考えてみるニャ? そのS3バケットは単にパブリックだっただけではな く、顧客の連絡先情報と支払履歴がぎっしり詰まっ ていました。ニャンコはハックするまでもなく、ただ バケットを眺めるだけで個人情報にアクセスできま した。 ニャンとも壊滅的な データ漏洩

Slide 17

Slide 17 text

プレイヤーの思考 = アーキテクトの思考 ゲーム中の思考 「インサイド・キャットが来た。 どのカードで防ぐ?」 「Amazon GuardDuty または AWS CloudTrailがDETECTIONに使える!」 「RESPONSEは、AWS Config、Amazon S3、 AWS Organizationsのいずれかが必要」 「両方揃えた! Cloud-Adoption追加ゲット!」 = 同じ 問い アーキテクト設計の思考 「データ漏洩リスクに対して どう設計する?」 「Amazon GuardDutyと AWS CloudTrailでS3の異常を検知する」 「AWS ConfigとAmazon S3ポリシーで パブリック公開を自動修正する」 「検知から対応までの 自動化パイプラインが完成した」 Security-JAWS DAYS

Slide 18

Slide 18 text

DETECTION 検知への翻訳 — インサイド・キャットを発見する 【盤上】 Amazon GuardDutyカード / AWS CloudTrailカード → 【クラウド】 具体的なサービスへのマッピング Amazon GuardDuty Amazon GuardDuty(S3 Protection) S3バケットへの不審なAPIコール(異常なGetObject・DeleteObjectの大量発生等)を機械学習で分析し、 データ漏洩・破壊の予兆を自動検知。CloudTrailのログをリアルタイムに解析する。 AWS CloudTrail AWS CloudTrail(データイベント有効化) S3バケットの全操作(GetObject / PutObject / DeleteObject)の完全な監査ログを記録。誰が・いつ・どのオ ブジェクトに・どのIPからアクセスしたかをトレース可能にする。 Security-JAWS DAYS

Slide 19

Slide 19 text

RESPONSE 対応への翻訳 — インサイド・キャットを封じ込める 【盤上】 Amazon S3カード / AWS Configカード → 【クラウド】 具体的なサービスへのマッピング Amazon S3 Amazon S3(パブリックアクセスブロック) S3バケットのパブリックアクセスを組織レベルで強制ブロック。AWS OrganizationsのSCPと組み合わせるこ とで、全アカウントにわたって意図しない公開設定を防ぐ。 AWS Config AWS Config(自動修復ルール) S3バケットの設定コンプライアンスを継続監視。パブリックアクセスブロックが無効になった瞬間に検知し、 AWS Systems Manager Automationと連携して自動修復する。 AWS Organizations AWS Organizations(予防的統制、発見的統制によるガバナンス) SCPによるS3バケット公開の強制ブロックと、個人情報検知、全アカウントを横断した自動修復の仕組みを連 携させ、組織全体のセキュリティを一元的に統制。 Security-JAWS DAYS

Slide 20

Slide 20 text

盤上の試行錯誤 = アーキテクチャ設計のシミュレーション Security-JAWS DAYS 何が問題かニャ? ● S3バケットがパブリックアクセス可能 ● 顧客の連絡先情報(PII)が保管されている ● トランザクションの履歴が保管されている ニャンとも壊滅的な データ漏洩 データ漏洩を検知し、対応するために必要なサービスは? DETECTION ● Amazon GuardDuty ● Amazon CloudTrail RESPONSE ● AWS Config ● Amazon S3 ● AWS Organizations

Slide 21

Slide 21 text

インシデントレスポンスの完成 盤上の「ただのカードの組み合わせ」が、現実の AWS上では堅牢なパイプラインに翻訳された Security-JAWS DAYS 出典: https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/aspects-of-aws-incident-response.html

Slide 22

Slide 22 text

セキュリティの柱を具体化する、 4+1メソッド セキュリティ実装の「 4+1」ポイント 1 アクセス管理 2 防御 3 検知 4 対応 +1 学習 Security-JAWS DAYS 4匹のペットアクター DETECTION に対応したビルダーカード RESPONSE に対応したビルダーカード

Slide 23

Slide 23 text

BuilderCardsは「対面型の学習ツール」である 遊びの皮を被った、 AWSのベストプラクティスを 組織のカルチャーに焼き付けるための戦略的ツール 01 抽象から具象への翻訳 W-Aの難解な概念が手で触れるカードになる。頭で理解するのではなく、体で覚える。 02 安全な失敗体験 実環境リスクゼロで脅威シナリオと対応を体験。PWNEDの痛みが実際の設計ミスを防ぐ。 03 チームへのインストール 一人ではなくチーム全員が同じ体験を共有し、W-Aの概念が組織の共通言語になる。 Security-JAWS DAYS

Slide 24

Slide 24 text

Call to Action Security-JAWS DAYS 明日 Day 2 (CTF Day) AWS BuilderCards セキュリティ拡張パック 体験ブースを設置@ 21.002 Supported by JAWS-UG千葉支部

Slide 25

Slide 25 text

AWS BuilderCardsの今後の方向性について in Japan Security-JAWS DAYS ● メンテナンスモード (KTLOモード)へ移行 ○ 新規開発の凍結 ○ メンテナンスに専念 ● JAWS-UG Leaders有志でBuilderCards WGを立ち 上げ ○ ルールやガイドの更新と再整備 ○ 全国のBuilderCards体験会の支援 ○ 新しいアイデアの具現化 詳細は私のnoteにて AWS BuilderCardsを更に日本全国へ展開し、 Well-Architectedを啓蒙するフェーズ

Slide 26

Slide 26 text

Security-JAWS DAYS Thank you !!