Por que é uma prática ruim permitir que todos usem o logon sa?

Até a Microsoft desencoraja o uso do modo de autenticação do SQL Server , mas nossos aplicativos exigem isso.

Li que é uma prática recomendada não permitir que os usuários usem o salogon diretamente, em vez disso, usando a Autenticação do Windows e permitindo privilégios de administrador de sistema a essas contas (ou grupos de contas).

• Isso não é essencialmente a mesma coisa? Quais são as vantagens / desvantagens?
• Como as práticas recomendadas aumentam a segurança das minhas instâncias do SQL Server?
• Isso se aplica apenas a instâncias de produção ou também a nossas instâncias de desenvolvimento interno?

Você tem várias perguntas diferentes aqui, então eu vou eliminá-las individualmente:

"Li que é uma prática recomendada não permitir que os usuários usem o logon sa diretamente, em vez disso, usando 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 do Windows.

A autenticação SQL é uma lista de nomes de usuário e senhas armazenados em todo e qualquer servidor SQL. O fato de estar armazenado no SQL é o primeiro problema. Se você precisar alterar a senha de um login, precisará alterá-la em todos os servidores (ou manter senhas diferentes em servidores diferentes). Com a autenticação do Windows, você pode desativar centralmente os logins, 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 do administrador padrão, assim como o administrador está na autenticação do Windows. Ele possui superpotências locais nessa instância, mas não superpotências 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 que você escolher, o ideal é seguir o princípio do menor privilégio: conceder às pessoas os direitos mínimos necessários 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, não serão demitidos, porque, por padrão, o SQL não rastreia quem fez o que. Você é quem vai ser demitido porque isso vai acontecer, e você não será capaz de dizer qual pessoa fez isso.

"Como as práticas recomendadas aumentam a segurança das minhas instâncias do SQL Server?"

Você quer fazer duas coisas:

1. Impedir que as pessoas quebrem o servidor
2. Quando eles quebrarem o servidor, poderão identificar exatamente quem o fez

O primeiro é realizado com o princípio do menor privilégio: dar às pessoas apenas as permissões necessárias 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á a última parte imediatamente, porque é meio doloroso, mas vamos colocar as peças em primeiro lugar, para que você possa adicionar auditorias mais tarde depois que alguém soltar um banco de dados e seu chefe quiser saber o porquê.

Sei o que você está pensando: "Mas estamos codificando aplicativos, e o aplicativo precisa de um login". Sim, dê ao aplicativo seu próprio logon, e os desenvolvedores precisam saber essa senha, mas esse logon deve ser tão despojado de permissões que ninguém em sã consciência desejaria usá-lo. Por exemplo, pode ser necessário apenas nas 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?"

Eu acho que isso se aplica tanto a instâncias de desenvolvimento porque geralmente estou preocupado com pessoas quebrando coisas. As pessoas adoram quebrar servidores em desenvolvimento. E, é claro, quando é hora de agrupar a lista de alterações para migrar para a produção, preciso saber se um determinado índice é realmente vital para o aplicativo ou se algum idiota acabou de executar o Orientador de Otimização do Banco de Dados e disse-lhe para aplicar todas as alterações . Permissões apropriadas ajudam a diminuir essa dor.

Na verdade, se você ler este white paper: White paper sobre separação de tarefas do SQL Server

Ele informará que NINGUÉM deve usar privilégios de administrador de sistema na conta deles. Sua conta de acesso diário deve ter acesso mínimo, e não direitos explícitos do administrador de sistemas. Dado a eles, o CONTROL SERVER está realmente próximo do que é o sysadmin e, em seguida, permite que você ainda tenha o DENY / REVOKE de acesso onde eles não precisam. A concessão de direitos de administrador de sistemas a qualquer pessoa se torna um problema se você precisar atender a algum padrão de conformidade de TI. A maioria dos padrões requer o uso mínimo da função sysadmin.

Desabilito e renomeio a conta "sa", assim como você faria com a conta de administrador interna no sistema operacional. Apenas para ser usado em emergência.

Os desenvolvedores geralmente têm acesso total ao seu ambiente de desenvolvimento. Então, quando o programa for movido para a instância de pré-produção, o acesso deverá ser mínimo ou nenhum; assim como seria na produção. Esse é um mundo perfeito. Se, no entanto, você não estiver nessa e seus desenvolvedores tiverem privilégios mais altos do que você imagina, eles auditariam as contas deles. Eu capturaria tudo e qualquer coisa que eles fizessem até certo ponto. Portanto, se algo der errado quando eles estavam no servidor de produção, você poderá voltar e descobrir exatamente o que eles fizeram.

