Práticas recomendadas para gerenciar a interação do aplicativo com o servidor de banco de dados

Question

Esta é a minha primeira pergunta no ServerFault e estou mais familiarizado com o desenvolvimento de software do que com a administração, então não tenho certeza se essa é uma pergunta válida ou não.

Estou criando um aplicativo da web como um exercício de aprendizado e não tenho certeza se estou adotando a abordagem correta em relação à segurança. Meu plano atual é criar uma conta de usuário para o aplicativo no banco de dados e remover todas as permissões, exceto as necessárias para executar um conjunto de procedimentos armazenados que agem em nome do aplicativo da Web.

1. Essa é uma abordagem recomendada
2. Há alguma consideração que eu deva saber?

Para referência, o aplicativo será escrito em PHP e o banco de dados usado é o MySQL

    

Answer 1

Em geral, é melhor autenticar / autorizar através da interface e permitir que a interface interaja com o repositório usando uma conta de aplicativo. Dê à (s) conta (s) da aplicação a quantidade mínima de acesso necessária para que o aplicativo funcione para limitar o impacto de uma conta comprometida.

Eu também recomendaria evitar o uso de credenciais de texto sem formatação no código-fonte ou nos arquivos de configuração. Considere criptografar as credenciais ou, possivelmente, fazer com que o aplicativo seja executado em uma única conta, de modo que todas as solicitações de banco de dados sejam feitas no contexto dessa conta. Dessa forma, o administrador do servidor é responsável por manter as credenciais, não o desenvolvedor.

Por fim, sugiro que você adicione a conta do aplicativo a uma função no banco de dados e conceda a essa função as permissões necessárias necessárias. Isso torna mais fácil lidar com as alterações na conta no futuro (ou seja, adicionar / remover da função em vez de conceder / negar 100 permissões individuais).

    

Answer 2

sim, esta é uma abordagem recomendada. Uma coisa também é possível, quando seu aplicativo está ficando mais complexo e você tem partes diferentes que precisam fazer um trabalho diferente em seu banco de dados, você pode criar mais contas, por exemplo, um com acesso rw e um com apenas acesso de leitura.

mas certifique-se de não torná-lo mais complexo conforme necessário. isso reverterá todas as considerações de segurança, porque em determinado momento você não sabe para qual usuário usar o que e cada usuário receberá mais permissões do que ele precisa.

    

Answer 3

Sim, você está certo. Mesmo se os usuários fizerem login no sistema, provavelmente é melhor que o login seja apenas uma autenticação para usar o programa, enquanto o acesso ao banco de dados é feito por um único usuário.

A desvantagem disso é que, quando você vai verificar seus logs do SQL se algo de ruim aconteceu, todas as alterações terão sido feitas pelo mesmo usuário, dificultando o estreitamento de uma fonte. Um bom design de aplicativo deve ser capaz de evitar isso na sua maior parte, mas apenas tenha isso em mente.

    

Answer 4

Uma prática melhor, mas do tipo "em um mundo ideal", seria ter os mesmos IDs no banco de dados que você tem no aplicativo, e as contas de usuário do DB têm apenas as permissões dentro do banco de dados que correspondem às suas permissões dentro do aplicativo. Então você pode contornar a situação que o Dynamo apontou corretamente - você pode ver dentro do DB os mesmos usuários que estão no aplicativo.

Eu não sei o quão realista isso é implementar (eu certamente não vi isso feito dessa maneira), mas é melhor do que um único usuário do aplicativo que tem todos os direitos sobre o banco de dados do aplicativo - que é muito melhor do que usar a conta 'sa' ou semelhante para a conexão do aplicativo.