Fornecendo aos usuários do MySQL com apenas os privilégios mínimos

Question

Para uma aplicação web, ao criar o usuário que irá se conectar ao banco de dados MySQL, você tem a opção de privilégios. Assumindo que as únicas acções destinam-se a ser feito pelo usuário são SELECT / INSERT / UPDATE / DELETE, parece fazer sentido para apenas fornecer esses privilégios, no entanto eu nunca vi que o recomendado em qualquer lugar - quais são as razões a favor e contra esta método?

Answer 1

Existem outros privilégios que um usuário pode precisar durante uma aplicação comum, por exemplo:

• CREATE TABLE TEMPORÁRIA
• Executar (procedimentos armazenados)
• ARQUIVO (para SELECT INTO e carregar dados)
• LOCK TABLES

Há também a possibilidade de que mínima privilégios só podia significar SELECT no certas tabelas, e só SELECT e UPDATE em outras tabelas, etc. Isto está sujeito a alterações a qualquer momento funcionalidade da aplicação é reforçada. E há casos estranhos, como a necessidade de ter o privilégio SELECT sobre uma mesa você nunca consulta, porque é referenciada pelas chaves estrangeiras em uma tabela que você UPDATE. Então tracking mínima privilégios é uma dor real.

O que você está tentando restringir usando privilégios de SQL? Você é o único que escreveu todo o código, de modo gerir os privilégios de SQL em um bom granularidade não deve ser necessário. Francamente, se os usuários são capazes de carregar e declarações executar o SQL que você não tenha vetado, você tem problemas maiores:

SELECT * FROM mytable, mytable, mytable, mytable, mytable ORDER BY 1;

As tarefas reais que você quer para governar não estão no nível de banco de dados, eles estão no nível de negócios do aplicativo. Por exemplo, um CMS tem operações como criar uma página, editar uma página, comentários administrar, etc. Essas tarefas são de nível superior do que privilégios SQL. Você poderia imitá-los com funções SQL (que são grupos de privilégios), mas papéis SQL não são amplamente suportado.

Eu não conheço ninguém que mapeia os usuários do aplicativo para usuários do MySQL distintas. Eles são usuários que autenticar em seu aplicativo, após o aplicativo foi conectado ao banco de dados (os usuários são apenas linhas de dados no banco de dados).

Então, você é provavelmente melhor fora de ter seu uso web app um único usuário MySQL com privilégios totais.

Answer 2

Não concordo com Bill aqui e linha de pensamento de Atomix é mais adequado. A menos que se possa demonstrar o contrário, a resposta de Bill altamente aumenta o risco do banco de dados a ser comprometida.

Talvez por desenvolvedores muito experientes, há outra garantia no lugar, mas para outros desenvolvedores dando um roteiro completo, acesso irrestrito a fazer ~ nada ~ a um banco de dados está pedindo para ter problemas, quando não há necessidade.

O princípio do menor privilégio deve estar em uso aqui. Para o MySQL, tem um super usuário com todos os privilégios que é usado para a criação de tabelas, banco de dados de queda, e assim por diante. Idealmente este nome de usuário e senha nunca é visto em qualquer arquivo PHP ou qualquer arquivo no servidor web. (Estou usando PHP como exemplo, mas ela se aplica a outras aplicações web). Você só iria usar este nome de usuário e senha com algo como PHPMyAdmin ou MySQL Workbench.

Então, por scripts PHP, ter um com o mínimo exigido, tal como apenas INSERT, SELECT, UPDATE, talvez nem mesmo DELETE, dependendo do seu script PHP. Isso seria nos arquivos PHP, isto é, na verdade, apenas um arquivo fora da raiz do documento, como é recomendado pela maioria.

A razão é assim: sim, você não precisa de um usuário do MySQL para cada usuário do aplicativo web. Mas o princípio do menor privilégio ( http://en.wikipedia.org/wiki/Principle_of_least_privilege ) deve Aplique. Se de alguma forma o seu super usuário do MySQL é comprometida porque você chamado acidentalmente seu script de conexão MySQL como .txt em vez de .php, ou alguém que teve acesso aos arquivos do servidor web, pelo menos, o "pior" que podem fazer é SELECT, UPDATE e INSERT. .. que enquanto pode causar grandes problemas de qualquer maneira, não é tão ruim quanto dando-lhes DROP DATABASE, TABELAS cair e coisas muito piores.

Além disso, em meu projeto atual devido a práticas de desenvolvimento ágil (Eu não trabalho para, mas recomendo http: // www. agilealliance.org/ ), um ou dois "não-tech" membros da equipe estão diretamente usando o phpMyAdmin para fazer alterações directas para o banco de dados MySQL. Isso ocorre porque a criação de um CMS para a entrada directa de dados simples não é necessária. Neste caso, um terceiro usuário MySQL com razoáveis ??mas, novamente, "apenas o suficiente" privilégios é adequado para eles. Nós não queremos prejudicar o membro da equipe com muito pouco privilégios, mas é claro que não deve ser capaz de apagar acidentalmente ou mudar as coisas.

Uma vez que o MySQL não têm papéis (como parte do tempo a pergunta original foi perguntado, e como por Bill), em seguida, permitindo que qualquer script web apenas para MySQL acesso com apenas um Super User é muito arriscado.

Answer 3

A aplicação web normalmente usa apenas um usuário para acessar o banco de dados, em vez de um usuário por conta de usuário real. Aplicando privilégios mínimos é uma boa prática. O nome de usuário e senha vai ser codificado em seu script (alguém ofuscar isso?) Então não há espaço para um compromisso se os seus scripts não são geridos de forma adequada.

Na minha experiência, eu muito, muito raramente têm as linhas de exclusão de aplicativos - muito melhor para sinalizar uma linha como excluídos como você tem então uma auditoria do que está lá, em vez de não saber o que estava lá! Esta abordagem também ajuda tabelas guardar e índices otimizado.

Por isso, gostaria de sugerir permitindo apenas INSERT, UPDATE e SELECT -! Ele vai rapidamente tornar-se aparente se partes de sua necessidade aplicativo para ser relaxado um pouco

Permitindo mais privilégios só pode ampliar a possibilidade de ataques DoS emitindo comandos uso intensivo de recursos, ou permitir ataques de dados maliciosos.