AWSセキュリティログとモニタリング: CloudTrail、CloudWatch、Config

可視性のないセキュリティはセキュリティシアター（見せかけのセキュリティ）です。最も洗練されたアクセス制御と暗号化を実装しても、環境で何が起きているかを見ることができなければ、侵害を検出したり、インシデントを調査したり、コンプライアンスを証明したりすることはできません。AWSは包括的なログとモニタリングサービスを提供しており、適切に設定すれば、クラウド環境の完全な可視性を得ることができます。

なぜセキュリティログが重要なのか

検出のギャップ

ほとんどのセキュリティ侵害はすぐには検出されません。業界調査は一貫して、組織が侵害を発見するまでに数ヶ月、時には数年かかることを示しています。この間、攻撃者はデータを持ち出し、永続性を確立し、環境内を横方向に移動できます。

この検出ギャップの主な理由は、不十分なログとモニタリングです。ログがなければ、悪意のある活動の証拠がありません。モニタリングがなければ、異常を監視する人がいません。

フォレンジックの要件

セキュリティインシデントが発生したとき、最初の質問は常に「何が起きたのか？」です。包括的なログがなければ、この質問に答えられない可能性があります。データがアクセスされたことはわかっても、誰が、いつ、どれだけアクセスしたかはわからないかもしれません。

効果的なログは、以下を可能にするフォレンジック記録を作成します：

侵害の範囲を特定する
攻撃ベクトルを理解する
影響を受けたリソースとデータを特定する
法的および規制上の開示要件を満たす

コンプライアンスの義務

ほとんどのコンプライアンスフレームワークはログとモニタリングを要求します：

PCI DSSはカード会員データへのすべてのアクセスの追跡を要求
HIPAAは保護対象医療情報の監査コントロールを要求
SOC 2はセキュリティコントロールの一部としてログを評価
GDPRはコンプライアンスを実証する能力を要求

適切なログがなければ、コンプライアンス監査は不可能になります。

AWS CloudTrail：API監査ログ

CloudTrailはAWSサービスに対して行われたAPI呼び出しを記録します。誰かまたは何かがAWSとやり取りするたびに—EC2インスタンスの作成、セキュリティグループの変更、S3オブジェクトへのアクセス—CloudTrailはそのイベントをキャプチャできます。

flowchart LR
    subgraph Sources["APIソース"]
        Console["AWSコンソール"]
        CLI["AWS CLI"]
        SDK["AWS SDK"]
        Service["AWSサービス"]
    end

    subgraph CloudTrail["CloudTrail"]
        Trail["証跡"]
    end

    subgraph Destinations["送信先"]
        S3["S3バケット"]
        CWL["CloudWatch Logs"]
        Lake["CloudTrail Lake"]
    end

    Sources --> CloudTrail
    Trail --> S3
    Trail --> CWL
    Trail --> Lake

    style CloudTrail fill:#f59e0b,color:#000
    style Destinations fill:#22c55e,color:#fff

CloudTrailが記録するもの

CloudTrailは以下をキャプチャします：

誰が：リクエストを行ったプリンシパル（ユーザー、ロール、またはサービス）
何を：実行されたAPIアクション
いつ：リクエストのタイムスタンプ
どこから：ソースIPアドレスとAWSリージョン
どのように：リクエストパラメータとレスポンス要素
結果：リクエストが成功したか失敗したか、およびその理由

この情報はセキュリティ調査に非常に価値があります。「誰がそのS3バケットを削除したのか？」や「誰がそのIAMポリシーを変更したのか？」に答える必要があるとき、CloudTrailには答えがあります。

管理イベント vs データイベント

CloudTrailは2種類のイベントを区別します：

管理イベントはコントロールプレーン操作—AWSリソースの作成、変更、または削除です。CreateBucket、RunInstances、AttachRolePolicyなどのアクションが含まれます。すべてのAWSアカウントはデフォルトの証跡で管理イベントログを取得します。

