建议|从五个方面入手，以确保微服务应用程序的安全性(2)

网关直接​​验证令牌

成功验证客户端后，使用JWT令牌在网关上调用服务网关，以直接解密JWT令牌本身以验证令牌检查是否合法，然后将请求路由到服务提供商应用程序. 收到请求后，如果还需要更多授权信息，则可以转到授权管理服务根据令牌获取授权信息（可选步骤，必要时添加）.

在以上两种方案中，方案1的令牌是没有业务含义的标识字符串. 网关在每次收到请求时都会进行IAM身份验证，这给IAM身份验证服务的性能带来了巨大压力. 在第二种情况下，IAM发行的令牌包含部分客户端或用户信息，并使用JWT加密. IAM向负责身份验证的网关提供身份验证方法或SDK. 对于IAM，减少了每次令牌认证请求所带来的通信数量，并减轻了对IAM的压力.

建议使用方案二实施令牌检查. 应该注意的是，方案二中的JWT令牌仅包含必要的信息，而没有放置太多的角色授权信息. 当后续功能中需要其他信息时，您可以转到IAM以根据令牌获取信息. 如果令牌中存储了很多权限数据，则后台中的授权数据一旦更改，令牌中的权限数据将与实际的IAM权限不一致，并且只能强制用户注销并再次登录

JWT令牌是防篡改的，但未加密. 如果需要将其存储在浏览器存储中，建议使用JWT + JWE对令牌进行加密. 在令牌中存储少量数据足以避免滥用. 大多数服务器通常会限制Http标头和cookie的长度.

3.2系统的内部应用程序是否通过网关传递？

我的回答是“否”，否则会很麻烦. 通常，网关负责一个独立的团队，并且在团队之间发布API更改和内部联合调试验证是不可行的. 建议您不要通过系统中的网关. 您必须使用网关来访问系统. 为此，应用程序还需要请求源以进行客户端身份验证. 该认证方案不必太复杂. 该应用程序应仅允许可信网关和系统内部应用程序访问其服务，而不允许绕过外部系统请求. 网关直接呼叫. 因此，您需要在网关和系统内部应用程序之间的小区域内建立信任. 有两种常见的解决方案:

第一种解决方案的优点是实现简单，缺点是安全级别稍低. 在常见的企业体系结构中，网关和业务系统将由不同的团队甚至不同的供应商开发和维护. 内部令牌与其他团队的网关共享. ，存在一定风险. 方案二比方案一稍微复杂一点，并且具有更高的安全性. 内部令牌在系统内是相互通用的. 系统和网关身份验证使用网关提供的安全令牌检查方法. 可以根据实际需要选择两个选项.

2. 访问授权

经过认证的API客户端可以访问网关开发的所有API吗？经过身份验证的用户可以调用所有API吗？认证用户可以调用订单修改界面，那么他可以修改每个人的订单吗？

显然，在大多数情况下，上述三个问题的答案为“否”. 在大多数业务场景中，除了访问者的身份验证外，我们还需要进一步控制权限.

1. 当API客户端访问网关接口时，网关需要执行API权限控制

如果访问者是API客户端，则需要由网关控制API调用的权限. 建议访问前采用订阅授权方式. 网关应仅允许API客户端访问其已订阅的API. 具体的实现方法基于大多数网关提供的API密钥控制API访问方法.

请注意，仅使用API​​密钥进行访问控制是不够的. API密钥是网关订阅API时生成的唯一编号，并且不具有标识客户端身份的能力. 就像过去买火车票不是真实的. 任何获得火车票的人都可以乘坐相应的火车. 火车票实名制完成后，首先需要对进行验证，验证通过后才能购买并通过. 如果车票不匹配，则不允许乘车.

结合客户端身份验证和API密钥进行访问身份验证和权限验证是一种更安全的解决方案.

API权限控制

上图是结合了API密钥的访问令牌的身份认证，说明如下:

2. 用户访问应用程序功能时需要权限控制

