アクセスキーが漏洩した時、我々はどう動くべきか？

お断り

本記事で紹介している各種手法は完全ではありませんし、記事内で触れられていないような不正アクセスの手段も存在するでしょう。
なんなら執筆者はセキュリティ業務に従事している専門家でもありません。
もちろん責任は負いかねますので、その前提で「自分だったらこうやるかな。。」と考えるキッカケにくらいにしていただければと思います。

✏️ はじめに

大前提としてアクセスキーはよほどの理由がない限り作成するべきではありません。
実際にAWSのマネジメントコンソールからアクセスキーを作成しようとすると、アクセスキーのユースケースを選択するという画面導線になっています。
どの選択肢を選んでも「アクセスキーの代替案」が画面上にアラート提示され、「アクセスキーなんて作ってくれるなよ？」というAWSさんの強い意志を感じます。

そもそもで、最近はIAMユーザーを作ることもアンチパターンとなりつつあります。
実際にAWSのドキュメント上からも2021年10月にベストプラクティスから削除されています¹。

Added information about creating administrative users instead of using root user credentials, removed the best practice of using IAM groups to assign permissions to IAM users, and clarified when to use managed policies instead of inline policies.

---

アクセスキーを使うのであればAWS公式ドキュメントを熟読の上、運用プロセスに取り込んでください。
CIS BenchmarksやMITRE ATT&CK、Well-Architected FrameworkのSecurity Pillerも参考になるでしょう。

ただ、どれを読んでも本質としては同じことに帰着します。
このあたりの話を始めると膨大な量になるので本記事ではこれ以上触れません。

🧠 まずは攻撃者の思考を知る

アクセスキーが漏洩した時どんな被害が発生するでしょうか？

真っ先に思いつくのが下記あたりかなあと思います。

• ムキムキのコンピュートリソースを大量に立てられる
• S3といったデータストアから機密情報の奪取

ただし、これらは"最終的に"分かりやすい形として表層化しているだけであり、実際のところ攻撃者は水面下で様々な仕込みをしているケースがあります。

では攻撃者はアクセスキーを奪取したあと、どのような行動を取るのか？
こちらについてはJAWS DAYS 2021のこちらのセッションがとても参考になります。

多くの場合は、まずは情報調査のフェーズです。
奪取したアクセスキーでそもそも何ができるのか？という点を調べたりするパターンも多いかと思います。
有名所で行くとpacoというPythonライブラリあたりでしょうか。

上記資料の攻撃者Iのケースを見てください。

この操作で攻撃者は何を実現しようとしているか？

ログインPWの変更

AWSアカウントの正規利用者にキー漏洩が気付いた場合、AWSコンソールにログインして調査なり止血作業を行うはずです。
ところがどっこい、ログインPWが変更されておりログインできなくなっているではありませんか！
となると、止血作業の着手が遅れてしまいます。攻撃者は更にボーナスタイム加算で色々とできる。というわけです。

新規IAMユーザーの作成

アカウント正規利用者がようやくアカウントに入れたとしましょう。
真っ先にやることが該当のアクセスキーを無効化、ローテーションを回す、かと思います。
が、攻撃者が別にIAMユーザー×アクセスキーを新規作成している場合、漏洩したアクセスキーを処置するだけでは不十分です。
今頃新規で作ったアクセスキーに乗り換えて好き放題放題やっていることでしょう。

他に考えられるパターンとしては、踏み台用EC2を立てる。なども起こり得るかと思います。
例えば、AdministratorAccessのロールをアタッチしたEC2を作成し、そのEC2にSSHアクセスできるようにしておけば何が出来るでしょうか？

アクセスキーはIAMユーザーに紐づくリソースとなりますが、EC2に付与されるAdministratorAccessは”IAMロール”です。
つまり、IAMユーザーの世界線を飛び越えています。
となると、目に付くアクセスキーを全て無効化、IAMユーザーを削除して止血しようが、攻撃者はAdmin権限付きEC2にSSHアクセスしてCLIでAWSリソースをゴリゴリ操作できるというワケです。

ここまでで触れた内容についてはAWSの世界線で、ある意味王道な気もします。

他にもSSRF（Server Side Request Forgery）の脆弱性を持ったEC2上のアプリケーション経由でメタデータを奪取する、といったAWSレイヤーだけにとどまらない認証情報漏洩もシナリオとして発生する可能性があります。

