保护 SQL Server Express Edition Server.docx

保护 SQL Server Express Edition Server.docx

《保护 SQL Server Express Edition Server.docx》由会员分享，可在线阅读，更多相关《保护 SQL Server Express Edition Server.docx（17页珍藏版）》请在冰豆网上搜索。

保护SQLServerExpressEditionServer

保护SQLServer2005ExpressEditionServer

什么是SQLServerExpress？

SQLServer2005ExpressEdition是MicrosoftSQLServer的Microsoft桌面引擎（MSDE）版本的替代产品。

它的体系结构完全重新设计，您可以像使用MicrosoftAccess/JET数据库那样安装和使用它，但是不会出现与该方法相关联的问题。

SQLServer2005ExpressEdition为满足下列应用程序的需要而构建更好的解决方案，这经历了很长的历程：

•

替代JET数据库。

也就是说，如果需要，可以由IT部门代替DBMS，这一方面可以满足HIPA安全性的需要，一方面可以使用所有SQLServer保护数据和参照安全性的功能，并且无需考虑用户采取的手段。

（HIPPA或HIPAA（通常简略为HIPA）指联邦立法部门，该部门要求将可靠的安全性和访问保护用于存储个人医疗卫生信息的数据库中。

）

•

无需升级到SQLServerStandardEdition，DBMS即可从单个用户扩展到很多用户，并且DBMS无需担心在最需要调控器时，调控器的性能降低。

•

可以轻松地在小型网站上和客户端/服务器配置中工作的DBMS。

•

当ServicePack可用时，可以轻松地安装并就地更新的DBMS引擎。

这意味着安装例程可以轻松地集成到应用程序的部署脚本中。

•

通过简单地指向安装或传递到应用程序中的DBMS文件，就可以对其进行访问的DBMS。

因为SQLServerExpress旨在允许数据库随时连接，它可以比以前更加简单地使用“松散”的SQLServerMDF数据库文件并利用应用程序对它们进行部署。

这使得部署独立的SQLServerExpress数据库.MDF文件非常简单，就像利用JET数据库完成那样。

•

引用SQLServer的共享实例的标准方法。

当安装SSE时，默认情况下安装为具有相同的实例名称SQLEXPRESS。

这意味着如果假设应用程序安装例程利用了该功能，无论应用程序的连接字符串是安装在本地系统上还是安装在局域网上，它都可以更简单地针对SQLServerExpress。

我会在稍后谈论实例问题。

我的新书，Hitchhiker'sGuidetoVisualStudioandSQLServer2005（AddisonWesley），将会用一整节来讨论SQLServer2005ExpressEdition，但对于本文，我将重点限制在使用SQLServer2005ExpressEditionBeta2的托管安全性上。

随后我将会讨论下列内容：

•

什么是“安全”的系统？

对于小型系统而言，安全性意味着什么呢？

•

MSDE开发人员面临着什么问题？

•

SQLServerExpress如何解决这些问题？

•

应用程序如何获得对SQLServerExpress数据库的访问？

•

如何保护SQLServerExpress数据库？

注在撰写本文时，SQLServer2005ExpressBeta2不应该用于产品系统中，不应该公开在Web上或在EULA限制外使用。

什么是“安全”的系统？

在我们深入讨论SQLServer2005ExpressEdition的技术优点以及如何配置其安全功能之前，我认为有必要定义安全性的实际含义。

当然，对于小型企业或部门系统来说，当数据服务器受到安全威胁或其数据丢失或损坏时，该公司与大型公司一样容易面临失败。

SQLServerExpress可以驻留在Web服务器上，为ASP应用程序提供SQLServer服务。

因此，正常运行时间、可靠性和安全性也意味着对Web服务器应用程序公开信息的能力，但同时还不易受到来自Web的攻击。

对于将编写代码和构建应用程序作为兼职的“经验不足的开发人员”来说，SQLServerExpress也是非常理想的。

这些医生、律师、接待员和出租车司机都需要一个用于存储和检索数据的简单、安全、稳定的方式，而不必考虑在后台正在为他们所做的操作。

安全性还包括应用程序设计程序和开发人员要防止数据丢失而采取的这些步骤，无论丢失是由于意外、疏漏或是恶意攻击所致。

安全性意味着将那些不应该访问数据的人员拒之门外，并保护物理文件和系统本身。

