AWS has created a new sign up experience which they've described a bit in their blog post "AWS reimagines the getting started experience", along with new documentation, and a scattering of recently announced features that were used for it. I explored this new Sign Up experience and looked into how it works. The new experience creates an account in a restricted sandbox, but it has some interesting differences when compared to something like Control Tower. This post will explore what this new concept does, how it works with the new Account Access capability, and why a strong security posture still requires upgrading out of the sandbox.
Account creationWhen you sign up to create an AWS account (now referred to as a Project in AWS's blog post), the new experience will create three AWS accounts that are part of an AWS Organization. They give you access to one of the member accounts while hiding the Org management account and the other member account. You do not have access to the Organization management account, but AWS uses that account to apply SCPs and RCPs to your sandboxed account. The other account that you do not have access to is an Identity account.
AWS is largely using existing capabilities they already had, or added recently, but sets all this up behind the scenes. While you are in the sandbox you won't have much visibility into what was set up, but once you upgrade, you will be given access to the Org management account. From there, I was able to look at the artifacts of what had been done, and could review the CloudTrail Event History.
The expectation is that people new to AWS will be able to try out AWS within the sandboxed environment, and then once they start bumping into the restrictions of the sandbox (budget controls, restrictions on services they can use, etc.) they can upgrade their account in order to break out of the sandbox by being given access to the Org management account.
Security configurationMy initial assumption about the new Sign Up experience was that it was going to be like Control Tower where all the security features are enabled. I was surprised to find this was not the case and the goals were different. There is no CloudTrail configured, at the account or Org level. CloudTrail Event History is still there though, which is a way to see 90 days of events, but through limited interface. S3 Public Block Access is not enabled at the account level, but is default enabled at the bucket level when you create new buckets.
The biggest difference from Control Tower is many of the AWS security services are not even allowed! The sandbox denies access to GuardDuty, SecurityHub, Detective, Inspector, Macie, and Access Analyzer (even the free features). AWS Config and CloudTrail are allowed though.
I was interested in what types of security best practices I could violate.
I was able to make an IAM user with an access key, although there are warnings about this. I was prevented from setting up a password for the IAM user in order to do a console sign-in with it.
I could make a public S3 bucket, although I did need to turn off the bucket-level S3 Public Block Access.
I could launch an EC2 with IMDSv1, although I did need to change the default from IMDSv2 only.
AWS does a great job of warning against these historical features that are known cloud security concerns, but given that I was not prevented entirely from using them, while I was prevented from enabling AWS's own security services, I realized that this is focused on a different goal than I assumed. The sandbox is focused on providing a simplified experience and limiting costs. These are also good goals, and there are some things it does which have nice security benefits, but I'll discuss in a bit how this can conflict with my own goals of maximizing security.
BudgetsWhile in the sandbox, AWS creates a Budget of $20/month which has an associated action to apply the SCP BudgetsSpendLimitDenyNewWorkloads if the Budget will be breached. This SCP denies over one hundred actions associated mostly with denying the creation of compute resources (such as EC2s), but a lot of other things as well. Once the account is upgraded out of the sandbox, this Budget is removed.
SCPsThe sandbox has a couple of SCPs that are applied to it. Three of these are documented in the AWS docs here. One is removed once you upgrade the account, and simply protects some of the contact information for the account and other settings that are controlled by the new settings.aws.com experience. One that remains after the upgrade is ManagedAccountSecurityControlPolicy
which prevents the account from leaving the org, and protects the IAM role AWSManagedAccountManagementAccessRole
. The more interesting SCP that remains is AdvancedModeRegionRestrictionSecurityControlPolicy
which applies region restrictions to services to keep the user in a single AWS region.
While you are in the sandbox you additionally have "FreeTierSCP" applied which restricts a number of services. This uses a Deny with a NotAction
which results in being an allowlist of approved services, and is therefore what blocks GuardDuty and other security services from being used. It will be interesting to see how AWS handles new services they launch, because they will be denied by the allowlist strategy. It also has Denies on some specific actions, such as denying s3:PutObject
with the Glacier storage class, or denying various capacity reservations.
RCPsA single RCP is used which is shown in the docs here. This is a simplified version of a data perimeter. It blocks all Principals from outside the Org from accessing any of the RCP protected resources. This has a troublesome side effect of denying an sts:AssumeRole
from any other account, which means that no vendors that use IAM role access can be used until the user upgrades their account and then modifies the RCP. I worry that this hurdle could encourage some vendors to revert back to using IAM User access keys as a way of gaining access to AWS environments.
Account AccessWhen you sign up with this new experience, you generate a Builder ID instead of a root email and password. This login flow sends a verification code to your email for every login, resulting in a form of two-factor authentication being used by default. Historically, when you created an AWS account you started out as the root user, and it was hoped that you would then set up a different identity and access solution. Now, you cannot even get access to a root user until you upgrade your account. The user you create and anyone else you invite to the account will have admin privileges, but this is better than a root user where it is common to share credentials and where incident response is complicated if any incidents do occur with a root user.
Access to the account is done with the new Account Access service. The sandbox account will have an IAM role AccountFullAccessRole
that has a trust policy for the service account-access.amazonaws.com
. From the sandbox account, you do not have API visibility into who has access to the account, and instead have to use a web browser to look at settings.aws.com.
Once you upgrade, you must use the Org management account in order to get visibility into the Account Access service.
IAM Role ManagerThe new experience enables IAM Role Manager, which was a new feature announced last month. That feature causes IAM roles to be created with the PowerUserAccess
policy attached to them, when AWS creates these roles on your behalf, such as when clicking around in the web console. That policy is nearly equivalent to an admin policy, which means you will need to retroactively reduce privileges later, instead of using a strategy of starting with least privileges.
ConclusionThe new AWS sign up experience is a big change for AWS, but still relies on many of the features we're familiar with. The focus is on ensuring new AWS users can try out the cloud service without having to worry about unexpected credit card charges. In doing this, there are some security improvements they have made, but also some security challenges. For those people focused on security, they will need to upgrade their account out of the sandbox in order to implement a complete security strategy.