A segurança dos dados deve ser realizada no lado do banco de dados?

Question

Estamos no processo de criação de uma nova estrutura e forma de fazer negócios para nossos novos aplicativos internos.Nosso design atual determina que toda a lógica de segurança deve ser tratada pelo nosso banco de dados, e todas as informações (e quero dizer todas) entrarão e sairão do banco de dados por meio de procedimentos armazenados.

A teoria é que a camada de acesso a dados solicita informações de um procedimento armazenado e passa a autenticação para o banco de dados.O banco de dados determina a função/permissões do usuário e decide se deve ou não executar a tarefa (seja recuperando dados ou fazendo uma atualização).

Acho que isso significa menos transações de banco de dados.Uma chamada para o banco de dados.Se a segurança estivesse em nossa camada de acesso a dados, isso exigiria 1 chamada de banco de dados para determinar se o usuário tinha as permissões adequadas e, em seguida, 1 chamada de banco de dados separada para executar a ação.

Eu, por exemplo, acho o SQL Management Studio completamente ausente como IDE.Minha principal preocupação é que acabaremos tendo que manter uma quantidade desagradável de lógica de negócios em nossos procedimentos armazenados para obter ganhos mínimos de desempenho.

No momento, estamos usando LINQ para nosso ORM.Parece leve e rápido, mas o melhor de tudo é que é muito fácil de desenvolver rapidamente.

O custo de manutenção compensa o ganho de desempenho?Estamos nos enganando pensando que haverá um ganho perceptível de desempenho?Ou estamos apenas criando um pesadelo para nós mesmos?

Nosso ambiente:

• Aplicativos de negócios internos e não essenciais
• C#/ASP.NET 3.5
• Janelas 2003
• MS SQL Server 2005
• 35 aplicativos web de médio porte com aproximadamente 500 usuários

Answer 1

Não faça isso.Recentemente tivemos um MUITO MAL experiência quando o "guru do banco de dados" decidiu ir para outra empresa.A manutenção de toda a lógica dos procedimentos é simplesmente horrível!!

Sim, você terá alguma melhoria de desempenho, mas não vale a pena.Na verdade, o desempenho nem sequer é uma grande preocupação na aplicação interna.Invista mais dinheiro em bons servidores.Vai valer a pena.

Answer 2

Infelizmente não existe "uma resposta verdadeira".A escolha que você deve fazer depende de vários fatores, como:

