AWSの不正アクセス調査方法｜CloudTrail・IAM・EC2の監査ログ確認

個人でWebサービスや検証環境、ポートフォリオを動かすためにAWSを利用しているエンジニアにとって、もっとも恐ろしいトラブルのひとつがアカウントの不正アクセスや乗っ取りです。

「GitHubに誤ってIAMアクセスキーをコミットしてしまい、数時間後に見知らぬ海外リージョンで高額なGPUインスタンスが数十台起動されていた」「身に覚えのない請求通知が届いてログインしたら、知らないIAMユーザーが勝手に追加されていた」といった被害は、個人開発者の間でも後を絶ちません。

AWSで「不正アクセスされたかもしれない」と感じたとき、焦って手当たり次第に画面をクリックしても、攻撃者がどこから侵入し、何を改ざんし、どのようなバックドアを残したのかを正確に把握することは困難です。被害の全容を解明し、完全に侵害を断ち切るためには、AWSが提供する監査ログサービスである AWS CloudTrail や IAM認証情報レポート を活用した論理的な調査手順が不可欠です。

この記事では、個人でAWSアカウントやEC2、S3を運用しているエンジニア向けに、CloudTrailのイベント履歴検索、IAMユーザー・アクセスキーの監査、EC2セキュリティグループの開放点検、S3の公開設定確認、そしてCost Explorerによる異常課金調査までをステップバイステップで体系的に解説します。

この記事で行うこと
前提条件・対象読者
注意点
1. AWSにおける不正アクセスの典型手口と調査の全体像
1. 想定される4大侵害パターン
2. CloudTrailイベント履歴で不審なAPI操作を追跡する手順
3. IAM認証情報レポートで全ユーザーとアクセスキーの利用状況を監査する
4. EC2とセキュリティグループの意図しない開放・不正起動の点検
1. 全リージョンのEC2インスタンス確認
2. セキュリティグループのインバウンドルール点検
5. S3バケットのパブリック設定とデータ流出リスクの点検
1. アカウント全体のブロックパブリックアクセス確認
2. 個別バケットのバケットポリシー点検
6. AWS BudgetsとCost Explorerで異常課金を早期覚知する
1. AWS Cost Explorerによる日別コストの追跡
2. AWS Budgetsで少額アラートを設定しておく
7. CloudTrail調査で確認できること・確認できないこと
1. CloudTrail単体で確認できること
2. CloudTrail単体では確認できないこと
  1. EC2インスタンスのOS内部ログ
  2. S3個別ファイルのダウンロード（デフォルト状態）
8. 不正アクセスを確認した場合の緊急初動対応チェックリスト
1. AWSサポートへの報告時のポイント
よくある質問（FAQ）
まとめ
次に読むおすすめ記事
参考情報

この記事で行うこと

AWSで発生する不正アクセスの典型的な侵入パターンと被害実態を把握する
CloudTrailのイベント履歴（Event history）を活用して不審なAPI操作を追跡する
IAM認証情報レポート（Credential Report）を出力し、全ユーザーとアクセスキーの最終使用履歴を監査する
警戒すべき重要API（RunInstances、CreateUser、AttachUserPolicy 等）の検索テクニックを身につける
EC2セキュリティグループやS3バケットの意図しない開放状態を点検する
AWS BudgetsやCost Explorerを活用して急激なコスト増加を検知・調査する
CloudTrail単体で確認できる範囲と、OS内部など確認できない範囲の境界線を正しく理解する
不正アクセスが確定した際に行うべき緊急初動対応手順を実行できるようにする

前提条件・対象読者

AWSマネジメントコンソールにサインインできる個人開発者・エンジニア
EC2、S3、LambdaなどのAWSリソースを個人または小規模チームで運用している方
アカウント乗っ取りや身に覚えのない課金が発生した際の調査手順を事前に把握しておきたい方
対象サービス：AWS CloudTrail、AWS IAM、Amazon EC2、Amazon S3、AWS Cost Explorer、AWS Budgets
最終確認日：2026年11月

注意点

CloudTrailのイベント履歴は過去90日分のみ無料保持される

AWSアカウント作成時から自動で有効化されているCloudTrailの「イベント履歴（Event history）」は、過去90日間の管理イベントを無料で閲覧できます。90日を超えた過去のログを調査したい場合は、事前にS3バケットへログを保管する「証跡（Trail）」を設定しておく必要があります。侵害に気づいた時点で過去90日を経過している場合、標準のイベント履歴からは追跡できなくなります。

