Disclaimer: infrastructure secrets management is my profession.<p>This is a lot harder problem than people realize.<p>If you have a fixed set of machines that need secrets, then encrypting a bag of secrets with each machine's private key works ok.<p>But in auto scaling / automated / ephemeral scenarios, it doesn't work. You need an RBAC scheme for machines that builds layers of trust; each machine is placed into a role by a trusted service, script or person. Communication between the machines and the secrets service is verified TLS. Each event of access to, or modification of, a secret is recorded for audit purposes. And people and machines should both be treated as first-class actors.<p>Furthermore, secrets should be kept off permanent media; per the 12factor guidelines, secrets should come from environment variables.<p>Don't entangle secrets management with other tools like configuration management; otherwise you impede yourself from switching architectures down the road.<p>Don't create workflows that only ops can control, leaving developers out in the cold, or you are increasing organizational friction.<p>And if your secrets management processes are opaque to security and compliance people, then they won't have the same level of trust that they would have in a transparent system.<p>Here's an example of how we approach the problem: <a href="http://blog.conjur.net/chef-cookbook-uploads-with-conjur" rel="nofollow">http://blog.conjur.net/chef-cookbook-uploads-with-conjur</a>
Storing secrets is fundamentally imperfect ("it's not a secret if someone [or something] else knows it"). This article calls for aid in the form of standards other than PCI-DSS, and those standards do actually exist. NIST 800-53 and 800-130 to name a couple; the EU has others in different industry flavors.<p>Now, I'm not going to defend these govt. standards as up-to-date or comprehensive. But they're a good philosophical reference for how to manage keys/secrets. Some COTS technologies (which I won't advertise here) try to automate/enforce strong key management for infra, but are typically only affordable for enterprise deployments.
The attack vectors that surprised me but should not have:<p>- MongoHQ support person has access to data in customer database.<p>- CircleCI stores <i>everything</i> in the MongoHQ database, that is used to deploy/control customer servers.<p>- CircleCI's Customers' CircleCI controlled environments mixed with production environments.<p>I am guessing everyone just expects most companies, especially those with maybe just Series A financing or close to it, expects those companies to employ this level of security paranoia?
The link to the MongoHQ page about their compromise is giving a cert expired error (1 day ago), which then redirects to a page not found on compose.io. Odd.