它意味着制作备份并能够无缝地执行还原。

利用SQLServerExpress系统，尤其具有挑战性，因为与通常不同，没有专职系统管理员或IT部门介入并执行周期性的备份，或者当系统发生故障时从各个部分中进行还原整个系统。

具有安全的系统意味着当发生问题时保持您的工作（并且可能会有提升），然后可以快速、安静、高效地恢复应用程序。

我将会指出很多事项，您可以完成它们使应用程序更持久、更不容易受到攻击并且更易于维护。

问题是什么？

相当长时间以来，我一直都在赞美SQLServer的MSDE版本。

这是因为我确信对于需要“少量用户”数据存储区的应用程序，或应用程序不需要对远程DBMS引擎进行访问的情况下，MSDE是非常好的解决方案。

尽管MSDE已经广泛地被大量关键业务采用，它们通常必须依赖自己来处理很多问题—实现非标准解决方案，该解决方案有时与解决相同或不同问题的其他公司的尝试相冲突。

这些冲突包括：

部署：

如果将SQLServer与应用程序一起安装将会怎样？

下面就是对相关问题的阐述。

例如，如果SQLServer已经安装，又该如何呢？

如果实例名与其他现有实例冲突，又该如何呢？

应用程序应该共享一个现有的SQLServer实例还是创建一个独特的实例呢？

当卸载安装有共享SQLServer实例的应用程序行时会发生什么情况？

它还会卸载SQLServer实例吗？

如果会，那么该实例宿主的其他数据库会发生什么情况呢？

安全性：

如果选择共享一个SQLServer实例，应该为SA使用什么密码呢？

如何设置用户帐户？

应用程序是否应该只是使用由域控制器管理的集成安全性呢？

如果没有ActiveDirectory，又该如何呢？

如何将数据库安装在目标MSDE服务器上？

安装后，数据库是否对服务器上的其他应用程序可见呢？

应用程序如何隐藏专用数据呢？

性能：

MSDE使用限制服务器上并发操作数量的调控器。

如果单个用户应用程序需要同时执行几个操作，但是调控器不发挥作用并使其速度下降，又该如何呢？

坦白地说，我不确认这个问题是十分普遍的。

我曾经听到非常少的人抱怨调控器终止，并且使他们的应用程序运行得非常慢。

的确，我曾听说应用程序运行得不是特别快，但是这（通常）是由于野蛮强制查询或“置疑的”数据库实现导致的结果。

可伸缩性：

MSDE数据库限制在2GB。

如果您需要比这更多的数据，又该如何呢？

这是否意味着您必须升级目标系统以使用SQLServerStandardEdition，而这可能比期望使用它的系统花费更多？

另外，我所听到的最多的抱怨就是人们存储二进制大对象（BLOB）（例如数据库中的文档或图片）时涉及的问题。

一旦它们将BLOB替换为一个到BLOB文件的路径，它们的数据库就缩小到非常合理的大小了。

工具：

SQLServer的MSDE版本是“部署”配置。

同样，它并不包括管理服务器或它所管理的数据库所需要的任何工具。

我通常会推荐开发人员购买49美元的（SRP）DeveloperEdition，它包括用于管理其MSDE数据库的整套工具。

但是，由于许可限制，这些工具无法利用应用程序进行部署。

这意味着开发人员必须构建他们自己的客户端工具或简单地将需要的功能构建到他们已部署的应用程序中。

管理：

无论它是如何完成的，应用程序必须要承担很多管理性责任。

对于没有“SA”（系统管理员）值守的SQLServerExpress系统而言，这一点尤为重要。

这些管理责任包括管理登录帐户、权限、备份、还原和日志维护。

最终用户通常不具有执行这些操作的能力并且不应该被信任来执行这些操作—这取决于应用程序。

因为JET数据库需要周期性的压缩或修复，MSDE（和任意SQLServer数据库）需要周期性地备份（和转储）日志和数据库。

当数据库没有进行集中管理时（集中管理可以更简单地管理管理性和维护任务），这个问题就变得相当重要。

同样，这取决于应用程序。

ServicePack：

由于MSDE通常嵌入到应用程序中，用户可能不知道他们已经安装了一个SQLServer实例。

