Live:CloudOps Webinars & Hands-on Workshops ·Register ↗
メインコンテンツまでスキップ

CloudWatch Logs のセキュリティベストプラクティス

Amazon CloudWatch Logs のセキュリティ確保は、コンプライアンスの維持、機密データの保護、適切な監査証跡の確保に不可欠です。このガイドでは、重要な削除保護機能を含む、ログ グループに関する堅牢なアクセス許可制御とセキュリティ ポリシーを実装するための包括的なベスト プラクティスを提供します。

はじめに​

Amazon CloudWatch Logs を使用すると、システム、アプリケーション、AWS サービスからのログを単一の高度にスケーラブルなサービスに集約できます (Amazon CloudWatch Logs とは?)。ただし、適切なセキュリティコントロールがないと、ログデータは資産ではなく脆弱性になる可能性があります。このガイドでは、最小権限アクセス、暗号化、リソースベースのポリシー、削除保護、包括的な監査を実装して、ロググループを安全かつコンプライアンスに準拠した状態に保つことに焦点を当てています。

なぜこれが重要なのか​

セキュリティへの影響​

ログデータには、ユーザーアクティビティ、システム設定、API 呼び出し、および個人を特定できる情報 (PII) を含む機密情報が含まれていることがよくあります。ログへの不正アクセスは、インフラストラクチャ、アプリケーションの動作、およびビジネスオペレーションに関する重要なセキュリティの詳細を公開する可能性があります。さらに、ロググループの誤削除または悪意のある削除は、重要な監査証跡の損失やコンプライアンス違反につながる可能性があります。

コンプライアンス要件​

多くの規制フレームワークでは、アクセス制限、保管時および転送時の暗号化、保持ポリシー、削除保護、監査証跡など、ログデータに関する特定の管理が求められます。適切なアクセス許可管理と削除保護は、これらの要件を満たすための基本となります。

オペレーショナルエクセレンス​

適切に構造化された権限により、チームは必要なログにアクセスできる一方で、不要な変更や削除を防ぐことができます。このバランスにより、データの整合性を維持しながら、セキュリティと運用効率の両方をサポートします。

セキュリティのベストプラクティス​

CloudWatch Logs のセキュリティは、複数層のアクセス制御、削除保護、暗号化メカニズムを通じて動作し、これらが連携してログデータを保護します。包括的なセキュリティを実装するには、IAM ポリシー、削除保護、暗号化、リソースポリシー、継続的なモニタリングを組み合わせた多層的なアプローチが必要です。

1. CloudWatch Logs の階層とセキュリティ境界​

CloudWatch Logs アーキテクチャを理解することは、効果的なセキュリティコントロールを実装するための基本です。適切なログの整理と階層設計は、他のすべてのセキュリティ対策の基盤となります。

CloudWatch Logs は、セキュリティコントロールに直接影響する 2 レベルの階層を使用します (ロググループとログストリームの操作)。

  • ロググループ: 保持ポリシー、暗号化設定、アクセス許可、削除保護を定義する最上位のコンテナです。各ロググループは、独自の IAM ポリシーと KMS 暗号化キーを持つセキュリティ境界として機能します
  • ログストリーム: ロググループ内の個別のログイベントのシーケンスで、通常は単一のソース (EC2 インスタンス、Lambda 関数、アプリケーションプロセスなど) を表します。ログストリームは親ロググループからセキュリティ設定を継承しますが、きめ細かいアクセス制御のために IAM ポリシーで個別にターゲット設定できます

セキュリティ駆動型ロググループ設計​

セキュリティ要件とアクセスパターンに合わせてロググループ構造を設計します (CloudWatch Logs アクセス許可リファレンス)。

  • アプリケーションの分離: 特に機密データを扱う場合は、異なるアプリケーション用に個別のロググループを作成し、きめ細かい IAM ポリシーを有効にして、アプリケーション間のログアクセスを防止します
  • 環境の分離: 本番環境、ステージング環境、開発環境には別々のロググループを使用して、異なるアクセス制御と保持ポリシーを適用します
  • データ分類: ログを機密レベル (公開、内部、機密、制限付き) ごとにグループ化して、適切な暗号化、アクセス制御、保持ポリシーを適用します
  • コンプライアンス境界: 特別な取り扱いとより長い保持期間を必要とする監査ログ、セキュリティログ、コンプライアンス関連データ用に専用のロググループを作成します

