- Amazon GuardDuty
- CloudTrail
アマゾンウェブサービス(AWS)のアカウントで身に覚えのない請求やリソースが見つかった場合や、不審なアクティビティに関する通知が届いた場合は、第三者による不正利用の可能性があります。
被害の拡大を防ぐには、漏洩した可能性のある認証情報への対処や不審なリソースの停止・隔離など、初動対応を速やかに進めます。その後、CloudTrailやGuardDutyなどを活用して被害範囲や原因を調査し、再発防止につなげます。
本記事では、不正利用が疑われるときの確認方法、初動対応、被害範囲や原因の調査、不正な利用料金への対応、再発防止策、監視・運用体制について解説します。
不正利用は、身に覚えのない請求やリソース、AWSからの通知などをきっかけに発覚することがあります。まずは料金、利用中のリソース、セキュリティ通知に通常とは異なる動きがないかを見ます。
AWS Billing and Cost ManagementやAWS Cost Explorerで、料金が急増していないか、利用した覚えのないサービスやリージョンで費用が発生していないかを調べます。
前月までの利用状況と比べ、不自然に増えているサービスや普段使っていないリージョンがあれば、関連するリソースも確認します。ただし、設定変更や想定外のリソース稼働でも料金は増えるため、請求額だけで不正利用とは判断せず、ほかの兆候とあわせて見ます。
AWSマネジメントコンソールで、作成した覚えのないリソースやIAMユーザーなどがないかを調べます。普段使っているリージョンだけでなく、利用していないリージョンも対象にします。
特に、普段利用していないリージョンで多数のAmazon EC2インスタンスやスポットインスタンスのリクエストが作成されていないかは要確認です。侵害されたAWS認証情報を使ってAmazon EC2やAmazon ECSに暗号通貨マイニング環境を構築する攻撃も確認されています。2025年にAWSが公表した事例では、攻撃者が侵害したIAM認証情報でアクセスした後、10分以内に暗号通貨マイナーを稼働させていました。
不審なリソースを見つけた場合は、すぐに削除せず、対象のサービスやリージョン、作成時刻などを記録しておきます。
AWSから不審なアクティビティに関する通知が届いている場合は、対象となったアクセスキーやリソース、発生日時などを確認します。
Amazon GuardDutyを利用している場合は、不正な操作や認証情報の悪用を示すFindingが出ていないかも見ます。この段階では不正利用の兆候をつかむことを優先し、操作履歴や被害範囲の詳細はCloudTrailなどを使って調査します。
不正利用の可能性が高い場合は、漏洩した認証情報への対処や不審なリソースの停止・隔離など、被害拡大を防ぐ対応を優先します。
ただし、認証情報やリソースの変更・削除は、稼働中のシステムや原因調査に影響する場合があります。必要な情報を記録しながら進めます。
Palo Alto Networks Unit 42の調査では、GitHub上に公開されたAWS IAMの認証情報が5分以内に攻撃者によって検出・利用された事例があります。漏洩が疑われる場合は、被害の確認を待たずに対処します。
IAMユーザーのアクセスキーは、新しいキーへ更新したうえで元のキーを無効化し、アプリケーションなどの動作を確認してから古いキーを削除します。
IAMユーザーに「AWSCompromisedKeyQuarantineV3」というAWSマネージドポリシーが付与されている場合があります。これは、IAMユーザーの認証情報が侵害または公開された場合にAWSによって適用され、不正利用による被害を制限するためのポリシーです。自己判断で削除せず、この事象について作成されたAWSサポートケースの指示に従います。
IAMロールなどの一時的な認証情報が悪用されている場合は、アクセスキーの変更だけでは対処できません。必要に応じて既存のセッションを失効させるなど、認証方式に応じて対応します。
身に覚えのないルートユーザーのアクセスキーがあれば削除し、不審なサインインなどから侵害が疑われる場合はパスワードを変更します。MFAの設定状況や、アカウント復旧に利用するメールアドレスが第三者に変更されていないかも確認します。
ルートユーザーは通常の運用には使用せず、アクセスキーも作成しない運用が基本です。AWS Organizationsで管理するメンバーアカウントでは、ルートユーザー認証情報を集中管理し、削除する方法もあります。
不審なリソースを見つけても、直ちにすべて削除するとは限りません。削除すると、原因や影響範囲を調査するための情報が失われる可能性があります。
対象や状況を記録したうえで、ネットワークからの隔離、アクセス権限の制限、停止、削除などから適切な方法を選びます。
AWSから不審なアクティビティに関する通知を受け取っている場合は、必要な対処を行ったうえで、AWS Support Centerから実施内容を返信します。
初動対応の後は、ログやセキュリティの検出結果から、不正に行われた操作、影響を受けたリソース、悪用された認証情報を特定します。
AWS CloudTrailで、不正利用が疑われる時間帯のユーザーやロール、実行されたAPI、日時、AWSリージョン、接続元IPアドレスなどを調べます。
あわせて、CloudTrailの証跡設定が変更されていないかも確認します。攻撃者が痕跡を残さないためにログ記録を停止する場合があり、Amazon GuardDutyにはCloudTrailのログ記録が無効化されたことを検出するFindingもあります。GuardDuty自体の停止・無効化の有無も確認します。
CloudTrailのイベント履歴では、各AWSリージョンの過去90日間の管理イベントを確認できます。一方、Amazon S3のオブジェクトへのアクセスなどのデータイベントは表示されません。調査するには、事前に証跡やCloudTrail Lakeのイベントデータストアなどで対象のデータイベントを記録している必要があります。
不審なアクセスキーが特定できている場合は、その認証情報で実行された操作を追うことで、不正利用が始まった時点や変更内容を絞り込めます。
Amazon GuardDutyを利用している場合は、不正利用が疑われる時期のFindingを調べます。
認証情報の侵害が疑われるFindingでは、対象となるアクセスキー、API操作、実行回数、日時、接続元IPアドレスなどを確認できます。複数の不審な操作を関連付け、認証情報を悪用した攻撃の流れを示すAttackSequenceのFindingもあります。
CloudTrailのイベントと照合すると、どの認証情報から、どのリソースに対して操作が行われたのかを追いやすくなります。
不正利用によって作成・変更・削除されたリソースに加え、IAMユーザーやロール、ポリシーの変更、既存リソースの設定変更、データへのアクセスなども洗い出します。
第三者が新たな認証情報や権限を作成している場合は、最初に漏洩した認証情報を無効化してもアクセス経路が残ります。
調査結果は、その後の復旧やAWSサポートへの情報共有に利用します。
悪用されたアクセスキーやIAMユーザー、IAMロールなどを特定し、その認証情報がどのシステムやアプリケーションで使用されていたのかをたどります。
長期的なアクセスキーを使用していた場合は、ソースコードへの埋め込み、外部リポジトリへの公開、端末や開発環境での保存など、外部に露出した可能性がある場所を調べます。
あわせて、必要以上に広いIAM権限が付与されていなかったか、不要なユーザーやアクセスキーが残っていなかったかも確認し、不正利用につながった原因を切り分けます。
身に覚えのない料金が発生している場合は、利用状況を精査したうえで、AWSサポートへ相談します。
AWS Billing and Cost ManagementやAWS Cost Explorerで、料金が発生したサービス、リージョン、期間を整理します。
すでに削除したリソースでも、削除前の利用分は請求されます。CloudTrailの操作履歴などと照合し、不正利用が始まった時期と料金の規模を確認します。
請求に関する問い合わせでは、AWS Support Centerで「Account and billing support」のケースを作成できます。
問い合わせ時には、次の情報を整理しておきます。
不正利用に気づいた日時
不審な利用が確認された期間
対象のサービスやリージョン
不正に作成・変更されたリソース
確認した利用料金
漏洩した可能性のある認証情報
実施済みの初動対応
請求についてAWSサポートへ相談しても、第三者が利用したアクセス経路が残っていれば再び不正利用される可能性があります。
漏洩した認証情報や不要なIAMユーザーなど、不正利用の原因となった箇所まで対処したうえで復旧します。
不正利用への対応後は、原因となった認証情報や権限を見直し、異常を早期に検知できる状態を整えます。
MFA(多要素認証)を利用すると、パスワードが漏洩した場合でも第三者によるサインインを防ぎやすくなります。
特に、強い権限を持つユーザーの認証を保護します。AWSアカウントのルートユーザーにはMFAが必要で、通常の運用では使用せず、ルートユーザーでしか実行できない作業に限定します。
複数のAWSアカウントを利用している場合は、AWS IAM Identity Centerや外部のIDプロバイダーによる認証の一元管理も検討します。
不要なアクセスキーやIAMユーザーを削除し、長期的な認証情報への依存を減らします。
人によるアクセスにはIDプロバイダーを介した一時的な認証情報、ワークロードにはIAMロールなどの一時的な認証情報を利用します。IAMの権限は必要な操作だけを許可する最小権限を基本とし、不要なユーザー、ロール、ポリシー、認証情報が残っていないか定期的に見直します。
CloudTrailのログを保存・分析できる状態にし、不審な操作を追跡できるようにします。
GuardDutyでは、重要なFindingが発生した際に担当者へ通知し、対応を開始できる運用まで整えます。
不正利用で大量のリソースが作成されると、利用料金が急増することがあります。AWS Cost Anomaly Detectionでは、通常とは異なる支出パターンを検出し、メールやAmazon SNSなどで通知できます。
AWS Budgetsでは、実績値や予測値が設定したしきい値を超えた場合に通知できます。
AWSのセキュリティサービスを導入していても、アラートを確認する担当者や対応手順が決まっていなければ、対応が遅れる可能性があります。通知後に調査、封じ込め、復旧へ移れるよう、監視時間や役割、対応手順まで決めておきます。
営業時間外に重大なアラートが発生し、翌営業日まで確認されなければ、その間に被害が拡大する可能性があります。
システムの重要度や扱うデータ、許容できる対応時間を踏まえ、夜間や休日を含めてどの時間帯まで監視するかを決めます。
担当者、エスカレーション先、連絡方法に加え、認証情報の無効化やリソースの隔離など、想定される事象ごとの対応手順を整理します。
AWS Well-Architected Frameworkでは、セキュリティインシデントに備えてプレイブックを作成し、検知、分析、封じ込め、脅威の排除、復旧までの手順を定めることを推奨しています。担当者やAWS環境の変更にあわせて手順を見直し、定期的に訓練します。
24時間365日の監視やインシデント発生時の調査・対応を自社だけで継続することが難しい場合は、AWS環境に対応したマネージドセキュリティサービスなど、外部の運用支援を利用する方法があります。
外部サービスを選ぶ際は、監視する時間帯や対象サービス、アラート発生後の対応範囲、自社のAWS環境や利用地域に対応しているかを確認します。
AWSアカウントの不正利用が疑われる場合は、認証情報への対処や不審なリソースの停止・隔離を優先し、その後にCloudTrailやGuardDutyなどを使って被害範囲と原因を調査します。
復旧後は、同じ経路から再発しないよう認証・権限・監視を見直します。あわせて、異常を検知した際に誰が判断し、対応するのかまで決めておくことで、不正利用の早期発見と被害拡大の防止につながります。