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.
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.
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
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.
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.
Skip the “sandbox” constructs and save yourself a world of hassle.
Shamir is a Microsoft Most Valuable Professional (MVP – Azure) and has extensive experience building solutions in the cloud, from strategy to deployment to automation