AWS Config Ruleの新たな評価モード「Proactive」モードを検証してみた

# はじめに
re:Invent2022でAWS Config Ruleに新しい評価モードとして「**Proactive**」モードが追加されました。これまではConfig Ruleに非準拠のAWSリソースが**作成、設定変更後**にCofigによるコンプライアンスチェックが実施されていましたが、この新しい評価モードにより**事前**にチェックすることができるようになりました。

https://aws.amazon.com/jp/about-aws/whats-new/2022/11/aws-config-rules-support-proactive-compliance/

AWSリソースのプロビジョニングや変更に対して**発見的統制**に加えて**予防的統制**によるガバナンスを効かせることが可能になるので、実際の所どんなもんなのか確かめたく検証をしてみました。

# 2種類の評価モード
|評価モード|概要|トリガー|対応マネージドルール数<br>(2022/12時点)|
|---|---|---|:---:|
|Proactive|リソースの**プロビジョニング前**に、リソースを評価する予防的統制タイプの評価モード|構成の変更|17|
|Detective|リソースの**プロビジョニング後**に、リソースの評価する発見的統制タイプの評価モード|構成の変更と定期的な評価|301|

https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config-rules.html

# Proactiveモード対応のルール
Proactiveモードによる評価は**マネージドルール**のみだけでなく、**カスタムルール**にもそれぞれ対応しています。

因みに対応しているマネージドルールは現在以下の通りです。リリースされたばかりもあって、対応しているマネージドルールはまだまだ少ないですね。

https://docs.aws.amazon.com/ja_jp/config/latest/developerguide/managed-rules-by-evaluation-mode.html

|対応マネージドルール|概要|
|---|---|
|api-gw-xray-enabled|Amazon API Gateway REST APIでAWS X-Rayトレースが有効になっているかどうかを確認|
|autoscaling-group-elb-healthcheck-required|Classic Load Balancerに関連付けられたAuto Scalingグループで、Elastic Load Balancingのヘルスチェックが使用されているかどうかを確認|
|ec2-instance-multiple-eni-check|EC2で複数のENIまたはEFAが使用されているかどうかを確認|
|eip-attached|ElasticIPアドレスが、EC2またはENIにアタッチされているかどうかを確認|
|elasticsearch-node-to-node-encryption-check|ElasticSearchノードがエンドツーエンドで暗号化されているかどうかを確認|
|lambda-function-settings-check|Lambda関数設定の内、ランタイム、ロール、タイムアウト、メモリサイズが予期されている値と一致するかどうか確認|
|lambda-inside-vpc|Lambda関数によるVPCアクセスが許可されているかどうかを確認|
|rds-automatic-minor-version-upgrade-enabled|RDSが自動マイナーバージョンアップグレードに設定されているかどうかを確認|
|rds-enhanced-monitoring-enabled|RDSインスタンスに対して拡張モニタリングが有効になっているかどうかを確認|
|rds-instance-public-access-check|RDSインスタンスがパブリックアクセス可能になっていないかどうかを確認|
|rds-multi-az-support|RDSインスタンスでMulti-AZが有効になっているかどうかを確認|
|rds-storage-encrypted|RDSインスタンスに対してストレージの暗号化が有効になっているかどうかを確認|
|redshift-cluster-maintenancesettings-check|Redshiftクラスターに、指定されたメンテナンス設定があるかどうか確認|
|redshift-cluster-public-access-check|Redshiftクラスターがパブリックアクセス可能になっていないかどうかを確認|
|s3-bucket-logging-enabled|S3バケットに対してログ記録が有効になっているかどうか確認|
|sns-encrypted-kms|SNSトピックがKMSで暗号化されているかどうかを確認|
|subnet-auto-assign-public-ip-disabled|VPCサブネットにパブリックIPアドレスが割り当てられているかどうかを確認|

# Proactiveモード対応設定
**※リリースでは全商用リージョンでGAとされていましたが、2022年12月時点では東京リージョンで使えなかったのでバージニア北部で検証します。**

