Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How does your company manage its encryption keys?

news.ycombinator.com

Post reply on HN
Print view View original

131–140 of 246 posts

Re: Ask HN: How does your company manage its encryption keys?

#131

Post by closeparen »

mmm_grayons wrote: post #114
varikin wrote: post #101

Earlier quoted context omitted.

This just pushed the problem further down the stack. You should have keys to unlock vault when it is restarted. How do you secure those keys?

I can't seem to understand how a "secrets manager" helps things. Could someone who does ELI5 why it's better than a config file with permissions locked down?

In a monolithic application they're pretty close. In a microservices architecture, suppose you have 100 services and schedule 6 service containers per host. That is 94 services worth of secrets that don't need to be there, expanding the blast radius of single host compromise. There may be a credential on that host that can be exchanged for more secrets, but audit logs can tell you whether it actually was, and you can revoke it.

Secrets may still need to go to config files for third party stuff, but you can write your in-house applications to fetch secrets at runtime and hold them only in memory. That's less opportunity for compromise vs. both memory and disk. Also have heard that Linux's process address space isolation is less prone to vulnerabilities than user account separation or filesystem permissions. Not really sure how true that is.

Re: Ask HN: How does your company manage its encryption keys?

#132

Post by hellcow »

ahnick wrote: post #124
hellcow wrote: post #82

We use shh for secrets ( https://egt.run/shh ). It's designed to integrate really well with your existing CLI tools like vim, xargs, and diff. It offers user-based permissions, and secrets are encrypted into a single file that's safe to commit into your git repo. We can stream secrets out of it directly to our remote servers during deploys. Unlike Vault you don't need to manage infra to run it -- it's just a file. Un…

A couple of questions.. 1. Does every client have a copy of shh to interact with the secrets? Or are the secrets in the file served from a single centralized node? 2. What is your process of exchanging user keys with shh? 3. If someone leaves the company, what is the process you go through to change the secrets and rotate keys?

1. Every client (i.e. developer) has their own copy of shh but interacts with a shared .shh file in the project root. Secrets can be decrypted locally in memory then streamed to the remote servers over ssh. You could in theory run this on a server to help address your third point.

2. Exchanging public user keys is done via email when an employee starts, then added to the .shh file and committed in the repo.

3. You'd need to write a script for this, which probably involves `shh rm-user {email}`. There is no silver bullet here for changing secrets; since developers have access to secrets, any secret they had would need to be regenerated. `shh` makes no assumptions about how you deploy, what secrets you keep, or their formats.

Re: Ask HN: How does your company manage its encryption keys?

#134

Post by jwr »

rrdharan wrote: post #80
jwr wrote: post #51

Here's what works for small and medium organizations for data which needs to be encrypted at rest, but is not often accessed (so, backups): 1. Buy a bunch of Yubikeys, minimum of 2. 2. Create GPG keys and store them on YubiKeys. Follow this guide: https://github.com/drduh/YubiKey-Guide (if you want to, keep the secret keys, but in case of multiple YubiKeys I would not keep them anywhere). Remember to set the keys to…

This is all generally good advice, but I think there's huge potential complexity lurking here: > 4. Take care of the physical keys with proper storage and procedures. Do not store the keys together, have at least one in a really secure location, check if you have all the keys regularly, etc. Would be great to see what folks think this concretely looks like for joe random startup in Capital City, Somewhere. e.g. Does…

This depends on your company size and security requirements. I'd say use common sense for small companies, where the idea is mostly not to lose access to all of your decryption keys at once. As the company grows and you need to worry about trusting people, you are solving two problems: having an always-available fallback decryption key (that's the easy part, and indeed deposit boxes work just fine, but so does your parent's home in many cases :)), and restricting access to keys to those people who need it. The second problem is more difficult to solve.

My main point was that the use of hardware keys makes many things much easier, and you do not have to worry about your keys being copied and used without your knowledge. That's a big thing. Also, the often-ridiculed GnuPG is amazingly useful with Yubikeys (using the setup I linked to), because you can use the same keys for SSH, thus ensuring access to all resources as needed.

Re: Ask HN: How does your company manage its encryption keys?

#135

Post by jwr »

pas wrote: post #108
jwr wrote: post #51

Here's what works for small and medium organizations for data which needs to be encrypted at rest, but is not often accessed (so, backups): 1. Buy a bunch of Yubikeys, minimum of 2. 2. Create GPG keys and store them on YubiKeys. Follow this guide: https://github.com/drduh/YubiKey-Guide (if you want to, keep the secret keys, but in case of multiple YubiKeys I would not keep them anywhere). Remember to set the keys to…

GPG alternative: https://docs.sequoia-pgp.org/sq/#subcommand-encrypt https://sequoia-pgp.org/status/ is coming along nicely ( https://sequoia-pgp.org/blog/2020/04/26/202004-towards-sequo... )

I'm very glad it's being developed, but it is in no way a GnuPG alternative.

GnuPG is a command-line tool that is omnipresent, keys can be stored on Yubikeys, can be used with ssh-agent, and I can use it to encrypt files in an automated fashion, using both symmetric and asymmetric crypto.

Re: Ask HN: How does your company manage its encryption keys?

#136

Post by lux »

ecesena wrote: post #113

We use Knox: http://github.com/pinterest/knox Think of a lighter vault, with ACLs for people and/or machines to access keys and versioning to rotate keys. In our case, Knox depends upon AWS KMS to "lock/unlock" its storage.

This looks way easier than getting Vault setup! Unfortunately, googling for it returns a ton of info about Apache Knox which is an unfortunate name clash. I would love to see this catch on. Thanks for the share!

Re: Ask HN: How does your company manage its encryption keys?

#137

Post by scott00 »

bvandewalle wrote: post #119
mmm_grayons wrote: post #114

Earlier quoted context omitted.

I can't seem to understand how a "secrets manager" helps things. Could someone who does ELI5 why it's better than a config file with permissions locked down?

It makes sense at scale. If you are a company of two there are probably better solutions. At scale, you can very granularly define policies for each secret. When a secret is accessed, it is done so through a user or application identity. Each access is also logged.

So then how do you manage the secret that authenticates an application's identity? And what good is the logging if after an application has the secret it can do whatever it wants with it?

Re: Ask HN: How does your company manage its encryption keys?

#138

Post by jacobsenscott »

opticalfiber wrote: post #59
hn_throwaway_99 wrote: post #42

I highly second the people saying KMS (AWS KMS, Google KMS, or KeyVault). * The pricing for just storing keys is incredibly cheap. * At least with Google KMS you can't delete the keys without a 24 hour waiting period (and you can alert on the deletion attempt), so that's a huge safeguard. * You get key access auditing out of the box.

AWS KMS also enforces a waiting period of between 7 and 30 days before it will let you delete a key. There’s also a feature you can enable that automatically rotates your key once a year. KMS is great!

Given the keys never leave the KMS hardware encryption module, are you at all concerned that all your data will be destroyed if you lose access to KMS for any reason? That's what has always given me pause when I consider KMS. Or do KMS users just take on faith that AWS will always be there?

Why do you like their auto-rotation? The keys that are rotated out are not never disabled, so I don't really understand the benefit. In what scenario would their auto-rotation improve security?

Post reply on HN