OS内部のコマンド操作はCloudTrail単体では記録されない

CloudTrailが記録するのは「AWSのAPI呼び出し（コンソール操作、CLI、SDKによるリソース作成・変更・削除など）」です。EC2インスタンス内部にSSHログインした後に侵入者が実行したシェルコマンドや、Webサーバー上のファイルを改ざんした痕跡などは、CloudTrail単体では記録されません。OS内部の調査にはLinuxの認証ログ（/var/log/auth.log や /var/log/secure）やWebサーバーのアクセスログの直接確認が必要です。

不正リソースを慌てて即時削除すると証拠が消える場合がある

不審なEC2インスタンスを見つけた際、即座に終了（Terminate）してしまうと、インスタンス内のメモリやディスクに記録されていた攻撃元の痕跡が消失します。課金を止めるためにインスタンスの停止（Stop）やセキュリティグループの遮断を優先し、必要に応じてEBSスナップショットを取得してから証拠保全を行う判断が推奨されます。

1. AWSにおける不正アクセスの典型手口と調査の全体像

個人運用のアカウントで発生する不正アクセスの大半は、高度なゼロデイ攻撃ではなく、管理不備や認証情報の漏洩に起因します。

想定される4大侵害パターン

パターン1：IAMアクセスキーの漏洩と不正API呼び出し

GitHubの公開リポジトリへの誤コミットやローカル環境のマルウェア感染により、長期間有効なアクセスキー（AKIA...）が流出するケースです。攻撃者は自動スクリプトを用いて数分以内に世界中のリージョンでAPIを実行し、暗号資産マイニング用の高額GPUインスタンスを大量起動します。

パターン2：ルートユーザーのパスワード突破・乗っ取り

強力なパスワードを設定していなかったり、多要素認証（MFA）を設定していなかったルートアカウントにパスワードスプレー攻撃などで侵入されるケースです。侵入者は自身の管理下にあるMFAを勝手に紐付け、本来の所有者をコンソールから締め出します。

パターン3：特権昇格とバックドアの設置

一度侵入に成功した攻撃者は、発覚後も継続してアクセスできるよう、新たなIAMユーザーを作成（CreateUser）したり、既存の一般ユーザーに AdministratorAccess ポリシーを付与（AttachUserPolicy）して権限を最大化します。

パターン4：S3バケットの公開設定改ざんとデータ持ち出し

S3バケットのアクセス制限を解除（DeletePublicAccessBlock や PutBucketPolicy）し、機密データを外部へ持ち出したり、バケットをランサムウェアのように全削除・暗号化するケースです。

【AWS不正アクセス調査の全体フロー】

ステップ1: 被害の全体像と課金状況の把握（Cost Explorer / Budgets）
   │
ステップ2: 認証情報の監査（IAM 認証情報レポート / 最終使用日時）
   │
ステップ3: 操作履歴の深掘り調査（CloudTrail イベント履歴）
   │    ├─ 不審なサインイン（ConsoleLogin）
   │    ├─ 特権昇格・バックドア（CreateUser, AttachUserPolicy）
   │    └─ 不正リソース起動（RunInstances, CreateBucket）
   │
ステップ4: 露出箇所の点検（EC2セキュリティグループ / S3パケット設定）
   │
ステップ5: 侵害の封じ込めと修復（キー無効化・パスワード変更・サポート連絡）

2. CloudTrailイベント履歴で不審なAPI操作を追跡する手順

AWS CloudTrailは、アカウント内で実行されたすべてのアクション（マネジメントコンソールでの操作、AWS CLI、SDK、サービス間の連携など）を記録する監査ログ基盤です。

イベント履歴（Event history）の基本仕様

全リージョンにおいて、デフォルトで有効化されています。特別な初期設定を行わなくても、過去90日間の「管理イベント（リソースの作成、変更、削除など）」が自動で保存されており、無料で閲覧・検索できます。

マネジメントコンソールでの確認手順

AWSマネジメントコンソールにサインインし、検索バーに CloudTrail と入力してサービス画面を開きます。
左側のナビゲーションペインから イベント履歴（Event history）を選択します。
イベント履歴画面の上部にあるフィルターのドロップダウンメニュー（ルックアップ属性）を活用して、調査したい条件を指定します。

