[Feature Request] Scope disabled policies with tags

[majormoses]

🙋 feature request

I would like to be able to use tags as an abstraction layer to decide whether or not to disable policies for a given asset. This is very similar to #943 but applies to disabling policies rather than suppressing results for alerting and reporting purposes.

🔦 Context

I many cases companies have used account boundaries for isolating compliance needs, while this is admirable it in many cases is not easily doable and its important for security tools to meet the customer where they are rather than tell them "well you should be here"...chances are they know and they wish they could isolate in such a manner. Rather than unreasonably asking folks to migrate their apps all over the place its more reasonable to ask owners of resources to tag their assets (ideally in automation). Lets empower folks to make light changes in their infrastructure and allow our exception model to be flexible.

Even if you have implemented ☝️ you may find the need to suppress results based on the needs of the individual resource. See the examples for further clarification.

💻 Examples

This is never valid, unless it is

Lets take some very basic guidelines such as "Never expose SSH/RDP to the world". Is this always true or is it ALMOST always true?

It would be preferable to to suppress these types of events with a tag of Service = (Bastion|VPN|...) while not turning off the visibility on other assets within the same account.

Align a compliance framework to defined resources

Often times we have mixed resources that have different security needs. For example you may find that tagging a resource such as RDS, S3, etc with some organizational standard tags could result in reduced noise.

If one tags a resource with (PCI|PHI|...)=(true|false) we can decide how to instruct the platform to activate, disable, or suppress various checks based on the frameworks at play. This becomes more important as we have shared resources in technologies such as k8s where there may be distinct node groups to address compliance needs within the same cluster while allowing flexibility for other use cases.

[PaladinCloudJohn]

Thanks for the feedback, @majormoses,
The engineering team discussed this item, and while it could prove valuable, it didn't make the roadmap for Q2. We hope that once #943 is implemented, it will be able to serve as a stopgap for this need until there is the capacity to add more nuance to the "enable/disable" functionality of policies.