Ansible安全最佳做法

我将把Ansible引入我的数据中心，并且我正在寻找有关在哪里放置控制机器以及如何管理SSH密钥的最佳安全性最佳实践。

问题1：控制机

我们当然需要一台控制机。控制计算机上已保存了公共SSH密钥。如果攻击者有权访问控制计算机，则它可能有权访问整个数据中心（或由Ansible管理的服务器）。那么在数据中心或远程控制机器（例如我的笔记本电脑远程连接到数据中心）中配备专用的控制机器会更好吗？

如果最佳实践是使用笔记本电脑（当然可能会被盗，但是我可以将我的公钥安全地在线存储在云中或离线保存在便携式加密设备上），如果我需要使用某些Web界面像Ansible Tower，Semaphore，Rundeck或Foreman这样的Ansible是否需要在集中式计算机上安装到数据中心？如何保护它并避免它成为“单一攻击点”？

问题2：SSH密钥

假设我需要使用Ansible来完成一些需要由root执行的任务（例如安装软件包或类似的东西）。我认为最佳实践不是在受控服务器上使用root用户，而是为具有sudo权限的Ansible添加普通用户。但是，如果Ansible需要执行几乎所有任务，则需要通过sudo访问每个命令。那么，什么是最佳选择：

• 让Ansible使用root用户（其公共密钥保存在 ~/.ssh/authorized_keys
• 创建一个专用于具有sudo访问权限的Ansible的非特权用户
• 让Ansible用户通过sudo指定密码来运行每个命令（每个使用Ansible来控制服务器的sysadmin都必须知道这是唯一的）
• 让Ansible用户通过sudo运行每个命令，而无需指定任何密码
• 还有其他提示吗？

堡垒主机（Ansible控制中心）属于一个单独的子网。不应从外部直接访问它，也不应从托管服务器直接访问它！

您的笔记本电脑是最不安全的设备。一封愚蠢的邮件，一个愚蠢的Flash漏洞，一个愚蠢的来宾Wifi，并对其进行伪造。

对于服务器，完全不允许通过ssh进行root访问。许多审计对此表示嘲笑。

对于Ansible，让每个管理员在每个目标服务器上使用他们自己的个人帐户，并让他们使用密码sudo。这样，两个人之间不会共享密码。您可以检查谁在每个服务器上做了什么。个人帐户只允许登录密码，仅使用ssh密钥或同时要求两者都由您决定。

澄清ansible不需要使用单个目标登录名。每个管理员可以并且应该具有个人目标登录名。

附带说明：如果有密码，请不要创建一个叫做“单词”（例如“ ansible”或“ admin”或“ cluster”或“ management”或“ operator”）的帐户。具有密码的帐户的唯一好名字是人的名字，例如“ jkowalski”。只有一个人才能对通过该帐户执行的操作负责，并对不正确地保护其密码负责，“可翻译”则不能。

>问题一：控制机

在Userify（全面披露：我们实际上提供了用于管理ssh密钥的软件）时，我们一直都在处理此问题，因为我们还运行着最大的SSH密钥仓库。通常，我们建议您使用本地安装，而不要使用云，因为您可以增强控制能力，减少表面积，因此可以将其真正锁定在已知的受信任网络中。

要记住的重要一点是，在像这样的适当构建的系统中，实际上不应有任何重要的机密可以泄露给攻击者。如果有人驾驶叉车进入您的数据中心并离开服务器，那么他们将得到很多，除了一些哈希值很高的密码，可能是一些高度加密的文件以及一些没有相应私钥的公共密钥。换句话说，没有那么多。

正如您所指出的那样，如果攻击者获得了该计算机的控制权并使用它来部署自己的用户帐户和（公共）密钥，就会发生真正的威胁向量。这几乎对每个云平台（例如：Linode）都是一个风险。您应该最集中精力阻止访问控制平面，这意味着最大程度地减少攻击面（仅暴露一些端口，并尽可能地锁定这些端口），并且最好使用能够防止特权升级和各种攻击的软件（ SQL注入，XSS，CSRF等）使2FA / MFA访问控制平面并尽可能集中于锁定该控制平面。

那么在数据中心或远程控制机器（例如我的笔记本电脑远程连接到数据中心）中配备专用的控制机器会更好吗？

这是肯定更好有一个专用的控制机器在安全的数据中心，因为你可以隔离并锁定，以防止/最小化被盗或未经授权的访问的风险。

如果最好的做法是用我的笔记本电脑（这可能会被窃取，当然，但我有我的公钥安全地在便携式加密后设备上的云或离线在线保存），如果我需要使用一些网络接口什么用像Ansible Tower，Semaphore，Rundeck或Foreman这样的Ansible是否需要在集中式计算机上安装到数据中心？

您无需运行任何Web界面或辅助控制平面来管理密钥（甚至是Userify），直到由于用户数量众多以及服务器之间的授权级别不同而变得足够大而开始陷入管理问题之前，或者您需要额外的权限为您可能不了解或无法访问Ansible更新密钥的用户提供帮助。最初，Userify只是一堆shell脚本（今天可能是Ansible！），这根本没有错，直到您开始需要其他管理控制和人们用来管理/轮换他们的简单方法为止自己的钥匙。（当然，如果可以的话，请看一下Userify！）

