クレデンシャル流出 ― 攻撃 3 時間 vs 復旧 10 時間。この非対称性にどう備えるか

2026年6月25日の AWS Summit Japan 2026 Builder Community Lounge でチョークトーク登壇した際の資料です

AWS さんにチェックいただいたそのままを上げていますので、本来追加したほうがいいところもそのままにしています（25ページ目の CodeGuru Reviewer は新規受付が止まっています）

Transcript

1. クレデンシャル流出 ― 攻撃 3 時間 vs 復旧 10 時間。 この非対称性にどう備えるか AWS Summit Japan 2026 Builder Community Lounge (June 25, 2026) Speaker : @kazzpapa3(ICHINO Kazuaki) / Serverworks Co., Ltd.
2. 目次 導入：実際の流出事例と被害規模の紹介 話題提起：「あなたの組織ではどう守っていますか？」 チョークトーク本編：ホワイトボードで整理しながら議論 対策のまとめと AWS サービスを活用したベストプラクティス クロージング
3. Biography { "Bio": { "Name": "ICHINO Kazuaki a.k.a. kazzpapa3", "Organization": [ "Serverworks Co., Ltd.", "JAWS-UG Kobe", "AWS Community Builder(Cloud Operations)" ], "Role": "Technical Support Engineer", "Favorite AWS Services": [ "AWS CLI", "AWS CloudTrail", "Kiro CLI" ], "Personal Interest": "初音ミク", "Socials": { "Twitter/X": "@kazzpapa3", "LinkedIn": "https://www.linkedin.com/in/kazzpapa3/" } } }
4. そもそもチョークトークとは？ @kazzpapa3 / #AWSSummit2026 4 / 35
5. 進め方や心構えなど チョークトークは対話型のセッションで学校の授業やゼミに近いもので す 今回のテーマ的にベストプラクティスはありますが、正解はありません 正解があるわけではないので積極的にご発言ください ただし AWS コミュニティのブースであるので、JAWS-UG のルールと マナー に則って、建設的で前向きなご発言をお願いします さまざまな立場のみなさまからの多角的な意見や知見が活発に飛び交う ことを期待しています @kazzpapa3 / #AWSSummit2026 5 / 35
6. 導入：実際の流出事例と被害規模の紹介 @kazzpapa3 / #AWSSummit2026 6 / 35
7. そもそもあなたは誰？ / 登壇者のバックボーン エンドカスタマー – リセラー事業者 – AWS の三者の関係性の中間に位 置し、AWS からアカウントを仕入れてエンドカスタマーに再販してい る立場です AWS との契約関係にあるのはリセラー事業者となるため、エンドカス タマーは直接 AWS とのパスを持っていない ことになります そのためリセラー事業者がサポート体制を構築し、エンドカスタマーの 問い合わせに応対する責務があります 上記の関係性から、私の立場はエンドカスタマーと AWS の 中間地点の やや AWS に肩入れする位置 にいます @kazzpapa3 / #AWSSummit2026 7 / 35
8. アクセスキーが流出したような事例では 前述の通り、エンドカスタマーは直接 AWS Support への連絡パスを持 たないので我々リセラー事業者が仲介します その関係上、AWS 通知から流出キーの特定、封じ込め、フォレンジッ ク調査の行く末を多くみています JAWS DAYS 2026 でも登壇機会をいただくなど、アクセスキー流出に ついて昨今の攻撃手法などの紹介もしつつ、どのようなことが起こるか などお話ししました 関西のコミュニティ中心ですが、AWS CloudTrail を用いた調査手法や アクセスキー撲滅のための啓蒙を少しずつ進めています @kazzpapa3 / #AWSSummit2026 8 / 35
9. どのような事例があるか @kazzpapa3 / #AWSSummit2026 9 / 35
10. 私が見たおそらく最悪のシナリオ 1 1. IAM ユーザーのログインプロファイルの削除や、新たな IAM リソース の作成など「目に見えてわかりやすい」リソース作成の裏側で AWS Organizations のメンバーアカウントである場合に付随的に作成される IAM ロールのスイッチロール元の AWS アカウント ID を書き換えられ てバックドアを仕込まれていた 2. 「目に見えてわかりやすい」リソースの削除が完了し、ほっとした頃合 いで、バックドア経由で再侵入され て複数回の犯行を行われた 3. 利用料高騰につながったのは典型的な CryptoMining（暗号通貨採掘） 目的のコンピュートリソースの不正利用 @kazzpapa3 / #AWSSummit2026 10 / 35
11. 私が見たおそらく最悪のシナリオ 1 AWS Account 不正利用 ②③ 新規作成 ①削除 ④改変 ①削除 不正入手 利⽤ このロールは AWS Organizations 管理アカウントからメン バーアカウントを発行した際にデフォルトで作成されるロー ル 通常、管理アカウントが AssumeRole の引き受け元となるよ うに払い出されます AWS Account 不正利用 ②新規作成 犯⾏者所有のアカウント ①スイッチロール ③利⽤ アクセス 第１波 第２波 @kazzpapa3 / #AWSSummit2026 11 / 35
12. 私が見たおそらく最悪のシナリオ 2 1. AWS 通知が行われたタイミングで、のちに 4,000 リソースを乱立する ことになる 自動起動のための仕込みが完了していた 2. つまり緊急通知がされたタイミングで、利用料の高騰が始まっていた 3. この時も、利用料高騰につながったのは典型的な CryptoMining（暗号 通貨採掘）目的のコンピュートリソースの不正利用 @kazzpapa3 / #AWSSummit2026 12 / 35
13. 私が見たおそらく最悪のシナリオ 2 攻撃者は 約 17 分 でリソースの自動起動の仕込みを完了 弊社側の削除作 業に 合計約 4 時間 要した例があります なお削除対象リソースの把握にはさらに 3.5 時間ほど要しています リソース 作成（攻撃者） 削除（対応者） 作成数 Auto Scaling Group 約 13 分 約 7 分 約 300 個 Amazon SageMaker Notebook 約 13 分 約 19 分 約 150 個 Amazon ECS Cluster 約 12 分 約 2 時間 24 分 約 2,700 個 Amazon EC2 Instance ASG 配下・継続起動 約 1 時間 約 1,000 台 @kazzpapa3 / #AWSSummit2026 13 / 35
14. どちらの事例も AdministratorAccess がついていた シナリオ 1 の例では、バックドアからの侵入後、再度 IaC 化した仕組 みでリソースの乱立が行われた シナリオ 2 の例でも、 AWS Trust & Security の検知の時点で IaC 化 した仕組みでリソースの乱立が行われた 言葉のチョイスが適切でないことは承知ですが、犯行者は「ちゃんと」 IaC を利用して効率的にリソースを乱立し、最短距離で目的を果たすた めの行動をしている @kazzpapa3 / #AWSSummit2026 14 / 35
15. 話題提起： 「あなたの組織ではどう守っていますか？」 @kazzpapa3 / #AWSSummit2026 15 / 35
16. チョークトーク本編： ホワイトボードで整理しながら議論 @kazzpapa3 / #AWSSummit2026 16 / 35
17. 1. どこから漏れるのか ― 流出経路の全体像 @kazzpapa3 / #AWSSummit2026 17 / 35
18. 用意していた選択肢 Git リポジトリへのハードコード（パブリック／プライベート問わず） CI/CD パイプラインのログ・環境変数 .env ファイル、Docker イメージ内の埋め込み 退職者・委託先からの持ち出し ローカル PC の ~/.aws/credentials の管理不備 @kazzpapa3 / #AWSSummit2026 18 / 35
19. 2. 漏れたら何が起きるのか ― 攻撃と復旧の時間差 @kazzpapa3 / #AWSSummit2026 19 / 35
20. 用意していた選択肢 暗号通貨マイニング、データ窃取、ランサムウェアの踏み台 初動対応として、鍵の無効化 → 影響範囲特定 → フォレンジック すれ ば良いのだが… 攻撃者の行動タイムライン：GetCallerIdentity → IAM ユーザー/キ ー作成 → リージョンオプトイン → 4,000超リソース乱立（3時間以 内） 防御側の現実：検知 → 無効化 → 一覧化(2h) → 削除(10h)、その間 も課金は止まらない @kazzpapa3 / #AWSSummit2026 20 / 35
21. 用意していた選択肢 「キーを無効化すれば終わり」ではない 被害額の拡大に対して、復旧完了までの時間と被害額の相関がある @kazzpapa3 / #AWSSummit2026 21 / 35
22. 3. 漏れる前に何をするか ― 予防 + 復旧時間を短くする設計 @kazzpapa3 / #AWSSummit2026 22 / 35
23. 用意していた選択肢 IAM ロール／一時クレデンシャルへの移行 AWS Secrets Manager / Parameter Store の活用 git-secrets, GitHub Secret Scanning, Amazon CodeGuru Reviewer AWS GuardDuty による異常検知、AWS CloudTrail + Amazon Athena による監査 IAM Access Analyzer による最小権限の継続的検証 OIDC フェデレーション（GitHub Actions → IAM ロール等） @kazzpapa3 / #AWSSummit2026 23 / 35
24. 用意していた選択肢 被害を局所化する事前設計 未使用リージョンのオプトアウト SCP によるリージョン・サービス制限 削除手順のランブック化・自動化の検討 「避難訓練」の実施（JAWS DAYS で話した内容の発展） @kazzpapa3 / #AWSSummit2026 24 / 35
25. Appendix: 想定問答集 @kazzpapa3 / #AWSSummit2026 25 / 35
26. Q1.「長期クレデンシャルを完全にゼロにするのは現 実的ですか？」 理想はゼロですが、サードパーティ SaaS 連携など IAM ロールが使えな いケースは残ります。 その場合は Secrets Manager でローテーションを自動化し、有効期限を 短くすることでリスクを最小化します。 AWS は 2024 年にルートアクセスキーの集中管理機能も追加しており、 Organizations レベルで長期キーの作成自体を制限できます。 @kazzpapa3 / #AWSSummit2026 26 / 35
27. Q2.「GitHub に漏らしてしまった場合、最初にやる べきことは？」 1. 即座に IAM コンソールまたは CLI でキーを無効化（削除ではなくまず 無効化） 2. CloudTrail でそのキーによる API コールを確認し影響範囲を特定 3. 不正リソース（EC2, AWS Lambda 等）の停止・削除 4. 新しいクレデンシャルの発行と該当システムの更新 5. ポストモーテムで再発防止策を策定。Git の履歴からも消す必要がある 点を忘れがち（ git filter-repo 等）。 @kazzpapa3 / #AWSSummit2026 27 / 35
28. Q3.「GuardDuty はクレデンシャル流出をどう検知 するのですか？」 GuardDuty は CloudTrail の API ログと VPC Flow Logs 等を分析し、 普段と異なるリージョンや IP からの API コール、Tor 経由のアクセスな どを検知します。 たとえば UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS は EC2 のインスタンスクレデンシャルが外部から使われた場合に発火しま す。 @kazzpapa3 / #AWSSummit2026 28 / 35
29. Q4.「CI/CD パイプラインでのベストプラクティス は？」 GitHub Actions なら OIDC フェデレーションで IAM ロールを直接 Assume し、アクセスキーをシークレットに保存すること自体をやめるの がベスト。 AWS CodeBuild なら実行ロールに必要最小限のポリシーを付与するだけ で済みます。 ログにクレデンシャルが出力されないよう、マスキング設定も確認してく ださい。 @kazzpapa3 / #AWSSummit2026 29 / 35
30. Q5.「小さいチームでもここまでやる必要があります か？」 むしろ小さいチームほど一人の漏洩が致命的。 最低限やるべきことは 3 つ： 1. MFA の全ユーザー有効化 2. 長期アクセスキーの廃止（IAM Identity Center の利用） 3. GuardDuty の有効化（無料トライアルあり） この 3 つだけでリスクは大幅に下がります。 @kazzpapa3 / #AWSSummit2026 30 / 35
31. Q6.「検知から対応までを自動化できますか？」 はい。GuardDuty の Finding → Amazon EventBridge → Lambda（ま たは AWS Step Functions）で、キーの自動無効化や Slack 通知を組め ます。 ただし自動無効化は正常な処理も止めるリスクがあるため、まずは通知か ら始めて、確信度の高い Finding のみ自動対応にするのが現実的です。 @kazzpapa3 / #AWSSummit2026 31 / 35
32. Q7.「Secrets Manager のコストが気になります」 1 シークレットあたり月額 $0.40 + API コール 10,000 回あたり 0.05 USD アクセスキー流出によるインシデント対応コスト（人件費・被害額）と比 較すれば桁違いに安い。 Parameter Store の SecureString（無料枠あり）も選択肢になります。 @kazzpapa3 / #AWSSummit2026 32 / 35
33. Q8.「リージョンをオプトアウトしておけば被害を防 げますか？」 デフォルトで有効なリージョン（東京、バージニア北部など）はオプトア ウトできないため完全な防御にはなりません。 ただし、オプトインが必要なリージョン（ジャカルタ、ハイデラバードな ど）を事前にオプトアウト状態のままにしておくことで、攻撃面を縮小 し、復旧対象のリージョン数を減らせます。 SCP と組み合わせるのが効果的です。 @kazzpapa3 / #AWSSummit2026 33 / 35
34. Q9.「4,000リソースの削除に10時間もかかるのは なぜですか？」 リソース間の依存関係（セキュリティグループを参照する ENI、ENI を持 つ EC2 など）があり、削除順序を間違えるとエラーになります。 また全リージョンを対象にマネジメントコンソールで1つずつ確認・削除 するのは現実的でなく、CLI でのスクリプト作成自体にも時間がかかりま す。 事前にランブックを用意しておくことで大幅に短縮可能です。 @kazzpapa3 / #AWSSummit2026 34 / 35
35. Have pride in your work. Thank you.