【AWS】AWS Configの修復アクションを実行してみた(デフォルトSGからルールを削除)

# はじめに
<!-- 発端や概要を記載 -->
VPC作成時に同時に作成されるデフォルトセキュリティグループってご存じでしょうか。
アカウント内に存在するけど使ってないなぁという方は結構多いのではないかと思います。
このSGは外部との通信が許可された状態で作成されますので、そのまま放置していると不正アクセスに利用される恐れがあります。

本記事ではこのデフォルトセキュリティグループのルールをAWSConfigのマネージドルールを使用して無効化してみます。
はじめてConfigを触る方でも理解できるよう、易しめの内容となっております。
AWS Configというサービスの存在は知ってるけど、どんな使い方ができるのか知らないって方の参考になれば幸いです。

また、「Configルールに紐づけられた修復アクションは、コンソール画面から削除できない」というちょっと癖がある仕様なため、修復アクションの削除方法も併せて紹介します。

【宣伝】
弊社に関する質問や何か聞きたいことがあればTwitterのDM等でお声がけください！お待ちしております！

# 目次
<!-- タイトルとアンカー名を編集 -->
1. [AWS Configとは](#awsconfigとは)
1. [デフォルトセキュリティグループの作成](#デフォルトセキュリティグループの作成)
1. [Configルールを作成](#configルールを作成)
1. [修復アクションを定義](#修復アクションを定義)
1. [リソースを修復](#リソースを修復)
1. [修復アクションを削除](#修復アクションを削除)

<!-- 各チャプター -->
<a id="#Chapter1"></a>
# AWSConfigとは
「Configルール」に記載された内容を正しい姿としてAWSリソースやオンプレミスサーバを評価します。
ルールに対して非準拠だった場合はSNSを使用してユーザに通知したり、Lambdaを実行することで対象のリソースを修正することも可能です。
自動修正だけでなく、非準拠を検知後に手動で修正アクションを実行することも可能です。
リソースの評価だけでなく、「リソースのインベントリ」や「リソースタイムライン」の機能を使用して、いつどんな変更が行われたかを確認することも可能です。


# デフォルトセキュリティグループの作成
今回の検証で修正対象となるセキュリティグループを作成していきます。
デフォルトセキュリティグループはVPCを作成すると併せて自動作成されます。
(SGさえ作成されればいいのでVPCの内容は何でもいいです。)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/0e07df33-d303-302f-73ef-b1e098685659.png)

VPCの作成が完了したら、セキュリティグループの画面でVPCIDを検索します。
デフォルトSGが作成されていることを確認できるかと思います。
このSGのルールに注目してください。
インバウンド、アウトバウンドでそれぞれルールが指定されています。（ルールの詳細は割愛)

今回の検証ではこのインバウンド・アウトバウンドルールをAWS Configを使用して削除します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/e5840411-b2c8-9fd8-ec21-5087f51bc887.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/91aabba3-bd63-0c41-c616-56229c1511eb.png)


# Configルールを作成
AWS Configのサービス画面で「ルールを追加」を押下します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/129e41c0-84f0-e796-b245-aa753ea0f03a.png)
今回はAWSが提供するマネージドルール「vpc-default-security-group-closed」を使用します。
画像のような内容になっているか確認し、「ルールを追加」を押下します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/c5fdf76b-1b92-0a10-8781-441228ae7240.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/778e7f07-8c7e-3ec4-c548-9c6892350831.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/483fc8bb-99d9-cded-f322-4f7bf941d718.png)

# 修復アクションを定義
次にConfigルールで検出されたリソースに対して実行する修復アクションを定義します。
「アクション」から「修復の管理」を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/cb21d7f9-4765-c320-b9ce-448f83ad4eb9.png)

今回は手動修復を選択します。
定期的なスキャンやリソース作成を検知して自動修正したい場合は「自動修復」を選択してください。

