AWSのアクセスキーがGitHub、CI/CDログ、チャット、チケット、.envなどへ誤って公開されると、第三者によってAWS環境へ不正アクセスされる可能性があります。特に長期利用されるアクセスキーは、漏洩後に攻撃者から悪用されると、EC2などの高額リソース作成、IAM権限の追加、S3上のデータ取得などにつながるおそれがあります。

AWSアクセスキーが漏洩した場合は、公開したファイルやリポジトリからキーを削除するだけでは不十分です。一度外部へ露出した認証情報は、すでに第三者へ取得されたものとして扱い、キー自体を無効化したうえで、CloudTrailなどから実際の利用履歴を確認する必要があります。

また、AWSではAKIAから始まるキーはIAMユーザーやルートユーザーに紐づく長期認証情報、ASIAから始まるキーはSTSによる一時認証情報として扱われます。どの主体の認証情報が漏れたかによって、確認すべき範囲も変わります。

特に重要なのは、「キーを止めたから終わり」ではなく、攻撃者がすでに何をした可能性があるかまで確認することです。IAMの権限変更、CloudTrail停止、全リージョンでのリソース作成、S3やSecrets Managerからの情報取得などを横断して確認する必要があります。

そこで本記事では、AWSアクセスキー漏洩時に最優先で行う封じ込め、CloudTrail・GuardDutyで確認すべき不正利用の痕跡、CLIを使ったアクセスキー無効化・削除の方法、ルートユーザーのキーが漏れた場合の対応、再発防止策、フォレンジック調査で侵害範囲を確認する方法までわかりやすく解説します。

AWSアクセスキーが漏洩した場合にまず行う初動対応

AWSアクセスキーの漏洩が確認された場合は、実際に利用された証拠がまだなくても、侵害済みの認証情報として扱います。まずキーを使えない状態にし、その後にCloudTrailなどから不正利用の有無を確認します。

漏洩したアクセスキーを特定してInactiveにする

漏洩したアクセスキーが判明したら、IAMユーザーの「Security credentials」から該当キーを確認し、まずInactiveへ変更します。

アクセスキーをそのまま有効にしておくと、攻撃者が継続してAWS APIを利用できる可能性があります。

稼働中のアプリケーションがそのキーへ依存している場合は、新しい認証方式または新キーへ切り替えた後に旧キーを削除します。ただし、攻撃が進行している疑いがある場合は可用性より停止を優先します。

公開されたGitHub・ログ・チャットなどの露出元を閉じる

アクセスキーがGitHub、GitLab、CI/CDログ、チャット、チケット、.env、コンテナイメージ、AMIなどへ含まれていた場合は、露出元を直ちに非公開化・削除します。

ただし、リポジトリ履歴やログから削除しても、すでに第三者に取得されている可能性があります。

そのため、「削除したから安全」と考えず、キー自体は侵害済みとして無効化・ローテーションします。

キーがルートユーザーのものか確認する

漏洩したアクセスキーがルートユーザーに紐づくものであれば、緊急度をさらに引き上げます。

ルートアクセスキーは削除し、ルートユーザーのパスワード変更、MFAの状態、代替MFAデバイスの有無なども確認します。

あわせて、IAM管理者権限を持つユーザーやロール、信頼ポリシーなどに不審な変更がないか重点的に確認します。

CloudTrail・GuardDutyなどの証跡を保全する

キーを止めた後は、CloudTrailやGuardDutyなどに残る記録を保全します。

CloudTrailのEvent historyだけでは期間や範囲に限界があるため、可能であれば組織全体・全リージョンの証跡を対象にします。

特にAccessKeyId、eventSource、eventName、sourceIPAddress、userAgent、イベント時刻などを確認します。

AWSサポート・社内CSIRTへエスカレーションする

AWSからアクセスキー露出や不正利用の通知を受けた場合は、AWSサポートケースへ対応状況を返します。

また、事業影響、個人情報、顧客データ、外部公開などの可能性がある場合は、社内CSIRT、情報システム、法務、個人情報保護担当、必要に応じて経営層へ共有します。

AKIAとASIAの違いと確認すべきポイント

AWS認証情報を調査する場合は、アクセスキーIDの形式から、長期認証情報なのか一時認証情報なのかを切り分けます。

AKIAはIAMユーザーまたはルートユーザーに紐づく長期認証情報

