feat(kms): add kms_cmk_not_multi_region AWS check

[wunzeco]

Context

When developing a custom check to check the multi-region status of keys created in an AWS account, I discovered
that the Key class
was missing a field for the KMS Key KeyMetadata.MultiRegion data. The resulting error I encountered is given below:

E       AttributeError: 'Key' object has no attribute 'multi_region'

Please include relevant motivation and context for this PR.

If fixes an issue please add it with Fix #6792

Description

Please include a summary of the change and which issue is fixed. List any dependencies that are required for this change.

• Addes missing multi_region field to KMS Key class to store the value of KeyMetadata.MultiRegion that is available in the KMS DescribeKey api response

See example output here

• No additional dependencies required for this change

Checklist

• Are there new checks included in this PR? No
  • If so, do we need to update permissions for the provider? Please review this carefully.
• [yes] Review if the code is being covered by tests.
• [N/A] Review if code is being documented following this specification https://github.com/google/styleguide/blob/gh-pages/pyguide.md#38-comments-and-docstrings
• [N/A] Review if backport is needed.
• [No] Review if is needed to change the Readme.md

License

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[MrCloudSec]

Good catch @wunzeco! Just out of curiosity, how is the check you are developing?

[wunzeco]

@MrCloudSec
I was developing a custom check to check the multi-region status of kms keys.
The use case for my organisation is this:

A customer managed key should be single region only. The rationale is that though a multi-region key can facilitate data transfer between AWS regions. However, it can also increase the risk of data exposure because managing access controls and auditing across multi regions becomes more complex, potentially allowing more attack surfaces to could result in compromise of sensitive data.

For organisations with strict data residency requirements (like mine), a multi-region key is not useful.

I'd be happy to contribute this custom check as I believe it might help others.

Currently, I got the custom check working by extending KMS class and Key class locally, which I won't have needed to do if the missing multi_region field was in place. Fortunately, it enabled me explore and be exposed more to the inner workings of this awesome project.

[wunzeco]

Investigating the failed PR build jobs

[MrCloudSec]

@MrCloudSec I was developing a custom check to check the multi-region status of kms keys. The use case for my organisation is this:

A customer managed key should be single region only. The rationale is that though a multi-region key can facilitate data transfer between AWS regions. However, it can also increase the risk of data exposure because managing access controls and auditing across multi regions becomes more complex, potentially allowing more attack surfaces to could result in compromise of sensitive data.

For organisations with strict data residency requirements (like mine), a multi-region key is not useful.

I'd be happy to contribute this custom check as I believe it might help others.

Currently, I got the custom check working by extending KMS class and Key class locally, which I won't have needed to do if the missing multi_region field was in place. Fortunately, it enabled me explore and be exposed more to the inner workings of this awesome project.

It would be great if you can add that check here too so we can add value to the Prowler community 😄

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.70%. Comparing base (763130f) to head (b8c2026).
Report is 27 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6794      +/-   ##
==========================================
- Coverage   93.52%   88.70%   -4.83%     
==========================================
  Files          67     1198    +1131     
  Lines        6330    34578   +28248     
==========================================
+ Hits         5920    30671   +24751     
- Misses        410     3907    +3497     

Flag	Coverage Δ
api	?
prowler	88.70% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
prowler	88.70% <100.00%> (∅)
api	∅ <ø> (∅)

[wunzeco]

@MrCloudSec I was developing a custom check to check the multi-region status of kms keys. The use case for my organisation is this:

A customer managed key should be single region only. The rationale is that though a multi-region key can facilitate data transfer between AWS regions. However, it can also increase the risk of data exposure because managing access controls and auditing across multi regions becomes more complex, potentially allowing more attack surfaces to could result in compromise of sensitive data.

For organisations with strict data residency requirements (like mine), a multi-region key is not useful.
I'd be happy to contribute this custom check as I believe it might help others.
Currently, I got the custom check working by extending KMS class and Key class locally, which I won't have needed to do if the missing multi_region field was in place. Fortunately, it enabled me explore and be exposed more to the inner workings of this awesome project.

It would be great if you can add that check here too so we can add value to the Prowler community 😄

I've added the new check as advised, unit tests included. I followed the pattern in existing kms checks as closely as possible

[MrCloudSec]

Thanks for this new check @wunzeco ! I have added some changes to the metadata and naming.