管理堡垒后面AWS服务器的SSH密钥访问

Question

我现在有一个AWS设置，有3个VPC，一个用于堡垒，然后是一个Dev和一个Prod，最后两个当然是通过堡垒(这个伟大的向导布局)访问的。我正在寻找最好的方式来管理3-5个用户访问系统。长期而言，我希望自动化和外部日志的地方，没有人需要SSH，但就目前而言，SSH是。

在阅读了这个关于ssh密钥管理的问题的想法之后，我正在考虑设置我的AWS访问，如下所示：

• 2防御工事、防御工事和不可征服堡垒的帐户。系统管理员经历一个，开发通过另一个。(开发人员没有理由做任何事情，只能通过堡垒)
• 每个bastion帐户中的authorized_keys文件分别持有sysadmins或devs的公钥。
• Dev/prodVPC实例每个都有一个sudoable帐户: it@devVPC和it@prodVPC。
• Devs在其@devVPC上获取实例的私钥，sysadmins为两个VPC实例获取私钥。
• 如果有人加入/离开公司，他们的公开密钥将从堡垒上正确的authorized_keys文件中添加/删除。
• 由于devVPC/prodVPC实例位于堡垒后面，即使离开的工作人员可能仍然拥有这些服务器的私钥，也无法访问它们，因为堡垒不允许它们通过。

我认为这将使我不必在每个实例上管理单独的useradd/userdel帐户。如果不深入LDAP和一些我无论如何都不想要的东西(同样，希望将来没有人需要SSH进入AWS服务器)，对于一个小团队来说，这看起来像是一个合法的/安全的设置吗？

我没有使用它，但我也看到了AWS OpsWorks作为控制SSH密钥的一种方法？我的情况听起来像是一个很好的用例吗？

Answer 1

这其中有一个很大的漏洞，那就是很难证明是谁对共享账户采取了什么行动。不是不可能，只是更难。此外，从深度防御策略来看，共享私钥是个坏主意。您可以通过单独管理帐户来解决这两个问题，这会造成更大的管理开销，但对于只有5个用户来说，这不应该很重要。

我不能对作品的想法作深入的评论，我没有使用它。根据对您提供的文档的快速阅读，它看起来就像在实例和authorized_keys文件上设置帐户一样，这是一个非常小的任务。你还得花时间用AWS帐户来设置你的所有用户，这似乎不是一个好的权衡。

Answer 2

对每个用户使用单独的SSH密钥，在每个系统上为它们使用单独的用户帐户。

我们创建用户，将他们分配给角色，并使用用户食谱启用公共密钥访问，这是OpsWorks所基于的开源项目。

Answer 3

正如杰西所指出的那样，如果我们需要这样做的话，使用我的方法就会让我们很难对后续的行为进行审计，所以我认为我需要选择一个更好的选择。

1)查看OpsWorks或仅仅使用Ansible，就像Alain建议的那样，我们已经为某些服务器配置做了一些工作，这听起来很有希望。它似乎不会增加太多的开销。

2)我还遇到了福克斯帕斯服务，它看起来像是将SSH密钥管理与我们现有的Google帐户集成在一起。这可以减轻我对上机(和不登机)员工开销的一些担忧。