アクセスキーが漏れた日にやるべきこと- 無効化の先にある本当の対応

2026年8月22日に倉敷の、倉敷物語館で行われた「JAWS-UG Okayama 2026」で登壇した際の資料です

追記）登壇中にいただいた情報を Appendix に追記しました

・代替連絡先 にある Security contact information（セキュリティに関する連絡先）を忘れずに設定しよう！
・GitHub へのキー公開などは AWS でも巡回監視していて、発見次第連絡するけど、その連絡先がわからないことにはね…、ということです

#jawsoka #jawsug

Transcript

1. JAWS-UG Okayama 2026 (August 22, 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 AWS Service (as a Support Engineer)": [ "AWS Billing (請求ロジックが難解すぎる)" ], "Personal Interest": "初音ミク", "Socials": { "Twitter/X": "@kazzpapa3", "LinkedIn": "https://www.linkedin.com/in/kazzpapa3/" } } }
3. 1 年ぶりにお邪魔します @kazzpapa3 / #jawsoka #jawsug 3 / 92
4. 昨年、倉敷にお伺いした時にこんなことしてました 2025-08-30 08:57 姫路駅でえきそば食べる 2025-08-30 11:23 倉敷駅着（在来線） → 倉敷うどん ぶっかけ ふるいち 仲店さんでうどん食べる 2025-08-30 12:00 倉敷物語館周辺に到着 2025-08-30 12:34 AWS からの緊急通知（Irregular Activity Detected for Your AWS Access Key for Account）受信 オールカフェ×タニタカフェ あちてらす倉敷店 さんまで戻る お腹いっぱいなのにチーズケーキセット頼んで座席確保、緊急対応する @kazzpapa3 / #jawsoka #jawsug 4 / 92
5. 得てして、休みの日とか夜間に喰らう 昨年の JAWS-UG 岡山の前にも、社員旅行で行っていたススキノで Abuse Report 受信 JAWS FESTA 2025 in 金沢の翌日の大人の遠足での能登半島の先っち ょでアクセスキー流出が疑われる通知を受信 結果、私不在で集合写真撮影が終わっていた JAWS 界隈の面々と飲んでいた時にアクセスキー流出で上司からじゃん じゃん電話がなる など @kazzpapa3 / #jawsoka #jawsug 5 / 92
6. 余談）悔しくて作った能登の集合写真 6 / 92
7. おかげさまで、という言い方は適していませんが アクセスキー流出関連でいくつかの登壇や、イベント開催をしました 支部・イベント JAWS DAYS 2026 タイトルなど Abuse report だけじゃない。AWS から緊急連絡が来る状況とは？昨今の攻 撃や被害の事例の紹介と備えておきたい考え方について クラメソおおさか IT 勉強会 Midosuji CloudTrail を見つめ直してみる Tech AWS Community Builders Meetup 2026 今年取り組んでみたいこと アクセスキー撲滅運動の旗振りかなぁ JAWS-UG DE&I AWS麻雀で 楽しく 遊んで 学ぼう!! あまりにもアクセスキーの事故が多いので CTF のゲームを作った話 JAWS-UG 神戸 自作の CTF Game 大会開催 AWS Summit Japan 2026 Builder Community Lounge クレデンシャル流出 ― 攻撃 3 時間 vs 復旧 10 時間。この非対称性にどう備 えるか（チョークトーク） 7 / 92
8. 今日の結論 8 / 92
9. アクセスキーは使うなー 9 / 92
10. AWS からの緊急連絡はさまざま 10 / 92
11. この 1 〜 2 年で私が見聞きしたパターン # 性質 代表的なメール件名 1 バウンス Amazon SES Bounce Review Period for AWS Account ${AWS_ACCOUNT_ID} 2 Abuse Report Your AWS Abuse Report [${AWS_CASE_ID}] [AWS ID ${AWS_ACCOUNT_ID}] 3 アクセスキーの流出 [CASE ${AWS_CASE_ID}] ACTION REQUIRED: Your AWS Access Key is Exposed for AWS Account ${AWS_ACCOUNT_ID} 4 異常なアクティビティの検出 [Action Required] Unexpected Activity Detected on your AWS Account [AWS Account: ${AWS_ACCOUNT_ID}] 5 脆弱性レポート Your AWS Vulnerability Report [${AWS_CASE_ID}] [AWS ID ${AWS_ACCOUNT_ID}] 6 アクセスキーに対する不審な アクティビティの検出 [CASE ${AWS_CASE_ID}] [Action Required] Irregular Activity Detected for Your AWS Access Key for Account [AWS Account: ${AWS_ACCOUNT_ID}] 7 第三者からの不正なアクセス が疑われる事象の検出 [CASE ${AWS_CASE_ID}] [Action Required] Please review your AWS Account and credentials ${AWS_ACCOUNT_ID} 8 バウンス [CASE ${AWS_CASE_ID}] Sending Blocked - Compromised Credentials occured for offending VID [${MAIL_ADDRESS}] AWS ID ${AWS_ACCOUNT_ID} 通知件名に多少のブレや、未知の件名が発生する可能性 はあります
12. 傾向をサマリー（2024年3月 〜 2026年2月） 12 / 92
13. 性質別 Abuse Report : 9件 バウンス : 9件 アクセスキーに対する不審なア クティビティの検出 : 5件 通知の性質別分布 アクセスキーの流 1件(3.0%) 異常なアクティビ 4件(12.1%) Abuse Re 9件(27.3%) アクセスキーに対 5件(15.2%) 脆弱性レポート : 5件 異常なアクティビティの検出 : 4件 脆弱性レポート 5件(15.2%) バウンス 9件(27.3%) アクセスキーの流出 : 1件 13 / 92
14. 曜日別 月曜日: 8件 8 8 曜日別通知件数 火曜日: 4件 水曜日: 8件 木曜日: 4件 4 4 4 3 金曜日: 4件 2 土曜日: 3件 日曜日: 2件 月 火 水 木 金 土 日 14 / 92
15. 時間帯別 時間帯別通知件数 7 7 4 数件 3 3 2 2 1 0 1 1 2 3 1 4 5 6 7 8 9 10 11 12 1 13 時刻 14 1 15 16 17 18 19 20 21 22 23 15 / 92
16. さまざまありますが、今日はアクセスキーの話 16 / 92
17. 不正利用額が高騰した事例１ 17 / 92
18. 攻撃手法 1. 第 1 波としてアクセスキー ID とシークレットアクセスキーの不正入手 とそれを利用され、別の IAM ユーザーとアクセスキーを作成される その後、新しく作成したアクセスキーで以下のような行動を実施される 1. 既存の IAM ユーザーのログインプロファイルの削除 2. SageMaker Notebook インスタンスの乱立 3. ECS コンテナの乱立 4. IAM ロールの信頼ポリシーの変更 18 / 92
19. 対処したのにもう一度 2. 第 2 波として、再度不正利用をされる 1. 第 1 波の対応時点でアクセスキーの削除はしていた 2. ＜1-4＞ で IAM ロール OrganizationsAccountAccessRole の AssumeRole の引き受け元の AWS アカウント ID を書き換えられて いた 3. ＜2-2＞で設定されていた AWS アカウントから OrganizationsAccountAccessRole ロールへスイッチロールされ、 新たなアクセスキーを作成され、それを利用された 19 / 92
20. 第1波 不正入手したアクセスキーを用いて犯行用の別の IAM ユーザー・アク セスキーを作成 各種リソースの削除、改変、リソースの乱立をされていた AWS Account ②③ 不正利用 このロールは AWS Organizations 管理アカウントからメン バーアカウントを発行した際にデフォルトで作成されるロー ル 通常、管理アカウントが AssumeRole の引き受け元となるよ うに払い出されます ①削除 不正入手 新規作成 利⽤ ④改変 ①削除 20 / 92
21. 第2波 犯行者が第 1 波の際に改変していた IAM ロールを用いて再侵入され、 各種リソースの乱立をされた 管理アカウントからのアカウント発行時に作成されるロールの AssumeRole の引き受け元アカウント ID を書き換えられていた 犯⾏者所有のアカウント AWS Account 不正利用 ①スイッチロール アクセス ②新規作成 ③利⽤ 21 / 92
22. 不正利用額が高騰した事例２ 22 / 92
23. 対応時間の非対称性を認識した事例 事例１はお客様で手配されたベンダーで封じ込めやフォレンジックを行 なっていたため全容は不明 事例２は弊社で封じ込めの支援をした例（攻撃手法はほぼ類似） 攻撃者は 約 17 分 でリソースを作成（実際には仕込み完了まで） 対して、弊社側の削除作業に 合計約 4 時間要しました リソース 作成（攻撃者） 削除（対応者） 作成数 Auto Scaling Group 約 13 分 約7分 約 300 個 SageMaker Notebook 約 13 分 約 19 分 約 150 個 ECS Cluster 約 12 分 約 2 時間 24 分 約 2,700 個 EC2 Instance ASG 配下・継続起動 約 1 時間 約 1,000 台 23 / 92
24. 調査を含めるとさらに時間を要しています 実際には、削除の前に対象となるリソース ID の把握が必要 そのため、すべてのリージョンで AWS サービス全般における網羅的 な調査が必要 事例２では全容把握に 3.5 時間ほど要した 24 / 92
25. 削除のためには ID（ARN）を知る必要がある リソース作成は完全に自動化可能 作成リクエストを送ってリソースが生成された結果 ID が生まれる 削除時は削除対象とする ID を明示的に指定する必要がある そのため不正作成されたリソースを一覧化して把握する必要がある 25 / 92
26. 依存関係により削除作業に明確な順序が必要 例えば ECS は「タスク停止 序が必要 → サービス削除 → クラスター削除」の順 SageMaker は起動中は削除不可。停止 → 完了待ち → 削除を 1 つずつ 全リージョン対応のため、確認・削除範囲が膨大 普段使っていなかったリージョンを有効化されていることもある 正規リソースと不正リソースの選別 に時間がかかる（第三者には判断 がつかない） 26 / 92
27. さらにお客様と連絡が取れるまでの所要時間 通知は E メールやサポートケースで届く 電話で知らせてもらえることは基本的にない 弊社からの通知自体もテキストメッセージなので気づいてもらえないこ とが多い 伺っている電話番号が固定電話（大代表など）、かつ、休日・深夜帯な どで出てもらえない、など この時は連絡がつくまでに 2.5 時間ほど要している 27 / 92
28. 気づいてもらえた/気づいた後の対応 28 / 92
29. 実は通知文面にやるべきことは書いてある 29 / 92
30. 実際の通知文面（抜粋） “ “We detected potentially unexpected activity in your AWS account. This activity is related to your AWS access key(s) belonging to User(s) on the account. 英語で届く（弊社では日本語翻訳も送付） 基本的に Step 1 〜 Step 4 の手順が記載されている 焦らず上から順に対応すれば、大体なんとかなる 30 / 92
31. Step 1：アクセスキーのローテーション 31 / 92
32. 通知文面での案内 “Step 1: If your application uses the exposed access key, you need to replace the key. To replace the key, first create a second key (at that point, both keys will be active). Then, modify your application to use the new key. “ Next, disable (do not delete) the exposed key... When your application is fully functional using the new key, please delete the exposed access key(s). 32 / 92
33. ローテーション＝段階的な入れ替え 1. 新しいアクセスキーを作成する（この時点で両方のキーが有効） 2. 正規に利用しているプログラムやシステムを新しいキーに切り替え 3. 流出したキーを 無効化（削除ではない） 4. 新しいキーでシステムが問題なく動作することを確認 5. 最終的に流出したキーを 削除 する 33 / 92
34. なぜ「無効化」 →「削除」の 2 段階なのか いきなり削除すると正規利用中のプログラムが停止するリスク まず無効化して切り戻し可能な状態にする 新しいキーでの稼働を確認してから完全削除 34 / 92
35. なぜ「無効化のまま」ではダメなのか 無効化したキーは 再有効化が可能 対応から日が経ち、経緯を知らない運用者が再有効化してしまうリスク 攻撃者が侵入中に「後から自分で有効に戻す仕掛け」を仕込んでいる可 能性 再有効化された瞬間、犯行者が知っている認証情報が再び使えてしまう だから最終的に削除まで行う必要がある 35 / 92
36. ここで重要なのは 正規利用のプログラムが どこにいるか 把握できているか？ そもそも 今すぐ判断できる人は誰 か？ 有事の際の 業務影響 を判断できるか？ 定期的な棚卸し、最新の情報を把握しておく必要がある 必要な情報 ないとどうなるか どのシステムで利用されているか ローテーション時の影響範囲がわからない 技術的判断は誰が下せるか 深夜に連絡がついても判断ができない ビジネスインパクトはどの程度か 最悪の場合に止めていいのかの判断ができない 36 / 92
37. Step 2：CloudTrail での IAM 系の調査 37 / 92
38. 通知文面での案内 “Step 2: Check your CloudTrail log for unwanted activity. “ Check your account for any unwanted activity, such as creation of unapproved IAM users and/or associated passwords (login profile), access keys, policies, roles or temporary security credentials 38 / 92
39. CloudTrail ことはじめ AWS リージョン内の過去 90 日間の管理イベント をデフォルトで記録 明示的に証跡を作成していなくても、管理イベントは無料で確認可能 有効化されている全リージョンそれぞれで記録される 39 / 92
40. IAM のイベントは us-east-1 に記録される IAM は グローバルサービス であるため、CloudTrail のイベント履歴は 米国東部（バージニア北部）リージョン に記録される 東京リージョンで見ても IAM の操作ログは出てこない 焦っている時ほど陥りやすいポイント 40 / 92
41. 確認すべきポイント 不正な IAM ユーザーの 作成 がないか 新たなアクセスキーの 発行 がないか 既存 IAM ユーザーのログインプロファイル（パスワード）の 削除 がな いか 既存 IAM ロールや IAM ポリシーの 改変 がないか 信頼ポリシーの 書き換え（バックドア）がないか 41 / 92
42. 犯行者の典型的な行動パターン 1. 流出したアクセスキーで 新たな IAM ユーザー・アクセスキーを作成 2. 既存 IAM ユーザーの ログインプロファイルを削除 正規ユーザーをコンソールから締め出し、発見を遅らせるため 3. 既存 IAM ロールの 信頼ポリシーを改変（再侵入経路の確保） 4. 新たに作成したキーで 各種リソースを乱立 42 / 92
43. 「数珠繋ぎ」の調査が必要 流出キー → 新規作成キー → さらにその先… と追跡する必要がある 1 つの IAM リソースの確認で終わりではない すべての派生を追い切る必要がある 43 / 92
44. マネジメントコンソールでの確認は困難 検索条件を 1 対しか指定できない 日付範囲の指定は可能 ただし全リージョン横断が不可能 大量のイベントの俯瞰には向かない 44 / 92
45. AWS CLI + jq で抽出が有効 aws cloudtrail lookup-events \ --lookup-attributes \ AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE \ --start-time "2026-08-01T00:00:00Z" \ --end-time "2026-08-22T00:00:00Z" \ --region us-east-1 CloudShell なら AWS CLI と jq が導入済み CSV に加工して俯瞰するのが効率的 45 / 92
46. 個人的に作成してみたツール 全リージョン横断で CloudTrail イベント履歴を CSV に出力するツール github.com/kazzpapa3/research-viacloudtrail オプトインしている全リージョンに対して実行 可能 46 / 92
47. Step 3：CloudTrail での全般的な調査 47 / 92
48. 通知文面での案内 “Step 3: Review your AWS account for any unwanted usage. Check your account for any unwanted usage, such as EC2 instances, Lambda functions, or EC2 Spot bids... “ Please note, unwanted usage can occur in any region 48 / 92
49. IAM 以外の AWS サービス全般を確認する EC2 インスタンス、Lambda 関数、ECS クラスター・タスク・サービ ス、SageMaker ノートブックなど 有効化されているすべてのリージョン で確認が必要 マネジメントコンソールでは一度に 1 リージョンしか見られない 49 / 92
50. 調査範囲は 2 つの要素に依存する 要素 影響 有効化されているリージョン 不正利用は どのリージョンでも 発生しうる 普段使っていないリージョンをオプトインされていることも 付与されていた IAM 権限 権限の範囲＝悪用できる範囲 AdministratorAccess 付与時は調査に膨大な時間 50 / 92
51. 確認の着眼点 流出したアクセスキーの IAM ポリシーで 何ができるか を把握する 関連する IAM アクションの一覧は AWS サービスリファレンスで確認 可能 servicereference.us-east-1.amazonaws.com CRUD のうち Read 以外（Create / Update / Delete）を中心に確認 51 / 92
52. CloudTrail 証跡がある場合 S3 に JSON 形式で保存されている Amazon Athena と連携した SQL クエリでの検索が有効 全リージョン横断での分析が容易 52 / 92
53. CloudTrail 証跡がない場合 デフォルトの管理イベント（90 日間）のみが利用可能 全リージョンの目視確認は現実的でない AWS CLI での抽出 → CSV 加工 → 俯瞰が有効 先ほどのツール research-via-cloudtrail などを使って全リージョン横 断で実行可能にしておくと良い 53 / 92
54. ところで：AWS からリソース一覧が届くことがある “ “We will provide a list of potentially unexpected resources related to this event through the associated Support Case within the next 2 hour(s). 通知から約 2 時間以内に意図しないと思われるリソース一覧が提供され ることがある（ただし、来ないこともある） 届いても全てを網羅的に見ていない可能性がある 意図して作成したリソースかは第三者からの判断ができないため、結局 利用者自身で調査することが重要 54 / 92
55. Step 4：減免申請（請求調整） 55 / 92
56. 通知文面での案内 “ “Step 4: Please work with your TAM/Account Manager and respond to the existing Support Case or create a new one to confirm completion of steps 1-3 and apply for a billing adjustment, if applicable. 56 / 92
57. 減免申請とは Step 1〜3 の対処完了後に、不正利用で発生した AWS 利用料について 請求調整の審査 を受けることが可能 サポートケースへの返信で申請する 57 / 92
58. 重要な注意点 観点 内容 確約ではない 必ず承認されるわけではない AWS 担当部署による個別審査 基準は非開示 承認・否認の審査基準は公開されていない 2 回目は厳しい 同一事態で過去に減免を受けている場合 2 回目は承認されないことがほとんど 時間がかかる 審査に時間を要し、一旦は支払いが必要な場合がある Step 1〜3 完了が前提 対処が完了していないと審査に進めない 58 / 92
59. つまり 何かあっても AWS が救済してくれるから大丈夫、ではない 何かあった場合に救済して もらえることがある、程度に捉えるべき まずは 事態を発生させないこと が最も重要 59 / 92
60. 改めて整理する：対応時間の非対称性 60 / 92
61. 攻撃者 vs 防御者 観点 攻撃者 防御者 リソース作成 自動化・IaC 化済 ID を知らないと削除できない 所要時間 仕込み完了まで 約 17 分 全容把握 3.5 時間 + 削除 4 時間 リージョン 全リージョンに並列展開 1 リージョンずつ確認 依存関係 気にせず作るだけ 削除順序を守る必要あり 判断 迷いがない 正規 vs 不正の選別に時間 61 / 92
62. 実際の数字で振り返る リソース 作成（攻撃者） 削除（対応者） 作成数 Auto Scaling Group 約 13 分 約7分 約 300 個 SageMaker Notebook 約 13 分 約 19 分 約 150 個 ECS Cluster 約 12 分 約 2 時間 24 分 約 2,700 個 EC2 Instance ASG 配下・継続起動 約 1 時間 約 1,000 台 62 / 92
63. なぜ削除にこんなに時間がかかるのか 1. ID（ARN）の把握 が必要 作成はリクエストを送るだけ、削除は対象を明示的に指定する必要が ある 2. 依存関係 により削除に明確な順序が必要 → サービス削除 → クラスター削除 SageMaker：起動中は削除不可。停止 → 完了待ち → 削除を 1 つずつ ECS：タスク停止 63 / 92
64. なぜ削除にこんなに時間がかかるのか 3. 正規リソースとの選別 に時間がかかる アカウント内を正しく理解していないと「これは正規か不正か」の判 断がつかない 4. 全リージョン が対象 普段使っていないリージョンを有効化されていることも むしろ普段使っているリージョンを避ける傾向もある 64 / 92
65. 攻撃 3 時間 vs 復旧 10 時間 攻撃者は IaC で自動化 されたリソース乱立を実行 対応者は 手作業で全容把握 → 選別 → 依存関係の解決 → 削除 この時間差の間も 課金は止まらない そして、通知に気づいて着手するまでの時間がさらに加算される 65 / 92
66. 犯行者はちゃんと「仕事」をしている 犯行者は「ちゃんと」IaC を利用して効率的にリソースを乱立している ダークウェブでは使えそうな情報、悪用に最適化されたツールが出回っ ている 会社のような構造で、ツール開発者と実行者が分業している 露見した情報で 最大限の悪用ができる道 を把握して行動している AdministratorAccess メール送信権限のみ → リソース乱立でマイニング → スパムメールの配信元に 66 / 92
67. 個人的な所感 67 / 92
68. 自分が何者か判断がつくと悪用が早い・多様化する？ AmazonEC2FullAccess がついていても EC2 インスタンスが急増しな いこともある IAM アクションの許可がなく、自分が何者か、何ができるかがわからな いと、何もしないことがあるように見える 無駄に AWS API を叩いても Access Denied が多発するだけなので、 そこから犯行が漏れるのを忌避している？（私の推察） IAM 権限がついていなければ AmazonEC2FullAccess をつけていても いい、と言っているわけではないことに注意 68 / 92
69. この非対称性にどう立ち向かうか 69 / 92
70. 事後対処は頑張ればできる。でも時間がかかる。 Step 1〜4 の手順は明確で、順を追えば対処できる しかし対処にかかる時間は攻撃の規模に比例して膨大になる 対処を頑張れるかどうか ではなく、対処の必要をなくすこと が重要 70 / 92
71. AWS が使う AWS 管理ポリシーを使う手もある 71 / 92
72. 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 となっている 72 / 92
73. ユーザーが使うべきでない、とは書いていない GitHub のバブリックな URL として一意に表すことができ、かつ、ア クセス可能、といった流出が明確な場合に AWS 側で IAM エンティテ ィにアタッチすることがある このポリシーを付与することで、新規のリソース構築が拒否される アタッチ時点以降、犯行者が仕込んでいたプログラムも拒否されはじめ リソースの乱立を低減することはできそう ただし、過信は禁物 あくまで根本的な対処は必要 73 / 92
74. 結局、漏らさないことが最強 74 / 92
75. そもそもアクセスキーは必要なのか 2026 年現在のアクセスキー作成画面 → AWS の 「絶対に作らせたくない」意志 がにじみ出ている AWS 自身がアクセスキーの利用を推奨していない 代替手段が充実している 75 / 92
76. アクセスキーの代替手段 ユースケース 代替手段 コマンド 概要 コンソール認証情報で CLI / SDK を利用 一時的な認証情報を自動取得（2025年11月〜） ローカル開発 aws login CI/CD（GitHub Actions 等） OIDC フェデレーション IAM OIDC プロバイダー経由で AssumeRole オンプレ / AWS 外 IAM Roles Anywhere X.509 証明書ベースで一時認証情報を取得 （2022年7月〜） EC2 / ECS / Lambda インスタンスプロファイル タスクロール / 実行ロール サービスが一時認証情報を自動提供 76 / 92
77. aws login コマンド AWS CLI v2.32.0 以降で利用可能 コンソールにログインできるなら、CLI もそのまま使える 永続的な認証情報をディスクに保存しない 一時認証情報は 15 分ごとに自動ローテーション ~/.aws/credentials から 永続キーを消せる 77 / 92
78. IAM Roles Anywhere AWS 外部のワークロードに対して一時的な認証情報を発行 X.509 証明書ベースの認証 オンプレミスでも長期アクセスキーが不要に 証明書の失効（CRL / OCSP）で即座に無効化が可能 アクセスキーと違い 再有効化のリスクがない 78 / 92
79. OIDC フェデレーション（GitHub Actions） permissions: id-token: write contents: read steps: - uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole aws-region: ap-northeast-1 アクセスキーをシークレットに保存すること自体が不要に ワークフローから IAM ロールを直接 Assume 79 / 92
80. 漏れたら困るもの自体が存在しないこと aws login → ローカル開発から永続キーを排除 → CI/CD から永続キーを排除 IAM Roles Anywhere → オンプレから永続キーを排除 インスタンスプロファイル / タスクロール → コンピュートから排除 OIDC 漏れる可能性があるもの自体を減らす ことが最も確実な対策 80 / 92
81. まとめ 81 / 92
82. アクセスキーが漏れた日にやるべきこと Step 内容 ポイント 1 キーのローテーション 無効化だけで終わらず削除まで 2 CloudTrail で IAM 系の調査 us-east-1 で確認。数珠繋ぎの追跡 3 CloudTrail で全般的な調査 全リージョン × 権限の範囲で確認 4 減免申請 必ず承認されるわけではない 82 / 92
83. 無効化の先にある本当の対応 無効化は 入口 にすぎない その先に膨大な調査と復旧が待っている 攻撃者は自動化・組織化されており、人間の対応速度を上回る 非対称性 を前提に、事前の備えが不可欠 83 / 92
84. ただし、今日お話ししていないこと 84 / 92
85. 証拠保全などはお話ししていない 今回、利用料の高騰を防ぐために「削除する」観点しか述べていない OS レイヤー以上の改変・改ざん ストレージ、データベースへのアクセス、データ持ち出し 上記のような証拠保全や追加調査を行うとなると、さらに時間を要 する 削除の前に AMI や スナップショットを取得する、など、作業の順序性 も高度化する 85 / 92
86. 今日からできること 1. アクセスキーの棚卸し をする 存在しているか？本当に必要か？撤廃できないか？ 2. 撤廃できないなら 最小権限 にする *FullAccess や AdministratorAccess がついていないか？ 3. シミュレーション（避難訓練） をやってみる 今「漏れました」と言われて、すぐ動ける体制になっているか？ 4. キーレス化 を段階的に進める まずは aws login で ~/.aws/credentials から永続キーを消す 86 / 92
87. 結論 対処の手順は後追いで 頑張れる でも 時間がかかるし、その間も 課金は止まらない 結局 漏らさないこと あるいは 漏れたら困るもの自体が存在しない こと これが最も確実で、最も安価な対策 87 / 92
88. 1 年前の私のように休日に緊急対応しないために 漏れたら困るものを 今のうちに 減らしておく そして 万が一の時に動ける体制 を整えておく みなさんの環境が、今日より少しでも安全になりますように 88 / 92
89. Security is job zero. Thank you.
90. Appendix 90 / 92
91. 登壇中にいただいた情報 代替連絡先 にある Security contact information（セキュリティに関 する連絡先）を忘れずに設定しよう！ ↑ここね↑ GitHub へのキー公開などは巡回監視していて、発見次第連絡するけ ど、その連絡先がわからないことにはね…、と 個人情報をマスクするのが面倒だったので一旦消しただけだよw 91 / 92
92. 参考リンク（AWS 公式情報） AWSCompromisedKeyQuarantineV3 - AWS Managed Policy AWS enables developers to use console credentials for AWS CLI and SDK authentication（aws login / What's New） aws login - AWS CLI Command Reference The IAM Roles Anywhere trust model - IAM Roles Anywhere AWS Service Reference Information 92 / 92