トップ > AWS IAM > アクセスキーが流出した時、何をしなければならないか再考してみる

アクセスキーが流出した時、何をしなければならないか再考してみる

AWS IAM AWS CloudTrail AWS Support
記事タイトルとURLをコピーする

みなさん、こんにちは。

AWS CLI が好きなテクニカルサポート課の市野です。

アクセスキーが意図せず流出する事案は昔からありますが、GitHub などのバージョン管理システムへのパブリック公開や、サーバー内部の脆弱性などでの流出など留まるところを知りません。

今日は、アクセスキーの流出が起きた時に何をしなければならないのか、どのような対処が必要なのかをまとめます。

よくある通知文面

アクセスキーが不正に利用されていることが疑われる場合、以下のような文面で、AWS Support から「ケース起票」という形を伴ってアカウントの利用者に通知されます。1

なお、犯行者のどのような行動をもって不審な行動とみなしているかは AWS の内部情報のため網羅的にご案内することや、どのくらいのスピードで通知が行われるかをご案内することは困難です。

ただし、佐竹さんが書いてくれているように、攻撃の初手として使われる sts:GetCallerIdentity が普段と異なるロケーションから行われた際は、検知スピードが早いように感じています。
（個人的な体感ですので根拠はありません。）

blog.serverworks.co.jp

件名の例

[CASE 123456789012345] [Action Required] Unexpected Activity Detected on your AWS Account 123456789012

本文の例

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. Please review the detailed list of access key(s) and User(s) in the existing Support Case within your AWS Console.

Refer to the user guide [1] for detailed instructions.

As a security best practice, we recommend that you enable multi-factor authentication (MFA) [2].

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 by clicking on the “Make inactive” option in the console. If there are any problems with your application, you can reactivate the exposed key. When your application is fully functional using the new key, please delete the exposed access key(s).

To delete IAM user keys, go to [3].
To delete Root user keys, go to [4].

Please note, only rotating and deleting the exposed key may not be sufficient to protect your account, continue to Step 2.

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 by checking your CloudTrail log, and immediately delete them.

To delete IAM users, go to [5].
To delete policies, go to [6].
To delete roles, go to [7].

Please note, deleting IAM users may impact production workloads and should be done carefully.

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 by logging into your AWS Management Console and reviewing each service page. You can also do this by checking the "Bills" page in the Billing console [8].

Please note, unwanted usage can occur in any region and your console only displays one region at a time. To switch regions, use the drop-down menu in the top-right corner of the console.

Step 4: Please work with your TAM/Account Manager and respond to the existing Support Case or create a new one [9] to confirm completion of steps 1-3 and apply for a billing adjustment, if applicable. We will work with you to evaluate billing adjustments after the account is secured.

We will provide a list of potentially unexpected resources related to this event through the associated Support Case within the next 2 hour(s). Please review the resources listed for each of your services, and take action to stop, delete, or terminate any that are unwanted. The deeplinks in the attached file should take you to the exact resource page, or you can manually navigate to the resource to investigate. In addition to the resources detailed in the Support Case, it's important that you review all your services and credentials to identify and address any other unwanted usage, as described.

If you need help securing your account, let us know through the Support Case where you can request a phone call or chat session for immediate assistance. Alternatively, if you believe that your account is secured and there is no unwanted access or usage, please contact us immediately via the Support Case to confirm this in writing.

Thank you for your immediate attention to this matter.

[1] https://aws.amazon.com/premiumsupport/knowledge-center/potential-account-compromise/
[2] https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_enable.html
[3] https://console.aws.amazon.com/iam/home#users
[4] https://console.aws.amazon.com/iam/home#security_credential
[5] https://console.aws.amazon.com/iamv2/home#/users
[6] https://console.aws.amazon.com/iam/home#/policies
[7] https://console.aws.amazon.com/iam/home#/roles
[8] https://console.aws.amazon.com/billing/home#/bill
[9] https://console.aws.amazon.com/support/home?#/

対処すべき内容を見てみる

Step 1

機械翻訳ですが、以下のように書かれています。

ステップ1：アプリケーションが公開されているアクセスキーを使用している場合は、キーを交換する必要があります。キーを交換するには、まず2つ目のキーを作成します（この時点で両方のキーが有効になります）。次に、アプリケーションを修正して新しいキーを使用するようにします。

次に、コンソールの「非アクティブにする」オプションをクリックして、公開されているキーを無効化します（削除しないでください）。アプリケーションに問題が発生した場合は、公開されているキーを再度アクティブ化できます。アプリケーションが新しいキーで完全に動作するようになったら、公開されているアクセスキーを削除してください。

