AWS launched Access Analyzer Policy Checks to help you develop valid, secure policies and review existing policies. This post explains what the four types of policy checks do and how to start using them. The checks are available via console, CLI, and API (announcement).
These security policy checks provide useful feedback for the entire spectrum of IAM policy authors from beginner through advanced. The checks identify when a policy is invalid, overly permissive, or deviates from best practice and style.
The static analysis is scoped to the single policy being validated, and does not try to assess how access will work out with specific principals nor other policies in the AWS account.
Policies can be analyzed while authoring, during delivery, or after deployment.
Policy Check Finding Types
The 107 policy checks (reference doc) break down into four types of findings:
When you ask AccessAnalyzer to validate a policy using the ValidatePolicy action, it returns a list of findings describing the problems AccessAnalyzer found. Each finding is one of four types, classifying the impact of the finding. Let’s explore those now.
Error
Count: 60
API FindingType: ERROR
An error means a part of the policy is invalid due to invalid policy syntax, structure, or data values.
You may recognize a lot of these checks from working through issues getting a policy to save. The flexibility of AWS security policy language and variation in ARN structure and regional availability show up here.
Examples:
- Json syntax error
- Invalid ARN account, prefix, region, resource, service case
- Invalid Principal format or key
General Warning
Count: 20
API FindingType: WARNING
A General Warning means a statement probably isn’t working as intended or is missing a Best Practice.
Examples:
- Wildcard without like operator
- Type mismatch (for a condition operator)
- Invalid role or user reference
- Statement Id missing or duplicated
Security Warning
Count: 8
API FindingType: SECURITY_WARNING
A Security Warning means there is probably a security issue:
- granting too much permission via
NotPrincipal,NotAction,NotResource - enabling escalation via
iam:PassRole
Focus initial linting and reviews on Security Warnings.
Suggestion
Count: 19
API FindingType: SUGGESTION
Suggestions help you identify and improve awkward or unintended policy elements and conditions to Best Practice.
The suggestions provide sorely-needed help for people using policy conditions. Additionally, the docs explain a number of gotchas that are illuminating.
Examples:
- Empty object or array for principal, resource, or condition
- Redundant action, resource, statement, or condition values
- Private IP address subset (used with aws:SourceIp)
Using Policy Checks
Read through the full checks & recommendation reference to understand more and decide which checks to integrate into your development and delivery processes. Then look for tools that integrate these checks into your policy review and delivery process to find and address these issues early and reliably.
You can integrate today using AWS cli v1’s aws accessanalyzer validate-policy command (docs). AWS cli v2 does not appear to support this command yet.
Summary
The AWS Access Analyzer Policy Checks suite provides policy authors much needed support creating good security policies. These checks identify where a given policy is invalid, overly permissive, or deviate from best practice.
These checks do not provide feedback on what a policy allows specific IAM users or roles to do, but k9 can help. Learn what access IAM principals really have then grant the access you intend by integrating usable IAM access assessments and automation libraries into your delivery process with k9 Security for DevOps.
Recent Comments