Quais são os privilégios razoáveis ​​para conceder aos usuários típicos? [fechadas]

Acho a lista de privilégios fornecidos pelo MySQL um pouco esmagadora. Não tenho certeza de quem deve ter quais privilégios. Na minha opinião, existem três usuários típicos para minha situação:

1. root
2. developer
3. application

rooté auto-explicativo. Para que developeresse usuário precise acessar facilmente qualquer banco de dados, faça ajustes nele, etc. Para começar, estou configurando esse usuário para este conjunto de privilégios:

SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, EVENT, TRIGGER ON

applicationtem um conjunto ainda mais limitado. Deve ser limitado apenas à manipulação de um banco de dados específico.

Não tenho certeza do que um conjunto razoável de privilégios deve conceder. O que é um conjunto razoável de privilégios para conceder a um desenvolvedor e um aplicativo e por quê?

Um usuário típico deve ter:

SELECT, INSERT, DELETE, UPDATE, CREATE TEMPORARY TABLES, EXECUTE

Os quatro primeiros são bastante óbvios - embora você também possa configurar usuários "somente leitura" apenas SELECT.

CREATE TEMPORARYtambém é útil e geralmente inofensivo: tabelas temporárias podem ajudar a otimizar consultas, dividindo-as em partes menores e mais rápidas. Eles são limitados à conexão em execução e são descartados automaticamente quando ela é fechada.

EXECUTEdepende do seu tipo de sistema. Você tem rotinas armazenadas? Deseja que seus usuários os acessem? Verifique também a SECURITY=DEFINER/INVOKERdefinição das rotinas armazenadas.

Em qualquer caso, certifique-se de aplicar todas as opções acima em esquemas específicos . Evite usar:

GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO 'some_user'@'some_host';

como o acima também concede privilégios nas mysqltabelas do sistema, permitindo efetivamente a qualquer usuário criar novas contas ou atualizar seu próprio conjunto de privilégios. Em vez disso, faça:

GRANT SELECT, INSERT, UPDATE, DELETE ON some_schema.* TO 'some_user'@'some_host';
GRANT SELECT, INSERT, UPDATE, DELETE ON another_schema.* TO 'some_user'@'some_host';

Em qualquer sistema de escala real (ou seja, não um projeto pessoal), esses tipos de usuários variam de acordo com o ambiente, portanto não é tão simples assim.

Em todos os ambientes, o aplicativo deve ter o que precisa e não mais (geralmente isso é "selecionar / inserir / atualizar em todas as tabelas" e "exec em todos os procedimentos". Para sistemas maiores, onde você pode ter usuários de aplicativos separados para tarefas diferentes (por Por exemplo, um aplicativo é responsável por alimentar os dados do censor e outro por gerar relatórios), você deve separar seus privilégios para que eles tenham o mínimo de que precisam (o usuário que está gerando relatórios provavelmente não precisa e não tem direitos de gravação). ambientes se você os tiver: vi código cair quando promovido ao Live que funcionava em teste porque tudo no ambiente de teste estava acessando o banco de dados como sa(o MSSQL é equivalente a root).Idealmente, um usuário de aplicativo geralmente não deve ter privilégios que permitam alterar seu esquema (CREATE,, DROP...) - há exceções, mas são poucas e distantes entre si.

rooté, bem root,. Na produção, esse é apenas o seu DBA e raramente deve ser usado - apenas para manutenção do sistema (atualizações para o design do banco de dados, etc.) e monitoramento. Para um sistema grande, especialmente em ambientes regulamentados, nos quais é necessário manter um controle rigoroso das pessoas para fins de prestação de contas, talvez você não permita um único rootusuário e tente separar os privilégios em rolos menores (não sei até onde você pode ir) com isso no mysql, mas você pode ser bastante refinado no MSSQL, Oracle e assim por diante).

Para usuários desenvolvedores: eles não devem ter acesso aos seus ambientes ao vivo. Esse é um dos motivos pelos quais os usuários do aplicativo não devem ter um esquema que afeta os direitos: alguém com acesso a uma conta de desenvolvedor pode potencialmente burlar o bloqueio dessa maneira. Também em ambientes de teste, eles geralmente não têm acesso: eles enviavam patches ao controle de qualidade e o DBA (provavelmente usando um rootusuário) aplicava as atualizações ao ambiente de teste (na verdade, isso geralmente é automatizado em grandes organizações, portanto, o DA de controle de qualidade é na verdade um conjunto de scripts que controla a reconstrução do ambiente de teste para cada ciclo). Em ambientes de desenvolvimento, especialmente se os desenvolvedores tiverem suas próprias cópias locais do serviço em execução, é claro que esses usuários devem ter acesso total a tudo para poder experimentar.

O acima é todas as notas gerais: para fazer recomendações específicas, precisamos saber muito mais sobre seus aplicativos e os ambientes em que operam. O ambiente de destino às vezes é mais importante do que você imagina: dependendo do ambiente de negócios os direitos de seus usuários podem até ser ditados de maneira bastante direta, como regulamentos legais, mesmo em desenvolvimento se seus clientes fornecerem acesso a dados reais para fins de diagnóstico.