Log Streams によるきめ細かなアクセス制御​

ログループが主要なセキュリティ境界を提供する一方で、ログストリームはきめ細かなアクセスパターンを可能にします (CloudWatch Logs のアクション、リソース、および条件キー)。

  • インスタンスレベルのアクセス: IAM ポリシーでログストリーム名を使用して、特定の EC2 インスタンスまたはコンテナからのログのみへのアクセスをユーザーに許可します
  • 時間ベースのアクセス: 作成時刻または命名パターンに基づいてログストリームへのアクセスを制限するポリシーを実装します
  • サービス固有のストリーム: アプリケーションが指定されたログストリームにのみ書き込みを許可し、同じロググループ内の他のストリームへのアクセスを防止します
  • 監査証跡の整合性: 監査およびコンプライアンス戦略の一部として、ログストリームの不変性 (作成後、ログイベントは変更できません) を使用します

2. アイデンティティベースのポリシー (IAM ポリシー)​

  • IAM ポリシーを使用して、ロググループとログストリームを作成、読み取り、管理できるユーザーを制御します (CloudWatch Logs のアイデンティティベースのポリシーの使用)

    • 最小権限の原則を適用する: 組織のニーズに基づいて特定のロググループへのアクセスを制限するカスタマー管理ポリシーを作成します
    • 特定のリソース ARN を使用する: IAM ポリシーでは、ワイルドカード (*) を使用するのではなく、常に明示的なロググループ ARN を指定します。これにより、権限昇格を防ぎ、ユーザーが意図したロググループにのみアクセスできるようにします
    • 管理権限と運用権限を分離する: 異なる権限レベルに対して個別のポリシーを作成します。たとえば、アナリスト向けの読み取り専用アクセス、アプリケーション向けの書き込み権限、インフラストラクチャチーム向けの管理権限などです。これらを単一の過度に許可されたポリシーに組み合わせないでください
    • 削除操作を明示的に拒否する: 重要なロググループについては、削除保護を超えた追加の保護を提供するために、削除操作に対する明示的な拒否ステートメントを実装します

  • CloudWatch にログを記録する Lambda 関数の場合、IAM ロールに最低限必要な権限が含まれていることを確認してください。 logs:CreateLogGroup, logs:CreateLogStream、および logs:PutLogEvents (Lambda 実行ロール)

  • ログループを変更または削除できる特権アカウントに MFA を実装します (アクセス許可の管理の概要)

  • タグベースのアクセス制御を実装する: ロググループのリソースタグと IAM 条件キー (aws:ResourceTag) を使用して、環境 (本番/開発)、チーム所有権、データ分類レベルなどの属性に基づいてアクセスを動的に制御できます (CloudWatch Logs のアクション、リソース、および条件キー)

3. 重要なロググループの削除保護​

削除保護は、Amazon CloudWatch Logs によって導入された重要なセキュリティ機能で、ロググループとそれに関連するログストリームの誤削除や悪意のある削除を防ぎます。有効にすると、削除保護は明示的に無効化されるまですべての削除操作をブロックし、重要な運用データとコンプライアンスデータの保護に役立ちます。この機能は、トラブルシューティング、分析、規制要件のために保持する必要がある監査ログ、コンプライアンス記録、本番アプリケーションログを保護する上で特に有用です。(ロググループを削除から保護する)

主な特徴​

  • 予防的コントロール: 削除の試行が発生する前に停止する予防的セキュリティコントロールとして機能します
  • 明示的な無効化が必要: 削除操作を実行する前に明示的に無効化する必要があります
  • ログストリームに適用: ロググループとその中のすべてのログストリームを保護します
  • パフォーマンスへの影響なし: ログの取り込み、クエリ、その他の操作には影響しません
  • 監査証跡: 削除保護ステータスへのすべての変更は CloudTrail に記録されます

重要なユースケース - 削除保護を有効にすべき場合​

  • 監査ログ: すべての監査ログは、コンプライアンスを維持し、監査証跡の改ざんを防ぐために、削除保護を有効にする必要があります
  • セキュリティログ: AWS CloudTrail、VPC Flow Logs、アプリケーションセキュリティログを含むセキュリティ関連のログ
  • コンプライアンスログ: 規制コンプライアンスに必要なすべてのログ
  • 本番アプリケーションログ: トラブルシューティングとインシデント対応に必要な本番ログ
  • 長期保持ログ: 保持要件が 1 年を超えるすべてのログ

