AWSアクセスキー漏えい時の初動対応

冒頭要約

AWSアクセスキーがGitリポジトリ、CI/CDログ、チャット、共有ストレージ、端末から漏えいした疑いがある場合、公開した文字列を消すだけでは対応完了になりません。アクセスキーが有効で権限を持っていれば、第三者がAWS APIを操作し、リソース作成、データ参照、権限変更、課金発生などにつながる可能性があります。

最初にアクセスキーID、紐づくIAMユーザーまたは一時認証情報の発行元、発見時刻、露出場所を記録します。不正利用が疑われる場合は対象キーを無効化し、CloudTrail、GuardDuty、IAM権限、全AWSリージョンのリソース、請求・使用量を確認します。

この記事では、情シス、開発者、SRE、クラウド管理者、CSIRTが、検知から最初の15分、影響評価、復旧、再発防止へ進む順番を整理します。漏えいしたキーの動作確認や侵入再現は行わず、防御・確認・報告に必要な手順だけを扱います。

漏えいしたキーで接続テストをしない

有効性を確かめる目的でも、露出したアクセスキーをAWS CLI、SDK、検証スクリプトへ設定しないでください。信頼できる管理経路からIAMとログを確認し、対象キーの無効化を優先します。

AWSアクセスキーとは

AWSアクセスキーは、AWS CLI、SDK、APIなどからAWSへプログラムで認証するための認証情報です。通常はアクセスキーIDとシークレットアクセスキーを組み合わせて使います。一時認証情報には、これらに加えてセッショントークンと有効期限があります。

種類	主な発行元	漏えい時の確認点
長期アクセスキー	IAMユーザー、まれにルートユーザー	キーを無効化し、IAM権限、利用先、使用履歴、他の認証情報を確認する
一時認証情報	IAMロール、STS、フェデレーション、IAM Identity Center	発行元ロール、セッション、信頼ポリシー、有効期限、セッション失効の影響を確認する
アクセスキーIDだけ	ログや設定に識別子として現れる場合がある	IDだけでは通常認証できないが、シークレットやセッショントークンも露出していないか確認する

AWS GuardDutyの公式ガイドでは、長期キーとSTSの一時認証情報を区別し、対象がIAMユーザーかロールか、どのAPI操作が行われたかを確認するよう案内しています。キー文字列の見た目だけで判断せず、GuardDuty finding、IAM、CloudTrailの正規画面でプリンシパルを特定します。

読者別の影響：誰が何を確認するか

対象者	まず確認すること	主な責任
開発者・SRE	リポジトリ、CI/CD、環境変数、端末、デプロイ先	利用箇所の特定、代替認証への切り替え、エラー監視
情シス・クラウド管理者	IAMユーザー、ロール、ポリシー、Organizations、全リージョン	キー無効化、権限評価、横断調査、請求・アカウント情報確認
SaaS・連携管理者	外部SaaS、バックアップ、監視、データ連携	連携停止の影響、保存済みキー、再設定、ベンダー連絡
CSIRT・SOC	検知経路、露出期間、CloudTrail、GuardDuty、証跡	優先度判断、封じ込め、調査範囲、法務・経営への報告
個人開発者	個人AWSアカウント、GitHub、ローカル設定、請求	キー無効化、不審リソースと課金の確認、ルート保護

AWSアカウントを複数運用している場合、アクセスキーが属するアカウントだけでなく、引き受け可能なクロスアカウントロールや共有リソースも確認対象です。

まず確認すること：最初の15分チェックリスト

1. 発見した事実を記録する

発見日時と報告者を記録する
アクセスキーIDを記録する。シークレットアクセスキーやセッショントークンは記録へ貼らない
露出場所を特定する。公開リポジトリ、履歴、ログ、チャット、ストレージ、端末などを分ける
公開範囲と露出開始時刻を可能な範囲で記録する
AWS、GitHub、GuardDuty、SIEMなどの検知通知を原文のまま保全する
すでに削除・上書き・無効化した操作があれば、実施者と時刻を記録する

証跡のスクリーンショットやログを書き換えず、タイムゾーンも記録します。インシデント記録にはシークレット値そのものを残しません。

2. キーの種類と紐づくプリンシパルを特定する

