AWSセキュリティグループの削除前に確認すること
AWSのセキュリティグループ（Security Group、以下SG）を整理するときに、どのような確認が必要なのかを学習用・検証用の環境を想定して整理する。 はじめに SGは、EC2などのAWSリソースに対する通信を制御する仮想ファイアウォールです。SGにはインバウンドルールとアウトバウンドルールがあり、どの送信元からどのポートへの通信を許可するかを定義します。 SGを整理していると、広い範囲からのアクセスを許可するルールや、用途が分からないSGを見つけることがあります。しかし、ルールが広いからといって、すぐに削除してよいとは限りません。 削除前には、次の2つを分けて考える必要があります。 その通信ルールは業務上必要なのか そのSGは現在どのリソースに関連付けられているのか 0.0.0.0/0とは 0.0.0.0/0は、すべてのIPv4アドレスを表すCIDRです。SGのインバウンドルールでこの値を指定すると、指定したポートへの通信を、送信元IPアドレスによらず許可することになります。 たとえば、次のルールは世界中のIPv4アドレスからSSH接続を許可します。 プロトコル ポート 送信元 意味 TCP 22 0.0.0.0/0 すべてのIPv4アドレスからSSHを許可 このような設定では、インターネット上のスキャンや攻撃の対象になる可能性が高くなります。特にSSH（22番）やRDP（3389番）、データベースのポートなどを全世界に公開するのは危険です。 一方で、公開WebサイトのHTTP（80番）やHTTPS（443番）では、利用者の送信元IPを事前に限定できないため、0.0.0.0/0を使うことがあります。この場合も、Webサーバーやロードバランサーなど、公開が意図されたリソースにだけ関連付けることが重要です。 また、今回問題にしたいのは主にインバウンドルールです。アウトバウンドの0.0.0.0/0は、リソースからインターネット上のサービスへ接続するために使われることがあり、インバウンドと同じ意味で単純に判断できません。 未使用のSGを整理する理由 未使用のSGを残しておくと、今すぐ通信が発生するわけではありません。しかし、将来そのSGを誤ってEC2やENIなどに関連付けたとき、広い範囲からのアクセスを許可する設定が意図せず有効になる可能性があります。 また、不要なSGが多いと、名前やルールを見ただけでは「現在使われている設定なのか」「過去の作業の残りなのか」を判断しにくくなります。これは、設定ミスや変更時の事故につながります。 そのため、未使用であることを確認できたSGは、削除または廃止候補として整理する価値があります。 本当に使われていないかを確認する SGを削除する前に、少なくとも次の観点で確認します。 EC2インスタンスやENIに関連付けられていないか 他のSGのルールから参照されていないか ロードバランサー、RDS、ECSなどのAWSサービスで使われていないか Auto Scaling、起動テンプレート、CloudFormationなどで指定されていないか TerraformやAWS CDKなどのIaCで管理されていないか 今後必要になる予定のSGではないか SGのルールを確認する まず、対象SGの所属VPCやルールを確認します。以下は実際の環境で実行する場合の形式例です。値は自分の確認対象に置き換えます。 1 2 3 4 aws ec2 describe-security-groups \ --group-ids sg-xxxxxxxxxxxxxxxxx \ --profile <profile> \ --region <region> IpPermissionsがインバウンドルール、IpPermissionsEgressがアウトバウンドルールです。0.0.0.0/0だけでなく、::/0というIPv6の全アドレスを表すルールも確認します。 ENIへの関連付けを確認する SGはEC2インスタンスだけでなく、Elastic Network Interface（ENI）に関連付けられます。ロードバランサーやRDS、ECSなど、AWSサービスが管理するENIに関連付けられていることもあります。 ...