Treat Your Development Environments (almost) Like Production
The stakes are higher than you think!
I recently came across a tweet sharing a very strong opinion about the separation of “cloud” accounts to isolate environments. The subject has been highly debated over the years and while there is no “one size fits all” solution, there is a widespread consensus on the advantages of separated accounts. It often makes security and cost control easier to deal with and these are sound reasons to opt for the multiple accounts solution. The worst of them all, instead, is: “so I can hand the dev account over to the development team”.
I am a developer myself and worked several “developer” jobs before taking the path of the cloud. I still write a lot of code. So I am not here to bash developers like a cranky old sysadmin. Yet, I think there are some considerations worth making and sharing about this.
Foreword: Security is made of many building blocks
Application security is not network security or systems security. Your most experienced developers might have a very good understanding of all of those, but don’t take it for granted. Also, if you are working in a medium or big sized company, chances are that you don’t only have seniores* aboard. If you are wondering why this matters to development environments, keep reading.
* “senior” is a Latin word, so please allow me to use its correct plural form ;)
Development environments hold precious assets
Yes, you don’t have real users or customers on dev, so who cares if it breaks from time to time? Well, any malicious competitor or hacker might very well care about the code and the configurations you put into your development environment. Information about your software products and services (especially the upcoming ones) might be worth a lot on the corporate espionage market, or be used to learn how to target your production systems. Ensure your development environments are secured, too. Don’t leave “soft targets” around.
You should be part of the design process
One thing I love about modern cloud platforms is the quick prototyping opportunities they offer. It’s really helpful in the design process. Keeping up with change requests from your developers while they try new things and test them might be highly demanding at times, but it also gives you the chance to promptly address any concern you might have about the security design or operating costs of the whole solution. Stepping early into the design and development process and becoming an active part of it might save everybody’s time and a few headaches later on.
Mind the data stored in the development (and test) environments
The data used for application development and testing purpose should always be fake data, randomly generated for the purpose, but that is not always the case. Especially when people need to test systems under their most realistic working conditions, they might copy data from production environments to the test environments. Such data MUST, of course, get anonymized in the process, but a significant number of data leaks occurred and even big companies that are supposed to enforce strict security practices were involved. Also, people might inadvertently post confidential company files to a development system to test its functionality. So taking good care of the development and test environments can act as a “failsafe” to prevent such incidents.