GuardDuty findingやAWS通知にあるアクセスキーIDと対象リソースを確認する
長期キーならIAMユーザーかルートユーザーかを確認する
一時認証情報なら発行元ロール、セッション、信頼元を確認する
対象プリンシパルの所有者、用途、管理者、業務依存先を確認する
同じIAMユーザーに別の有効なキー、コンソールパスワード、サービス固有認証情報がないか確認する

ルートユーザーのアクセスキーだった場合は、アカウント全体へ影響し得る最優先インシデントとして扱います。日常運用に使わず、不要なルートアクセスキーは削除することがAWSの公式推奨です。

3. 対象キーを無効化する

不正利用が確認済み、または否定できない場合は対象キーを無効化する
重要ワークロードが依存する場合は、封じ込めと事業継続の担当を分けて同時に動かす
代替キーを作る前に、可能ならIAMロールや一時認証情報へ切り替えられないか判断する
代替キーが必要なら、別の安全な管理経路で作成し、最小権限で配布する
無効化後のアプリケーションエラー、ジョブ失敗、監視アラートを記録する

単なる定期ローテーションでは、新しいキーへ切り替えてから古いキーを無効化する手順が有効です。しかし、漏えいが疑われるインシデントで古いキーを長時間有効なまま残すと、被害が拡大します。確認済みの不正利用、管理者権限、ルートキー、高機密データへの到達がある場合は封じ込めを優先します。

4. 権限と到達範囲を確認する

対象IAMユーザーまたはロールの直接・グループ・管理ポリシーを確認する
Permissions boundary、SCP、セッションポリシー、条件を含む実効権限を確認する
引き受け可能なロールとクロスアカウントアクセスを確認する
S3、KMS、Secrets Managerなどのリソースベースポリシーも確認する
IAM Access Analyzerの外部アクセス検出結果を確認する
読み取り権限でも個人情報、バックアップ、ソースコード、秘密情報へ到達できるか確認する

優先度はキーの存在だけでなく、IAMとIAM Policyが許可する操作・リソース・条件で決めます。最小権限から外れた管理権限やワイルドカード権限があれば、調査範囲を広げます。

5. CloudTrail・GuardDuty・課金を確認する

CloudTrailでアクセスキーID、プリンシパル、時間帯、送信元、操作対象を確認する
現在のリージョンだけでなく、利用可能な全リージョンを確認する
GuardDutyの関連findingと前後の検知を確認する
新規リソース、権限変更、ログ停止、データ参照、認証情報作成の有無を確認する
Cost Explorer、請求、使用量、予算アラートで想定外の増加を確認する
AWS Supportから不規則な活動の通知があれば、Support Centerで内容を確認する

CloudTrail Event historyは、AWSアカウントで既定利用できる直近90日間の管理イベントをリージョン単位で確認できます。ただし、データイベント、90日より前、複数リージョン・複数アカウントの横断調査はEvent historyだけでは完結しません。trail、CloudTrail Lake、S3データイベント、組織ログなどの設定と保存状況を確認します。

初動対応：やること、やらないこと、記録すること

やること

信頼できる管理者セッションから対象キーとプリンシパルを特定する。
不正利用を否定できないキーを無効化し、依存ワークロードを安全な認証方式へ切り替える。
CloudTrail、GuardDuty、IAM、リソース、課金の証跡を保全する。
対象プリンシパルの実効権限とクロスアカウント到達範囲を確認する。
不審な変更を個別に記録し、正規変更と照合する。
影響があるサービス所有者、CSIRT、経営、法務、AWS Supportへ必要に応じて連絡する。
復旧確認後、古いキーを削除し、失効時刻を記録する。

やってはいけないこと

漏えいしたキーを使って有効性や権限を試さない
Git履歴やチャットから文字列を消しただけで対応を終了しない
証跡を取得する前に、IAMユーザーや不審リソースを一括削除しない
CloudTrail Event historyに何もないことだけで安全と断定しない
業務停止を恐れて、不正利用中の高権限キーを有効なまま残さない
既存の正規管理者まで同じ認証経路でロックアウトしない
シークレット値をチケット、メール、チャット、議事録へ貼らない
影響が不明なままGuardDuty findingを抑制・アーカイブしない

記録すること

