Início / dba / Perguntas / 99262
Accepted
Aaron Bertrand
Asked: 2015-05-01 07:28:56 +0800 CST

sys.sql_logins.is_policy_checked significa que a política foi verificada?

  • 772

Quando olho para dentro sys.sql_logins, vejo uma coluna chamada is_policy_checked. Posso confiar que minha política de senha foi verificada para todos os logins onde está o valor desta coluna 1?

sql-server security

1 respostas

  1. Best Answer

    ##Não. Embora a documentação atualmente tenha a seguinte declaração indiscutivelmente ambígua sobre o que esse sinalizador significa:

    A política de senha está marcada.

    O que realmente significa, e deveria dizer, é que a bandeira serve a dois propósitos:

    1. A política de senha pode ter sido verificada, mas apenas se (a) a política de senha foi habilitada no momento em que a senha foi definida pela última vez e (b) a senha foi especificada em texto simples (não com um hash). 2. A política de senha será verificada na próxima vez que a política for definida, mas somente se (a) a política de senha estiver habilitada naquele momento e (b) a senha for especificada em texto simples (não com um hash).

    (E observe que "a política" também se refere à imposição de expiração e ao fato de que o usuário deve alterar a senha no próximo login, mas como a complexidade normalmente é o foco das operações de auditoria, vou me concentrar apenas nesse aspecto. )

    O is_policy_checkedbit é definido como 1if CHECK_POLICY = ONdurante um evento CREATE LOGINou ALTER LOGIN, mesmo que a política não esteja marcada no momento. Como você provavelmente pode perceber acima, esta verificação não acontece nestes cenários:

    • A senha é especificada usando a palavra- HASHEDchave (uma tática muito comum ao migrar logins entre servidores ou copiar logins para logs enviados / espelhados / AG secundários). Obviamente, não é possível verificar a complexidade da senha se você não tiver o valor pré-hash.
    • A política de complexidade de senha local não está habilitada no momento em que o evento ocorre.
    • Não coberto na reformulação proposta acima, mas você pode ALTER LOGINsem definir uma nova senha e ainda alterar o sinalizador ( obrigado a @AMtwo por ilustrar isso ). Eu suspeito que isso pode ter sido feito por pessoas inteligentes tentando enganar um auditor.

    Todos esses problemas são fáceis de demonstrar.

    Como a maioria das pessoas com quem conversei sobre isso sempre assumiu que isso is_policy_checkedrealmente significa que a senha atual atende à política de senha atual, acho importante que algo mude aqui para que os usuários tenham as expectativas corretas e entendam que esse sinalizador não significa necessariamente tudo está bem. No mínimo, a documentação deve ser atualizada para refletir a realidade, algo como indiquei acima. Mas há outras coisas que podem ser feitas também.

    • Um aviso pode ser gerado se CHECK_POLICY = ONfor especificado, mas a política não pode, de fato, ser verificada (porque a senha é especificada com um hash, ou porque a política de senha foi desativada ou porque o comando é uma simples tentativa de ignorar ou defina o sinalizador, por exemplo ALTER LOGIN blat WITH CHECK_POLICY = ON;).
    • CHECK_POLICYpoderia ser obsoleto, em favor de ACTIVELY_CHECK_POLICYe talvez CHECK_POLICY_ON_NEXT_CHANGE. As colunas em sys.sql_loginsdevem ser policy_has_been_checkede policy_will_be_checked. Não sou casado com esses nomes, mas eles são muito mais precisos do que a redação atual.
    • Se eu escolher ACTIVELY_CHECK_POLICY = ONe a política não puder ser verificada durante a execução do comando, devo receber uma mensagem de erro e o sinalizador não deve ser definido como 1(ou mesmo a criação do login ou alteração da senha não deve ser bem-sucedida).
    • Não acho que faça sentido neste caso continuar com o comportamento atual, onde posso especificar que quero que a política seja verificada, mas mesmo que não possa, a senha é permitida e o login é criado/alterado (isso é ruim, IMHO, independentemente do estado do sinalizador após o fato - mas pelo menos se fosse definido como 0, esses desvios poderiam ser identificados).

    Hoje não há uma maneira confiável - sem alterar manualmente suas senhas para algo que você sabe que é seguro - para auditar seus logins SQL e ter certeza de que todos atendem à sua política de complexidade. Neste dia e idade de dados cada vez maiores, mais e mais violações de dados e a necessidade óbvia de proteger os sistemas cada vez mais, esse é um problema que precisa ser resolvido. Eu escrevi sobre isso e criei um item do Connect sobre isso:

    Encorajo você a votar no item Connect e, mais importante, certifique-se de não estar auditando seus sistemas com falsas percepções sobre como essa opção DDL e metadados funcionam.

    Por favor, não ignore isso como um "não-problema" porque você está perfeitamente confortável com a forma como funciona e já sabe que o sinalizador não é confiável - você não é o usuário com o qual estou preocupado; é todo mundo.

    • 21

relate perguntas