Changing handling of StringNotLike in Conditions

[tweedge]

From Policy Universe's statement.py, there's a lengthy comment on StringNotLike et al:

Extracts any ARNs, Account Numbers, UserIDs, Usernames, CIDRs, VPCs, and VPC Endpoints from a condition block. Ignores any negated condition operators like StringNotLike. Ignores weak condition keys like referer, date, etc. Reason: A condition is meant to limit the principal in a statement. Often, resource policies use a wildcard principal and rely exclusively on the Condition block to limit access. We would want to alert if the Condition had no limitations (like a non-existent Condition block), or very weak limitations. Any negation would be weak, and largely equivalent to having no condition block whatsoever.

My personal opinion is that this is worth avoiding, but in the interest of guiding people from poor to better practices (and explaining why along the way), I believe it would also be worthwhile to expose this opinion more directly. For example, this could take several forms:

• Exposing some sort of "Policy Uses Bad Practices" check, or
• Modulating internet accessibility results with a boolean to allow/disallow bad practices (leaving the default as "disallow bad practices"), or
• Other currently unknown solutions?

If I created a PR for any of the above, would Policy Universe team support its inclusion? If so, let me know which ones!