【主なルックアップ属性の指定項目】
- イベント名（Event name）：実行されたAPI名で絞り込み（例: ConsoleLogin, RunInstances）
- ユーザー名（User name）：実行したIAMユーザー名やルートユーザーで絞り込み
- イベントソース（Event source）：サービス単位で絞り込み（例: ec2.amazonaws.com, iam.amazonaws.com）
- リソース名（Resource name）：対象となったリソース名（インスタンスIDやバケット名）
- アクセスキー ID（Access key ID）：特定の漏洩疑いアクセスキーによる操作を特定

調査で真っ先に検索すべき警戒API一覧

サインイン関連のAPI

ConsoleLogin：AWSマネジメントコンソールへのログイン操作。イベントレコード内の responseElements.ConsoleLogin が Failure になっている連続履歴（パスワード総当たり）や、見覚えのない送信元IPアドレス（sourceIPAddress）からの Success がないか確認します。ルートユーザーによるログインは userIdentity.type が Root と記録されます。

IAM・バックドア設置関連のAPI

CreateUser：新しいIAMユーザーが作成されていないか
CreateAccessKey：既存または新規ユーザーに対して新しいアクセスキーが発行されていないか
AttachUserPolicy / AttachRolePolicy / AttachGroupPolicy：強力な管理権限（AdministratorAccess 等）が不正に付与されていないか
PutUserPolicy / PutRolePolicy：インラインポリシーによる不正な権限追加がないか
CreateLoginProfile：プログラム用だったIAMユーザーにコンソールログイン権限が付与されていないか

リソース乱造・高額課金関連のAPI

RunInstances：EC2インスタンスの新規起動。通常利用していないリージョン（例: アフリカ、中東、欧州など）や、高額なインスタンスタイプ（p4d.24xlarge や g5.12xlarge 等のGPUインスタンス）が起動されていないか
PurchaseReservedInstancesOffering：長期間の予約インスタンスを勝手に購入されていないか

防御無効化・証拠隠滅関連のAPI

StopLogging：CloudTrailのログ記録を停止しようとした形跡がないか
DeleteTrail：既存の監査証跡を削除しようとしていないか
DeletePublicAccessBlock：S3のブロックパブリックアクセスを強制解除していないか

AWS CLIを使用した効率的なイベント抽出

コンソールのGUI検索では単一属性の絞り込みに限定されますが、AWS CLIの aws cloudtrail lookup-events コマンドを使用すると、ターミナルから素早くJSON形式で取得・抽出できます。

# 直近に実行された不審なEC2起動（RunInstances）イベントを検索する例
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=RunInstances \
  --max-results 20 \
  --query 'Events[*].[EventTime,Username,Resources[0].ResourceName]' \
  --output table

# 特定のIAMユーザーが実行した直近の全イベントを時系列で確認する例
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=suspect-user \
  --max-results 50 \
  --query 'Events[*].[EventTime,EventName,SourceIPAddress]' \
  --output table

3. IAM認証情報レポートで全ユーザーとアクセスキーの利用状況を監査する

アカウント内に存在するすべてのIAMユーザー、ルートアカウント、アクセスキーの状態を網羅的に点検するもっとも強力な手段が「IAM認証情報レポート（Credential Report）」です。

認証情報レポートの出力手順

AWSマネジメントコンソールで IAM を開きます。
左側メニューの アクセス管理 から 認証情報レポート（Credential Report）を選択します。
レポートをダウンロード（Download Report）ボタンをクリックして、CSV形式のファイルをローカルに保存します。

AWS CLIを使用してターミナルから直接取得することも可能です。

# 認証情報レポートを生成してCSVとして保存するコマンド
aws iam generate-credential-report
aws iam get-credential-report --output text --query Content | base64 -d > credential_report.csv

レポートの重要チェック項目

ダウンロードしたCSVファイルをExcelやテキストエディタで開き、以下の列を横断点検します。

ユーザー名とルートアカウント（user列）

<root_account> および見覚えのない不審なIAMユーザーが存在しないかを確認します。

パスワードの利用状況（password_enabled / password_last_used列）

password_enabled が true にもかかわらず、自分がコンソールパスワードを設定した覚えのないユーザーが存在しないか点検します。また、password_last_used に自分がログインしていない日時のタイムスタンプが記録されていないか確認します。

アクセスキーの利用状況（access_key_1_active / access_key_1_last_used_date列）

access_key_1_active が true のキーについて、access_key_1_last_used_date（最終使用日時）、access_key_1_last_used_service（最後にアクセスしたサービス）、access_key_1_last_used_region（最後にアクセスしたリージョン）を確認します。普段開発を行っていない海外リージョンや、利用した覚えのないサービスが記録されている場合、そのアクセスキーは漏洩しています。

