基础设施安全不会拖累开发人员

在这篇文章中，我想分享我对SaaS公司如何在拥有坚实的云基础设施安全和过度使用激怒自己的工程师之间进行权衡的观察。

保安很烦人。如果安全措施不妨碍事情的完成，生活可能会容易得多。如果您是一名正在处理紧急停机的站点可靠性工程师，从陷入困境的数据库管理员那里收到一条“拒绝访问”消息就像医生被他们试图救活的病人一拳打在脸上一样令人恼火！！

在这篇博客文章中，我们将回顾常见的反模式，建议替代方案，并提供有关如何更好地实现我们推荐的更好实践的较低级别技术资料的参考。

我们想要立即向房间里的大象发表讲话，并说以牺牲其他一切为代价的“最大”安全并不总是一件好事。每个人都在寻找“摇滚明星黑客”，并试图吸引最优秀的工程师加入他们的团队，但猜猜如果你强迫他们以一种不自然的方式工作，“黑客”会怎么做？

意图不一定是恶意的。比方说，您有一个专有的SSH连接“堡垒主机”，您强制每个人都通过。堡垒解决方案与ProxyJump设置不兼容，阻止人们直接从他们的计算机运行Ansible脚本或建立交互会话。我看到过另一种形式，堡垒只接受来自VPN的连接，这有点违背了被称为“堡垒”的目的，不是吗？

通过使SSH访问变得如此复杂，您最终可能会遇到另一个由开发人员在其他地方建立的“秘密”堡垒，原因很简单，因为他们试图提高工作效率。

或者您可能会注意到，堡垒主机现在正在运行其他服务，如Jenkins，甚至Wordpress，因为工程师发现总是手动“跳转”很麻烦。恭喜您，现在您在这些应用程序中很容易受到潜在的利用漏洞攻击。

一般来说，复杂性是良好安全性的敌人。复杂的系统不仅很难使用，而且也很难推理。它们提高了您的团队对高素质安全人才的需求。许多安全漏洞可以追溯到人为错误，人类在面对复杂性时往往会犯更多错误。

如果您使基础设施访问太复杂或太不方便，您最终会处于不太安全的状态。

另一方面，一些公司犯了与之相反的错误。他们可以轻松地将admin.pem放入Github上的私有存储库，由许多SRE共享。其他人则简单地要求每个人在供应期间将他们的SSH密钥分发到服务器，遗憾的是，这也很常见。

许多工程师向我承认，他们仍然可以接触到他们以前雇主的生产环境。在我担任一家主要云提供商的产品总监时，我在与客户互动时听过很多次这样的话。

很明显，如果您以方便为首要目标进行优化，那么您最终也会处于易受攻击的状态。

没有一种单一的、绝对正确的方法来实现基础设施安全，但我们希望提供一些您可能会发现对您的团队有帮助和适用的选项。

尽早投资于基于身份的访问是值得的。“身份”这个词已经被糟糕的行业营销劫持并吹到了面目全非的地步。但核心理念在原则上和实施上都很简单。

不是根据“什么”(秘密)授予访问权限，而是根据“谁”(身份)授予访问权限。

机密可能会丢失或被盗。即使是第二个因素也不是灵丹妙药，因为它只能将一个秘密一分为二。

基于身份的访问也更加方便，因为如果您是John Doe，并且您是DevOps工程师，这在工作时间内是不会改变的。你不应该为不断向各种系统提供秘密而烦恼。

要使用SSH作为示例，请考虑只将生产环境的SSH访问权限授予“SRE”组的成员，而不是拥有admin.pem密钥的任何人。还有一个好办法，就是确保在有限的时间内授予访问权限。

这消除了对SSH密钥的需要，同时使每个人的生活变得更容易。但最重要的是，如果团队成员离开SRE组(离开公司或转到另一个团队)，访问权限将自动撤销。

SRE组存储在哪里？随便挑一个最方便的。GitHub、Google Apps、Active Directory等。只需确保您使用的是每个人的单一身份来源-不只是工程师，而是所有员工。

如何根据组成员身份授予SSH访问权限？您必须留下SSH密钥(即使它们是“自动轮换”的)，并采用基于证书的身份验证。

我们之前已经在博客中介绍了如何正确使用SSH，在那里我们展示了如何使用事实上的标准OpenSSH进行设置。或者，您也可以通过使用我们的开源远程端口解决方案(将基于身份的访问作为访问基础设施的唯一方法)来走捷径，而不是自己实施“如何正确使用SSH”中的所有技巧。这简化了访问管理，并且基于身份的访问的副作用是极大地改善了用户体验。

为什么是证书？因为证书具有指定的TTL(生存时间)，这意味着访问凭证自动过期。此外，证书允许注入元数据。元数据之所以有用，原因有几个：

它允许您使用执行可审核任务的人员的全名、电子邮件地址和职务等附加信息来丰富安全审核日志。

它允许您实现RBAC(基于角色的访问控制)。HTTP/TLS使用的X.509证书广泛用于实现RBAC。如果您对SSH证书进行标准化，那么至少在理论上，您可以拥有用于SSH的RBAC。

使用SSH证书的另一个优点是，其他一切都已经是基于证书的。当工程师打开他们的笔记本电脑并通过SSO过程时，他们可能会收到来自同一证书颁发机构的证书，用于他们需要的一切：SSH、Kubernetes和任何支持此形式身份验证的内部Web应用程序。

访问代理和SSH跳转主机之间存在细微差别。Jumphost只是一个常规的SSH服务器，恰好是暴露在Internet上的服务器。开发人员(手动或使用OpenSSH ProxyJumpSetting或其较早的同级ProxyCommand)连接到跳转主机，然后必须建立从该跳转主机到目的地的另一个SSH会话。这有三个原因：

开始将跳转主机当作更多东西来对待变得很诱人：构建服务器、个人临时环境等，因为它更方便。

如果执行手动跳转，端到端加密就会消失，因为每个会话都会在跳转主机上解密并重新加密，也就是说，如果攻击者获得对跳转主机的访问权限，他们将更容易窃听会话，甚至窃取密钥。

访问代理是一个简单得多的概念。与跳跃主机类似，它是可以通过Internet访问的服务器，但您不能通过SSH进入它。可以把它想象成一个愚蠢的交换机，它只是将您的加密连接代理到目的地：

没有办法通过SSH进入它，因此不会诱使它承担额外的职责，从而增加攻击面。

端到端加密始终是强制的，也就是说，即使攻击者获得了访问此框的权限，他们看到的也只是一堆通过代理的加密连接。

一个访问代理可以支持多个协议，即不仅支持SSH，还可以支持Kubernetes API，甚至可以支持用于Jenkins等Web工具的HTTP/TLS。

也许更重要的是，它的回报是首先将访问基础设施的需求降至最低。作为软件工程师，我们更愿意只与一台计算机打交道--我自己的。如果测试通过了，并且代码审查很好，那么git提交和推送应该就是故事的结束了！