sys.sql_logins.is_policy_checkedは、ポリシーがチェックされたことを意味しますか？

Question

sys.sql_loginsを見ると、is_policy_checkedという列があります。この列の値が1であるすべてのログインに対してパスワードポリシーがチェックされていることを信頼できますか？

Aaron Bertrand · Accepted Answer

番号。

ドキュメントには現在、このフラグが何を意味するかについて次の間違いのあるステートメントがあります：

パスワードポリシーがチェックされます。

それが実際に意味すること、そして言うべきことは、フラグが2つの目的を果たすということです。

パスワードポリシーmightがチェックされましたが、（a）パスワードが最後に設定されたときにパスワードポリシーが有効であり、（b）パスワードがプレーンで指定されている場合のみテキスト（ハッシュなし）。

パスワードポリシーは、次回ポリシーが設定されたときにチェックされますは、（a）パスワードポリシーがそのときに有効になっていて、（b）パスワードがプレーンテキスト（ハッシュなし）。

（「ポリシー」とは、有効期限を強制することと、ユーザーが次回ログイン時にパスワードを変更する必要があることも指しますが、通常は複雑さが監査操作の焦点であるため、その側面のみに焦点を当てます。）

is_policy_checkedまたは1イベント中にCHECK_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オプションとメタデータがどのように機能するかについて誤った認識でシステムを監査していないことを確認してください。

あなたはそれがどのように機能するかに完全に慣れているので、これを「非問題」として無視しないでくださいそしてフラグは信頼できないことをすでに知っています-あなたは私が心配しているユーザーではありません。それはみんなです。