管理加密密钥的好方法？
管理与特定源代码关联的加密密钥的规范方法是什么？ （例如，与特定程序密切相关的 SSH 或 RSA 密钥对）。
出于明显的原因，我不愿意将其检查到版本控制中，但我也不希望它们仅驻留在少数人的本地硬盘驱动器上。
What's the canonical way to manage cryptographic keys associated with particular source code? (e.g. SSH or RSA key pairs strongly associated with a particular program).
I am reluctant to check this into version control for obvious reasons, but I don't want them to reside only on few people's local hard drives either.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可以将它们加密放入版本控制中，并且只让少数人知道密码。这样做的优点是它们与代码一起存储，并且您可以轻松更新它们，但这些文件对攻击者来说毫无用处（前提是您使用强密码）。
You could put them into version control encrypted, and let only a few people know the password. This has the advantage that they are stored along with the code and that you can update them easily, but the files are useless to an attacker (providing you use a strong password).
工业强度的答案是使用硬件安全模块 (HSM)。
稍微不那么花哨的答案是在公司安全地保存印刷版和/或电子版。
The industrial-strength answer is to use a Hardware Security Module (HSM).
The slightly less fancy answer is to keep a printed and/or electronic copy in the company safe.
非常好的问题，在我看来没有绝对正确的答案。
要问自己的问题：
1) 密钥被知晓会产生什么影响
2) 公司的信任程度如何
3）对于工程师来说，能够生成发布版本有多重要
我多年来使用的想法包括：
存储在源代码控制存储库中，但限制“secure_group”访问
优点
scm admins
缺点
具有安全权限
由构建系统注入的密钥
标准版本包含虚拟密钥。
发布版本由构建服务器生成，该服务器替换或注入生产密钥
优点
建筑规范
仅限于构建服务器 + 管理员
缺点
- 所有数据/系统必须支持虚拟密钥
- 构建服务器成为瓶颈/关键任务组件
自定义 DRM 包
创建您自己的密钥包，即使用会话生成的对称密钥的 RSA 加密标头来加密密钥数据。 DRM 方法还允许您执行诸如设置包过期时间或最大使用次数之类的操作
优点
安全地分发
按需使用公钥/私钥对
缺点
- 很多自定义代码
- 所有构建系统都需要重新设计才能读取关键包数据
- 密钥包需要 lib/API 来提取，因此工程师仍然可以读取密钥数据
还有其他选项，例如安全加密服务器或二次验证网站来检索密钥数据。
根据我的经验，没有完美的解决方案，尽管我非常有兴趣听取社区的建议或意见
希望有所帮助
Very good question and there's no absolute right answer IMO.
Questions to ask yourself:
1) What's the impact of a key becoming known
2) What is the trust level in the company
3) How important is it for engineers to be able to produce release builds
Ideas I have used over the years include:
Stored in source control repository but with restricted 'secure_group' access
Pros
scm admins
Cons
with secure permissions
Keys injected by build system
Standard build contains dummy key(s).
Release builds are generated by build server which replaces or injects production keys
Pros
building code
restricted to build server + admins
Cons
- All data/systems must support dummy key
- Build server becomes bottleneck/mission critical component
Custom DRM package
Create your own key package i.e. RSA encrypted header with session generated symmetric key to encrypt key data. DRM approach also allows you to do stuff like set package expiry time or maximum number of uses
Pros
be safely distributed
on demand with pub/private key pair
Cons
- A lot of custom code
- All build systems need to be re-engineered to read key package data
- Key Package needs lib/API to extract and so engineer can still read key data
There are other options such as secure encryption server or two-pass authentication web sites to retrieve key data.
In my experience there is no perfect solution though I'd be very interested in hearing suggestions or opinions from the community
Hope that helps
当我负责管理我们的软件签名密钥时，我将 GPG 密钥保存在网络上的两台主机上，具有出色的主机安全性和良好的防火墙。我刻录了两张 CD：一张给我们的首席技术官，一张给我们的首席执行官。 （我只是告诉他，“不要丢失这张光盘。不要把它送给别人。”保持简单。:)
密钥的密码不同。我记得那件事。如果我失踪的话，负责接替我的同事知道密码。我要求我们的首席执行官和首席技术官将密码短语远离带有密钥的 CD。
当然，这是针对我们每天最多使用一次的密钥，当我们发布安全更新时，通常不会一次使用几天或几周。如果您的需求与我们的需求不同，您可能需要做其他事情。
When I was in charge of managing our software signing keys, I kept the GPG key on two hosts on our network with excellent host security and good firewalls. I burned two CD copies: one for our CTO, and one for our CEO. (I just told him, "Do not lose this disc. Do not give it away." Keep it simple. :)
The passphrase for the key was different. I remembered that. The coworker who would fill in for me if I was missing knew the passphrase. I asked our CEO and CTO to keep the passphrase well away from the CD with the key.
Of course, this was for keys that we would use at most once in a day, and often not for days or weeks at a time, when we released security updates. If your needs are different than ours were, you might need to do something else.