項目	記録内容
検知	発見時刻、検知元、通知ID、報告者
認証情報	アクセスキーID、種類、IAMユーザー・ロール・アカウント、状態
露出	場所、公開範囲、開始・終了推定時刻、削除・非公開化時刻
封じ込め	無効化時刻、実施者、代替認証、停止したワークロード
権限	実効権限、ロール、SCP、リソースベースポリシー、対象データ
ログ	CloudTrail範囲、GuardDuty finding、保存期間、未取得のログ
影響	不審操作、変更リソース、データ、課金、外部アカウント
復旧	新認証方式、動作確認、旧キー削除時刻、監視期間
連絡	AWS Support、経営、法務、顧客、委託先への連絡判断

証拠保全の粒度と保管方法は、インシデント時の証拠保全に合わせます。

無効化と削除の違い：どちらを先に行うか

操作	状態	利点	注意点
無効化	キーをInactiveにし、通常は再有効化できる	不正利用を止めつつ、依存先の切り分けに使える	高権限キーを安易に再有効化しない。実施時刻を記録する
削除	キーを恒久的に削除する	古いキーを再利用できなくする	元に戻せない。削除前にアクセスキーID、最終利用情報、証跡を記録する
新規発行	代替キーを作る	既存ワークロードを切り替えられる	長期キーを増やす。古いキーを残せばリスクは解消しない
一時認証へ移行	IAMロールなどで期限付き認証情報を使う	長期シークレットの配布を減らせる	信頼ポリシー、対象リポジトリ、ブランチ、アカウントなどを絞る

AWS公式のアクセスキー更新手順は、依存先を新しいキーへ切り替え、古いキーを無効化して動作を確認し、不要と判断してから削除する流れです。一方、インシデント対応では、侵害継続の可能性と業務停止の影響を比較し、不正利用が疑われるほど無効化を前倒しします。

Secret Revocationは、古いキーを無効化して初めて完了します。新しいキーの発行だけをSecrets Rotationと考えないことが重要です。

影響確認：CloudTrailで見る観点

CloudTrailは「誰が、いつ、どのサービスへ、どの操作を要求したか」を追う中心的な証跡です。ただし、ログの有無だけで結論を出さず、正規の変更管理、IAM所有者、リソース所有者と照合します。

IAMと認証経路の変化

新しいIAMユーザー、アクセスキー、ログインプロファイル、ロール、ポリシーが作成されていないか
既存ユーザーやロールへ管理権限・権限昇格につながる変更がないか
ロールの信頼ポリシー、外部ID、OIDC・SAMLプロバイダーが変更されていないか
CloudTrail、GuardDuty、Config、Security Hub、ログ保存先が無効化・変更されていないか
新しい一時認証情報やロールセッションが発行されていないか

リソースとデータの変化

普段使わないリージョンにEC2、Lambda、コンテナ、データベースなどが作成されていないか
S3、スナップショット、AMI、KMSキー、Secrets Managerの共有・公開範囲が変わっていないか
データ参照、ダウンロード、コピー、削除を確認できるデータイベントやサービスログがあるか
バックアップ、ログ、監視、ネットワーク設定が変更されていないか
外部アカウントへの共有やクロスアカウントロール利用がないか

コストとアカウント情報の変化

前月・平常時と比べて使用量や請求見込みが急増していないか
すべてのリージョンに身に覚えのないリソースがないか
アカウント名、ルートメール、連絡先、支払い情報、Support caseに変更がないか
予算・請求アラートの宛先やしきい値が変更されていないか

Event historyだけではデータアクセスを網羅できない

CloudTrail Event historyは管理イベントが中心です。S3オブジェクトなどのデータ操作を確認するには、データイベントを記録していたか、対象サービスのアクセスログやアプリケーションログがあるかを確認します。未記録の範囲は「異常なし」ではなく「確認不能」と記録します。

発行済み一時認証情報も確認する

長期アクセスキーがSTSの一時認証情報を発行するために使われていた場合、元のキーを無効化しただけで調査が終わるとは限りません。CloudTrailでロール引き受けやセッション発行の有無を確認し、発行元ロール、セッション名、時刻、送信元、権限を特定します。

AWS IAMでは、ロールの既存セッションへ失効ポリシーを適用できますが、対象ロールの既存セッション全体へ影響する場合があります。IAM Identity Centerのpermission setで作られたロールやservice-linked roleには別の制約があります。影響する利用者・ワークロードを確認し、AWS公式手順と組織の緊急変更手続きに沿って実施します。

一時認証情報の対応では、次を分けて記録します。