同样，他们也没有注意到他们可能需要应用SQLServerServicePack来保护他们的数据和系统以免受攻击，即使他们在5点钟新闻时看到它时，还在正常运转。

为了防止由蠕虫和其他攻击病毒引起的某些问题，MSDESP3（a）禁用了网络连接，因此应用程序无法通过Intranet（或Internet）连接到服务器。

问题在于ServicePack未能应用到很多系统中，因为用户不知道它是必要的，或者不知道如何应用修补程序。

将SQLServer更新应用到MSDE安装这个问题仍然难以解决，因为Microsoft升级不是始终可以与用于部署MSDE应用程序和数据库的自定义安装脚本一起使用的。

SQLServerExpress如何解决这些问题？

近年来，世界范围的开发人员、架构师和IT经理一直对上述问题进行着讨论。

尽管没有对所有这些问题的解决方案，但是通过一些相当基本的改动，SQLServerExpress已经解决了其中的很多问题。

在了解差异之前，知道什么内容没有变化非常重要。

SQLServer2005ExpressEdition仍然是免费的（具有惯例的licensinganduserestrictions），它仍然支持订阅者复制以及实际上与MSDE相同的所有功能。

新的SQLServerExpress版本无法宿主报告服务，但它可以作为宿主在SQLServer2000StandardEdition上的服务器的数据源。

（有关SQLServer报告服务的详细信息，请参阅B网站。

）默认情况下，安装程序仍然禁用将SQLServerExpress实例公开到网络的能力（首次在MSDESP3中实现）。

让我们更仔细地考察一下SQLServerExpress是如何解决每个问题的。

部署

SQLServerExpress设计为可以通过Web下载，并可以像任何其他系统软件那样安装在用户系统上。

（这假设系统管理员安装了SQLServerExpress。

）您可以使用交互式安装程序（我将在稍后进行说明），或运行命令行安装可执行文件。

利用“安静”模式，用户根本不需看到任何SQLServerExpress安装对话框。

当安装SQLServerExpress时，默认情况下安装程序会尝试创建一个公用的SQLEXPRESS实例。

如果它已经准备就绪，将提示您选择放弃安装或是选择另一个实例名。

此处的思想在于让使用SQLServerExpress的应用程序共享一个公用实例，而不是创建它们自己的实例。

这使得应用程序配置更加简单，同时还可以降低用户系统上的内存和磁盘占用空间。

如果卸载应用程序，最好还是卸载您所安装的任意唯一的SQLServerExpress实例。

但是，Microsoft建议保留所有就绪的SQLEXPRESS实例，除非您确认系统没有任何其他使用该实例的相关应用程序。

确定这一点的一种方法是搜索其他应用程序可能连接或创建的其他数据库的Master数据库。

安全性

默认情况下，SQLServerExpress配置为保护您的数据。

在安装时，您会有机会根据要求进一步加强安全性或放松安全性。

您必须首先做出的决定就是选择安装实用工具配置SQLServerExpress实例的方式。

实例就是程序的一个副本。

从SQLServer2000版本开始，SQLServer允许您安装服务器的几个独立的实例。

每个实例都被视为独立的实体：

每个实例具有其自己的Master数据库、其自己的安全性配置以及其自己的磁盘和内存中的位置。

安装SQLServerExpress后，每个应用程序（或您）必须决定它是否与使用该服务器的共享实例的其他应用程序共存，或者它是否要求其自己的独立实例。

有几个与每个配置相关联的安全性问题，我将在下面进行阐述。

请注意，SQLServerExpress允许您安装多达15个实例，但是我希望人们不要安装多个实例，除非在非常特殊的情况下。

安装公用实例

默认情况下，SQLServerExpress假设您要创建（或使用）一个名为“SQLEXPRESS”的公用实例。

还可以命名一个“公用”实例，但是这假设您所安装的所有程序都可以分辩出这个独特的名称。

如果保留默认名称（SQLEXPRESS），其他应用程序可以自动共享这个公用实例。

利用这种方法，所有数据库都可以由一个单个的、共享Master数据库管理，并且有一个永远不需要显示的SA密码。

当使用公用实例时，您有可能看到其他安装的数据库，而其他应用程序也可能会看到您的数据库—除非您确保应用了适当的权限。

一般而言，对于家庭、个人或小型办公室实现，您通常不必担心一个应用程序会扰乱另一个数据库中的数据。

