はじめに
re:Invent2022でAWS Config Ruleに新しい評価モードとして「Proactive」モードが追加されました。これまではConfig Ruleに非準拠のAWSリソースが作成、設定変更後にCofigによるコンプライアンスチェックが実施されていましたが、この新しい評価モードにより事前にチェックすることができるようになりました。
AWSリソースのプロビジョニングや変更に対して発見的統制に加えて予防的統制によるガバナンスを効かせることが可能になるので、実際の所どんなもんなのか確かめたく検証をしてみました。
2種類の評価モード
| 評価モード | 概要 | トリガー | 対応マネージドルール数 (2022/12時点) |
|---|---|---|---|
| Proactive | リソースのプロビジョニング前に、リソースを評価する予防的統制タイプの評価モード | 構成の変更 | 17 |
| Detective | リソースのプロビジョニング後に、リソースの評価する発見的統制タイプの評価モード | 構成の変更と定期的な評価 | 301 |
Proactiveモード対応のルール
Proactiveモードによる評価はマネージドルールのみだけでなく、カスタムルールにもそれぞれ対応しています。
因みに対応しているマネージドルールは現在以下の通りです。リリースされたばかりもあって、対応しているマネージドルールはまだまだ少ないですね。
| 対応マネージドルール | 概要 |
|---|---|
| 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」を使って検証してみたいと思います。
-
Config Ruleの追加
Config Ruleコンソール画面にて「ルールを追加」を押下
-
ルールタイプの選択
「AWSによって管理されるルールの追加」を選択して、検索欄にて「sns-encrypted-kms」を入力、表示されたルールにチェックを入れる
-
Proactiveモード有効化
Evolution modeにて「Turn on proactive evaluation」 を有効化する
-
確認
「Enabled evaluation mode」項にて「PROACTIVE」が表示されていることを確認
Proactiveモード検証
上記設定によりSNSでKMSによる暗号化がされていないトピックの作成する際に自動的に事前評価が走って何かしらのメッセージでも表示されるものと勝手にイメージしていましたが、どうやらそういうものではなかったです。
よくよくリリースドキュメントを読むと、評価してくれますではなくて、評価できますという表現なので基本的には能動的に評価を実行する必要がありそうです。
AWS Config では、リソースのプロビジョニング前に AWS Config ルールへの準拠をプロアクティブに確認する機能をリリースします。AWS Config を使用して、AWS Config ルールと呼ばれる機能により、クラウドリソースに加えられた設定の変更を追跡し、それらのリソースが望ましい設定と一致しているかどうかを確認します。プロアクティブなコンプライアンスによって、クラウドリソースの設定を作成または更新する前に評価できます。
更新が早い英語verの開発者ガイドを確認しましたが、具体的な評価方法の記述が現段階では見つけられなかったので以下のAWSBlogを参考
実施方法としてはAWS Config API、AWS SDK、CloudFormation Guard、CloudFormation Hooksなどがあり、CI/CDパイプラインに組み込む事で事前評価してからデプロイといった事も可能とのこと。
補足
| ツール/機能名 | 概要 |
|---|---|
| CloudFormation Guard | CloudFormationテンプレートのポリシーコンプライアンスをチェックするオープンソースのCLIツール |
| CloudFormation Hooks | スタックを作成、更新、削除する前に、カスタムロジックを呼び出してアクションを自動化したり、リソース設定を検査したりできるようにする機能 |
- CloudFormation Guard
- CloudFormation Hooks
CloudFormation GuardやCloudFormation Hooksは一旦の検証としてはやや面倒なのでAWS Config APIを使って検証します。
評価実行(Rule準拠)
※ResourceConfigurationには対象リソースのCloudFormationスキーマをそれぞれ確認して入力してください。
SNSトピックの場合は以下を参考に、KmsMasterKeyIdをキーに指定
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
出力結果
{
"ResourceEvaluationId": "ce7e63c1-7aa3-40ed-99af-d82036fa1270-1856ce7738e"
}
評価結果の確認
aws configservice get-resource-evaluation-summary --resource-evaluation-id ce7e63c1-7aa3-40ed-99af-d82036fa1270-1856ce7738e
出力結果
EvaluationStatusがSUCCEEDEDとなっているので評価実行は問題なく成功している事が確認できます。
また、ComplianceがCOMPLIANTになっているので、投入したリソース構成はRuleに準拠している事が確認できます。
{
"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を指定した構成で評価を投入してみます。
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
出力結果
{
"ResourceEvaluationId": "b58780e8-acb8-45b1-8dd7-cfd58f4ee444-1856cfbb1dd"
}
評価結果の確認
aws configservice get-resource-evaluation-summary --resource-evaluation-id b58780e8-acb8-45b1-8dd7-cfd58f4ee444-1856cfbb1dd
出力結果
EvaluationStatusがSUCCEEDEDとなっているので評価実行は前回同様に問題なく成功している事が確認できます。
しかし、ComplianceがNON_COMPLIANTになっているので、投入したリソース構成はRuleに準拠していない事が確認できました。
{
"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モードによるリソース構成の評価機能を検証しましたが、カスタムルールはまた別ですが現段階では対応しているマネージドルールが少ない事と、当初勝手にイメージしていた様なプロビジョニング方法に縛りのない自動評価ではなく、自前で作り込んでパイプラインに組み込むか手動で実行する前提の機能だったので、実際に導入していくには時間を要するなというのが正直な所感です。
ハードルはありますが、予防的統制を効かせられるのでこれらが整備されるようになると組織としてより安心を得られるメリットは確かにあると思いました。