Clique no banner para conhecer e adquirir o meu treinamento de Bancos de Dados no Azure

SQL Server – Políticas de Senhas, Expiração de Senha, Troca de Senha Obrigatória e Bloqueio de Login após N tentativas

Esse post é a parte 20 de 20 da série Segurança e Auditoria
Tempo de Leitura: 10 minutos

Fala pessoal!
Nesse post eu gostaria de falar sobre a parte de Segurança de SQL Server voltada para senhas: Políticas de Senhas, Expiração de Senha, Troca de Senha Obrigatória e Bloqueio de Login após N tentativas.

Vídeo com o Resumo do Artigo

Se você gostou desse vídeo e quer aprofundar mais na parte de segurança de dados, não deixe de conferir o meu curso Segurança no SQL Server

Políticas de Senhas (CHECK_POLICY)

Clique aqui para visualizar esse conteúdo
O recurso de Política de Senha (CHECK_POLICY) do SQL Server tem como objetivo garantir que as senhas dos logins sejam senhas complexas, de modo a reduzir a possibilidade de ataques de força bruta. Vale lembrar que esse recurso de aplica apenas a usuários com autenticação SQL.

Um dos objetivos da política de senha é evitar esse tipo de cenário abaixo, onde alguém fique tentando autenticar no banco através de tentativa e erro, sem ser bloqueado, até ele achar uma combinação onde ele consiga se logar no banco.

Além de restringir senhas simples ou vazias, a política de senha pode bloquear automaticamente logins após N tentativas incorretas de usuário/senha (esse número é parametrizável), além de possibilitar que as senhas expirem após N dias e ela tenha que ser alterada periodicamente.

Importante: Para saber mais sobre ataques de força bruta, acesse o artigo SQL Server – Como evitar ataques de força bruta no seu banco de dados

Para criar um usuário com política de senha ativada, você pode utilizar esse comando:

Para verificar os logins SQL que não estão com a política de senha ativada, utilize a consulta abaixo:

Resultado:

Você também pode visualizar as propriedades do Login para confirmar se essa opção está ativada

Por falar em política de senha, você pode conferir neste link aqui a política de senha do Windows, utilizada pelo SQL Server para logins com autenticação SQL.

