Início / dba / Perguntas / 8470
Accepted
ThinkingMonkey
Asked: 2011-11-29 05:45:21 +0800 CST

Webapp e MySQL: segurança em nível de linha

  • 772

Estou tentando emular a segurança em nível de linha em um aplicativo da web que estou desenvolvendo usando o MySQL.

Usando este método: Criando um banco de dados com as tabelas necessárias onde os dados pertencentes a todos os usuários serão armazenados com indexação adequada das colunas das tabelas.

Criando 'visualizações' do mysql para usuários específicos com base no ID do usuário.

Para obter segurança no nível da linha, também terei que criar uma conta mysql para cada usuário e definir permissões de 'conceder' nas visualizações.

Para a interface web será usado um framework MVC baseado em PHP.

Mas, de acordo com minha pesquisa:

1] Having separate mysql account per user "make the webapp less secure".
2]Having separate mysql account per user "increases the disk I/O".

Questões:
1] How does creating mysql user per webapp user make the webapp less secure?
2] Does the disk I/O increase considerably?
3] Is there a better way to implement row-level-security in MySQL?
4]What are the pros/cons of implementing row-level-security by the above method?

Por que estou olhando para a segurança em nível de linha?
I need row level security because there are rows which will be shared between multiple users & have 1 or 2 owners to it. Only these owners can delete/modify them.

Não consigo adicionar tags como 'segurança em nível de linha' 'disk-io' porque meus pontos de reputação são menores. Se alguém mais puder, por favor, faça.

mysql database-design

1 respostas

  1. Best Answer

    Como a criação de usuário mysql por usuário de webapp torna o webapp menos seguro?

    • Tudo o que você precisa fazer é executar SHOW GRANTS;nas conexões de banco de dados do aplicativo e todas as concessões para o usuário conectado são expostas. Isso pode incluir ver IPs de host, sub-redes. Concessões para tabelas, exibições e colunas específicas também se tornam visíveis.

    A E/S do disco aumenta consideravelmente?

    • Com certeza faria isso. Embora concessões e exibições sejam armazenadas no banco de dados information_schema (na RAM), cada exibição seria rigorosamente verificada para garantir que as tabelas subjacentes existam para usar a definição de exibição. Isso exigiria acessar o .frm para cada tabela envolvida. Quaisquer concessões em tabelas ou colunas também são verificadas em relação aos arquivos .frm subjacentes.

    Existe uma maneira melhor de implementar segurança em nível de linha no MySQL?

    • Isso pode ser um pouco louco, mas você provavelmente poderia usar gatilhos

    Exemplo

    delimiter $$
CREATE TRIGGER check_row_priv BEFORE UPDATE ON t1
FOR EACH ROW
BEGIN
 IF (USER()='user1@localhost') && (OLD.is_editable=0)
 THEN
    -- Make Trigger Fail Here
 END IF;
END; $$
delimiter ;

    Escrevi outro post que mostra como abortar stored procedures e triggers . Outras respostas na pergunta podem fornecer informações sobre como abortar gatilhos ou, pelo menos, tornar os dados imutáveis.

    Quais são os prós/contras da implementação da segurança em nível de linha pelo método acima?

    • IMHO Em poucas palavras, seria a complexidade da gestão.
    • 5

relate perguntas