CloudWatch — ログの海から宝を見つける

CloudWatch について語る時ですね。一見シンプルに見えるサービスなんですが、セキュリティ運用の「目玉」になります。

CloudWatch の構造——三層アーキテクチャ

基本から。CloudWatch には Logs、Alarms、Insights という三つの層があります。

Logs——CloudTrail、VPC Flow Logs、Lambda ログなどを集約する層。ロググループとログストリームで階層化。

次に、メトリクスフィルター——CloudWatch Logs を数値化する層。「UnauthorizedOperation が発生したか？」って Yes/No を「メトリクス（数値）」に変換。

最後に、Alarms と Insights——メトリクスの閾値チェックと深掘り調査をする層。

ロググループ・ログストリームの設計

ログの整理方法が重要です。大事なのが「ロググループの保持期間」。つまり、何日でログを消すか。規制要件で「90日保持」と決まってたら、CloudTrail ロググループを put-retention-policy —retention-in-days 90 で設定。

セキュリティ規制がなければ「60日」とか「30日」で十分。長期保存が必要な場合は S3 アーカイブ（Kinesis Firehose 経由）で対応。

メトリクスフィルター——セキュリティ脅威の自動検知

ここからが勝負ですね。

重要な制約：メトリクスフィルターは「設定後のログのみ」をスキャンします。過去ログには遡及しません。つまり、「去年のログを今から監視する」は不可能。

不正な API コール検知

CloudTrail から UnauthorizedOperation をメトリクス化するパターン。マッチしたら、メトリクス値 = 1。カウント増加。

ルートアカウント使用の検知

Root ユーザーが操作するたびにカウント。Severity 最高レベル。

IAM 変更の検知

権限昇格の試みを即座に検知。

Logs Insights — 深掘り調査用クエリ

メトリクスフィルターじゃ足りないケースがあります。例えば「特定 IP から失敗ログインが5回以上」とか複雑な条件。そこが Logs Insights。このクエリで、ブルートフォース攻撃の兆候を30秒で発見。

注意。Logs Insights は 15分のタイムアウト制限がある。大規模ログだと結果行数が 10,000 行上限。統計処理で集約するか、時間範囲を絞り込む必要。

クロスアカウント集約 — マルチアカウント環境

企業規模だと複数アカウントがありますよね。「全アカウントの CloudTrail を一箇所に集約したい」——その場合、送信側アカウントが Assume Role で中央アカウントのロググループに PutLogEvents します。

流れは：

1. 送信側：クロスアカウント用 IAM ロール作成。ExternalId でセキュリティ強化。
2. 中央側：受信用ロググループのリソースベースポリシーで送信側ロールを許可。
3. CloudTrail の設定を「中央ロググループ」に指向。

結果として、セキュリティチームは「一つの中央ロググループ」でしか見ない。スケーラビリティ確保。

メトリクスフィルター + Alarms の組み合わせ

メトリクスをアラームに変換します。Threshold = 1、つまり「1回でもアラート」。Period = 300秒（5分）。

複合アラームという概念もある。例えば「IAM 変更 AND UnauthorizedOperation」という AND 条件をアラームで表現。

異常検出アラーム——機械学習ベース

Anomaly Detection アラームっていう機能があります。

過去2週間のデータから標準偏差を計算して、「いつもより異常に多い / 少ない」を自動判定。

例えば CloudTrail イベント数：通常 1000個/日、標準偏差 100、係数 2σ なら「正常範囲：800～1200」。実際 2000 個来たらアラート。

注意：14日間のデータがないと機能しません。新規 Alarms は最初の2週間は機械学習期間。

CloudWatch Agent — EC2 からのログ・メトリクス収集

重要。Amazon Linux 2 には標準搭載されてます。CloudWatch Agent を起動すれば：

ファイル監視（/var/log/secure, /var/log/audit/audit.log）、メトリクス収集（CPU, Disk, Network）、カスタムメトリクス。

すべてが CloudWatch に流れ込みます。

VPC Flow Logs との連携

ネットワークトラフィックを分析します。ポートスキャン、DDoS 前兆の検知が可能。

制限と落とし穴

重要な制限いくつか：

1. メトリクスフィルターは「設定後のログのみ」——過去ログに遡及しない。
2. Logs Insights は 15分タイムアウト。大規模クエリは時間範囲を絞り込む。
3. ロググループあたり最大10個のメトリクスフィルター。
4. CloudWatch Logs 暗号化は KMS キーとロググループが同一リージョンに必須。

クロスリージョン集約の複雑性

CloudWatch はリージョンサービス。東京 と バージニア のログを一箇所に集約したいなら、Lambda → Kinesis → 中央リージョン という複雑なパイプライン必須。

試験では「マルチリージョンの集約」って聞かれたら「複雑だから、同一リージョン運用を推奨」って答えるのが無難。

試験で狙われるポイント

必出：メトリクスフィルターが「過去ログに遡及しない」という制約。

必出：クロスアカウント集約は「送信側ロール」と「受信側リソースポリシー」の両方が必須。

よく出る：異常検出アラームの学習期間は「約2週間」。

まとめ

CloudWatch は「ログ集約」じゃなくて「セキュリティ監視の統合プラットフォーム」。

Logs で収集、メトリクスフィルターで数値化、Alarms で自動検知、Insights で深掘り調査——この四層をすべて使い倒すのが、本番環境のコツです。