构建安全微服务的六大挑战和一些最佳实践。
译自How To Secure Microservices in a Multicloud Architecture，作者 Manas Chowdhury。
微服务架构允许每个服务独立扩展，使其能够灵活地扩展而不会影响整个系统。
然而，虽然微服务提高了应用程序的质量和灵活性，但也带来了独特的风险。因此，保护每个单独的微服务对于保护整个架构至关重要。
微服务架构中的安全挑战
保护微服务架构由于其分布式性质以及管理多个独立服务的复杂性，因此特别具有挑战性。让我们看一下构建安全微服务的六个主要挑战以及一些最佳实践。
1. 更大、更复杂的攻击面
在单体方法中，只有一个大型代码库和一个数据库，因此安全性主要集中化。您可以通过一个单一网关管理访问、身份验证和安全协议，使其更易于处理。
但是，在微服务架构中，您将其分解为更小的 Spring Boot 应用程序。现在每个服务都单独运行，通过 API 进行通信，并管理自己的数据和资源。
每个微服务都有自己的入口点、单独的身份验证和安全控制。现在每个微服务都需要安全措施。
攻击者如果发现一个服务的 API 中存在漏洞，可能会获得对其他服务的未经授权的访问权限，突出了保护这种分布式系统的挑战。
2. DevOps 实施
假设您是一个在线教育管理平台，并且有一个用于用户管理的微服务，一个用于课程的微服务，另一个用于支付的微服务。
微服务提供了更快的开发和部署的灵活性，因为它们由不同的团队管理。但这也有缺点。
由于服务是单独且快速部署的，因此存在为了满足紧迫的期限而跳过适当的安全测试的风险。
例如，支付服务可能会在没有进行彻底的安全检查的情况下启动，这使得它在投入生产后容易受到攻击。这会创建一个环境，在该环境中，漏洞发现得太晚，导致更高的安全风险。
3. 微服务访问控制
让我们考虑一个电子商务平台，它被拆分为各种微服务——库存、客户和订单处理。在这些服务中实施访问控制并非易事。
安全专业人员必须确保只有授权用户才能访问系统的特定部分，例如客户查看其订单历史记录或库存管理员更新库存水平。
这需要在API 网关处对外部用户严格执行访问控制。微服务之间的通信也需要根据零信任原则进行保护，这意味着任何服务都不应该自动信任另一个服务。
如果存在策略更改，例如限制管理员访问权限，您不能像在单体中那样在一个地方进行更新。相反，每个微服务都需要单独更新，这使得流程变得复杂。
您可以对五个或十个微服务进行操作，但想象一下，如果您有数千个微服务。在整个应用程序中维护一致的访问控制可能是一项艰巨的任务。
4. 微服务中的容错性
在传统架构中，当一个组件出现故障时，由于系统作为一个整体运行，因此更容易查明和解决问题。
微服务架构涉及许多相互连接的较小服务，如下所示。
如果一个服务出现故障，它可能会级联成更大的问题。
例如，如果 Microservice5 出现停机，其他服务（无论直接或间接依赖于它）也可能出现故障，导致整个系统出现广泛的中断。
因此，团队需要专注于创建弹性服务并有效地处理故障。这涉及断路器或重试机制。
在故障期间保持整个系统稳定需要持续监控和主动措施。因此，您需要一个集中式的微服务管理和安全平台来管理数百个服务的容错性。
5. 微服务中的缓存
考虑一个大型社交媒体平台，它使用微服务进行个人资料管理、消息传递和媒体上传。为了提高性能，缓存存储了经常请求的数据，例如用户个人资料或消息历史记录，减少了对微服务的重复请求。随着平台规模的扩大，缓存变得更加复杂。数千名用户同时更新个人资料和发送消息，给缓存失效带来了挑战。
此外，在微服务之间维护缓存一致性变得至关重要，尤其是在多个服务依赖于相同数据的情况下。
例如，个人资料服务可能会存储缓存的用户资料信息，但如果消息服务也依赖于此数据，则这两个服务都需要在缓存更新时进行协调。
微服务安全最佳实践
以下最佳实践可以帮助您将安全性设计到微服务应用程序中，并解决应用程序安全挑战。
安全容器
容器在微服务中发挥着至关重要的作用。由于它们的容器是基于镜像的，如果未正确扫描，它们会存在潜在的安全风险。因此，通过关注容器级别的安全性，企业可以防止潜在的漏洞蔓延到整个系统。
为了确保您的容器安全：
使用扫描工具确保镜像不包含漏洞，并部署经过验证的容器。
实施运行时安全来监控容器行为，加强保护。
实施集中式 API 网关
亚马逊 CTOWerner Vogels曾在 2014 年提到，“API 是数字世界的粘合剂”。
快进十年，这句话仍然成立。API 网关充当中央枢纽，管理外部用户和内部微服务之间的请求。它不仅简化了微服务架构，还执行了必要的安全措施，例如身份验证、授权和流量监控。
微服务通常跨越各种网络运行，使用不同的技术和协议。保护它们需要一个 API 网关，一个所有客户端连接的单一入口点。网关可以处理身份验证、授权和过滤请求，确保对敏感资源的受控访问。
优先考虑微服务隔离
在微服务架构中，每个服务独立运行，允许更新、维护和修改，而不会影响其他服务。
这种隔离应该扩展到基础设施层，包括数据库，确保任何服务都无法访问其他服务的數據。完全隔离可以防止攻击者在系统内横向移动。
保护敏感数据
敏感数据，例如密码或个人信息，绝不应该以明文形式暴露或存储。用户和自动化系统可以轻松访问此信息，使其容易受到威胁。
企业应始终在将敏感信息存储在任何记录中之前将其删除或屏蔽。诸如 TLS/HTTPS 或加密日志之类的做法还不够，因为一种做法侧重于保护传输中的数据，而另一种做法则保护静止数据。因此，最好的方法是完全停止存储敏感信息。
采用零信任安全模型
零信任安全的理念是，默认情况下不信任任何用户或设备，无论是在网络内部还是外部。通过使用零信任模型，企业可以确保每个用户和设备都经过持续的身份验证和授权，无论它们身在何处。
在微服务中，这意味着检查服务之间的每次交互，执行严格的访问控制并记录所有操作。这种方法可以减少攻击的可能性，并降低黑客在网络中移动的风险。
Kubernetes 在微服务安全中的作用
Kubernetes 提供强大的安全功能，旨在保护基于微服务的应用程序。以下是 Kubernetes 保护微服务架构的关键功能：
基于角色的访问控制 (RBAC)：Kubernetes 使用 RBAC 来确保只有授权用户和服务才能访问特定资源，从而执行最小权限原则，降低未经授权访问的风险。
网络策略：Kubernetes 提供对 Pod 通信的细粒度控制，允许您定义哪些服务可以交互。这种隔离有助于防止安全漏洞在集群内蔓延。
安全和合规性：Kubernetes 增强了微服务的安全性，简化了与行业法规的合规性，提供更安全、更具弹性的基础设施。
分层安全方法：Kubernetes 提供针对内部和外部威胁的保护，使其成为安全应用程序部署的关键工具。
结论
微服务不仅提供更高的灵活性和可扩展性，以及更高的成本效益；它们还改变了 DevOps 和开发团队的工作方式。随着微服务采用率的提高，端到端保护微服务的需求也随之增加。
也就是说，为了完全保护这些独立组件，为您的团队配备合适的工具非常重要。AccuKnox提供端到端的无代理安全解决方案，可以无缝集成到您的应用程序中。这使您的团队能够专注于构建可扩展的系统，而无需开发内部安全措施。