実装のベストプラクティス​

  • 重要なロググループで有効化: すべての重要なログについて、ログループの作成時または既存のロググループで削除保護を有効にします。これは、偶発的または悪意のある削除に対する第一の防御線です
  • デプロイの自動化: AWS CloudFormation、AWS CDK、Terraform などの Infrastructure as Code (IaC) ツールを使用して、新しいロググループの作成時に削除保護を自動的に有効にします。これにより、環境全体で一貫したセキュリティ体制が確保されます
  • 手順の文書化: 削除保護を無効にする時期と方法について、明確なドキュメントとランブックを作成します。これには、承認ワークフロー、正当化要件、再有効化手順を含める必要があります。これにより、絶対に必要な場合にのみ保護が一時的に無効化されることが保証されます
  • 変更の監視: 重要なロググループで削除保護が無効化されたことを検出するために、CloudWatch アラームとメトリクスフィルターを作成します。これが発生した場合は、変更が承認されたものかどうかを調査するために、セキュリティチームに直ちに警告します
  • 多層防御: 削除保護を、削除操作を明示的に拒否する IAM ポリシーと組み合わせて使用します。これにより多層防御が提供されます。削除保護が無効化された場合でも、IAM ポリシーによって不正な削除を防ぐことができます

複数の保護レイヤーを組み合わせる​

4. カスタマー管理 KMS キーによる暗号化​

機密性の高いロググループには、カスタマー管理 KMS キーを実装して、暗号化キーの完全な制御を維持し、キーのローテーションを有効にし、キー使用の詳細な監査証跡を作成します。

暗号化アーキテクチャ​

暗号化のベストプラクティス​

  • 機密ログに対して KMS 暗号化を有効にする: 機密データを含むロググループには、カスタマー管理の KMS キーを関連付けます。これにより、キーポリシーによる強化された制御が提供され、キーローテーションが有効になり、すべての暗号化/復号化操作の詳細な CloudTrail ログが作成されます
  • 適切な KMS キーポリシーを設定する: KMS キーポリシーは、CloudWatch Logs サービスプリンシパル (logs.amazonaws.com) 権限を付与し、暗号化と復号化にキーを使用できるようにします。特定のロググループと AWS アカウントに使用を制限する条件を含めます
  • キーローテーションの実装: CloudWatch Logs で使用する KMS キーの自動キーローテーションを有効にします。AWS は、以前のキーバージョンで暗号化されたデータへのアクセスを維持しながら、カスタマー管理キーを年に 1 回自動的にローテーションします
  • KMS キー使用状況の監視: CloudTrail を使用して、ログ暗号化キーに関連するすべての KMS API 呼び出しを監視します。過度な復号化操作や不正なキーアクセス試行などの異常なパターンについてアラートを送信する CloudWatch アラームを設定します

5. データ保護ポリシー​

CloudWatch Logs データ保護は、機械学習とパターンマッチングを使用してログ群内の機密データを検出、保護、監査するための機能です (マスキングによる機密ログデータの保護)。この機能は、個人を特定できる情報 (PII)、認証情報、財務データなどの機密情報をログイベントから自動的にスキャンし、設定に基づいてデータを監査またはマスキングします。データ保護ポリシーは、ログイベントが取り込まれる際にリアルタイムで動作し、アプリケーションやログソースに変更を加えることなく即座に保護を提供します。

  • データ保護ポリシーの設定: CloudWatch Logs データ保護ポリシーを実装して、マネージド型データ識別子を使用して機密情報を自動的に検出およびマスクします (個人を特定できる情報 (PII))
  • 保護オペレーションの選択: セキュリティ要件に基づいて、監査オペレーション (機密データの監視とレポート) または非識別化オペレーション (機密データのリアルタイムマスキング) を設定します (機密データタイプの CloudWatch Logs マネージド型データ識別子)
  • 包括的なデータカバレッジ: 以下を含む複数のカテゴリの機密データを保護します。
    • 認証情報: AWS シークレットキー、SSH プライベートキー、PGP プライベートキー、PKCS プライベートキー
    • 金融情報: クレジットカード番号、銀行口座番号、セキュリティコード
    • 個人情報: メールアドレス、氏名、住所、IP アドレス、車両識別番号
    • 地域固有情報: 運転免許証、納税者番号、郵便番号などの国固有の識別子
  • キーワード近接検出: 機密データパターンの 30 文字以内でキーワードをスキャンする高度な検出を活用して、誤検出を削減します
  • グローバルカバレッジ: データ保護ポリシーは、ロググループの地理的位置に関係なく機能し、ISO 国コードを使用した地域固有のデータ識別子をサポートします
  • Amazon Macie との統合: CloudWatch Logs と連携して Amazon Macie を使用することで、AWS 環境全体で機密データの検出と分類を強化します (AWS ブログ: Amazon CloudWatch Logs Data Protection が機密ログデータの検出と保護にどのように役立つか)