長期キーそのものの状態
そのキーで発行された可能性がある一時認証情報
対象IAMユーザーまたはロールの現在の権限
リソースベースポリシーから許可される経路
セッション失効が正規業務へ与える影響

判断基準：危険度とエスカレーション条件

優先度	判断例	対応目安
緊急	ルートアクセスキー、管理者権限、不正API操作、未知のIAM変更、ログ停止、機密データアクセス、請求急増	直ちにキー無効化、CSIRT招集、全リージョン・全アカウント調査、AWS Support・経営・法務へ連絡
高	公開リポジトリでシークレットまで露出、権限範囲が広い、露出期間不明、一時認証情報発行の可能性	即時封じ込め、CloudTrail・GuardDuty保全、権限とデータ影響を優先調査
中	非公開場所だが閲覧者が不明、限定権限でも重要データへ到達、依存先が複数	当日中に無効化・切り替え、ログと所有者確認、監視強化
低	アクセスキーIDだけの露出でシークレット非露出を確認、キーは既にInactive、利用痕跡なし	記録を残し、周辺のシークレット露出、所有者、不要キーを確認

次のいずれかに当てはまる場合は、担当者だけで閉じずにエスカレーションします。

ルートユーザーまたは管理者相当のアクセスキーである
正規利用と説明できないCloudTrailイベントやGuardDuty findingがある
IAM、ロール、ポリシー、ログ、アカウント連絡先が変更されている
個人情報、顧客データ、秘密情報、バックアップへ到達できる
複数アカウント、Organizations、クロスアカウントロールへ影響し得る
全リージョンの調査を自組織だけで完了できない
AWSから不規則な活動・キー露出・請求に関する通知を受けた
顧客、委託先、規制当局への報告判断が必要である

記録テンプレート

件名: AWSアクセスキー漏えい疑い 初動記録

検知日時（JST / UTC）:
検知元・通知ID:
報告者 / 対応責任者:

AWSアカウントID:
アクセスキーID（シークレット値は記録しない）:
認証情報種別: IAMユーザー長期キー / ルートキー / STS一時認証情報 / 未確認
対象プリンシパル:
所有者・用途:

露出場所:
露出開始・終了の推定:
公開範囲・閲覧可能者:

キー無効化日時 / 実施者:
代替認証への切り替え:
キー削除日時 / 実施者:

実効権限・引受可能ロール:
対象リソース・データ:
確認したAWSアカウント・リージョン:

CloudTrail確認範囲・保存先:
GuardDuty finding:
不審操作・リソース・課金:
確認不能なログ・期間:

発行済み一時認証情報の確認:
セッション失効の判断:

業務影響:
エスカレーション先:
AWS Support case:
次回更新時刻:

よくある誤解

「アクセスキーIDが見えたので、直ちに認証できる」

通常、アクセスキーIDだけでは認証できず、対応するシークレットアクセスキーが必要です。ただし、同じファイル、履歴、ログ、チャットにシークレットやセッショントークンが露出していないかを確認し、キーIDから対象プリンシパルを特定します。

「GitHubから削除したので安全」

履歴、fork、clone、キャッシュ、CIログへ残っている可能性があります。公開場所の削除と、AWS側での無効化・影響確認は別の作業です。

「MFAを有効にしているのでアクセスキーは使われない」

長期アクセスキーによるAPI認証は、通常のコンソールサインインとは別経路です。MFAだけに頼らず、キー無効化、IAM権限、利用条件、ログを確認します。

「古いキーを無効化すれば、発行済みセッションもすべて消える」

一時認証情報は有効期限と発行元の権限に基づいて評価されます。CloudTrailでセッション発行を確認し、必要に応じてロールセッション失効や権限変更を検討します。失効操作が正規セッション全体へ与える影響にも注意します。

「CloudTrailに異常がないので不正利用はない」

Event historyは90日・管理イベント・リージョン単位などの制約があります。データイベントが未設定なら、オブジェクト単位の参照を確認できない場合があります。「異常なし」と「ログがなく確認不能」を分けます。

「90日ごとのローテーションだけで十分」

定期ローテーションだけでは、長期キーの保管・配布・所有者不明・古いキー残存の問題は解決しません。AWSは可能な限りIAMロールやフェデレーションによる一時認証情報を推奨しています。

再発防止：長期アクセスキーを減らす

人のアクセスをフェデレーションへ移す

