Sensitive is a relative term. You do development, you install a private key on the VM, you grant that key access to your system in order to test new integration prototype, you delete the VM before you disable the key - and voila, you got private key with access to your systems in a hands of a random stranger. Of course, the solution would be to disable the key access first - but how many devs are trained in security procedures to this level? How many can follow them flawlessly over repeated tedious cycles of development and resist the temptation of make shortcuts?
Proper procedures should make it easy for people to do security, otherwise they are part of the problem.
"Proper procedures should make it easy for people to do security, otherwise they are part of the problem."
Correct. And leaving the proper procedure in other people's hands is the problem. The best procedure [in testing a new intergration prototype] would be to create a new special test key and properly track and maintain that it is only enabled during the known testing time frame and then properly "disposing"/"revoking" it in the system YOU control. We can argue all day that DO should scrub the data by default and prevent new instances from low level access... however security relies on trust. So, do you TRUST (and KNOW) that checking the "scrub data" check box actually works and does what it says it does? If it doesn't, its beyond your control. And if you care about proper procedures and security you either a) don't use systems/servers beyond your control (if you are that concerned...) and/or b) rely on proper procedures and things you can and do control. I don't know what happens in DOs infrastructure... maybe there is some other leak I'm unaware of so to limit any damage for testing I will properly create and control short lived test keys.
