数据库安全性

数据库安全性

分布式应用程序最常见的方案涉及在远程数据库上读写数据。这会引出一个难题，即如何在维持应用程序伸缩性的同时，保证安全地进行读写操作。在应用程序中选择管理安全性将大大影响应用程序的伸缩性，这种影响或是积极的，或是消极的。

若要实现伸缩性，使用数据库连接池要优于让数据库管理安全性。这是因为数据库连接池要求连接字符串要与池连接相同。因此，必须在其他地方管理安全性。如果必须基于每个用户跟踪数据库操作，请考虑在每个操作中为用户标识添加一个参数，然后手动记录用户的数据库操作。

采取以上建议后，另一个问题是如何保存数据库连接字符串（该字符串通常包含安全凭据），而让多个用户可以访问它，同时又不降低安全性。大多数应用程序示例都说明了在 Web.config 或 global.asax 文件中保存连接字符串。但是，因为这些文件是纯文本文件，安全性有限，所以不是保存这些信息的最佳位置。如果入侵者破坏 Web 服务器的安全性，很容易访问到这些文件。这里有几个备选方案：

• 如果使用 Web.config 文件，应存储加密的连接字符串，然后在需要时在应用程序代码中解密该连接字符串。
• 使用 ServicedComponent 类生成一个 COM+ 应用程序，并在该组件的构造字符串中存储连接字符串。

  当在构造函数字符串中存储敏感信息时，应验证下列内容：

  • 只有适当的用户或组属于系统包的读者角色。然而，必须仔细管理 COM+ 以防止它无法读取其自身的配置。
  • 已经控制和审核了对 %windows%/Registration 文件夹的访问，COM+ 配置数据库 (RegDB) 将其文件存储在该文件夹中。

  有关更多信息，请参见 ServicedComponent 类。

• 使用集成安全性建立与 SQL Server 间受信任的连接。这将允许使用连接字符串，该字符串免除在连接字符串中保存密码的需要，如：
  复制代码

  "Data Source=mySqlServer;Integrated Security=SSPI;Initial Catalog=myDB"

  使用集成安全性有一些缺点，其中大部分是可以克服的。因为集成安全性要求有 Windows 帐户，如果使用个人 Windows 帐户模拟每一个已经过身份验证的主体，它将导致不能使用连接池。但是，如果改为模拟数量有限的 Windows 帐户，让每个帐户表示一个特定的角色，就可以克服此缺点。每一个 Windows 帐户必须是一个域帐户，且 IIS 和 SQL Server 在同一个域或信任域中。或者，可以在每台计算机上创建相同的（包括密码）Windows 帐户。

  进行典型安装后，SQL Server 2000 的默认安全身份验证模式是 Windows 身份验证，这与 SQL Server 7.0 不同。在 SQL Server 7.0 中，默认安全身份验证模式是混合型的（Windows 身份验证模式和 SQL Server 身份验证）。Windows 身份验证是较好的安全方法，因为它提供附加的安全功能，如密码的安全验证和加密、密码到期时间以及审核。有关更多信息，请参见身份验证模式。

  如果将 SQL Server 配置为使用 Windows 身份验证，可以为只读操作创建一个 Windows 帐户，而为读/写操作创建另一个 Windows 帐户。然后将每一个 Windows 帐户映射到 SQL Server 登录，并建立所需的权限。使用应用程序逻辑，可以确定在执行数据库操作时模拟哪个 Windows 帐户。在 SQL Server 中，可以添加任何 Windows 用户帐户作为固定数据库角色的成员。每一个成员获得适用于该固定数据库角色的权限。有关更多信息，请参见管理权限。

  对于 SQL Server 7.0，集成安全性不支持 SQL Server 的 TCP/IP 网络库，而是使用命名管道网络库。

作为添加的安全措施，默认情况下，SqlConnection 对象的 ConnectionString 属性不持续存在或不返回完整的连接字符串。若要这样做，必须将“持久性安全信息”设置为 true。有关更多信息，请参见 SqlConnection.ConnectionString 属性和 SqlConnection 类。