---

少し長くなりましたが、アクセスキーの無効化だけで攻撃者を締め出せる！と思ってはいけないということです。

もし、私が攻撃者側の立場ならアクセスキーが無効化されたとしてもアタックを続けられるよう、様々な抜け道をあらかじめ作り、土台を整えたうえでEC2をたくさん立てたりして大暴れすると思います。

AWSのService Quotaを予めワークロード実行に必要な最低限のラインまで下られれば、いざリソースをたくさん立てられたとしてもコスト被害拡大を小さくできるのにな。。サービスアプデでできるようになると嬉しいな。。

🔔 検知

とにもかくにも気付かないと手の打ちようもありません。
自分が思いつくアクセスキー周りの検知方法を記載しています。

🔐 Security Hub CSPM

こちらはアクセスキー漏洩後の事後検知ではなく、漏洩前の事前検知に該当するものです。

AWS環境をチェックし、ベストプラクティスに違反しているリソースを抽出するためのAWSサービスです。
各AWSサービスごとにチェック項目があり、項目の内容に違反がある場合、通知したりAWSコンソールのダッシュボード上で対象リソースを確認できます。

IAMに関連するチェック項目（コントロール）の中で、アクセスキーに言及されているものを見てみましょう。

• [IAM.3] IAMユーザーのアクセスキーは90日以内にローテーションする ²
• [IAM.4] ルートユーザーのアクセスキーを存在させない³

■ IAM.4
IAM.4は特に分かりやすいですね。
ルートユーザーはAWSアカウントにおける絶対神です。神なので権限を縛ることもできません。
一昔前はアカウント名や連絡先メールアドレス、請求情報、サポートプランを変更する際に使う必要があったのですが、アップデートにより非ルートユーザーでも操作できるようになりました。

ルートユーザーを使う必要があるケースはパッと思いつく限り、非OrganizationsのAWSアカウントを解約する時くらいでしょうか。

というわけなので、日々のシステム運用でルートユーザーでのログインや、ルートユーザーのアクセスキーを使うケースはないはずです。
検知されたら直ぐに運用を見直しましょう。コントロールの重要度はもちろんCritical（非常事態）です。

ちなみにOrganizations経由でAWSアカウントを作成する場合、ルートユーザーは認証情報が設定されない状態で払い出されます。そのため、デフォルトでルートユーザーは使えない状態となっています。AWSさんの「ルートユーザーなんて使ってくれるなよ？」という強い意志を感じます。

■ IAM.3
さて、気になるのはこちらです。
コントロールの説明を見る限り、「アクセスキーを作るのはOK。ただし、ローテーションすることで安全性を高めてね」と読み取れます。
そうなんです、IAMユーザーに紐づくアクセスキーを作ったとしても直ぐに検知することはこのコントロールでは実現できないのです。

一応この制約には逃げ道があるのでそちらを紹介します。
Security Hubの実態はAWS Config（AWSリソースの変更履歴追跡サービス）で用意されているConfigルールです。
Configルールを調べると「access-keys-rotated⁴」というルールがあるはずです。
このルールがまさにSecurityHubにおけるIAM.3となります。

Configルールのパラメータはカスタマイズ可能です。
このルールのパラメータを見ると、maxAccessKeyAgeというパラメータがあります。
このパラメータを0にして、ついでに評価頻度を1時間にでもしておきましょう。
この設定でほぼリアルタイムでアクセスキー作成を検出することが可能となります。あとは通知の設定を入れておければ気付けるでしょう。

🛡️ GuardDuty

事後検知に該当するものです。

GuardDutyは振る舞い検知型のセキュリティサービスです。
「なんかアカウントで不審な動きがあったぞ？」というときにアラートを上げてくれます。

IAM周りに該当するfinding（検出）は下記ドキュメントに記載されています。

このページの内容を読んでいただくと、ほぼ「認証情報の侵害あるいはそれを助長するもの」であることが分かるかと思います。

IAMUser/AnomalousBehaviorと名の付いているものはアクセスキー漏洩に絡む不正アクセスに該当する内容です。
こちらのブログで各Findingsの内容が解説されているので、どんな動きが観測されているのか？をぜひ確認してみて下さい。