Ao ativar a política de senha para um login SQL, você deverá seguir a política abaixo:

  • A senha não pode conter o nome de conta do usuário
  • A senha deve ter um comprimento de pelo menos 8 (oito) caracteres
  • As senhas podem ter até 128 caracteres. Use senhas longas e complexas
  • Senhas Nulas ou em branco não são permitidas
  • Não é permitido utilizar como senha o mesmo nome do computador ou logon
  • Senhas que não são permitidas: “password”, “admin”, “administrator”, “sa”, “sysadmin”
  • A senha deve conter caracteres de pelo menos três das quatro categorias abaixo:
    – Letras maiúsculas latinas (A a Z)
    – Letras minúsculas latinas (a a z)
    – Números (0 a 9)
    – Caracteres não alfanuméricos como: ponto de exclamação (!), cifrão ($), sinal numérico (#) ou porcentagem (%).
Quando CHECK_POLICY é alterado para ON, o seguinte comportamento ocorre:

  • CHECK_EXPIRATION também é definido como ON, a menos que seja definido explicitamente como OFF
  • O histórico de senhas é inicializado com o valor do hash da senha atual
  • As opções duração do bloqueio de conta, limite de bloqueio de conta e zerar contador de bloqueios de conta após também estão habilitadas

Quando CHECK_POLICY é alterado para OFF, o seguinte comportamento ocorre:

  • CHECK_EXPIRATION também será definido como OFF
  • O histórico de senhas será apagado
  • O valor de lockout_time é redefinido

Para verificar nas configurações do Windows algumas informações adicionais como quantidade de falhas de login para bloquear um login, você pode abrir a tela do “Local Security Policy” digitando o comando “secpol.msc” no menu Iniciar

Ou na tela de Executar:

Navegue no diretório “Account Policies” e depois no diretório “Password Policy”

Existem algumas configurações interessantes aí nessa tela com relação à complexidade de senhas:

  • Enforce password history (Forçar histórico de senhas): Quantidade de senhas que serão armazenadas para garantir que uma senha já utilizada anteriormente seja utilizada de novo. Esse valor deve ser entre 0 e 24 senhas e o valor padrão é 0 (zero)
  • Minimum password length (Tamanho mínimo da senha): Bem óbvio aqui. Define a quantidade mínima de caracteres que uma senha deve ter para ser aceita como senha válida. Os valores aceitáveis para esse parâmetro são entre 1 e 14. O valor padrão é 0 (zero), o que significa não haver tamanho mínimo
  • Password must meet complexity requirements (Senha deve atender aos requisitos de complexidade): Esse parâmetro define se as políticas de senha deverão ser utilizadas e senhas que não se enquadrem na política sejam impedidas de serem criadas. O valor padrão é Enabled (Habilitado) e se for desativado, o SQL Server não irá validar complexidade de senha, mesmo que você ative a propriedade CHECK_POLICY no Login SQL

Ao tentar criar uma senha com menos caracteres que o definido nessa tela, você verá essa mensagem de erro:

Msg 15116, Level 16, State 1, Line 15
Password validation failed. The password does not meet the operating system policy requirements because it is too short.
Observação: Para saber mais sobre essas configurações do “Password Policy”, clique neste link aqui.

Expiração de Senhas (CHECK_EXPIRATION)

Clique aqui para visualizar esse conteúdo
Outro recurso interessante do ponto de vista de segurança, é a possibilidade de definir uma expiração das senhas dos logins SQL. Uma vez habilitado, essa opção (CHECK_EXPIRATION) irá expirar a senha do login após N dias e só será possível conectar ao trocar a senha.

Para criar um usuário cuja senha expira, você pode utilizar o comando abaixo:

Para verificar os usuários expirados ou próximos de expirar, você pode usar a consulta abaixo:

Resultado:

Você também pode visualizar as propriedades do Login para confirmar se essa opção está ativada

Para alterar a quantidade de dias que as senhas expiram, você pode abrir a tela do “Local Security Policy” digitando o comando “secpol.msc” no menu Iniciar

Ou na tela de Executar:

Navegue até a pasta “Account Policies” e depois “Password Policy”

Edite a propriedade “Maximum password age” e defina um número de 1 a 999 para definir a quantidade de dias que uma senha expira. O valor padrão são 42 dias.

Caso você defina o valor 0 (zero), isso quer dizer que a senha não irá expirar. Ou seja, mesmo que você habilite essa opção de expiração de senha no SQL Server, ele não irá expirar porque a configuração da política do Windows está definida para não expirar.

Observação: Para saber mais sobre essas configurações do “Password Policy”, clique neste link aqui.

Troca de Senha Obrigatória (MUST_CHANGE)

Clique aqui para visualizar esse conteúdo
A propriedade MUST_CHANGE define que o usuário obrigatoriamente deve trocar a senha na próxima vez que ele for conectar no banco de dados.

Para criar um login onde ele deverá trocar a senha logo na primeira utilização, você utilizar algo assim:

Importante: A opção MUST_CHANGE só pode ser utilizada se as opções CHECK_EXPIRATION e CHECK_POLICY estiverem definidas como ON.

Para visualizar os logins que estão com essa propriedade MUST_CHANGE habilitada, você pode usar a consulta abaixo:

Resultado:

Diferente das outras 2 propriedades (CHECK_POLICY e CHECK_EXPIRATION), não dá para visualizar na interface do SSMS se a propriedade MUST_CHANGE está habilitada, somente utilizando T-SQL.

Ao tentar logar com esse usuário no banco com esse usuário recém criado (teste3), você verá essa tela aqui:

Para forçar um login já existe a trocar a senha, você pode trocar a senha dele para uma qualquer e ativar a opção MUST_CHANGE

Importante: Não é possível ativar a opção MUST_CHANGE num login já existente sem trocar a senha atual para uma outra qualquer no mesmo comando ALTER LOGIN.

Bloqueio de Login após N tentativas

Clique aqui para visualizar esse conteúdo
Imagino que vocês saibam disso, mas o SQL Server só irá travar um login SQL se a opção de política de senha estiver habilitada para esse login e as configurações de política de senha do Windows/AD estiverem configuradas corretamente.

Se essa combinação não estiver configurada corretamente, você pode tentar conectar quantas vezes quiser, que o SQL só irá armazenar as falhas de conexão no log (caso esteja configurado para isso), mas não irá bloquear o login.

Uma forma de evitar que isso aconteça é utilizar apenas logins com autenticação Windows (melhor opção), ou então você definir um limite de quantidade de falha de logins para realizar o bloqueio automático.

Para fazer isso, você pode abrir a tela do “Local Security Policy” digitando o comando “secpol.msc” no menu Iniciar

Ou na tela de Executar:

Navegue no diretório “Account Policies” e depois no diretório “Account Lockout Policy”

A configuração padrão é essa do screenshot, sendo NÃO bloquear usuários por falhas de tentativas de conexão por erro de usuário/senha, o que acho bem inseguro.

Podemos até confirmar que com o valor 0 (zero), a senha NÃO será bloqueada por falhas de conexão

Vou alterar essa configuração para bloquear após 5 falhas de conexão seguidas

E logo após confirmar essa alteração, uma nova janela de diálogo aparece sugerido para alterar também as configurações de “Account lockout period” e “Reset account lockout counter after” para 30 minutos (esse valor pode ser alterado depois). Isso quer dizer que após 30 minutos, a conta será desbloqueada automaticamente e o contador de falhas de conexão será reiniciado.

A partir de agora, após 5 falhas (configurei esse valor) durante o processo de login, esse Login SQL será bloqueado automaticamente por 30 minutos (esse tempo é parametrizável também).

Ao continuar errando a senha, será mostrada a mensagem padrão para senha incorreta, mesmo que o usuário já esteja bloqueado:

Login failed for user ‘teste_politica_senha’. Reason: Password did not match that for the login provided.

Se a senha correta for digitada e o usuário estiver bloqueado, será mostrada essa mensagem de erro:

Login failed for user ‘teste_politica_senha’.Reason: The account is currently locked out. The system administrator can unlock it.

Para verificar os logins SQL bloqueados, você pode utilizar essa consulta:

Resultado:

Você também pode visualizar se essa opção está ativa pela interface do SSMS ao abrir as propriedades do Login SQL:

Vale lembrar que existe um tempo parametrizável onde o usuário será desbloqueado automaticamente após N minutos.

Observação: Para saber mais sobre essas configurações do “Account Lockup Policy”, clique neste link aqui.

Local Security Policy (Sem AD) ou Group Policy Management (Com AD)

Caso a máquina esteja em um domínio (bem provável), essas configurações de complexidade de senha, bloqueio automático e outras devem ser alteradas pelo utilitário “Group Policy Management” para que essas alterações sejam feitas no Windows Active Directory (Windows AD) e, logo depois, elas serão replicadas para todos os servidores:

Se você alterar apenas nas configurações locais do Windows do servidor, na próxima vez que as políticas forem atualizadas, essa alteração que você fez localmente será sobrescrita pela configuração do domínio.

Você pode utilizar o “Local Security Policy” (secpool.msc) para visualizar qual é a política atual que está sendo aplicada no servidor, pois provavelmente será a mesma do domínio.

Para forçar uma atualização das políticas locais do Active Directory para o computador local, você pode rodar o comando “gpupdate /force” no Prompt do DOS:

Caso a sua máquina NÃO esteja em um domínio, então basta alterar essas configurações no utilitário “Local Security Policy” (secpool.msc) mesmo, conforme mostrei no artigo.

E é isso aí, pessoal!
Um grande abraço e até a próxima!