STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。

AWS Security Groupの棚卸とその後の運用

STORES 決済 バックエンド

STORES 決済 バックエンドエンジニアの nannany です。
この記事は STORES Advent Calendar 2022 の 22日目の記事です。

概要

システムを運用していくと、過去使っていたけれど現在は使っていない AWS Security Group (以下、Security Group)がどうしても出てきます。 ここではそういったSecurity Groupの棚卸方法と、利用していない Security Group が出ないようにどう運用していくかについて記述します。

棚卸手順

大まかに下記の手順で棚卸をします。

  • Security Hub の AWS 基礎セキュリティのベストプラクティス v1.0.0の IDがEC2.22の Unused EC2 security groups should be removedを使って、利用していないSecurity Groupの洗い出し
  • 上記で利用していないとなったSecurity Groupのうち、Auto Scaling Group、Event Bridgeで利用している箇所を特定し、Security Hub 上の ワークフロー を 抑制済み(英語表記だとSUPPRESSED)に変更
  • Security Hub 上でFAILED として残っている Security Group を削除

Security Hub

Security Hubの AWS 基礎セキュリティのベストプラクティス v1.0.0 というセキュリティ標準のID:EC2.22である Unused EC2 security groups should be removed というコントロールでは、利用されていない Security Group を判別できます。 下記の コンプライアンスのステータス が FAILED となっている箇所は、該当の Security Group がアタッチされていないことを示しています。

AWS Security Hubの画面

ただし、このコントロールの説明は下記のようでした。

This AWS control checks that security groups are attached to Amazon EC2 instances or to an elastic network interface.

つまり、EC2インスタンスまたは ENI にアタッチされていない Security Group を FAILED として検知するものの、それら検知した Security Group はEC2インスタンスまたは ENI 以外のところで設定されている可能性があるということです。 例えば、定刻に起動し、処理が終わったらインスタンス停止するようなバッチに付与される Security Group は、Auto Scaling Group などで設定していても FAILED となってしまいます。

利用していない Security Group を絞るにあたり、ここまでで下記のEC2, ENIに紐づかないSecurity Groupにまで絞ることができました。 本当に使われていない Security Group はEC2, ENIに紐づかないSecurity Group の中に含まれているので、ここからさらに絞り込んでいきます。

AWS Configを使って絞り込み

ここからは AWS Config の Advanced Queries を使って、利用していない Security Group を絞っていきます。

Auto Scaling Group の起動設定に紐づく Security Group

AWS Config の Advanced Queries を利用して、 Auto Scaling Group の起動設定に紐づく Security Group を探します。 Auto Scaling Group の起動設定について取得できる情報は このページ にあります。 上記参考にして下記のようなクエリを実行します。

SELECT
  configuration.securityGroups
WHERE
  resourceType = 'AWS::AutoScaling::LaunchConfiguration'
  and configuration.securityGroups.value IN (
  ${EC2, ENIに紐づかないSecurity Group}
  )

AWS Configの画面

上記のクエリによって、EC2, ENIに紐づかないSecurity Group のうち、Auto Scaling Group の Lannch Configuration には紐づくものが明らかになります。 クエリの結果はCSVまたはJSONの形式でダウンロードできます。

aws cliを使って絞り込み

次に Event Bridge の設定に紐づく Security Group を特定したいのですが、AWS Config においては Event Bridge の設定を取り扱っていなかったため、aws cli を利用して絞り込みを行います。1

Event Bridge の target に設定されているSecurity Group

下記のシェルスクリプトで Event Bridge の target となっている Security Group を特定できます。

実施している内容としては、

  • aws events list-rules コマンドで Event Bridge のルール名称を全て取得
  • aws events list-targets-by-rule --rule $name コマンドを使って、該当のルールで Security Group の設定がされているか確認

のみです。

#!/bin/sh

aws events list-rules | jq '.Rules[].Name' > names
len=$(cat names |wc -l)
for i in $( seq 1 $(($len)) ); do
  name=$(sed -n "$i"p names | tr -d '"')
  if aws events list-targets-by-rule --rule $name | grep -q SecurityGroups; then
    echo $name
    aws events list-targets-by-rule --rule $name | grep -1 sg-
  fi
done

Security Hub への反映

ここまでで、EC2, ENIに紐づかないSecurity Group のうち、Auto Scaling Group と Event Bridge では利用しているSecurity Group を洗い出せました。

Security Hub では、チェックの対象外とするべく抑制済みというステータスが用意されています。 本当に不要な Security Group を明示できるように、上記で洗い出した Security Group は 抑制済み のステータスに変えていきます。

Security Hub 上で該当の行にチェックを入れて、かんたんにステータスを変更できます。

AWS Security Hubの画面

ここまで整理した内容をベン図で表すと下記の通りです。(白塗りの部分が真に使われていないSecurity Group)

Security Group の削除

抑制済みステータスを入れた後にも コンプライアンスのステータス が FAILED となっているものが使われていない Security Group への警告にあたるので、該当のSecurity Groupを消していって棚卸は完了です。

注意点

我々のシステムではたまたま Auto Scaling Group と Event Bridge のみが EC2.22 のチェックに引っ掛からなかったのですが、必ずしもそうではなく、これら以外にもチェックに引っ掛からないAWS リソースはあり得る点に注意が必要です。

運用

棚卸が完了すると、Unused EC2 security groups should be removedの コンプライアンスのステータス は 成功 になります。この 成功 の状態を保つための運用方法をここでは記述していきます。

Slack通知

コンプライアンスのステータスの 失敗 を検知して、Slack通知を飛ばすようにします。 Slack通知を送るアーキテクチャの詳細は割愛しますが、Event Bridge・SNS・Chatbotを利用して実現しています。2

Slack通知例

Slack通知への対応

これまでに見てきた通り コンプライアンスのステータス が 失敗 となるのは、ENIに紐づかない Security Group が発生した場合です。 そのため、Slack通知を受け取った担当者は、通知の原因となった Security Group を Security Hub 上で確認し、その Security Group が本当に使われていないなら削除し、ENIに紐づかない部分で利用されているなら、Security Hub 上でのステータスを 抑制済みにするようにします。 この対応で、コンプライアンスのステータス は再び 成功 に戻ります。

課題

上記の運用を回すことができていれば、利用されていない Security Group を最小限に抑えることはできると思います。 ただ、ENIには紐づかないが、Auto Scaling Group では使っている、という理由から 抑制済み にしている Security Group について、Auto Scaling Group を消すなどしてどこからも使われなくなった場合に、利用しなくなったことを検知する方法がありません。 今の所そのような問題は顕在化していないですが、これを防ぐためには定期的に 抑制済み のSecurity Groupが本当に利用されているか確認する必要があります。

おわりに

この記事では、不要となった AWS Security Group の特定方法と、棚卸を実施した後に不要な AWS Security Group が発生しないようにする運用方法とその課題を紹介しました。

最後に、AWSの機能を使っていく中で下記の機能があったら助かるなぁと感じたので一応書き記しておきます。(AWSの人が見ることを期待して)

  • AWS::AutoScaling::LaunchConfigurationなども含め、本当にどこでも使用していない Security Group を評価してくれるものがあったら嬉しい
  • 抑制済み にした理由を付与したいので、コメントを付与できたら嬉しい

20240111追記

EC2.22が非推奨になってしまいました。

docs.aws.amazon.com

  1. 雑にissue出してみましたが今のところ動きなし↩
  2. こちらの記事に詳細が記載されています↩