c# - 建立一个安全库，我想我过度 build 了

Question

所以我正在构建一个自定义安全库，它与我们的数据库交互。它应该为内部应用程序提供基本的访问控制:某些用户可以做 X，其他人不能。我目前的需求非常基本，但该库最终将被多个应用程序使用并控制许多安全对象。

我的基本对象模型是用户是零个或多个组的成员。这些组授予零个或多个权限。实际上，这些都是一对多的，但我不想引用强制执行。权限仅授予(如果没有组授予您权限，则您没有权限，但没有像 Windows RBS 中那样覆盖授予的权限的“拒绝”)，并且组可以嵌套(第 2 层用户拥有第 1 层的权利，以及一些新的权利)。当尝试访问程序的安全区域时，应用程序将通过检查其组层次结构来强制断言用户具有必要的权限。

但是，我希望在库中内置多个级别的冗余。特别重要的是，无权更改安全设置的用户不应该能够这样做。因此，我想在大多数情况下将此安全层次结构设为只读，因此无法在内存中添加所需但被拒绝的权限。只有当用户通过向只读用户提供该权限来证明他们有权修改安全设置时，这些属性才应该从代码级别变为可设置的。

这就是我认为我过度构建它的地方。为了做到这一点，该领域已经形成了 split 的人格；每个对象的两个副本，一个只读，另一个不是。只读版本是默认生成的版本；任何会产生可写版本的操作都需要当前登录的用户具有进行安全更改的权限。这导致了两个用户(User 和 ConfigurableUser)、两个组、两个权限，每个都有两个接口(interface)(从 readonly 派生的可配置)......你明白了。

我已经意识到，基本上唯一会阻止所有这些额外垃圾的人是其他开发人员，他们通常值得信赖(这是一个内部应用程序，我们控制该应用程序使用的所有资源，开发人员通常获得管理员权限)很多)。如果我相信接触代码的人知道他们在做什么，那么这些应用程序就可以读写，并且通过巧妙的代码片段“提升”权限的可能性就不会有问题。

帮我搞清楚。我应该遵循不同的模式吗？我不信任其他开发人员是否正确？我不想与 Windows 安全集成，但已经讨论了该选项；主要缺点是整个公司的访问权限将在 Active Directory 中维护，并且此应用程序的用户的经理不应该对整个系统安全具有这种访问权限。

编辑:来自所有人的一些好的评论和答案。 AD 或其他集成安全性并非完全不可行，但我们在开始开发之前确实讨论过它，并发现了一些缺点。所以，这里有更多我/我们关于为什么我们甚至决定采用“自定义”安全设置的想法:

该应用程序的使用完全在内部进行。因此，该应用程序的安全性与其说是防止外部攻击/恶意收购，还不如说是防止 Joe Officeworker 根据业务政策做他不应该做的事情。如果 Joe 最终奇迹般地找到了一种方法让自己在应用程序中成为“上帝”，那么他的权力仍然非常有限，因为应用程序本身对数据库和其他资源的访问非常有限，其中大部分内容他都需要做他的无论如何工作，因此即使是最低级别的用户也能被授予。

尽管如此，如果用户的 Windows 密码被钓鱼、破解或键盘记录，如果应用程序使用集成安全而不是传统登录，攻击者将通过“免费”应用程序获得对客户端数据的一些严重访问。应用程序的单独安全层至少提供了冗余的可能性；他们必须破解两组凭据才能进入而不是一组凭据，而第二组凭据被锁定在另一层数据库安全性后面，被破解的用户将无法自由访问。

从开发/管理的角度来看，使用 Active Directory 或其他集成安全性有几个问题。

首先，部门成员“交换办公 table ”，在彼此的电脑上做很多事情。与 Windows 安全集成要求用户完全退出操作系统以更改应用程序的当前登录用户，而不仅仅是关闭、重新打开和以不同用户身份登录应用程序。

其次，将使用该软件的部门经理是处理应用程序内安全权限的逻辑人，但不是授予 AD 管理员访问权限的逻辑人。平衡将需要 AD 中的额外角色层以提供可以访问 AD 的“子管理员”，但仅向某些人授予某些权限。还有一个文件要求将安全管理集成到应用程序中，IMO 使 AD 集成不可行。

最后，据我所知，Windows Integrated Security 没有那个“权限”层。您不是断言用户具有执行某事的声明权限，而是断言用户处于特定角色中，推断是该角色有权继续。因此，我可以开发一个系统，要求 AD 为应用程序中的每个特定安全对象提供一个角色，嵌套到用户将拥有的逻辑角色中(这是一个管理噩梦，我相信网络管理员会努力保护他的安全层)，或者我们定义属于已知角色的大量功能，嵌套角色以创建“用户级别”，如果用户需要从下一个级别访问一项功能，他们必须获得整个级别(或 AD 和我的应用程序必须更改以将该功能划分为特定的可分配角色)。

鉴于所有这些，简单的解决方案是将安全性包含在应用程序的范围内，而不是与网络安全性相关联。我们得到了一个可以相对轻松地维护的安全结构，它停留在应用程序上。

编辑 2:作为这个问题的结尾，我最终得到的解决方案是保持我的可变对象层次结构，然后创建一个简单的接口(interface) IAuthUser，其中包含用户基本信息和权限的只读成员。 IAuthUsers 仅在一个地方创建 - 在登录期间 - 通过将使用凭据检索到的用户复制到实现公共(public)接口(interface)的私有(private)类中。它们用于所有身份验证和授权，方法是在启动时询问从用户组成员身份转换的包含的权限列表。它们永远不会变回可变用户，因此永远不会保存回数据库。同时，可变用户不能在登录过程之外变成 IAuthUsers，因此对授权无用，并且如果不提供有权在对象中检测到更改类型的 IAuthUser(通过将其与数据库中当前的版本进行比较)

Answer 1

我没有拆分层次结构，而是拥有“用户可以修改安全设置”权限，并在用户尝试编辑某些内容时断言。