基本的にGuardDutyは有効化しておき、アラートが上がった場合は然るべきロールの人間に通知が飛ぶようにしておきましょう。
もちろん誤検知も発生するので、「GuardDutyの検出内容が実際に悪意を持った攻撃者によって行われている」と同義ではありません。誤検知や通知が多い場合は通知する内容のチューニングやトリアージを検討するべきです。
日常的アラートが鳴り続けると、それが当たり前の状態となってしまい、本当に気付かなければならないものに気づけなくなる「オオカミ少年問題」へと繋がります。
といいつつも、この手の運用体制の組成、サービスアップデートに付き合っていく根気、が真に必要なものかもしれません（知らんけど。

💰️ Cost Anomaly Detection

事後検知に該当するものです。

Cost Anomaly DetectionはBilling and Cost Managementの機能の1つで、AWSアカウントのコスト異常を検知するためのサービスです。
事前に閾値金額（絶対値の＄）と割合（％）を設定しておけば、左記の条件に抵触あるいは急激に請求金額が上昇した際にアラートを発砲することができ、SNSやEメールで通知を投げることができます。

先にも述べましたが、アクセスキーを奪われた場合、最終的にコンピュートリソースをたくさん立てられて請求金額が突如跳ね上がるケースが非常に多いです。そういった際にコスト異常と判定し、通知することが可能となります。
Cost Anomaly Detectionは日々改善されており、異常検出までのレイテンシー改善のアップデート⁵が出るなど、より高解像度に異常を検出することができます。

詳細は直近版のBlackBelt⁶を見ていてだければ図解も掲載されているのでイメージが掴めると思います。

💰️ Budgets

事後検知に該当するものです。

こちらも日々のAWS利用金額をモニタリングし、SNSやEメール通知ができるサービスです。
ただし、こちらは事前に立てた予算金額（$）を元にしたアラート発砲条件です。アラート条件は複数設定することができます。

例えば、予算金額を$200として設定した場合、下記のように複数のアラート条件を設定できます。

• 予算額の80% → $160 到達時点でA-sanに通知
• 予算額の150% → $300 到達時点でB-sanに通知
• 絶対値＄180 → $180 到達時点でA/B-sanに通知
• 絶対値＄220 → $220 到達時点でSNSトピックにPublish

また、上記ような絶対値だけでなく予測値としてトリガーすることも可能です。
→ eg. "予想コスト"が予算額（＄200）の90%（=＄180）を超えた場合アラート発砲

さて、ここまで見ると、Cost Anomaly Detectionと機能が似ているような気がしますが、Budgetsの方がより細かくアラート条件を設定できるというのが分かるかと思います（"設定しないといけない"とも言える）。CostAnomaly Detectionの方が後発なので、より楽に使えるようになっている、というとことですね。

Cost Anomaly DetectionとBudgetsに共通する点が"事前に閾値を設定しておく"という点です。
ある程度利用料金が安定しているシステムであれば「毎月大体これくらいだろう」という金額値が分かると思うのでそれを設定しておきましょう。

ただし、Budgetsでないと実現できない機能もあります。
それが"アラートが発砲された際に特定のアクション（budget actions）を自動発動する"という機能です。
これについては"検知"ではなく"止血処理"に該当するものであるため後述します。

🧑‍🤝‍🧑 AWSさん/パートナー企業からの連絡

急激にコストが増大した場合、AWSアカウントに設定したメールアドレスから連絡（Abuse Report）がくることがあります。受信したメールに「Abuse」のようなワードが入っていたら絶対にチェックしましょう。

エンタープライズ利用でTAMの方が付いている場合はTAMの方から連絡が来ると思われます。

個人利用など、場合によってはAWSサポートとやり取りする必要もあります。
ステークホルダーを巻き込んで今後の対応について相談しましょう。
私から言えることは以上です。

🚑️ 止血処理

大前段として、AWSアカウントにちゃんとアクセスできるかを確認しましょう。
攻撃者が正規ユーザーのアクセス経路や操作権限を潰している可能性があるからです。

上記は「アカウントにサインインできない場合の対応策」についてまとめられているものになります。
もしAWSアカウントにログインすらできなくなっていた場合、一番下に記載されている「アカウントサポートを受ける」に該当するので、AWSサポートフォームへ起票することになるかと思います（英語です）。

