AWS Best Practice: Sandbox Accounts Provide Secure Middle Ground

At Flux7, we often work with organizations whose teams are interested in playing with AWS as a way to help them determine where to start with their AWS adoption. While their end goal is to introduce DevOps concepts like infrastructure as code, their initial goal is to enable development teams to start using AWS in a meaningful, quick, and secure manner.


A common solution is to provide these enthusiastic Development teams with their own sandbox AWS account where they can experiment freely. Historically, the recommendation has been that the sandbox is a complete island, i.e., it is not connected to internal networks or AWS. Thus, it is neither managed nor governed. The underlying assumption is that developers will not use any corporate data in this account. The reality is often different.

If your organization is concerned about security, and your team is worried about making fast progress, you may find our paper: Effectively Balancing DevOps and Security useful. 

We are learning from developers that even experimenting in a sandbox is not productive unless they have sample data to work with. While, in an ideal world, they will take the time to cleanse the data and copy it into the sandbox, they often end up copying the data to their sandbox without cleansing (with all good intentions to delete it immediately after). If the data is then left there, it presents a very serious security issue leading to data leaks. (And, in fact, we’ve seen this issue hit the headlines lately as we’ve read about several organizations who spun up misconfigured data buckets in AWS S3.)

Rather than building completely isolated sandboxes, we are increasingly taking an approach where we build what we call a “governed” sandbox. Such a sandbox takes the middle ground between a fully managed, governed environment and a completely isolated, unmanaged, and ungoverned environment. In this blog, we’ll share the story of how we used this approach with one customer to provide agility with security.

What’s a Sandbox?

For those of you unfamiliar with the term, sandboxes have traditionally referred to a way to separate running programs from one another. Sandboxes have been used to keep system failures or software vulnerabilities from spreading across systems and, as we refer to them today, are also used to run untested programs or code.

As discussed before, no corporate IP or data should be used in a sandbox. Yet, in practice, this rule is very difficult to enforce, which can lead to data leaks. This creates the need for governed sandboxes. In the governed sandbox middle ground, Dev teams are allowed to access low profile corporate assets in exchange for constraints, like security. Such constraints are enforced via AWS Service Catalog.  

The Use Case

Our customer, who is a B2B advisory service provider, had two important goals.

1. It’s IT team wanted to allow developers from the company’s business units to cultivate ideas about how AWS could help their efforts by giving them a space to explore the platform. All without creating barriers to entry for the team, e.g. requiring them to learn how to work with infrastructure as code, templates, and more.
2. While imposing security standards to ensure that this space didn’t become the proverbial Wild West where mistakes were made that could lead to the company becoming the next data leak headline.

The client agreed that a lower-tier sandbox account for the business unit dev teams would meet its requirements. Further, the client clearly saw the downside to a Wild West approach and so to avoid insecure environments being launched, we recommended building a service catalog.

AWS Service Catalog allowed us to create sandbox environments (that could be deployed by the team with the push of a button) that were configured to meet the company’s security and best practice standards. With the service catalog, the team can quickly and easily provision a new sandbox environment and just as quickly try something out in it.

While this client didn’t know which applications they wanted to replatform, they began by kickstarting their efforts with EC2 Linux instances. We created a golden Linux image that imposed this client’s operational and security standards and restricted permissions so that users could only provision and update instances with this Golden image. The network security of the instance was restricted by setting minimalistic security groups that opened only common ports like 80, 8080, and 443 to just the corporate network. And, when someone creates an instance, they are required to do so with their email address, which is used as a tag so that the person can be followed up with about the instance if needed.

Last, the sandboxes were configured such that they would only deploy to specific regions, VPCs, and subnets to enforce that there was no accidental data leakage. Over time, other AWS services were added to the Service Catalog to make it complete but each service offered via the Service Catalog was restricted to secure settings, e.g., Lambda functions run only in the private subnets of the VPC, or S3 buckets do not allow all-open access.

An interesting note: At Flux7, we use sandboxes for very similar purposes. For example, we might quickly provision a sandbox environment to test something for a client. This approach allows us to quickly test a theory and prove its viability. This option keeps our projects secure, agile and fuels innovation.

The Benefits

Governed sandboxes increase agility and shorten the feedback cycle. Specifically, when building a new AWS environment, we often think about Development, Test and Production as three different areas with different requirements. As a result, we then begin to linearly create these environments, working from hardening to config rules and more for each. However, with a governed sandbox approach, we can let others in the organization begin playing with the new environment, obtaining their feedback right away — all with certain corporate restrictions applied that keep the company’s IP secure and its name out of the headlines. Governed sandboxes shorten the feedback process as earlier feedback results in fewer changes at the end of the project and we eliminate the need to make a change across three environments.

In addition, this sandbox approach makes it easy for teams to play with AWS, helping avoid Shadow IT. For, we’ve found that when the barrier to entry to play with AWS is too high, teams will venture out on their own, opening the door to misconfiguration and other potentially serious errors that are often at the root of AWS data leaks.

While this approach is newly enabled by AWS, at Flux7 we think that sandboxes will increasingly become an AWS best practice for organizations who want to be able to meaningfully, quickly, and securely play with AWS as a way to help them determine where to start with their AWS DevOps adoption. Interested in learning more about getting started with AWS DevOps? Here are several great resources:

• A Primer: What is DevOps? And how do Code, Config, CI/CD & Containers Relate
• The Flux7 Enterprise DevOps Framework, a model for marrying DevOps process improvement with digital transformation.
• Seven Steps to Successful and Sustainable DevOps Transformation
• The Socratic Approach: Why We Start DevOps Projects With “Why?”.
• Why We Teach Our Customers How to Fish

Resources

Read more about how sandboxes can be an enabling strategy for cloud migration in our whitepaper “Strategies for Large-Scale Cloud Migrations“