I spent six years in the USAF as a nuclear weapons tech. Somce then, I've not seen any civilian company handle security well, or even correctly.
Physical access to properties, building, departments, rooms, cabinets, all tissue-paper defended. Intimidation of rank being rampant. Guards with little to no training or authority. Employees not adequately screened or monitored. Typically all of the above.
If you're referring to a properly run CA, then they're a good model to follow. Some of them, obviously, do not implement proper operational security procedures, but a good many of them do. It's usually required in order to have your Root CA certificate added to the trust store of major browsers, OSes, etc. I was a senior engineer for one of the larger commercial CAs, and started off my career as an engineer for the world's largest gov't CA. Biometrics, HSMs (hardware security modules) for storing the keys, offline root CAs, documenting EVERYTHING, armed guards, etc. are the norm. The CA software platforms themselves are usually assessed for FIPS, Common Criteria, etc. compliance. And we were audited. All. The. Time. I can't speak to Let's Encrypt, but the bigger companies that make their money in the CA space are insanely serious about security.
> I can't speak to Let's Encrypt, but the bigger companies that make their money in the CA space are insanely serious about security.
That's really what I'm interested in, very high level security / operations standards. Not that I'm intending on running the CA myself but it's easier to understand daily trade offs knowing how it would be done if extremely high standards were absolutely necessary.
Unfortunately there is not much reading material online on this subject (I understand it may not be super interesting subject for most people) but reading the CPS really shed some light.
Note that I work for HashiCorp so I have a clear bias. I tend to shy away from these comments because of that but there is a certain addition I'd like to add here. The other comments around this are good so I won't talk about those.
The surface area of Vault capabilities is much larger than EC2 parameter store and through the lens of our paying customers, most are using Vault for many more of the backends (the most popular probably being PKI).
For pure AWS-based companies, parameter store could provide a fine solution for basic key/value secrets! I don't want to bash at all, I just wanted to make sure for any readers that they don't mistake Vault for purely encrypted K/V.
But, if you're using vault for only Secrets Management on AWS you are using a nuclear warhead to destroy an ant-hill.
It's quite frankly not a good experience and really challenging to automate running Vault in a modern environment, all something that is very simple with SSM.
You note this, but I have 2-3 people reaching out to me per week stuck/struggling with vault, who find chamber/SSM and have solved the problem with 1 day of work.
if you are not on Amazon, you are forced to use something other than Amazon's services.
Another would be vendor lock-in. If your code is tied to Amazon, you are then also tied to Amazon, without engineering resources to divorce.
Another reason is, if you are cross-cloud, and not tied to only Amazon.
Also @organsnyder's point in the other comment is also true.
But certainly, if you are married to Amazon, there is nothing wrong with staying married, if it's working out for you and using the EC2 parameter store w/ KMS.
Vault can also work under Amazon just fine, so you can use vault under Amazon, and avoid some of the above reasons.
Many organizations (especially large ones) are hesitant to outsource this function. There is certainly an argument to be made as to whether it's a wise stance, but it is the reality.