• A familiaridade da equipe com as soluções fornecidas (ou seja, se a maioria deles se sente confortável escrevendo SQL, pode estar no banco de dados, porém se a maioria deles se sente mais confortável com C#, deve estar no código)
• O “poder político” de cada partido
• etc.

Não há vantagem decisiva em nenhuma direção (como você disse que os ganhos de desempenho são mínimos), a única coisa a ter em mente é o princípio DRY (Don't Repeat Yourself):não reimplemente a funcionalidade duas vezes (no código e no banco de dados), porque mantê-los sincronizados será um pesadelo.Escolha uma solução e cumpra-a.

Answer 3

Você poderia fazer isso, mas é uma grande dor desenvolver e manter.Aprenda com alguém que está em um projeto onde quase toda a lógica de negócios é codificada em procedimentos armazenados.

Por segurança, o ASP.NET possui gerenciamento de usuários e funções integrado, então você pode salvar viagens ao banco de dados, mas e daí?Em troca, torna-se muito mais irritante lidar e depurar erros de sistema e de validação porque eles precisam surgir no banco de dados.

O teste unitário é muito mais difícil, pois as estruturas disponíveis para testes unitários são muito menos desenvolvidas.

O design adequado de oop e controlado por domínio está praticamente fora de questão.

E o ganho de desempenho será minúsculo, se houver.Nós conversamos sobre isso aqui.

Eu recomendaria que se você quiser salvar sua sanidade como desenvolvedor, você lute com unhas e dentes para manter o banco de dados apenas como camada de persistência

Answer 4

NA MINHA HUMILDE OPINIÃO:

Camada de serviço do aplicativo -> lógica e validação do aplicativo
Camada de dados do aplicativo -> lógica e segurança de dados
Banco de dados -> consistência de dados

Você será mordido pela abordagem sproc, mais cedo ou mais tarde. Aprendi isso da maneira mais difícil.
Procs são ótimos para operações únicas que precisam de muito desempenho, mas a parte CRUD é o trabalho das camadas de dados

Answer 5

Os procedimentos armazenados geralmente são uma vitória para a segurança.Simplificar o relacionamento entre seu aplicativo e o banco de dados reduz o número de locais onde você pode ter erros;erros no código que faz a interface da lógica de negócios com o banco de dados tendem a ser problemas de segurança.Portanto, seu DBA não está errado ao bloquear coisas em procedimentos armazenados.

Outro benefício de bloquear o aplicativo para procedimentos armazenados é que a conexão do banco de dados da pilha de aplicativos pode ter seus privilégios bloqueados para chamadas específicas de procedimentos armazenados e nada mais.

Um benefício de ter um DBA envolvido na lógica de segurança do seu aplicativo é que os diferentes recursos e funções do aplicativo podem ser particionados no banco de dados em visualizações, de modo que, mesmo que SQL dinâmico e instruções genéricas de seleção sejam necessárias, os danos de uma vulnerabilidade SQL pode ser restringido.

O outro lado disso é, obviamente, a perda de flexibilidade.Obviamente, será mais rápido desenvolver um ORM do que uma negociação constante com um DBA sobre parâmetros de procedimentos armazenados.E, à medida que a pressão sobre esses procedimentos armazenados aumenta, é cada vez mais provável que os próprios procedimentos recorram ao SQL dinâmico, que será tão vulnerável ao ataque quanto o SQL composto por aplicativos.

Há um meio-termo feliz aqui e você deve tentar encontrá-lo.Trabalhei recentemente em projetos que foram salvos de problemas terríveis de injeção de SQL porque um DBA configurou cuidadosamente o banco de dados, suas conexões e seus procedimentos armazenados para "menor privilégio", de modo que qualquer usuário do banco de dados tivesse acesso apenas ao que eles queriam. precisava saber.

Obviamente, ao escrever o código SQL na lógica do seu aplicativo, certifique-se de usar consistentemente instruções preparadas parametrizadas, de limpar sua entrada, de estar atento às entradas internacionalizadas (há muitas, muitas maneiras de dizer único -quote sobre HTTP) e que você esteja ciente de como seu banco de dados se comporta quando as entradas são muito grandes para larguras de coluna.

Answer 6

Tudo depende do seu caso, provavelmente é melhor não seguir o caminho do SP e fazer tudo do jeito DDD (faça um modelo de domínio no código e use-o).

No entanto, se você tiver um banco de dados que não seja usado apenas pelo seu aplicativo, mas por muitos, provavelmente deverá considerar os serviços da Web.De qualquer forma, o banco de dados só deve ser acessível por meio de uma camada que aplica as regras de negócios, caso contrário você acabará com dados "sujos" e higienizar seus dados posteriormente será uma dor muito maior do que escrever algumas regras de negócios de antemão.Um bom banco de dados deve ter restrições de verificação e índices definidos, para que tenha algumas regras de negócios, quer você goste ou não.

E se você tiver que lidar com milhões e bilhões de registros, ficará feliz em ter um bom cara de banco de dados que resolva o problema para você.

Answer 7

Minha opinião é que o próprio aplicativo deve lidar com autenticação e autorização.No lado do banco de dados, você só deve lidar com a criptografia dos dados conforme necessário.

Answer 8

Eu construí aplicativos baseados em procedimentos armazenados no passado.No seu caso, talvez haja uma maneira de manter a autenticação na camada de banco de dados e ter sua lógica de negócios em C#.Use visualizações para limitar os dados (você vê apenas as linhas para as quais tem autoridade).Essas visualizações podem ser usadas no LINQ com a mesma facilidade que as tabelas.Você configura suas atualizações para acontecerem com procedimentos armazenados.

Isso permite linq, lógica de negócios em C# e uma camada de autenticação comum no banco de dados que controla o acesso aos dados.