VPS configurado para o MySQL

Question

Nosso VPS é configurado de tal forma que todos os bancos de dados são acessíveis a partir de qualquer domínio via localhost e o nome de usuário / senha / dbname.

Esta é a configuração usual, ou deve haver alguma maneira de 'prender' cada usuário, para que eles não possam acessar outros bancos de dados no host local?

Obrigado Mark

    

Answer 1

Como o Caleb menciona, ao configurar o MySQL, é melhor, como com outros sistemas, operar um sistema com privilégios mínimos - a menos que os diferentes aplicativos estejam relacionados, então há poucas razões para eles terem acesso a cada um deles. outros bancos de dados. Se alguns estão relacionados, então eles devem ter privilégios específicos, limitados nas tabelas que precisam acessar no outro banco de dados, mas não mais.

Estou assumindo que quando você diz

accessible from any domain via localhost

você quer dizer que você está executando uma instalação multi-domínio do Apache (ou similar), isso significa que todos os seus aplicativos estão rodando na mesma máquina e, do ponto de vista do MySQL, todo usuário é um usuário 'username'@'localhost' , então você está restrito a especificar usuários por nome de usuário.

É importante observar que, devido à maneira como as permissões do MySQL funcionam, em uma situação em que você tem usuários remotos, 'user1'@'abc.example.com' é realmente um usuário completamente diferente para 'user1'@'xyz.example.com' ou 'user1'@'localhost' compartilhar um nome de usuário que aumenta significativamente sua flexibilidade ao definir permissões (ou torna as coisas muito confusas, dependendo da sua perspectiva). É um ponto a favor da execução do seu servidor de banco de dados em uma VM diferente, se você puder - não é necessário ter, é claro.

O método comum, fácil de usar (e inseguro) para adicionar usuários de banco de dados tende a ser algo como:

GRANT ALL ON *.* TO 'user1'@'localhost';

que simplesmente dá ao usuário GLOBAL privilégios para fazer qualquer coisa em qualquer banco de dados.

Isso é ruim para algumas razões óbvias e outras não tão óbvias. *.* inclui o banco de dados mysql em si - que permite fazer qualquer coisa que você gosta com outros usuários, configurações etc., e deve ser evitado. A parte ALL da instrução concede todos os privilégios disponíveis no escopo GLOBAL - isso significa que eles podem fazer coisas como SHOW PROCESSLIST e KILL <query-id> . Pode parecer bom ("por que eles fariam isso de qualquer maneira?") Mas, novamente, como Caleb observa - se o aplicativo for comprometido, o usuário do banco de dados com o qual ele se conecta é o usuário que o atacante "usa" contra você.

Uma melhoria simples do que foi dito acima é atribuir privilégios usando uma declaração como essa, para cada banco de dados:

GRANT ALL ON 'user1_database'.* TO 'user1'@'localhost';

Isso concede todos os privilégios de nível DATABASE a user1 on user1_database - isso é importante, pois exclui todos os% privilégios deGLOBAL listados acima, então agora o usuário pode, na pior das hipóteses, descartar seu próprio banco de dados.

Uma melhoria adicional para este método é criar pelo menos dois usuários por aplicativo. Um com GRANT ALL no banco de dados (para administração) e outro a ser usado pelo próprio aplicativo da web que possui apenas os privilégios necessários e apenas nos objetos aos quais ele precisa de acesso. Isto é obviamente um pouco de trabalho extra quando você faz mudanças, e testes extras, mas bem feito, pode reduzir significativamente o dano possível se o sistema estiver comprometido.

Eu geralmente tenho um usuário padrão e outro com um sufixo _www para um aplicativo da Web.

Você pode simplificar um pouco disso usando os privilégios curinga do MySQL e ter usuários capazes de criar seus próprios bancos de dados (que correspondam a um determinado padrão) e

Exemplo

-- Create a user that has ALL privileges on databases beginning with 'user1_' 
-- This is our application admin user 
-- it can create any database that matches the pattern

GRANT ALL ON 'user1\_%'.* TO 'user1'@'localhost';

-- Create a "safe" version of this user with just the ability to modify data
-- This is a generic approach and could be applied at object level per-database

GRANT SELECT, INSERT, UPDATE, DELETE ON 'user1\_%'.* TO 'user1_www'@'localhost';

A forma como o usuário administrador é criado no exemplo é um método comum em um ambiente compartilhado - ele permite que os usuários criem bancos de dados, sem atribuir GLOBAL privilégios para que eles não possam ver os bancos de dados de outros usuários.

    

Answer 2

Você deve usar privilégios mais refinados usando a tabela de privilégios do MySQL para que cada aplicativo (ou até mesmo componente de um aplicativo) tenha acesso somente aos bancos de dados ou tabelas que são necessários para sua função. Isso reduzirá possíveis problemas com violações de privacidade, reduzirá danos em caso de violação de segurança e até mesmo ajudará a revelar erros em seu software durante o teste.

    

Answer 3

Como @simon e @caleb mencionam, é comum que permissões globais sejam dadas, mas isso não é uma boa prática, eu uso essa 'macro' (que eu criei com base em outra postagem em serverfault ou SO, não me lembro qual deles tho ') para privilégios:

SET @usr = '\'username\'@\'localhost\'';
SET @pwd = '\'longpassword\'';
SET @db = 'database';
set @query = CONCAT('revoke all privileges on *.* from ', @usr);PREPARE stmt FROM @query;EXECUTE stmt;DEALLOCATE PREPARE stmt;
set @query = CONCAT('drop user ', @usr);PREPARE stmt FROM @query;EXECUTE stmt;DEALLOCATE PREPARE stmt;
set @query = CONCAT('create user ', @usr, ' identified by ', @pwd);PREPARE stmt FROM @query;EXECUTE stmt;DEALLOCATE PREPARE stmt;
set @obj = CONCAT(@db, '.tablename');SET @query = CONCAT('GRANT select ON ', @obj, ' TO ', @usr, ' identified by ', @pwd);PREPARE stmt FROM @query;EXECUTE stmt;DEALLOCATE PREPARE stmt;

removendo as linhas 'revoke', 'drop' e 'create' e alterando o nome da tabela e os privilégios conforme necessário. Ele permite, como sugere o @caleb, a criação de privilégios refinados com o mínimo de problemas.