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

Question

Quand je regarde dans sys.sql_logins, Je vois une colonne intitulée is_policy_checked. Puis-je avoir confiance que ma stratégie de mot de passe a été vérifiée pour toutes les connexions où cette valeur de colonne est 1?

Aaron Bertrand · Accepted Answer

Non.

Alors que la documentation contient 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 politique de mot de passe peut-être a été vérifiée, mais seulement si (a) la politique 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 politique de mot de passe sera sera vérifiée la prochaine fois que la politique sera définie, mais seulement si (a) la politique de mot de passe est activée à ce moment, et (b) le mot de passe est spécifié en texte clair ( 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_checked le bit est défini sur 1 si CHECK_POLICY = ON au cours d'une CREATE LOGIN ou ALTER LOGIN événement, 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 mot clé HASHED (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 LOGIN sans définir de 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 auditeur.

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

Étant donné que la plupart des gens à qui j'en ai parlé ont toujours supposé que is_policy_checked signifie 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 pour que les utilisateurs aient les bonnes attentes et comprennent que ce drapeau ne signifie pas nécessairement que tout va 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 = ON est spécifié mais la politique ne peut en fait pas ê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 de définir l'indicateur , par exemple ALTER LOGIN blat WITH CHECK_POLICY = ON;).
CHECK_POLICY pourrait être déconseillé au profit de ACTIVELY_CHECK_POLICY et peut-être CHECK_POLICY_ON_NEXT_CHANGE. Les colonnes dans sys.sql_logins devrait être policy_has_been_checked et 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 = ON et la politique 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 ont pu ê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ûrs 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.

S'il vous plaît ne balayez pas cela comme un "non-problème" parce que vous sont parfaitement à l'aise avec la façon dont cela fonctionne et savez déjà que le drapeau n'est pas fiable - vous n'êtes pas l'utilisateur qui m'inquiète; c'est tout le monde.