发信人: pcZealot (有痔青年), 信区: DotNET
标  题: Re: 在C/S结构的软件中，DB连接串的安全怎么保证呢
发信站: BBS 水木清华站 (Sun Mar 14 18:52:26 2004), 转信

存储链接字符串


有多种方法可存储链接字符串，每种方法具有不同程度的灵活性和安全性。尽管在源
代码中对字符串进行硬编码提供了最优性能，但文件系统缓存确保了与在文凭系统外
部存储字符串相关的性能损失可被忽略。实际上外部链接字符串（允许管理员进行配
置）所提供的附加灵活性在任何情况下都是受欢迎的。  
选择存储链接字符串的方法时，首先要考虑的两个重要因素是配置的安全性与简易性
，其次是性能。  
可以选择将数据库链接字符串存储在下列位置：  
        · 应用程序配置文件 例如用于ASP.NET Web应用程序的Web.config文件。  
        · 通用数据链接文件(UDL) （只被OLE DB .NET 数据供应器所支持)  
        · Windows 注册表  
        · 定制文件  
        · COM+ 目录，通过过使用构造字符串(只用于服务组件)  
使用Windows认证访问SQL Server，就可以避免在链接字符串存储用户名和密码。如
果 安全需求要求更严格的方式，那么就考虑以加密格式存储链接字符串。  
对于ASP.NET Web应用程序，以加密格式将链接字符串存储在Web.config文件中是一
种安全而可配置的解决方案。  
注意，在链接字符串中将Persist Security Info命名值设置为假，就可以阻止利用
SqlConnection 或OleDbConnection对象的ConnectionString属性返回对安全敏感的
内容，如密码。  
下面我来说明如何用这些方法存储链接字符串，并说明了相对的优点和缺点。这使你
能根据特定的应用程序环境作出相应的的选择。  

· 使用XML应用程序配置文件  

可以使用元素appSettings将数据库链接字符串存储在应用程序配置文件的定制设置
部分。该元素支持任意关键字-值对，如下面的代码片段所示：  
<configuration>
<appSettings>
<add key="DBConnStr"
value="server=(local);Integrated Security=SSPI;database=northwind"/>
</appSettings>
</configuration>

注意：appSettings元素现在在configuration元素下面，并且不能直接出现在system
.web下面。
  
优点：
· 易于部署。通过常规.NET xcopy部署，链接字符串随配置文件一起被部署。  
· 通过程序易于访问。ConfigurationSettings类的AppSettings属性使得在运行时
读取数据库链接字符串更为简单。  
· 支持动态更新（仅限于ASP.NET）。如果管理员更新了Web.config文件中的链接
字符串，那么下次在字符串被访问时所作出的变化生效，这对一个无状态的组件来说
，就象客户再次利用组件作出了数据访问请求一样。  

缺点：
安全性。尽管ASP.NET Internet 服务器应用程序编程接口（ISAPI）DLL阻止了客户
直接访问带.config扩展名的文件，并且NTFS文件系统权限也用于进一步限制访问，
但你可能仍希望避免以明文方式将这些内容存储在前端的Web服务器上。要增加安全
性，需将链接字符串以加密格式存储在配置文件中。  

利用System.Configuration.ConfigurationSettings类的AppSettings静态属性，可
以获取应用程序的定制设置。如下面的代码片段所示，此处假定先前示例的定置关键
字为DBConnStr。  
using System.Configuration;
private string GetDBaseConnectionString()
{
return ConfigurationSettings.AppSettings["DBConnStr"];
}


· 使用UDL文件  

OLE DB .NET数据供应器支持在它的链接字符串中使用统一数据链接（UDL）文件名。
可以以构建参数的形式将链接字符串传给OleDbConnection对象，或利用对象的ConnectionString
属性设置链接字符串。  
注意 SQL Server .NET数据供应器不支持在它的链接字符串中使用UDL文件。因此，
只有使用OLE DB .NET数据供应器，此方法才有效。  
对于OLE DB 供应器，要利用链接字符串引用UDL文件，使用“File Name=name.udl.
”。  