漏洩したアクセスキーの無効化

漏洩したアクセスキーが特定できるのであれば即無効化しましょう。
もし漏洩したアクセスキーが分からないのであれば順番に無効化していきましょう。

この作業のときに役立つのがIAM認証情報レポートです。
IAMコンソール上からIAMユーザーの一覧をCSVでダウンロードできます。認証情報の棚卸しの際によく使われるやつです。
このCSVの中にaccess_key_x_activeというカラムがあり、ここがTRUEになっているIAMユーザーは有効なアクセスキーを所有しているという意味になります。access_key-x_last_used_dateというカラムも「最後にアクセスキーを利用したタイムスタンプ」が表示されているので参考情報として使えるでしょう。

user	user_creation_time	access_key_1_active	access_key_1_last_used_date	⋯
test-user-1	＜TimeStamp＞	FALSE	N/A	⋯
test-user-2	＜TimeStamp＞	TRUE	＜TimeStamp＞	⋯

問答無用で削除してもOKですが、CloudTrailの分析に利用するため、アクセスキーID（AKIAxxxxx）とアクセスキーに該当するIAMユーザーは必ず控えておきましょう。

不正に作成されたIAMユーザーやIAMロールの削除

身に覚えのない変なIAMユーザー/IAMロールがいないか？
強い権限（AdminiStratorAccessなど）を持つリソースから順番にチェックしていき、怪しいものがあれば権限剥奪、アクセスキーを無効化しましょう。
既存のIAMロールの信頼関係も念の為確認しておいたほうが良いでしょう（信頼設定された外部プリンシパルが攻撃者のリソースのケースがあるかも）。

もしIAM Access Analyzerを有効化しているのであればチェックしましょう。
ここでリストアップされる検出タイプは下記の2種類で、下記条件に該当するIAMロールやS3がリストアップされています。

• パブリックアクセス：誰でもアクセスできるリソース
• 組織外のアクセス：Organizations外からアクセスできるリソース

不正作成されたリソースの確認・停止

おそらくコンピュートリソースの作成によりコストが跳ね上がっているはずです。

ざっと思いつく限りだと EC2/ECS/SageMaker/RDS あたりでしょうか。。。
踏み台にされている可能性もあるので心当たりの無いリソースはすべて停止・削除しましょう。
もちろん他のリージョンもチェックしましょう。
EC2であればEC2 Global Viewという機能で簡単に全リージョンチェックできるので確認しましょう。

CloudTrail調査

アクセスキーが特定できていれば、攻撃者がどんな行動をとったかきちんと確認しておきましょう。
ちゃんと攻撃者の環境アクセスを排除できたよね？を確認するという観点もあります。

CloudTrail＞イベント履歴 からルックアップ属性をAWSアクセスキーに設定して、アクセスキーID AKIAxxxxを条件設定してあげればAPIコール履歴を確認できます。
ただし、上記画面からは過去90日間のイベントまでしか遡れないという点にはご注意ください。
90日以上遡る場合はCloudTrail Lakeや、S3（CloudTrailの生ログ）＋Athenaのパターンで行う必要があります（事前に設定しておく必要があります）。

この辺の調査はなかなか骨が折れます。 が、Amazon Qを利用しているのであれば、「アクセスキー:xxxを利用した操作を抽出して」や「yyyy/mm/dd以降に新規作成されたコンピュートリソースをピックアップして」という感じで楽できるでしょう。 ただし、生成AIは非決定的であるので毎回100％同じ回答をするわけではないので、それを念頭に置いておきましょう。

また、Securit Hubもアップデートが入っており、アタックパスの可視化⁷でグラフィカルに確認できたり、Detectiveを用いて直感的にセキュリティ観点でリソースを調査する。なんてこともできるので活用できるかと思います。

🚑️ 止血処理、自動化できんかね？

⚙️ SCP / Config+SSM Automation

都合上こちらに記載しましたが、そもそもIAMアクセスキーを作れなくしてしまう、作られても直ぐに無効化する、という事前止血です。

■ SCP
SCPを利用するパターンです。
簡単です。SCPでiam:CreateAccessKeyをDenyするポリシーを作成してOUにアタッチしてしまうという方法です。
はい、これでアクセスキー作成はできなくなりました。以上！

