在我们的管理团队中,每个人都拥有所有客户端服务器的 root 密码。但是,如果其中一名团队成员不再与我们合作,我们该怎么办?他仍然有我们的密码,每次有人离开我们时,我们都必须全部更改。
现在我们使用 ssh 密钥而不是密码,但是如果我们必须使用 ssh 以外的其他东西,这将无济于事。
我运行的系统有一个sudo -only 策略。即,root 密码是*
(禁用),人们必须使用 sudo 来获得 root 访问权限。然后,您可以编辑您的sudoers
文件以授予/撤销人们的访问权限。它非常精细,并且具有很多可配置性——但具有合理的默认值,因此设置起来不会花很长时间。
我通常会建议以下内容:
现在,使用此设置,所有用户都必须使用 sudo 进行远程管理,但是当系统严重混乱时,无需寻找 root 密码来解锁控制台。
编辑:其他提供自己登录名的系统管理工具也需要调整。
虽然根据系统的大小使用 Chris 建议的仅 sudo 策略是个好主意,但 ldap 方法也可能会有所帮助。我们通过一个包含所有 root 密码的文件来补充这一点,但 root 密码真的很长而且难以记忆。虽然这可能被认为是一个安全漏洞,但它允许我们在 ldap 服务器关闭时仍然登录。
除了可能更好的 sudo 策略之外,没有理由每个管理员不能拥有自己的 UID 0 帐户,但名称不同,密码不同,甚至主目录不同。只需在他们离开时删除他们的帐户即可。
合理的强根密码。每个盒子都不一样。没有远程 root 登录,也没有登录密码,只有密钥。
我们只是让更改我们管理的每台机器上的 root 密码变得非常容易,所以当人们离开时,我们只需运行脚本。我知道不是很精明,但它奏效了。在我之前,公司的每个人都可以访问所有服务器上的 root。幸运的是,我们远离了这一点。
一般来说,如果有人离开我们的团队,我们不会费心更改 root 密码。要么他们离开了公司(并且由于他们的 VPN 已被撤销,他们对大楼的访问权限以及对网络的无线访问权限都已被撤销,因此无法再访问机器),或者他们在公司内部的另一个部门并具有不与我们的环境搞混的专业精神。
是安全漏洞吗?也许。但是,真的,如果他们想搞砸我们的环境,他们会在继续前进之前这样做。
到目前为止,任何想要再次访问我们机器的离开团队的人总是会请求许可,即使他们可以在未经许可的情况下继续使用。我看不出有任何理由阻碍我们完成工作的能力,即,没有理由相信其他任何人向前和向上会做不同的事情。
如果您通过证书进行 ssh 访问,您不能通过 ssh 登录并更改root
密码吗?passwd
或者sudo passwd
当您需要执行其他需要密码的操作时?
我们在我工作的地方使用 sudo only 策略,但仍保留 root 密码。只有少数员工可以使用 root 密码。我们有一个名为 Password Manager Pro 的程序,它可以存储我们所有的密码,并且还可以提供密码审核。这使我们可以返回并查看哪些用户访问了哪些密码。因此,我们只能更改实际需要更改的密码。
SSH 密钥没有真正的选择。
为了管理authorized_keys
许多服务器上的许多文件,如果您不想在每台服务器上使用相同的文件,则必须实施自己的解决方案。要么通过自己的工具,要么使用一些配置管理解决方案,如 puppet、ansible 或类似的东西。
否则一个 for 循环bash
或一些clush
操作就足够了。
除了 SSH 登录之外的任何东西:
对于您运行的基于登录的服务,请使用某种带有中央后端的身份验证。请记住,如果此后端不可用,则没有人会做任何工作!
以集群方式运行服务。不要使用超级欺骗服务后门帐户进行黑客攻击,以便在出现问题时始终可以访问(例如由于配置错误导致管理员访问中断)。无论您如何监控影响此帐户的访问或配置更改,这都是“糟糕的”(TM)。
与其让这个后门正确,不如只对应用程序进行集群,或者至少有一个备用系统定期镜像手头的设置,如果主机死机,然后可以通过网络中的路由更改轻松激活。如果这听起来太复杂,您的业务要么太小,您可以忍受半天到两天的停机时间。或者你真的因为缺乏知识而讨厌集群,只是在错误的事情上存钱。
一般来说:如果您确实使用了无法通过某种 Active Directory 或 LDAP 集成使用的软件,则必须手动更改密码。
还有一个专用的密码管理数据库,只能由极少数人直接访问,并且对所有其他人都是只读的,非常好。不要打扰excel文件,这些文件缺乏适当的权限管理。在 .csv 文件上使用版本控制并不会在某个阈值之后真正削减它。