从五个方面入手，保障微服务应用安全
|
方案一优点是实现简单，缺点是安全级别略低，常见的企业架构中，网关和业务系统会是不同团队甚至不同的厂商负责开发维护，内部令牌共享给了其他团队负责的网关，存在一定的风险。方案二相比方案一略复杂一点，安全性更高，系统内互通用内部令牌，系统和网关认证使用了网关提供的安全令牌检查方式。两种方案可根据实际需求选择。 2.访问授权 通过认证的API客户端能够访问网关开发的所有API吗?通过认证的用户能够调用所有API吗?通过认证的用户允许调用修改订单的接口，那么他能修改所有人的订单吗? 很显然绝大多数场景下上述三个问题答案都是"不能"。在绝大多数业务场景中除了对访问者的身份认证之外，我们还需要再进一步控制权限。 1. API客户端访问网关接口时，网关需进行API权限控制 如果访问者是API客户端时，API调用的权限需由网关进行控制。建议采用先订阅再访问的授权模式，网关应该仅允许API客户端访问其订阅过的API 。具体实现方法就是绝大多数网关都会提供的基于API Key控制API访问的方式。 需要注意的是，仅使用API key的访问控制是不够的。API Key是在网关订阅API时生成的一串唯一编号，并不具备识别客户端身份的能力。就好比以前买火车票是不实名的，谁拿到火车票，都可以乘坐对应车次。火车票实名制之后，首先需要核验身份证，核验通过后才能购票乘车。如果证票不符，则不允许乘车。 将客户端认证和API Key配合进行访问认证和权限校验才是个更安全的方案。  API权限控制 上图为访问令牌结合API Key的认证鉴权示意图，说明如下：
2. 用户访问应用功能时需要进行权限控制 用户访问的功能权限或数据权限不要交给网关管控，原因是网关仅能支持API Path授权，而实际需要控制的用户权限有很多，如菜单、API、数据等。如果由网关控制用户权限，管少了不满足需求，管多了就要耦合太多应用数据。 因此推荐用户权限由业务系统自行管理维护和控制。每个业务系统内部如果需要控制用户权限，可以建设一个基础权限框架，负责管理权限数据，并提供访问请求拦截和权限检查的SDK给其他应用。 也有部分企业权限管理要求较高，将系统内部的基础权限框架抽取为独立的权限管理服务，由独立团队维护该服务，采用分布式部署+权限缓存的方式保障性能。这样做的好处是权限模型统一、容易对权限变更进行审批控制和审计。缺点是跨团队交互，变更流程复杂。 关于权限管理，是业务系统自治或是集中管控，根据企业自身的需求特点决定即可。 3.通信安全 通信安全的方案就是基于传输过程加密的方式，常见的选择就是使用Https协议通信。 微服务架构体系中，逻辑层面上外部请求接入都是通过网关作为入口，网关作为内外网的分界，实际部署上，网关本身也是多实例分布式的高可用部署形态，前面架设有一个负载均衡F5或nginx，用来对外提供Https协议接入和路由转发，而网关内部就是企业内网，默认是可信任的，内网的系统之间的通信会采用更轻量级的HTTP协议。此方案中微服务换成SOA，把网关换成ESB，就是传统的SOA架构中的安全通信方案，本质上没有区别。 示意图如下：  内外网通信协议 为什么用了https就能保证通信安全呢?https是http+ssl，采用密码学手段对通信报文做了加密，使得报文无法被篡改，做到了安全传输，从而保障了通信安全。关于https原理和负载均衡器证书配置相关资料网络上有很多，请大家即用即查。 4.代码安全 敏感配置加密：上述各种服务安全场景和方案聊了那么多，大家发现保存好令牌、密钥、密码是一切安全的前提。这些东西千万不能外泄。要保证密码不泄露的办法就是做好敏感数据保密，技术手段上则要求存储密码、凭证的地方(配置文件和数据库表)需要加密存储。如：配置文件中的数据库口令、数据表中存放的密码数据等 （编辑：温州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