「修復アクションの詳細」は「AWS-CloseSecurityGroup」,「リソースIDパラメータ」は「SecurityGroupId」を選択してください。
そのまま「変更を保存」を押下します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/dd332ea8-c055-0f32-32c0-1e1f3f816ac8.png)
ルールのアクションに「AWS-CloseSecurityGroup」が追加されました。
まだデフォルトセキュリティグループを修正していないので非準拠として1件検出されています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/fe5d91f6-77c9-89ce-f3da-ea069c1b1a85.png)

ルール名を押下すると画像のようにルールの詳細が表示されます。
デフォルトセキュリティグループが非準拠として検知されていることがわかります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/51707762-321f-bfc0-66ea-c2eb5c7fe62e.png)


# リソースを修復
再度ですが、修復前のセキュリティグループを確認しておきます。
インバウンド、アウトバウンドにそれぞれルールが存在しています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/2c0e9cf1-bc2f-6ff3-2899-973e5bec52ac.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/e4696b77-cf10-82d7-3624-f4342db4e29f.png)

いよいよ修正していきます。
リソースを選択した状態で「修復」を押下します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/ed5cec72-63be-4376-97e3-686455f4c6e3.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/73ffe64d-fef1-0338-7c9c-f0766490b8c6.png)
実行が完了したらフィルターを「準拠」に変更してください。
先ほどは非準拠だったセキュリティグループIDが表示されました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/4b0beb53-9925-9cf9-6b71-6d2048f6ce10.png)


コンソール画面でルールが削除されたか確認してみます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/f7ac8884-b01f-4be1-15c2-38623973cc12.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/166d8eb2-e638-c3bd-a89c-4624f29834cd.png)

全てのルールが削除されていることを確認できました！

# 修復アクションを削除
はじめに　でも記載しましたが、修復アクションが定義されたConfigルールはコンソール画面から削除できません。（ゴ〇仕様)
そのため、CloudShellを使用してConfigルールに紐づけられた修復アクションを削除します。
まず初めにConfigルールに紐づけられた修復アクションを確認します。
``` describe-remediation-configurations.txt
#指定したConfigルールの修復アクションを確認
aws configservice describe-remediation-configurations --config-rule-names {ルール名}
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/ff1e9d07-9583-edf6-4bf5-cbaaab680a28.png)

ルール名に修復アクションが紐づけられていることが確認できました。

次にルールに紐づいた修復アクションを削除します。
``` delete-remediation-configuration.txt
#指定したConfigルールから修復アクションを削除
aws configservice delete-remediation-configuration --config-rule-name {ルール名}
```
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/9ed4e27a-4cc3-4825-42ac-4ad4122a0e9a.png)
削除コマンドを実行し、再度ルールに紐づけられた修復アクションを確認してみると、何も返ってきませんでした。
つまり修復アクションとConfigルールの関連付けが解除できました。
コンソールで確認すると修復アクションが消えていることが確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2615865/0c1559c8-890f-bba5-a890-3aaa743931dc.png)

あとはコンソールから（もしくはCLIコマンド）でルールを削除すればOKです！



* 本記事で紹介した修復アクションは以下のクラスメソッドさんの記事を参考にさせていただきました。非常にわかりやすかったです。ありがとうございます！
*  [修正アクションが関連付けられたAWS Configルールを削除する](https://dev.classmethod.jp/articles/delete-aws-config-rule-with-remedation/)


# おわりに
今回はAWS Configって名前も知ってるし、使ったほうがよりセキュアに保てることは分かっているけど、触ったことないからイマイチイメージがつかめない。。。って方向けに書いてみました。
実際に手を動かさなくてもある程度理解できるように画像多めにしてみましたがいかがでしょうか。
今回はマネージドルールを使用した修正でしたが、Lambdaを使ったカスタムルールも作れるのでそのうち検証して記事書いてみようかなと思ってます。気長にお待ちください（笑）

今回はここまでとなります。
最後まで読んでいただきありがとうございました。