So I have been incentivised to put some thought and research into the various models available for providing platforms for developers in a secure manner, and this is a short summary of what I came out with...
Basically 3 ways to try and mitigate the dangers of un fettered creativity, without putting too much of a sysadmin damper on the use of fucking stupid configurations and settings.
Development environment as a peer with Production and Test
In this scenario the development platform is principally the same as test and production and developers have access to parallel systems which share many of the same features as the live test and production, this might include databases or hardware.
This is a locked down mode and typically a highly controlled environment, and requires that any new software for developers is requested from the sysadmins, and that you may even decide to not give the developers root access.
This is generally the choice when the development platform is not easily replicable in a limited fashion, ie some expensive system needs to be shared, or that the target platform is actually intrinsically very restricted.
Pros: security good
Cons: high maintenance
Development environment as sandbox, or "developers playground"
In this scenario, you create a sandbox and some basic rules and let the developers go nuts.
The basic rules are that they shouldn't use live customer data, and that they shouldn't copy over user accounts and passwords that are the same as production/test, so that when they inevitably get hacked or something breaks, that these systems are considered disposable.
This network is usually protected by a VPN, or some other logical barrier to the public internet and is could be retroactively monitored with something like a network-based IDS.
This is considered a kind of light touch approach, but its important to have the VPN and rules in place up front otherwise its all the bad side and none of the good side ;-)
Pros: low maintenance, flexible
Cons: upfront effort to configure VPN
Development environment as tiny replicas of production/test
Basically in this model, you take advantage of virtualization and/or configuration tools to provide each developer with a mini-me version of your target platform in a downloadable guest image.
The developers then have a local development sandbox which they can run in a vhost like virtualbox - https://www.virtualbox.org/ or vmware workstation depending on what they choose.
Rather than develop a custom guest image, you actually use a really basic guest, and then leverage your production/test configuration management tools to generate on-the-fly the installation to make it match your prod/test platform.
Pros: in principle secure
Cons: quite a new concept
no control over the ultimate destination of your sandbox copies.
dependent on centralized infrastructure
No comments:
Post a Comment
Don't be nasty. Being rude is fine.