IAMユーザーキーを削除するには、[3]を参照してください。ルートユーザーキーを削除するには、[4]を参照してください。

なお、公開されているキーのローテーションと削除だけではアカウントの保護が不十分な場合がありますので、ステップ2に進んでください。

アクセスキーの削除をしていいのか、してはいけないのか読み解くのが難しいように書かれていますが、主旨としては以下となります。

  1. 本質的には流出しているアクセスキーは削除しなければならない
    • ただし、該当のアクセスキーをお客様のプログラムやシステムで正規に利用している可能性があるため、いきなり削除してしまうと業務影響も発生してしまう
  2. 新たなアクセスキーを作成して、正規に利用しているプログラムやシステムでの利用部分のアクセスキーを更新する
    • システムやプログラムがあたらしいアクセスキーを利用するように更新する
  3. ここまで完了したら、流出してしまったアクセスキーを「無効化する」
    • いきなり削除しないことで、正規に利用しているプログラムやシステムで不具合が起きた場合に切り戻しができるようにしている
    • あたらしいアクセスキーでプログラムやシステムが問題なく稼働することを確認する
  4. 業務への影響が回避できていることを確認してから、流出してしまったアクセスキーを削除する

本来、目的があってアクセスキーを発行し、プログラムなどで利用しているはずです。
それを踏まえて プログラムでの正規の利用は継続できるようにしつつ、第三者の手に渡ったアクセスキーは捨てましょう、ということ です。

Step 2

機械翻訳ですが、以下のように書かれています。

ステップ2：CloudTrailログで不要なアクティビティを確認してください。

CloudTrailログを確認し、承認されていないIAMユーザーや関連するパスワード（ログインプロファイル）、アクセスキー、ポリシー、ロール、一時的なセキュリティ認証情報など、アカウントに不要なアクティビティがないか確認してください。不要なアクティビティが見つかった場合は、直ちに削除してください。

  • IAMユーザーを削除するには、[5]を参照してください。
  • ポリシーを削除するには、[6]を参照してください。
  • ロールを削除するには、[7]を参照してください。

IAMユーザーの削除は本番環境のワークロードに影響を与える可能性があるため、慎重に行ってください。

IAM リソースを中心にお客様の意図しない改変や新規作成がないかを確認するように書かれています。

ここで AWS CloudTrail を活用して状況の調査が求められますが、CloudTrail では以下の点に注意が必要です。

  • CloudTrail はデフォルトで 90 日間分の 管理イベント を「イベント履歴」としてログ記録している
  • イベント履歴は AWS リージョンごとに記録されており、特定のリージョンに対するイベント履歴を確認する場合には、明示的にリージョンを選択しなければならない2
  • AWS におけるイベントには「グローバルサービスイベント」と呼ばれる概念があり、IAM はグローバルサービスイベントにあたる
  • グローバルサービスイベントのイベント履歴の多くは米国東部 (バージニア北部) リージョンで発生しているものとして記録される

つまり、IAM リソースに対する CloudTrail でのイベント履歴の確認のためには、米国東部 (バージニア北部) リージョンで確認する必要 があります。3

また、流出が疑われているアクセスキーは AWS から通知されたサポートケースに続報として届いた案内の中で、以下のような形式で記載されていることが多いです。

Access Key: AKIAIOSFODNN7EXAMPLE
IAMUser: foouser
Event Name: GetCallerIdentity
Event Time: 2026年1月1日 00:00:00 (UTC+00:00)
IP: 203.0.113.39
IP Country/Region: US

上記に記載されている時間帯や IAM ユーザー名、アクセスキー ID を条件の中心に据えて、米国東部 (バージニア北部) リージョンの CloudTrail で行動履歴を確認する必要があります。

昨今の事例では、問題の発見を遅らせるために既存の IAM ユーザーのログインプロファイル（＝いわゆるパスワード）を削除することも多く見られます。
また、流出したアクセスキーをそのまま利用するのではなく新たな IAM ユーザーの作成とアクセスキーの発行し、流出したアクセスキー以外の IAM リソースを作成して悪用をしていることも多くあります。
さらに、既存の IAM ロールや IAM ポリシーに対する改変が行われることも多くあります。

これらの行動をすべて確認し、お客様の意図通りでない IAM リソースの作成や改変、削除が行われていないかを確認する必要があります。

