AWSは便利な一方で、アクセスキーの漏えいや過剰な権限付与、設定ミスなどが重なると、短時間で環境全体に影響が及ぶことがあります。請求額の急増や見覚えのないAPI実行に気づいた場合でも、復旧を急ぐあまり手当たり次第に削除してしまうと、後から「何が起きたのか」を説明できなくなることがあります。
特に初動対応を誤ると、攻撃の継続や二次被害につながるだけでなく、ログのローテーションや上書きによって証跡喪失の恐れが高まり、原因特定や再発防止が難しくなります。
そこで本記事では、AWSで不正アクセスが疑われた際の初動対応から、証拠となり得るデータの保全、復旧、連絡の要点までを具体的に解説します。
目次
AWSで不正アクセスが疑われるサイン
「不正アクセスかもしれない」と感じた段階で、まずは兆候を整理します。複数のサインが重なる場合は、早めに封じ込め判断へ進むことが大切です。
- 請求の急増や、見覚えのないリソース増加がある
- CloudTrailで、通常使わないAPI（IAM変更、権限付与、S3公開など）が実行されている
- 見覚えのないIAMユーザー・アクセスキー・ロール・IdP連携が追加されている
- セキュリティグループやNACLが緩められ、外部公開が増えている
- GuardDutyやSecurity Hubの重大アラートが急増している
AWSで不正アクセスが起きる主な原因
原因は1つとは限りません。典型パターンを押さえ、調査の当たりをつけることで、初動の迷いを減らせます。
アクセスキーの漏えいと長期運用
Gitリポジトリへの誤コミット、端末侵害、CI/CD設定の露出などでアクセスキーが漏れると、攻撃者はAPIでリソース作成や権限変更を行えます。長期キーが残っているほど、侵害の影響範囲が広がりやすくなります。
過剰権限と権限昇格の取り逃し
Administrator相当の権限や、iam:PassRole、sts:AssumeRoleなどの強力な権限が過剰に付与されていると、侵害後に横展開が進みます。権限の最小化ができていない場合、影響範囲の切り分けが難しくなります。
公開設定やネットワーク設定の見落とし
S3バケットの公開、セキュリティグループの0.0.0.0/0、管理ポートの露出などがあると、侵入の起点になります。設定変更が不正に行われた場合もあるため、変更履歴とあわせて確認します。
ルートアカウントの管理不備
ルートは最強権限のため、パスワード管理やMFAの不備があると致命的です。ルートの利用履歴や認証情報の状況は、初動で優先して確認します。
原因が複合している場合、関係ログを横断して時系列を作る必要があります。作業を進めるほど記録が上書きされるため、早い段階での整理が重要です。
AWSで不正アクセスが疑われた場合に最初にやること
侵害範囲の特定よりも先に、「これ以上操作させない」ための対応を行います。ただし、削除を急ぐのではなく、無効化と隔離を優先することが重要です。
怪しい認証情報を無効化して追加操作を止める
影響が疑われるIAMユーザー、アクセスキー、ロールの利用を停止し、追加のAPI実行を止めます。削除ではなく無効化を基本とし、後から検証できる状態を残すことが重要です。
- CloudTrail等で、疑わしい主体（IAMユーザー／AssumedRole）を特定します。
- 対象のアクセスキーを無効化し、必要に応じて当該ユーザーをログイン不可にします。
- 実施した変更（対象・時刻・担当者・根拠）を記録として残します。
外部通信を一時遮断して拡大を抑える
EC2、コンテナ、VPN経路など、不審な挙動が確認された資産については、セキュリティグループやNACLを用いて外部通信を一時的に制限します。業務影響を考慮しつつ、まずは攻撃の拡大経路を遮断します。
- 影響が疑われるリソース（EC2／ECS／EKS／VPN等）を一覧化します。
- 管理に必要な最小限の通信のみ残し、外部公開や不要ポートを一時的に閉鎖します。
- 変更前後の設定（ルール・適用先）をエクスポートして保管します。
ルートアカウントが疑わしい場合の緊急措置
ルートアカウントの侵害が疑われる場合は、最優先で対応が必要です。認証情報の更新とMFAの強制を行い、ルートを日常運用から切り離します。
- ルートアカウントのメールアドレスおよびパスワードを更新し、MFAを必ず有効化します。
- 支払い情報、連絡先、サポート設定など、ルートに紐づく変更がないか確認します。
- 以後はIAM管理者で運用し、ルートの利用は最小限に制限します。
状況が不明なまま触りすぎると証跡喪失の恐れがあるため、止血と記録の両立を意識することが重要です。
証拠となり得るデータの保全と原因特定
次に行うのは「ログと状態の固定化」です。原因特定と説明責任のために、関連ログやスナップショットを確保します。
監査ログとアクセスログを退避して残す
CloudTrail、CloudWatch Logs、VPCフローログ、S3アクセスログなど、後から検証できる記録を保全します。可能であれば別アカウントや別リージョンにコピーし、改変や欠落のリスクを下げます。
- 調査対象期間の目安（発見前後、異常が始まった時間帯）を決めます。
- 該当期間のログをエクスポートし、保管先（別アカウント／別リージョン等）へ退避します。
- 保全したファイルの保管場所、取得者、取得時刻を台帳として残します。
EC2やストレージのスナップショットを取得する
不審なEC2やEBS、RDSなどは、停止や作り直しの前にスナップショットを取得し、当時の状態を残します。復旧の都合で変更が必要な場合でも、元の状態が残っていれば検証が可能になります。
- 不審なインスタンス、ボリューム、データベースを優先度順に列挙します。
- スナップショット取得と同時に、関連する設定情報（SG、IAM、起動設定）も控えます。
- 取得後はアクセス制御を強め、保全データへの変更を最小化します。
侵害経路と影響範囲を時系列で洗い出す
CloudTrailで「どの主体が」「どのIPから」「どのAPIを実行したか」を追い、IAM変更、S3公開、セキュリティグループ変更、Lambda/EC2の改変、ユーザー追加、請求設定変更などを重点的に確認します。
- 最初の侵入が疑われる操作（初回の異常API）を起点に時系列を作ります。
- 影響資産を「アカウント/IAM」「ネットワーク」「データ/S3」「計算資源」の軸で整理します。
- 暫定結論と未確定点を分け、追加で必要なログや保全対象を明確にします。
再発防止として最低限やるべきAWSの設定
復旧後は、同じ入口を塞ぐことが最優先です。運用に組み込みやすい「最低限」から整備し、段階的に強化します。
IAMのベストプラクティスを徹底する
最小権限、ロール中心設計、長期アクセスキーの削減、パスワードポリシーとMFAの運用徹底が基本です。特にルートアカウントは日常運用から切り離し、必要時のみ使う運用へ移行します。
検知・監視を強化して早期発見できる状態にする
CloudTrailの全リージョン有効化、GuardDuty、Security Hubなどを有効化し、通知が実運用で見逃されない設計にします。検知後に誰が何をするかまで決めると、初動が早くなります。
ネットワーク公開範囲を縮小する
0.0.0.0/0の公開を極力避け、管理用アクセスはIP制限やVPN経由に限定します。公開が必要な場合はWAF等も含めて防御層を作ります。
インシデント対応プレイブックを整備する
「アクセスキー漏えい」「IAM侵害」「EC2乗っ取り」など、シナリオ別に手順書を作り、演習しておくことで実際の対応品質が上がります。連絡体制とログ保全の手順まで含めて整備すると安心です。
詳しく調べる際はフォレンジック調査会社に相談を
AWSの不正アクセス対応では、封じ込めと復旧だけでなく、侵入経路と影響範囲を事実として説明できる形に整えることが重要です。状況が複雑な場合や、対外説明や法的対応が視野に入る場合は、第三者性を担保できる専門調査を活用すると進めやすくなります。
サイバーセキュリティの専門業者に相談する
不審な兆候を確認した場合、原因と影響範囲を客観的に整理するために、専門業者への相談が有効です。復旧を急いで操作を重ねると、ログの保存期間や上書きの影響で証跡喪失の恐れが高まります。
専門業者であれば、クラウド上の操作履歴や構成差分、関連ログを横断して調査し、侵入経路や被害範囲を整理できます。社内外への説明が必要な場合も、第三者性のある調査報告書としてまとめられることがあります。
デジタルデータフォレンジックでは、官公庁、上場企業、捜査機関等を含む幅広いインシデントに対応経験があります。状況のヒアリングから初期診断・お見積りまで無料でご案内しています。
よくある質問
対応内容・期間などにより変動いたします。
詳細なお見積もりについてはお気軽にお問い合わせください。
専門のアドバイザーがお客様の状況を伺い、概算の見積りと納期をお伝えいたします。
可能です。当社は特定の休業日はございません。緊急度の高い場合も迅速に対応できるように、365日年中無休で対応いたしますので、土日祝日でもご相談下さい。
もちろん可能です。お客様の重要なデータをお取り扱いするにあたり、当社では機密保持誓約書ををお渡しし、機器やデータの取り扱いについても徹底管理を行っております。また当社では、プライバシーの保護を最優先に考えており、情報セキュリティの国際規格（ISO24001）およびPマークも取得しています。法人様、個人様に関わらず、匿名での相談も受け付けておりますので、安心してご相談ください。
この記事を書いた人
デジタルデータフォレンジック
エンジニア