MFAの有効化状況（mfa_active列）

ルートアカウントおよびすべてのIAMユーザーで mfa_active が true になっているか確認します。false のまま放置されているユーザーは侵害の温床となります。

IAMコンソールでの「最終アクセス情報（Access Advisor）」の確認

個別のIAMユーザーやIAMロールが「実際にどのサービスにいつアクセスしたか」をGUIで直感的に確認したい場合は、各ユーザーの詳細画面にある 最終アクセス（Access Advisor）タブを開きます。許可されている権限（ポリシー）のうち、過去に一度もアクセスされていない不要なサービスや、直近数日間に身に覚えのないアクセスがあったサービスが一目で判別できます。

4. EC2とセキュリティグループの意図しない開放・不正起動の点検

攻撃者がEC2に侵入したり、不正なインスタンスを立ち上げた場合、外部から自由に通信できるようにセキュリティグループを改ざんするケースが極めて多く見られます。

全リージョンのEC2インスタンス確認

AWSではリージョンごとにリソースが分離されています。東京リージョン（ap-northeast-1）しか使っていないつもりでも、攻撃者はオハイオ、バージニア北部、フランクフルト、サンパウロなどの別リージョンにリソースを作成します。

AWSマネジメントコンソールの画面右上でリージョンを切り替えて、各リージョンの EC2 ダッシュボード を確認します。
もしくは、AWS Systems Manager の インベントリ や、AWS Resource Groups のタグエディタを利用して、全リージョンのリソースを一括スキャンします。

AWS CLIを使用すれば、全リージョンの稼働中インスタンスをシェルスクリプトで一括チェックできます。

# 全リージョンを走査して実行中のEC2インスタンスを一覧表示するコマンド例
for region in $(aws ec2 describe-regions --query "Regions[].RegionName" --output text); do
  echo "--- Checking region: $region ---"
  aws ec2 describe-instances --region "$region" \
    --filters "Name=instance-state-name,Values=running" \
    --query "Reservations[].Instances[].[InstanceId,InstanceType,LaunchTime,State.Name]" \
    --output table
done

セキュリティグループのインバウンドルール点検

セキュリティグループのインバウンド（受信）規則において、以下の危険な設定が放置されていないか確認します。

【危険なセキュリティグループ設定の例】
- ポート22（SSH）：ソースが `0.0.0.0/0`（全IPv4）または `::/0`（全IPv6）
- ポート3389（RDP）：ソースが `0.0.0.0/0` または `::/0`
- すべてのトラフィック（All Traffic）：プロトコル・ポート不問で全開放されている状態

SSHやRDPなどの管理ポートは、自宅やオフィスの固定IPアドレスに限定するか、AWS Systems Managerの Session Manager を利用してインバウンドポートを完全に閉じる構成が安全です。

5. S3バケットのパブリック設定とデータ流出リスクの点検

S3バケット内の重要データやバックアップが外部へ漏洩していないか、バケットの公開設定を点検します。

アカウント全体のブロックパブリックアクセス確認

AWSには、アカウント内のすべてのS3バケットに対してパブリックアクセスを一括遮断する安全機能が備わっています。

Amazon S3 コンソールを開きます。
左側メニューの このアカウントのパブリックアクセスブロック設定（Block Public Access settings for this account）を選択します。
以下の4つの項目がすべて オン（有効）になっていることを確認します。

【S3 ブロックパブリックアクセスの4大保護項目】
1. 新しいアクセスコントロールリスト (ACL) を介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックする
2. 任意のアクセスコントロールリスト (ACL) を介して付与されたバケットとオブジェクトへのパブリックアクセスを除外する
3. 新しいパブリックバケットポリシーまたはアクセスポイントポリシーを介して付与されたバケットとオブジェクトへのパブリックアクセスをブロックする
4. 任意のパブリックバケットポリシーまたはアクセスポイントポリシーを介したバケットとオブジェクトへのパブリックアクセスとクロスアカウントアクセスをブロックする

もし意図せず オフ に変更されていた場合、CloudTrailで DeletePublicAccessBlock または PutPublicAccessBlock APIを検索し、誰がいつ変更したのかを特定します。

個別バケットのバケットポリシー点検

各バケットの アクセス許可 タブを開き、バケットポリシー（Bucket Policy）に以下のような設定が含まれていないか確認します。 Principal: "*" かつ Effect: "Allow" で s3:GetObject が許可されている場合、全世界の誰でもURLを知っていればバケット内の全ファイルをダウンロードできる状態になっています。

