セキュリティグループにおける設定変更監視について

2025.08.15

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

今回は、セキュリティグループの変更を監視するメトリクスフィルターが設定されていない状態について、そのリスクと対策を解説します。

リスク

AWSのセキュリティグループは、EC2インスタンスやRDSなどのリソースに対するトラフィックを制御する仮想ファイアウォールとして機能します。セキュリティグループのルール変更は、意図しないアクセスを許可し、システムのセキュリティ体制を脆弱にする可能性があるため、厳格な管理と監視が必要です。

セキュリティグループの変更を監視するメトリクスフィルターが設定されていない場合、以下のような重大なリスクが発生します。

  • 不正なアクセスの見逃し: 誰かがセキュリティグループのインバウンドルールを変更し、不必要なポート（例：SSH 22、RDP 3389）をインターネット全体に公開した場合、その変更をリアルタイムで検知できません。これにより、不正アクセスや攻撃の機会が増大します。
  • 意図しない設定ミスの放置: 運用者が設定変更を誤り、重要な通信ポートを閉じてしまった場合、サービスが停止するなどの問題が発生します。しかし、メトリクスフィルターがないと、この設定ミスを即座に発見できず、サービス障害の長期化につながります。
  • 監査証跡の不備: セキュリティグループの変更はAWS CloudTrailに記録されますが、そのログを能動的に監視する仕組みがなければ、変更履歴を確認するためには手動でログを検索する必要があります。これにより、インシデント発生時の原因究明やフォレンジックが困難になります。

対策

CloudTrailのログからセキュリティグループの変更を抽出し、メトリクスフィルターとCloudWatchアラームを設定することは、上記のすべてのリスクを軽減し、システムのセキュリティと運用の健全性を確保するための重要なベストプラクティスです。

  • リアルタイムでの変更検知: セキュリティグループのルールが変更されると、CloudTrailにログが記録されます。このログをメトリクスフィルターで抽出し、閾値（例：変更が1回発生したら）を超えるアラームを設定することで、メールやSNS通知をリアルタイムで受け取ることができます。
  • 迅速な対応: 不審な変更や設定ミスを即座に通知することで、セキュリティチームや運用チームが迅速に対応でき、インシデントの影響を最小限に抑えることができます。
  • 自動化との連携: CloudWatchアラームをトリガーとして、Lambda関数を起動し、変更を自動的に元の状態に戻す、あるいはIAMポリシーを変更して不審なユーザーの権限を無効化する、といった自動修復の仕組みを構築できます。
  • コンプライアンスの遵守: セキュリティグループの変更を監視し、記録する仕組みを構築することで、多くのコンプライアンス要件を自動的に満たせます。

修復方法

セキュリティグループの変更を監視するためのメトリクスフィルターとCloudWatchアラームの設定は、AWSコンソールまたはTerraformで行えます。

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

AWSコンソールを使用して、CloudTrailのロググループにメトリクスフィルターを設定し、CloudWatchアラームを作成します。

ステップ 1: CloudTrailロググループへのメトリクスフィルター作成

  1. CloudWatchサービスへ移動: AWSコンソールにログインし、CloudWatch サービスを開きます。
  2. メトリクスフィルターへ移動: 左側のナビゲーションペインで「ログ」の下の「メトリクスフィルター」を選択します。
  3. フィルターの作成:
    • 「メトリクスフィルターの作成」をクリックします。
    • 「フィルタリングするログデータ」で、CloudTrailのロググループを選択します。
    • 「フィルターパターン」に、セキュリティグループの変更を検知するためのパターンを入力します。 { ($.eventName = AuthorizeSecurityGroupIngress) || ($.eventName = AuthorizeSecurityGroupEgress) || ($.eventName = RevokeSecurityGroupIngress) || ($.eventName = RevokeSecurityGroupEgress) || ($.eventName = CreateSecurityGroup) || ($.eventName = DeleteSecurityGroup) }
    • 「フィルターパターンのテスト」で、CloudTrailログが正しく抽出されるか確認します。
    • 「メトリクスの詳細」で以下を設定します。
      • フィルター名: SecurityGroupChangeFilter など。
      • メトリクス名前空間: CloudTrailMetrics など。
      • メトリクス名: SecurityGroupChanges など。
    • 「フィルターの作成」をクリックして保存します。

