SQL总结-最佳做法检查表.doc

总结：最佳做法检查表以下检查表总结了本白皮书中讨论的各种最佳做法。有关详细信息，请参阅上面的讨论。管理员检查表在安装之前设置环境物理安全 确保服务器的物理安全。防火墙 在服务器和 Internet 之间放置防火墙。 总是在外围防火墙上阻止 TCP 端口 1433 和 UDP 端口 1434。如果命名实例在其他端口上侦听，则还要阻止这些端口。 在多层环境中，使用多个防火墙创建屏蔽子网。服务隔离 隔离服务，降低受到威胁的服务被利用来危害其他服务的风险。 绝对不要在域控制器上安装 SQL Server。 以单独的 Windows 帐户身份运行单独的 SQL Server 服务。 在多层环境中，在单独的计算机上运行 Web 逻辑和业务逻辑。服务帐户 创建 Windows 帐户，尽可能只让其具有运行 SQL Server 服务所需的最小特权。文件系统 使用 NTFS。 对关键的数据文件使用 RAID。安装最新版本和 Service Pack 总是安装最新的 Service Pack 和安全修补程序。服务帐户 使用尽可能具有最低特权的帐户运行 SQL Server 服务。 使用企业管理器将服务与 Windows 帐户相关联。身份验证模式 要求使用 Windows 身份验证与 SQL Server 连接。强密码 即使在使用 Windows 身份验证时，也总是为 sa 帐户指派强密码。 对所有 SQL Server 帐户都总是使用强密码。 安装之后的配置选项和设置删除或保护旧安装文件 在安装之后删除或存档下列文件：sqlstp.log、sqlsp.log 和 setup.iss。对于默认安装，这些文件位于 :Program FilesMicrosoft SQL ServerMSSQLInstall 文件夹中；对于命名实例，这些文件位于 :Program FilesMicrosoft SQL Server MSSQL$ Install 文件夹中。 如果当前系统是从 SQL Server 7.0 升级的，请删除下列文件：%Windir% 文件夹中的 setup.iss；Windows Temp 文件夹中的 sqlsp.log。 为命名实例选择静态端口 为 SQL Server 的命名实例分配静态端口。安装之后的配置选项和设置（续）设置登录审核级别 将登录审核级别设置为“失败”或“全部”。 启用安全审核 对 Sysadmin 操作、固定角色成员身份更改、所有与登录相关的活动以及密码更改启用安全审核。 在选择适当的审核选项之后，应该编写审核脚本，将它包装在存储过程中，并将该存储过程标记为 AutoStart。即使在 Windows 身份验证模式下也要保护 sa 帐户的安全 即使在配置为要求进行 Windows 身份验证的服务器上，也要为 sa 帐户指派强密码。 删除示例数据库 从生产服务器中删除示例数据库。安全操作安全模型 学会使用 SQL Server 安全模型。备份策略 定期备份所有数据并将副本存放在安全的非现场位置。 测试灾难恢复系统。减少功能、减小受攻击范围 通过只运行环境所必需的服务和功能，减小系统受到攻击的范围。减少管理员 限制少数几个受信任用户拥有 sysadmin 固定服务器角色的成员身份。强密码 确保对于所有的 SQL Server 帐户使用复杂密码。 跨数据库所有权链接 如果系统不使用跨数据库所有权链接，请禁用它。Xp_cmdshell 在默认情况下，只有 sysadmin 角色的成员能够执行 xp_cmdshell。不应更改此默认设置。 不要将执行 xp_cmdshell 的权限授予 sysadmin 角色成员以外的用户。加密 安装证书以启用 SSL 连接。 证书应该使用服务器的完全限定的 DNS 名称。 在 SQL Server 服务帐户下使用 EFS 加密数据库文件。 如果应用程序要求加密数据，请考虑使用诸如 Protegrity 和 Application Security Inc. 之类的供应商的产品。角色和组 将用户汇集到 SQL Server 角色或 Windows 组中以简化权限管理。权限 绝对不要向 public 数据库角色授予权限。 分布式查询 在支持分布式查询的环境中设置 SQL Server 时，使用链接服务器（而不要使用远程服务器）。 仅将链接服务器的访问权限授予那些需要它的登录。 对于除 sysadmin 固定服务器角色的成员以外的所有用户，禁止对除 SQL OLE DB 以外的所有提供程序进行特殊 (ad hoc) 数据访问。 只允许对受信任的提供程序进行特殊数据访问。来宾帐户 不要启用来宾帐户。安全操作（续）服务帐户 如果需要更改与 SQL Server 服务相关联的帐户，请使用 SQL Server 企业管理器。 如果更改多个服务，则必须使用企业管理器将所做的更改分别应用于每个服务。建议的定期管理过程Microsoft 基准安全分析器 (MBSA) 将 MBSA 添加到每周维护计划中，并按照计划中的任何安全建议操作。扫描登录 定期扫描帐户，查看是否有使用空密码的帐户，并删除使用空密码的帐户或为它们指派强密码。 删除不再使用的帐户。枚举固定角色成员成份 定期扫描固定服务器和数据库角色，确保只将成员身份授予受信任用户。启动过程 验证已被标记为 AutoStart 的存储过程是否安全。登录到用户的映射 确保数据库用户与服务器级登录之间的映射正确无误。 定期运行带有 report 选项的 sp_change_users_login，确保映射按预期方式工作。直接更新目录 不允许直接更新目录。跨数据库所有权链接 使用 sp_dboption 枚举和验证启用了跨数据库所有权链接的数据库。修补实例的最佳做法实例检测和枚举 保留您所负责的 SQL Server 的所有版本和语言清单。 在清单中包括 MSDE 实例。 使用 SQL Scan 和 SQL Check（可从 Microsoft 网站获取），扫描域中的 SQL Server 实例。公告 订阅 Microsoft 安全公告。 修补应用程序 维护与生产系统的配置相匹配并且可用于测试新修补程序的测试系统。 在将修补程序应用于生产系统之前，认真测试修补程序。 考虑修补不需要太多测试的开发系统。开发人员检查表除上面的所有项目外，开发人员应将下列内容视为最佳做法。常规有效地使用所有权链接 在单个数据库中使用所有权链接来简化权限管理。 尽可能避免使用跨数据库所有权链接。 如果必须使用跨数据库所有权链接，请确保这两个数据库总是部署为单个管理单元。使用角色来简化权限管理和所有权 向角色指派权限，而不要直接向用户指派权限。 如果希望在删除拥有对象的用户时不必更改应用程序，则可以让角色拥有对象，而不是让用户直接拥有对象。打开加密功能（SSL 或 IPSEC） 对服务器启用加密连接，并考虑只允许建立加密连接。 如果允许使用 SQL Server 身份验证，则强烈建议您使用 IPSec 加密网络层或者使用 SSL 加密会话。不将 SQL Server 错误传播回到用户 您的应用程序不应该将 SQL Server 错误返回给最终用户，而是将它们记录到日志中或者将它们传输给系统管理员。 防止受到 SQL 插入攻击 通过先验证所有的用户输入，然后将其传输到服务器，防止受到 SQL 插入攻击。 只允许具有最小特权的帐户将用户输入的内容发送到服务器，从而限制可能受损的范围。 使用必需的最小特权运行 SQL Server 本身。多层选项同一个域/受信任域（完整的 Windows 身份验证）如果应用程序服务器和数据库服务器位于同一个域中或者位于受信任域中，则应使用 Windows 身份验证，并配置“完全提供”功能（所有客户端上下文都与 SQL Server 建立通道连接）。这样，可以审核访问 SQL Server 的所有用户，允许执行 Windows 安全策略，并且无需将凭据存储在中间层。在该方案中，客户端连接到应用程序服务器，应用程序服务器从而模拟客户端并连接到 SQL Server。 应用程序服务器上的每个用户都必须在数据库服务器上有一个有效的 Windows 登录，且必须启用委派功能。 该方案中进行交互的所有系统（包括域控制器）都必须运行 Windows 2000 或更高版本。 用来运行应用程序的帐户必须能够委派其他帐户（即，必须针对此帐户打开 Active Directory 用户帐户选项“帐户可委派其他帐户”）。 客户端帐户必须能够被委派（确保取消选中 Active Directory 用户帐户选项“敏感帐户，不能被委派”）。 应用程序服务必须有一个有效的服务主体名称 (SPN)。注意 如果安全计划要求最小化用户对数据库服务器的访问权限或者企业策略禁止委派，建议不要在跨数据库或 Internet 级别的安装中使用“完全提供”功能。多层选项（续）混合方案（部分 Windows 身份验证）如果在面向 Internet 的层中，并非每个用户都有一个单独的 Windows 域帐户，则建议将身份验证分成几个阶段。在验证用户身份的外层，如果不加密整个会话，至少应该使用 SSL 加密凭据。应该使用 Windows 身份验证连接到数据库服务器，并在特权很小、只具有执行数据库服务器功能所必需的权限的单独安全上下文中转发事务信息。这样，可以将中间层有效地作为服务器和 Internet 之间的附加防御层。注意 建议不要在中间层和 SQL Server 之间使用 SQL Server 身份验证，因为使用 SQL Server 身份验证需要存储凭据。如果必须在中间层和 SQL Server 之间使用 SQL Server 身份验证，那么应该创建几个帐户，并让它们分别具有与不同种类的用户对应的不同级别的特权。这要求您向中间层中添加逻辑，以便按照所需的特权级别分配连接。不同的非信任域或没有域（不进行 Windows 身份验证）如果不能在各层之间使用 Windows 身份验证，则应要求对登录序列进行 SSL 加密。最好加密整个会话。 还应使用 DPAPI 加密必须存储的凭据。 应将加密凭据存储在用 ACL 保护的注册表项中。软件供应商检查表除上面的所有项目外，下列安全开发做法也已被证明对于提高各种开发环境中代码的质量及安全性非常有用。 安全过程了解各种安全问题 确保开发小组的成员了解主要的安全问题：当前存在的威胁、安全趋势、更改安全环境以及受到攻击的情形。 要求对所有开发人员和测试人员进行相关的安全培训。 增强对跨站点脚本、缓冲区溢出、SQL 插入和危险的 API 等问题的认识。 确定对产品构成威胁的各种具体类型，例如拒绝服务、特权升级、欺骗、篡改数据、信息泄漏和丢弃。 针对每个组件逐一分析产品受到的安全威胁。 基于产品构建安全威胁检查表。 在产品开发周期的每个阶段（从设计到测试）增加安全审核步骤。安全过程（续）安装 MSDE如果将 MSDE 与应用程序一起分发，则应遵守下列附加准则： 使用“Windows 安全模式”作为默认设置安装 MSDE。 绝对不要使用空的 sa 密码。