6. ログの保持とライフサイクル管理​

CloudWatch Logs のログ保持期間は、ログイベントが自動的に削除されるまでの保存期間を制御し、コンプライアンス要件とストレージコストのバランスを取るのに役立ちます (CloudWatch Logs でログデータの保持期間を変更する)。デフォルトでは、CloudWatch Logs はログデータを無期限に保存しますが、ロググループレベルで 1 日から 10 年までの保持期間を設定できます。適切なライフサイクル管理により、規制要件、運用ニーズ、コスト最適化の目標に基づいて、機密データを適切な期間保持し、不要になったデータを自動的に削除できます。

  • 保持期間の設定: コンプライアンス要件と運用ニーズに基づいて、ロググループに適切な保持期間を設定します。デフォルトでは、ログデータは無期限に保存されますが、1 日から 10 年までの保持期間を設定できます (CloudWatch Logs でログデータの保持期間を変更する)
  • データ分類に基づくポリシーの適用: データの機密性と分類に基づいて、異なる保持ポリシーを実装します。
    • 重要/監査ログ: コンプライアンス要件のための長期保持 (7 年以上)
    • セキュリティログ: フォレンジック分析のための延長保持 (1〜3 年)
    • アプリケーションログ: トラブルシューティングのための中期保持 (30〜90 日)
    • デバッグ/開発ログ: コスト最適化のための短期保持 (1〜7 日)
  • コストの最適化: コンプライアンスニーズとストレージコストのバランスを取るために、保持期間を定期的に見直して調整します。保持期間が終了すると、古いログデータは自動的に削除されます
  • ライフサイクル管理のためのタグ付け: 環境、アプリケーション、データ分類、保持要件ごとにロググループを分類するために、一貫したタグ付け戦略を使用して、自動化されたポリシー適用を実現します (Amazon CloudWatch Logs でロググループにタグを付ける)
  • 一元化との統合: ログの一元化を使用する場合は、コンプライアンス要件を維持するために、ソースアカウントと宛先アカウント全体で保持ポリシーが一貫して適用されるようにします

7. ログ送信先のリソースベースのポリシー​

CloudWatch Logs のリソースベースのポリシーは、クロスアカウントサブスクリプションを有効にするために送信先に特化して使用されます (クロスアカウントクロスリージョンサブスクリプション)。アイデンティティベースの IAM ポリシーを使用するロググループとは異なり、送信先はリソースベースのポリシーをサポートしており、外部の AWS アカウントが Kinesis Data Streams、Kinesis Data Firehose、Lambda 関数などの送信先リソースにロググループをサブスクライブできるかを指定します (アクセス許可の管理の概要)。

Destination とは何か、およびリソースベースのポリシーを使用するタイミング​

  • ログ送信先: 送信先は、サブスクリプションフィルターからログデータを受信できる AWS サービス (Kinesis Data Streams、Kinesis Data Firehose、Lambda 関数) を表す CloudWatch Logs リソースです
  • クロスアカウントログストリーミング: 他の AWS アカウントが自身のログデータを集中処理インフラストラクチャにストリーミングできるようにする場合は、送信先でリソースベースのポリシーを使用します
  • 集中ログ処理: 複数のアカウントが統合分析、セキュリティモニタリング、またはコンプライアンス処理のために、中央アカウントの Kinesis ストリームまたは Firehose にログを送信するシナリオを有効にします
  • サードパーティ統合: 厳格なアクセス制御を維持しながら、パートナーアカウントまたはサービスプロバイダーが処理システムにログデータを送信できるようにします

