VPC変更監視の設定について

2025.07.18

このブログシリーズ 「クラウドセキュリティ 実践集」 では、一般的なセキュリティ課題を取り上げ、「なぜ危険なのか？」 というリスクの解説から、「どうやって直すのか？」 という具体的な修復手順（コンソール、AWS CLI、Terraformなど）まで、分かりやすく解説します。

この記事では、AWS環境で VPCの変更を監視するCloudTrailメトリクスフィルター が設定されていない状態について、そのリスクと対策を解説します。

リスク

Amazon VPC (Virtual Private Cloud) は、AWSクラウド内にプライベートで隔離されたネットワーク環境を構築するためのサービスです。VPCの設定に対する意図しない、または悪意のある変更は、セキュリティ上の重大な穴となり、以下のような深刻なリスクを招く可能性があります。

  • ネットワークセキュリティの侵害: セキュリティグループ、ネットワークACL (NACL)、ルートテーブルなどのVPC設定が不正に変更されると、本来隔離されているべきリソースがインターネットに公開されたり、予期しないネットワーク経路が作成されたりする可能性があります。これにより、不正アクセスやデータ漏洩のリスクが大幅に増加します。
  • コンプライアンス違反: 多くのセキュリティ規制やコンプライアンス基準（例: PCI DSS, HIPAA, ISO 27001）では、ネットワークの厳格な分離とアクセス制御が義務付けられています。VPC設定の変更を監視していない場合、これらの要件を満たせず、監査での指摘や法的リスクに直面する可能性があります。
  • サービス中断と可用性の低下: 不適切なVPC設定の変更は、アプリケーション間の通信を遮断したり、ロードバランサーやデータベースへのアクセスを妨げたりして、サービスの可用性を低下させる可能性があります。これは、業務への影響や機会損失につながります。
  • 攻撃経路の拡大: VPCのルーティングやピアリング接続の変更が監視されていない場合、攻撃者が既存の侵害ポイントからVPCピアリング経由で他のVPCに横展開したり、不正なルートを追加してトラフィックをリダイレクトしたりする可能性があります。
  • 設定の逸脱と管理の複雑化: 意図しないVPCの変更が頻繁に発生すると、本来あるべきネットワークセキュリティ設定（ベースライン）からの逸脱が生じ、セキュリティ体制が不明確になります。これにより、VPC環境の管理が複雑になり、脆弱性の特定が困難になります。

対策

VPC設定の変更を即座に検知し、対応できる監視体制を構築することは、AWS環境のネットワークセキュリティを維持するために不可欠です。

  • CloudTrailの有効化: AWSアカウントのCloudTrailが有効になっており、VPCに関する管理イベントを記録していることを確認してください。CloudTrailは、VPC設定の変更を含む、アカウント内のすべてのアクティビティを記録する中心的なサービスです。
  • CloudWatch Logsへの連携: CloudTrailのログを CloudWatch Logs に送信するように設定します。これにより、ログデータを一元的に管理し、メトリクスフィルターやアラームを設定できるようになります。
  • メトリクスフィルターの設定: CloudWatch Logsグループ内で、VPCの主要な設定変更に関連するCloudTrailイベントを検出するメトリクスフィルターを作成します。対象となる代表的なAPIアクションは以下の通りです。
    • VPC全般: CreateVpc, DeleteVpc
    • サブネット: CreateSubnet, DeleteSubnet
    • セキュリティグループ: CreateSecurityGroup, DeleteSecurityGroup, AuthorizeSecurityGroupIngress, AuthorizeSecurityGroupEgress, RevokeSecurityGroupIngress, RevokeSecurityGroupEgress
    • ネットワークACL (NACL): CreateNetworkAcl, DeleteNetworkAcl, CreateNetworkAclEntry, DeleteNetworkAclEntry, ReplaceNetworkAclEntry
    • ルートテーブル: CreateRouteTable, DeleteRouteTable, CreateRoute, DeleteRoute, ReplaceRoute
    • インターネットゲートウェイ (IGW): CreateInternetGateway, DeleteInternetGateway, AttachInternetGateway, DetachInternetGateway
    • VPCピアリング接続: CreateVpcPeeringConnection, DeleteVpcPeeringConnection, AcceptVpcPeeringConnection, RejectVpcPeeringConnection
    • NATゲートウェイ: CreateNatGateway, DeleteNatGateway
  • CloudWatchアラームの設定: 作成したメトリクスフィルターに基づいて CloudWatchアラーム を設定します。これにより、VPC変更イベントが検出された際に、Amazon SNSなどを通じて関係者（セキュリティチーム、運用チームなど）に即座に通知が送信されるようになります。
  • 通知の自動化: SNSトピックを介して、適切なチャネルでアラートが届くように設定します。
  • 定期的なレビューと対応計画: VPC変更のアラートが発報された際の対応手順（変更内容の確認、承認プロセスのチェック、不正な変更のロールバック、根本原因分析など）を明確に定義し、定期的にレビューします。

修復方法

AWSコンソールでの修復手順

