SQL Server 密码策略.docx
《SQL Server 密码策略.docx》由会员分享，可在线阅读，更多相关《SQL Server 密码策略.docx（20页珍藏版）》请在冰豆网上搜索。
SQLServer密码策略
SQLServer2008密码策略 2008-11-2513:
59:
43
分类：
Linux
在WindowsServer2003或更高版本中运行时，SQLServer可以使用Windows密码策略机制。
SQLServer可以对在SQLServer内部使用的密码应用在WindowsServer2003中使用的相同复杂性策略和过期策略。
此功能需要通过NetValidatePasswordPolicyAPI实现，该API只在WindowsServer2003和更高版本中提供。
密码复杂性
密码复杂性策略通过增加可能密码的数量来阻止强力攻击。
实施密码复杂性策略时，新密码必须符合以下原则：
密码不得包含全部或部分用户帐户名。
部分帐户名是指三个或三个以上两端用“空白”（空格、制表符、回车符等）或任何以下字符分隔的连续字母数字字符：
逗号（,）、句点（.）、连字符（-）、下划线（_）或数字符号（#）。
密码长度至少为八个字符。
密码包含以下四类字符中的三类：
拉丁文大写字母（A-Z）
拉丁文小写字母（a-z）
10个基本数字（0-9）
非字母数字字符，如感叹号（!
）、美元符号（$）、数字符号（#）或百分号（%）。
密码最长可为128个字符。
使用的密码应尽可能长，尽可能复杂。
密码过期
密码过期策略用于管理密码的使用期限。
如果SQLServer实施密码过期策略，则系统将提醒用户更改旧密码，并禁用带有过期密码的帐户。
策略实施
可为每个SQLServer登录名单独配置密码策略实施。
使用ALTERLOGIN（Transact-SQL）来配置SQLServer登录名的密码策略选项。
配置密码策略实施时，适用以下规则：
如果CHECK_POLICY改为ON，则将出现以下行为：
除非将CHECK_EXPIRATION显式设置为OFF，否则也会将其设置为ON。
密码历史使用当前的密码哈希值初始化。
如果CHECK_POLICY改为OFF，则将出现以下行为：
CHECK_EXPIRATION也设置为OFF。
清除密码历史。
lockout_time的值被重置。
不支持策略选项的某些组合。
如果指定MUST_CHANGE，则CHECK_EXPIRATION和CHECK_POLICY必须设置为ON。
否则，该语句将失败。
如果CHECK_POLICY设置为OFF，则CHECK_EXPIRATION不能设置为ON。
包含此选项组合的ALTERLOGIN语句将失败。
重要提示：
只有在WindowsServer2003及更高版本上才会强制执行CHECK_EXPIRATION和CHECK_POLICY。
重要提示：
WindowsServer2003中的已知问题可以防止错误密码计数在达到LockoutThreshold后重置。
这可能会导致在后续登录尝试失败后立即锁定。
可以通过暂时设置CHECK_POLICY=OFF，然后设置CHECK_POLICY=ON来手动重置错误的密码计数。
当SQLServer在Windows2000中运行时，设置CHECK_POLICY=ON将禁止创建以下类型的密码：
为NULL或空
与计算机名或登录名相同
下列任意项：
“password”、“admin”、“administrator”、“sa”、“sysadmin”
可以在Windows中设置安全策略，也可以从域接收安全策略。
若要查看计算机上的密码策略，请使用本地安全策略MMC管理单元（secpol.msc）。
SQLServer2008的选择身份验证模式 2008-11-2513:
56:
22
分类：
Linux
在安装过程中，必须为数据库引擎选择身份验证模式。
可供选择的模式有两种：
Windows身份验证模式和混合模式。
Windows身份验证模式会启用Windows身份验证并禁用SQLServer身份验证。
混合模式会同时启用Windows身份验证和SQLServer身份验证。
Windows身份验证始终可用，并且无法禁用。
配置身份验证模式
如果在安装过程中选择混合模式身份验证，则必须为名为sa的内置SQLServer系统管理员帐户提供一个强密码并确认该密码。
sa帐户通过使用SQLServer身份验证进行连接。
如果在安装过程中选择Windows身份验证，则安装程序会为SQLServer身份验证创建sa帐户，但会禁用该帐户。
如果稍后更改为混合模式身份验证并要使用sa帐户，则必须启用该帐户。
您可以将任何Windows或SQLServer帐户配置为系统管理员。
由于sa帐户广为人知且经常成为恶意用户的攻击目标，因此除非应用程序需要使用sa帐户，否则请勿启用该帐户。
切勿为sa帐户设置空密码或弱密码。
若要从Windows身份验证模式更改为混合模式身份验证并使用SQLServer身份验证，请参阅如何更改服务器身份验证模式。
通过Windows身份验证进行连接
当用户通过Windows用户帐户连接时，SQLServer使用操作系统中的Windows主体标记验证帐户名和密码。
也就是说，用户身份由Windows进行确认。
SQLServer不要求提供密码，也不执行身份验证。
Windows身份验证是默认身份验证模式，并且比SQLServer身份验证更为安全。
Windows身份验证使用Kerberos安全协议，提供有关强密码复杂性验证的密码策略强制，还提供帐户锁定支持，并且支持密码过期。
通过Windows身份验证完成的连接有时也称为可信连接，这是因为SQLServer信任由Windows提供的凭据。
安全说明：
请尽可能使用Windows身份验证。
通过SQLServer身份验证进行连接
当使用SQLServer身份验证时，在SQLServer中创建的登录名并不基于Windows用户帐户。
用户名和密码均通过使用SQLServer创建并存储在SQLServer中。
通过SQLServer身份验证进行连接的用户每次连接时必须提供其凭据（登录名和密码）。
当使用SQLServer身份验证时，必须为所有SQLServer帐户设置强密码。
有关强密码的指南，请参阅数据库引擎配置-帐户设置。
可供SQLServer登录名选择使用的密码策略有三种。
用户在下次登录时必须更改密码
要求用户在下次连接时更改密码。
更改密码的功能由SQLServerManagementStudio提供。
如果使用该选项，则第三方软件开发人员应提供此功能。
强制密码过期
对SQLServer登录名强制实施计算机的密码最长使用期限策略。
强制实施密码策略
对SQLServer登录名强制实施计算机的Windows密码策略。
这包括密码长度和密码复杂性。
此功能需要通过NetValidatePasswordPolicyAPI实现，该API只在WindowsServer2003和更高版本中提供。
确定本地计算机的密码策略
在“开始”菜单上，单击“运行”。
在“运行”对话框中，键入secpol.msc，然后单击“确定”。
在“本地安全设置”应用程序中，依次展开“安全设置”、“帐户策略”，然后单击“密码策略”。
密码策略将如结果窗格中所示。
SQLServer身份验证的缺点
如果用户是具有Windows登录名和密码的Windows域用户，则还必须提供另一个用于连接的（SQLServer）登录名和密码。
记住多个登录名和密码对于许多用户而言都较为困难。
每次连接到数据库时都必须提供SQLServer凭据也十分烦人。
SQLServer身份验证无法使用Kerberos安全协议。
SQLServer登录名不能使用Windows提供的其他密码策略。
SQLServer身份验证的优点
允许SQLServer支持那些需要进行SQLServer身份验证的旧版应用程序和由第三方提供的应用程序。
允许SQLServer支持具有混合操作系统的环境，在这种环境中并不是所有用户均由Windows域进行验证。
允许用户从未知的或不可信的域进行连接。
例如，既定客户使用指定的SQLServer登录名进行连接以接收其订单状态的应用程序。
允许SQLServer支持基于Web的应用程序，在这些应用程序中用户可创建自己的标识。
允许软件开发人员通过使用基于已知的预设SQLServer登录名的复杂权限层次结构来分发应用程序。
注意：
使用SQLServer身份验证不会限制安装SQLServer的计算机上的本地管理员权限。
SQLServer2008权限层次结构 2008-11-2513:
49:
33
分类：
Linux
数据库引擎管理着可以通过权限进行保护的实体的分层集合。
这些实体称为“安全对象”。
在安全对象中，最突出的是服务器和数据库，但可以在更细的级别上设置离散权限。
SQLServer通过验证主体是否已获得适当的权限来控制主体对安全对象执行的操作。
下图显示了数据库引擎权限层次结构之间的关系。
使用权限
可以使用常见的Transact-SQL查询GRANT、DENY和REVOKE来操作权限。
有关权限的信息，可以从 sys.server_permissions 和 sys.database_permissions 目录视图中看到。
也可以使用内置函数来查询权限信息。
关于数据库安全性和保护的一些知识
1，用户：
数据库用户是数据库级别上的主体。
每个数据库用户都是 public 角色的成员。
guest 用户
创建数据库时，该数据库默认包含 guest 用户。
授予 guest 用户的权限由在数据库中没有用户帐户的用户继承。
不能删除 guest
2，应用程序角色：
应用程序角色是一个数据库主体，它使应用程序能够用其自身的、类似用户的权限来运行。
使用应用程序角色，可以只允许通过特定应用程序连
接的用户访问特定数据。
与数据库角色不同的是，应用程序角色默认情况下不包含任何成员，而且是非活动的。
应用程序角色使用两种身份验证
模式。
可以使用 sp_setapprole 启用应用程序角色，该过程需要密码。
因为应用程序角色是数据库级主体，所以它们只能通过其他数据库中为
guest 授予的权限来访问这些数据库。
因此，其他数据库中的应用程序角色将无法访问任何已禁用 guest 的数据库。
在 SQL Server 中，应用程序角色无法访问服务器级元数据，因为它们不与服务器级主体关联。
若要禁用此限制，从而允许应用程序角色访问服
务器级元数据，请设置全局标志 4616
连接应用程序角色
应用程序角色切换安全上下文的过程包括下列步骤：
用户执行客户端应用程序。
客户端应用程序作为用户连接到 SQL Server。
然后应用程序用一个只有它才知道的密码执行 sp_setapprole 存储过程。
如果应用程序角色名称和密码都有效，则启用应用程序角色。
此时，连接将失去用户权限，而获得应用程序角色权限。
通过应用程序角色获得的权限在连接期间始终有效。
在 SQL Server 的早期版本中，用户若要在启动应用程序角色后重新获取其原始安全上下文，唯一的方法就是断开 SQL Server 连接，然后再重
新连接。
从 SQL Server 2005 开始，sp_setapprole 有了一个可创建 cookie 的选项。
Cookie 包含启用应用程序角色之前的上下文信息。
sp_unsetapprole 可以使用此 Cookie 将会话恢复到其原始上下文。
有关这个新选项和示例的信息，请参阅 sp_setapprole （Transact-SQL）。
安全说明：
SqlClient 不支持 ODBC encrypt 选项。
通过网络传输机密信息时，请使用安全套接字层 （SSL） 或 IPSec 对通道进行加密。
如果必须使凭据
在客户端应用程序中持久化，请使用加密 API 函数来加密凭据。
在 SQL Server 2005 及更高版本中，参数 password 将作为单向哈希进行存储
。
3，SID和ID
如果要编写与 SQL Server 引擎进行交互的代码，则应该注意用作主体内部表示形式的两个号码。
每个主体都具有一个 ID 和一个安全 ID
（SID）。
这些号码的含义和源取决于主体的创建方式，同时与主体是服务器主体还是数据库主体有关。
服务器级标识号
创建 SQL Server 登录名时，便会为它分配一个 ID 和一个 SID。
这些号码在 sys.server_principals 目录视图中显示为 principal_id 和
SID。
ID （principal_id） 将登录名标识为服务器上的安全对象。
创建登录名时由 SQL Server 分配此 ID。
删除登录名时，将回收其 ID 号。
SID 标识登录名的安全上下文，并且在服务器实例中是唯一的。
SID 的源取决于登录名的创建方式。
如果通过 Windows 用户或组创建登录名，
则会为它指定源主体的 Windows SID；Windows SID 在域中是唯一的。
如果通过证书或非对称密钥创建 SQL Server 登录名，则会为它分配源
自公钥的 SHA-1 哈希的 SID。
如果按照需要密码的、早期样式的 SQL Server 登录名创建登录名，则服务器将生成一个 SID。
数据库级标识号
创建数据库用户时，便会为它分配一个 ID 和一个安全 ID （SID）。
这些号码在 sys.database_principals 目录视图中显示为 principal_id
和 SID。
ID 将用户标识为数据库中的安全对象。
删除数据库用户时，将回收其 ID。
分配给数据库用户的 SID 在数据库中是唯一的。
SID 的源
取决于数据库用户的创建方式。
如果通过 SQL Server 登录名创建用户，则会为它指定登录名的 SID。
如果通过证书或非对称密钥创建用户，则
SID 源自公钥的 SHA-1 哈希。
最大数据库用户数
最大数据库用户数由用户 ID 字段的大小确定。
用户 ID 的值必须为零或正整数。
在 SQL Server 2000 中，将用户 ID 存储为 16 位的
smallint（其中一位是符号）。
因此，SQL Server 2000 中最大用户 ID 数是 2的15次方 = 32,768。
在 SQL Server 2005 及更高版本中，将
用户 ID 存储为 32 位的 int（其中一位是符号）。
这些附加的位可以分配 2的31次方 = 2,147,483,648 的 ID 号。
数据库用户 ID 划分为预分配的范围省略。
--图片在我空间
用户 ID 大小从 smallint（16 位）增加到 int（32 位）。
如果传递的是 32 位用户 ID，则要求使用 16 位用户 ID 的 API 将返回错误结果
。
当迁移为 SQL Server 2000 或早期版本创建的数据和应用程序时，应检查代码是否引用了以下不推荐使用的接口。
sysusers
syscacheobjects
sysmembers
sysobjects
syspermissions
sysprocesses
sysprotects
systypes
USER_ID
这些接口需要 16 位用户 ID。
当使用 32 位用户 ID 时，这些接口将返回错误结果。
4，如何创建数据库用户：
使用 SQL Server Management Studio 创建数据库用户
在 SQL Server Management Studio 中，打开对象资源管理器，然后展开“数据库”文件夹。
展开要在其中创建新数据库用户的数据库。
右键单击“安全性”文件夹，指向“新建”，再单击“用户”。
在“常规”页的“用户名”框中输入新用户的名称。
在“登录名”框中，输入要映射到数据库用户的 SQL Server 登录名的名称。
单击“确定”。
使用 Transact-SQL 创建数据库用户
在查询编辑器中，通过执行以下 Transact-SQL 命令连接至要在其中创建新数据库用户的数据库：
USE
GO
通过执行以下 Transact-SQL 命令创建用户：
CREATE USER FOR LOGIN ;
GO
5，如何创建 SQL Server 登录名：
创建使用 Windows 身份验证 （SQL Server Management Studio） 的 SQL Server 登录名
在 SQL Server Management Studio 中，打开对象资源管理器并展开要在其中创建新登录名的服务器实例的文件夹。
右键单击“安全性”文件夹，指向“新建”，然后单击“登录名”。
在“常规”页上的“登录名”框中输入一个 Windows 用户名。
选择“Windows 身份验证”。
单击“确定”。
创建使用 SQL Server 身份验证 （SQL Server Management Studio） 的 SQL Server 登录名
在 SQL Server Management Studio 中，打开对象资源管理器并展开要在其中创建新登录名的服务器实例的文件夹。
右键单击“安全性”文件夹，指向“新建”，然后单击“登录名”。
在“常规”页上的“登录名”框中输入一个新登录名的名称。
选择“SQL Server 身份验证”。
Windows 身份验证是更安全的选择。
输入登录名的密码。
选择应当应用于新登录名的密码策略选项。
通常，强制密码策略是更安全的选择。
单击“确定”。
通过 Transact-SQL 创建使用 Windows 身份验证的 SQL Server 登录名
在查询编辑器中，输入以下 Transact-SQL 命令：
CREATE LOGIN FROM WINDOWS;
GO
通过 Transact-SQL 创建使用 SQL Server 身份验证的 SQL Server 登录名
在查询编辑器中，输入以下 Transact-SQL 命令：
CREATE LOGIN WITH PASSWORD = '' ;
GO
6，服务器级角色：
为便于管理服务器上的权限，SQL Server 提供了若干“角色”，这些角色是用于分组其他主体的安全主体。
“角色”类似于 Microsoft
Windows 操作系统中的“组”。
服务器级角色也称为“固定服务器角色”，因为您不能创建新的服务器级角色。
服务器级角色的权限作用域为服务器范围。
您可以向服务器级角色中添加 SQL Server 登录名、Windows 帐户和 Windows 组。
固定服务器角色的每个成员都可以向其所属角色添加其他登
录名。
下表显示了服务器级角色及其能够执行的操作。
服务器级角色名称 说明
sysadmin sysadmin 固定服务器角色的成员可以在服务器上执行任何活动。
默认情况下，Windows BUILTIN\Administrators 组（本
地管理员组）的所有成员都是 sysadmin 固定服务器角色的成员。
serveradmin serveradmin 固定服务器角色的成员可以更改服务器范围的配置选项和关闭服务器。
securityadmin securityadmin 固定服务器角色的成员可以管理登录名及其属性。
他们可以 GRANT、DENY 和 REVOKE 服务器级别的权限。
他们还可以 GRANT、DENY 和 REVOKE 数据库级别的权限。
此外，他们还可以重置 SQL Server 登录名的密码。
processadmin processadmin 固定服务器角色的成员可以终止在SQL Server 实例中运行的进程。
setupadmin setupadmin 固定服务器角色的成员可以添加和删除链接服务器。
bulkadmin bulkadmin 固定服务器角色的成员可以运行 BULK INSERT 语句。
diskadmin diskadmin 固定服务器角色用于管理磁盘文件。
dbcreator dbcreator 固定服务器角色的成员可以创建、更改、删除和还原任何数据库。
7，数据库级别的角色：
为便于管理数据库中的权限，SQL Server 提供了若干“角色”，这些角色是用于分组其他主体的安全主体。
它们类似于 Microsoft Windows 操
作系统中的组。
数据库级角色的权限作用域为数据库范围。
SQL Server 中有两种类型的数据库级角色：
数据库中预定义的“固定数据库角色”和您可以创建的“灵活数据库角色”。
固定数据库角色是在数据库级别定义的，并且存在于每个数据库中。
db_owner 和 db_securityadmin 数据库角色的成员可以管理固定数据库角
色成员身份。
但是，只有 db_owner 数据库角色的成员能够向 db_owner 固定数据库角色中添加成员。
msdb 数据库中还有一些特殊用途的固定
数据库角色。
您可以向数据库级角色中添加任何数据库帐户和其他 SQL Server 角色。
固定数据库角色的每个成员都可向同一个角色添加其他登录名。
重要提示：
请不要将灵活数据库角色添加为固定角色的成员。
这会导致意外的权限升级。
下表显示了固定数据库级角色及其能够执行的操作。
所有数据库中都有这些角色。
数据库级别的角色名称 说明
db_owner db_owner 固定数据库角色的成员可以执行数据库的所有配置和维护活动，还可以删除数据库。
db_securityadmin db_securityadmin 固定数据库角色的成员可以修改角色成员身份和管理权限。
向此角色中添加主体可能会导致意外的
权限升级。
db_accessadmin db_accessadmin 固定数据库角色的成员可以为 Windows 登录名、Windows 组和 SQL Server 登录名添加或删除数据
库访问权限。
db_backupoperator db_backupoperator 固定数据库角色的成员可以备份数据库。
db_ddladmin db_ddl
升级会员 