原文:Securing microservices
作者:SERGIUOLTEAN
翻译:无阻我飞扬

摘要:如何保护微服务,确保微服务的安全,作者从保护应用程序安全和保护容器的安全两个方面进行了阐述,以下是译文

保护微服务

实现一个微服务很难。部署一个微服务应用程序复杂性也很高。保护微服务的安全就更难更复杂。从哪里开始呢?脑海中首先出现的一些词是身份验证和授权、防火墙、授信、会话、令牌。我们需要保护应用程序的安全,也需要保护容器的安全。

保护应用程序

一种方法是构建一个单点登录(SSO)网关,像普通的网关一样,它位于应用程序的前端,但需要考虑到其与SSO服务器的握手,并执行URL重定向操作。可以用http报文头传送授权和认证信息给服务。但是除非使用https,否则这样做是不安全的。但是我们知道https有证书,维护多个微服务的证书可能会成为问题,尤其是需要补发或撤销这些证书的时候,复杂性将进一步增加,我们尽量避免这种情况。

另一种方法是用HMAC(基于哈希的消息代码)。这个请求的主体带有哈希私钥,结果是随着请求发送的。然后,服务器通过使用其私钥和请求主体的副本重新创建哈希,并将其与接收到的哈希进行比较。如果一切都匹配,那就意味着消息没有被篡改,请求可以通过。这种模式由JWT(Json Web Tokens)实现。但是,事实上网络侦听器仍然可以看到数据。

Twitter,Google等使用API密钥。使用API密钥,服务可以识别谁在调用,并可以对其设置限制。密钥是成对的(公钥和私钥),它们必须集中管理。

假定一切都准备就绪了,但是还是有一个问题,如何确保用户无法访问其他用户的数据呢?那就需要做更多的限制,可以通过限定用户只能访问他自己的数据来保护我们的服务,但是将导致在许多地方产生大量的样板代码。不幸的是,没有更好的办法。微服务意味着复杂性和一些重复预期会被减少。

还是没有解决嗅探器(sniffer,也叫数据抓包软件)的问题。怎样才能确保sniffer看不到数据呢。答案是加密。先加密,然后根据需要进行解密。这就是微服务复杂系统的另一个组件:密钥服务。

有很多库可以用,最好的选择是使用成熟的库,如OAuth或SAML。

服务可以有状态参数。为网关中初始化的所有服务保持一个全局会话,并将其传播到所有其它服务。会话可以从像KeyCloak这样的中央认证和授权服务器(SSO)获得。

我们更希望服务没有状态参数。这意味着需要将状态从服务器转移到客户端。Json的 Web令牌(JWT)非常符合这种需求。这是一种在双方之间转移声明的安全方式。基本上它的一个json作为Json Web签名(JWS)的主体或Json Web加密(JWE)的明文传递。声明可以进行数字签名,并包含发行者,用户的身份,到期时间,还可以包含自定义属性。

举一个例子,流程看起来如下图:

这里写图片描述

客户端应用程序将与UAA(用户认证和授权)服务器进行交互。它为包含一个JWT令牌的重定向URL交换其证书。令牌将提交到网关,在UAA服务器进行验证。如果一切正常,它会将该JWT令牌转发到所请求的服务,将会解码它并授予其对所请求资源的访问权限。

保护容器

现在已经知道如何保护应用程序了,是时候关注容器的安全了。Docker是一个广泛使用的容器。可以做些什么来保护它们呢?

答案是深度防御。这意味着需要防火墙;这意味着需要小心记录在日志中的信息(被攻击后,日志有助于快速恢复系统);这意味着需要监视集群的可疑行为(入侵检测系统和入侵防御系统);这意味着需要将服务分开并将它们放在不同的位置(虚拟私有云),并创建一组规则,确保它们仍然能够相互通信;这意味着保持操作系统更新(特别是安全更新)。

Aaron Grattafiori在Docker Con 2016年的演讲中谈到三个原则:

  • 最小权限原则,这意味着不以root身份运行应用程序
  • 最小意外原则
  • 最小访问原则,这意味着每个模块只能访问与其相关的数据

这里有篇文章有更多的相关细节。假设已经遵循了上述三原则,想到的下一个问题是:使用的Docker图像安全吗?怎么知道它们没有包含恶意代码呢?幸运的是,在Docker 1.8中引入了Docker Content Trust ,与此同时,Docker图像的发布者在将其推送到注册表之前进行了验证。

保护Docker安全的一个有用的工具是Calico。每个Docker网络都有Calico配置文件,必须设置规则和策略以控制流量。更多相关内容看这里

现在你应该有足够的信息来启动你的微服务安全保护了。

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