确定强制实施安全性的位置
强制实施安全性时，不可避免地需要权衡。 数据库可以是放置安全逻辑的自然位置，因为最终数据是要保护的最重要内容。 但是，这样做会对性能产生重大影响。 在数据库中强制实施安全性可能非常昂贵、伸缩能力差且不灵活。
在中间层强制实施安全性
使用 COM+ 的可扩展多层应用程序遵循的一般规则是，应尽可能在中间层的 COM+ 应用程序中强制实施详细的安全性。 这样，便可以充分利用 COM+ 提供的可扩展服务。 只有在绝对需要的时候才强制在数据库进行身份验证，并充分权衡这样做对性能的影响。
最佳情况是能够保护数据库表，以便 COM+ 应用程序能够利用自己的标识访问它们。 数据库应仅对 COM+ 应用程序进行身份验证，并信任它以正确对将访问数据的客户端进行身份验证和授权。 这种方法有如下好处：
- 它可以在所有客户端之间启用连接池，因为连接是完全通用的。
- 它通常会优化数据访问，而数据访问通常是伸缩应用程序时有问题的阻塞点。
- 它可以最大程度地减少强制实施安全性的逻辑开销，尤其是在可以使用基于角色的声明性安全性时。
- 它可以在安全策略中提供极大的灵活性。 可以根据基于角色的安全管理中所述轻松配置和重新配置它。
但是，正如有效设计角色中所述，虽然可以轻松有效地将角色应用于某些用户数据关系，但它们并不是安全访问决策的通用解决方案。
在数据库中强制实施安全性
尽管在中间层强制实施安全性是可取的，但仍有很多理由要求在数据库中强制实施安全性，例如：
- 您没有选择，也许出于传统原因，或者可能是因为您无权做出这个决定。
- 数据库会由各种应用程序访问，因此不能根据单个应用程序配置其安全性。
- 可以预见，数据库会受到保护。 如果将企业关键型数据保存在数据库中，可以围绕数据实施安全措施，并帮助控制谁能够看到此类数据。
- 通过在数据库中对原始客户端进行身份验证，可以详细记录谁在数据库中执行了哪些操作。
- 某些数据本来就绑定到特定用户，并且对数据库本身（靠近数据）执行极其精细的访问决策的逻辑可能最为高效。
在设计数据库和 COM+ 应用程序安全性方面确实很奢侈，其中大多数问题都与数据本身的特征及其与访问数据的用户的关系有关。 使用可由可预测类别的用户访问的数据，使用角色控制中间层中的访问会很高效。 对于杂乱地绑定到非常小的用户群体的数据，这些关系通常必须与数据本身一起表达，因此必须在数据库中强制实施某些安全性。
在数据库中强制实施安全性的性能影响
如果对数据库中的用户进行身份验证或授权，则需要将用户标识传播到数据库，才能支持此操作。 如果数据库信任中间层应用程序这样做，则有可能会在参数中传入用户安全信息。 否则，必须根据用户的标识进行数据库调用，这意味着服务器应用程序必须模拟客户端。 这可能会有性能影响，例如：
- 模拟客户端比直接利用应用程序标识进行调用要慢得多。 有关更多详细信息，请参阅客户端模拟和委派。
- 不能共用利用特定用户标识建立的数据库连接。
- 在数据库中添加逻辑会面临产生伸缩瓶颈的风险。
相关主题