No, your cloud environment doesn't need a sandbox

Many companies are still taking their first steps in adopting the public cloud for their business use cases. In the last several years, the major cloud providers have created cloud adoption frameworks that help companies make best practice decisions during their journey to the cloud. I’m fortunately (or unfortunately as the case may be) going through this process with both AWS and Azure, and one of the common components that both of these providers recommend is the concept of a “sandbox” construct within your organization. When pushed on why this was necessary, both teams said that this was the cloud best practice. Well, I’m here to tell you that you don’t actually need a “sandbox” environment.

What is a “sandbox” environment?

Before we dive too much deeper into why you don’t need one of these in your cloud deployment, let’s first talk about what a sandbox environment is. In Azure, this manifests as a management group and set of subscriptions labeled/named sandbox. In AWS, this is typically an organizational unit with a set of accounts also labeled sandbox.

Looking through both providers documentation, the following are the common reasons proposed for sandbox environments.

1. You will need an environment that is dedicated for testing and exploratory work done by an organization. The idea is that in this environment you will remove most (or all) of your security controls to facilitate innovation.
2. This environment will necessarily be in control of “users” (in this case, developers I guess?) and those users will need administrative access to be able to innovate properly
3. Sandbox environments are disconnected from corporate resources (such as code repositories, data, and security)
4. Sandbox environments need direct access to the internet to provide the freedom required for innovation

Why could a “sandbox” environment be bad for business?

If you’ve been in the security industry for any length of time, you likely see where I am going to take this argument. Sandbox environments are effectively uncontrolled environments where users have the run of the town. This can be bad for business.

Firstly, the assumption that sandbox environments don’t have access to production data is a very very (dare I say very a third time?) weak assumption. In order for users to experiment and innovate, they likely need access to something “real-world” to test out their assumptions. If you follow the cloud provider best practices and reduce your security controls in this environment, you also likely don’t have any monitoring in place to ensure that this assumption holds true. What is stopping a user from uploading production data to a storage account in a sandbox environment, thus invalidating this assumption?

Secondly, there are many ways to damage an organization (from a security perspective). Access to corporate resources/data and leaking that is one way, but there are also ways to cause reputational or financial damage that don’t require said access. Having sandboxes with unrestricted access to the internet still leaves organizations open to a multitude of negative outcomes.

Thirdly, administration should be left up to administrators. Cloud platforms are extremely powerful, and you need a fair amount of experience/training to use it properly. Leaving “sandbox” locations up to users (trained or untrained frankly) is a recipe for disaster. You want your users to be able to work, but guardrails/policies/security/etc should be setup to ensure that they don’t make mistakes.

Lastly, cloud providers pushing “sandbox” constructs seem to make the distinction that innovation cannot occur securely and should be done outside of the normal process. Security, especially with tooling that the cloud providers provide, can use/adopt policy-as-code constructs that allow them to move just as fast as users when understanding and provisioning new services

What should you do instead?

I think that sandbox environments arrive out of a very arcane notion within IT, the notion that there are different environments such as development, test, and production. Traditional IT believes that by simply calling something development it makes it so. The fact of the matter is that prod/test/dev constructs don’t make much sense in the new world. They are emergent properties of how the system is used, as opposed to a label we can simply declare at the outset.

Don’t believe me? How many times have you run into “test” environments that have access to production data? Well, is that environment still a test system in your mind, or is that now production? How many times have you had a report/system/process developed in the “test” environment magically become critical to the business?

So, what are the alternatives? Personally, rather than adopting a dev/test/prod approach (and applying different policy in different environments), workloads should be broken out separately. While it is true that within those workload constructs you may have concepts of dev/test/prod, the same policy from a security perspective should apply across all deployments of the workload.

But Mr. Security guy, how will we innovate?

Easy! While the same policy should generally be applied to all “environments” for a given workload, you should have the ability to change policy on certain deployments to facilitate additional use cases. What this allows for is controlled innovation. Not only does this directly involve your security/operations teams, it allows for your policy and controls to evolve as the application does. This security-first type approach helps companies maintain a strong security posture while allowing for required growth and change within the organization.

Effectively:

1. Create fit-for-purpose policy that is applied generically at the workload level ensuring that all environments for a workload are governed in a consistent manner
2. Allow for the evolution of policy as it applies to a single environment
3. Implement controls via automation (policy-as-code) so that security controls can move quickly to meet user needs
4. Have users plan/design (maybe even architect?) the solution prior to just ramming things into a cloud environment. A small amount of design can go a long way to ensuring it is done securely

Conclusion

Skip the “sandbox” constructs and save yourself a world of hassle.

 

About Shamir Charania

Share This Article

Comments