当然ですが、前提として対象リージョンにてAWS Configを有効にする必要があります。

今回はマネージドルール「**sns-encrypted-kms**」を使って検証してみたいと思います。

1. Config Ruleの追加
Config Ruleコンソール画面にて「ルールを追加」を押下
![スクリーンショット_2023-01-01_18_14_57.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/354022/5280e490-3066-9f50-74d2-3f38920a3181.png)

1. ルールタイプの選択
「AWSによって管理されるルールの追加」を選択して、検索欄にて「sns-encrypted-kms」を入力、表示されたルールにチェックを入れる
![スクリーンショット_2023-01-01_18_20_07.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/354022/39c6d74f-8119-5ede-b2c1-2487452fb14b.png)

1. Proactiveモード有効化
Evolution modeにて「Turn on proactive evaluation」 を有効化する
![スクリーンショット_2023-01-01_18_15_37.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/354022/79ddb643-0658-40fa-ad9f-309fb27ec24c.png)

1. 確認
「Enabled evaluation mode」項にて「PROACTIVE」が表示されていることを確認
![空白_Skitch_キャンバス.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/354022/f4ae62f9-06d3-b41f-82a3-d454c1e11b38.png)

# Proactiveモード検証
上記設定によりSNSでKMSによる暗号化がされていないトピックの作成する際に自動的に事前評価が走って何かしらのメッセージでも表示されるものと勝手にイメージしていましたが、どうやらそういうものではなかったです。

よくよくリリースドキュメントを読むと、**評価してくれます**ではなくて、**評価できます**という表現なので基本的には能動的に評価を実行する必要がありそうです。

>AWS Config では、リソースのプロビジョニング前に AWS Config ルールへの準拠をプロアクティブに確認する機能をリリースします。AWS Config を使用して、AWS Config ルールと呼ばれる機能により、クラウドリソースに加えられた設定の変更を追跡し、それらのリソースが望ましい設定と一致しているかどうかを確認します。プロアクティブなコンプライアンスによって、クラウドリソースの設定を作成または更新する前に評価できます。

更新が早い英語verの開発者ガイドを確認しましたが、具体的な評価方法の記述が現段階では見つけられなかったので以下のAWSBlogを参考

https://aws.amazon.com/jp/blogs/news/new-aws-config-rules-now-support-proactive-compliance/

実施方法としては**AWS Config API**、**AWS SDK**、**CloudFormation Guard**、**CloudFormation Hooks**などがあり、CI/CDパイプラインに組み込む事で事前評価してからデプロイといった事も可能とのこと。

### 補足
|ツール/機能名|概要|
|---|---|
|CloudFormation Guard|CloudFormationテンプレートのポリシーコンプライアンスをチェックするオープンソースのCLIツール|
|CloudFormation Hooks|スタックを作成、更新、削除する前に、カスタムロジックを呼び出してアクションを自動化したり、リソース設定を検査したりできるようにする機能|

- CloudFormation Guard

https://aws.amazon.com/jp/about-aws/whats-new/2022/06/aws-cloudformation-guard-2-1-available/

- CloudFormation Hooks

https://aws.amazon.com/jp/about-aws/whats-new/2022/02/aws-announces-general-availability-aws-cloudformation-hooks/

CloudFormation GuardやCloudFormation Hooksは一旦の検証としてはやや面倒なのでAWS Config APIを使って検証します。

## 評価実行(Rule準拠)

https://awscli.amazonaws.com/v2/documentation/api/latest/reference/configservice/start-resource-evaluation.html

※**ResourceConfiguration**には対象リソースのCloudFormationスキーマをそれぞれ確認して入力してください。

SNSトピックの場合は以下を参考に、**KmsMasterKeyId**をキーに指定

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-sns-topic.html

```sh
aws configservice start-resource-evaluation --evaluation-mode PROACTIVE \
    --resource-details '{"ResourceId":"sampleTopic",
                         "ResourceType":"AWS::SNS::Topic",
                         "ResourceConfiguration":"{\"KmsMasterKeyId\":xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}",
                         "ResourceConfigurationSchemaType":"CFN_RESOURCE_SCHEMA"}' \
    --evaluation-timeout 60
```

