为小组存储生产密码的最佳实践
这不是一个技术问题。 小型组织如何确保必须在多人之间共享的敏感信息（例如生产服务器的 root 密码）的安全？ 并非所有需要访问权限的人都在同一位置工作。新密码可以通过电话分发，但在存储密码时应为团队成员执行哪些规则？
更新：这个问题与 root 密码的正确使用无关——这只是一个例子。 也许更好的例子是 SSL 密码或必须在执行管理任务的人员之间共享的任何其他密码。 事实是，需要生成和存储 root 密码等，并且通常需要多个人具有访问权限，有时这些人在不同的地点工作。 问题是关于存储协议。 谢谢。
This is not a technical question. How do small organizations keep sensitive information that must be shared among several individuals safe, such as root passwords to production servers? Not all people that need to have access work in the same location.. new passwords can be distributed by phone, but what rules should be enforced for team members in the storing of the passwords?
UPDATE: this question is not about the proper usage of root passwords -- that was just meant as an example. Maybe a better example would be the SSL passphrase or any other password that must be shared among people performing administrative tasks. The fact is, root passwords and the like need to be generated and stored and usually more than one person needs to have access, sometimes those people work in different locations. The question is about storage protocols. Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
您不应该向任何服务器、生产服务器或其他服务器分发（或使用）root 密码。 您不应该共享密码。
人们应该以自己的身份登录（身份验证）使用自己的用户 ID 密码； 这是图片的一半。
正确登录后，他们应该被授予适当的权限（图片的授权方）。 您可以将 sudo 之类的东西用于一般操作系统用途，以及数据库内部的权限机制等。
这是两个不同的问题。 不要跨越溪流！
You shouldn't be handing out (or using) root passwords to any servers, production or otherwise. You shouldn't be sharing passwords.
People should log in as themselves (authentication) with their own user ids passwords; that's one half of the picture.
When properly logged in they should be given rights (the authorization side of the picture) as appropriate. You can use things like
sudofor general OS purposes, and the rights mechanisms inside databases, etc.These are two separate issues. Don't cross the streams!
我个人建议面临类似问题的人使用 keepass 或 roboform 之类的东西来存储密码。 这些程序使用个人记住的主密码对拇指驱动器上的密码进行加密，因此他们只需要记住主密码即可。 如果有人丢失了拇指驱动器，他们将有一段时间可以报告受损的拇指驱动器，并允许您更改密码。 窃取拇指驱动器的人需要花费一点时间才能暴力破解主密码以获取所有其他存储的密码，具体取决于主密码的强度。
此外，如果有的话，请避免超过 3 人共享任何帐户！ 相反，请考虑为每个人创建一个具有同等访问权限的帐户。 如果恶意员工有权访问他们知道是共享的帐户，那么他们可能更容易做出恶意行为，因为他们知道您无法追究他们的责任，因为共享该帐户的人可能是多个人中的任何一个。
这也意味着您不必在每次有人退出时都更改密码。 相反，您只需禁用/删除他们的帐户即可。 因此，尽管您有更多帐户需要管理，但当有人离开时，您的开销会更少，因为您不必通知每个人密码已更改。
编辑：哦，Roboform 还具有基于 SSL 的在线密码同步服务。 因此，您可以让人们通过同步来检索密码。 一旦习惯了就感觉很酷。
I personally recommend to people facing similar problems to use something like keepass or roboform to store passwords. These programs encrypt your passwords on a thumbdrive using a master password that the individual remembers, so that they need only remember the master password. In the event that someone looses their thumbdrive, they will have a window of time in which they can report the compromised thumbdrive, and allow you to change passwords. It will take a little bit of time, depending on the master password's strength, before the person who stole the thumb drive would be able to brute force the master password to get at all the other stored passwords.
Additionally, avoid having any account shared by more than 3 people, if at all! Instead, consider creating each individual an account with equivalent access. If a malicious employee has access to an account which they know is shared, it might be more tempting for them to do malicious things since they know you could not hold them accountable, since it could have been any of several people sharing the account.
This also means you don't have to change the password every time someone quits. Instead, you just disable/delete their account. So although you have more accounts to manage, you have less overhead when someone leaves since you don't have to notify everyone of a changed password.
Edit: Oh Roboform also has a online password sync service over SSL. So you could just have people retrieve passwords via syncing. It's kinda cool once you get used to it.
随着
sudo的出现，我们很少需要再使用 root 密码了。 在我的老店里，根密码写在一张卡上，密封在一个信封中，锁在系统管理员区域的抽屉里。 那些需要知道的人有抽屉的钥匙。任何打开信封的人都必须更改密码并将新密码放入新的密封信封中。 信封不常被打开。
这个系统可能是非常糟糕的专业实践，但在一个每个人都认识的小商店里，它运作良好。
With the advent of
sudowe seldom need to use a root password any more. In my old shop, the root password was written on a card, sealed in an envelope, and locked in a drawer in the sysadmins' area. Those who needed to know had keys to the drawer.Anybody opening the envelope was required to change the password and put the new password in a new sealed envelope. The envelope was not opened often.
This system is probably really bad professional practice, but in a small shop where everybody knew everybody, it worked well.
在原型和 我以前工作的研发实验室有“标准”实验室密码，用于 root、控制台、交换机的管理访问等。这些密码简单、易于记忆，并与任何需要它们的人口头共享。 一般来说，如果您能够实际进入实验室，您就被授权拥有这些密码。
在制造工厂中，为客户构建和配置了新系统。 客户必须选择所有密码，并将它们打印在一组表格上，并与系统一起固定在机架上。 根据需要提供远程访问，密码通过电子邮件发送或通过电话给出。 完全预计客户会在系统交付给客户后立即更改这些密码。
对于 IT 和 生产实验室中，几乎没有人拥有 root 访问权限。 几乎每个人都拥有 sudo 访问权限，但没有任何限制，只能挂载虚拟文件系统……具体取决于个人和系统。 获得 sudo 访问权限以 root 身份启动 shell 的情况非常罕见。 这会留下非常清晰的日志记录，记录您以 root 身份运行的所有命令。 该日志用于 tar & 多年来羽毛不止一个人。
多年前，在我担任的帮助台/支持角色中，每个工具专家都选择了自己的管理密码。 这些记录在一个信封里，锁在机房的保险箱里。 如果有人需要管理员访问权限，他们可以打开信封，读取密码，并在日志中注明他们知道密码，然后将密码重新密封在信封中。 由工具所有者决定是否需要更改密码。 该系统已使用超过 5 年......在一个案例中，实际上帮助该项目在一名团队成员的“总线测试”（心脏病发作）中幸存下来。
不同类型的系统和实验室有不同的标准。 这是合理的。 我发现，当密码需要分片时，最好密码简单、简短并以口头方式传达（亲自或通过电话）。 我发现唯一不应该共享的密码是我个人帐户的密码。 任何 root/admin/工具特定的密码都应该备份在至少一个其他头中......如果没有以某种方式记录的话。
In a prototype & R&D lab where I formerly worked, there were 'standard' lab passwords for things like root, administrative access to consoles, switches, etc. These are simple, easy to remember, and shared verbally with anyone who needed them. In general, if you could physically get into the lab, you were authorized to have these passwords.
In the manufacturing facility, new systems were built and configured for customers. The customer got to choose all the passwords, and they were printed on a set of forms that were attached to the rack with the systems. Remote access was provided as required, and the passwords were sent in an e-mail, or given over the phone. It was fully expected that the customer would change these passwords as soon as the system was delivered to them.
For the IT & Production labs, almost no one had root access. Almost everyone did have sudo access with somewhere between no limits and only the ability to mount virtual filesystems...depending on the person and the system. It was very rare to get sudo access to launch a shell as root. This left a very clear log trail of all the commands you ran as root. That log was used to tar & feather more than one person over the years.
At a help desk / support role I had many years ago, each tool expert picked their own administrative passwords. These were recorded in an envelop that was locked in a safe in the machine room. If someone needed admin access, they could open the envelop, read the password, and note in the log that they knew the password and then re-seal the password in the envelop. It was up to the tool owner to decide if the password needed to be changed. This system was used for more than 5 years...and in one case actually helped the project to survive the "bus test" (heart attack) for one team member.
Different standards for different kinds of systems and labs. That is reasonable. I find that when passwords need to be shard, it is best if the password is simple, short, and communicated verbally (either in person or over the phone). I find that the only password that should never be shared is the one for my personal account. Any root/admin/tool specific passwords should be backed up in at least one other head...if not recorded in some manner.
您可以使用像anypasswordpro这样的程序来共享密码。 它已加密并具有访问级别:)
you can use a program like anypasswordpro to share passwords. It is encrypted and has levels of access :)
现实点。 无论您是否喜欢，小团队中的人员都会将密码写在便利贴上，通过即时消息发送给他们，或者很想通过电子邮件发送给他们，尤其是当他们认为没有威胁时。
我发现对小团体有用的一项措施是建立一个混淆协议。
例如，通过语音邮件、电子邮件、即时消息或纸质文件传达或存储的所有密码都将具有
1）字符顺序颠倒
2) 每个密码字符之间放置一个随机字符或单词
3) 按拼音发音的密码字符。
例如：
密码：VMaccp@ss1
模糊处理：one 2 es df es 23 at sd pee fd see dfs see fxz ay df EM sd VEE
关键是建立某种编码，如果不知道密码，某人实际上不可能弄清楚协议，很容易记住。
请记住，这是针对没有生死安全的小团体的。 显然，对于较大的团体或保护极其敏感的财务数据的团体来说，更强有力、更繁琐的措施是合适的。
Be realistic. Whether you like it or not, people in small teams are going to write passwords on sticky notes, IM them, or be tempted to email them, especially when they perceive no threat.
One measure I've found useful with small groups is to establish an obfuscation protocol.
For example, all passwords communicated or stored via voicemail, email, IM, or paper will have
1) the order of their characters reversed
2) a random character or word placed in between each password character
3) phonetically pronounced password characters.
For example:
Password: VMaccp@ss1
Obfuscated: one 2 es df es 23 at sd pee fd see dfs see fxz ay df EM sd VEE
The key is to establish some kind of encoding that is virtually impossible for someone to figure out without knowing the protocol, which is easy to remember.
Keep in mind this is for small groups without life-or-death security. Obviously for larger groups or those protecting extremely sensitive financial data stronger more cumbersome measures are appropriate.