AWS Identity and Access Management (IAM) is the security bedrock of any AWS environment. However, managing security in multi-account organizations requires moving beyond basic identity-based policies. True enterprise isolation is achieved by combining fine-grained policies, Permissions Boundaries, Attribute-Based Access Control (ABAC), and Service Control Policies (SCPs) at the Organization level.
This reference sheet covers policy structures, evaluation logic, permissions boundaries, ABAC tagging configurations, and enterprise SCP templates.
- Policy Structure: Write secure policies conforming to the standard
SID-Effect-Action-Resource-Conditionsyntax. - Permissions Boundaries: Restrict user privilege limits using boundary guards to delegate admin access safely.
- ABAC Tagging: Implement scalable Attribute-Based Access Control utilizing resource tags and principal tags.
- Service Control Policies: Establish coarse-grained guardrails across entire AWS Accounts using Organizations SCPs.
Before diving into this cheatsheet, check out my previous deep-dive on AWS DynamoDB Single-Table Design Cheatsheet: The Complete Reference to see how we structured these patterns in practice.
Standard IAM Policy Structure
All IAM policies resolve to a JSON structure. Understanding the evaluation logic is key: an explicit Deny always overrides any Allow permissions.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "EnforceMfaAndSecureTransport",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::meshworld-secure-data/*",
"Condition": {
"Bool": {
"aws:SecureTransport": "false",
"aws:MultiFactorAuthPresent": "false"
}
}
},
{
"Sid": "AllowS3ReadWrite",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::meshworld-secure-data/*"
}
]
}Applying Permissions Boundaries
Permissions boundaries are advanced policies used to control the maximum permissions that an identity-based policy can grant to an IAM user or role. They are ideal for delegating admin rights without risk of privilege escalation.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "LimitAllowedServices",
"Effect": "Allow",
"Action": [
"s3:*",
"ec2:*",
"rds:*"
],
"Resource": "*"
},
{
"Sid": "DenyIamModificationsExceptBoundaryAttachment",
"Effect": "Deny",
"Action": [
"iam:CreateUser",
"iam:PutUserPolicy",
"iam:AttachUserPolicy"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"iam:PermissionsBoundary": "arn:aws:iam::111122223333:policy/DeveloperBoundary"
}
}
}
]
}Scaling with ABAC (Attribute-Based Access Control)
ABAC allows you to configure authorization rules based on attributes (tags) on both the IAM principal (user/role) and the AWS resource. This reduces policy bloat as your organization scales.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowReadWriteIfProjectTagsMatch",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Project": "${aws:PrincipalTag/Project}",
"aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}"
}
}
}
]
}Configuring Service Control Policies (SCPs)
Service Control Policies are organization-level guardrails that restrict actions in member accounts of an AWS Organization. SCPs do not grant permissions; they define maximum permission thresholds.
1. Enforce Region Compliance
Prevent deployment of resources outside authorized geographic compliance regions.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllOutsideAllowedRegions",
"Effect": "Deny",
"NotAction": [
"iam:*",
"organizations:*",
"route53:*",
"cloudfront:*",
"support:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"us-east-1",
"eu-west-1"
]
}
}
}
]
}2. Block Root User Actions
Enforce the practice of using IAM roles instead of the Account Root User.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictRootUserActivity",
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:PrincipalArn": "arn:aws:iam::*:root"
}
}
}
]
}