AWSコンソールを使用して、VPC変更を監視するCloudWatchメトリクスフィルターとアラームを設定します。

前提: CloudTrailが有効で、ログがCloudWatch Logsに送信されていることを確認してください。

  1. CloudWatchサービスへ移動: AWSコンソールにログインし、CloudWatchサービスを開きます。
  2. ロググループの選択: 左側のナビゲーションペインで「ロググループ」を選択します。 CloudTrailのログが保存されているロググループ（通常はCloudTrail/DefaultLogGroupのような名前、またはCloudTrailトレイルで設定したロググループ名）を選択します。
  3. メトリクスフィルターの作成: ロググループの詳細ページで「メトリクスフィルター」タブを選択し、「メトリクスフィルターの作成」をクリックします。
  4. フィルターパターンの定義: 「フィルターパターン」に、VPCの主要な変更に関連するイベントを検出するパターンを入力します。以下は一例です。必要に応じて、監視したい具体的なAPIアクションを追加してください。 { ($.eventName = "CreateVpc") || ($.eventName = "DeleteVpc") || ($.eventName = "CreateSubnet") || ($.eventName = "DeleteSubnet") || ($.eventName = "CreateSecurityGroup") || ($.eventName = "DeleteSecurityGroup") || ($.eventName = "AuthorizeSecurityGroupIngress") || ($.eventName = "AuthorizeSecurityGroupEgress") || ($.eventName = "RevokeSecurityGroupIngress") || ($.eventName = "RevokeSecurityGroupEgress") || ($.eventName = "CreateNetworkAcl") || ($.eventName = "DeleteNetworkAcl") || ($.eventName = "CreateNetworkAclEntry") || ($.eventName = "DeleteNetworkAclEntry") || ($.eventName = "ReplaceNetworkAclEntry") || ($.eventName = "CreateRouteTable") || ($.eventName = "DeleteRouteTable") || ($.eventName = "CreateRoute") || ($.eventName = "DeleteRoute") || ($.eventName = "ReplaceRoute") || ($.eventName = "CreateInternetGateway") || ($.eventName = "DeleteInternetGateway") || ($.eventName = "AttachInternetGateway") || ($.eventName = "DetachInternetGateway") || ($.eventName = "CreateVpcPeeringConnection") || ($.eventName = "DeleteVpcPeeringConnection") || ($.eventName = "AcceptVpcPeeringConnection") || ($.eventName = "RejectVpcPeeringConnection") || ($.eventName = "CreateNatGateway") || ($.eventName = "DeleteNatGateway") } ※ フィルターは1024文字までのため、必要に応じて修正してください。 「次へ」をクリックします。
  5. メトリクス詳細の指定:
    • フィルター名: 例: VPCConfigurationChangeFilter
    • メトリクス名前空間: 例: CloudTrailMetrics
    • メトリクス名: 例: VPCConfigurationChangeCount
    • メトリクス値: 1 「次へ」をクリックします。
  6. メトリクスの作成: 設定を確認し、「メトリクスフィルターの作成」をクリックします。
  7. アラームの作成: 作成したメトリクスフィルターを選択し、「アラームの作成」をクリックします。
  8. アラームの設定:
    • メトリクス: 自動的に設定されます。
    • 統計: 「合計」を選択します。
    • 期間: 例: 「5分」を選択します。
    • しきい値: 「次とより大きい」を選択し、0 を入力します。（1回でもイベントが発生したらアラーム）
    • 「次へ」をクリックします。
  9. 通知の設定:
    • 「通知の送信先」で、既存のSNSトピックを選択するか、「新しいトピックの作成」を選択して、メールアドレスなどを指定します。
    • 「次へ」をクリックします。
  10. アラーム名の追加:
    • アラーム名: 例: VPCConfigurationChangeAlarm
    • アラーム説明: 例: Alerts when a VPC configuration change event is detected. 「次へ」をクリックします。
  11. アラームの作成: 設定を確認し、「アラームの作成」をクリックします。

Terraformでの修復手順

TerraformでVPCフローログを有効化し、フィルタ設定を行うには、aws_flow_log リソースを使用します。ログの保存先はs3_bucket_arnまたはlog_group_nameで指定します。

# (例) フローログを保存するためのS3バケット
resource "aws_s3_bucket" "flow_log_bucket" {
  bucket = "my-vpc-flow-logs-bucket-unique-12345" # グローバルで一意の名前に変更
  force_destroy = true # テスト用。本番環境ではfalseを推奨

  tags = {
    Name = "VPCFlowLogBucket"
  }
}