AKIAから始まるアクセスキーIDは、IAMユーザーまたはルートユーザーに関連する長期認証情報です。

長期アクセスキーが漏洩した場合は、無効化するまで第三者に利用され続ける可能性があります。

そのため、依存アプリケーションを確認しつつ、速やかに無効化・ローテーションします。

ASIAはSTSによる一時認証情報

ASIAから始まるアクセスキーIDは、AWS STSによって発行された一時認証情報です。

一時認証情報には有効期限がありますが、有効期間中に悪用される可能性はあります。

そのため、単に期限切れを待つのではなく、どのIAMロールやセッションから発行されたものか確認します。

STSの場合はsessionIssuerも追跡する

ロールやSTSの一時キーが関係する場合は、CloudTrail上のsessionIssuerも確認します。

どのロールを引き受けて発行されたセッションなのかを特定し、元となる認証主体や信頼ポリシーに不審な変更がないか確認します。

CloudTrailでAWSアクセスキーの不正利用を調査するポイント

アクセスキー漏洩後の調査では、CloudTrailを中心に「誰が、いつ、どこから、どのAPIを実行したか」を追跡します。

AccessKeyIdで漏洩キーの利用履歴を追跡する

CloudTrailで漏洩したAccessKeyIdを起点に、そのキーで実行されたAPI操作を確認します。

イベント時刻、実行API、対象リソースを時系列で並べることで、漏洩後にどのような操作が行われたかを把握しやすくなります。

sourceIPAddressとuserAgentを確認する

sourceIPAddressやuserAgentを確認し、通常のアプリケーションや利用者が使っている環境と一致するか確認します。

見覚えのないIPアドレスやツールからのアクセスがあれば、不正利用の手掛かりになります。

全リージョンのAPI操作を確認する

攻撃者は、普段利用していないリージョンでリソースを作成する場合があります。

そのため、東京リージョンだけを見るのではなく、全リージョンでEC2、Lambda、ECS、EKS、SageMakerなどのリソースが作成されていないか確認します。

不審なIAM操作を確認する

侵害後に別のユーザーやキーを作成して永続化される場合があります。

特に次のようなIAM APIは重点的に確認します。

CreateUser CreateAccessKey CreateLoginProfile AttachUserPolicy PutUserPolicy CreateRole UpdateAssumeRolePolicy 

これらの操作が正規の変更でない場合は、攻撃者がアクセスを維持するための設定を追加した可能性があります。

CloudTrail停止・ログ削除などの防御回避を確認する

攻撃者が調査を困難にするため、監査ログを止めたり削除したりする場合があります。

次のような操作を確認します。

StopLogging DeleteTrail UpdateTrail DeleteDetector 

CloudWatch Logsのログ削除や保持期間変更なども確認対象です。

AWSアクセスキー漏洩後に確認すべき不正利用の痕跡

アクセスキー漏洩後は、単純なログインやAPI利用だけでなく、権限昇格、課金悪用、データ持ち出し、外部公開設定の変更なども確認します。

IAMユーザー・ロール・アクセスキーの新規作成

攻撃者が漏洩キーを使って別のIAMユーザーやアクセスキーを作成すると、元のキーを止めてもアクセスが残る可能性があります。

新規ユーザー、アクセスキー、ログインプロファイル、管理者権限の付与などを確認します。

EC2・Lambda・ECS・EKSなどの高コストリソース作成

漏洩キーが暗号資産マイニングや高額サービスの利用に悪用されることがあります。

RunInstances、Spot関連操作、CreateFunction、ECS/EKS、SageMaker、Bedrockなどの利用状況を確認します。

Cost Explorerや請求アラートも確認し、普段と異なる費用増加がないか確認します。

S3・RDS・DynamoDBなどからのデータ取得

漏洩したキーにデータアクセス権限がある場合は、情報持ち出しの有無を確認します。

S3ではListBucketやGetObjectなどを確認し、機密情報や顧客データにアクセスされていないか調査します。

RDS、DynamoDBなども、対象キーがアクセス可能だった範囲を確認します。

Secrets Manager・SSM Parameter Storeの読み出し

Secrets ManagerやSSM Parameter Storeに、データベースパスワード、APIキー、外部サービスの認証情報などを保存している場合があります。

