アクセスキー流出時の対応で再認識した攻撃側と防御側の非対称性について

2026年8月26日に開催された Security-JAWS【第42回】で登壇した際の投影資料です。

攻撃側と防御側の労力や所要時間の観点から、攻撃を受けると如何に大変か、というお話をしました。
言いたかったことは「アクセスキーやめれ」ですが、そうもいかない現場・環境はあると思います。
まずは正しく怖がってベストプラクティスに沿った運用、特に最小権限をめざしていただけると良いかと思います。
#secjaws #secjaws42 #jawsug

Transcript

1. Security-JAWS (August 28, 2026) アクセスキー流出時の対応で再認識した 攻撃側と防御側の非対称性について Speaker : @kazzpapa3(ICHINO Kazuaki) / JAWS-UG 神戸
2. Biography { "Bio": { "Name": "ICHINO Kazuaki a.k.a. kazzpapa3", "Organization": "A certain AWS partner company", "Role": "Technical Support Engineer", "Favorite AWS Services": [ "AWS CLI", "AWS CloudTrail", "Kiro CLI" ], "Less Favorite Person (as a Support Engineer)": [ "アクセスキーを雑に扱うすべての人" ], "Personal Interest": "初音ミク", "Socials": { "Twitter/X": "@kazzpapa3", "LinkedIn": "https://www.linkedin.com/in/kazzpapa3/" } } }
3. 先に結論 @kazzpapa3 / #secjaws #secjaws42 #jawsug 3 / 36
4. アクセスキーやめれ、って言いたいけど 正しく怖がりましょう @kazzpapa3 / #secjaws #secjaws42 #jawsug 4 / 36
5. アクセスキーの流出に対応することが多々ありました これらを踏まえいくつかの登壇や、イベント開催をしました 支部・イベント JAWS DAYS 2026 クラメソおおさか IT 勉強会 Midosuji Tech AWS Community Builders Meetup 2026 JAWS-UG DE&I AWS麻雀で 楽しく 遊んで 学ぼう!! タイトルなど Abuse report だけじゃない。AWS から緊急連絡が来る状況とは？昨今の 攻撃や被害の事例の紹介と備えておきたい考え方について CloudTrail を見つめ直してみる 今年取り組んでみたいこと アクセスキー撲滅運動の旗振りかなぁ あまりにもアクセスキーの事故が多いので CTF のゲームを作った話 JAWS-UG 神戸 自作の CTF Game 大会開催 AWS Summit Japan 2026 Builder クレデンシャル流出 ― 攻撃 3 時間 vs 復旧 10 時間。この非対称性にどう Community Lounge 備えるか（チョークトーク） JAWS-UG 岡山 アクセスキーが漏れた日にやるべきこと - 無効化の先にある本当の対応
6. 今日は非対称性の話 AWS Summit Japan 2026 Builder Community Lounge で "クレデ ンシャル流出 ― 攻撃 3 時間 vs 復旧 10 時間。この非対称性にどう備 えるか" と題してチョークトークを実施しました その時事例でさらっと紹介したのですが、今回は防御側（アクセスキー 流出で被害を受ける側）が、如何に大変か？という観点からのお話です @kazzpapa3 / #secjaws #secjaws42 #jawsug 6 / 36
7. 概要 @kazzpapa3 / #secjaws #secjaws42 #jawsug 7 / 36
8. 被害の全体像 漏れたアクセスキーには AdministratorAccess がついていた 不正に作成されたリソースとそれぞれの所要時間 リソース 作成（攻撃者） 削除（対応者） 作成数 Auto Scaling Group 約 13 分 約7分 約 300 個 SageMaker Notebook 約 13 分 約 19 分 約 150 個 ECS Cluster 約 12 分 約 2 時間 24 分 約 2,700 個 EC2 Instance ASG 配下・継続起動 約 1 時間 約 1,000 台 これらがオプトインできるすべてのリージョンで作成されていた 緊急連絡があってから対応完了までの所要時間はトータルで約 10 時間 @kazzpapa3 / #secjaws #secjaws42 #jawsug 8 / 36
9. 実際に起きたこと（タイムライン） 時系列としては以下のような感じ 時刻 出来事 21:38 攻撃者がリソース作成開始 21:55 約 17 分で各種サービスの自動作成のための仕込みが完了 結果として 4,000 超のリソース作成につながる 正規ユーザーの締め出し（ログインプロファイルの削除） リージョンのオプトイン Auto Scaling Group の作成（IaC） ECS Cluster の作成（IaC） SageMaker Notebook の起動（IaC） 22:07 AWS から緊急通知が届く 01:19 お客様と連絡がつき、不正リソースの削除着手 09:30 削除作業完了（通知から約 10 時間後）
10. 本格着手後の動き（主に 1:19 から 9:30 の間） IAM 関連の不審な挙動の調査、確認（ここは連絡つく前から着手してい た） オプトインされたリージョン全てで不正利用されたと思われるリソース の確認、一覧化（ここも連絡つく前から着手していた） 削除対象リソースの照会（正規利用のものがないかの観点で利用者確 認） 不正に構築されたリソースの削除スクリプト作成 削除実施 事後確認 @kazzpapa3 / #secjaws #secjaws42 #jawsug 10 / 36
11. 一覧化と削除がとにかく時間がかかる @kazzpapa3 / #secjaws #secjaws42 #jawsug 11 / 36
12. 削除のためには ID（ARN）を知る必要がある リソース作成は完全に自動化可能 作成リクエストを送ってリソースが生成された結果 ID が生まれる 削除時は削除対象とする ID を明示的に指定する必要がある そのため不正作成されたリソースを一覧化して把握する必要がある @kazzpapa3 / #secjaws #secjaws42 #jawsug 12 / 36
13. 依存関係により削除作業に明確な順序が必要 例えば ECS は「タスク停止 序が必要 → サービス削除 → クラスター削除」の順 SageMaker は起動中は削除不可。停止 → 完了待ち → 削除を 1 つずつ 全リージョン対応のため、確認・削除範囲が膨大 普段使っていなかったリージョンを有効化されていることもある 正規リソースと不正リソースの選別 に時間がかかる（第三者には判断 がつかない） 普段使っていなかったリージョンであれば気にせず削除可能 @kazzpapa3 / #secjaws #secjaws42 #jawsug 13 / 36
14. あらためて整理する：対応時間の非対称性 @kazzpapa3 / #secjaws #secjaws42 #jawsug 14 / 36
15. 攻撃者 vs 防御者 観点 攻撃者 防御者 リソース 自動化・IaC 化済 操作 ID を知らないと削除できない 仕込み完了まで 約 17 分 所要時間 実際にはリソースが作成し終わるまでには 3 時間ほど要している が、手を動かし続けているわけではない 全容把握 3.5 時間 + 削除 4 時間 （加えて顧客と連絡がつくまでの待機時 間や確認作業待ちなど） 依存関係 気にせず作るだけ 削除順序を守る必要あり 判断 正規 vs 不正の選別に時間 迷いがない @kazzpapa3 / #secjaws #secjaws42 #jawsug 15 / 36
16. 実際の数字で振り返る リソース 作成（攻撃者） 削除（対応者） 作成数 Auto Scaling Group 約 13 分 約7分 約 300 個 SageMaker Notebook 約 13 分 約 19 分 約 150 個 ECS Cluster 約 12 分 約 2 時間 24 分 約 2,700 個 EC2 Instance ASG 配下・継続起動 約 1 時間 約 1,000 台 @kazzpapa3 / #secjaws #secjaws42 #jawsug 16 / 36
17. 余談 コンピュートリソースは Auto Scaling Group から作成される設定にな っていた そのため、コンピュートリソースの不正起動に気づいてそちら側を削除 していても Auto Scaling Group の設定によりゾンビのように起動して くるようになっていた 我々はこうした例があったことを他社の事例で見ていたので、真っ先に Auto Scaling Group の存在を疑ってかかった 知らずにコンピュートリソース側に着眼した場合、ゾンビのように立ち 上がるリソースの謎に混乱した可能性はあった @kazzpapa3 / #secjaws #secjaws42 #jawsug 17 / 36
18. 未知との戦いがしんどい Auto Scaling Group のように、我々が知っていた攻撃手法だったので 気づくのに時間がかからなかったものもあった ただし、多くの人にとって不正利用を受けるのは大体その時が初めての 経験のはず AdministratorAccess のように、実行できる権限が限定されていない 場合は、考えられる不正が無限に広がる 何をされているかわからない状態で、何をされたのかを網羅的に把握す ることは難しい @kazzpapa3 / #secjaws #secjaws42 #jawsug 18 / 36
19. 個人的な所感 @kazzpapa3 / #secjaws #secjaws42 #jawsug 19 / 36
20. 自分が何者か判断がつくと悪用が早い・多様化する？ AmazonEC2FullAccess がついていても EC2 インスタンスが急増しな かった例はあった IAM アクションの許可がなく、自分が何者か、何ができるかがわからな いと、何もしないことがあるように見える 無駄に AWS API を叩いても Access Denied が多発するだけなので、 そこから犯行が漏れる/検知されるのを避けている？（私の推察） ただし IAM 権限がついていなければ AmazonEC2FullAccess をつけ ていてもいい、と言っているわけではないことに注意 @kazzpapa3 / #secjaws #secjaws42 #jawsug 20 / 36
21. この非対称性にどう立ち向かうか @kazzpapa3 / #secjaws #secjaws42 #jawsug 21 / 36
22. AWS から届く通知にやることは書いている Step 内容 ポイント 1 キーのローテーショ ン 無効化だけで終わらず削除まで 被害の拡大を防ぐために、まずは無効化を迅速に進める 2 CloudTrail で IAM 系の調査 us-east-1 で確認 新しく作成された IAM ユーザーやアクセスキーがないか、締め出しを目的としたり、バ ックドアとしての仕込みがないかなど数珠繋ぎの追跡 3 CloudTrail で全般的 な調査 全リージョン × 権限の範囲で確認 4 減免申請 必要に応じて ただし必ず承認されるわけではない @kazzpapa3 / #secjaws #secjaws42 #jawsug 22 / 36
23. 事後対処は頑張ればできる。でも時間がかかる。 Step 1〜4 の手順は明確で、順を追えば対処できる しかし対処にかかる時間は攻撃の規模に比例して膨大になる 対処を頑張れるかどうか ではなく、対処の必要をなくすこと が重要 @kazzpapa3 / #secjaws #secjaws42 #jawsug 23 / 36
24. ただし、今日お話ししていないこと @kazzpapa3 / #secjaws #secjaws42 #jawsug 24 / 36
25. 証拠保全などはお話ししていない 今回、利用料の高騰を防ぐために「削除する」観点しか述べていない OS レイヤー以上の改変・改ざん ストレージ、データベースへのアクセス、データ持ち出し 上記のような証拠保全や追加調査を行うとなると、さらに時間を要 する 削除の前に AMI や スナップショットを取得する、など、作業の順序性 も高度化する @kazzpapa3 / #secjaws #secjaws42 #jawsug 25 / 36
26. AWS が使う AWS 管理ポリシーを使う手もある @kazzpapa3 / #secjaws #secjaws42 #jawsug 26 / 36
27. AWSCompromisedKeyQuarantine ポリシー “ “Denies access to certain actions, applied by AWS in the event that an IAM user's credentials have been compromised or exposed publicly. The policy aims to limit the potential damage that may be caused by fraud-related activity leading to unauthorized charges, while not impacting the existing resources. Do NOT remove this policy. 新規リソースを構築させないことで不正利用で高額請求が発生するのを 止めるが、既存のリソースは極力巻き込まないことを目論むポリシー 現在は V3 となっている @kazzpapa3 / #secjaws #secjaws42 #jawsug 27 / 36
28. ユーザーが使うべきでない、とは書いていない GitHub のバブリックな URL として一意に表すことができ、かつ、ア クセス可能、といった流出が明確な場合に AWS 側で IAM エンティテ ィにアタッチすることがある このポリシーを付与することで、新規のリソース構築が拒否される アタッチ時点以降、犯行者が仕込んでいたプログラムも拒否されはじめ リソースの乱立を低減することはできそう ただし、過信は禁物 あくまで根本的な対処は必要 @kazzpapa3 / #secjaws #secjaws42 #jawsug 28 / 36
29. アクセスキー、やめたくなりましたか？ @kazzpapa3 / #secjaws #secjaws42 #jawsug 29 / 36
30. 漏れたら困るもの自体が存在しないこと AWS としてさまざまな代替手段を用意している aws login → ローカル開発から永続キーを排除 → CI/CD から永続キーを排除 IAM Roles Anywhere → オンプレから永続キーを排除 インスタンスプロファイル / タスクロール → コンピュート内部に永続 OIDC キーを持つことを回避できる 漏れる可能性があるもの自体を減らす ことが最も確実な対策 @kazzpapa3 / #secjaws #secjaws42 #jawsug 30 / 36
31. AWS も常に進化している まさしく本日発表されたアップデート IAM Roles Anywhere で Java SDK v2 用の新プラグインが提供開始 従来のように credential helper を別プロセスで実行したり、 credential_process をプロファイルに設定する必要がなくなった このように常にアップデートされている 昨日のベストプラクティスが、今日には更新されている可能性もある @kazzpapa3 / #secjaws #secjaws42 #jawsug 31 / 36
32. 結論 対処の手順は後追いで 頑張れる でも 時間がかかるし、その間も 課金は止まらない 結局 漏らさないこと あるいは 漏れたら困るもの自体が存在しない こと これが最も確実で、最も安価な対策 理想はアクセスキーを使わなくても済むこと ただ、それが難しい現実があるのもまあわかるので、せめて最小権限 に！ @kazzpapa3 / #secjaws #secjaws42 #jawsug 32 / 36
33. ちょっとだけ告知 JAWS-UG 神戸も JAWS SONIC 2026 に出ます IoT ロボットカーを作って、視聴者の皆 さんの操作で動かしてみようと思ってい ます ロボットカーを作っているのですが、ハ ンダづけしたワイヤーを我が家のネコち ゃんがちぎっちゃったのでちょっと焦っ ています @kazzpapa3 / #secjaws #secjaws42 #jawsug 33 / 36
34. Security is job zero. Thank you.
35. Appendix 35 / 36
36. 過去の登壇資料など Abuse report だけじゃない。AWS から緊急連絡が来る状況とは？昨 今の攻撃や被害の事例の紹介と備えておきたい考え方について CloudTrail を見つめ直してみる 今年取り組んでみたいこと アクセスキー撲滅運動の旗振りかなぁ あまりにもアクセスキーの事故が多いので CTF のゲームを作った話 自作の CTF Game 大会開催 クレデンシャル流出 ― 攻撃 3 時間 vs 復旧 10 時間。この非対称性に どう備えるか（チョークトーク） アクセスキーが漏れた日にやるべきこと - 無効化の先にある本当の対応 36 / 36