提高云中的运营安全性

如果您想降低云运营成本，请查看运营管理方面的安全实践。

目前对安全的大部分关注都集中在应用协议和应用堆栈本身的漏洞上。 这并不奇怪，因为大多数违规行为的发生都是因为常见平台和框架中的漏洞提供了大量容易攻击的目标。

但我们不要忽视企业管理方面日益增强的难度。 当我们将应用程序移到公共云中时，我们常常忽视将管理流量与轻松访问隔离的重要性。 在现场，这很容易。 管理网络无法向公众开放。 我们将它们锁定在只能从内部访问的不可路由的网络上。 由于我们已将应用程序及其应用服务基础设施迁移到云中，因此我们需要可公开访问的管理，因为操作员现在位于远程。

虽然我们已经从 Telnet（除了所有需要赶上的物联网设备）过渡到 SSH，甚至实践了良好的密码生成行为，但我们不一定研究如何更好地利用云原生安全性以及我们自己的实践。

使用云提供商安全服务会极大地影响在云中开展业务的运营成本 - 特别是在管理应用服务基础设施方面。

威胁是真实存在的

如果您还没有机会阅读 F5 Labs 关于最受攻击的用户名和密码的文章，那么您应该阅读一下。 在其中，您会了解到 SSH 是一种高度针对性的服务。 事实证明，这种情况比其他任何事情都更严重。

摘自本文：

从攻击量来看，攻击者花在攻击 SSH 上的时间和精力比攻击其他任何在线服务都要多。 通过 SSH 强制访问生产应用s的管理登录信息的行为比通过 HTTP 攻击应用本身（攻击者试图利用 Web应用漏洞）的行为多 2.7 倍。

为什么不呢？ 对应用服务基础设施的管理控制赋予您很多权力 - 包括修改可能阻止轻松访问 Web应用s的策略的能力。 就 Kubernetes 而言（通常由于未要求任何凭证而成为攻击目标），人们需要获得访问权限以便用别人的钱来获取资源。

但是您非常注重安全，并且需要使用强密码才能访问所有基础设施。 您的 SSH 密码非常强，您必须停下来思考一下输入它是什么。 每次。

现在来看看本世纪最显而易见的说法：强密码并不能防止攻击。 它们只能减轻成功的攻击。 你无法阻止某人发动攻击。 你确实不能。 您只能检测并阻止其成功。

但与此同时，这次袭击也带来了实际的运营成本。 因为您实行智能安全，并且所有失败的尝试都会被记录下来。 每一个。 单身的。 一。

而对于你阻止的每一次失败的尝试，你都在消耗资源。 带宽。 贮存。 计算。  

使用云原生服务增强安全实践

所有主要的云提供商（可能还包括较小的云提供商）都提供基本的网络安全控制，可用于锁定对应用服务基础设施的管理访问。 AWS 安全组 (SG)和Azure 网络安全组 (NSG) 的工作原理与防火墙非常相似 - 它们过滤进入（和离开）实例的流量。 在管理访问的情况下，这可能是您的安全工具箱中的一个重要工具。 通过锁定仅已知 IP 地址（或指定范围）的访问，您可以显著减少到达您基础设施的攻击量。 这可以防止过度消耗计算、带宽和存储，从而降低成本。

这一原则与鼓励在云中使用 Web应用防火墙作为应用程序保护和最佳操作实践的原则相同。 其目的是为了在攻击消耗过多资源之前阻止它。  即使该攻击失败，事实是这些尝试很可能足以强制自动扩展事件，从而给企业造成经济损失或破坏合法用户的可用性。 这两种结果都不是理想的。

一般来说，你越接近攻击源头就能阻止攻击，你就会越安全，企业的成本也会越低。

増强。 不要替代。

在安全实践中使用云原生服务的关键是“增强”。 使用强 SSH 密码是好的。 将其与强大的访问控制相结合效果更好。 但千万不要为了安全组而放弃强密码实践。 两者结合使用，以确保安全并限制在云中开展业务的成本。