トップ > アクセスキー > AWS アクセスキーが流出したらどうなる？ 実例から学ぶ対処と予防策

AWS アクセスキーが流出したらどうなる？ 実例から学ぶ対処と予防策

アクセスキー AWS Identity and Access Management AWS CloudTrail
記事タイトルとURLをコピーする

みなさん、こんにちは。AWS CLI が好きなテクニカルサポート課の市野です。

先日、サーバーワークススキルアップトレーニングで「AWS アクセスキー流出の実態と対策 ― 検知・封じ込め・予防の全体像」と題してセミナーを行いました。

オンデマンドで公開されていますが、テキストのほうが時間のある時に読みやすい、というかた向けに、セミナーでお話しした内容の抜粋ではありますが、技術ブログとしても公開します。

オンデマンドセミナー

動画の方が都合が良いな、という方はぜひ以下からご覧いただけると幸いです。

www.serverworks.co.jp

前提：AWS から届く緊急通知について

AWS では、アカウントやリソースが不審な状態にある場合、通常のメンテナンス通知とは別に緊急性のある通知が配信されます。具体的には以下のような形式で届きます。

  • AWS 側からサポートケースが起票される通知（アウトバウンドケースと呼ばれることが多いです）
  • AWS Trust & Safety から Eメールで届く通知

代表的な通知の件名

# 性質 代表的なメール件名
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}

ただし、上記の件名はこの 2 年の間に受信し弊社で認知している件名の一例となります。また AWS 側の通知作業に依存し、件名に揺れがあることも確認しています。
なお AWS でも通知時に使用する件名を網羅的に公表しておらず、また未知のサイバー犯罪により新しいパターンが出現する可能性も考えられます。

そのため上記が全てではないことにご留意ください。

通知を見逃すことのリスク

これらの通知は土日深夜関係なく届きます。攻撃者は日本のタイムゾーンで動いているわけではないため、通知への気づきが遅れれば初動対応が遅れ、被害が拡大します。

アクセスキー流出時の対処手順（4 ステップ）

AWS からの通知には、以下の 4 つのステップで対処手順が案内されています。

Step 1：アクセスキーのローテーション

流出したキーは最終的に 削除 する必要があります。
ただし、アクセスキーを正規に利用しているシステムへの影響を回避するため、段階的な対処が必要です。

この段階的な対処を、AWS からの通知文面でも「アクセスキーのローテーション」と呼称しています。慌てずに順に対処することが求められます。

推奨手順

  1. 新しいアクセスキーを作成 する（この時点で両方のキーが有効）
  2. 正規利用しているプログラムやシステムを新しいキーに切り替え
  3. 流出したキーを 無効化（削除ではない）して切り戻し可能な状態にする
  4. 新しいキーでシステムが問題なく稼働することを確認
  5. 流出したキーを 削除

ポイントは「プログラムでの正規の利用は継続しつつ、第三者の手に渡ったキーは捨てる」ことです。「無効化」だけで放置せず、最終的に削除まで行いましょう。

また、なぜ無効化だけでは不十分と指摘を受けるのかの観点に立ったブログも公開しています。合わせてご覧いただけると幸いです。

blog.serverworks.co.jp

Step 2：CloudTrail を用いた調査（IAM リソース）

IAM のイベントは米国東部（バージニア北部）リージョンに記録される

IAM はグローバルサービスであるため、CloudTrail のイベント履歴は us-east-1 に記録されます。
他のリージョンで確認しても見つかりません。

焦っている時ほど陥りやすいポイントです。調査着手時にあらためてマネジメントコンソールがどのリージョンを参照しているかご確認ください。

確認すべきポイント

  • 不正な IAM ユーザーの作成やアクセスキーの発行がないか
  • 既存 IAM ユーザーのログインプロファイル（パスワード）の削除がないか
  • 既存 IAM ロールや IAM ポリシーの改変がないか

「数珠繋ぎ」の調査が必要

犯行者の典型的な行動パターンは以下のとおりです。

  1. 流出したアクセスキーで 新たな IAM ユーザー・アクセスキーを作成
  2. 既存 IAM ユーザーの ログインプロファイルを削除（正規にサインインできるユーザーを締め出して、発見を遅らせるため）
  3. 既存 IAM ロールの信頼ポリシーを改変（再侵入経路の確保）
  4. 新たに作成したキーで 各種リソースを乱立