## 出力結果
```sh
{
    "ResourceEvaluationId": "ce7e63c1-7aa3-40ed-99af-d82036fa1270-1856ce7738e"
}
```

## 評価結果の確認

https://awscli.amazonaws.com/v2/documentation/api/latest/reference/configservice/get-resource-evaluation-summary.html

```sh
aws configservice get-resource-evaluation-summary --resource-evaluation-id ce7e63c1-7aa3-40ed-99af-d82036fa1270-1856ce7738e
```

## 出力結果
**EvaluationStatus**が**SUCCEEDED**となっているので評価実行は問題なく成功している事が確認できます。

また、**Compliance**が**COMPLIANT**になっているので、投入したリソース構成は**Ruleに準拠している**事が確認できます。

```diff_json
{
    "ResourceEvaluationId": "ce7e63c1-7aa3-40ed-99af-d82036fa1270-1856ce7738e",
    "EvaluationMode": "PROACTIVE",
    "EvaluationStatus": {
+        "Status": "SUCCEEDED"
    },
    "EvaluationStartTimestamp": "2023-01-01T10:36:25.922000+00:00",
+    "Compliance": "COMPLIANT",
    "ResourceDetails": {
        "ResourceId": "sampleTopic",
        "ResourceType": "AWS::SNS::Topic",
        "ResourceConfiguration": "{\"KmsMasterKeyId\":xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}"
    }
}
```

## 評価実行(Rule非準拠)
今度はConfig Ruleに関係のないDisplayNameを指定した構成で評価を投入してみます。

```sh
aws configservice start-resource-evaluation --evaluation-mode PROACTIVE \
    --resource-details '{"ResourceId":"sampleTopic",
                         "ResourceType":"AWS::SNS::Topic",
                         "ResourceConfiguration":"{\"DisplayName\":non-compliant-test}",
                         "ResourceConfigurationSchemaType":"CFN_RESOURCE_SCHEMA"}' \
    --evaluation-timeout 60
```

## 出力結果

```sh
{
    "ResourceEvaluationId": "b58780e8-acb8-45b1-8dd7-cfd58f4ee444-1856cfbb1dd"
}
```

## 評価結果の確認

```sh
aws configservice get-resource-evaluation-summary --resource-evaluation-id b58780e8-acb8-45b1-8dd7-cfd58f4ee444-1856cfbb1dd
```

## 出力結果
**EvaluationStatus**が**SUCCEEDED**となっているので評価実行は前回同様に問題なく成功している事が確認できます。

しかし、**Compliance**が**NON_COMPLIANT**になっているので、投入したリソース構成は**Ruleに準拠していない**事が確認できました。

```diff_json
{
    "ResourceEvaluationId": "b58780e8-acb8-45b1-8dd7-cfd58f4ee444-1856cfbb1dd",
    "EvaluationMode": "PROACTIVE",
    "EvaluationStatus": {
+        "Status": "SUCCEEDED"
    },
    "EvaluationStartTimestamp": "2023-01-01T10:58:32.588000+00:00",
-    "Compliance": "NON_COMPLIANT",
    "ResourceDetails": {
        "ResourceId": "sampleTopic",
        "ResourceType": "AWS::SNS::Topic",
        "ResourceConfiguration": "{\"DisplayName\":non-compliant-test}"
    }
}
```

# まとめ
今回、新規に追加されたProactiveモードによるリソース構成の評価機能を検証しましたが、カスタムルールはまた別ですが現段階では対応しているマネージドルールが少ない事と、当初勝手にイメージしていた様なプロビジョニング方法に縛りのない自動評価ではなく、自前で作り込んでパイプラインに組み込むか手動で実行する前提の機能だったので、実際に導入していくには時間を要するなというのが正直な所感です。

ハードルはありますが、予防的統制を効かせられるのでこれらが整備されるようになると組織としてより安心を得られるメリットは確かにあると思いました。