6. AWS BudgetsとCost Explorerで異常課金を早期覚知する

不正アクセスの被害の多くは「月末の高額請求通知」によって初めて発覚します。これを防ぎ、数日〜数時間単位で異常を検知するための仕組みを整備します。

AWS Cost Explorerによる日別コストの追跡

マネジメントコンソールの右上にあるアカウント名をクリックし、請求およびコスト管理ダッシュボード（Billing and Cost Management）を開きます。
左側メニューから Cost Explorer を選択します。
コストと使用状況 のグラフで、粒度（Granularity）を 日別（Daily）に変更し、グルーピング（Group by）を サービス（Service）または リージョン（Region）に設定します。
直近数日間の棒グラフで、通常は数十円〜数百円程度の推移であるにもかかわらず、突如として数万円以上の急激なスパイクが発生していないか確認します。

AWS Budgetsで少額アラートを設定しておく

予期せぬ課金を早期に検知するために、AWS Budgetsで予算アラートを作成しておくことが極めて有効です。

請求およびコスト管理 の左側メニューから 予算（Budgets）を開きます。
予算を作成 をクリックし、コスト予算（Cost budget）を選択します。
予算額に、個人開発の月間想定費用（例: 5ドル、10ドルなど少額）を設定します。
アラート条件として「実際のコストが予算の100%に達したとき」および「予測コストが予算の100%を超えると見込まれたとき」に自身のメールアドレスへ即時通知が届くように設定します。

7. CloudTrail調査で確認できること・確認できないこと

不正アクセス調査において、CloudTrailの守備範囲と限界を正確に把握しておくことは、誤った安全宣言を出さないために不可欠です。

【AWS CloudTrailの調査範囲と限界】

┌────────────────────────────────────────────────────────┐
│ CloudTrailで確認できる領域（コントロールプレーン）     │
│  ├─ マネジメントコンソールへのログイン履歴             │
│  ├─ IAMユーザー・アクセスキーの作成・権限付与          │
│  ├─ EC2インスタンスの起動・停止・削除                  │
│  ├─ セキュリティグループの変更・ポート開放             │
│  └─ S3バケットの作成・ポリシー変更・削除               │
└────────────────────────────────────────────────────────┘
                           ▲
                           │ 調査の境界線
                           ▼
┌────────────────────────────────────────────────────────┐
│ CloudTrail単体では確認できない領域（データ・OS内部）   │
│  ├─ EC2内部でのLinuxシェル操作（history, マルウェア）  │
│  ├─ SSHログイン後の不正なプロセスの稼働・マイニング    │
│  ├─ Webアプリケーションの脆弱性を突いた侵入ログ        │
│  └─ S3個別オブジェクトのダウンロード（※要データイベント│
└────────────────────────────────────────────────────────┘

CloudTrail単体で確認できること

どのアカウント・ユーザー・アクセスキーがアクションを実行したか
どの日時に、どの送信元IPアドレスからAPIが呼び出されたか
どのリージョンの、どのAWSリソースが作成・変更・削除されたか
操作が成功したか、権限不足（AccessDenied）で失敗したか

CloudTrail単体では確認できないこと

EC2インスタンスのOS内部ログ

CloudTrailはハイパーバイザー外側のAPIを監視しているため、EC2のOSにログインした侵入者がどのようなコマンドを実行したか、バックドアスクリプトをどこに仕込んだかは一切記録されません。これらを調べるには、EC2インスタンス内の /var/log/auth.log や /var/log/secure、シェル履歴（~/.bash_history）、稼働中プロセス（ps aux）を直接調査する必要があります。

S3個別ファイルのダウンロード（デフォルト状態）

CloudTrailの無料イベント履歴で記録されるのは「管理イベント」のみです。「バケット内のどのオブジェクトを読み取ったか（GetObject）」というデータイベントは、追加設定を行って証跡を作成していない限り記録に残りません。

8. 不正アクセスを確認した場合の緊急初動対応チェックリスト

もしCloudTrailやIAMの調査で明らかな不正アクセスや侵入の痕跡が発見された場合は、直ちに以下の初動対応を順序立てて実行してください。

【不正アクセス発覚時の初動対応5大ステップ】

ステップ1: 漏洩した認証情報の即時無効化
   ├─ 不審なアクセスキーを「非アクティブ（Inactive）」に変更
   └─ 該当IAMユーザーのコンソールログインプロファイルを無効化