流出したキーによる操作 → 新たに作られたキーによる操作 → さらにその先…と、すべての派生を追跡する必要があります。
4 は昨今よく見られる手法で、流出したキーをそのまま利用せず、新しく作成した IAM ユーザーやアクセスキーを利用する傾向が見受けられます。

ある例での攻撃手法
  1. 攻撃の初動
    1. 不正に入手したアクセスキーで新規の IAM ユーザーとアクセスキーを作成
    2. 新たに作成したアクセスキーを利用し、既存の IAM ユーザーのログインプロファイル（パスワード情報）を削除
    3. 新たに作成したアクセスキーを利用し、既存の IAM ロールの信頼関係ポリシーを改変（バックドアの作成）
    4. この後、ECS や SageMaker AI ノートブックインスタンスなどを乱立し、不正利用を実施
  2. 第 2 波の実施
    1. 初動で書き換えていた IAM ロールに対し、犯行者の所有アカウントからスイッチロールし再侵入
    2. バックドアとして利用した IAM ロールを利用し新規の IAM ユーザーとアクセスキーを作成
    3. 第 1 波と同様に ECS や SageMaker AI ノートブックインスタンスなどを乱立し、不正利用を実施

Step 3：CloudTrail を用いた調査（AWS サービス全般）

調査範囲は以下の 2 つの要素に依存します。

要素 影響
有効化されているリージョン 不正利用はどのリージョンでも発生しうる
事象発生時に有効になっているすべてのリージョンを確認する必要がある
付与されていた IAM 権限 権限の範囲＝悪用できる範囲
AdministratorAccess 付与時は調査・復旧に膨大な時間がかかる

責任共有モデルの観点

AWS や弊社など第三者では、正規の利用か不正利用かの判断がつきません。
不正に乱立されたリソース群を正規サービスへの影響を回避しながら削除することも困難です。「何かあったら止めてもらえる」とは考えず、自分のシステムは自分で守る意識が重要です。

ただし GitHub リポジトリの URL として第三者から視認できるなど、アクセスキーの流出が明白な場合は、AWS 側で暫定的な封じ込めを行う場合があります。
具体的には AWSCompromisedKeyQuarantine* という命名をもつポリシーを付与されます。（いくつかバージョンがあり、現在は V3 となっています）

このポリシーの詳細や目的については、弊社の森さんが詳しく解説しているブログがありますのでご一読ください。
端的には「利用料の高騰につながる傾向のある」AWS API アクションの新規実行を封じ込めています。

blog.serverworks.co.jp

また、森さんのブログにも言及がありますが、これらのポリシーは対処が完了後、AWS へ報告し、AWS にて全ての対策がとられていることを確認後にデタッチされます。
IAM 権限が充足していてご自身でデタッチできる、という場合でも、ご利用者様でのデタッチは避けてください。

調査の実務的なヒント

  • CloudTrail のイベント履歴はデフォルトで 90 日間 保持されている
  • マネジメントコンソールでの全リージョン目視確認は非常に困難。AWS CLI で抽出して CSV に加工すると俯瞰しやすい
  • CloudTrail 証跡を作成し、S3 に保存している場合は Athena との連携が有効

上記の最後に述べた CloudTrail 証跡は意外と有効化されていないアカウントも多く、CloudTrail のイベント履歴しか利用できないシーンが多い印象です。
そのため、参考ツールとして research-via-cloudtrail を CloudTrail イベント履歴の抽出スクリプトとして紹介しました。

Step 4：AWS 利用料の請求調整

不正利用による利用料について、AWS に請求調整を申請できる場合があります（必ず承認されるわけではありません）。

条件・注意事項

  • 過去に同様の問題で請求調整を受けたことが ない こと
  • 前述の Step 1〜3 の対処が完了していること
  • AWS での個別審査となり、承認・否認の基準は非開示
  • 審査に時間を要する可能性があり、一度は支払いが必要
  • 過去に同一事態で減免を受けていた場合、2 回目は承認されないことがほとんど

「何かあっても AWS が救済してくれるから大丈夫」とは考えず、まずは事態の発生を防ぐことが肝要 です。

同様の事態を引き起こさないために

ここからは「予防」「早期検出」「封じ込め」の 3 つの観点で対策を整理します。

予防：そもそも流出させない・被害を最小化する

