安全可能不是一个横切关注？

我正在处理一个非常详细的安全需求的项目。如果提出的模型与任何情报/安全机构一样复杂，我会诚实地不会感到惊讶。现在我已经读到，将安全与业务逻辑结合起来是一个混合问题，因此需要避免。安全可能不是一个横切关注？

但是，所有抽象安全的尝试都失败了，或者像以前一样产生了像抽象一样的“抽象”。是否有可能让安全性如此具体以至于成为业务规则的一部分？在某些违反安全的情况下，只会屏蔽数据，而在其他情况下会终止会话，而在其他情况下，则会触发默认值以替代使用。对安全性要求有很多要求。

我的根本问题是：我是否可以处于特殊情况下（即将安全性合理化）或者我不理解关于抽象安全性的基本知识？

编辑：

TL;博士（答案，因为我理解他们）：认证（你是谁）是一个很有横切关注点，应该抽象，而授权（什么都可以你这样做）是商业逻辑。缺乏这种词汇并且只有“安全”这个词（或者可能没有意识到两者之间的区别）导致我的困惑。

来源

2011-05-09 ArtB

我认为您会在[ITSecurity]（http://security.stackexchange.com） /） – AviD 2011-05-09 16:18:25

我认为当你说“安全性”时，你并不是指*只是*来进行身份验证和授权，因为这两个海报至今都宣称它是全部存在的...... – AviD 2011-05-09 16:20:00

Avid，我认为我们是没有解决其他安全问题，因为这个帖子特别质疑安全性是否可以成为业务规则的一部分，而Sql注入攻击虽然是“安全性”的一部分，但通过编码模式和实践来解决，因为数据跨越各层，而不是在要求中常见的东西 – Andy 2011-05-09 16:23:03

安全性分为两部分;认证和授权。认证是一个非常具体的用例。你如何确定一个用户信任的一组不信任的用户。我认为这是交叉性的;您需要将未经身份验证的用户保留在您的系统或系统的子集之外。

授权（用户可以做些什么）是非常多的商业规则。它可以（而且经常）对每个用例都非常具体和不同。谁决定什么角色可以做什么？那么，业务呢。没有人能为你回答这个问题。

在Csla.Net 4框架中，这正是授权的处理方式;作为一项专门的商业规则。你甚至不限于“用户在角色中”或“用户有权限”。“您可以制定更复杂的规则”，如果工作流程步骤未经过此特定步骤，用户可以编辑此字段。“

来源

2011-05-09 16:18:10 Andy

“安全性分为两部分：身份验证和授权，身份验证是一个非常具体的用例：我认为这是交叉性的，授权（用户可以做些什么）非常符合业务规则。这激起了我启蒙的一刻，谢谢。 – ArtB 2011-05-09 16:24:14

很高兴听到它ArtB。 – Andy 2011-05-09 16:56:13

'“安全分为两部分：认证和授权” - 安全性远不止于此。 – AviD 2011-05-09 18:36:37

我想，如果您的业务逻辑是某种安全服务，那么会出现例外情况。但是我认为你的问题可能是你将用户授权与验证混淆了。

当然，身份验证应该有一组与其相关的规则，但最终的结果应该是用户的标识和会话的创建。

授权将与我们确定用户角色以及该角色布置的权限分开。

一个典型的例子是认证返回一个用户对象并将其存储在会话中。用户具有1到多个角色。角色可能具有1到多个特权。业务逻辑方法可能是sendEmail。此方法查询User对象的特定权限，如果它存在则执行某些操作，如果不执行其他操作。

编辑：安全在我看来应该始终是一个横切关注，当涉及到用户，但是如果您的业务逻辑涉及对象的属性不是用户，这些对象的CRUD或管理其他用户，然后它符合您的业务需求，因此是业务逻辑。

来源

2011-05-09 16:15:46

是的，QuarterBack是一个角色。 QuarterBack具有多种关联的权限。 RunningBack也可能是一个角色，但RunningBack可能具有相同的权限。他们都可能有特权，“跑足球”。您应该能够查询User对象以查看是否在其任何角色中都有特定的权限。 – 2011-05-09 16:21:53

“我以为人们都在倡导在商业代码中没有安全的痕迹”。这个陈述过于笼统，我会作为一般规则提出质疑。您不应该在业务逻辑代码中正确认证用户。授权可以由业务逻辑可以共享的全局横切组件来处理。它不需要比这更复杂。 – 2011-05-09 16:24:54

'“......将用户授权与认证相混淆” - 安全性远不止于此。 – AviD 2011-05-09 18:38:02

安全可能不是一个横切关注？

回答

相关问题