如果您安装一个单独的公用实例，那么只有一组SQLServerDLL、缓存和其他驻留内存的结构会加载到内存中。

这意味着只有一个SQLServer实例占用CPU资源。

安装独立的实例

在安装过程中，如果您将实例名设置为自己的值，那么安装程序会创建一个完全独立的SQLServerExpress版本。

该实例具有其自己的Master数据库、其自己的文件、DLL、内存占有空间以及其自己的SA密码。

除了可能已安装的任意其他实例外，每个独立的实例都会启动占用CPU周期的单独的SQLServer服务（程序）。

尽管该方法在某种意义上增加了安全性，只有那些被授予对该实例访问权限的程序才能看到它所管理的数据库，但是实现和维护却增加了很多成本。

这是因为每个实例都要复制DLL、缓存和其他内存中的结构。

安装默认实例

另一种方法就是在安装过程中删除实例名。

在这种情况下，SQLServerExpress作为默认实例安装，假设没有已安装的默认实例。

在这种方式中，只可以安装一个服务器实例。

同样，如果这是安装到系统上的唯一的实例，那么在其他配置之间差异就会非常小，除非当它连接SQLServerExpress时，我将在稍后对此进行讨论。

选择系统管理员的密码

SA密码是解开整个数据库的密钥。

系统管理员获准对数据库或数据库中的信息进行任何操作。

SA可以添加、更改或删除数据库，所有操作都可以在任何人不知道所做更改的情况下进行。

正确设置这个密码并对其进行保护是至关重要的。

当您使用公用实例安装SQLServerExpress时，只有一个SA密码需要关注。

由于只有在您选择使用Windows身份验证进行安装时，SA帐户才可以访问，所以SA密码永远不需要显示。

在任何情况下，当安装SQLServerExpress时，都要求您提供SA密码，但是在已发布的版本中，可以设置为随机（隐藏）的值。

Microsoft建议您配置SQLServerExpress实例以使用Windows集成安全性身份验证。

这意味着计算机和Windows域系统管理员帐户都被授予对SQLServerExpress实例的完全SA访问权限。

当然，您需要成为计算机或域管理员才能执行维护、安装数据库以及执行像更改数据库表值这样的简单操作。

这并不意味着使用SQLServerExpress的每个人都应该成为管理员。

它真正的意义在于，作为安装制度的组成部分，您需要创建“用户”或应用程序登录，并在应用程序需要的表格、视图、函数以及存储过程上设置适当的权限。

我将会在稍后对此进行更详细的讨论。

性能

SQLServerExpress已经摒弃了“调控器”的概念。

坦白地讲，我以前几乎没有看到调控器降低任何MSDE系统的情况，但是通过放弃调控器，Microsoft消除了有关SQLServer引擎可伸缩性的混淆。

SQLServerExpress有很多方法来限制可伸缩性。

正如在测试版中所配置的那样，SQLServerExpress只能处理缓冲池中1GB的系统RAM。

这限制了RAM缓存中数据页面和过程的数量。

任何SQLServer专业人士都可以告诉您改进性能的最简单方法就是向缓存中增加内存。

将可见RAM限制在1GB意味着在您向SQLServerExpress实例中增加负载时，您将（最终）耗尽性能。

这是否意味着SQLServerExpress可以支持1000个用户呢？

当然，如果将负载放在SQLServerExpress实例上并不会那么完美。

在相同的情况下，10个用户就可以将SQLServerExpress陷入困境，尤其是如果应用程序编写得并不是非常有效时。

SQLServerExpress也限制到一个单个的处理器，而不可以在附加处理器（最多两个）上运行线程（如果系统支持）。

这种限制也压缩了您期望从SQLServerExpress获得的性能上限。

当使用SQLServerExpress的应用程序结束时，SQLServer并不会关闭。

在SQLServerExpress版本中并没有自动关闭选项。

因此，即使在您的应用程序结束后，SQLServer引擎也会保留在内存中，并继续占用系统RAM和CPU资源。

可以编写SQL管理对象（SMO）例程来关闭SQLServerExpress实例，但只有在您确认该实例没有被其他应用程序共享时，才可以完成该操作。

可伸缩性

尽管MSDE数据库限制在2GB，SQLServerExpress数据库文件却限制在4GB。