これらが取得されている場合は、AWS内だけでなく、関連する外部サービスの認証情報も漏洩した前提でローテーションを検討します。

Security Group・Bucket Policy・KMS Policyなどの変更

攻撃者が外部公開設定を変更してアクセスを広げる場合があります。

Security Group、NACL、S3 Bucket Policy、KMS Key Policy、IAM Trust Policyなどに不審な変更がないか確認します。

アクセスキー漏洩後は、「キーが使われたか」だけでなく、「その権限で何を変更・取得できたか」まで確認することが重要です。

GuardDutyでアクセスキー漏洩の不正利用を確認する方法

GuardDutyを利用している場合は、アクセスキーを悪用した疑いのある検出結果がないか確認します。

関係するIAMエンティティ

どのIAMユーザーやロールに関連する検出なのか確認します。

漏洩したキーの所有者と一致するか、正規の利用者へ確認します。

Access key ID

GuardDutyの検出結果に含まれるAccess key IDと、漏洩したキーを照合します。

実行されたAPI

どのAWS APIが実行されたかを確認し、その操作が正規業務として想定されるものか判断します。

接続元IPアドレス

普段利用しているCI/CD環境、NAT Gateway、社内ネットワークなどのIPと一致するか確認します。

発生時刻

キーが公開されたと考えられる時刻と、GuardDutyの検出時刻を照合します。

CloudTrailとあわせて時系列を作成することで、漏洩から不正利用までの流れを整理しやすくなります。

AWSアクセスキーをCLIで無効化・確認・削除する方法

AWS CLIを利用できる場合は、アクセスキーの無効化、最終利用状況の確認、切り替え後の削除を行えます。

漏洩したアクセスキーをInactiveにする

aws iam update-access-key \ --user-name <IAM_USER> \ --access-key-id AKIAxxxxxxxxxxxxxxxx \ --status Inactive 

まず削除するのではなくInactiveにすることで、利用停止しながら影響確認を進められます。

アクセスキーの最終利用状況を確認する

aws iam get-access-key-last-used \ --access-key-id AKIAxxxxxxxxxxxxxxxx 

対象キーが最後に利用された日時やサービスを確認する際の参考になります。

ただし、これだけで被害範囲を確定せず、CloudTrailの詳細なAPI履歴も確認します。

必要に応じて新しいキーを作成する

aws iam create-access-key \ --user-name <IAM_USER> 

業務継続上どうしてもアクセスキーが必要な場合は、新しいキーを発行してアプリケーション側を切り替えます。

ただし、恒久的な対応としてはIAMロールやSTSによる一時認証情報への移行を検討します。

切り替え確認後に旧キーを削除する

aws iam delete-access-key \ --user-name <IAM_USER> \ --access-key-id AKIAxxxxxxxxxxxxxxxx 

アプリケーションの切り替えと動作確認後、漏洩した旧キーを削除します。

ただし、削除前後にCloudTrailなどの調査に必要な情報を記録しておくことが重要です。

ルートユーザーのAWSアクセスキーが漏洩した場合の対処法

ルートユーザーに紐づくアクセスキーが漏洩した場合は、IAMユーザーのアクセスキー漏洩よりも大きな影響が生じる可能性があります。

ルートアクセスキーを削除する

ルートユーザーの長期アクセスキーを利用している場合は、漏洩対応を機に削除します。

通常運用ではルートユーザーのアクセスキーに依存しない構成へ移行することが重要です。

ルートパスワードを変更する

アクセスキーだけでなく、ルートユーザーのパスワードも見直します。

同時期に他の認証情報まで漏れていないか確認します。

MFA設定を確認する

ルートユーザーのMFAが正しく設定されているか確認します。

見覚えのないMFAデバイスや認証手段が追加されていないかも確認します。

IAM管理者・ロール・信頼ポリシーを確認する

ルート権限が悪用された場合は、別の管理者ユーザーやロールを作成されている可能性があります。

管理者ポリシー、IAMユーザー、アクセスキー、ロール、信頼ポリシーなどを横断して確認します。

AWSアクセスキー漏洩で情報流出が発生していないか確認する

漏洩したキーにS3やSecrets Managerなどへのアクセス権限がある場合は、認証情報漏洩だけでなく、実際のデータ流出が起きていないか確認します。

S3オブジェクトが取得されていないか確認する

