Essential AWS Guardrails (SCP / RCP) to Reduce Blast Radius
Practical AWS guardrails that shrink the blast radius, block privilege escalation, and enforce safer cloud operations using organization-wide SCP and RCP controls.
As cyber attacks become more frequent, it’s more important than ever to have environments that are self-protecting with strong security measures. While basic guardrails like preventing users from leaving the organization or disabling unused regions are essential, today we’ll focus on a few key AWS guardrails that provide extra protection for your cloud infrastructure. These examples demonstrate key policies that can significantly reduce your blast radius, but they represent just a fraction of the comprehensive set of controls needed. There are many more policies – across various levels of complexity – that should be implemented alongside these to effectively minimize exposure to threats and limit lateral movement in the event of a breach. While these guardrails can be implemented using IAM and resource-based policies, we strongly recommend implementing them with Service Control Policies and Resource Control Policies at the organization level. This ensures a broader coverage across all accounts and units within the organization.
Disclaimer: Before implementing these guardrails, it’s crucial to simulate their impact and add the right exclusions that manages the accepted risk to ensure they won’t disrupt workflows.
Deny Sensitive IAM Actions Without MFA (Organization SCP)
What this Guardrail Enforces: Scope & Intent
This guardrail blocks IAM users from executing sensitive actions-such as modifying roles or users – unless MFA is enabled. MFA ensures that attackers who may have stolen credentials cannot perform critical operations without an additional layer of authentication.
Security Impact: How MFA Blocks Credential Abuse
Enforcing MFA for sensitive IAM actions prevents unauthorized privilege escalation and credential management. Attackers may steal access keys, but they won’t be able to perform high-risk actions like deleting users or attaching policies without triggering MFA.
Example SCP: Deny STS: AssumeRole Without MFA Conditions
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenySensitiveIAMActionsWithoutMFA",
"Effect": "Deny",
"Action": [
"iam:DeleteGroup",
"iam:DeleteGroupPolicy",
"iam:DeletePolicyVersion",
"iam:DeleteRole",
"iam:DeleteRolePolicy",
"iam:DeleteUser",
"iam:DeleteUserPolicy",
"iam:DetachGroupPolicy",
"iam:DetachRolePolicy",
"iam:DetachUserPolicy",
"iam:RemoveUserFromGroup",
"iam:DeleteAccessKey",
"iam:SetDefaultPolicyVersion",
"iam:AttachGroupPolicy",
"iam:AttachRolePolicy",
"iam:AttachUserPolicy",
"iam:PutGroupPolicy",
"iam:PutUserPermissionsBoundary",
"iam:PutUserPolicy",
"iam:PutRolePermissionsBoundary",
"iam:PutRolePolicy",
"iam:UpdateAssumeRolePolicy",
"iam:RemoveRoleFromInstanceProfile",
"iam:UpdateAccessKey"
],
"Resource": ["*"],
"Condition": {
"ArnLike": {
"aws:PrincipalArn": ["arn:aws:iam::*:user/*"]
},
"BoolIfExists": {
"aws:MultiFactorAuthPresent": ["false"]
}
}
}
]
}
Deny KMS Key Access From Untrusted Networks (RCP/SCP)
Risk Summary: Preventing Key Exfiltration & Misuse
This guardrail ensures that AWS KMS keys can only be accessed from trusted networks, blocking cryptographic key operations from untrusted sources, such as the public internet.
Operational Effect: Limits Cross-Account Crypto Abuse
By enforcing this guardrail, access to KMS keys is restricted to internal environments, minimizing the risk of key exposure and attacks originating from compromised or untrusted networks.
Example RCP: Enforce VPC Endpoint & Source IP Controls
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "KMSEnforceNetworkPerimeter",
"Effect": "Deny",
"Action": ["kms:*"],
"Resource": ["*"],
"Principal": "*",
"Condition": {
"StringNotEqualsIfExists": {
"aws:SourceVpc": [
"{{ [ EndpointVPCs ] }}"
]
},
"NotIpAddressIfExists": {
"aws:SourceIp": [
"{{ [ CustomerCIDRs ] }}"
]
},
"BoolIfExists": {
"aws:ViaAWSService": ["false"],
"aws:PrincipalIsAWSService": ["false"]
}
}
}
]
}Prevent IAM Users from Assuming Roles Directly (SCP)
Why Blocking Direct AssumeRole Matters for Containment
This guardrail prevents IAM users from assuming roles in AWS, which is a common attack vector for privilege escalation.
Containment Benefit: Reduces Lateral Privilege Escalation
IAM users already have sufficient permissions for their needs. Allowing them to assume additional roles opens up the potential for unauthorized privilege escalation. This guardrail blocks that opportunity, ensuring that role assumption isn’t misused for unauthorized access.
Example SCP: Deny AssumeRole for IAM Principals
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyIAMUsersFromAssumeRole",
"Effect": "Deny",
"Action": ["sts:AssumeRole"],
"Resource": ["*"],
"Condition": {
"ArnLike": {
"aws:PrincipalArn": ["arn:aws:iam::*:user/*"]
}
}
}
]
}Deny IAM User Permission Changes (Org SCP)
Business Impact: Prevents Privilege Creep & Backdoors
This guardrail blocks unauthorized changes to IAM user permissions, ensuring only authorized entities can modify user access rights.
Attack Surface Reduction: Locks Down Escalation Paths
This guardrail mitigates the risk of privilege escalation by preventing unauthorized modifications to IAM user permissions. If an attacker compromises a user, they won’t be able to change their own permissions or escalate privileges by adding new policies.
Example SCP: Block IAM:PutUserPolicy / AddUserToGroup
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyChangeUserPermissions",
"Effect": "Deny",
"Action": [
"iam:AddUserToGroup",
"iam:AttachGroupPolicy",
"iam:AttachUserPolicy",
"iam:DeleteUserPermissionsBoundary",
"iam:PutGroupPolicy",
"iam:PutUserPermissionsBoundary",
"iam:PutUserPolicy"
],
"Resource": ["*"]
}
]
}Prevent S3 Bucket Discovery by Non-Human Identities
Privacy & Data Exposure Risk: Why Discovery Matters
This guardrail blocks non-human identities (e.g., service accounts) from listing S3 buckets in order to reduce exposure to sensitive storage resources and limit unauthorized enumeration of buckets.
Data Containment: Limits Automated Reconnaissance
By preventing service accounts from listing S3 buckets, this guardrail limits attackers’ ability to gather information about S3 buckets and objects, thus reducing the risk of information stealing and lateral movement.
Example SCP: Deny s3:ListBucket for Non-Human Principals
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyS3ServiceDiscovery",
"Effect": "Deny",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketAcl",
"s3:GetBucketPolicy"
],
"Resource": ["*"],
"Condition": {
"ArnLike": {
"aws:PrincipalArn": ["arn:aws:iam::*:role/*"]
},
"ArnNotLike": {
"aws:PrincipalArn": ["arn:aws:iam::*:role/aws-reserved/sso.amazonaws.com/*"]
},
"BoolIfExists": {
"aws:PrincipalIsAWSService": ["false"]
}
}
}
]
}Mitigate Confused Deputy Attacks (Service Principals)
Threat Overview: How Confused Deputy Enables Abuse
This guardrail protects against confused deputy attacks by ensuring that AWS Bedrock service principals cannot assume unintended roles or access unauthorized resources from a different account or organization.
Prevents Service Acting As Proxy: Limits Privilege Escalation
By preventing Bedrock from being used as a relay for unauthorized access, this guardrail protects sensitive data and resources from being compromised via misconfigured or exploited service principals.
Example RCP: Constrain Service Principal Actions by Condition
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "BedrockConfusedDeputyProtection",
"Effect": "Deny",
"Action": ["sts:AssumeRole"],
"Resource": ["*"],
"Principal": {
"Service": ["bedrock.amazonaws.com"]
},
"Condition": {
"StringNotEquals": {
"aws:SourceOrgId": ["{{ OrgID }}"]
},
"Null": {
"aws:SourceAccount": ["false"]
}
}
}
]
}Block SSE-C Uploads to Org S3 (RCP)
Why SSE-C is Dangerous in Org Contexts: Key Management Risk
This guardrail prevents the uploading of objects to S3 using customer-provided keys (SSE-C), enforcing the use of organization-controlled encryption mechanisms.
Data Loss & Forensics: Keeps Org In Control of Keys
Using SSE-C for encryption in S3 is a known attack vector exploited by ransomware to encrypt S3 data. This practice is rarely used by AWS operators, but its existence opens up opportunities for attackers to leverage unauthorized encryption methods. By mandating internal encryption controls, this guardrail ensures that encryption keys are managed within your organization, reducing the risk of unauthorized data access.
Example RCP: Deny PutObject with x-amz-server-side-encryption-c
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyS3SSECObjectUpload",
"Effect": "Deny",
"Action": ["s3:PutObject"],
"Resource": ["*"],
"Principal": "*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption-customer-algorithm": ["false"]
},
"Bool": {
"aws:PrincipalIsAWSService": ["false"]
}
}
}
]
}Conclusion: Prioritize Guardrails, Measure, Automate Rollout
These guardrails are just a few examples of the policies that can help reduce the blast radius in AWS environments. However, they are not exhaustive. To truly safeguard your environment, it’s essential to implement a comprehensive suite of AWS guardrails, continuously test and simulate their impact, and adapt to new emerging threats. While these guardrails can be applied at the IAM and resource levels, we highly recommend using SCP and RCP at the organization level for broader coverage. This approach will ensure that security is enforced across all parts of your AWS infrastructure, reducing the attack surface and enhancing your organization’s overall security posture. Before implementing these guardrails, it’s critical to test and simulate their impact. At Blast Security, we offer an advanced platform that allows you to actively manage these guardrails, stopping malicious activities and misconfigurations with a simulation-driven approach and accepted risk management strategies.
