应用程序的哪一层应该保留安全逻辑（权限、授权）？

Question

由于最相似的问题与 ASP MVC 有关，我想了解一些常见的正确选择策略。

让我们尝试决定是进入业务层还是位于服务层。

考虑到服务层具有经典的远程外观接口，因此在这里进行权限检查似乎很重要，因为用户对象实例始终在这里（服务会话绑定到用户）并准备好调用.hasPermission(...)。但这看起来像是业务逻辑泄漏。

在业务层中实现安全检查的不同方法中，我们使用“安全令牌”参数和类似的东西污染域对象接口。

有什么建议如何克服这种权衡，或者也许您知道唯一真正的解决方案？

Answer 1

我认为这个问题的答案很复杂，值得尽早思考。以下是一些指南。

服务层是执行以下任务的好地方：

• 页面是公开的还是仅对注册用户开放？
• 此页面是否需要特定角色的用户？
• 身份验证过程包括将令牌转换为用户的内部表示。
• 网络检查，例如 IP 和垃圾邮件过滤器。

业务层是执行以下任务的好地方：

• 该特定用户是否有权访问所请求的记录？例如，用户应该有权访问自己的个人资料，但不能访问其他人的个人资料。
• 审核请求。业务层最适合描述请求的细节，因为此时协议和其他细节已被过滤掉。您可以根据您正在设置策略的业务实体进行审核。

您可以尝试将访问决策与执行点分开。例如，您的业务逻辑可以使用代码来确定用户是否可以访问特定角色并将其作为回调呈现给服务层。有时这是有道理的。

需要记住的一些想法：

1. 将安全性融入到框架中的能力越多越好。如果您有数十个服务调用，其中每个服务调用都需要在代码开头执行安全检查，那么您就是在寻求错误（也可能是漏洞）。如果您有框架，请使用它。
2. 一些安全措施最好离网络最近。例如，如果您希望禁止向您发送垃圾邮件的 IP 地址，那绝对不应该在业务层中进行。距离网络连接越近越好。
3. 重复安全检查不是问题（除非是性能问题）。通常情况下，在工作流程中越早检测到安全问题，用户体验就越好。也就是说，您希望保护业务运营尽可能接近实施，以避免绕过早期安全检查的后门。这通常会导致为了用户界面而进行早期检查，但最终的检查发生在业务流程的后期。

希望这可以帮助。