漏洩キーがS3へアクセス可能だった場合は、対象バケットやオブジェクトへの操作を確認します。

顧客情報、ログ、バックアップ、ソースコードなどが保存されている場合は、取得されたデータの範囲を整理します。

Secrets ManagerやSSMの認証情報を確認する

Secrets ManagerやSSM Parameter Storeのシークレットが読み出されている場合は、その中に含まれるデータベース認証情報や外部APIキーなども漏洩した可能性があります。

必要に応じて関連する秘密情報をローテーションします。

RDS・DynamoDBなどへのアクセスを確認する

対象キーがRDS、DynamoDBなどに関係する操作権限を持っていた場合は、その利用状況も確認します。

外部公開設定の変更を確認する

S3 Bucket PolicyやSecurity Groupなどが変更され、外部から直接アクセスできる状態にされていないか確認します。

単なる認証情報漏洩だけではなく、攻撃者が環境設定を変更して別のアクセス経路を作っていないかを確認する必要があります。

AWSアクセスキー漏洩後の再発防止策

AWSアクセスキーの漏洩を繰り返さないためには、長期アクセスキーを前提とした運用自体を見直すことが重要です。

IAMユーザーの長期アクセスキーを原則廃止する

長期アクセスキーをアプリケーションや利用者へ配布すると、漏洩時に影響が長期化しやすくなります。

可能な範囲でIAMロールやSTSによる一時認証情報へ移行します。

EC2・ECS・Lambda・EKSではIAMロールを利用する

AWS上で稼働するワークロードでは、アクセスキーをファイルや環境変数へ直接保存するのではなく、IAMロールを利用します。

これにより、長期認証情報をコードや設定ファイルへ埋め込む必要を減らせます。

人間のCLI利用はIAM Identity Centerへ移行する

管理者や開発者がCLIを利用する場合は、IAM Identity Centerなどを用いたSSO運用を検討します。

個人へ長期アクセスキーを配布する方式を減らすことが重要です。

GitHub・GitLab・CI/CDはOIDCフェデレーションを利用する

CI/CDではAWSアクセスキーをシークレットとして長期保存せず、OIDCフェデレーションを利用して短期認証情報を取得する方式へ移行します。

シークレット検出を導入する

Git pre-commit、GitHub secret scanning、CI上のシークレット検出などを利用し、アクセスキーがコミット・公開される前に検知できる仕組みを導入します。

GuardDuty、Security Hubなどの監視も組み合わせます。

CloudTrailを集中管理・改ざん耐性のある構成にする

CloudTrailは全リージョン・全アカウントで有効化し、ログを集中管理します。

ログ格納先を分離アカウントへ置くなど、侵害されたアカウントから簡単に削除・変更されにくい構成を検討します。

AWSアクセスキー漏洩の原因と被害範囲をフォレンジック調査で確認する方法

AWSアクセスキーが漏洩した場合、キーの無効化だけでなく、「どこから漏れたのか」「誰が利用したのか」「どのAWSリソースへアクセスされたのか」「情報持ち出しがあったのか」を確認する必要があります。

アクセスキーの漏洩元を確認する

GitHub、GitLab、開発端末、CI/CDログ、チャット、チケット、.env、コンテナイメージなど、どこからアクセスキーが外部へ露出したのかを確認します。

漏洩元が開発端末である場合は、単純な誤コミットだけでなく、マルウェアやインフォスティーラによる情報窃取も確認対象になります。

CloudTrailから不正API操作を確認する

CloudTrailを用いて、漏洩したAccessKeyIdによるAPI操作を時系列で整理します。

イベント時刻、接続元IP、userAgent、利用サービスなどを突き合わせ、正規利用と不正利用を切り分けます。

IAM権限昇格・永続化の有無を確認する

新しいIAMユーザー、アクセスキー、ロール、ログインプロファイルなどが作成されていないか確認します。

元のキーを止めても別の認証情報で侵入が継続できる状態が残っていないか確認することが重要です。

高額リソース・外部公開設定を確認する

全リージョンを対象に、EC2や高額サービスの不審な利用がないか確認します。

Security Group、Bucket Policy、IAM Trust Policyなどの設定変更も確認します。

データ持ち出しの有無を確認する

S3、Secrets Manager、SSM Parameter Store、RDS、DynamoDBなどから機密情報が取得されていないか確認します。

