设计符合安全标准的Intranet应用程序

.NET框架的性能使得它成为开发企业内部互联网（Intranet）应用程序的理想平台。由于其内在的对活动目录（Active Directory）访问支持以及借助于SqlClient名字空间而获得的对SQL Server快速访问能力，用它开发健壮、安全的企业内部互联网要比用传统的ASP容易的多。

但是体系结构设计者仍需要在他们的设计中考虑采用哪些安全机制，并与工程与安全团队协作确保他们的设计符合本企业的安全标准。在设计安全体系时，系统结构设计者应该考虑到Intranet应用程序的特殊之处。

Intranet应用程序的特殊之处

由于企业对他们所支持的浏览器拥有控制权，所以Intranet应用程序使用高级浏览器（如4.0或者更高版本的Internet Explorer，IE）的情况并不少见。由于从4.0版本开始，IE提供了对NTLM验证的支持，所以它极大的简化了浏览器和网络服务器之间的安全机制——只要企业为它的用户帐号同样支持动态目录。

绝大多数Intranet应用程序应该假设用户只有在获得相应权限之后才可以使用该应用程序。一旦用户获得授权，Intranet应用程序应该向该用户提供特定数据访问的权力。这就是许多安全设计崩溃的原因。

用户特定数据并不意味着唯一用户登录

体系结构设计者在设计Intranet安全系统时常常犯的一个错误就是假设获得访问Web应用程序的证书（credential）的用户也应该获得访问其底层数据库的权力。尽管可能会有助于实现数据库审计的目的，但是使用用户证书来验证后端数据库会带来严重的性能下降问题。

这是因为高性能ASP.NET应用程序依赖于对连接（来自连接池（connection pool））的重用获得性能的提高，它并不为每个数据库调用而重建这些连接。由于只有共享同样的连接字符串的连接才可以汇集到池中，而连接字符串包含了用户ID和口令，所以由多个用户打开的连接不可以放到存储池中得到重用。由于性能的原因，你的Intranet应用程序安全设计应该假设应用程序用同一个用户ID调用数据库。

然而，系统事物要求包括查账索引（用户在其中可以要求一定的动作去执行）的情况并不鲜见。如果你的Intranet应用程序要求用户级的审核（auditing），那么你应该把用户ID作为存储过程（用来执行数据请求）的一部分，并在存储过程处理审核。

由于性能和安全的原因，所有对数据库的请求都应该在存储过程中产生，而不是在查询中用表格名字和数据栏名字进行直接SQL Server查询。通过使用存储过程，你可以给那些进行存储过程（被请求用来支持Intranet应用程序）的普通应用程序用户授以ID许可，而拒绝那些直接修改表格的请求。这样，你就对应用程序所请求的数据有了更多的控制。