データイベントはデータプレーン操作—リソース内のデータへの実際のアクセスです。S3でのGetObject/PutObject操作、LambdaでのInvoke操作、DynamoDBでのQuery操作が含まれます。データイベントはデフォルトではキャプチャされず、明示的に有効にする必要があります。

この区別はセキュリティにとって重要です。管理イベントはインフラの変更を教えてくれます。データイベントはデータアクセスを教えてくれます。機密データには、おそらく両方が必要です。

証跡設定の決定

CloudTrailを設定する際、いくつかの決定がセキュリティ態勢に影響します：

マルチリージョン証跡：すべてのリージョンからイベントをキャプチャすべきか、特定のリージョンのみか？攻撃者は、監視していないことを知って、使用していないリージョンを標的にすることがよくあります。マルチリージョン証跡は完全な可視性を提供します。

組織証跡：AWS Organizationsでは、組織証跡がすべてのメンバーアカウントからイベントをキャプチャします。これにより監査ログが一元化され、個々のアカウントがログを無効にすることを防ぎます。

ログファイル整合性検証：CloudTrailはSHA-256ハッシュを使用して、ログが改ざんされていないことを検証できるダイジェストファイルを作成できます。これはフォレンジックの整合性とコンプライアンスに不可欠です。

ログ暗号化：ログは保存時の保護のためにKMSで暗号化する必要があります。これにより追加のアクセス制御も提供されます—キーアクセスを持つプリンシパルのみがログを読み取れます。

CloudTrail Insights

CloudTrail Insightsは機械学習を使用して異常なAPIアクティビティを検出します。正常な動作のベースラインを確立し、アクティビティが大幅に逸脱したときにアラートを出します。

Insightsが検出できるもの：

API呼び出し量の異常なスパイク
探査や設定ミスを示す可能性のあるエラー率の増加
異常なソースまたは異常な時間からのAPI呼び出し

数百万のAPI呼び出しを手動でレビューすることは現実的ではないため、この自動異常検出は価値があります。

CloudTrail Lake

CloudTrail LakeはCloudTrailイベントのマネージドデータレイクです。S3にログを保存してAthenaでクエリする代わりに、CloudTrail Lakeは以下を提供します：

イベントに対する直接のSQLベースのクエリ
マネージド保持（最大7年）
他のソースからのフェデレーションイベントとの統合
最近のイベントに対するより高速なクエリパフォーマンス

CloudTrail分析ニーズが多い組織では、Lakeがアーキテクチャを簡素化できます。

CloudWatch Logs：一元化されたログ管理

CloudTrailがAWS API呼び出しをキャプチャする一方、CloudWatch Logsはアプリケーションとシステムログを処理します。あらゆるログデータをCloudWatch Logsに送信できます—アプリケーションログ、Webサーバーアクセスログ、システムログ、カスタムアプリケーションメトリクス。

なぜログを一元化するのか

分散システムでは、ログは数十または数百のインスタンスに散在しています。問題を調査するとき、個々のサーバーにSSHしてログファイルを読む必要はないはずです。一元化されたログは以下を可能にします：

複数のシステム間の相関
統一された検索と分析
インスタンスのライフサイクルを超えたログ保持
ログパターンに対するリアルタイムアラート

ロググループ、ストリーム、保持

CloudWatch Logsはデータを階層的に整理します：

ロググループ：共有の保持とアクセス設定を持つログのコンテナ
ログストリーム：グループ内のログデータの個々のソース（通常、インスタンスまたはコンテナごとに1つ）
ログイベント：タイムスタンプ付きの個々のログエントリ

保持はロググループごとに設定可能で、1日から無期限まで選べます。セキュリティログの場合、保持要件を慎重に検討してください—コンプライアンスは多くの場合1年以上を義務付けますが、長期保持ではコストが蓄積します。

メトリクスフィルター：ログからメトリクスを作成