# S3バケットポリシー (フローログサービスがバケットに書き込めるようにする)
resource "aws_s3_bucket_policy" "flow_log_bucket_policy" {
  bucket = aws_s3_bucket.flow_log_bucket.id
  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Sid       = "AWSLogDeliveryWrite"
        Effect    = "Allow"
        Principal = {
          Service = "delivery.logs.amazonaws.com"
        },
        Action    = "s3:PutObject",
        Resource  = "${aws_s3_bucket.flow_log_bucket.arn}/AWSLogs/${data.aws_caller_identity.current.account_id}/*",
        Condition = {
          StringEquals = {
            "s3:x-amz-acl" = "bucket-owner-full-control"
          }
        }
      },
      {
        Sid       = "AWSLogDeliveryAclCheck"
        Effect    = "Allow"
        Principal = {
          Service = "delivery.logs.amazonaws.com"
        },
        Action    = "s3:GetBucketAcl",
        Resource  = aws_s3_bucket.flow_log_bucket.arn
      }
    ]
  })
}

# (例) フローログを有効にするVPC
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = {
    Name = "main-vpc-with-flow-logs"
  }
}

# VPCフローログの設定
resource "aws_flow_log" "vpc_flow_log" {
  log_destination      = aws_s3_bucket.flow_log_bucket.arn # S3バケットを宛先とする
  log_destination_type = "s3"
  traffic_type         = "ALL" # ALL (全て) または REJECT (却下) を選択
  # traffic_type         = "REJECT" # REJECT (却下) を選択することも可能
  vpc_id               = aws_vpc.main.id # フローログを有効にするVPCのID

  # IAMロールの指定 (S3への書き込み権限を持つロール)
  # 通常、サービスにリンクされたロールが使用されるため、
  # ExplicitなIAMロールの定義は不要な場合が多い。
  # ただし、特定のユースケースでは必要になる場合があります。
  # iam_role_arn = aws_iam_role.flow_log_role.arn

  tags = {
    Name = "VPCFlowLog"
  }
}

# (オプション) フローログ用のIAMロール (CloudWatch Logsに送信する場合やS3へのカスタムロールが必要な場合)
# resource "aws_iam_role" "flow_log_role" {
#   name = "vpc-flow-log-delivery-role"
#   assume_role_policy = jsonencode({
#     Version = "2012-10-17"
#     Statement = [
#       {
#         Action = "sts:AssumeRole"
#         Effect = "Allow"
#         Principal = {
#           Service = "ec2.amazonaws.com"
#         }
#       }
#     ]
#   })
# }

# resource "aws_iam_role_policy" "flow_log_policy" {
#   name = "vpc-flow-log-delivery-policy"
#   role = aws_iam_role.flow_log_role.id
#   policy = jsonencode({
#     Version = "2012-10-17"
#     Statement = [
#       {
#         Action = [
#           "logs:CreateLogGroup",
#           "logs:CreateLogStream",
#           "logs:PutLogEvents",
#           "logs:DescribeLogGroups",
#           "logs:DescribeLogStreams",
#         ],
#         Effect = "Allow",
#         Resource = "*"
#       },
#       {
#         Action = [
#           "s3:PutObject",
#           "s3:GetBucketAcl",
#           "s3:ListBucket"
#         ],
#         Effect = "Allow",
#         Resource = [
#           "${aws_s3_bucket.flow_log_bucket.arn}",
#           "${aws_s3_bucket.flow_log_bucket.arn}/*"
#         ]
#       }
#     ]
#   })
# }

# 現在のAWSアカウント情報を取得
data "aws_caller_identity" "current" {}

上記のTerraformコードでは、以下のリソースを定義しています。

  1. data "aws_cloudwatch_log_group" "cloudtrail_log_group": 既存のCloudTrailロググループを参照します。
  2. aws_cloudwatch_log_metric_filter.vpc_configuration_change_filter: VPCの変更イベントを検出するメトリクスフィルターを定義します。patternには、監視したい具体的なAPIアクションのリストが含まれています。
  3. aws_sns_topic.vpc_change_sns_topic: アラート通知のためのSNSトピックを定義します。
  4. aws_sns_topic_subscription.vpc_change_email_subscription: SNSトピックの購読者（ここではメールアドレス）を設定します。（この購読は手動で承認が必要です。）
  5. aws_cloudwatch_metric_alarm.vpc_configuration_change_alarm: メトリクスフィルターで検出されたイベント数が閾値を超えた場合にアラートを発報するCloudWatchアラームを定義します。

your-security-email@example.com や CloudTrail/DefaultLogGroup などのプレースホルダーは、実際の環境に合わせて修正してください。

最後に

この記事では、CloudTrailとCloudWatch Logsを活用してVPCの変更を監視するためのメトリクスフィルターとアラームを設定する方法について解説しました。VPC設定の変更は、ネットワークセキュリティに直接影響を与えるため、これを早期に検知し、対応できる体制を構築することは非常に重要です。

貴社のAWS環境では、VPC変更に対する監視体制が適切に構築されていますか？この機会にぜひ強化を検討してみてください。

この問題の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。

運用が非常に楽に出来る製品になっていますので、ぜひ興味がある方はお問い合わせお待ちしております。

最後までお読みいただきありがとうございました。この記事が皆さんの役に立てば幸いです。

この記事をシェアする

クラウドセキュリティ対策実践集一覧へ戻る

貴社の利用状況に合わせた見積もりを作成します。

見積もりを希望する
資料ダウンロード

料金プランを詳しく見る