发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 大数据 扩展性 并发编程 事件驱动 分布式 SOA

几种微服务安全机制

         
2016-12-08 14:06
赞助商链接

在微服务架构中,一组细粒度微服务通过相互交互以构建应用或实现业务功能。每个细粒度的服务是实现单个功能或通过网络访问实现几个相关功能。这导致被攻击机会增加,尤其显得微服务架构的安全性非常重要。

保护微服务安全的一些常见技术如下:
1.边界安全。
2.用户名和密码。
3.双向SSL。
4.OAuth 2.0和OpenID Connect。
5.自包含的JWT令牌。

让我们深入了解每一个利弊。

边界安全
执行边界安全是保护微服务的一种非常传统的方法。 这意味着单个微服务不安全;访问微服务的层必须是受信任的。

对Web应用程序的访问是安全的,并且Web应用程序自由地调用微服务层。各个微服务彼此自由交互。

有一些与微服务相关的特性和要求使得边际的安全性不足。

1.由于各种原因,应在每个服务执行认证或授权。
2.每个细粒度的服务是一个小团队的责任。 这可能意味着保证数据的安全性也是他们的责任。

用户名和密码
在这种方法中,每个微服务将使用BasicAuthentication进行保护。 有几种方法来实现这一点。

1.最终用户凭据。 在这种情况下,每个微服务需要最终用户的用户名和密码来执行认证或授权。 当应用程序调用微服务或微服务调用另一个微服务时,它必须传递最终用户的用户名和密码。 这种方法有很多安全隐患。

2.每个微服务都应该有权访问最终用户凭证存储。

3.用户名和密码必须由每个服务被存储在存储器或会话,以便当一个微服务正在呼叫另一个微服务时使用。

4.受信任的子系统凭据。 用户名和密码用于受信任的子系统(例如,系统中的每个实体都有一个凭据集)。这种方法的缺点是最终用户是未知的,因此不能执行授权。如果一个实体更新凭证,会发生什么? 如果凭据保存在文件中,则应在每个实例中更新此文件。

双向SSL
在此安全机制中,系统中的每个实体都有一个证书(公共和私有)密钥对,并使用双向SSL彼此通信。在正常的SSL场景中,服务器由客户端进行身份验证,但在双向SSL中,双方都彼此进行身份验证。 与最终用户用户名和密码方法相比,这是一个更好的方法,因为风险很小。

然而,这种方法的一些缺点在下面给出。

1.每个微服务都需要一个证书,所以当更新证书时,更新需要在所有实例中进行。
2.最终用户不能在此模式下授权或认证。
3.它具有与可信子系统模式类似的优点和缺点。

OAuth 2.0和OpenID Connect
微服务可以使用OAuth 2.0以及OpenID连接来验证和授权用户。有一个IdP提供方向请求方提供OAuth 2.0令牌。 例如,应用程序获得OAuth 2.0访问令牌,并且访问此令牌用于调用MSA中的所有服务。 它也可以用于微服务之间的通信。 使用短寿命访问,令牌简化并提高整个系统的安全性。 使用OpenID连接,可以检索最终用户的身份,允许微服务执行授权本身。

然而,这种方法的缺点是对IdP额外方的调用。

自包含JWT令牌
自包含JWT令牌是在令牌本身内具有授权信息,即令牌由发行者签名,并且所有各方可以验证令牌的有效性。 这意味着微服务不需要调用外部方来验证访问令牌并获得JWT令牌。消除了验证接入令牌并获得承载令牌的附加呼叫。 它具有OAuth2.0的所有优点,但不具有短寿命标记的缺点。

这是一种最合适的微服务安全方式。

Securing Microservices: A Brief Look at Different

2
微服务      权限     

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系管理员 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com