ではありません。
SCP設定前に作成したアクセスキーは残存し続け、引き続き利用可能なので注意してください。
また、アカウント契約体系によりSCPを操作できない場合はこの方法は使えません。

■ Config+SSM Automation

先ほど、アクセスキーが作成されたことを検出するConfigルールについて言及しました。
Configルールには修復アクション（実態はSSMのランブック。自作もできる）というものが設定可能で、Configのコンプライアンス違反を検出したら自動的にトリガーすることができます。

SSM Automationのランブックで使えそうなのは下記です。

• RevokeUnusedIAMUserCredentials⁸

このランブックではIAMユーザーのPWとアクティブなアクセスキーを失効させることができます。
本来は長期間利用されていないIAMユーザー認証情報を失効させるために利用されるものです（裏側でiam:UpdateAccessKeyとiam:DeleteLoginProfileがコールされる）。

このランブックのパラメータで先程と同じくMaxCredentialUsageAge（デフォ90日）が設定可能なのでここを0にでもすれば大丈夫です。
実機検証はしていないのですが、上記ランブックはアクセスキーだけでなくIAMログインパスワードも失効させるので、もしコンソールログインするIAMユーザーだとログイン不能になると思われるので注意が必要です。

そもそもの話ですが、コンソールログイン可能なIAMユーザーに紐づくアクセスキーはやめておくべきです。
アクセスキーを作るなら、コンソールログイン権限を持たなくても問題ない専用のIAMユーザーで作成するべきです。

💰️ Budgets Actions

お待たせしました。

それが'アラートが発砲された際に特定のアクション（budget actions）を自動発動する"という機能です。

検知>Budgets で言及した上記の内容についてです。

Budgets Actionsとは何でしょうか？実際にアラートの設定画面を見てみましょう。

「IAM Policy」をクリックすると。。

1枚目の画像に何やら3つほど選択肢がありますね、以下に具体的な処理内容を記載します。
(これらの3アクションでニーズが満たせない場合、SNS宛にアラームを発砲し、SNS→Lambdaのように独自処理を組むこともできます)

• IAM Policy
  → 事前に設定したIAMユーザーやIAMロールにIAMポリシーをアタッチする

• Service Control Policy（SCP）
  → 事前に設定したSCPを組織単位（OU）にアタッチする

• Automate Instances to stop for EC2 or RDS
  → 事前に指定したEC2・RDSを停止する

はい、お察しの通り、Budgetsのアラームが発砲されたら上記の操作を自動トリガーすることができます。
例えば、IAM Policyであれば Deny AllのIAMポリシーを作成しておき、該当のIAMユーザー/グループ/ロールに自動アタッチすれば以降操作不能になります。なんか良さそうです。

が、1つ注意点があります。"事前に設定した"という文言に着目してください。

---

「アクセスキーが漏洩して、新規IAMユーザーを作られる＋たくさん新規EC2を立てられた」というシナリオを考えてみましょう。

攻撃者によって新規作成されたリソースはすべて「Budgets Actionsを設定したタイミングでは存在していないリソース」です。
つまり、Budgets Actionsではアクセスキー漏洩後に新規作成された怪しいIAMユーザーやコンピュートリソースを自動停止して被害を食い止めることができません（何なら最近はEC2/RDS以外にもECSやSageMakerを立ち上げるケースもあるらしいのでカバーしきれない）。

ただし、希望は残っています、SCPの自動アタッチです。All DenyのSCPポリシーをアタッチしてしまいましょう。これでアカウントを操作不能にすることができます。
ただし、注意点があります。アタッチ単位がOUであるという点です。最も早い確実なやり方は最上段のルートOUにAll DenyのSCPポリシーをアタッチしてしまうという方法ですが、これでは他の正常なアカウントも操作不能になるというトンデモ副作用が発生します。もし他のアカウントがリリース作業なんてしていた際にはあなたは磔にされてしまうでしょう。
ちなみに、アカウントの契約体系によってはSCPの操作権限を貰うことができないとパターンもあるのでご留意ください。

