Não.
Embora a documentação tenha atualmente a seguinte declaração indiscutivelmente ambígua sobre o que essa bandeira significa:
A política de senha está marcada.
O que realmente significa e deve dizer é que a bandeira serve a dois propósitos:
- A política de senha pode ter sido verificada, mas apenas se (a) a política de senha foi ativada no momento em que a senha foi definida pela última vez e (b) a senha foi especificada em texto sem formatação (não com hash).
- 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 ativada naquele momento e (b) a senha for especificada em texto sem formatação (não com hash).
(E observe que "a política" também se refere à imposição da 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 focar apenas nesse aspecto. )
O is_policy_checkedbit é definido como 1se CHECK_POLICY = ONdurante um evento CREATE LOGINou ALTER LOGIN, mesmo que a política não seja verificada no momento. Como você provavelmente pode coletar de cima, essa verificação não ocorre nos seguintes cenários:
- A senha é especificada usando a
HASHEDpalavra - chave (uma tática muito comum ao migrar logons entre servidores ou copiar logons para log enviados / espelhados / secundários AG). Obviamente, não é possível verificar a complexidade da senha se você não tiver o valor pré-hash.
- A política de complexidade da senha local não está ativada no momento em que o evento ocorre.
- Não abordado na reformulação proposta acima, mas você pode
ALTER LOGINdefinir uma nova senha e ainda assim alterar a sinalização ( obrigado a @AMtwo por ilustrar isso ). Suspeito que isso possa ter sido feito por pessoas inteligentes tentando enganar um auditor.
Todos esses problemas são fáceis de demonstrar.
Como a maioria das pessoas que eu falei para cerca de este ter sempre assumiu que is_policy_checkedrealmente significa que a senha atual atende a política de senha atual, eu acho que é importante que algo mude para que os usuários têm o direito expectativas e entender que esta bandeira não significa necessariamente tudo está bem. No mínimo, a documentação deve ser atualizada para refletir a realidade, como eu apontei acima. Mas há outras coisas que também podem ser feitas.
- 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 tentativa simples de ignorar ou defina a bandeira, por exemplo ALTER LOGIN blat WITH CHECK_POLICY = ON;).
CHECK_POLICYpoderia ser preterido, a favor ACTIVELY_CHECK_POLICYe talvez CHECK_POLICY_ON_NEXT_CHANGE. As colunas em sys.sql_loginsdevem ser policy_has_been_checkede policy_will_be_checked. Eu 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, eu recebo uma mensagem de erro e o sinalizador não deve ser definido como 1(ou mesmo a criação de login ou a alteração de senha não deve ser bem-sucedida).
- Acho que não faz sentido, neste caso, continuar com o comportamento atual, onde posso especificar que desejo 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 da bandeira após o fato - mas pelo menos se fosse definido
0, esses desvios poderão ser identificados).
Hoje, não existe uma maneira confiável - sem alterar manualmente suas senhas para algo que você sabe que é seguro - auditar seus logins SQL e ter certeza de que todos eles atendem à sua política de complexidade. Hoje em dia, com dados cada vez maiores, violações cada vez maiores e a necessidade óbvia de proteger cada vez mais os sistemas, esse é um problema que precisa ser resolvido. Eu escrevi um blog sobre isso e criei um item do Connect sobre ele:
Convido você a votar no item Connect e, mais importante, verifique se não está auditando seus sistemas com percepções falsas sobre como essas opções e metadados de DDL funcionam.
Por favor, não deixe isso de lado como um "não-problema", porque você está perfeitamente confortável com o funcionamento e já sabe que a bandeira não pode ser confiável - você não é o usuário com o qual estou preocupado; é todo mundo.
