Sandbox environments enable you to isolate code executions, for testing purposes, trapping malware and threat actors, or for pre-migration preparations. Implementing these actions in isolation can help keep your production systems and networks safe from bugs and vulnerabilities. 

Basic AWS sandbox accounts typically include components of EC2 and S3 storage. To ensure the security of your account, you need to define IAM policies and create a permissions boundary that blocks certain functions. This article walks you through the process of creating and configuring an AWS sandbox, and explains key best practices you should implement.

In this article, you will learn:

• What is a sandbox environment
• Creating AWS sandbox accounts
• Sandbox security considerations
• Best practices for AWS sandboxes

What Is a Sandbox Environment?

Sandboxes are environments you can use to execute programs or code in isolation. These environments may also be referred to as test or development servers or working directories. You can use sandboxes to develop application features, test for and identify bugs, isolate malware or other security threats, test patches, or before going live with lift and shift applications. 

The benefit of a sandbox is that it creates an environment that is disconnected from your primary environment. This enables you to evaluate processes and programs without fear of impacting your primary environment. It also enables you to strictly control your test conditions, preventing system processes or other applications from interfering with your results.

Why Would You Want An AWS Sandbox

Now that you understand what a sandbox environment is, you can see how working with an AWS environment can be beneficial. Creating a sandbox environment in AWS can be a useful way to test new configurations, train users, or evaluate new services. The benefit of an AWS sandbox account is that it is separate from your organizational account. This prevents you from incurring excess expenses and prevents unintentional exposure of your production systems. 

How to Create a Sandbox Account on AWS

Basics

When creating a sandbox account in AWS, you first need to define your user roles—an Owner and a SandboxUser. The owner role is responsible for managing the creation of the sandbox and setting up the permissions given to the user. Once permissions are granted, the user can use the sandbox to experiment in AWS. 

The components of your AWS sandbox environment should include basic configurations of EC2, S3 storage volumes, and the IAM roles covered above. 

EC2 configuration

When setting up your EC2 configuration you need to create a virtual private cloud (VPC). This VPC should be managed by a security policy that only allows inbound access from your trusted IP addresses. This ensures that external users cannot access your AWS sandbox. 

After this is set up, your user should be able to access any EC2 instances, Lambda functions, or other services included in the security group. 

AWS SandboxUser permissions boundary

When setting up your permissions for your user, you need to create an IAM permissions boundary. This boundary should block the following functions: 

• Modification of security group rules—prevents the user from easing security group rules or creating an insecure group. 
• Modification of password policies—ensures that passwords maintain security standards.
• Modification of S3 block access—prevents the creation of public S3 buckets. 
• Use of Elasticsearch API functions—it is not currently possible to prevent users from creating public Elasticsearch instances so you need to deny all access.
• Removal of IAM permissions boundaries—prevents the user from removing their own restrictions or creating users without restrictions. 
• Modification of the Owner—prevents the user from disabling or limiting the permissions of the owner role.
• Modification of the SandboxUser—prevents the user from escalating their own privileges.
• Creation of IAM users or roles without permissions boundaries—prevents the user from creating roles with admin privileges. 

Sandbox Security Considerations

To be useful, sandboxes need to grant your users freedom to perform most actions. However, this also makes sandbox user accounts incredibly valuable to attackers and can present a serious security concern. Although your sandbox is separate from your production environment, it can still be used to access a variety of resources. In the wrong hands, these resources can be abused leaving you with a large bill and liable for damages.

To prevent security breaches from occurring, there are some additional security considerations you should keep in mind. These include:

• Enforce strong passwords and multi-factor authentication for any users or applications in the sandbox.
• Do not store credentials or secrets in your source code.
• Do not share credentials via mobile devices, Internet connections, or uncontrolled clients.
• Restrict Internet facing endpoints

Best Practices for AWS Sandbox Accounts

When creating your AWS sandboxes, you want to give your users as much freedom as possible while still protecting your resources and budget. The following best practices can help you ensure that your sandboxes provide the greatest value with the greatest cost savings and the least risk. 

Use sandbox accounts flexibly

Sandbox accounts are used for a wide range of purposes by many different teams and users. Due to this, if you try to use the same AWS sandbox account for multiple teams, user actions and configurations are likely to contradict each other. To avoid this, consider creating a sandbox for each team or multiple sandboxes that can be used as needed. 

When creating these sandbox accounts it can be helpful to name them something generic, like “devSandbox”. This makes it clear to users which sandbox they are in while discouraging the idea that configurations are permanent or tied to a single user. 

Related to this, when creating sandboxes you should not tie sandboxes to single users or emails. Instead, try to use group email addresses and create a generic admin user. This eliminates the chance that access is lost if your team members change. 

An easy way to do this is to use a plus sign in your sandbox account email when signing up. For example, if you use the email address “sandbox+dev@myorg.com” any mail sent will go to “sandbox@myorg.com” since the section after the plus is ignored by default.

Prevent changes to your organization access role

When you create a new AWS account, there are two ways to manage it. You can use root credentials or you can use the OrganizationAccountAccessRole that is created by default. When created, this role is automatically tied to the AdministratorAccess policy, granting admin privileges.

You should not change or delete this account and you need to make sure that sandbox users do not accidentally change it either. To prevent any changes, you can create a service control policy (SCP) and tie it to the organizational unit that contains your sandbox. To do this, you can use code like the following:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProtectOrgAccess",
      "Effect": "Deny",
      "Action": [
        "iam:DeleteRole",
        "iam:DeleteRolePolicy",
        "iam:DetachRolePolicy",
        "iam:UpdateRole"
      ],
      "Resource": [
        "arn:aws:iam::*:role/OrganizationAccountAccessRole"
      ]
    }
  ]
}

Limit the creation of instances

If you do not limit the type of instances that AWS sandbox users can create you may find that your costs expand quickly. In general, you should be able to limit your sandbox users to the creation of relatively small and cheap instances without having a significant impact on their capabilities. 

You can enforce these limitations with a service control policy that outlines exactly which instances are allowed and which aren’t. You can see an example policy below which limits the use of larger and more expensive instances. 

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireMicroInstanceType",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringNotLike": {
          "ec2:InstanceType": [
            "t2.*",
            "t3.*",
            "m5.large",
            "m5d.large"
          ]
        }
      }
    }
  ]
}

Limit your resource regions

Limiting the regions that users can create resources in helps ensure that low latency in workloads. It also reduces the chance that resources will be forgotten because they are not in the regions you typically monitor. 

Similar to how you can manage instance types and your organization access role, you can also manage your regions with AWS SCPs. Below is an example policy that restricts regions to US-East 1 and 2:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictRegion",
      "Effect": "Deny",
      "Action": "*",
      "Resource": [
        "*"
      ],
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-east-2"
          ]
        }
      }
    }
  ]
}

Conclusion

AWS sandboxes can help you test your systems and isolate threats. However, to be truly effective and secure, AWS sandboxes should be configured properly. For security, a critical aspect is defining an IAM permissions boundary that prevents users from gaining admin privileges or modifying owner role permissions. You should keep your organization access role secure by tying a SCP to an organizational unit. This can help prevent unauthorized changes to your role.

---