- Auditing in SQL Server (Server Audit)
- How to Create an Audit to Monitor Job Creation, Modification, and Deletion in SQL Server
- How to create an Audit trigger to log object manipulation in SQL Server
- SQL Server - How to implement login auditing and control (Logon Trigger)
- Monitoring DDL and DCL operations using SQL Server's fn_trace_gettable
- Using the standard SQL Server trace to audit events (fn_trace_gettable)
- SQL Server – Permissions and privileges audit trigger at database and instance level (GRANT and REVOKE)
- SQL Server - How to monitor and audit data changes in tables using Change Data Capture (CDC)
- SQL Server 2016 - How to "time travel" using the Temporal Tables feature
- SQL Server - How to use auditing to map actual required permissions on a user
- SQL Server - Trigger to prevent and prevent changes in tables
- SQL Server - How to Create a Data Change History for Your Tables (Audit Logs)
- SQL Server - How to avoid brute force attacks on your database
- SQL Server – Security Checklist – An SP with over 70 security items to validate your database
- SQL Server - How to know the last login date of a user
- SQL Server - How to avoid and protect yourself from Ransomware attacks like WannaCry on your database server
- SQL Server - Watch out for the securityadmin server role! Using elevation of privileges to become sysadmin
- SQL Server – How to avoid SQL Injection? Stop using Dynamic Query like EXEC(@Query). Now.
- SQL Server - Understanding the risks of the TRUSTWORTHY property enabled on a database
- SQL Server - Password Policies, Password Expiration, Mandatory Password Change and Login Blocking after several Attempts
- SQL Server - How to create a login audit using instance logs
Hey guys!
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
Políticas de Senhas (CHECK_POLICY)
Clique aqui para visualizar esse conteúdoUm 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.
Para criar um usuário com política de senha ativada, você pode utilizar esse comando:
|
1 2 3 4 5 6 7 8 |
USE [master] GO CREATE LOGIN [teste_politica_senha] WITH PASSWORD = 'BdP@BPptxENu', CHECK_POLICY = ON GO |
Para verificar os logins SQL que não estão com a política de senha ativada, utilize a consulta abaixo:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
SELECT A.[name], A.[type_desc], A.is_disabled, A.create_date, A.modify_date, A.is_policy_checked, A.is_expiration_checked, LOGINPROPERTY(A.[name],'BadPasswordCount') AS [BadPasswordCount], LOGINPROPERTY(A.[name],'BadPasswordTime') AS [BadPasswordTime], LOGINPROPERTY(A.[name],'DaysUntilExpiration') AS [DaysUntilExpiration], LOGINPROPERTY(A.[name],'HistoryLength') AS [HistoryLength], LOGINPROPERTY(A.[name],'IsExpired') AS [IsExpired], LOGINPROPERTY(A.[name],'IsLocked') AS [IsLocked], LOGINPROPERTY(A.[name],'IsMustChange') AS [IsMustChange], LOGINPROPERTY(A.[name],'LockoutTime') AS [LockoutTime], LOGINPROPERTY(A.[name],'PasswordLastSetTime') AS [PasswordLastSetTime], LOGINPROPERTY(A.[name],'PasswordHashAlgorithm') AS [PasswordHashAlgorithm] FROM sys.sql_logins A JOIN sys.server_principals B ON A.[sid] = B.[sid] WHERE A.is_disabled = 0 AND B.is_fixed_role = 0 AND A.is_policy_checked = 0 |
Result:
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 in this link here 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 (%).
- 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:
Password validation failed. The password does not meet the operating system policy requirements because it is too short.
Expiração de Senhas (CHECK_EXPIRATION)
Clique aqui para visualizar esse conteúdoPara criar um usuário cuja senha expira, você pode utilizar o comando abaixo:
|
1 2 3 4 5 6 7 8 9 |
USE [master] GO CREATE LOGIN [teste_expiracao_senha] WITH PASSWORD = 'BdP@BPptxENu', CHECK_POLICY = ON, CHECK_EXPIRATION = ON GO |
Para verificar os usuários expirados ou próximos de expirar, você pode usar a consulta abaixo:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
SELECT A.[name], A.[type_desc], A.is_disabled, A.create_date, A.modify_date, A.is_policy_checked, A.is_expiration_checked, A.password_hash, LOGINPROPERTY(A.[name],'BadPasswordCount') AS [BadPasswordCount], LOGINPROPERTY(A.[name],'BadPasswordTime') AS [BadPasswordTime], LOGINPROPERTY(A.[name],'DaysUntilExpiration') AS [DaysUntilExpiration], LOGINPROPERTY(A.[name],'HistoryLength') AS [HistoryLength], LOGINPROPERTY(A.[name],'IsExpired') AS [IsExpired], LOGINPROPERTY(A.[name],'IsLocked') AS [IsLocked], LOGINPROPERTY(A.[name],'IsMustChange') AS [IsMustChange], LOGINPROPERTY(A.[name],'LockoutTime') AS [LockoutTime], LOGINPROPERTY(A.[name],'PasswordLastSetTime') AS [PasswordLastSetTime], LOGINPROPERTY(A.[name],'PasswordHashAlgorithm') AS [PasswordHashAlgorithm] FROM sys.sql_logins A JOIN sys.server_principals B ON A.[sid] = B.[sid] WHERE A.is_disabled = 0 AND B.is_fixed_role = 0 AND ( LOGINPROPERTY( A.[name], 'IsExpired' ) = 1 OR LOGINPROPERTY( A.[name], 'DaysUntilExpiration' ) < 15 ) |
Result:
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.
Troca de Senha Obrigatória (MUST_CHANGE)
Clique aqui para visualizar esse conteúdoPara criar um login onde ele deverá trocar a senha logo na primeira utilização, você utilizar algo assim:
|
1 2 3 4 5 6 7 8 9 10 |
USE [master] GO CREATE LOGIN [teste3] WITH PASSWORD=N'a*1' MUST_CHANGE, CHECK_EXPIRATION=ON, CHECK_POLICY=ON GO |
Para visualizar os logins que estão com essa propriedade MUST_CHANGE habilitada, você pode usar a consulta abaixo:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
SELECT A.[name], A.[type_desc], A.is_disabled, A.create_date, A.modify_date, A.is_policy_checked, A.is_expiration_checked, LOGINPROPERTY(A.[name],'BadPasswordCount') AS [BadPasswordCount], LOGINPROPERTY(A.[name],'BadPasswordTime') AS [BadPasswordTime], LOGINPROPERTY(A.[name],'DaysUntilExpiration') AS [DaysUntilExpiration], LOGINPROPERTY(A.[name],'HistoryLength') AS [HistoryLength], LOGINPROPERTY(A.[name],'IsExpired') AS [IsExpired], LOGINPROPERTY(A.[name],'IsLocked') AS [IsLocked], LOGINPROPERTY(A.[name],'IsMustChange') AS [IsMustChange], LOGINPROPERTY(A.[name],'LockoutTime') AS [LockoutTime], LOGINPROPERTY(A.[name],'PasswordLastSetTime') AS [PasswordLastSetTime], LOGINPROPERTY(A.[name],'PasswordHashAlgorithm') AS [PasswordHashAlgorithm] FROM sys.sql_logins A JOIN sys.server_principals B ON A.[sid] = B.[sid] WHERE A.is_disabled = 0 AND B.is_fixed_role = 0 AND LOGINPROPERTY( A.[name], 'IsMustChange' ) = 1 |
Result:
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
|
1 2 3 4 |
USE [master] GO ALTER LOGIN [teste3] WITH PASSWORD = 'senhaqualquer123*' MUST_CHANGE |
Bloqueio de Login após N tentativas
Clique aqui para visualizar esse conteúdoSe 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:
Se a senha correta for digitada e o usuário estiver bloqueado, será mostrada essa mensagem de erro:
Para verificar os logins SQL bloqueados, você pode utilizar essa consulta:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
SELECT A.[name], A.[type_desc], A.is_disabled, A.create_date, A.modify_date, A.is_policy_checked, A.is_expiration_checked, LOGINPROPERTY(A.[name],'BadPasswordCount') AS [BadPasswordCount], LOGINPROPERTY(A.[name],'BadPasswordTime') AS [BadPasswordTime], LOGINPROPERTY(A.[name],'DaysUntilExpiration') AS [DaysUntilExpiration], LOGINPROPERTY(A.[name],'HistoryLength') AS [HistoryLength], LOGINPROPERTY(A.[name],'IsExpired') AS [IsExpired], LOGINPROPERTY(A.[name],'IsLocked') AS [IsLocked], LOGINPROPERTY(A.[name],'IsMustChange') AS [IsMustChange], LOGINPROPERTY(A.[name],'LockoutTime') AS [LockoutTime], LOGINPROPERTY(A.[name],'PasswordLastSetTime') AS [PasswordLastSetTime], LOGINPROPERTY(A.[name],'PasswordHashAlgorithm') AS [PasswordHashAlgorithm] FROM sys.sql_logins A JOIN sys.server_principals B ON A.[sid] = B.[sid] WHERE A.is_disabled = 0 AND B.is_fixed_role = 0 AND LOGINPROPERTY(A.[name],'IsLocked') = 1 |
Result:
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.
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.
And that's it, folks!
Um grande abraço e até a próxima!
Portuguese 
English