架构相关（74）
今天给大家带来的是数人云工程师文权在线上的分享实录。从传统单体应用架构到微服务架构，安全问题一直是人们关注的重点，我们来看看文权他在微服务访问安全设计方案上的探索与实践。
数人云资深售前工程师，致力于帮助客户进行实施部署，提供最适合的解决方案；之前在惠普工作5年，主要负责Openstack、Docker等云计算方面的项目开发；开源技术拥护者，热衷于IT技术交流和分享。
我们首先从传统单体应用架构下的访问安全设计说起，然后，分析下现代微服务架构下，访问安全涉及的原则，接着，来看下目前常用的几种，微服务架构下的访问安全设计方案。最后，重点看下Spring Cloud微服务架构下，是如何解决访问安全这个问题的。
一、传统单体应用的访问安全设计
上面的示意图展示了单体应用的访问逻辑。用户通过客户端发出http或者https请求，经过负载均衡后，单体应用收到请求。接着经过auth层，进行身份验证和权限批准，这里，一般会有跟后端数据库的交互。
通过后，将请求分发到对应的功能逻辑层中去。完成相关操作后，返回结果给客户端。
传统单体应用的访问安全设计——原则
从以上分析可以看到，传统单体应用的访问安全设计原则为：
第二，用户的操作请求都在后端单个进程中执行完成，完全依赖后端调用方法的可靠性。一旦出错，应用是无法再次重复请求。
传统单体应用的访问安全设计——优势和注意点
小结:&传统单体应用由于设计相对简单单一，暴露给外界的入口相对较少，从而具有被攻击并造成危害性的可能小的优势。
也正是由于单体应用简单单一的特点，需要注意相关问题：
二、微服务架构下，访问安全设计原则
先来看下这张典型的微服务设计架构图，如图所示，有以下几点特征：
从上面的特征分析来看，想要给出一份访问安全设计的原则说明，就要看看微服务架构下，访问安全有哪些痛点，以下罗列了几点：
根据实际情况，还有一些其他痛点，这里不再一一赘述，而这些痛点，就形成了我们在为微服务架构设计访问安全的原则。
三、微服务架构下，常用的访问安全设计方案
这里列出4种，首先简单介绍下，然后一一叙述。
第一种，使用HTTP Basic Auth协议，加上独立的Auth数据库。
第二种，也是使用HTTP Basic Auth协议，跟第一种不同的是，使用集中式的Auth数据库
第三种，API Tokens协议，这种大家应该比较熟悉，很多公有服务（比如Github、Twitter等）的API都是用这种方式。
第四种，SAML，即Security Assertion Markup Language，翻译过来，是『安全声明标记语言』，它是基于XML的一种协议，企业内使用得较多。
下面一一做介绍。
1. 微服务常用访问安全设计方案——Basic Auth + Independent Auth DB
第一种，如上示意图所示，使用Basic Auth协议，配合每个服务自己都拥有存储Credential敏感数据的数据库（或者其他持久化仓库）。
简单介绍下Basic Auth协议，它是在用户的请求中添加一个Authorization消息头，这个消息头的值是一个固定格式：
Basic base64encode(username+“:”+password)
完整的消息头列子为：
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Basic Auth协议基本上被所有流行的网页浏览器都支持。
这种方案的特点：
小结下使用这种方案的好处：
同时，小结下使用这种方案需要注意的地方：
2. 微服务常用访问安全设计方案——Basic Auth + Central Auth DB
第二种，如上示意图所示，使用Basic Auth协议，与第一种方案相比，每个服务共用有同一个Auth DB。
第二种方案的特点和第一种很相似：
小结下使用第二种方案的好处：
除了拥有第一种方案相似的好处外，由于共用了同一个持久化仓库来管理用户信息，简化了原来独立管理的机制。
同时，小结下使用这种方案需要注意的地方：
3. 微服务常用访问安全设计方案——API Tokens
第三种，如上示意图所示，使用Token Based协议来对用户请求进行操作鉴权。
简单介绍下最基本的Token Based的交互方式：
业界常用的OAuth就是基于Token Based这套逻辑，实现的互联网级的鉴权机制。
第三种方案的特点明显：
小结下使用第三种方案的好处：
由于使用了token来鉴权，业务服务不会看到用户的敏感信息。
同时，小结下使用这种方案需要注意的地方：
Auth服务可能需要处理大量的生产token的操作。
4. 微服务常用访问安全设计方案——SAML
第四种，如上示意图所示，使用SAML协议来对用户请求进行操作鉴权。它是一个基于XML的标准，用于在不同的安全域(security domain)之间交换认证和授权数据。
在SAML标准定义了身份提供者(identity provider)和服务提供者(service provider)，这两者构成了前面所说的不同的安全域。
以上图Google提供的Apps SSO的机制，简单介绍下SAML鉴权的交互方式：
第四种方案的特点有：
小结下使用第四种方案的好处：标准的可信访问模型
同时，小结下使用这种方案需要注意的地方：
四、Spring Cloud Security解决方案
Spring Cloud Security特点有：
下面简单介绍下UAA，事实上，它是由CloudFoundry发起的，也是CloudFoundry平台的身份管理服务（
主要功能是基于OAuth2，当用户访问客户端应用时，生成并发放token给目标客户端。
UAA认证服务包含如下几个方面的内容：
如图所示，这是一个简单的基于Spring Cloud微服务架构的例子，它的主要组件有：
这里主要讲Auth组件和Account组件是如何基于UAA服务进行认证和授权。
图一为Auth组件业务代码中定义了不同客户端的认证类型和认证范围，其中
图一为浏览器打开应用入口后，输入用户名和密码后，发出的认证请求：
图二为图一发出认证请求的返回结果：
Access_token为有效认证token，将来被其他请求使用
图三为发出获取当前用户的信息的请求：
在请求里的Authorization的值为图二中获得的access_token
图一为Account组件在Config组件（配置中心）定义的OAuth2协议下获取token的方式，这里定义了：
图二为Accout组件业务代码中定义了需要使用Auth组件进行事先鉴权的方法：
最后小结下Spring Cloud Security的特点：
&&相关文章推荐
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：94194次
积分：2007
积分：2007
排名：第17932名
原创：13篇
转载：594篇
评论：11条
(2)(32)(36)(12)(29)(43)(93)(39)(48)(44)(24)(24)(13)(15)(14)(39)(75)(25)& & 系列文章目录：
身份认证和授权
& & & 1.单点登录（SSO）
& & & 当主体试图访问一个资源，他会被定向到一个身份提供者那里进行身份验证，身份提供者验明正向后会发消息给服务提供者，让服务提供者来决定是否允许它访问资源。
& & & SAML和OpenID Connect/OAuth2.0是企业领域中占据统治地位的单点解决方案。
& & & 2.单点登录网关
& & & 现在问题来了，多个微服务是不是也要单独地与单点登录系统交互，显然这样是不合理的，这意味着大量的重复工作。我们可以使用单点登录网关来帮助我们完成这一工作，在使用者通过单点登录网关后，可以将用户名和角色等用户信息放入HTTP头信息，传递给下游服务。
& & & 同时，网关应该提供的是粗粒度的身份验证，而不应该过于具体，如我们可以使用它来完成对是否登录、取角色、是否访问某个服务这类的验证，而不应该具体到“是拥有view.html页面50条还是100条数据的导出权限”。
网络传输和服务间传输的身份验证和授权
& & & 从浏览器中输入用户和密码，到真正的服务提供者，这中间是一个漫长的过程，通过HTTP有很高的风险，因为用户和密码并没有以安全的方式发送，任何中间方都可以看到HTTP头的信息并读取里面的数据，因此HTTP基本身份验证通常应该使用HTTPS进行通信。
& & & 使用HTTPS时，浏览器到服务器的通信将获得强有力的保证，但是服务器端要管理的SSL证书，这有一个额外的行政和运营负担，同时SSL上的流量不能被反向代码服务器（如Varnish或Squid）所缓存，这意味着，如果你需要缓存信息，就不得不在服务端或浏览器内部实现，你可以在负载均衡中把HTTPS的请求转成HTTP请求，然后在负载均衡之后就可以使用缓存了。
& & & 如果你已经在使用SAML或OpenID Connect作为身份验证和授权方案，你可以在服务之间的交互中也使用它们。你可以针对服务也创建一些凭证，如果凭证被泄露，只需要撤销有限的受影响的凭证即可。（这里我感觉像配置Git的SSH PublicKey和PrivateKey一样。）
& & & 同时我们也可以使用TLS（Transport Layer Security安全传输协议），在这里，每个客户端都安装了一个X.509证书，用于客户端和服务器端之间建立通信链路，服务器端可以验证客户端证书的真实性。当你特别关注所发数据的敏感性，或无法控制发送数据所使用的网络时，才考虑使用这种技术。
& & & 另一种方式，我们还可以使用HTTP之上的HMAC（Hash-based Message Authentication Code基于哈希的消息码）对请求进行签名，它是OAuth规范的一部分。使用HMAC，请求主体和私有密钥一起被哈希处理，生成的哈希值随请求一起发送，服务器使用请求主体和自己的私钥副本重建哈希值，如果匹配则接受请求。这样做的好处是，如果一个中间人更改了请求，那么哈希值会不匹配，服务器便知道该请求被篡改过，且私钥永远不会随请求发送，因此不会存在传输过程中泄露的问题，而且通信更容易被缓存，生成哈希的开销要低于处理HTTPS的开销。
& & & HMAC也存在缺点，首先客户端和服务器端需要一个共享的、以某种方式交流的密钥，其次这是一个模式而不是标准，可以参看AWS的S3 API，最后请求中所带的其他数据，对网络嗅探来说仍然是可见的。
& & & 另外，在大部分的组织内部，服务间的通信被认为是安全的，而没有采取任何防备。我们也可以采用上面的方式对组织内部的通信进行安全加固。
提供出的公共API安全：API密钥
& & & API密钥允许服务识别出是谁进行调用，然后对他们能做的进行限制，限制通常不仅限于对特定资源的访问，还可以扩展到类似于针对特定的调用者限速，以保护其他人服务调用的质量。
& & & 通常情况下，我们会在系统中集中管理API密钥，API网关（API Gateway）模型在这个领域很受欢迎。
一个问题：代理人欺骗
& & & 当我登录了系统后，我再通过尝试，看是否能够获得其他客户或者订单的信息，它们原来不属于我，但由于接口只是提供order/12345之类的规则，并没有验证信息，万一这样成功了呢？那么我就可以作为一个假的代理人去欺骗系统的数据。
& & & 解决这个问题的方法是在应用程序中加入验证，使这个人只能查询自己的订单，也可以在请求中加入原始的凭证。
静态数据的安全
& & & 有些组织中，服务器中的静态数据是完全没有加密的，这有可能会生成安全漏洞。有一些产品已经提供了加密算法，比如SqlServer和Oracle就提供了可以加密表的某一列值的功能，同时我们可以采用已知的加密算法（不要自己去尝试写一套加密算法）对静态数据进行加密，同时对备份也进行加密。
& & & 我们应该从浏览器到应用程序服务器再到数据库都存在安全防御措施，防火墙（设置允许的入口和出口）、日志（不要将敏感的数据写到日志中）、入侵检测系统（IDS，可以监控网络或主机，当发现可疑行为时报告问题）、入侵预防系统（IPS，监控可疑行为并阻止它的发生）、网络隔离（我们可以把服务放进不同的网段）、操作系统（自动定时打补丁、设置OS的安全策略等）。
& & & 先看一下不安全的架构
& & &&在这里，所有的请求都使用普通的HTTP传输，但我们希望在传输的过程中数据不要被篡改；同时我们要限制公共API的使用范围和使用频率；另外我们希望第三方系统与我们的交互是受保护的，而避免被竞争对手所获取；我们希望客户服务中的数据是完全加密的，这样即使发生拖库的情况，黑客也不能获取相应的数据。
& & & 基于这些设定，我们提供了一种安全的架构，如下所示：
一些可供借鉴的法则和实践
& & & &OWASP十大列表和SP安全测试框架
& & & 微软安全开发生命周期（）
& & & 《微服务设计》（Sam Newman 著 / 崔力强 张骏 译）
阅读(...) 评论()