つまり IAM リソース全般において、流出したアクセスキーを利用して行われたすべての行動を確認します。
そして新たに作成されている IAM リソースがあれば数珠繋ぎにして、新たに作成されたリソースで行われた活動をつぶさに確認します。これを繰り返しお客様の意図通りではない IAM リソースの存在をあぶり出す必要がある、ということになります。

IAM リソースに対する確認観点
流出したアクセスキーを使った行動と、新たに作られたアクセスキーを使った行動の両面で、数珠繋ぎに確認する必要があります

また IAM のアクション一覧は以下の公式ドキュメントにありますので、Update 系や Create 系など CRUD 操作のうちの Read 以外のアクションを中心にご確認いただく必要があります。

docs.aws.amazon.com

マネジメントコンソールでの AWS CloudTrail でのイベント履歴ページ
IAM のイベント履歴は米国東部 (バージニア北部) リージョンで確認する必要があります

また CloudTrail の詳細な利用方法は公式ドキュメントもご確認ください。

docs.aws.amazon.com

Step 3

機械翻訳ですが、以下のように書かれています。

ステップ3：AWSアカウントに不要な使用がないか確認します。AWSマネジメントコンソールにログインし、各サービスページを確認することで、EC2インスタンス、Lambda関数、EC2スポット入札など、アカウントに不要な使用がないか確認できます。請求コンソールの「請求書」ページ[8]でも確認できます。

なお、不要な使用はどのリージョンでも発生する可能性がありますが、コンソールには一度に1つのリージョンしか表示されません。リージョンを切り替えるには、コンソールの右上隅にあるドロップダウンメニューを使用してください。

このステップでは Step 2 とは異なり、IAM 以外の広範な AWS サービスにおいてお客様の意図に沿わないリソースの作成がされていないかの確認と、必要に応じて削除が求められています。

どのような観点で確認すると良いか

大変難しい問題で、ひと口に言ってしまうと漏れたアクセスキーが紐づく IAM ユーザーに付与されている IAM ポリシーに依存する、となります。

例えば悪用された時の AWS からの通知件名や扱いが異なりますが、Amazon SES での SMTP ユーザーも内部的には IAM ユーザーとアクセスキーとして発行されます。
推奨手順の通り作っていれば、執筆時点ではインラインポリシー AmazonSesSendingAccess に ses:SendRawEmail のみ許可されたアクセスキーとして発行されます。4
このような場合であれば、ses:SendRawEmail しか行えないため、Amazon SES を利用したメール送信しか行えないはずです。
もちろん大量のスパムメール配信に使われるなど、Amazon SES の送信者評価の低下につながるため問題は大きく発生します。ただ多岐にわたる AWS サービスにおいて多様なリソースの乱立には使えないはずです。

他方で、*FullAccess や PowerUserAccess、AdministratorAccess が付与されていた場合、許可されている範囲が広がるため、悪用できる範囲も広がることになります。

そのため流出したアクセスキーや新たに作られたアクセスキーが持つ IAM ポリシーとして 何ができるかを考慮する必要 があります。それらを踏まえて 有効になっているすべてのリージョンで 悪意を持ったユーザーによる意図しないリソースの作成がされていないかを確認する必要があります。

Step 3 での確認観点
ここでも流出したアクセスキーを使った行動と、新たに作られたアクセスキーを使った行動の両面で、かつ、有効化されているすべてのリージョンに対して確認する必要があります

この時、すべてのリージョンを対象にして、さまざまな条件でイベント履歴を目視確認するのは煩雑だと考えられます。

CloudTrail 証跡を設定し、S3 バケットにイベント履歴データがある場合は Amazon Athena との連携による検索が有用です。新規受付の停止がアナウンスされていますが CloudTrail Lake などを用いた検索も有用です。
しかしながら、アクセスキーの流出が起こったタイミングでこれらのサービスを有効にしていなかった場合、デフォルトの管理イベントの 90 日間の記録のみとなります。

デフォルトの管理イベントの確認をマネジメントコンソールから行うのは大変困難ですので、AWS CLI を用いて抽出した上で CSV に加工するなどをし、俯瞰しやすくすると良いかと考えます。

サンプルスクリプトですが、イベント履歴の抽出しやすくするシェルスクリプトを試作してみました。
AWS CLI と jq が導入済みの環境であれば動作しますので、ご参考にしていただけると幸いです。

github.com

Step 4