送信先のリソースベースポリシーのベストプラクティス​

  • 正確なソースアカウントを指定する: 送信先ポリシーでは、サブスクリプションの作成を許可する AWS アカウント ID を明示的に指定します。アカウント ID にワイルドカード (*) を使用しないでください (ステップ 1: 送信先を作成する)
  • 最小権限アクセスを使用する: 必要最小限のアクセス許可のみを付与します - 通常は logs:PutSubscriptionFilter 特定の送信先 ARN に対して
  • 条件キーの実装: IAM 条件キーを使用して、送信元 IP 制限、時間ベースのアクセス、または MFA 要件などの追加のセキュリティレイヤーを追加します
  • 定期的なポリシー監査: 送信先ポリシーを定期的に確認して、現在の要件を引き続き反映していることを確認します。廃止されたアカウントのアクセスを削除し、過度に許可されたポリシーを厳格化します
  • サブスクリプションアクティビティの監視: CloudTrail を使用して監視します PutSubscriptionFilter および DeleteSubscriptionFilter どのアカウントが送信先へのサブスクリプションを作成または削除しているかを追跡するための API 呼び出し

8. AWS Organizations を使用したログの一元化​

ログの一元化は、クロスアカウントおよびクロスリージョンの一元化ルールを使用して、複数のメンバーアカウントと AWS リージョンからログデータを一元化されたアカウントに自動的にレプリケートする AWS Organizations の機能です（クロスアカウントクロスリージョンログの一元化）。この機能により、リソースベースのポリシーやクロスアカウント IAM ロールを必要とせずに、AWS インフラストラクチャ全体にわたる一元化された監視、分析、コンプライアンスを改善するためのログ統合が効率化されます。この機能は、バックアップリージョンの設定や、ソースアカウントからコピーされたロググループの暗号化動作の完全な制御など、運用およびセキュリティ要件を満たすための設定の柔軟性を提供します。

AWS セキュリティリファレンスアーキテクチャの整合性​

AWS Security Reference Architecture (AWS SRA) のベストプラクティスに従い、CloudWatch Logs の一元化は、全体的なセキュリティアカウント構造と整合させる必要があります (AWS Security Reference Architecture)。

  • ログアーカイブアカウントを委任管理者として指定: 専用のログアーカイブアカウントを AWS Organization の CloudWatch 委任管理者として設定します。このアカウントは、セキュリティ関連のすべてのログの取り込みとアーカイブ専用とし、制御されたアクセスメカニズムを備えた不変ストレージを提供します
  • セキュリティ OU への一元化: すべての CloudWatch Logs 一元化ルールを、セキュリティ組織単位 (OU) 内のログアーカイブアカウントにログをレプリケートするように設定し、本番ワークロードからの分離と一貫したセキュリティコントロールを確保します
  • 既存のログインフラストラクチャとの統合: ログアーカイブアカウントの既存のセキュリティインフラストラクチャ (カスタマー管理 KMS 暗号化キー、IAM アクセス制御パターン、VPC エンドポイント、他のセキュリティログ用に既に確立された監視フレームワークを含む) を活用しながら、CloudWatch Logs を一元化されたロググループのプライマリストレージとして維持します
  • 多層防御の実装: 他の重要なログに使用されているのと同じセキュリティ原則 (最小権限アクセス、カスタマー管理 KMS キーによる暗号化、不変性のための削除保護、包括的な監視) を適用します