ステップ2: ルートアカウントの防衛
   ├─ ルートユーザーのパスワード変更
   └─ 物理セキュリティキーや認証アプリによるMFAの再設定

ステップ3: バックドアの全件排除
   ├─ 攻撃者が作成した未知のIAMユーザー・ロールを削除
   └─ 勝手に追加された管理者ポリシー（AdministratorAccess等）を剥奪

ステップ4: 不正リソースの隔離・停止
   ├─ マイニング等で不正起動されたEC2インスタンスの停止
   └─ 開放されたセキュリティグループの遮断

ステップ5: AWSサポートへのインシデント報告
   └─ サポートセンターから「アカウントおよび請求」のケースを起票

AWSサポートへの報告時のポイント

不正アクセスによって数万〜数十万円規模の身に覚えのない課金が発生した場合でも、自力で侵害を封じ込めた上でAWSサポートへ迅速にチケットを起票し、漏洩の経緯やCloudTrailの調査結果を誠実に説明することで、不正利用分の請求免除や調整を相談できるケースがあります。決してアカウントを放置せず、速やかに公式サポートへ連絡してください。

よくある質問（FAQ）

Q1. CloudTrailのイベント履歴で過去90日より前のログを見る方法はありますか？

標準の無料イベント履歴は90日間で自動的にローテーションされ、消去されます。90日より前のログを遡って確認することはできません。今後長期にわたってログを保管したい場合は、CloudTrailのコンソールから「証跡の作成（Create trail）」を行い、S3バケットへログを恒久保存する設定を行ってください。S3標準のストレージ料金がわずかに発生しますが、個人利用規模であれば月額数円〜数十円程度で運用可能です。

Q2. 侵害されたEC2インスタンスを調査する際、インスタンスを削除してしまってもよいですか？

直ちにインスタンスを終了（Terminate）することは避けてください。インスタンスを終了すると、ルートボリューム（EBS）が削除され、侵入者が残したログやマルウェアファイルなどの証拠が完全に消滅します。被害の拡大を止めるためには、まずセキュリティグループを全遮断するか、インスタンスを「停止（Stop）」状態にしてください。その後、EBSボリュームのスナップショットを取得して証拠保全を行った上で、削除等の判断を行ってください。

Q3. GitHubにアクセスキーをコミットしてしまいました。キーを無効化すれば安全ですか？

アクセスキーを非アクティブ（Inactive）または削除（Delete）することは必須の第一歩ですが、それだけでは不十分です。キーが無効化されるまでのわずか数分の間に、攻撃者によってバックドア用IAMユーザーが作成されていたり、別リージョンにEC2が立ち上げられている可能性があります。キーを無効化した後は、必ずCloudTrailのイベント履歴で該当キーが実行した全API履歴を検索し、副次的な侵害が発生していないかを徹底点検してください。

まとめ

AWSにおける不正アクセス調査の成否は、事実に基づいたログをいかに素早く、体系的に追跡できるかにかかっています。

CloudTrailのイベント履歴を活用し、過去90日間の管理イベントから不審なAPIコール（RunInstances, CreateUser 等）を特定する
IAM認証情報レポートを出力し、全ユーザー・全アクセスキーの最終使用日時とリージョンを網羅的に監査する
意図しない全開放（0.0.0.0/0）されたセキュリティグループや、S3バケットの公開設定を速やかに点検する
Cost ExplorerやAWS Budgetsを活用して、コストの異常急増を検知するアラート網を構築しておく
CloudTrailはAPI操作の記録であり、EC2内部のコマンド実行はLinux/WindowsのOSログを直接調べる必要がある

日頃からMFAの徹底やアクセスキーの最小化、予算アラートの設定を行っておくことが最大の防御となりますが、万が一異常を感じた際は、本記事の手順に沿って冷静にログを紐解き、確実な封じ込めを実施してください。

次に読むおすすめ記事

個人で運用するクラウド全般の不正アクセス調査入門や、侵害発覚時の技術的初動手順は、以下の記事で詳しく解説しています。

個人で運用するサーバーやクラウドの包括的なセキュリティ対策手順については、以下の完全ガイドもあわせて参考にしてください。

個人でできるセキュリティ対策まとめ｜情報漏洩から身を守る完全ガイド

大手企業、Webサービス、通信キャリア、金融機関からの「個人情報流出」のニュースが連日報じられています。「またか」と感じる一方で、「自分のデータも漏れているのではないか」「個人で防げることなどあるのだろうか」と無力感を抱く方も少なくありませ…