一、引言

与当前正在使用的任何其他技术或方法一样，微服务也有其自己的一套缺陷和问题。尽管如此，微服务架构的采用率不断增加，预计到2028年将达到1718.2亿美元。

然而，尽管团队使用微服务，但确保这些微服务的安全性仍然被视为事后事项。 这可能导致应用程序中的许多安全问题，甚至可能使用户数据面临风险，甚至导致应用程序停机。因此，让我们看看在2024年保护微服务方法！

二、微服务架构的常见威胁是什么？

在深入研究保护微服务之前，了解可能使您基于微服务的应用程序面临风险的威胁是很重要的。

1. 滥用有缺陷的身份验证和授权

攻击者获取对基于微服务的应用程序的访问权限的主要原因是身份验证和访问策略的配置错误。这些策略和机制的配置错误将是灾难性的，因为它可能暴露敏感信息，甚至让攻击者通过执行远程代码来获得对系统的访问权限。

2. 基于API的攻击

在微服务架构中，API安全性的重要性是毫无争议的，因为每个组件都与API相互连接；此外，当OWASP提出其自己的十大最常见问题清单时，您就知道这个方面有多重要。

攻击者通常通过身份验证和有效载荷处理配置错误来利用API端点，通过操纵有效载荷绕过可能已经设置的任何验证。

3. DDoS和DoS攻击

在适当的控制措施缺失的情况下，没有人免疫拒绝服务攻击。

这是我们必须接受的现实，因为任何人都可以轻松获取提供DDoS服务的服务，价格低至每天$30，具体取决于攻击的规模和持续时间。 当您的基于微服务的应用程序可能能够扩展以抵抗DDoS或DoS攻击以保持其服务运行时；

真正的问题是以何种代价？ 在DDoS或DoS攻击期间，微服务的扩展将对成本产生重大影响，因为即使使用诸如AWS Lambda等无服务器解决方案，计算资源也不便宜。

三、保护微服务的策略

既然我们已经确认了即使微服务也会受到攻击，并且这只是一个“何时”的问题。

让我们看看一些策略，我们可以实施以减少攻击可能带来的影响。

1. 安全设计

顾名思义，安全设计或左移安全性意味着安全性必须从设计阶段考虑，并必须在整个开发生命周期中应用。这可能不是微服务特有的概念，但由于它带来的显著好处，必须遵循此概念。

如果您目前正在实践DevSecOps，那么您很可能正在遵循左移或安全设计原则，在这里您在每个开发阶段都考虑安全性。这不仅有助于在非常早期阶段识别威胁和安全问题，而且由于整个体系结构可以被设计为以最小的努力解决安全问题，因此还可以减少修复这些问题所需的工作量。

2. 零信任架构

这些架构设计对网络安全领域并不陌生，多年来我们已经看到其采用率稳步增长。这将我们多年来一直在使用的多种安全技术组合成一个强大的设计，能够减少甚至是最复杂应用程序的攻击面。

零信任基于一些共同的关键原则，这些原则共同发挥作用，形成了最安全的应用程序部署；其中一些原则是：

最小特权

持续监控和验证

设备访问控制

微分割

由于微服务独立于其他服务，这种方法非常适合确保即使一个微服务被攻破，攻击者也无法危及应用程序的其余部分。

3. 访问控制（IAM）

安全性的最重要方面之一是访问控制，甚至是零信任架构背后的关键原则之一，该架构要求仅为任何给定实体分配最小特权。

将有多个用户，如果没有多个账户用于允许每个微服务与其他微服务或其他服务（如数据库）进行通信。在这些部署中，必须分配最小数量的访问权限，以允许微服务执行定义的任务。

此外，如果您使用诸如AWS Lambda之类的解决方案，则建议使用短寿命的凭证，例如“角色”，这样用户帐户必须假定角色才能执行任务，没有此角色将没有任何本机权限。

4. 威胁建模

您可能知道您的微服务在应用程序构建到小规模时做什么，但是一旦您的应用程序增长并且您的微服务数量失控增长时，所有这些都会发生变化！很快，您将不知道做什么以及理解的任何意义都开始消失。

一旦发生这种情况，您将很可能在架构和微服务内留下未计划的空白，这些空白允许攻击者进入。

这就是威胁建模派上用场的地方，它允许考虑系统的数据流、服务间通信和外部威胁等多个方面。

威胁建模使架构师能够可视化和识别体系结构中存在的各种问题，并确保在构建应用程序之前修复了已识别的风险，从而节省了在开发和测试阶段所花费的大量金钱和时间。

5. 漏洞管理

我们已经确认微服务运行在不同的语言上，并在单个微服务中有多个组件来启用其功能。

漏洞管理是一种被忽视的方法，允许工程师和管理员识别和修补这些不同组件，无论是容器基础架构、代码还是甚至是使用的第三方库。

正确的漏洞和补丁管理不仅能够实现安全应用程序，而且能够实现严格的合规性。