É sempre uma boa prática usar uma conta de banco de dados distinta para cada usuário de um aplicativo?

Os aplicativos aos quais estou acostumado são baseados em servidor e usam uma conta de banco de dados para muitos usuários, com o código do aplicativo controlando o que o usuário pode fazer ou como usuário único.

Existem aplicativos de negócios complexos bem-sucedidos em que cada pessoa precisa de sua própria conta de banco de dados e o servidor de banco de dados é utilizado para impor regras de política sobre o que cada usuário deve ter permissão para fazer?

Estou pensando em aplicativos em que várias pessoas contribuem com informações em um banco de dados e podem acessar informações armazenadas por outras pessoas - por exemplo, colegas de uma organização que precisam acessar registros de clientes.

Também existe um nome para esse tipo de configuração?

Se você precisar de um controle realmente rígido imposto no nível dos dados. Por exemplo, auditoria extensiva. A auditoria não é muito boa se vários usuários compartilham a mesma conta. Se você possui alguns usuários que precisam acessar o banco de dados de dados diretamente.

Se a segurança é tão rígida, você normalmente nem expõe o banco de dados diretamente. Você tem um serviço e o cliente deve obter dados do serviço.

Em um aplicativo Web, o banco de dados (por exemplo, porta 1433) normalmente não é exposto diretamente, portanto você tem um nível de segurança. Mesmo se o aplicativo da web acessar o banco de dados diretamente, os usuários ainda não terão acesso direto acesso ao banco de dados.

Se o login e a senha estiverem no aplicativo cliente, eles poderão ser invadidos. Se um domínio, você pode usar a segurança integrada.

No banco de dados, você pode ter controles muito bons. Mas o controle no nível da linha é um pouco de trabalho. Um banco de dados não é uma boa ferramenta para regras de negócios. Regras de negócios e segurança detalhada são normalmente aplicadas no nível do aplicativo.

Você pode ter um modo misto, onde existem alguns procedimentos armazenados usados ​​pelos administradores e deseja rastrear qual administrador. E você pode conceder acesso somente leitura aos usuários que geram relatórios diretamente.

O desafio aqui é que o acesso ao seu banco de dados seja gerenciado por uma abstração. Em vez de os usuários se conectarem como eles mesmos, eles essencialmente assumem a identidade de alguma função de aplicativo generalizada. Você não apenas perde a visibilidade da conexão individual, mas também a granularidade de definir diferentes tipos de acesso para todos os usuários individuais.

O principal motivo para usar essa abordagem é a simplicidade. Muitos aplicativos são projetados para que o usuário do aplicativo não tenha conhecimento do banco de dados. Eles realmente não precisam, especialmente se o aplicativo gerencia sua própria segurança interna. A maioria dos usuários individuais nunca se conectará diretamente ao banco de dados, portanto, não é necessário definir um login explícito para eles.

O único momento em que você deve considerar permitir que o banco de dados gerencie sua segurança é se você tiver usuários que se conectarão diretamente ao seu banco de dados. Isso significa que eles estão analisando seu aplicativo e ele não pode mais reforçar a segurança por conta própria. A vantagem aqui é que você pode ser mais granular ao definir sua segurança. A desvantagem é a maior sobrecarga para gerenciar usuários e suas permissões.

Se você sente a necessidade desse tipo de acesso, deseja usar Controle de Acesso Baseado em Função . Você deve definir funções com base em que tipo de permissões são necessárias no seu banco de dados e, em seguida, agrupar usuários individuais nessas funções. Isso oferece uma melhor auditoria e controle sobre seu modelo de segurança, que pode sair rapidamente do controle ao gerenciar o acesso direto.

Existe uma abordagem híbrida para isso. Se você deseja que sua segurança seja gerenciada parcialmente pelo banco de dados, é possível criar vários usuários de aplicativos, cada um definido por sua função e conceder acesso explicitamente a esses usuários com base na função que eles cumprem. Isso significa que você pode aproveitar o mecanismo de banco de dados para alguns de seu modelo de segurança, mas ainda precisa ter algum gerenciamento dentro do aplicativo. Isso aumenta a complexidade do modelo de usuário do aplicativo, mas oferece uma granularidade mais fina nos diferentes logins em uso.

Você deve começar a impor a segurança no nível mais granular o mais rápido possível. As funções ajudam nesse sentido - dar às pessoas acesso a várias tabelas ao mesmo tempo não é um pesadelo.

A conta única para todos é uma ótima fonte de perguntas aqui e em outros lugares - "o registro x foi excluído, como faço para descobrir quem fez isso?" - a resposta é que você não pode - sem contas e auditorias individuais .

Ao "auditar", quero dizer que, embora seja muito bom ter uma conta para todos, isso não significa que você tenha uma verdadeira segurança. Se, digamos, um registro na tabela de RH for excluído, tudo o que você pode dizer é que alguém com acesso à tabela de RH fez isso - esse é o número x de pessoas.

Você precisa de gatilhos no sistema que registrem ações para poder rastrear até o nível individual que executou a ação X (a menos que você tenha um RDBMS como o Oracle, onde isso pode ser feito automaticamente).

De qualquer forma, você deve sempre tornar sua segurança o mais granular possível o mais rápido possível - conceda às pessoas acesso a tabelas apenas com base na "necessidade de conhecer". E sempre inclua carimbos de data e hora para ações em tabelas - as pessoas freqüentemente dão seus IDs para outras pessoas - se você pode dizer: "Jimmy, você era o único no escritório às 17:49 ..." - novamente, não é uma peça de ferro, apenas outra flecha na sua aljava.

Talvez se você nos forneceu seu RDBMS, poderia obter conselhos mais específicos / relevantes para sua situação?

Sim, ele é. Conectar-se a um banco de dados a partir de um aplicativo como um único usuário poderoso é uma violação do princípio do menor privilégio . Essa é a causa raiz da maioria dos ataques de injeção de SQL.

Isso geralmente é feito devido à ignorância, por uma questão de simplicidade ou, às vezes, por desempenho.

Os bancos de dados geralmente têm vida longa e são usados ​​por vários aplicativos ao mesmo tempo e ao longo do tempo. Você pode economizar recursos centralizando o controle de acesso no banco de dados, em vez de usar vários aplicativos.

Você deseja escolher um servidor de banco de dados que ofereça suporte a segurança de linha, segurança de coluna e autenticação / representação de proxy (que suporta usuários reais de banco de dados + pool de conexão)

Também seria mais seguro para aplicativos baseados em "plugins", como o Wordpress, onde é difícil evitar injeções de SQL devido a autores não qualificados de plugins. Cada plug-in obtém login no banco de dados, em vez do aplicativo como um todo.