微服务 - 访问&安全理解

时间:2018-03-18 21:17:10

标签: security external microservices internal

我今天要来,因为我正在进入POC的MicroServices架构逻辑。问题是我不确定完全理解如何管理这些服务的安全性的逻辑。

问题是,我希望我的应用程序的一部分可以在没有连接的情况下使用,因此任何人都可以调用某些服务,让A用于该情况。但是,我希望只有在用户连接时才调用某些服务,在这种情况下使用B.

所以,这意味着我的客户端有一个API(C)可以访问A& B其中B只能通过C访问,不像A(可以从任何地方通过任何HTTP请求访问)。

关于这一点,我不确定理解MicroServices架构之间应用的安全性的逻辑。事实上,我看到了几篇关于它的文章和几个堆栈溢出交换,主要是:

  • DMZ逻辑
  • 白名单IP访问
  • 内部服务&外部服务

那么,最后最好的方法是什么?因为使用白名单IP访问,例如,意味着我的数据库应该通过API(D.A.L.逻辑)访问,我想知道它是否是最好的方法。如果我理解“外部”& “内部”逻辑,这意味着某些服务是公开的而其他服务不是?如果是这样,它是如何组织的,它是如何在底部工作的?

感谢您提供任何示例或解释,请随时向我提出任何额外的详细信息。

提前感谢!

1 个答案:

答案 0 :(得分:1)

问题非常广泛,因为身份验证和授权本身就是一个很大的主题。

我会尽量在这里保持答案。如果您有时间和资源,请查看使用OAuth。它们是提供身份验证和访问REST API的行业标准方法。

您可以定义不同的访问模式,并在用户登录时将其与OAuth关联。身份验证可以是单独的服务,它只处理用户具有哪些权限的情况。这里不像服务特定的那样更好,例如用户A可以访问API B和C.而不是功能驱动,如用户A是管理员,用户B是特权用户,用户C是具有访问权限的特定业务用户付款等等。

现在您已实施OAuth,并且可以将用户与其访问控制相关联,请将这些标题作为标题传递给您的实际微服务。在您的API中,只需检查用户是否具有正确的令牌并访问并继续。如果没有,请使用422错误。哎呀,如果您使用好的库,您甚至可以在API代码之外进行(使用过滤器等)。

现在来看看你所看到的替代方案,所有这些方法都可行,但它们会有缺点。例如,列入白名单的IP可能意味着每次客户端的IP发生更改时,都需要更改白名单。或者使它成为通配符匹配,如果你不小心,也可以暴露其他不需要的IP。内部与外部服务通常可以表示公共API和私有API。这意味着某些API甚至无法在公共网络中访问,只有VPN或子网内的API才能访问。有自己的复杂性和问题。

我的两分钱:努力寻求每个人都在使用的清洁和常见模式。