3层应用程序中的安全性:在哪一层?

时间:2012-08-15 20:12:55

标签: security architecture 3-tier

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

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

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

  1. 数据访问层

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

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

  2. 业务层

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

  3. UI图层

    切线参数是因为UI层是处理身份验证的层。 更强有力的论据是当应用程序具有非UI功能时:计算每日P& L,存档等。这些程序没有安全上下文,并且创建虚构的“系统”用户是维护的噩梦。

  4. 一个单独的图层?

    在3?

  5. 内的某个地方开槽

    我正在寻找一个有说服力的论点,它会让我相信X层是最适合大规模3层应用的。请不要'依赖'答案;-)。

    感谢。

1 个答案:

答案 0 :(得分:0)

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

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

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

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