用户访问的功能或数据权限不应由网关控制，因为网关只能支持API路径授权，并且需要控制许多用户权限，例如菜单，API和数据. 如果用户权限由网关控制，则管理太少不能满足需求，太多的管理将耦合太多的应用程序数据.

因此，建议由业务系统本身来管理，维护和控制用户权限. 如果需要控制每个业务系统中的用户权限，则可以构建一个基本的权限框架，该框架负责管理权限数据，并提供SDK来进行访问请求的拦截和对其他应用程序的权限检查.

一些企业对权限管理有更高的要求. 系统内部的基本权限框架被提取为独立的权限管理服务，该服务由独立的团队维护. 采用分布式部署+权限缓存以确保性能. 这样做的好处是权限模型是统一的，并且易于进行批准控制和权限更改的审核. 缺点是跨团队的交互和复杂的变更过程.

关于权限管理，是业务系统的自主权或集中式管理和控制，可以根据企业自身需求的特征来确定.

3. 通讯安全

通信安全方案基于传输过程的加密方法. 常见的选择是使用Https协议进行通信.

在微服务体系结构系统中，逻辑级别上的外部请求访问是通过网关作为入口，而网关用作内部和外部网络之间的边界. 在实际部署中，网关本身也是多实例分布式高可用性部署形式. 负载平衡F5或nginx用于提供Https协议访问和路由转发，网关的内部是企业内部网，默认情况下受信任. Intranet上系统之间的通信将使用更轻量级的HTTP协议. 在这种方案中，用SOA替换微服务以及用ESB替换网关是传统SOA体系结构中的安全通信方案，并且基本上没有区别.

如下:

内部和外部网络通信协议

为什么使用https来确保通讯安全？ https是http + ssl，它使用加密技术对通信消息进行加密，因此消息不会被篡改，并且可以安全地传输，从而确保了通信的安全性. 网络上有很多有关https原理和负载均衡器证书配置的信息，请立即将其签出.

4. 代码安全性

敏感配置加密: 前面已经讨论了上述各种服务安全方案和解决方案. 每个人都发现保留令牌，密钥和密码是所有安全性的前提. 这些东西一定不能泄漏. 确保密码不泄露的方法是对敏感数据保密，而技术手段要求对密码和凭据（配置文件和表）的存储进行加密. 如: 配置文件中的密码，数据表中存储的密码数据等.

代码质量管理: 建议在开发期间制定代码规范，还可以使用辅助检查和控制工具，例如开源代码质量管理工具Sonar，它可以支持多种编程语言. 并促进与编译和构造工具的集成. 例如，Maven会在代码进入相应分支之前的早期阶段防止一些安全问题，例如SQL注入.

运行时安全扫描: 在测试阶段，您可以使用安全扫描软件（例如AppScan）扫描业务系统的前端和后端功能，以检查系统漏洞并立即进行修复. 尝试降低上网后发生安全事故的风险.

5. 管理审核

在运维管理安全性方面，根据安全性要求，必须得到与安全性相关的管理规范和工具的支持，严格控制和管理系统管理，权限分配和关键数据，并做好运行审核日志记录.

例如，许多安全级别较高的行业或企业，例如军工行业，对业务系统修改和权限管理审核提出了严格的流程规范和功能支持. 例如，典型的三人管理采用三权分立，相互制约的思想，包括系统管理员，安全管理员和安全审核员三个角色. 他们可以看到彼此的信息，并将业务流程划分为不同的部分. 段负责相应的人员，不允许任何人控制全局.

审计工作是非常重要的部分. 任何系统或过程都不是绝对安全的. 关键操作和数据更改的审核日志需要完整记录. 一旦出现问题，就可以通过审核日志对其进行分析和跟踪. 常见内容示例如下:

在上述审核工作中，如果它基于与API相关的审核信息记录（如边界交互式消息数据），则建议基于统一的技术框架执行记录管理. 对于某些内部实现方法，可以使用接口，方法添加注释，以及使用AOP截取记录的解决方案. 在其他情况下，可以根据实际需要设计审计数据存储方案.

参考返回搜狐，查看更多

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/tongxinshuyu/article-189144-2.html