- Auditoria no SQL Server (Server Audit)
- Como criar uma auditoria para monitorar a criação, modificação e exclusão de Jobs no SQL Server
- Como criar uma trigger de Auditoria para logar a manipulação de objetos no SQL Server
- SQL Server – Como implementar auditoria e controle de logins (Trigger de Logon)
- Monitorando operações de DDL e DCL utilizando a fn_trace_gettable do SQL Server
- Utilizando o trace padrão do SQL Server para auditar eventos (fn_trace_gettable)
- SQL Server – Trigger de auditoria de permissões e privilégios a nível de database e instância (GRANT e REVOKE)
- SQL Server – Como monitorar e auditar alterações de dados em tabelas utilizando Change Data Capture (CDC)
- SQL Server 2016 – Como “viajar no tempo” utilizando o recurso Temporal Tables
- SQL Server – Como utilizar auditoria para mapear permissões necessárias reais em um usuário
- SQL Server – Trigger para prevenir e impedir alterações em tabelas
- SQL Server – Como criar um histórico de alterações de dados para suas tabelas (logs para auditoria)
- SQL Server – Como evitar ataques de força bruta no seu banco de dados
- SQL Server – Checklist de Segurança – Uma SP com mais de 70 itens de segurança para validar seu banco de dados
- SQL Server – Como saber a data do último login de um usuário
- SQL Server – Como evitar e se proteger de ataques de Ransomware, como WannaCry, no seu servidor de banco de dados
- SQL Server – Cuidado com a server role securityadmin! Utilizando elevação de privilégios para virar sysadmin
- SQL Server – Como evitar SQL Injection? Pare de utilizar Query Dinâmica como EXEC(@Query). Agora.
- SQL Server – Entendendo os riscos da propriedade TRUSTWORTHY habilitada em um database
- SQL Server – Políticas de Senhas, Expiração de Senha, Troca de Senha Obrigatória e Bloqueio de Login após N tentativas
- SQL Server – Como criar uma auditoria de logins utilizando os logs da instância
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
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 |
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 (%).
- 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 ) |
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.
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 |
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
|
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 |
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.
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!
Portuguese 
English