従業員はIAM Identity Centerや外部IdPから一時認証情報を取得する
個人ごとのIAMユーザー長期キーを日常のCLI操作へ配布しない
ルートユーザーのアクセスキーを作成しない
ルートユーザーのMFA、回復用メール・電話、利用監視を整備する

ワークロードへIAMロールを割り当てる

EC2、ECS、LambdaなどAWS上のワークロードはIAMロールを利用する
GitHub Actionsなど外部CIはOIDCによるロール引き受けを検討する
信頼するリポジトリ、ブランチ、環境、AWSアカウント、属性条件を限定する
モバイルアプリや配布物へ長期アクセスキーを埋め込まない

残るキーを管理する

所有者、用途、AWSアカウント、利用先、作成日、最終利用、次回確認日を台帳化する
不要なIAMユーザー、アクセスキー、ロール、ポリシーを定期的に削除する
IAM Access Analyzerで外部アクセスとポリシーを確認する
キー作成権限を限定し、必要に応じてSCPやpermission boundaryでガードレールを設ける
Gitリポジトリ、CI/CD、チャット、ストレージでSecret Scanningを有効化する
GuardDuty、CloudTrail、予算アラート、SIEM通知を継続監視する
漏えい時の無効化、セッション確認、全リージョン調査、AWS Support連絡を演習する

再発防止の完了条件は「新しいアクセスキーを発行した」ではありません。長期キーを持つ箇所が減り、残るキーの所有者と権限を説明でき、漏えい時に短時間で止められる状態を目指します。

次に確認すること	CyberLensのページ
AWSの証跡と検知を理解する	CloudTrail、GuardDuty、IAM Access Analyzer
権限の広さを確認する	IAM、IAM Policy、最小権限、認証と認可の違い
シークレット漏えいを作業化する	Credential Exposure、GitHub secret leak対応チェックリスト、漏えい疑い初動テンプレート
他クラウドの違いを確認する	サービスアカウントキー漏えい時の初動対応
リポジトリ検知から対応する	GitHub Secret Scanningアラート初動対応
初動と証跡保全を学ぶ	インシデントレスポンス入門、インシデント時の証拠保全
知識を確認する	セキュリティ用語クイズ

公式情報・参考情報

Amazon GuardDuty: Remediating potentially compromised AWS credentials - 対象アクセスキー、IAMエンティティ、API操作、権限、正規利用かどうかを確認する公式手順。
AWS Support: Security checks - Exposed Access Keys - 露出したアクセスキーへの即時対応、身に覚えのないリソース、IAM、請求・使用量を確認する公式ガイド。
AWS IAM: Update access keys - 新しいキーへの切り替え、古いキーの無効化、動作確認、削除の公式手順。
AWS IAM: Security best practices in IAM - 人とワークロードに一時認証情報を使い、最小権限と認証情報棚卸しを行う公式推奨。
AWS IAM: Secure access keys - ルートユーザーのキーを作らず、IAMロールと一時認証情報を優先する公式ガイド。
AWS CloudTrail: Working with CloudTrail event history - Event historyの90日・管理イベント・リージョン単位という範囲と制約。
AWS IAM: Revoke IAM role temporary security credentials - ロールの既存セッションを失効させる際の影響と制約。
AWS IAM: Root user best practices for your AWS account - ルートアクセスキーを作成しないこと、MFA、回復経路、利用監視の公式推奨。

まとめ

AWSアクセスキーの漏えいを疑ったら、シークレット値を再利用せず、アクセスキーID、対象プリンシパル、発見時刻、露出場所を記録します。不正利用を否定できない場合はキーを無効化し、CloudTrail、GuardDuty、IAM権限、全リージョンのリソース、課金、発行済み一時認証情報を確認します。

CloudTrail Event historyに記録がないことや、公開ファイルを削除したことだけでは安全と断定できません。確認済みの事実、ログ設定の制約、確認不能な範囲を分けて記録し、ルート・管理者権限・不審操作・データ影響があれば直ちにエスカレーションします。復旧後はIAMロール、OIDC、IAM Identity Centerなどへ移行し、長期アクセスキーを持たない設計を再発防止の中心に置きます。

AWSアクセスキー漏えい時の初動対応：無効化・CloudTrail確認・再発防止

冒頭要約

AWSアクセスキーとは

読者別の影響：誰が何を確認するか