AWSのデフォルトセキュリティグループは削除できない?安全な対応方法

この記事は約8分で読めます

こんにちは、 @Manabu です。

AWS環境のセキュリティを確認していると、デフォルトのセキュリティグループについて、削除やルールの見直しを依頼されることがあります。

デフォルトのセキュリティグループには全てのプロトコルとポートを許可するルールがあるため、そのまま残してよいのか不安になる方もいるのではないでしょうか。

ただし、VPCに最初から作成されるデフォルトのセキュリティグループは削除できません。

今回は、デフォルトのセキュリティグループの正しい仕様と、削除を求められた場合に選択できる対応方法を紹介します。

この記事は、以下のような方におすすめです。

こんな方におすすめ

  • デフォルトのセキュリティグループを削除するよう依頼された
  • 全ポートを許可するルールがセキュリティ上問題ないか確認したい
  • Security HubやAWS Configの指摘を解消したい

デフォルトのセキュリティグループは削除できない

VPCを作成すると、defaultという名前のセキュリティグループが自動的に作成されます。

このセキュリティグループを単独で削除することはできません。

削除しようとすると、次のような文言が表示されます。

これはデフォルトのセキュリティグループです。デフォルトのセキュリティグループは削除できません。

デフォルトのセキュリティグループはVPCに付属するリソースです。VPC自体を削除した場合は一緒に削除されますが、利用中のVPCでデフォルトのセキュリティグループだけを削除することはできません。

そのため、セキュリティ診断などで削除を依頼された場合は、削除できない仕様を説明したうえで、ルールの削除や利用停止によって対応します。

初期状態で許可されている通信

デフォルトのセキュリティグループには、初期状態で次のルールがあります。

方向 プロトコル・ポート 通信元・通信先
インバウンド 全て 同じデフォルトセキュリティグループ
アウトバウンド 全て 0.0.0.0/0
アウトバウンド 全て ::/0(IPv6を使用する場合)

ここで注意したいのは、インバウンドルールがインターネット全体に公開されているわけではないことです。

初期状態でインバウンド通信を許可する送信元は、同じデフォルトセキュリティグループが設定されたリソースです。

そのため、0.0.0.0/0から全ポートへ接続できる設定とは異なります。

一方で、複数のリソースにデフォルトのセキュリティグループが設定されている場合、それらのリソース間では全てのプロトコルとポートが許可されます。また、アウトバウンド通信は全て許可されています。

意図せずデフォルトのセキュリティグループを使用した場合に、不要な通信が発生する可能性があるため、AWSは専用のセキュリティグループを作成することを推奨しています。

デフォルトのセキュリティグループをEC2へ設定し、外部から接続できなかった事例は以下の記事で紹介しています。

REFERENCEEC2デフォルトのセキュリティグループで接続エラー?対象方法IT自習室

対応方法1:全てのルールを削除する

デフォルトのセキュリティグループを使用していない場合は、インバウンドルールとアウトバウンドルールを全て削除する方法が分かりやすいです。

セキュリティグループはルールが1つもない状態にできます。

ルールを全て削除しておけば、誤ってリソースへ設定した場合でも、そのセキュリティグループを経由した通信は許可されません。

AWSマネジメントコンソールでは、次の手順で対応できます。

  1. VPCコンソールから「セキュリティグループ」を開く
  2. 対象VPCのdefaultセキュリティグループを選択する
  3. インバウンドルールを全て削除する
  4. アウトバウンドルールを全て削除する
  5. ルールが残っていないことを確認する

先に利用状況を確認する

ルールを削除する前に、デフォルトのセキュリティグループを使用しているネットワークインターフェイスやAWSリソースがないか確認してください。利用中の状態で削除すると、既存システムの通信が停止する可能性があります。

対応方法2:専用のセキュリティグループへ切り替える

デフォルトのセキュリティグループを使用しているリソースがある場合は、先に用途別のセキュリティグループを作成します。

