Um nome de conta conhecido como sa representa uma ameaça à segurança do banco de dados? Ao usar a autenticação do Windows no SQL Server, ela impõe a mesma política de senha (se foi definida para bloquear a conta após 5 vezes)?
AskOverflow.Dev
Uma conta de usuário "god" com um nome conhecido geralmente é considerada uma ideia pior do que um usuário god com um nome menos conhecido. Isso torna os ataques de força bruta um pouco mais fáceis, pois o invasor só precisa adivinhar a senha e não o nome de usuário e a senha.
Além disso, ter um usuário divino de qualquer maneira pode ser perigoso. Geralmente, é melhor ter usuários específicos com direitos específicos para o que eles precisam fazer. Esse tipo de segurança baseada em privilégios é mais fácil de implementar desde o início do que para adaptá-lo posteriormente ao seu ambiente.
Desabilitar o sa e dar a usuários específicos direitos administrativos específicos conforme necessário no servidor SQL é essencialmente a mesma recomendação que desabilitar
roote distribuir direitos administrativos conforme necessáriosudono Linux e similares. Você sempre pode reativarsauma vez conectado diretamente à máquina com privilégios adequados, caso algo dê errado e você acabe perdendo todos os direitos que seus usuários precisam para operar (e corrigir o problema), da mesma forma que você pode projetar o acesso root a um Linux caixa se você tiver acesso físico à caixa - portanto, desabilitar a conta não é uma bala mágica (mas uma vez que um invasor tenha acesso físico à sua máquina ou acesso administrativo total via RDC ou SSH, todas as apostas serão canceladas de qualquer maneira).Ao usar a Autenticação Integrada do Windows, o servidor SQL não tem controle sobre bloqueios de conta e tal - ele apenas mapeia um usuário do Windows para um usuário do SQL e solicita ao sistema operacional que ateste o fato de que o usuário forneceu as credenciais apropriadas. Para usuários humanos interativos, isso significa que qualquer bloqueio ocorreria quando o usuário tentasse se autenticar com o Windows, não quando ele se conectasse ao SQL Server.
Não é uma má ideia fazer com que o usuário administrador padrão (admin/root/postgres/sa/etc) não exista realmente em seu sistema. Você sempre pode criar uma conta privilegiada com um nome diferente.
Se nada mais, as pessoas que tentam explorar seu sistema não têm um tempo tão fácil como se estivessem trabalhando às cegas (por exemplo, injeção de sql sem ter algum shell interativo nem ser capaz de ver a saída direta de seus comandos)
Quanto aos bloqueios de conta - se alguém conseguiu chegar longe o suficiente para tentar fazer login em sua máquina, a menos que você permita especificamente o login direto dos usuários, você já perdeu a batalha. Pessoalmente, não sou a favor de bloqueios em sua maior parte, porque dá a alguém a capacidade de criar uma negação de serviço se conseguir obter o nome de qualquer um de seus usuários. (e fazer com que eles bloqueiem o superusuário? Não é divertido).
Eu recomendo olhar os benchmarks CIS ... eles não os têm para todos os bancos de dados, mas eles têm recomendações para Oracle, MS SQL, DB2 e MySQL. Se você estiver executando outra coisa, ainda vale a pena examinar os tipos gerais de coisas que eles recomendam.
Eu não vi ninguém mencionar isso, então vou adicioná-lo. Com o SQL Server 2005+, se o seu servidor fizer parte de um domínio e o domínio tiver uma política de senha, você poderá permitir que a política de senha seja aplicada em logins SQL. Isso inclui requisitos de complexidade de senha e a capacidade de forçar alterações de senha no login.
Observe que isso às vezes pode causar problemas com alguns instaladores de software que não foram atualizados para funcionar com SQL 2005+ e criar logins SQL com senhas inseguras.
Existem dois modos de autenticação usados no SQL Server: autenticação do Windows e modo misto (permite autenticação do Windows e autenticação do SQL Server)
O primeiro modo é menos vulnerável a ataques de força bruta, pois é provável que o invasor encontre um bloqueio de login (o recurso Política de bloqueio de conta) após um número finito de tentativas de ataque. Todo ambiente de produção, se estiver usando o modo de autenticação do Windows, deve utilizar o recurso de política de bloqueio, pois torna os ataques de força bruta impossíveis
Quando se trata de vulnerabilidade de ataque de força bruta de autenticação do SQL Server, a situação não é tão favorável. A Autenticação do SQL Server não possui recursos que permitam detectar quando o sistema está sob um ataque de força bruta. Além disso, o SQL Server é muito responsivo quando se trata de validar as credenciais de autenticação do SQL Server. Ele pode lidar facilmente com tentativas de login repetidas, agressivas e de força bruta, sem desempenho geral negativo que possa indicar tais ataques. Isso significa que a Autenticação do SQL Server é um alvo perfeito para quebra de senha por meio de ataques de força bruta
Além disso, os métodos de força bruta estão evoluindo com cada novo método introduzido de criptografia e complexidade de senha. Por exemplo, invasores que usam Rainbow Tables (as tabelas pré-computadas para reverter os valores de hash criptográficos para todas as combinações possíveis de caracteres) podem facilmente e rapidamente quebrar qualquer senha com hash
Para proteger seu SQL Server de ataques de força bruta, você deve considerar o seguinte:
A conta sa, quando habilitada, pode fazer qualquer coisa no SQL Server. Se um invasor entrar nessa conta, poderá fazer qualquer coisa que desejar na instância do SQL Server (e possivelmente no sistema operacional do host).
O SA (e outros nomes de contas bem conhecidos) são pontos bem conhecidos que os hackers podem atacar. Alguns dos Oracle foram mal documentados e, portanto, as senhas padrão nem sempre foram alteradas. Depois de obter o controle da conta SA no SQL Server, você controla o servidor em que está sendo executado e pode executar qualquer código ou instalar qualquer coisa que desejar. Nos meus dias mais de cowboy, lembro-me de não ter permissão (precisava de papelada que não iria preencher) para instalar um controle ActiveX em um servidor web que também hospedava o SQL Server - então usei xp_cmdshell para copiar e instalar o controle .