Maximizing IAM security with AWS permissions boundaries and Snyk

In today's rapidly evolving cloud landscape, managing permissions and ensuring robust security controls are essential for organizations utilizing Amazon Web Services (AWS). AWS Identity and Access Management (IAM) is crucial in managing permissions to access AWS resources. While IAM provides granular control over permissions, AWS IAM permissions boundaries offer additional security and flexibility for fine-tuning access controls.

An AWS permissions boundary is a security mechanism that limits the permissions an IAM principal (users and roles) can perform. By setting a permissions boundary, organizations can establish a consistent and well-defined authorization framework that prevents the accidental or intentional escalation of privileges. Permissions setting helps mitigate the risk of unauthorized access to sensitive resources and limits the potential impact of security breaches or human errors.

In short, permissions boundaries are guardrails around permissions. However, they do not GRANT permissions themself. For example, this user has no permissions even though it has the SecurityAudit permissions boundary:

Benefits and use cases

IAM permissions boundaries are particularly useful in organizations with a distributed or complex IAM environment. 

Consider the following use cases where permissions boundaries can enhance security and operational efficiency:

1. Centralized cloud IAM teams: Permissions boundaries empower teams or business units to manage their own IAM entities and associated permissions within the boundaries defined by the organization's security policies. This delegation of administrative tasks enhances agility and autonomy while maintaining a centralized security framework. The “delegated administrator” is the primary use case of IAM permissions boundaries.
2. Multi-tenant environments: In shared infrastructure environments or multi-tenant applications, permissions boundaries help prevent one tenant from accessing another tenant's resources. Organizations can ensure isolation and maintain strong security boundaries by defining boundaries specific to each tenant.
3. Segregation of duties: Permissions boundaries are valuable for separating and enforcing organizational responsibilities. Administrators can prevent unauthorized actions by assigning boundaries based on job functions, such as development, testing, or production.
4. Third-party access: Permissions boundaries offer an added control layer when granting access to external parties, such as contractors or vendors. By defining a boundary that limits their access to only the necessary resources, organizations can mitigate the risks associated with granting broad permissions to third parties.

How permissions boundaries are evaluated

If an IAM entity has a permissions boundary is defined during policy evaluation, it is evaluated near the end of the process as shown here:

The IAM permissions decision tree is a complex beast. Note that these diagrams don't include cross-account access or fully expand on resource-based policies. Each column represents a potential source for allowing or denying permissions for IAM principals. Permissions boundaries fall in the fifth lane for permissions evaluation and can allow or deny permissions. 

One important observation is that resource-based policies can override the intention of IAM permissions boundaries. If a resource-based policy grants permissions directly to the principal making the request, then an implicit denial in a permissions boundary does not impact the final decision. This is due to resource-based policies being evaluated before the permissions boundary.

To maintain a robust security posture, organizations must carefully design and monitor resource policies to align with their intended security boundaries. Regular audits, reviews, developer tooling, and SCM integration of permissions policies are all necessary to ensure that any overrides are intentional and adhere to the principle of least privilege.

Snyk rules

Snyk stands alone as the only infrastructure as code (IaC) security tool and code-to-cloud suite to evaluate IAM permissions boundaries and include the following rules. The screenshots included with each rule are from running the Snyk CLI.

IAM principal has no permissions boundary

This policy will generate findings for IAM roles and users with no assigned permissions boundary. A centralized or distributed IAM team can quickly gain visibility into whether or not permissions boundaries are being used. The following Terraform snippet generates findings for this rule as neither user:

IAM principal has overly permissive permissions boundary

Of the IAM roles and users with permissions boundaries, this policy looks for permissions boundaries that may be too broad. For example, an IAM permissions boundary of:

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": “*”,
        "Resource": "*"
    }]
}

Is really no permissions boundary at all. With this additional visibility, organizations are able to more effectively reduce permissions by following the least privilege principle. The following Terraform generates findings for each IAM principal whose permissions boundaries are too broad:

IAM delegated admin is misconfigured

As noted, IAM delegated administrators are the predominant use case for permissions boundaries. This enables centralized IAM teams to allow developers to create their own users and roles to meet business needs while still maintaining a degree of control over the accounts in which those users and roles are created. However, these newly created principals also need permissions boundaries of their own. IAM teams can require this by using a properly configured IAM policy with IAM conditions. Here, we inspect user and role permissions which can create other principals and evaluate their IAM policy for the appropriate conditions. These findings provide visibility into the potential for privilege escalation by delegated administrators.

Resource policy overrides permissions boundary

This proposed Snyk rule inspects resource policies to determine which IAM principals are granted access to the given resource and whether the principal should have access based on their identity-based policies and permissions boundaries. This helps organizations determine where there may be a gap in their security posture, i.e., where resource-based policies may override permissions boundaries. Some of these resources which support resource-based policies are:

• S3 buckets
• KMS keys
• DynamoDB tables
• SecretsManager secrets

Automating your security governance with Snyk

Snyk IaC empowers developers to secure your configurations with a unified policy engine for consistent security visibility and governance from IDE to running cloud environments. In addition to the built-in Snyk security rulesets for IAM permissions outlined above, teams can define custom rules in OPA’s Rego query language and ensure cloud compliance with compliance-mapped rulesets for 10+ supported frameworks. 

References

• Permissions boundaries for IAM entities
• Delegating responsibility to others using permissions boundaries
• When and where to use IAM permissions boundaries
• Policy evaluation logic
• AWS services that work with IAM