ログ集約のベストプラクティス​

  • 組織構造の確立: Log Archive アカウントを CloudWatch 委任管理者として指定し、組織全体のすべてのメンバーアカウントからログをレプリケートする一元化ルールを作成します
  • 一貫したセキュリティコントロールの適用: すべての一元化されたロググループに統一されたセキュリティポリシーを実装します。以下を含みます。
    • 暗号化: Log Archive アカウントで他のセキュリティログ用に既に確立されている同じカスタマー管理 KMS キーを使用します
    • アクセスポリシー: 既存のログアクセスコントロールおよび職務分離と整合性のある一貫した IAM ポリシーを適用します
    • 保持期間: コンプライアンス要件を満たし、既存のログライフサイクル管理と統合する保持ポリシーを設定します
  • 一元化の健全性の監視: CloudWatch メトリクスとコンソール監視を使用して、一元化ルールの健全性ステータスを追跡し、レプリケーションの問題を特定し、すべてのメンバーアカウントからの継続的なログフローを確保します
  • 既存のログソースとの統合: CloudWatch Logs の一元化を、Log Archive アカウントに既に流入している他のログソース (CloudTrail、VPC Flow Logs、GuardDuty の検出結果) と調整し、統一されたログ管理と分析を実現します
  • データレジデンシーのための複数の一元化ルールの設定: データレジデンシーとコンプライアンス要件に対応するために、複数の一元化ルールを使用します。
    • リージョンデータレジデンシー: 異なるリージョンに対して個別の一元化ルールを作成し、GDPR、データ主権法、または組織のポリシーで要求される特定の地理的境界内にログデータが確実に留まるようにします
    • コンプライアンスベースの分離: 業界固有のコンプライアンス要件を満たすために、異なるタイプの機密データ (金融、医療、個人データ) に対して個別の一元化ルールを設定します
    • マルチリージョンバックアップ戦略: データレジデンシーの制約を尊重しながら、災害復旧のために重要なログを複数のリージョンにレプリケートする一元化ルールを実装します
    • 選択的ログルーティング: 一元化ルールフィルターを使用して、データ分類とレジデンシー要件に基づいて、特定のログタイプを適切な宛先アカウントとリージョンにルーティングします
  • 一元化の健全性の監視: CloudWatch メトリクスとコンソール監視を使用して、一元化ルールの健全性ステータスを追跡し、レプリケーションの問題を特定します
  • 一元化されたセキュリティコントロールの実装: すべての一元化されたロググループに一貫したセキュリティポリシー、暗号化設定、アクセスコントロールを適用し、統一されたセキュリティ体制を維持します

9. CloudWatch Logs の VPC エンドポイント​

VPC エンドポイントを使用して、VPC と CloudWatch Logs 間にプライベート接続を確立し、ログトラフィックを AWS ネットワーク内に保持し、ネットワーク分離によってセキュリティを強化します。

  • プライベート接続を有効にする: インターフェイス VPC エンドポイントを使用して、インターネットを経由せずに CloudWatch Logs にログを送信します (インターフェイス VPC エンドポイントでの CloudWatch Logs の使用)
  • 複数のエンドポイントのサポート: CloudWatch Logs には 2 つの VPC エンドポイントが必要です。
    • com.amazonaws.region.logs 標準の CloudWatch Logs API の場合
    • com.amazonaws.region.stream-logs StartLiveTail や GetLogObject などのストリーミング API 用
  • FIPS エンドポイントのサポート: FIPS 準拠のエンドポイントを使用します (logs-fips および stream-logs-fips) コンプライアンスのために必要な場合
  • VPC エンドポイントポリシーを実装する: エンドポイントポリシーを使用して、VPC エンドポイント経由の CloudWatch Logs アクションを制限します。例えば、ログの作成と取り込みのみを許可し、管理操作を防止します
  • VPC コンテキストキーを活用する: 使用 aws:SourceVpc および aws:SourceVpce IAM ポリシーの条件キーを使用して、CloudWatch Logs が特定の VPC エンドポイント経由でのみアクセス可能であることを確認します
  • ネットワーク境界セキュリティ: 機密性の高いセキュリティおよび監査情報を含むログは、管理されたネットワーク境界内に留まり、パブリックエンドポイント経由での偶発的なデータ流出を防ぎます

10. モニタリングと監査​

包括的なログ記録を有効にする​

  • CloudTrail ログ記録を有効化: すべてのリージョンで CloudTrail が有効になっており、CloudWatch Logs API 呼び出しをログに記録するように設定されていることを確認します。監視と分析のために、CloudTrail が CloudWatch Logs ロググループに直接イベントを送信するように設定します (CloudWatch Logs へのイベントの送信)
  • 不正なアクセス試行や異常なパターンを検出するために CloudWatch アラームを設定します (Amazon CloudWatch アラームの使用)
  • Organizations を使用して複数のアカウント間で一元化されたログ記録を実装します (CloudWatch Logs でのクロスアカウントログデータ共有)
  • IAM ポリシーを通じてログの削除を防止することで、不変の監査証跡を維持します
  • 機密性レベルが異なるアプリケーション用に個別のロググループを作成します