Se você estiver sujeito a controles ou padrões regulatórios externos (SOX, PCI, etc.), poderá

• falhará em uma auditoria
• estão falhando nas verificações mensais do PCI

Os desenvolvedores devem ter db_owner em um SQL Server de rede apenas para desenvolvimento.

Se os servidores SQL estiverem todos na rede com uma compilação padrão (ou seja, a mesma conta de serviço), o sa em um conferirá direitos a todos.

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 = sysadmin

O login com sa permite ao usuário fazer o seguinte: - soltar e criar bancos de dados - modificar objetos no banco de dados - soltar e criar logins - alterar senhas - excluir todos os dados

A concessão de privilégios de administrador de sistema em uma conta do Windows realiza a mesma coisa.

A lista continua, mas isso deve lhe dar algumas boas razões para NUNCA NUNCA deixar que um não administrador use sa.

Você deve criar uma conta do Windows ou SQL com os privilégios mínimos necessários para que os aplicativos funcionem. (ou seja, logon, acesse procedimentos armazenados e visualizações)

A melhor prática é colocar uma senha forte e esquecê-la.

No momento, tenho duas opções em mente: por que não se deve ter uma conta SA fraca? Se você tiver uma senha fraca / vazia para a SA, uma pessoa má (traduza para 'colega amiga') pode:

• ative o procedimento do sistema xp_cmdshell e, usando os privilégios da conta de serviço do Sql Server, danifique sua caixa local (crie / remova arquivos ..). Ter baixa segurança para o SA não diz muito sobre as configurações da instância, mas pode implicar que o usuário do serviço possa seguir práticas inadequadas (como ser um administrador :-));

• habilite o correio na sua instância e avance rapidamente um pequeno script divertido de spam (que provavelmente causará alguns problemas ao seu provedor de Internet ou aos seus colegas ... dependendo de onde os emails vão ;-));

Não vou apontar os fatos óbvios de que ele pode eliminar bancos de dados, logins ... etc.

• Isso não é essencialmente a mesma coisa? Quais são as vantagens / desvantagens?

• Não necessariamente: por exemplo - na instância do SQL Server do seu laptop, a diferença entre autenticação do Windows e autenticação do SQL significa que, em teoria, um invasor externo pode 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 digitalizar laptops vizinhos no shopping em que 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 possa acontecer com frequência ... mas é uma possibilidade :-).

• Como as práticas recomendadas aumentam a segurança das minhas instâncias do SQL Server?

• Como todas as melhores práticas deste mundo realizam seu trabalho .. diminui as chances de uma possível desvantagem (por exemplo: a melhor prática de atividade física diminui as chances de você ser como eu ... um viciado em televisão) que poderia ocorrer de outra maneira.

• Isso se aplica apenas a instâncias de produção ou também a nossas instâncias de desenvolvimento interno?

• Digamos que eu sugira implementar as práticas recomendadas de segurança (testadas e modificadas de acordo com as necessidades do seu ambiente) pelo menos na produção. Mas se no desenvolvimento você também usa dados de produção (sensível ... etc), isso é uma forte indicação de que você também precisa alterar suas práticas de desenvolvimento.

Respondendo à sua pergunta final, usamos contas SA em todos os nossos bancos de dados de desenvolvimento (com a senha "sa"!)

No entanto, é fundamental 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 puramente dados de teste e são frequentemente criados, descartados, 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 estraga uma instalação inteira, eles estragam a si mesmos e 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 sólida e agradável. Se você deixar isso fraco, qualquer pessoa e todos terão acesso total aos seus dados e poderão destruir completamente seu banco de dados.

Para vários desenvolvedores com suas próprias cópias do banco de dados que contêm puramente 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 diretiva de senha do Windows - verificando o comprimento, a duração e o histórico da senha. O recurso da diretiva de senha do Windows que a diferencia da autenticação do SQL Server é o bloqueio de logon - após várias tentativas falhas de logon sucessivas, o logon fica bloqueado e inutilizável para uso posterior

Por outro lado, a autenticação do SQL Server não fornece métodos 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 logon. Portanto, se a autenticação do SQL Server for obrigatória em um sistema específico do SQL Server, é altamente recomendável desativar o logon do SA