Desenhando Bancos de Dados
O primeiro passo é sempre criar o banco de dados, a não ser que você queira
usar um de terceiros. Quando um banco de dados é criado, ele é
atribuído a um dono, que executou os comandos de criação. Normalmente, só
o dono (ou um superusuário) pode faz algo com os objetos naquele
banco de dados, e para permitir que outros usuários usem, privilégios devem
ser concedidos.
Aplicações nunca devem conecta ao banco de dados como seu dono ou um
superusuário, porque esses usuários podem executar qualquer consulta que
quiserem, por exemplo, modificar o esquema (ex.: destruindo tabelas) ou
removendo seu conteúdo completamente.
Você pode criar usuários de bancos de dados diferentes para cada aspecto
da sua aplicação com direitos muito limitados aos objetos do banco de dados.
Apenas os privilégios mais necessários devem ser concedidos, e evitar que o
mesmo usuário possa interagir com o banco de dados em casos de uso diferentes. Isso
significa que se invasores conseguirem acessar seu bando usando credenciais da sua
aplicação, eles só podem afetar o banco tanto quanto sua aplicação.
Encorajamos não implementar toda a lógica de negócio na aplicação
web (ex.: seu script). Ao invés disso, faça parte no esquema do banco,
usando view, triggers ou rules. Se o sistema evoluir, crescerá a vontade de
criar novas maneiras de usar o banco, e você terá que reimplementar a lógica
em cada cliente separado do banco. Além disso, triggers podem ser usados
para lidar com certos campos de maneira automática e transparente, o que
permite dar informações quando depurar problemas com sua aplicação ou
rastreando transações.
krystian at jablonowski dot eu ¶1 year ago
It's a good practice to create a user account with absolutely minimal permissions. Whenever You need to select those permissions by columns or tables remember that some rules don't apply to security measures on Your server, like "We are all adults here" or "KISS - Keep It Simple Stupid". Personally, I prefer to create a minimal amount of users with only the necessary authorization to manipulate or collect data from DB.
Remember, that leak of data can have tremendous consequences, and rebuilding the trust of Your users is extremely hard to accomplish.