IAM アクセスキーの撤廃を検討する

2026 年現在、AWS はアクセスキーの利用を推奨していません。代替手段が充実しています。

  • aws login コマンド（2025年11月〜）：CLI / SDK でもアクセスキー不要に 1
  • IAM Roles Anywhere（2022年7月〜）：オンプレミス環境でもアクセスキー不要に 2

まずはアクセスキーの棚卸しから始めましょう。

  1. アクセスキーが 存在しているかどうか の把握
  2. 存在している場合 本当に必要なのか の見直し
  3. 撤廃できるものは撤廃する

アクセスキーが撤廃できない場合

  • 最小権限の遵守
    • *FullAccess や AdministratorAccess が安易に付与されていないか確認
    • 権限の範囲＝悪用された場合の被害範囲
  • 定期的なローテーション
    • 手順と影響範囲を事前に把握しておく
  • Security Hub での状況把握
    • セキュリティ基準チェックで IAM の状況を継続的に可視化

早期検出：異常をいち早く検知する

手段 概要 注意点
Amazon GuardDuty 不審な API 呼び出しやアクセスパターンを検知。アクセスキーの不正利用に対する検出能力あり —
AWS Cost Anomaly Detection / AWS Budgets 異常な利用料を検知 タイムラグがあるため、高額被害を初期段階で検知できるものではない
AWS User Notifications AWS からの通知を任意の宛先に設定可能 利用者側での能動的な設定が必要

封じ込め：発生時に迅速に対処できる体制を整える

封じ込めの基本は前述の Step 1〜4 を迅速に実施することです。そのためには、事前の棚卸しと体制整備が不可欠です。

把握すべき情報 理由
どのシステムで利用しているか ローテーション時の影響範囲の特定
技術的判断は誰が下せるか 迅速な意思決定のため
経営判断は誰が下せるか サービス停止を伴う判断のため

実例：キー流出から 3 時間半で約 4,000 リソースが乱立

最後に、実際に発生した事例を紹介します。

  • アクセスキーの流出からわずか 3 時間半の間に約 4,000 のリソースが乱立
  • SageMaker Notebook インスタンス、ECS コンテナなどが大量に作成された

この事例から得られる教訓は以下のとおりです。

  • 攻撃は 自動化・組織化 されており、人間の対応速度を上回る
  • 初動の遅れが被害額に直結する
  • シミュレーション（避難訓練） を事前に実施しておくことが重要

避難訓練では、以下を確認しておきましょう。

  • 何かあったときに どこに 連絡が来るのか
  • その連絡は どの時間帯でも 受け取れるのか
  • 受け取った人が 即時判断できるのか、エスカレーションは必要か

おわりに

実例でご紹介した通り（不正利用者にとって）充実した権限が付与されたアクセスキーの流出があった場合、発生から数時間で甚大な被害につながります。
網羅的にリソース ID や ARN を一覧化し対象リソースを明示的に指定しなければ削除できないため、攻撃者の作業量に対して防御側の作業量が甚大になり、時間を要することで不正リソースの稼働時間も伸びてしまう傾向もあります。

そのため、以下を念頭に、今一度アクセスキーを撤廃できないか、撤廃できない場合は最小権限にしてベストプラクティスに沿った運用がとれないか、棚卸しをおすすめします。

  1. アクセスキーは可能な限り撤廃する（aws login、IAM Roles Anywhere の活用）
  2. 撤廃できない場合は最小権限＋定期ローテーション を徹底する
  3. GuardDuty や Cost Anomaly Detection で異常を早期検出する仕組みを整える
  4. 棚卸しと避難訓練 で、発生時に迅速に対処できる体制を構築する
  5. 「AWS が何とかしてくれる」ではなく、自分のシステムは自分で守る 意識を持つ

本エントリがどなたかの参考になれば幸いです。

ではまた。

  1. https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-sign-in.html↩
  2. https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html↩

市野 和明 (記事一覧)

マネージドサービス部・テクニカルサポート課

お客様から寄せられたご質問や技術検証を通じて得られた気づきを投稿していきます。

情シスだった前職までの経験で、UI がコロコロ変わる AWS においては GUI で手順を残していると画面構成が変わってしまって後々まごつくことが多かった経験から、極力変わりにくい AWS CLI での記事が多めです。

X（Twitter）：@kazzpapa3（AWS Community Builder）