Mesmo a Microsoft desencoraja o uso do modo de autenticação do SQL Server , mas nossos aplicativos exigem isso.
Eu li que é uma prática recomendada não permitir que os usuários usem o salogin diretamente, em vez disso, use a Autenticação do Windows e permita privilégios de administrador de sistema a essas contas (ou grupos de contas).
- Não é essencialmente a mesma coisa? Quais são as vantagens/desvantagens?
- Como a prática recomendada aumenta a segurança de minhas instâncias do SQL Server?
- Isso se aplica apenas às instâncias de produção ou também às nossas instâncias de desenvolvimento interno?
Você tem várias perguntas diferentes aqui, então vou eliminá-las individualmente:
"Li que é uma prática recomendada não permitir que os usuários usem o login sa diretamente, em vez disso, use a Autenticação do Windows"
Você está misturando duas coisas aqui: o conceito de SA e o conceito de autenticação SQL e autenticação Windows.
A autenticação SQL é uma lista de nomes de usuários e senhas que são armazenados em cada SQL Server. O fato de ser armazenado em SQL é o primeiro problema. Se você precisar alterar a senha de login, deverá alterá-la em todos os servidores (ou manter senhas diferentes em servidores diferentes). Com a autenticação do Windows, você pode desabilitar logins centralmente, alterar senhas, definir políticas etc.
Se você optar por usar a autenticação SQL, o SA será apenas um login de autenticação SQL. É o nome de usuário padrão do administrador, assim como o Administrador na autenticação do Windows. Ele tem superpoderes locais naquela instância, mas não superpoderes globais em todas as instâncias.
"...e permitindo a essas contas (ou grupos de contas) privilégios de administrador de sistema."
Qualquer que seja o método de autenticação escolhido, o ideal é seguir o princípio do privilégio mínimo: conceder às pessoas os direitos mínimos de que precisam para realizar seu trabalho e nada mais.
Não pense neles apenas como logins - são pessoas que podem fazer com que você seja demitido. Se eles descartarem o banco de dados ou desabilitarem suas tarefas de backup acidentalmente, eles não serão demitidos porque, por padrão, o SQL não rastreia quem fez o quê. Você é quem vai ser demitido porque vai acontecer, e você não vai poder dizer quem fez isso.
"Como a prática recomendada aumenta a segurança de minhas instâncias do SQL Server?"
Você quer fazer duas coisas:
A primeira é realizada com o princípio do menor privilégio: dar às pessoas apenas as permissões de que precisam e nada mais.
A segunda é realizada dando a cada pessoa seu próprio login, não permitindo logins compartilhados (como permitir que todos usem o mesmo nome de usuário/senha) e, idealmente, auditando os logins. Você provavelmente não fará essa última parte imediatamente, porque é meio doloroso, mas vamos colocar as peças no lugar primeiro para que você possa adicionar auditoria mais tarde, depois que alguém abandonar um banco de dados e seu chefe quiser saber por quê.
Eu sei o que você está pensando: "Mas estamos codificando aplicativos e o aplicativo precisa de um login." Sim, dê ao aplicativo seu próprio login, e os desenvolvedores precisam saber essa senha, mas esse login deve ser tão despojado de permissões que ninguém em sã consciência gostaria de usá-lo. Por exemplo, pode ser necessário apenas as funções db_datareader e db_datawriter, nada mais. Dessa forma, ele pode inserir, atualizar, excluir e selecionar dados, mas não necessariamente alterar esquemas, adicionar índices, alterar procedimentos armazenados, etc.
"Isso se aplica apenas a instâncias de produção ou também a nossas instâncias de desenvolvimento interno?"
Acho que se aplica tanto a instâncias de desenvolvimento porque geralmente fico preocupado com as pessoas quebrando as coisas. As pessoas adoram quebrar servidores em desenvolvimento. E, claro, quando é hora de agrupar a lista de alterações para migrar para produção, preciso saber se um determinado índice é realmente vital para o aplicativo ou se algum idiota apenas executou o Database Tuning Advisor e disse para aplicar todas as alterações . As permissões adequadas ajudam a diminuir essa dor.
Na verdade, se você ler este whitepaper: SQL Server Separation of Duties Whitepaper
Ele dirá que NINGUÉM deve usar privilégios de administrador de sistema em sua conta. Sua conta de acesso diário deve receber acesso mínimo, não direitos explícitos de administrador de sistema. Dado a eles, o CONTROL SERVER está realmente próximo do que o sysadmin é e permite que você ainda NEGUE/REVOGUE o acesso onde eles não precisam. Permitir direitos de administrador de sistema a qualquer pessoa torna-se um problema se você precisar atender a quaisquer padrões de conformidade de TI. A maioria dos padrões requer o uso mínimo da função sysadmin.
Eu desativo e renomeio a conta "sa", assim como você faria com a conta de administrador integrada no sistema operacional. Só para ser usado em emergência.
Os desenvolvedores geralmente recebem acesso total ao seu ambiente de desenvolvimento. Então, quando seu programa for movido para a instância de pré-produção, seu acesso deve ser mínimo ou nenhum; assim como seria na produção. Esse é um mundo perfeito. Se, no entanto, você não estiver nisso e seus desenvolvedores tiverem privilégios mais altos do que você acha que eles precisam, eu auditaria suas contas. Eu capturaria tudo e qualquer coisa que eles fazem até certo ponto. Portanto, no caso de algo dar errado quando eles estavam em seu servidor de produção, você pode voltar e descobrir exatamente o que eles fizeram.
Se você estiver sujeito a controles ou padrões regulatórios externos (SOX, PCI etc.), você
Os desenvolvedores devem ter db_owner em uma rede SQL Server apenas para desenvolvimento.
Se todos os seus SQL Servers estiverem na rede com uma compilação padrão (ou seja, a mesma conta de serviço), o sa em um confere direitos a todos eles.
Se a conta de serviço for administrador local, seus desenvolvedores também terão controle total sobre os servidores.
Não há vantagens.
sa = administrador do sistema
Fazer login com sa dá ao usuário o poder de fazer o seguinte: - eliminar e criar bancos de dados - modificar objetos no banco de dados - eliminar e criar logins - alterar senhas - excluir todos os dados
Conceder privilégios de administrador de sistema a uma conta do Windows realiza a mesma coisa.
A lista continua, mas isso deve lhe dar alguns bons motivos para NUNCA, NUNCA, permitir que um não administrador use o sa.
Você deve criar uma conta Windows ou SQL com os privilégios mínimos necessários para que os aplicativos funcionem. (ou seja, login, acesso a procedimentos armazenados e visualizações)
A melhor prática é colocar uma senha forte e esquecê-la.
Tenho duas opções em mente agora, por que não se deve ter uma conta SA fraca. Se você tiver uma senha fraca/vazia para SA, uma pessoa má (traduza isso para 'colega amigável') pode:
habilite o procedimento do sistema xp_cmdshell e, usando os privilégios da conta de serviço Sql Server, danifique sua caixa local (crie/remova arquivos...). Ter baixa segurança para SA não diz muito sobre as configurações da instância, mas pode implicar que o usuário do serviço pode seguir práticas ruins (como ser um administrador :-));
habilitar e-mail em sua instância e encaminhar rapidamente um pequeno script divertido de spam (que provavelmente causará alguns problemas com seu provedor de internet ou com seus colegas... dependendo de onde os e-mails vão ;-));
Não vou apontar os fatos óbvios de que ele pode descartar bancos de dados, logins ... etc.
Não necessariamente: por exemplo - na instância do SQL Server do seu laptop, a diferença entre a autenticação do Windows e a autenticação SQL significa que, em teoria, um invasor externo poderia usar apenas uma conta SQL, porque a autenticação do Windows não pode ser usada fora do seu próprio domínio conta. Um usuário pode escanear laptops vizinhos do shopping onde você está bebendo seu café e pode ver que você tem uma instância SQL instalada e iniciada e pode tentar se divertir de graça. Não é que isso aconteça com frequência... mas é uma possibilidade :-).
Como a prática recomendada aumenta a segurança de minhas instâncias do SQL Server?
Como todas as melhores práticas neste mundo fazem o seu trabalho..diminui as chances de uma possível desvantagem (por exemplo: a melhor prática de fazer atividade física diminuirá as chances de você ser como eu.. um preguiçoso) que poderia ocorrer de outra forma.
Isso se aplica apenas às instâncias de produção ou também às nossas instâncias de desenvolvimento interno?
Respondendo à sua pergunta final, usamos contas SA em todos os nossos bancos de dados de desenvolvimento (com a senha "sa", diga-se de passagem!)
No entanto, é importante observar que não armazenamos os dados e não os geramos. Nossos bancos de dados são usados exclusivamente para um armazenamento de dados para um aplicativo C/C++. Esses bancos de dados de desenvolvimento contêm apenas dados de teste e são frequentemente criados, eliminados, modificados, etc.\
Além disso, igualmente crítico, todos os bancos de dados de desenvolvimento são instalados em máquinas de desenvolvimento. (Uma cópia por desenvolvedor, pelo menos!) Portanto, se alguém bagunçar uma instalação inteira, eles apenas bagunçam a si mesmos e a mais ninguém.
Quando se trata de um ambiente em que você deseja garantir que seu banco de dados, tabelas e dados sejam realmente consistentes e seguros, você deseja uma senha SA boa e sólida. Se você deixar isso fraco, qualquer pessoa terá acesso total aos seus dados e poderá destruir completamente seu banco de dados.
Para um grupo de desenvolvedores com suas próprias cópias do banco de dados que contêm apenas dados de teste, ainda não encontrei um argumento sólido para manter uma conta SA forte.
Qualquer parâmetro de segurança do sistema SQL Server padrão fornecido deve ser modificado. É recomendável não usar o modo misto (habilita a autenticação do Windows e do SQL Server) para autenticação. Em vez disso, mude apenas para a autenticação do Windows - que aplicará a política de senha do Windows - verificando o comprimento da senha, a duração e o histórico. O recurso da política de senha do Windows que a torna diferente da autenticação do SQL Server é o bloqueio de login - após várias tentativas sucessivas de logon com falha, o login fica bloqueado e inutilizável para uso posterior
Por outro lado, a autenticação do SQL Server não fornece nenhum método para detectar tentativas de ataque de força bruta e, o que é pior, o SQL Server é otimizado para lidar com um grande número de tentativas rápidas de login. Portanto, se a autenticação do SQL Server for obrigatória em um sistema SQL Server específico, é altamente recomendável desabilitar o login SA