Essential AWS Guardrails (SCP/RCP) to Reduce Your 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 AWS IAM Actions Without MFA for IAM Users
Summary:
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.
How it reduces the blast radius:
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:
{
"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 Access to Organizational KMS Keys from Untrusted Networks
Summary:
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.
How it reduces the blast radius:
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:
{
"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"]
}
}
}
]
}Deny IAM Users from Assuming IAM Roles
Summary:
This guardrail prevents IAM users from assuming roles in AWS, which is a common attack vector for privilege escalation.
How it reduces the blast radius:
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:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyIAMUsersFromAssumeRole",
"Effect": "Deny",
"Action": ["sts:AssumeRole"],
"Resource": ["*"],
"Condition": {
"ArnLike": {
"aws:PrincipalArn": ["arn:aws:iam::*:user/*"]
}
}
}
]
}Deny Change of IAM User Permissions
Summary:
This guardrail blocks unauthorized changes to IAM user permissions, ensuring only authorized entities can modify user access rights.
How it reduces the blast radius:
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:
{
"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": ["*"]
}
]
}Deny S3 Buckets Discovery by Non-Human Identities
Summary:
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.
How it reduces the blast radius:
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:
{
"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"]
}
}
}
]
}Deny Confused Deputy via AWS Bedrock Service Principals
Summary:
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.
How it reduces the blast radius:
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:
{
"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"]
}
}
}
]
}Prevent Upload of Objects Using Customer-Provided Keys (SSE-C) to Organizational AWS S3 Buckets
Summary:
This guardrail prevents the uploading of objects to S3 using customer-provided keys (SSE-C), enforcing the use of organization-controlled encryption mechanisms.
How it reduces the blast radius:
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:
{
"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
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.
