如何存储加密的设置？
我们已经对一些应用程序中的设置实施了加密。
总有一天我们会忘记这些设置的内容。存储它们的好方法是什么？我们团队的某些成员需要访问它们。
有一种方式我不喜欢：我们的管理员为此使用维基。这个维基是否可以访问。没有简单的方法可以查看团队中的哪些成员拥有哪种登录的信息。
我可以想到两种可能性：
加密它们并将它们保存在 Subversion 中。只有参与该项目的团队成员才拥有解密它们的密钥。
使用专为解决此问题而定制的应用程序
保存秘密并使某些成员可以访问它们的好方法是什么？
编辑 1
这是我们可能遇到的问题的示例：
我们有一个在网络服务器上运行的网络应用程序。该配置有一些安全关键设置，例如支付提供商。如果系统崩溃，我们必须将应用程序移动到新服务器，我们就无法使用加密的配置。我们必须拥有一份明文并在新服务器上对其进行加密。
重新创建配置是不可行的。我们确实必须将其部分内容以明文形式存储在保存位置。
We have implemented encryption for settings in some of our applications.
The day will come when we forgott the content of these settings. What is a good way to store them? They need to be accessed by certain members of our team.
There is one way I dont like: Our admins use a wiki for this. This wiki is acessible or not. There is no easy way to see what member of the team has information to what kind of logins.
I can think of 2 possibilities:
Encrypt them and save them in Subversion. Only members of the team that work on the project have the key to decrypt them.
Use an application that is tailored to solve this problem
What is a good way to savely store secrets and make them accessible to certain members?
EDIT 1
Here is an example of a problem we might run into:
We have a web application that runs on a webserver. The config has some security critical settings like payment providers. If the system crashes and we have to move the application to a new server we cant use the encrypted config. We have to have one in clear text and encrypt it on the new server.
Its not feasible to recreate the config. We realy have to store parts of it in clear text in a save place.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
实现此目的的一种方法是使用密钥对其进行加密，然后在 USB 驱动器或类似设备上为每个用户提供 1/2 的密钥。这样他们就不能滥用它并直接窃取信息，但需要拥有密钥另一部分的其他人的合作。即使 USB 驱动器/文件被盗，整个帐户也不会受到损害。此外，还有冗余功能，因此如果数据丢失或被盗，您仍然可以获得访问权限并重新加密数据。
One way you could do this, is to encrypt it with a key, and then give each user 1/2 of the key on a usb drive or some such. That way they can't abuse it and steal the information directly, but would need the cooperation of someone else who has the other part of the key. And if the usb drive/file is ever stolen, the entire account isn't compromised. Plus there's redundancy so that if one is lost or stolen you can still gain access and re-encrypt the data.
您可以编写一个程序来保留授权用户的列表，并只允许他们通过该程序查看某些加密文件。授权用户可以通过公钥数字签名与程序进行通信 - 通过这种方式，管理员可以知道哪些用户仍然被授权，但他们仍然必须验证自己才能访问安全数据。
但是对于您在编辑中提供的示例，我有点困惑。这听起来像是一个略有不同的情况。但是，您永远不应该存储未加密的安全数据 - 这违背了目的，并且通过模糊性实现安全性并不是可接受的解决方案！为什么不只存储密钥来解密设置文件，以便如果需要将其移动到其他服务器，您可以解密它并（如果需要）使用新密钥对其进行加密？
You could write a program that keeps a list of authorized users and only allows them to view certain encrypted files through the program. The authorized users could communicate to the program via a public-key digital signature - in this way the admin could know which users are still authorized, but they would still have to authenticate themselves to access secure data.
But with the example you provide in your edit, I'm a bit confused. That sounds like a slightly different case. You should never store secure data unencrypted, though - that defeats the purpose and security through obscurity is not an acceptable solution! Why not just store the key to decrypt the settings file, so that if it needs to move to other server, you can decrypt it and (if necessary) encrypt it with a new key?
首先也是最重要的密码绝对不能加密，因为这是CWE-257。不要忘记“内部威胁”，毕竟您最终将不得不解雇某人。用户也经常重复使用密码。在这种情况下，我将实现一个类似于 sudo 的函数，您可以在其中控制帐户。或者大多数应用程序都有一个简单的“忘记密码”。
如果这些是共同的秘密。例如随机生成需要共享的 root 密码，那么加密是一个好的解决方案。请记住，如果您解雇某人，那么这个秘密就会被泄露，您将不得不重新生成秘密。
First and foremost passwords MUST NEVER be encrypted because this is a vulnerability identified by CWE-257. Don't forget about the "insider threat" after all you will have to fire someone eventually. Also users then to reuse passwords quite often. In this case i would implement a
sudolike function where you can assume control over an account. Or perhaps a simple "forgot password" that most applications have.If these is a mutual secrets. For instance randomly generated root passwords that need to be shared, then encryption is a good solution. Keep in mind that if you fire someone then this secret is compromised, and you will have to regenerate the secrets.