chore(kms): add multi_region attribute to AWS KMS key class

[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 😄