ステップ4：TAM/アカウントマネージャーと連携し、既存のサポートケースに返信するか、新しいサポートケース[9]を作成して、ステップ1～3の完了を確認し、該当する場合は請求調整を申請してください。アカウントのセキュリティが確保された後、請求調整についてお客様と協力して検討いたします。

Step 1〜3 で求められている内容の確認や是正が完了した上で、必要があれば、請求調整を申請可能と書かれています。

弊社の請求代行サービスをお使いの場合、お客様による操作ではサポートケースへの返信や新規作成はできないものとなっております。
そのため弊社へご依頼いただき、弊社を通じて申請することとなりますが、お客様の意図ではない不正なリソース作成によって発生した AWS 利用料について調整の審査を受けることが可能です。

ただし、AWS や弊社で必ず減額されることを確約するものではなく、すべて発生事象や背景、対処の内容などを総合的に判断した上で AWS 担当部署による個別審査となっています。
審査の基準やプロセスは開示されておらず、承認あるいは否認の結果を受領するだけとなります。ただ、過去に同一の事態が発生し、減免の許可を受けていた場合の 2 回目の同一事象の発生の場合には承認されないことがほとんどとなっています。

また不正利用額が高額な場合、審査に時間を要することもありますので、最終的に減免の決定が下されたようなケースでも、一度お支払いをいただく必要があります。

そのため、何かあっても AWS が救済してくれるから大丈夫と考えるのは危険です。何かあった場合に救済してもらえることがある、程度に捉えていただき、まずはこのような事態の発生をさせないようにしていただくことが肝要です。

おわりに

技術問い合わせ窓口であるテクニカルサポート部門では、お客様と AWS との中間地点にいる立場から、多くのアクセスキーの流出事案を見ることが多くあります。

アクセスキーが流出した場合、概ねここまでみてきた流れを案内する通知がされますので、順を追って確認をすることで対処は可能だと考えられます。
しかしながら、昨今では犯行者の手口が巧妙化、システム化している例が多く見受けられます。流出したアクセスキーが強い構築系の権限を持っていた場合、多岐にわたるリソースが自動作成され、あっという間に数十万円から数百万円の利用料につながるリソースの乱立が起こりえます。

アクセスキーの流出経路も、GitHub などのパブリックな場への意図しない公開や .env ファイルが漏れてしまったなど、何らかの形で流出していることが多く、管理が重要です。

従来アクセスキーが必要だった AWS 外からの AWS API 実行に対し aws login コマンドの提供や IAM Roles Anywhere の提供が進んでいます。5 アクセスキーの依存から脱却できる機能がリリースされる今、アクセスキーの発行とその利用である必要性が今もあるのか、見直しが必要です。

とはいえ、アクセスキーでないと外部からの利用ができないシーンもあると考えられます。
そのような場合を考慮するとアクセスキーの存在がたちまち悪、とはならないと考えます。ただ、ベストプラクティスに沿って定期的なローテーションを怠らない、安易な広めの権限をつけすぎない、といった基本の遵守は必要です。

いつもは本エントリがどなたかの参考になれば幸いです、的に締めていることが多いですが、できれば本エントリが必要な状況となりませんように。

ではまた。

  1. AWS 側からケース起票されることを「アウトバウンドケース」と呼称することもあります。↩
  2. CloudTrail イベント履歴は、 AWS リージョンにおける過去 90 日間の CloudTrail 管理 イベントの表示、検索、ダウンロード可能、および不変な記録を提供します。 （ https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-concepts.html#cloudtrail-concepts-event-history より引用抜粋）↩
  3. ほとんどのサービスの場合、イベントはアクションが発生したリージョンで記録されます。 AWS Identity and Access Management (IAM) AWS STSや Amazon CloudFront などのグローバルサービスの場合、イベントはグローバルサービスを含む証跡に配信されます。
    ほとんどのグローバルサービスの場合、イベントは米国東部 (バージニア北部) リージョンで発生しているものとしてログに記録されますが、一部のグローバルサービスイベントは米国東部 (オハイオ) リージョンや米国西部 (オレゴン) リージョンなどのその他のリージョンで発生しているものとしてログに記録されます。（https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-concepts.html#cloudtrail-concepts-global-service-events より引用抜粋）↩
  4. https://docs.aws.amazon.com/ja_jp/ses/latest/dg/smtp-credentials.html↩
  5. aws login コマンドについては山本さんが詳細にまとめたブログを公開してくれています https://blog.serverworks.co.jp/aws-cli-login-command↩

市野 和明 (記事一覧)

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

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

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

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