情報持ち出しが疑われる場合は、対象データを特定し、法務・個人情報保護担当と報告や通知の要否も検討します。

フォレンジック調査会社に相談する

AWSアクセスキー漏洩が判明したものの、単なるキー露出だけなのか、実際に第三者へ利用されたのか判断できない場合は、フォレンジック調査会社への相談を検討できます。

フォレンジック調査会社では、CloudTrail、GuardDuty、IAM、ネットワークや関連端末などの記録を確認し、アクセスキーがどこから漏洩したのか、不正API操作が行われたのか、権限昇格や永続化が行われたのか、データ持ち出しが発生した可能性があるのかを整理できます。

特に、CloudTrail停止やIAM権限変更、全リージョンでのリソース作成、S3・Secrets Managerへのアクセスなどが確認される場合は、単なる認証情報漏洩ではなく、AWS環境全体の侵害として調査範囲を広げる必要があります。

また、漏洩元がGitHubやCI/CDだけではなく開発端末にある可能性も考えられる場合は、端末側のマルウェア感染や認証情報窃取も含めて調査します。

原因と被害範囲を正確に確認するためには、アクセスキーの無効化と同時に、CloudTrail・GuardDuty・IAM・請求情報などの証跡を早期に保全することが重要です。

おすすめのフォレンジック調査会社

公式サイトデジタルデータフォレンジック

編集部が厳選したおすすめのフォレンジック調査会社は、デジタルデータフォレンジックです。

デジタルデータフォレンジックは、累計4万7千件以上の豊富な相談実績を持ち、全国各地の警察・捜査機関からの相談実績も409件以上ある国内有数のフォレンジック調査サービスです。

24時間365日の相談窓口があり、緊急時でも安心です。相談から見積りまで無料で対応してくれるので、フォレンジック調査の依頼が初めてという方もまずは気軽に相談してみることをおすすめします。

【厳格調査】デジタルデータフォレンジックの評判は？口コミや評価、料金体系からサービスを調査

2024.3.5

フォレンジックとは「パソコンやHDD、スマートフォンなどのデジタル端末に残されたログやデータ類を抽出し、サイバーセキュリティ調査や法的紛争支援などを行う」技術です。 その中でも【

【2026年版】ハッキング調査会社を見分けるポイント6選！費用相場や悪徳業者の特徴も解説

2024.3.5

「パソコンが遠隔操作され、詐欺にあったかもしれない…」 「会社のパソコンのログを確認したら、未知のIPアドレスから不正アクセスを受けた痕跡を見

まとめ

AWSアクセスキーが漏洩した場合は、実際に第三者へ悪用されている可能性を前提として、まず該当キーを無効化します。公開GitHubやCI/CDログ、チャット、チケット、.envなどからキーを削除しても、それだけでは安全とはいえません。

AKIAから始まるキーはIAMユーザーやルートユーザーに紐づく長期認証情報、ASIAから始まるキーはSTSによる一時認証情報です。特にルートユーザーのキーが漏洩した場合は、アクセスキー削除、ルートパスワード変更、MFA、IAM管理者や信頼ポリシーまで含めて緊急確認します。

CloudTrailでは、AccessKeyId、eventSource、eventName、sourceIPAddress、userAgent、時刻などを確認し、IAMユーザー・アクセスキーの新規作成、CloudTrail停止、高額リソース作成、S3・Secrets Managerへのアクセスなどを重点的に調査します。

また、全リージョンのリソースやCost Explorerも確認し、攻撃者が未使用リージョンでEC2などを作成していないか確認することが重要です。元のアクセスキーを止めても、新しいIAMユーザー、ロール、トークンなどが追加されていれば侵入が継続する可能性があります。

再発防止では、IAMユーザーの長期アクセスキーを減らし、EC2・ECS・Lambda・EKSにはIAMロール、人間のCLI利用にはIAM Identity Center、GitHubやCI/CDにはOIDCフェデレーションを利用する構成へ移行します。

AWSアクセスキー漏洩は、単なるキー交換ではなく、認証情報侵害インシデントとして扱うことが重要です。漏洩元、不正利用、権限昇格、永続化、課金悪用、情報持ち出しまで確認し、被害範囲が不明な場合はCloudTrailなどの証跡を保全したうえで、フォレンジック調査を検討します。