Sys.sql_logins.is_policy_checked signifie-t-il que la stratégie a été vérifiée?

Quand je regarde dedans sys.sql_logins, je vois une colonne appelée is_policy_checked. Puis-je avoir confiance que ma politique de mot de passe a été vérifiée pour toutes les connexions où se trouve cette valeur de colonne 1?

— Aaron Bertrand
source

Non.

Bien que la documentation contienne actuellement la déclaration sans doute ambiguë sur la signification de cet indicateur:

La politique de mot de passe est vérifiée.

Ce que cela signifie et devrait dire, c'est que le drapeau a deux objectifs:

La stratégie de mot de passe a peut- être été vérifiée, mais uniquement si (a) la stratégie de mot de passe a été activée au moment de la dernière définition du mot de passe et (b) le mot de passe a été spécifié en texte brut (pas avec un hachage).

La stratégie de mot de passe sera vérifiée la prochaine fois que la stratégie est définie, mais uniquement si (a) la stratégie de mot de passe est activée à ce moment, et (b) le mot de passe est spécifié en texte brut (pas avec un hachage).

(Et notez que "la politique" se réfère également à l'application de l'expiration et au fait que l'utilisateur doit changer le mot de passe lors de la prochaine connexion, mais comme la complexité est généralement au centre des opérations d'audit, je vais me concentrer uniquement sur cet aspect. )

Le is_policy_checkedbit est défini sur 1if CHECK_POLICY = ONpendant un événement CREATE LOGINou ALTER LOGIN, même si la stratégie n'est pas vérifiée à ce moment-là. Comme vous pouvez probablement le constater ci-dessus, cette vérification ne se produit pas dans les scénarios suivants:

Le mot de passe est spécifié à l'aide du HASHEDmot - clé (une tactique très courante lors de la migration des connexions entre les serveurs ou de la copie des connexions pour journaliser les secondaires expédiés / mis en miroir / AG). Il n'est évidemment pas possible de vérifier la complexité du mot de passe si vous n'avez pas la valeur pré-hachée.
La stratégie de complexité du mot de passe local n'est pas activée au moment où l'événement se produit.
Non couvert dans ma proposition de reformulation ci-dessus, mais vous pouvez ALTER LOGINsans définir un nouveau mot de passe et toujours changer le drapeau ( merci à @AMtwo pour l'illustrer ). Je soupçonne que cela a peut-être été fait par des gens intelligents essayant de tromper un vérificateur.

Ces problèmes sont tous faciles à démontrer.

Étant donné que la plupart des gens à qui j'ai parlé de cela ont toujours supposé que cela is_policy_checkedsignifie en fait que le mot de passe actuel répond à la politique de mot de passe actuelle, je pense qu'il est important que quelque chose change ici afin que les utilisateurs aient les bonnes attentes et comprennent que ce drapeau ne signifie pas nécessairement Tout est bien. À tout le moins, la documentation devrait être mise à jour pour refléter la réalité, un peu comme je l'ai souligné ci-dessus. Mais il y a aussi d'autres choses qui peuvent être faites.

Un avertissement pourrait être émis si CHECK_POLICY = ONest spécifié mais la politique ne peut pas, en fait, être vérifiée (soit parce que le mot de passe est spécifié avec un hachage, soit parce que la politique de mot de passe a été désactivée, soit parce que la commande est une simple tentative de contourner ou définir le drapeau, par exemple ALTER LOGIN blat WITH CHECK_POLICY = ON;).
CHECK_POLICYpourrait être déconseillé, en faveur de ACTIVELY_CHECK_POLICYet peut-être CHECK_POLICY_ON_NEXT_CHANGE. Les colonnes dans sys.sql_loginsdoivent être policy_has_been_checkedet policy_will_be_checked. Je ne suis pas marié à ces noms, mais ils sont beaucoup plus précis que le libellé actuel.
Si je choisis ACTIVELY_CHECK_POLICY = ONet que la stratégie ne peut pas être vérifiée pendant l'exécution de la commande, je devrais recevoir un message d'erreur et l'indicateur ne devrait pas être défini sur 1(ou même la création de connexion ou le changement de mot de passe ne devrait pas réussir).
Je ne pense pas qu'il soit logique dans ce cas de continuer avec le comportement actuel, où je peux spécifier que je veux que la politique soit vérifiée, mais même si ce n'est pas le cas, le mot de passe est autorisé et la connexion est créée / modifiée (c'est mauvais, à mon humble avis, quel que soit l'état du drapeau après coup - mais au moins s'il était réglé sur 0, de tels contournements pourraient être identifiés).

Aujourd'hui, il n'existe aucun moyen fiable - sans changer manuellement leurs mots de passe en quelque chose que vous savez sûr - pour auditer vos connexions SQL et être sûr qu'ils répondent tous à votre politique de complexité. En cette époque de données en constante augmentation, de plus en plus de violations de données et du besoin évident de sécuriser de plus en plus les systèmes, c'est un problème qui doit être résolu. J'ai blogué à ce sujet et créé un élément Connect à ce sujet:

Je vous encourage à voter sur l'élément Connect et, plus important encore, assurez-vous que vous n'auditez pas vos systèmes avec de fausses perceptions sur le fonctionnement de cette option DDL et des métadonnées.

Veuillez ne pas écarter cela comme un "non-problème" parce que vous êtes parfaitement à l'aise avec son fonctionnement et savez déjà que le drapeau ne peut pas faire confiance - vous n'êtes pas l'utilisateur qui m'inquiète; c'est tout le monde.

— Aaron Bertrand
source