这意味着可以比以前多存储一倍的数据。

坦白地讲，这使我很困惑。

我曾经在大型机上使用过大型的公司数据库，它在单个40MB磁盘包上非常适合。

我猜想人们喜欢使用数据库来存储其宠物的大量文档和图片。

对于MSDE而言，日志文件大小并不受限制—至少表面上看是这样。

您仍然需要周期性地备份或截断日志，我将在稍后进行讨论。

工具

Microsoft同时还更改了其对工具的访问方法。

即使您不将新的GUI安装程序计算在内，当您下载SQLServerExpressBeta2时，新的OSQL版本、SQL计算机管理器（MMC管理单元）以及SQLCMD命令行工具都包括在其中，以协助管理SQLServerExpress实例。

此外，Microsoft计划设计一个新的GUI工具（暂时命名为SQLExpressManager），以执行SQLServer数据库的初始配置和周期性维护。

这个工具很快可用于独立下载，基本上可以说，它是不同于SQL查询分析器的工具，可以执行用户帐户设置和维护以及协助编写、测试和调试SQL查询。

您不能使用其他任何工具连接到SQLServerExpress，包括ManagementStudio或SQL企业管理器。

但是，我希望在它发布前，当前的任何工具都可以访问SQLServerExpress。

管理

要管理MSDE，您只须对SQLServerExpress进行操作，这与对SQLServer的其他版本所做操作相同。

我希望看到一个可以周期性地转储数据库和日志然后截断日志的自动日志备份脚本。

或许，这就是企业第三方需要创建的脚本。

到那时，我建议开发人员将这些管理任务构建到他们的应用程序中，然后使用SMO来执行这些需要的维护功能，并且使用Windows计划程序来进行协助。

ServicePack

SQLServerExpress只能使用WindowsInstaller（MSI）安装软件包文件进行安装。

与MSDE不同，您将无法创建自定义的MSM安装脚本。

在其他方面中，它与MSDE相同，因此您仍然需要准备通过传统的ServicePack方式来更新SQLServer引擎。

在Microsoft工作的人都敏锐地意识到与此相关的问题，并且仍然在规划着更好的策略。

安装SQLServerExpressEdition

与MSDE不同，MSDE不支持任何形式的GUI安装实用工具，而SQLServerExpress允许命令行安装和GUI版本。

对于使用标准版版本或更高版本的开发人员来说，这个安装版本是非常熟悉的。

但是，在该过程的早期，SQLServerExpressGUI安装程序出现对话框（如图1所示），询问用户是否要设置AdvancedConfiguration选项。

默认情况下，安装程序会配置正在进行安装的SQLServerExpress实例来使用集成安全性，同时禁用对TCP端口和外部协议的所有访问。

这意味着您将无法从其他系统或使用SQLServer凭据来访问SQLServerExpress实例，除非更改高级配置选项。

图1.捕获SQLServerExpressGUI安装实用工具的注册信息

选择安全性模式

SQLServerExpress安装实用工具允许您在身份验证模式对话框（如图2所示）中设置服务器所使用的安全性类型。

正如我将在稍后讨论的那样，默认模式是WindowsAuthentication，它会根据域ActiveDirectory数据库来验证用户凭据。

在理解切换到SQLServerMixedMode安全性的安全意义之前，最好保留为默认模式。

例如，混合模式（SQLServer）安全性强制开发人员指出隐藏由其应用程序所使用的SQLServer凭据的方法，以防止肆无忌惮的黑客的使用。

尽管如此，最好还是坚持使用默认设置，除非您的设计使该配置无法使用。

兴趣使然黑客从何处来？

在伦敦举行的DiligenceInformationSecurity研讨会上，一项调查表明大多数“黑客”（那些试图获得对受保护的数据进行XX访问的人）是公司防火墙内部的个人—并且大多数（到目前为止）都是公司的正式员工。

不管您选择的安全性类型如何，安装实用工具都将要求您提供SA密码。

尽管它要求您需要提供“强”密码，这实际上是域密码强度设置的功能。

我提倡您使用格式规范的强密码，但是如果使用Windows身份验证模式，这一点就并不那么重要了。

实用工具不会让您将其保留为空。

图2.设置由SQLServerExpress实例使用的身份验证模式

安装SQLServer计算机管理器扩展

与SQLServerExpress安装的一