位开发人员|防患于未然，应对“删库跑路”的一种解决思路解决|公钥|开发人员|应对|跑路

作者 | Marc P?pper
译者 | 王强
策划 | 万佳
本文最初发布于 paepper.com 网站，经原作者授权由 InfoQ 中文站翻译并分享。
开发人员经常需要访问某些服务器，做一些检查应用程序日志之类的工作。
一般来说，访问过程是使用公私钥加密来控制的，每位开发人员都会生成自己的公私钥对。并且，每个开发人员的公钥都会添加到他们有权访问的每台服务器上的 authorized_keys 文件中。

文章插图
痛苦的手动更改
到目前为止，这还没什么问题。但是，当一名开发人员离职时又会发生什么事情呢？
在这种情况下，应该从所有服务器上删除这位开发人员的公钥。根据他们有权访问的服务器数量，这可能会涉及很多工作。
更糟糕的是，如果这个环节都是手动操作的，那么操作员很有可能会忘了删除某些服务器上的公钥。也就是说，离职员工的访问权限仍然保持启用状态。
替代解决方案
有一些商业和开源解决方案可以帮助我们解决这一问题。这里的基本思想是，你在这类服务上添加并维护一个密钥和访问权限列表，需要删除某个密钥时，该密钥将从所有服务器中删除。
这听起来不错，但这种方案有一个很大的缺陷：它是潜在的单一故障源。如果某人获取了对该服务的访问权限，那就意味着他可以访问你的所有服务器。而且，如果你无法访问这个服务，在最坏的情况下，甚至会无法访问所有服务器。
解决方案：签名密钥
当我遇到了这个问题时，我去 HackerNews 上问了问其他人是如何解决它的。
社区提供了一些很棒的建议和见解，而这个问题的最佳解决方案似乎是对密钥进行签名，本文会详细给大家介绍一下。
基本思想
这个方法的基本思想是：你还是要为每位开发人员生成一个公钥 - 私钥对。但是，不要把公钥上载到服务器上。
而是使用之前生成的，所谓的证书颁发机构（CA）密钥对公共密钥进行签名。这个签名就是生成了第三个证书文件，你将它还给开发人员，然后让他们放在.ssh/ 文件夹中，和私钥、公钥放在一起。
在服务器上，你只需告诉服务器你的 CA 的公钥，服务器就可以检测用户是否具有正确签名的证书，并且仅允许拥有这种签名证书的开发人员访问自己。
优点
签署证书时，可以定义这次签署有效的时间。因此，如果你签署的有效期为 3 个月，随后开发人员离开了公司，那么 3 个月后，他们肯定将无法访问任何服务器。
现在你会说：好吧，但我不想每 3 个月就对每个人的密钥签一次名，这个抱怨很合理。
一种办法是让这个流程自动化，例如，你可以构建服务，让用户在使用公司的电子邮件和密码授权时可以自动获得签名证书，但这不在本文的讨论范围之内。
另一种简单的替代方法是，你可以颁发有效期更长的证书。然后，如果有人离开公司，就可以撤消这个证书，也就是使其失效。你可以在服务器上放置一个无效证书列表，它们将不再接受用户访问。例如，可以通过 AWS S3 或其他存储来存放这个列表，并在每台服务器上定期创建一个 cronjob 来完成这一操作。
该怎么做？
了解了原理后，实际上做起来非常简单。
首先，你要生成一个证书颁发机构的公钥 - 私钥对，你应该把这个私钥放在非常安全的地方：
然后在你的服务器上，设置为允许由你的 CA 签名的所有用户访问该服务器：
【 位开发人员|防患于未然，应对“删库跑路”的一种解决思路】将 CA 的公钥上传到服务器上，例如放在 /etc/ssh/ca.pub
在 /etc/ssh/sshd_config 中添加一行，指示服务器允许访问由该证书签名的用户：
为了使更改生效，你应该重新加载 ssh 服务：sudo service ssh reload。现在，如果一位开发人员生成了他的公钥 - 私钥对（例如 ssh-keygen -t ecdsa -b 521），他们只需向你发送他们的公钥（请注意，你永远不需要发送任何私钥！）。然后，你只需签署他们的公钥就能生成他们的证书：
各个部分的简要说明：
-s ca：你要使用 CA 进行签名
-I USER_ID：你的用户 ID/ 用户名
-V +12w：证书过期前的有效时间，这里有效期为 12 周
-z 1：此证书的序列号，以后可用它来让这个证书无效，序列号应唯一
id_ecdsa.pub：你要签名的开发人员的公钥
它将生成证书 id_ecdsa-cert.pub，你可以将其发送给开发人员，然后将其放在?/.ssh 文件夹中的公钥 / 私钥对旁边。
改进一下
听起来不错，但是你还可以做得更好！