クラウドの検知とインシデント対応

なぜ検知と対応が「最後の防衛線」なのか

IAMの最小権限もネットワークの分離も、設定ミスやゼロデイによって突破される可能性があります。予防的統制(Preventive Control)がすべて機能しなかった場合に残るのは、検知的統制(Detective Control)だけです。監査ログが取得されていなければ、侵害が起きたこと自体に気づけず、攻撃者は数週間から数か月にわたって環境内に滞留できます。

典型的な検知アーキテクチャ

クラウドAPIへのすべての操作は監査ログサービスに記録され、そこから集約基盤(SIEM)へ転送されます。検知ルールと脅威インテリジェンスがこの経路上のゲートとなり、条件に一致したイベントだけがアラートとしてレスポンダーに届きます。

検知ルールの段階が「Security Gate」です。相関分析のロジックが弱ければ、正しいログが収集されていても異常を見逃し、逆に閾値が過敏すぎればアラート疲れ(Alert Fatigue)を引き起こします。

主要概念とAWS/Azure/GCPの対応

よくある設定ミス

• 監査ログの部分的な有効化 High Risk

  アカウント全体・全リージョンではなく一部のリージョンやプロジェクトのみで監査ログが有効化されており、盲点(ブラインドスポット)が生まれる。

• ログの短期保持・非エクスポート Medium Risk

  ログの保持期間が短すぎる、または改ざん耐性のある別アカウント/別ストレージへエクスポートされておらず、攻撃者がログを削除・改ざんできてしまう。

• 高シグナルイベントへのアラート未設定 High Risk

  root/グローバル管理者のログインやログ機能自体の無効化といった、明確に危険な操作に対してアラートが構成されていない。

• 脅威検知サービスの未有効化 High Risk

  GuardDuty / Defender for Cloud / Security Command Centerが一部のアカウント・サブスクリプション・プロジェクトでしか有効化されていない。

• インシデント対応手順の不在 Medium Risk

  検知後の役割分担・連絡フロー・封じ込め手順が文書化されておらず、実際の侵害時に対応が場当たり的になる。

攻撃シナリオ: 侵害後のログ無効化による痕跡隠蔽

攻撃者が漏洩したIAM認証情報を使ってクラウドアカウントに侵入した、という想定です。まず痕跡を消すことを優先します。

1. 侵害した認証情報の権限範囲を確認する。
2. アカウント内のCloudTrail証跡を列挙する。
3. 証跡を停止し、以降の操作が記録されないようにする。
4. 停止に気づかれる前に、S3バケットやEC2インスタンスの列挙・データ持ち出しを行う。

# 1. 認証情報の権限範囲を確認
$ aws sts get-caller-identity

# 2. アカウント内の証跡を列挙
$ aws cloudtrail list-trails

# 3. 証跡を停止して以降の操作を記録させない(攻撃ステップ)
$ aws cloudtrail stop-logging --name org-management-trail

# -- この stop-logging 呼び出し自体が、最も強いシグナルになる --
# GuardDutyは Stealth:IAMUser/CloudTrailLoggingDisabled として検出する

# 4. 停止に気づかれる前にリソースを列挙
$ aws s3 ls
$ aws ec2 describe-instances --region us-east-1

検知

ログ機能自体への操作と、ログイン挙動の異常という2種類のシグナルを組み合わせて監視します。

• StopLogging / DeleteTrail / UpdateTrailイベントは、それ自体が高優先度のアラート対象になる。
• 普段利用しない地域・ASNからのConsoleLogin、特にMFAなしでの成功ログイン。
• GuardDutyのStealth:IAMUser/CloudTrailLoggingDisabledやStealth:IAMUser/LoggingConfigurationModified系ファインディング。

SELECT eventTime, userIdentity.arn, eventName, sourceIPAddress, awsRegion
FROM cloudtrail_lake
WHERE eventName IN ('StopLogging', 'DeleteTrail', 'UpdateTrail')
   OR (eventName = 'ConsoleLogin'
       AND responseElements.ConsoleLogin = 'Success'
       AND additionalEventData.MFAUsed = 'No')
ORDER BY eventTime DESC;

是正

ログを即座に再開し、ログ設定の変更自体を高権限の承認プロセス配下に置き、今後同種の攻撃を即座に検知できるようにします。

# ログを再開
$ aws cloudtrail start-logging --name org-management-trail

# 証跡の削除保護を有効化
$ aws cloudtrail update-trail --name org-management-trail --enable-log-file-validation

# 侵害されたIAMユーザーの認証情報を無効化
$ aws iam update-access-key --access-key-id AKIA... --status Inactive --user-name compromised-user

# ログ停止イベントに対するアラートをEventBridge経由で構成
$ aws events put-rule --name detect-logging-disabled --event-pattern '{"source":["aws.cloudtrail"],"detail":{"eventName":["StopLogging","DeleteTrail","UpdateTrail"]}}'

実際に手を動かす

このページで扱った「ログ無効化を起点とした侵害の調査」を、実際のシナリオ形式で体験できます。Scenario → Architecture → CLI Commands → Misconfiguration → Detection → Remediation → Verification の流れで進めます。

実装チェックリスト

• 監査ログがアカウント/サブスクリプション/プロジェクト全体・全リージョンで有効化されている
• ログが分離された/改ざん耐性のある保存先(別アカウントのS3バケット等)にエクスポートされている
• ログ機能自体の無効化・変更イベントにアラートが構成されている
• GuardDuty / Defender for Cloud / Security Command Centerがすべての環境で有効化されている
• root/グローバル管理者アカウントのログインに個別のアラートが設定されている
• ログ集約基盤(SIEM)にすべてのクラウド環境のログが集約されている
• 検知 → トリアージ → 封じ込め → 根絶 → 復旧のインシデント対応runbookが存在し、定期的に演習している
• ログ設定の変更が最小権限化・承認プロセス配下に置かれている