【问题标题】:Security in 3-Tier applications: in which layer?3 层应用程序的安全性:在哪一层?
【发布时间】:2012-08-15 20:12:54
【问题描述】:

“安全”是指数据访问权限,例如:

  • Andrew 对法国的客户只有只读权限
  • Brian 可以更新法国和德国的客户
  • Charles 是管理员,他拥有所有内容的读取和更新权限

我可以看到每一层的潜在参数。

  1. 数据访问层

    DAL 仅公开用户有权访问的客户端,并在用户尝试执行未经授权的操作时将适当的错误传递给业务层。

    这简化了上层,并且可以减少只能访问一小部分数据的用户的数据流量。

  2. 业务层

    因为这是业务逻辑所在的位置,并且只有业务层才能完全了解应如何实现安全性。

  3. 界面层

    一个相切的论点是因为 UI 层是处理身份验证的层。 更有力的论点是应用程序具有非 UI 功能:计算每日损益、归档等。这些程序没有安全上下文,创建虚构的“系统”用户是维护的噩梦。

  4. 一个单独的层?

    插在 3 里面的某个地方?

我正在寻找一个有说服力的论据,它可以让我相信 X 层最适合大型 3 层应用程序。请不要“视情况而定”的答案;-)。

谢谢。

【问题讨论】:

  • @meagar 是的,编号确实更好:)
  • 如果反对者添加评论来解释原因(给予改进的机会)会很有帮助

标签: security architecture 3-tier


【解决方案1】:

我想这可能是一个主观的话题。尽管如此,我们遵循从不信任任何外部来源(例如跨越服务边界的数据)的原则。通常,现代应用程序与旧的客户端-服务器三层模型有些不同,因为它们通常是面向服务的(我认为 Web 服务器也是一种服务)。

这排除了将访问检查委托给客户端 - 客户端可能知道允许的访问并使用此信息以不同的行为(例如,不提供某些功能左右),但最终只有服务(服务器) 决定允许计数。

另一方面,数据库或 DAL 太低,因为大多数检查还依赖于某些业务逻辑或外部信息(例如用户角色)。所以这排除了数据层;在我们的环境中,数据访问是一个不做任何检查的可信空间。最后,DB 层和应用服务器形成一个逻辑单元(可以称之为堡垒——根据 Roger Sessions Software Fortresses 的书),其中不存在服务边界。如果应用层访问另一个服务,但它必须对接收到的数据进行检查。

总之,您可能希望获得一份Roger Sessions book 的副本,因为它确实为大型应用程序以及如何处理安全性和其他问题提供了一些有价值的意见和思考。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2020-12-24
    • 1970-01-01
    • 2013-08-03
    • 2015-08-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多