例えば、次のように分けます。

  • Webサーバー用
    • ALBからのHTTPまたはHTTPSだけを許可する
  • データベース用
    • Webサーバー用セキュリティグループからの接続だけを許可する
  • 管理用
    • Systems Managerを利用し、不要なSSHポートを開放しない

新しいセキュリティグループへ切り替えて通信を確認した後、デフォルトのセキュリティグループから全てのルールを削除します。

既存の通信要件を確認せず、先にルールを削除しないようにしましょう。

対応方法3:すぐに変更できない場合は段階的に対応する

既存システムでデフォルトのセキュリティグループが使われており、影響範囲が分からない場合もあります。

その場合は、次の順番で対応します。

  1. デフォルトのセキュリティグループを使用しているリソースを洗い出す
  2. VPC Flow Logsやアプリケーションの設定から必要な通信を確認する
  3. 必要な通信だけを許可する専用セキュリティグループを作成する
  4. 検証環境で切り替えて動作を確認する
  5. 本番環境を専用セキュリティグループへ切り替える
  6. デフォルトのインバウンド・アウトバウンドルールを削除する

すぐにルールを削除できない場合でも、対応期限と移行手順を決め、デフォルトのセキュリティグループを使い続けない状態を目指します。

AWS CLIで利用状況とルールを確認する

最初に、VPCのデフォルトセキュリティグループを確認します。

aws ec2 describe-security-groups \
  --filters \
    Name=vpc-id,Values=vpc-xxxxxxxx \
    Name=group-name,Values=default

対象のセキュリティグループを使用しているネットワークインターフェイスは、次のコマンドで確認できます。

aws ec2 describe-network-interfaces \
  --filters Name=group-id,Values=sg-xxxxxxxx

ルールを個別に確認する場合は、次のコマンドを使用します。

aws ec2 describe-security-group-rules \
  --filters Name=group-id,Values=sg-xxxxxxxx

表示されたルールIDを指定すると、インバウンドとアウトバウンドのルールを削除できます。

aws ec2 revoke-security-group-ingress \
  --group-id sg-xxxxxxxx \
  --security-group-rule-ids sgr-xxxxxxxx
aws ec2 revoke-security-group-egress \
  --group-id sg-xxxxxxxx \
  --security-group-rule-ids sgr-yyyyyyyy

削除対象を間違えないように、セキュリティグループID、ルールの方向、通信元・通信先を確認してから実行してください。

Security HubとAWS Configで継続的に確認する

一度ルールを削除しても、後から再び追加される可能性があります。

Security Hubには、デフォルトのセキュリティグループがインバウンドまたはアウトバウンド通信を許可していないか確認するEC2.2コントロールがあります。

AWS Configでは、マネージドルールvpc-default-security-group-closedを利用できます。このルールは、デフォルトのセキュリティグループにインバウンドまたはアウトバウンドルールが1つでも存在すると、非準拠として判定します。

複数のVPCやAWSアカウントを管理している場合は、手作業による確認だけでなく、これらのサービスを使って継続的に検出できる状態にしておくと安心です。

対応方針の選び方

状況ごとの対応をまとめると、次のようになります。

状況 対応
デフォルトセキュリティグループを使用していない インバウンド・アウトバウンドルールを全て削除する
使用中だが必要な通信が分かっている 専用セキュリティグループを作成して切り替える
使用中で影響範囲が分からない 利用状況と通信を調査し、段階的に切り替える
継続的に違反を検出したい Security HubまたはAWS Configを有効にする
VPC自体が不要 VPCと関連リソースを整理したうえでVPCを削除する

まとめ

AWSのデフォルトセキュリティグループは、単独では削除できません。

ただし、インバウンドルールとアウトバウンドルールは変更できるため、使用していなければ全て削除することで通信を許可しない状態にできます。

既存リソースで使用している場合は、必要な通信だけを許可する専用のセキュリティグループへ切り替えてから、デフォルトルールを削除します。

削除できないからそのままにするのではなく、誤って使用しても通信できない状態にしておくことが大切です。

参考資料