微服务 - 访问和安全理解

Question

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

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

因此，这意味着我的客户端有一个 API (C) 可以访问 A 和 B，其中 B 只能通过 C 访问，而不像 A（可以通过任何 HTTP 请求从任何地方访问）。

关于这一点，我不确定是否了解微服务架构之间应用的安全逻辑。事实上，我看过一些文章和一些关于它的堆栈溢出交流，主要是：

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

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

感谢您提供任何示例或解释，请随时询问我任何其他详细信息。

提前致谢！

Answer 1

这个问题非常广泛，因为身份验证和授权本身就是大主题。

我会尽量在这里简短地回答。如果您有时间和资源，请查看使用 OAuth。它们是提供身份验证和访问 REST API 的行业标准方式。

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

现在您已经实现了 OAuth 并且可以将用户与其访问控制相关联，将这些作为标头传递给您的实际微服务。在您的 API 中，只需检查用户是否拥有正确的令牌并访问并继续。如果不是，则会出现 422 错误。哎呀，如果您使用好的库，您甚至可以在 API 代码之外执行此操作（使用过滤器等）

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

我的两分钱：争取每个人都在使用的更清洁和通用的模式。