ステップ 2: CloudWatchアラームの作成

  1. アラームへ移動: 左側のナビゲーションペインで「アラーム」を選択し、「アラームの作成」をクリックします。
  2. メトリクスの選択:
    • 「メトリクスの選択」をクリックし、ステップ1で作成したメトリクス（CloudTrailMetrics > SecurityGroupChanges）を選択します。
  3. アラームの設定:
    • 統計: 「合計」を選択します。
    • 期間: 「1分」を選択します。
    • しきい値: 「しきい値」タイプを選択し、「1」を設定します。
    • より大きいを選択します。
    • 欠落データの処理: missing を notBreachingとして扱います。
  4. 通知の設定:
    • 「次へ」をクリックし、「通知」セクションで、アラームがALARM状態になったときに通知を送信するSNSトピックを選択します。
    • SNSトピックがない場合は、新しく作成します。
  5. アラームの作成:
    • アラーム名を入力し、詳細を確認して「アラームの作成」をクリックします。

これで、セキュリティグループに変更が発生すると、1分以内にアラームが発報し、設定したSNSトピックを通じて通知が届くようになります。

Terraformでの修復手順

TerraformでメトリクスフィルターとCloudWatchアラームを設定するには、aws_cloudwatch_log_metric_filter、aws_cloudwatch_metric_alarm、およびaws_sns_topic リソースを使用します。

# (前提) CloudTrailロググループは別途定義済み
resource "aws_cloudwatch_log_group" "cloudtrail_log_group" {
  name = "aws-cloudtrail-logs"
  retention_in_days = 90
}

# 1. セキュリティグループの変更を監視するメトリクスフィルター
resource "aws_cloudwatch_log_metric_filter" "sg_change_filter" {
  name           = "SecurityGroupChangeFilter"
  log_group_name = aws_cloudwatch_log_group.cloudtrail_log_group.name
  pattern = <<EOT
{ ($.eventName = AuthorizeSecurityGroupIngress) || ($.eventName = AuthorizeSecurityGroupEgress) || ($.eventName = RevokeSecurityGroupIngress) || ($.eventName = RevokeSecurityGroupEgress) || ($.eventName = CreateSecurityGroup) || ($.eventName = DeleteSecurityGroup) }
EOT
  metric_transformation {
    name          = "SecurityGroupChanges"
    namespace     = "CloudTrailMetrics"
    value         = "1"
    default_value = "0"
  }
}

# 2. 通知用SNSトピック
resource "aws_sns_topic" "sg_change_topic" {
  name = "SecurityGroupChangeTopic"
}

# Eメールで通知を受け取るためのサブスクリプション
resource "aws_sns_topic_subscription" "email_subscription" {
  topic_arn = aws_sns_topic.sg_change_topic.arn
  protocol  = "email"
  endpoint  = "your-email@example.com" # 通知を受け取るメールアドレスに置き換え
}

# 3. メトリクスフィルターを監視するCloudWatchアラーム
resource "aws_cloudwatch_metric_alarm" "sg_change_alarm" {
  alarm_name          = "SecurityGroupChangesAlarm"
  comparison_operator = "GreaterThanOrEqualToThreshold"
  evaluation_periods  = "1"
  metric_name         = aws_cloudwatch_log_metric_filter.sg_change_filter.metric_transformation[0].name
  namespace           = aws_cloudwatch_log_metric_filter.sg_change_filter.metric_transformation[0].namespace
  period              = "60" # 60秒
  statistic           = "Sum"
  threshold           = "1"
  alarm_description   = "This alarm will trigger if any Security Group change events are detected."
  alarm_actions       = [aws_sns_topic.sg_change_topic.arn]
}

上記のTerraformコードでは、aws_cloudwatch_log_metric_filter でセキュリティグループ関連のイベントを抽出するパターンを定義し、その結果を SecurityGroupChanges というメトリクスに変換しています。次に、aws_cloudwatch_metric_alarm でこのメトリクスを監視し、1分間に1回でも変更が発生したらaws_sns_topicに通知を送信するように設定しています。

この設定を適用することで、セキュリティグループの変更が自動的に監視され、迅速な対応が可能になります。

最後に

この記事では、セキュリティグループの変更を監視するメトリクスフィルターが設定されていないリスクと、それを修正する方法について解説しました。セキュリティグループは、ネットワークセキュリティの基盤であり、その変更を常に監視することは、不正アクセスや設定ミスからシステムを守るために不可欠です。 貴社のAWS環境では、セキュリティグループの変更が適切に監視されていますか？この機会にぜひ設定を確認・強化してみてください。

こちらの内容の検出は弊社が提供するSecurifyのCSPM機能で簡単に検出及び管理する事が可能です。運用が非常にラクに出来る製品になっていますのでぜひ興味がある方はお問い合わせお待ちしております。

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

この記事をシェアする

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

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

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

料金プランを詳しく見る