Criptografia MySQL e gerenciamento de chaves

Estou desenvolvendo um sistema de intranet local em PHP / MySQL para gerenciar nossos dados de clientes. Parece que a melhor prática seria criptografar os dados confidenciais no servidor MySQL à medida que eles são inseridos.

Não estou claro, no entanto, sobre qual seria a melhor maneira de fazer isso, mantendo os dados prontamente acessíveis.

Parece uma pergunta difícil de responder: onde estão armazenadas as chaves? Como proteger melhor a chave? Se a chave estiver armazenada na máquina de cada usuário, como protegê-la se a máquina for explorada? Se a chave é explorada, como alterar a chave?

Se a chave deve ser armazenada no banco de dados, como protegê-la lá? Como os usuários acessariam?

Não há realmente nenhum recurso interno do MySQL para lidar com configurações sofisticadas de chaves criptografadas. Você precisará implementar a maior parte da lógica de criptografia em seu próprio código PHP e / ou no navegador (javascript?).

Mas suas preocupações declaradas são um pouco peculiares: parece que suas únicas preocupações reais são uma injeção de SQL ou força bruta (suposição de senha, suponho) ataque de uma estação de trabalho / laptop de cliente remoto. Isso me faz suspeitar que você já tenha outras medidas de segurança não mencionadas planejadas e analisou as possíveis vias de comprometimento.

• Por um lado, suponho que você tenha regras de firewall para proteger o host MySQL / PHP contra qualquer tipo de acesso a partir de IPs remotos não aprovados do cliente. Se eu estiver correto, faz sentido que você esteja preocupado apenas com ataques de estações de trabalho de usuários comprometidos.

• Além disso, suponho que você entenda que, se um invasor no host do cliente remoto puder escalar para root / privs de administrador ou comprometer diretamente a conta do usuário real, os dados do cliente terão proteção zero, independentemente da criptografia ou de outras salvaguardas. (O invasor pode ler as chaves de onde quer que elas estejam salvas no disco ou espioná-las à medida que o usuário real as entra no logon, e as chaves levam aos dados.)

Partindo dessas duas suposições, faz sentido concluir que as duas únicas ameaças relevantes são: A) adivinhação de senha de força bruta e B) tentativas de injeção de SQL:

• Se o invasor não se apossar da chave do usuário real ou se desejar acessar mais do que apenas os dados do usuário real, ele poderá tentar criar brechas de logon de força bruta para o usuário real ou outra conta. (Em teoria, você pode bloquear cada conta em um IP de cliente remoto específico, o que também ajudaria a compartimentar os riscos.)
• Se o invasor obtiver uma chave válida para o usuário real, ele terá uma avenida além da tela de logon (presumivelmente simples o suficiente para ser segura), até o ponto fraco do código do aplicativo potencialmente defeituoso. Uma injeção de SQL bem-sucedida do contexto do usuário real também poderia dar acesso a dados de outros clientes.

Agora, vamos falar sobre como a criptografia do lado do servidor se aplica a estas situações:

• A criptografia do servidor definitivamente ajuda contra a ameaça de injeção de SQL. Se os valores da linha estiverem criptografados nas tabelas do banco de dados, o invasor poderá ver apenas o texto cifrado sem sentido dos dados que pertencem a outras contas. A ameaça está contida, compartimentada.
• No entanto, a adivinhação forçada de senha forçada não fica mais difícil para um invasor que enfrenta a criptografia do servidor. Independentemente de as chaves dos usuários serem armazenadas no servidor ou geradas no local a partir da senha, a única coisa que importa é se você possui a senha correta. O servidor decide permitir que você use a chave armazenada válida porque verifica se sua senha está correta ou calcula a chave válida para você porque sua senha é a entrada correta para gerar essa chave.

A criptografia do lado do cliente, por outro lado, torna os ataques de senha de força bruta irrelevantes. Você não pode forçar com força uma chave adequadamente construída. A criptografia do lado do cliente também mantém basicamente o mesmo nível de proteção contra injeção de SQL que a criptografia do lado do servidor. O cliente pode passar a chave para o servidor no logon, mantendo uma cópia na memória até a sessão terminar, o que coloca a carga de CPU criptográfica no servidor. Ou, o cliente pode lidar com a criptografia / descriptografia por si só, no navegador. Existem altos e baixos nas duas técnicas:

• Passar sua chave para o servidor é muito mais fácil de codificar e gerenciar, e geralmente muito mais rápido devido a um código criptográfico mais otimizado (C compilado, provavelmente).
• Uma abordagem pura do lado do cliente oferece segurança extra, porque, mesmo que um invasor se torne root no servidor, ele ainda não consegue ler os dados criptografados e nunca poderá lê-los. O único vetor de ataque possível é comprometer a estação de trabalho do cliente remoto.

Por fim, observarei que existem grandes desvantagens operacionais na criptografia de dados no banco de dados. Como as representações de dados criptografados são essencialmente padrões aleatórios, os recursos básicos do banco de dados, como indexação, junções etc., não vão funcionar. O cliente assume uma enorme carga lógica e pode perder muitos dos benefícios que os recursos do banco de dados normalmente trazem.

Você pode querer dar uma olhada no ezNcrypt , que usa ecryptfs, controles de acesso e gerenciamento de chaves para fornecer alta segurança e desempenho à criptografia Linux de bancos de dados MySQL e outros processos. Não, eu não trabalho para eles.

Você poderia usar o Scytale. É um proxy de criptografia NoSQL para DBMS e aplicativos da web modernos. Suporta criptografia de múltiplos destinatários e grupos. Carregado com um forte sistema de criptografia RSA / AES. Também é 100% gratuito e de código aberto.

https://bitbucket.org/maximelabelle/scytale