“Deny All” for Public Buckets: AWS Useful resource Management Insurance policies (RCP) Prolong Centralized Cloud Governance

AWS’s launch of Useful resource Controls Insurance policies (RCP) when utilized in mixture with present Service Management Insurance policies (SCP), allows Cloud Architects to create an identification perimeter controlling all undesired permissions and entry to assets at scale. Their utilization removes the necessity for cumbersome least privilege necessities for each workload, facilitating developer innovation.

Understanding RCP

A Useful resource Management Coverage (RCP) denies entry to a permission on a useful resource throughout any account that’s under the OU the place it’s hooked up in an AWS Group. They don’t grant permissions, however outline the utmost permissions and entry which will happen. Builders can nonetheless create useful resource insurance policies and belief that would seem to permit public or exterior entry, however the RCP coverage would override that and deny the entry on the request time.

The Want for RCP

The obvious use case prevents unintended public publicity of assets, together with S3 Knowledge, Queues, Roles, and Secrets and techniques that is perhaps uncovered by way of a misconfigured useful resource coverage. Public S3 buckets are the obvious of the plain.

There are roughly 30 companies in AWS that permit public publicity of assets like this, together with snapshots, backups, tables, keys, gateways, and so forth. Any service within the following AWS reference record that has a inexperienced test within the “Resource-based policies” column would qualify. We sit up for future additions to supported companies within the RCP roadmap.

For instance that is nonetheless an unsolved drawback, a fast soar over to GrayHatWarfare will provide you with some visibility into the variety of recordsdata that get uncovered this fashion.  

Instance State of affairs

Take into account an S3 bucket meant to be accessed from Cloudfront. Nevertheless, the developer is troubleshooting and including a principal of * as an alternative choice to see if that works after getting an error.

--- NEVER USE THIS POLICY ---
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal" : { 
        "AWS": [ 
          "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity XXXXXXXXXXXX",
          "*" 
          ]
        },
      "Action": [
        "s3:PutObject",
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::cloudfront-bucket/*",
        "arn:aws:s3:::cloudfront-bucket"
      ]
    }
  ]
}

This coverage by accident exposes the bucket to the Web unauthenticated. AWS has some ways to dam public S3 buckets, however till now, most different assets couldn’t be blocked.

Repair with Deny First Mannequin

A central strategy to fight the danger of misconfigurations just like the one described above is to implement a ‘deny-first’ mannequin utilizing RCPs. Because the identify suggests, this mannequin begins by denying all public entry throughout all accounts. Nevertheless, it permits for particular, intentional exceptions for public-facing assets, akin to a web site hosted on an S3 bucket. By implementing this mannequin, you possibly can considerably scale back the danger of public useful resource publicity.

Instance Coverage:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "NotResource": [
                        "arn:aws:s3:::website_1",
                        "arn:aws:s3:::website_1/*",
                        "arn:aws:s3:::website_2",
                        "arn:aws:s3:::website_2/*"
                    ]
          }
  ]
}

Alternatively, this might be written utilizing Situations vs. NotResource; nevertheless, NotResource is less complicated and makes use of fewer characters.

Instance Coverage with Situations:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::*",
      "Condition": {
                "StringNotLike": {
                    "aws:ResourceArn": [
                        "arn:aws:s3:::website_1",
                        "arn:aws:s3:::website_1/*",
                        "arn:aws:s3:::website_2",
                        "arn:aws:s3:::website_2/*"
                    ]
        }
      }
    }
  ]
}

Legitimate Makes use of of a Principal of “*”

There are legitimate causes for utilizing a Principal of * in a useful resource coverage that aren’t public and are finest practices.

Examples from AWS Documentation:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "*"
  },
  "Action": "dynamodb:*",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:PrincipalArn": "arn:aws:iam::123456789012:user/John"
    }
  }
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "dynamodb:*",
      "Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/MusicCollection",
      "Condition": {
        "StringEquals": {
          "aws:SourceVpc": [
            "vpc-91237329"
          ]
        }
      }
    }
  ]
}

In each instances, these DynamoDB useful resource insurance policies are restrictive. Nevertheless, what if “arn:aws:iam::123456789012:user/John” is a nasty actor from exterior your account who added that to keep up persistence after a breach clear up.

That is the place RCPs can prevent.  The situation key “aws:PrincipalOrgID” can test if the Identification making the request is a part of an AWS Group and “aws:SourceOrgID” can test if an AWS service making that decision originates from inside your Group. You’ll be able to fully deny entry to all exterior sources utilizing these keys.

For instance, RCP denies entry to all identities and companies exterior your AWS group.

{  
  "Effect": "Allow",
  "Principal": {
    "AWS": "*"
  },
  "Action": "dynamodb:*",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:PrincipalArn": "arn:aws:iam::123456789012:user/John"
    }
  }
}

In case you implement this, you’ll uncover you’ve numerous entry from exterior your Group. For instance, you would possibly use a 3rd social gathering for safety visibility, log administration, efficiency monitoring, price financial savings, and so forth., and people will all instantly break. You additionally may need a number of orgs doing cross-organization logging or Market subscriptions that require entry.

Dealing with Exceptions

The RCP insurance policies help placing in exceptions. I’d argue the Cloud Operations/Infrastructure group ought to concentrate on all third-party entry to your Org. Admittedly, when you haven’t had a lot supervision over growth groups, getting your arms round that is perhaps a process, however a worthwhile one. Assuming you’ve the record of assets these events must entry, it’s fairly simple to flip the “Resource”: “*” a part of the coverage to “NotResource”: “<Allowed Resources>”.

Instance Coverage:

For instance, RCP denies entry to all identities and companies exterior your AWS group.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
		 "Principal": "*",
            "Action": "*",
            "NotResource": [
            	"arn:aws:s3:::my-logs/*",
		 	"arn:aws:iam::*:role/3rdPartyAccessRole"
          	  ],
            "Condition": {
                "StringNotEqualsIfExists": {
                    "aws:PrincipalOrgID": "o-YourOrgID",
                    "aws:SourceOrgID": "o-YourOrgID"
                }
            }
        }
    ]
}

This lets you exempt any useful resource a 3rd social gathering should entry from exterior your org. This may scale up to some extent, however per RCP coverage, the restrict is 5120 characters. If you’re in a situation the place you have to scale past the restrict of what is going to match within the RCP, you will have to make use of ABAC controls akin to “aws:ResourceTag” or “aws:PrincipalTag”.

Why You Want Each SCPs and RCPs

SCPs are controls to your customers and roles that exist in your member accounts. They management which permissions, and underneath what circumstances you permit your principal to execute an API name. We use these closely within the Sonrai Cloud Permissions Firewall.

RCPs management what identities can entry your useful resource with what permissions underneath which circumstances – like encryption. You’ll be able to specify controls that apply to all useful resource sorts or controls that ought to solely apply to assets of a particular sort.

Extra Makes use of for RCP

RCPs will also be used to implement encryption controls, akin to requiring that every one information saved in S3 buckets have to be encrypted at relaxation or in transit:

Instance Coverage:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": ["s3:PutObject",],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    }
  ]
}

This coverage ensures that every one objects put into any S3 bucket or modifications to API Gateway should use AWS KMS for encryption.

Conclusion

AWS’s introduction of RCP provides a sturdy device to the safety arsenal of AWS Organizations, enabling finer management over useful resource entry and guaranteeing that compliance and safety don’t stifle innovation. By understanding and implementing RCP appropriately, organizations can shield their assets from unintended public publicity whereas sustaining the flexibleness required for agile growth.