SCPは強力であるがゆえに扱いが難しい代物です、OUの設計が微妙だとSCPの運用も難しくなります。このあたり、SCPアタッチの対象をどのOUにするか？というのは非常に難しいですが、いったんは被害を受けたアカウントが属する末端のOUくらいに留めておくのが安牌でしょう。

さて、これであらゆるAWS操作を封じることができました。
しかしこれで解決ではありません。
立ち上げられてしまったEC2が動き続けています、課金がまだ止まっていません。
処置用に権限を縛ったOUに移動なりして、先述した通り変なリソースをガシガシ消していきましょう。

💰️ Cost Anomaly Detection

Const Anomaly Detectionでは、アラート発砲されたらSNSに自動でメッセージをPublishすることができます。SNSをトリガーにLambdaやStepFunctionsを起動し、事前定義しておいた止血処理（EC2全停止など）を動かすとよいでしょう。

Budgets Actionsはマネージドに処理を動かすことができますが、こちらの方式ではLambdaやStepFunctionsの処理を書くなど、作り込みが必要です。
Amazon Qに修正用スクリプトを作ってもらうのも良い選択肢かもしれません。

💹 CloudWatch Alarm

こちらは請求アカウント（Payer Account）でのみ実現できる方法です。
請求情報をCloudWatchのメトリクスとして流せる機能があるので、Cloud Watch Alarmを仕込んでおいて、閾値（＄）を超えたら何かしらのアクションを自動キックします。

ただし、事前に下記の設定が必要となるため、このパターンで機能実装を行う場合は、事前に確認しておきましょう

Billing and Cost Management>請求設定＞アラート設定＞CloudWatch 請求アラート

上記の設定がONになっていればCloudWatchで請求周りのメトリクスが「Billing」というネームスペースで拾えるはずです。

あとはググればCloud Watch Alarmアクションの記事がたくさん見つかると思うので、StepFunctionsでワークフロー組むなりLambdaを動かすなりよしなに調理してください。
Amazon Qさんに作ってもr (ry

我々にできること

もう疲れてきたので軽く書きます。

• 日々のアカウント状況把握（コスト/リソース内容）
• ちゃんと通知やメールは確認する
• ちゃんと検知サービスを有効化する、サービスの使い方を心得ておく
  • CloudTrailでクエリを打つ、SecurityHubのダッシュボードを操作する etc...
• 攻撃者の思考を理解する → どんなアタックパターンが有るかを知る
• bad news fast/first → 悪いことほど直ぐに言う

この手のは突然発生しててんやわんやすること必至です。
いざ事が発生してからアカウントを覗いたとて、普段どのようなリソースが立っているか、どれくらいのコストが掛かっているか、といった正常な状態を知っていないと止血対応をやろうにもなかなかに大変です。
また、いきなり本番ぶっつけで正しく迅速に動くことは難しいでしょう、日々AWSサービスにに触れて習熟度を高めておくことは大事です。
あとは異常が発覚したら直ぐに騒ぐことです。情報漏洩や破産してしまうよりも、「勘違いだったわゴメンね」の方が遥かに良いです。

アクセスキー漏洩に関しては他にも記事やレポートが上がっているので、具体的にどんなプロセスを踏んだのか？などを知るためにもぜひご覧いただければと思います。

最後に強調しておきたいのが「アクセスキーが悪！」と言いたいわけではなく、「アクセスキーを雑に運用してしまう体制」の方が対処すべき課題です。
皆様の組織ではちゃんと気付ける仕組みが用意されていますか？

事前に想定できることは対処できる！

以上

1. https://docs.aws.amazon.com/IAM/latest/UserGuide/document-history.html ↩

2. https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/iam-controls.html#iam-3 ↩

3. https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/iam-controls.html#iam-4 ↩

4. https://docs.aws.amazon.com/config/latest/developerguide/access-keys-rotated.html ↩

5. https://aws.amazon.com/jp/about-aws/whats-new/2024/05/aws-cost-anomaly-detection-reduces-latency/ ↩

6. https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2024_AWS-CostAnomalyDetection_0831_v1.pdf ↩

7. https://aws.amazon.com/jp/about-aws/whats-new/2025/06/aws-security-hub-risk-prioritization-response-scale/ ↩

8. https://docs.aws.amazon.com/ja_jp/systems-manager-automation-runbooks/latest/userguide/automation-aws-revoke-iam-user.html ↩