如何保护它并避免它成为“单一攻击点”？

好吧，当然，请检查网络上的所有资源以锁定事物，但最重要的是要从安全的基础开始：

1.从一开始就在设计解决方案时要牢记安全性。选择传统上问题较少的技术（即数据库或语言），然后优先考虑安全性。清理所有传入数据，甚至是来自受信任用户的数据。偏执狂是一种美德。

2.最终，一切都崩溃了。尽可能减少发生的损害：正如您已经指出的那样，请尽量减少对秘密材料的处理。

3.保持简单。除非您确定它将可测量地证明可提高您的安全性，否则请不要做最新的奇特的东西。例如，我们选择了AES上的X25519 / NaCl（libsodium）作为加密层（我们对所有数据进行了静态和动态加密），因为它最初是由我们信任的人（DJB等人）设计和编写的，并且受到了世界的审查。知名研究人员，例如Schneier和Google的安全团队。如果它们是较新的，请使用倾向于简单性的东西，因为简单性会更难掩盖深层的bug。

4.符合安全标准。即使您不属于PCI或HIPAA安全规则之类的安全机制，也请通读那些标准并弄清楚如何满足这些标准，或者至少要采用非常强大的补偿性控制措施。这将有助于确保您真正符合“最佳实践”。

5.进行外部/独立渗透测试并运行漏洞赏金计划，以确保您不断遵循这些最佳实践。一切看起来都很好，直到您让一些聪明而有上进心的人为此付出了努力……一旦完成，您将对解决方案充满信心。

问题2：SSH密钥最佳选择：让Ansible使用root用户（其公共密钥保存在~/.ssh/authorized_keys/中，让Ansible用户通过sudo指定密码来运行每个命令（这是每个sysadmin都必须知道的唯一方法）使用Ansible来控制该服务器）

尽量避免在服务器上使用密码，即使是sudo。那是在处理机密信息，最终会破坏您的安全性（您无法真正非常轻松地在机器之间更改sudo密码，必须将其存储在某个地方，密码意味着您无法真正实现服务器到服务器的自动化，这是同样，如果您将SSH保留为默认设置，则这些密码可能会被强制使用，这会使密钥变得毫无意义，而且，请避免出于任何目的（尤其是远程登录）使用root用户。

使用sudo访问权限创建一个专用于Ansible的非特权用户/让Ansible用户通过sudo运行每个命令而无需指定任何密码

究竟。您可以使用sudo角色审核到ansible的非特权用户。理想情况下，创建一个专用于具有sudo访问权限（无密码）的服务器到服务器/可通信的标准用户。

...注意，如果您使用的是Userify，我建议这样做的方法是为ansible创建一个Userify用户（如果您有多个ansible控制机器，也可以按项目甚至服务器组将其拆分），生成控制服务器上的SSH密钥，并在其Userify配置文件页面中提供其公共密钥。（此文本框实质上变为/home/ansible/.ssh/authorized_keys）。您应该将ansible系统帐户与其他服务器到服务器系统帐户（例如，远程备份帐户，秘密管理等）分开。然后邀请您的人员，他们也可以创建和管理自己的密钥，并且一切都保持独立。但是，就像锁定Ansible控制服务器一样，请尝试以相同的方式锁定Userify服务器（或部署的任何解决方案）。

还有其他提示吗？

我认为您肯定是在以正确的方式提出这个问题，并提出正确的问题。如果您想讨论这种事情，请给我发电子邮件（userify上的第一个点的姓氏），无论您最终追求什么方向，我都会很高兴进行聊天。祝好运！

答案1：控制机

两者兼有，您可以使用笔记本电脑通过堡垒主机连接到服务器。就像是：

Host private1
  IdentityFile ~/.ssh/rsa_private_key
  ProxyCommand ssh user@bastion -W %h:%p

Host bastion
  IdentityFile ~/.ssh/bastion_rsa_key

有关堡垒主机的更多信息

您在其中拥有堡垒服务器的密钥，然后有背后的主机的单独密钥。（我个人将使用gpg-agent / ssh-agent）

答案2：验证

我不确定特定于“可使用的”最佳实践与任何其他ssh连接最佳实践有什么不同，但是不，您想以自己的身份运行ansible，而不是服务帐户而不是根帐户。

以下身份验证的组合：

• 每个用户的ssh密钥（集中存储）
• Kerberos验证
• 多因素身份验证（Yubikeys，Duo，GoogleAuth等）
• Fail2ban /帐户锁定
• 集中式日志记录和警报
• 集中式身份验证（FreeIPA，LDAP，IdM，MS AD）
• 用内部CA签署SSH密钥

其他想法：

• 始终将机密/私人信息存储在ansible-Vault中。
• Ansible不需要运行SUDO / Root，除非您正在执行的操作需要sudo / root。
• Ansible可以多种方式提升权限

最后，您没有提及Windows。因此，我只能假设您没有使用此功能。但是，在这种情况下，我将使用委托选项让您的笔记本电脑使用堡垒主机（delegate_to bastion.hostname.fqdn：）和kerberos / winrm https和kerberos票证。

万一您错过了它，计算的最佳实践，永远不要以root用户身份执行任何操作，始终使用命名帐户