SQL Server对于组织来说是个敏感信息库,管理者需要确保只有授权用户才能访问到这部分敏感信息。然而,要让SQL Server配置安全同时还不会产生错误,这不是一件容易的事,作为DBA我们不得不执行一系列额外步骤来强化我们的SQL Server部署安全配置。本文中列出了一份微软SQL Server数据库安全最佳实践检查表,能够帮助DBA更好地保护数据库,避免来自内部和外部的攻击。 认证 SQL Server支持两种模式的认证:Windows认证和混合模式认证。
根据SQL Server安全性最佳实践,我们建议为您的SQL Server部署选择Windows认证,除非遗留应用系统需要混合模式认……
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
SQL Server对于组织来说是个敏感信息库,管理者需要确保只有授权用户才能访问到这部分敏感信息。然而,要让SQL Server配置安全同时还不会产生错误,这不是一件容易的事,作为DBA我们不得不执行一系列额外步骤来强化我们的SQL Server部署安全配置。本文中列出了一份微软SQL Server数据库安全最佳实践检查表,能够帮助DBA更好地保护数据库,避免来自内部和外部的攻击。
认证
SQL Server支持两种模式的认证:Windows认证和混合模式认证。根据SQL Server安全性最佳实践,我们建议为您的SQL Server部署选择Windows认证,除非遗留应用系统需要混合模式认证向后兼容访问。
Windows认证比混合认证模式更安全,启用这种模式后,Windows认证凭据(也就是Kerberos或者Windows NT LAN管理器【NTLM】认证凭据)是允许登录到SQL Server的。Windows登录使用许多加密信息认证SQL Server,密码不会在认证期间跨网络传递。此外,在Kerberos协议下活动目录还提供了额外的安全级别。因此,认证就更加可靠,利用基于角色的活动目录组可以减少控制访问的管理工作。相比于Windows认证模式,混合模式认证支持Windows账号和SQL Server专用账号登陆SQL Server。SQL登陆密码通过网络传递用于认证,相比起来不如Windows登陆安全。
确保sySAdmin账号安全
如果不修改就退出,“sySAdmin”(SA)账号是很脆弱的。潜在的SQL Server攻击者们都意识到了这一点,如果他们控制了这个强大的用户,数据库攻击就更容易。为了防止使用“SA”账号进行攻击,可以把“SA”账号重命名为别的账号名称。我们可以按照以下操作实现这一点:在“对象资源管理器”中展开“登录”,右键点击“SA”账号并在菜单中选择“重命名”。或者我们也可以执行以下T-SQL脚本重命名“SA”账号:
USE [master] GO ALTER LOGIN SA WITH NAME = [] GO |
此外,也可以禁用SQL Server实例的“SA”账号。
为SA和SQL Server专用登录账号设置复杂密码
在使用混合认证模式时,要确保为“SA”账号和其它SQL Server上使用的SQL Server专用登录账号设置复杂密码。首先,为“SA”账号和所有其它SQL登录账号选中“强制密码过期”和“加强密码策略”选项。这两项可以保证所有其它SQL Server专用登录账号遵循底层操作系统的登录策略。除此之外,对所有新设置的SQL登录账号启用“MUST_CHANGE”选项。该选项确保登陆者必须在第一次登录后修改密码。
“sySAdmin”固定服务器角色和“CONTROL SERVER”权限资格
要谨慎选择sySAdmin固定服务器角色的资格,因为该角色可以在SQL Server上为所欲为。此外,不要明确授予“CONTROL SERVER”权限给Windows登录、Windows组登录和SQL Server登录,因为这种权限的登录获得了对整个SQL Server部署的完全管理员权限。默认情况下,sySAdmin固定服务器角色明确拥有这项权限。
SQL Server管理
要避免使用“SA”,或者任何其它已授予“CONTROL SERVER”权限的SQL登录账号,或者sySAdmin固定服务器角色下辖成员管理SQL Server实例。相反,要为DBA们设置专门的Windows登录账号,给这些账号分配“sySAdmin”权限作为管理用途。要给用户分配权限,可以使用内建的固定服务器角色或者数据库角色,也可以创建你自己定制的服务器角色和数据库角色满足你更精细化的权限控制。
禁用guest用户访问
默认情况下,guest用户存在于每个用户和系统数据库下,它是安全封闭环境下的潜在安全风险,因为它允许与数据库无关的用户登录访问数据库。由于这一潜在风险,我们需要在所有用户和系统数据库(除了msdb)中禁用guest用户。这样才能保证公共服务器角色成员不能访问SQL Server实例上的用户数据库,除非用户被明确授权访问这些数据库。
限制对公共角色授权
由于潜在的安全风险, 我们可以使用下面的扩展存储过程取消公共角色的访问权限。
此外,不要明确分配权限给用户公共角色和对系统存储过程的访问。要列出公共角色可用的存储过程,可以执行如下查询:
SELECT o.[name] AS [SPName] ,u.[name] AS [Role] FROM [master]..[sysobjects] o INNER JOIN [master]..[sysprotects] p ON o.[id] = p.[id] INNER JOIN [master]..[sysusers] u ON P.Uid = U.UID AND p.[uid] = 0 AND o.[xtype] IN ('X','P') |
减少SQL Server Surface Area
配置SQL Server时应该仅安装必要的功能特性,安装后使用SQL Server系统的外围界面禁用不需要的功能。你还可以使用基于策略的管理功能创建系统策略为一个或多个SQL Server系统实施精细配置设置。
强化SQL Server端口
另一项SQL Server安全性最佳实践是使用SQL Server配置管理器修改SQL Server安装时的默认端口。而且,要使用专门TCP端口替代动态端口。此外,要确保避开常见的TCP端口(比如1433和1434),不要用这些端口做客户端请求和交互,因为这些端口过于为人熟知,容易成为攻击目标。
禁用SQL Server浏览器服务
要确保SQL Server浏览器服务只运行在多个SQL Server实例运行其上的单个SQL Server上。SQL Server浏览器服务显示了网络环境中的SQL Server信息,这在安全封闭的环境中可能成为潜在安全威胁。
SQL Server服务账号
我们应该创建专用低权限域账户来运行SQL Server服务。此外,要定期检查SQL Server服务账号成员,确保它们不是任何域用户组或本地用户组的成员,因为那样会使这些用户具备不必要的权限。有关每个SQL Server服务账号所需权限的更多信息,请访问“配置Windows服务账号和权限”了解。
确保SQL Server错误日志和注册键的安全
使用NTFS权限确保SQL Server错误日志和注册键安全,因为它们可以展现关于SQL Server实例和安装的大量信息。
相关推荐
-
使用透明数据加密技术保护静态数据
透明数据加密(Transparent Data Encryption, TDE)是一个加密静态数据的有效工具。专家将在本文中详细介绍TDE的特性与未来。
-
SQL Server安全设置最佳实践
数据库管理员的主要职责之一是:确保他们所管理的所有SQL Server实例都安全。SQL Server安全本身是一个非常广泛的主题,这篇文章仅仅是我介绍的八个最佳实践。
-
SQL Server 2012安全性:功能更新
数据库基础架构的安全对于任何组织来说都是及其重要的,这也正是微软公司近几年在SQL Server安全功能方面投入巨大的原因。
-
SQL Server 2012安全性:案例分析
数据库备份被盗了,病毒攻击了服务器,数据库有未经授权的更改——如果SQL Server安全保护设置宽松的话,这些事情都会发生。