sys.sql_logins.is_policy_checked 是否表示策略已被检查？

Question

当我查看时sys.sql_logins，我看到一个名为is_policy_checked. 我可以相信我的密码策略已经针对此列值所在的所有登录名进行了检查1吗？

Answer 1

不。

虽然文档目前对这个标志的含义有以下可以说是模棱两可的声明：

检查密码策略。

它真正的意思是，并且应该说，这面旗帜有两个目的：

密码策略可能已被检查，但前提是 (a) 在上次设置密码时启用了密码策略，并且 (b) 密码是以纯文本形式指定的（而不是散列）。

密码策略将在下次设置策略时检查，但前提是 (a) 当时启用了密码策略，并且 (b) 密码以纯文本形式（不使用哈希）指定。

（请注意，“策略”还指强制过期以及用户必须在下次登录时更改密码这一事实，但由于复杂性通常是审核操作的重点，因此我将只关注该方面。 )

该is_policy_checked位设置为1ifCHECK_POLICY = ON在CREATE LOGIN或ALTER LOGIN事件期间，即使当时未检查该策略。正如您可能从上面收集到的那样，在这些情况下不会发生此检查：

密码是使用HASHED关键字指定的（在服务器之间迁移登录或将登录复制到日志传送/镜像/AG 辅助服务器时，这是一种非常常见的策略）。如果您没有预先散列的值，显然无法检查密码的复杂性。
事件发生时未启用本地密码复杂性策略。
上面我提议的改写没有涵盖，但是您可以ALTER LOGIN不设置新密码，并且仍然可以更改标志（感谢@AMtwo 对此进行说明）。我怀疑这可能是聪明人试图愚弄审计师所做的。

这些问题都很容易证明。

由于我与之交谈的大多数人一直认为这is_policy_checked实际上意味着当前的密码符合当前的密码策略，我认为重要的是在这里进行一些更改，以便用户有正确的期望并了解此标志并不一定意味着一切都很好。至少，应该更新文档以反映现实，有点像我上面指出的那样。但也有其他事情可以做。

如果CHECK_POLICY = ON指定了但实际上无法检查策略，则可能会引发警告（因为密码是用散列指定的，或者因为密码策略已被禁用，或者因为该命令是一个简单的绕过尝试或设置标志，例如ALTER LOGIN blat WITH CHECK_POLICY = ON;）。
CHECK_POLICY可能会被弃用，支持ACTIVELY_CHECK_POLICY和也许CHECK_POLICY_ON_NEXT_CHANGE。中的列sys.sql_logins应该是policy_has_been_checked和policy_will_be_checked。我不喜欢这些名字，但它们比目前的措辞要准确得多。
如果我选择 ACTIVELY_CHECK_POLICY = ON并且在命令执行期间无法检查策略，我应该会收到一条错误消息，并且不应将标志设置为1（甚至登录创建或密码更改都不应该成功）。
我认为在这种情况下继续当前行为没有意义，我可以在其中指定我希望检查策略，但即使不能，也允许使用密码并创建/更改登录（这很糟糕，恕我直言，无论事后标志的状态如何 - 但至少如果它被设置为 0，则可以识别此类绕过）。

今天没有可靠的方法 - 无需手动将其密码更改为您认为安全的密码 - 来审核您的 SQL 登录并确信它们都符合您的复杂性策略。在当今数据不断增加、数据泄露事件越来越多以及显然需要越来越严密地保护系统的时代，这是一个需要解决的问题。我已经写了关于这个的博客并创建了一个关于它的连接项目：

我鼓励您对 Connect 项目进行投票，更重要的是，请确保您不会以对 DDL 选项和元数据如何工作的错误认识来审核您的系统。

请不要将其视为“非问题”，因为您对它的工作方式非常满意，并且已经知道该标志是不可信的——您不是我担心的用户；这是其他人。