AWS pre:Invent 2024? That’s right, re:Invent is just around the corner. However, AWS have already softened us up with plenty of goodness in some pre-conference announcements. Here’s our pick of the security related announcements.

Resource control policies

What is it?

Resource Control Policies (RCPs)  are a new type of authorization policy aimed at providing fine-grained access control for AWS resources. RCPs are similar to Service Control Policies (SCPs). SCPs are used to limit permissions granted to identities in an AWS Organization. RCPs enable security teams to define specific resource-level permissions for AWS services. This allows administrators to restrict access to resources based on criteria such as resource tags, environment, or resource types.

Why should I care?

This feature is particularly useful for teams that require more granular control over which users or roles can access or modify certain resources. It allows consistency between related resources across accounts and the whole Organization. They complement existing IAM policies and make it easier to enforce security best practices in large-scale AWS environments.

For example, you might want to restrict access to Amazon S3 buckets containing highly sensitive data to a set of service principals only

How can I use it?

RCPs can be used alongside existing IAM (Identity and Access Management) policies to further restrict actions based on resources, rather than just actions or services. You can define RCPs at a service level, restricting certain AWS services or roles from accessing a specific or broad set of resources.

To get started you need to enable RCPs in the Organization console. Once done, create a policy and attach it to an account, an OU or the whole Organization just like an SCP.

Centrally managing root access for customers using AWS Organizations

What is it?

This new AWS IAM capability allows security teams to centrally manage root access for member accounts in an AWS Organization. With this new feature, you can easily manage root credentials and perform highly privileged actions.

Why should I care?

AWS accounts are provisioned with highly privileged root user credentials. Each AWS account root user had to be secured by adding protection such as multi-factor authentication (MFA). Security teams are required to manage and secure these root credentials manually.

As customers expand to 10s or 100s of AWS account, this manual approach became unmanageable. The manual intervention not only adds operational overhead but also  increases security risks. If not appropriately secured, unauthorized root access can lead to account takeovers and access to sensitive resources.

How can I use it?

The first step is to enable Root credentials management and Privileged root actions in the IAM console under Account settings.

Once enabled, you can use this new AWS pre:Invent 2024 announcement to perform one of the following tasks in a member account:

  • Remove existing root credentials
  • Recovery root credentials
  • Audit root credentials
  • Unlock an S3 bucket policy
  • Unlock an SQS queue policy

Let’s run through an example. First, using an appropriate role, we use the new AssumeRoot action to get root credentials in the member account. You need to include the specific policy, in this case to audit the root credentials for the account.

% aws sts assume-root --region us-east-1 --target-principal 123456789012 --task-policy-arn arn=arn:aws:iam::aws:policy/root-task/IAMAuditRootUserCredentials

Now I use the returned temporary credentials in my shell and check the session identity.

% export AWS_ACCESS_KEY_ID="ASIAXXXX"
% export AWS_SECRET_ACCESS_KEY="XXXX"
% export AWS_SESSION_TOKEN="XXXX=="

% aws sts get-caller-identity
{
    "UserId": "123456789012",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:root"
}

Finally we can get information on when the root credentials were last used.

% aws iam get-user
{
    "User": {
        "UserName": "aws-account-name",
        "UserId": "123456789012",
        "Arn": "arn:aws:iam::123456789012:root",
        "CreateDate": "2013-10-22T08:14:41+00:00",
        "PasswordLastUsed": "2024-09-25T05:28:22+00:00"
    }
}

VPC Block Public Access

What is it?

The VPC Block Public Access feature provides a simple and centralized way to control public internet access to AWS resources within a VPC. It improves security by blocking unintended exposure of resources, simplifies compliance management, and ensures that public access is only granted where explicitly needed, reducing the attack surface for AWS environments.

Why should I care?

The VPC Block Public Access feature allows customers to easily block public internet access to resources in their VPC, including EC2 instances and load balancers, by default or at a granular level. It is designed to help organizations secure their AWS environments and comply with security best practices by reducing the risk of inadvertent public exposure.

How can I use it?

This new feature provides a central setting that can block public access to all resources within a VPC. It can also be applied selectively to specific subnets or resources. You can block all traffic or, for example, allow egress but not ingress public access. It can be set at the account level and applied to all VPCs in the account. You can selectively exclude VPCs or subnets from the account level setting.

Get started under Settings in the VPC console

AWS WAF no longer charges for blocked requests

What is it?

Our last AWS pre:Invent 2024 announcement is not a feature or a new service but it is highly welcome! AWS has dropped charges in AWS WAF for blocked Cloudfront requests.

Why should I care?

AWS WAF is a awesome service to protect your workloads against security threats. For example, you can configure it to block SQL injection or cross-site scripting attack payloads. However, if your workload is targeted in an attack, and AWS WAF blocks the payloads, you can clock up a pretty chunky bill, particularly if the attack is sustained for a period of time. Until now,  AWS Shield Advanced was like an insurance policy against bill shock but it’s not a cheap service, particularly for a startup or scale out organization. Your friendly account team will normally try and help you out with some credits should you be in this position.

With this new announcement, you will no longer have to pay for blocked Cloudfront requests in AWS WAF!

How can I use it?

It’s already in place. Just remember, this applies to AWS WAF requests when integrated into a Cloudfront distribution.

Wrapping up

What do you think of these AWS pre:Invent 2024 security announcements? Do you have some other favourites? Have AWS saved some good stuff for the main event that is re:Invent? Share you thoughts with us on LinkedIn

If you want to know more about these and other announcements from AWS, contact us at RedBear!

Close Menu