メトリクスフィルターはログデータをスキャンし、パターンが一致したときにCloudWatchメトリクスを作成します。これにより、非構造化ログデータが測定可能なシグナルに変換されます。

セキュリティに有用なメトリクスフィルターには以下が含まれます：

認証失敗の回数
特定のエラーコードの発生
既知の攻撃パターンの出現
予期しないIP範囲からのアクセス

メトリクスがあれば、しきい値を超えたときに通知するアラームを作成できます。

CloudWatch Logs Insights

Logs Insightsはログデータのインタラクティブなクエリを提供します。従来のgrepベースの検索とは異なり、Insightsはログ構造を理解し、以下を可能にします：

統計的集計（カウント、平均、パーセンタイル）
時系列の可視化
パターン検出
クロスロググループクエリ

セキュリティ調査では、Insightsを使用して「過去24時間にアクセス拒否エラーがユーザー別にいくつ発生したか？」といった質問にすばやく答えることができます。

サブスクリプションフィルター：リアルタイム処理

サブスクリプションフィルターはログデータをリアルタイムで他のサービスにストリーミングします：

Lambdaでカスタム処理
Kinesis Data FirehoseでS3、Redshift、またはOpenSearchに配信
Kinesis Data Streamsでカスタムアプリケーション

これによりリアルタイムセキュリティモニタリングが可能になります—重要なログパターンが表示されたら、すぐに自動応答をトリガーします。

AWS Config：構成コンプライアンス

AWS Configはリソース構成を継続的に監視および記録します。CloudTrailがどのアクションが発生したかを教える一方、Configは結果の状態とその状態が時間とともにどのように変化したかを教えます。

構成アイテムと履歴

各リソースについて、Configは以下を維持します：

現在の構成（すべての設定可能な属性）
他のリソースとの関係
構成変更の完全な履歴
変更が発生したタイムライン

この履歴記録はセキュリティに非常に価値があります。セキュリティグループがパブリックアクセスを許可するように変更された場合、Configは正確にいつそれが起きたか、以前の構成が何だったかを教えることができます。

Configルール：継続的コンプライアンス

Configルールは、定義されたポリシーに対してリソース構成を評価します。リソースが非準拠の場合、Configはそれをフラグします。

AWSは一般的なセキュリティ要件に対するマネージドルールを提供します：

S3バケットには暗号化が有効になっている必要がある
EC2インスタンスにはパブリックIPアドレスがあってはならない
IAMパスワードポリシーは複雑さの要件を満たす必要がある
CloudTrailが有効になっている必要がある
ルートアカウントにはMFAが有効になっている必要がある

組織固有のポリシーには、Lambda関数を使用してカスタムルールを作成することもできます。

コンプライアンスダッシュボード

Configは以下を表示するコンプライアンスダッシュボードを提供します：

全体的なコンプライアンスステータス
ルール別の非準拠リソース
時間経過に伴うコンプライアンス傾向
タイプ別のリソースインベントリ

コンプライアンス報告では、このダッシュボードがコントロールが適切に機能していることの証拠を提供します。

修復アクション

Configは、Systems Manager Automationドキュメントを使用して非準拠リソースを自動的に修復できます。リソースが非準拠になると、Configは：

暗号化されていないS3バケットで暗号化を有効にする
リソースに必要なタグを追加する
セキュリティグループルールを変更する
リソースでログを有効にする

自動修復は強力ですが、慎重な検討が必要です—リソースを自動的に変更すると、意図しない結果が生じる可能性があります。

VPC Flow Logs：ネットワーク可視性

Flow LogsはVPC、サブネット、またはネットワークインターフェイスレベルでネットワークトラフィックメタデータをキャプチャします。パケットの内容はキャプチャしません—接続メタデータをキャプチャします：ソース、宛先、ポート、プロトコル、バイト数、許可/拒否ステータス。

Flow Logsが明らかにするもの

Flow Logsはネットワークレベルのセキュリティ分析を可能にします：