モニタリングのベストプラクティス​

  • ログ取り込みメトリクスの監視: 組み込みの CloudWatch メトリクスを使用して、ログ取り込みパターンを追跡し、異常を検出します (CloudWatch Logs メトリクス)。

    • IncomingLogEvents: 取り込まれたログイベントの数を監視して、セキュリティインシデント、アプリケーションの問題、または未承認のログソースを示す可能性のある異常な急増または減少を検出します
    • IncomingBytes: 取り込まれるログデータの量を追跡して、過度なログ記録によるデータ流出の試みやサービス拒否攻撃の可能性を特定します
    • DeliveryErrors: 失敗したログ配信を監視します。これは、ログの送信先への改ざんや監査証跡に影響を与えるインフラストラクチャの問題を示している可能性があります
    • ベースラインしきい値の設定: 通常の取り込みパターンを確立し、許容可能な変動範囲を超える偏差に対して CloudWatch アラームを作成します

  • 異常検出のために CloudWatch Contributor Insights を活用する: Contributor Insights を使用してログデータパターンを分析し、異常なアクティビティを特定します (CloudWatch Contributor Insights を使用した高カーディナリティデータの分析)。

    • トップトーカー分析: 最も多くのログを生成している送信元 (IP アドレス、ユーザーエージェント、API エンドポイント) を特定し、潜在的な不正使用、ボットアクティビティ、またはセキュリティ脅威を検出します
    • エラーパターン検出: エラーログを分析して、異常なエラーパターン、認証失敗の試行、またはセキュリティインシデントを示す可能性のある疑わしいアクセスパターンを特定します
    • リソース使用状況のモニタリング: 最も多くのログデータを生成しているユーザー、アプリケーション、またはサービスを追跡し、潜在的な誤用または不正なアクティビティを特定します
    • 時間ベースの分析: 時系列分析を使用して、営業時間外の異常なアクティビティパターンや、侵害を示す可能性のある予期しないトラフィックスパイクを検出します

  • セキュリティイベントアラームを作成する: メトリクスフィルターとアラームを設定して、不正なロググループの削除、削除保護の変更、アクセス許可の変更、暗号化キーの関連付け解除、または異常なクエリパターンなどの疑わしいアクティビティを検出します (メトリクスフィルターの作成)

  • CloudWatch ダッシュボードを設定して、セキュリティメトリクスとアクセスパターンを可視化します (Amazon CloudWatch ダッシュボードの使用)

  • CloudWatch Logs Insights を使用して、高度なログ分析と異常検出を行います (CloudWatch Logs Insights によるログデータの分析)

  • AWS Config を使用して CloudWatch Logs の設定変更をモニタリングします (Amazon EventBridge による AWS Config のモニタリング)

  • AWS Security Hub を実装して、ログ記録に関連するセキュリティ検出結果を集約し、優先順位を付けます (AWS Security Hub ユーザーガイド)

  • 失敗したアクセス試行をモニタリングする: メトリクスフィルターを作成して、CloudWatch Logs への失敗した API 呼び出し (AccessDenied エラー) を追跡します。パターンが不正アクセスの試行または権限昇格を示唆する場合は、セキュリティチームにアラートを送信します

  • 削除保護のモニタリングを実装する: 明示的な拒否ステートメントを含む IAM ポリシーと CloudWatch アラームを使用して、削除保護を無効にする試みや保護されたロググループを削除する試みをモニタリングします。組織全体の保護には、AWS Organizations のサービスコントロールポリシー (SCP) の使用を検討してください

まとめ​

Amazon CloudWatch Logs のセキュリティ保護には、アイデンティティベースのポリシー、削除保護、暗号化、データ保護ポリシー、継続的なモニタリングを組み合わせた包括的な多層アプローチが必要です。これにより、重要なログデータを保護できます。最小権限の IAM ポリシーと削除保護から VPC エンドポイントと自動化された機密データ検出まで、これらのセキュリティベストプラクティスを実装することで、ログインフラストラクチャに対する偶発的および悪意のある脅威の両方に対する堅牢な防御を構築できます。これらのコントロールは、機密性の高い運用データとコンプライアンスデータを保護するだけでなく、効果的なモニタリングとトラブルシューティングに必要な運用の可視性を維持しながら、組織が規制要件を満たすことを保証します。適切な CloudWatch Logs のセキュリティは、ログインフラストラクチャへの信頼を維持し、ログデータに含まれる貴重なインサイトを保護するために不可欠です。