优点：  
标准方法。你也许已经在用UDL文件进行链接字符串的管理了。  


缺点：  
· 性能。每次打开链接时，包含UDLs的链接字符串都被读取并被解析。  
· 安全性。UDL文件以纯文本格式存储。利用NFTS文件权限可以确保这些文件的安
全性，但这样做将引发与使用.config文件相同的问题。  
· SqlClient对象不支持UDL文件。此方法不被 SQL Server .NET数据供应器所支持
，而你要用此供应器访问 SQL Server 7.0及其以后版本。  
更多信息  
· 必须确保管理员拥有该文件的读/写访问权限以便进行管理，并且还要确保运行
应用程序的身份拥有读权限。对于ASP.NET Web应用程序，应用程序工作者进程默认
是以SYSTEM帐号运行的，但利用机器范围的配置文件（Machine.config）中的元素可
以将其覆盖掉。利用Web.config文件中的元素，及一个可选的指定帐号，可以进行冒
充。  
· 对于Web应用程序，要确保没有将UDL文件放在虚目录中，因为那样会使该文件可
通过网络下载。


· 使用Windows注册表  

可以利用定制关键字将链接字符串存储在Windows注册表中，但由于部署问题，建议
不要使用。
  
优点：  
· 安全性。利用访问控制列表（ACLs），可以对所选的注册表关键字的访问进行管
理。对更高级别的安全性，考虑对数据进行加密。  
· 通过程序易于访问。.NET类支持从注册表中读取字符串。  
缺点  
· 部署。相关的注册表设置必须同应用程序一起部署，从某种程度上抵消了xcopy
部署的优点。  

· 使用定置文件  

可以使用定制文件来存储链接字符串，然而这种技术没有优点，因此并不推荐使用。
  
优点  
· 没有  
缺点  
· 额外编码。这种方法需要额外编码，并迫使你明确处理同时发生的问题。  
· 部署。此文件必须同其它ASP.NET应用程序文件一起拷贝。避免将此文件放在ASP
.NET应用程序的目录或子目录中，就可以阻止通过网络对其进行下载。


· 使用构建参数和COM+目录  

可以将链接字符串存储在COM+目录中，并利用对象的构造字符串将它自动地传递给对
象。COM+在初始化对象，提供配置构造字符串后，将立即调用对象的Construct方法
。  
注意这个方法只用于服务组件。只有管理组件使用了其它服务，如分布式事务处理支
持或对象池化时，才考虑使用此方法。  

优点  
· 管理性。利用组件服务MMC插件，管理员可以很方便地配置链接字符串。
  
缺点  
· 安全性。COM+目录被认为是一个不安全的存储区（虽然利用COM+角色你可以限制
对它的访问），并因此不能用于以明文维护链接字符串。  
· 部署。COM+目录中的条目必须随.NET应用程序一同部署。如果使用了其它企业服
务，如分布式事务或对象池化，那么将数据库链接字符串存储在目录中不会增加部署
的额外开销，因为要支持其它服务，必须部署COM+目录。  
· 必须为组件提供服务。可以只为所服务的组件使用构造字符串。要使能构造字符
串，不能简单地从ServicedComponent类中派生所需组件类（这将为组件提供服务）
。  

本文信息来自于MSDN 的 ".NET 数据访问架构指南"
http://www.microsoft.com/china/msdn/adonet.asp

【 在 DRAGONESE (狗三斤◎做人要厚道) 的大作中提到: 】
∶C#
∶C/S结构的程序，连接Oracle数据库。
∶数据库连接串在安装的时候肯定是要改变的，放在哪里、怎么放比较好呢？
∶多谢大家先~~~~


--

有痔不在年糕


※ 来源:·BBS 水木清华站 smth.org·[FROM: 221.204.44.*]
上一篇
返回上一页
回到目录
回到页首
下一篇