偵察の検出：攻撃者がネットワークをスキャンすると、Flow Logsは単一のソースから多くのポートへの接続試行を示します。

データ流出の特定：異常なアウトバウンドトラフィックパターン—未知の宛先への大量のデータ転送—がFlow Logsに表示されます。

セグメンテーションの検証：Flow Logsはネットワークセグメンテーションが機能していることを証明します。2つのサブネットが通信すべきでない場合、Flow Logsはそれらの間にトラフィックが流れていないことを確認できます。

インシデント調査：侵害が発生したとき、Flow Logsはどのネットワーク通信が発生したかを示します—侵害されたインスタンスが何に接続し、何がそれに接続したか。

Flow Logsの宛先

Flow Logsは以下に送信できます：

CloudWatch Logs：リアルタイム分析とアラート用
S3：長期保存とAthenaでのバッチ分析用
Kinesis Data Firehose：他の宛先への配信用

コスト効率の良い長期保存にはS3が通常好まれます。リアルタイムアラートには、CloudWatch Logsが即座の分析を可能にします。

Flow Logsがキャプチャしないもの

制限を理解することが重要です：

169.254.169.254（インスタンスメタデータ）へ/からのトラフィック
DHCPトラフィック
VPC DNSサーバーへのトラフィック
Windowsライセンス認証トラフィック
Network Load Balancerへ/からのトラフィック

また、Flow Logsはサンプリングされます—特に高負荷下ではすべてのパケットをキャプチャしません。

Amazon EventBridge：イベント駆動型セキュリティ自動化

EventBridge（旧CloudWatch Events）はイベント駆動型アーキテクチャを可能にします。セキュリティにとって、これはセキュリティ関連イベントへの自動応答を意味します。

セキュリティイベントパターン

EventBridgeはAWSイベントのパターンにマッチできます：

IAM変更：ユーザーが作成されたとき、ポリシーが変更されたとき、アクセスキーが生成されたときにアラートをトリガー。

コンソールサインイン：特にルートアカウントの成功または失敗したコンソールログインにアラート。

セキュリティグループ変更：セキュリティグループが変更されたときに通知して、不正なアクセス変更を検出。

CloudTrail変更：誰かがCloudTrailを無効にしようとしたり、証跡を削除しようとしたりした場合に即座にアラート。

自動応答

EventBridgeのターゲットには以下が含まれます：

SNSで通知
Lambdaでカスタム修復
Step Functionsで複雑なワークフロー
Systems Managerで運用応答

例：ルートアカウントログインが検出されると、EventBridgeがLambda関数をトリガーし、セキュリティチームに通知し、セキュリティSIEMにイベントを記録し、インシデントチケットを作成します。

効果的なセキュリティモニタリングの構築

ログアーキテクチャ

完全なセキュリティログアーキテクチャには以下が含まれます：

flowchart TB
    subgraph Collection["1. 収集"]
        CT["CloudTrail"]
        VFL["VPC Flow Logs"]
        CWL["CloudWatch Logs"]
        Config["AWS Config"]
    end

    subgraph Storage["2. 保存"]
        S3["S3<br/>(長期)"]
        CWS["CloudWatch<br/>(リアルタイム)"]
    end

    subgraph Analysis["3. 分析"]
        Insights["Logs Insights"]
        Athena["Athena"]
        OS["OpenSearch"]
    end

    subgraph Alerting["4. アラート"]
        Alarms["CloudWatch Alarms"]
        EB["EventBridge"]
        SNS["SNS"]
    end

    subgraph Response["5. 応答"]
        Lambda["Lambda"]
        SSM["Systems Manager"]
        SF["Step Functions"]
    end

    Collection --> Storage --> Analysis --> Alerting --> Response

    style Collection fill:#3b82f6,color:#fff
    style Storage fill:#6366f1,color:#fff
    style Analysis fill:#8b5cf6,color:#fff
    style Alerting fill:#f59e0b,color:#000
    style Response fill:#22c55e,color:#fff

