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

覗き込むとsys.sql_logins、という列が表示されis_policy_checkedます。この列の値が設定されているすべてのログインでパスワードポリシーがチェックされていることを信頼できます1か？

番号。

一方でドキュメントが現在何このフラグの意味について、以下の間違いなくあいまいな文があります。

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

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

1. パスワードポリシーがチェックされた可能性がありますが、（a）パスワードが最後に設定されたときにパスワードポリシーが有効になっており、（b）パスワードがプレーンテキストで指定されていた場合（ハッシュなし）。
2. パスワードポリシーは、次にポリシーが設定されたときにチェックされますが、（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_POLICYACTIVELY_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アイテムを作成しました。

• 大きなセキュリティの抜け穴を修正するのを手伝ってください
• 接続＃1250342：CHECK_POLICYは、CREATE LOGIN ... PASSWORD ... HASHEDの操作なしです

Connect項目に投票することをお勧めします。さらに重要なことは、このDDLオプションとメタデータがどのように機能するかについて誤った認識でシステムを監査していないことを確認することです。

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