収集：API呼び出しのCloudTrail、ネットワークトラフィックのVPC Flow Logs、アプリケーションログのCloudWatch Logs、リソース状態のConfig
保存：適切なライフサイクルポリシーを持つ長期保持用のS3、短期リアルタイムアクセス用のCloudWatch Logs
分析：インタラクティブクエリ用のCloudWatch Logs Insights、S3ベースの分析用のAthena、全文検索と可視化用のOpenSearch
アラート：メトリクス用のCloudWatch Alarms、イベントパターン用のEventBridge、通知配信用のSNS
応答：自動修復用のLambda、運用タスク用のSystems Manager、複雑なワークフロー用のStep Functions

設定すべき重要なアラート

最低限、以下のアラートを設定してください：

ルートアカウントの使用（すべての活動）
CloudTrail設定の変更
IAMポリシーの変更
パブリックアクセスを許可するセキュリティグループの変更
しきい値を超える認証失敗の試行
異常な場所からのコンソールログイン
異常なIPアドレスからのAPI呼び出し

ログ保護

ログはセキュリティ上重要な資産です。保護してください：

不変性：S3 Object Lockを使用してログ削除を防止。攻撃者はしばしばログを削除して痕跡を隠そうとします。

暗号化：運用キーとは別のKMSキーでログを暗号化。

アクセス制御：ログを読み書きできる人を制限。ログ管理とログ読み取りに別々のIAMポリシーを使用。

クロスアカウントストレージ：侵害されたアカウントが自身の監査証跡を破壊することを防ぐために、アクセスが制限された別のアカウントにログを保存。

よくある間違い

データイベントを有効にしない：管理イベントはインフラの変更を示しますが、データイベントはデータアクセスを示します。機密データには両方が必要です。

不十分な保持：インシデントが数ヶ月後に発見されたとき、短い保持期間ではログがすでに削除されています。

リアルタイムアラートがない：モニタリングなしのログは単なるストレージです。アラートがなければ、侵害は気づかれません。

ログコストの無視：ログの保存と分析は高価になる可能性があります。適切なカバレッジを確保しながらコストを計画してください。

単一アカウントでのログ保存：監視対象と同じアカウントに保存されたログは、そのアカウントを侵害した攻撃者によって削除される可能性があります。

まとめ

AWSでのセキュリティログとモニタリングには、複数のサービスが連携して動作する必要があります：

サービス	目的	キャプチャするもの
CloudTrail	API監査	誰が何を、いつ、どこから
CloudWatch Logs	ログ集約	アプリケーションとシステムログ
AWS Config	構成状態	リソース構成と変更
VPC Flow Logs	ネットワーク可視性	接続メタデータ（内容ではない）
EventBridge	イベントルーティング	リアルタイムイベント駆動型自動化

重要な原則：

すべてをログに記録：すべてのリージョンでCloudTrailを有効化、すべてのVPCでVPC Flow Logsを有効化、すべてのアカウントでConfigを有効化
ログを保護：暗号化、別アカウント、不変性のためのオブジェクトロック
積極的にモニタリング：単なる保存ではなく、重要なイベントへのリアルタイムアラート
調査のために計画：ログは検索可能で、調査をサポートするのに十分な期間保持される必要がある
応答を自動化：EventBridgeとLambdaを使用した自動セキュリティ応答

可視性はセキュリティの基盤です。包括的なログと積極的なモニタリングなしには、盲目的に運用していることになります—攻撃がいつ発生するかを知るのではなく、発生しないことを願っているだけです。AWSはツールを提供しています。それらを効果的に設定し使用するのはあなたの責任です。

参考文献

AWS CloudTrail User Guide
Amazon CloudWatch Logs User Guide
AWS Config Developer Guide
VPC Flow Logs
Crane, Dylan. AWS Security. Manning Publications, 2022.
Muñoz, Mauricio, et al. Mastering AWS Security, 2nd Edition. Packt, 2024.