Mysql
 sql >> Base de Dados >  >> RDS >> Mysql

Criptografia em repouso e/ou AES_ENCRYPT

Criptografia em repouso


Criptografia em repouso são os dados no banco de dados quando não estão sendo usados/acessados ​​ou atualizados. Criptografia em movimento são coisas como TLS onde os dados (do banco de dados ) é transportado de servidor para servidor para navegador, para servidor, para navegador, etc. O TLS é perfeitamente bom na maioria das situações se for tratado com cuidado e abordado com uma atitude de que você precisa fazer mais do que o mínimo para torná-lo realmente seguro.

Um exemplo típico é que as pessoas colocam um certificado TLS da LetsEncrypt em seu domínio e pensam que de repente todas as suas coisas estão seguras; mas eles não criptografam suas sessões ou seus cookies deixando um enorme buraco potencial em suas defesas.

Não use o sistema de criptografia integrado do MySQL.


Eu não posso enfatizar isso o suficiente; o sistema de criptografia embutido no MySQL não é adequado para proteção de dados segura real.

Leia minha resposta a uma pergunta muito semelhante aqui quanto aos detalhes (não quero simplesmente copiar/colar ).

Ok, então, porque você insiste... aqui:

Pelo que li em minha própria pesquisa sobre este tópico, o link fornecido por Magnus para defuse/php -criptografia é uma das melhores maneiras de evitar que o MySQL faça com que você comprometa seus dados, nunca permitindo que o programa/servidor MySQL veja o valor de texto simples de seus dados.

-- Resposta publicada em 7 de maio de 2017.

Também resposta de Bill Karwin para a mesma pergunta fornece algumas informações adicionais valiosas:

-- Resposta publicada em 7 de maio de 2017.

Ponto de Fechamento:


A segurança é complexa. Se você quiser fazer isso corretamente e ter confiança em suas cascas protetoras de cebola, então você precisa fazer muitas coisas (veja as balas abaixo); mas a primeira coisa que você precisa fazer é:

  • Defina contra quem você está protegendo


Seriamente. Você precisa de estratégias diferentes contra alguém que quer roubar seus nomes e endereços em texto simples versus alguém que quer assumir seu servidor versus alguém que simplesmente quer destruir os dados apenas porque. É um mito que você pode se proteger contra todos o tempo todo, pelo conceito isso é impossível*; então você precisa definir os agressores mais prováveis ​​e então descobrir a melhor forma de mitigar seus avanços.

Especificamente para MySQL, algumas recomendações claras:

  • Mantenha o SQL e o PHP no mesmo servidor. Não acesse remotamente os dados do MySQL.

  • Exclua o acesso externo ao SQL (portanto, é localhost só)

  • Ofusque seus nomes de tabelas e nomes de colunas; se alguém invadir seus dados e você tiver HDTBJ^BTUETHNUYT na coluna username então eles sabem que esse ilegível é provavelmente um nome de usuário, então eles têm um bom começo na tentativa de quebrar sua criptografia.

  • IMPORTANTE :realmente bloqueie o acesso à sua mesa; configurar muitos usuários MySQL, cada um com apenas os privilégios mínimos para fazer o que eles precisam; você deseja que um usuário leia a tabela (somente ) e leia apenas algumas tabelas; usuários escrevam em determinadas tabelas, mas não têm acesso a outras tabelas. É uma separação de preocupação para que, se algum usuário do MySQL for comprometido; você não perdeu automaticamente todos os dados nele contidos.

  • Use serviços de criptografia PHP. Armazene as chaves de criptografia em um local completamente separado; por exemplo, tenha outro servidor que você use apenas para backup que você possa acessar apenas para obter as chaves de criptografia, portanto, se seu servidor PHP/MySQL estiver comprometido, você terá algum espaço para cortar e bloquear o servidor de chaves para que você possa limitar o dano. Se o servidor de chaves também tiver backups, então você não está muito comprometido (dependente da situação ).

  • Configure muitos observadores e informantes de e-mail para dizer exatamente quando certos processos estão sendo executados e quais usuários do servidor (não pessoas, mas programas) estão fazendo o quê. Assim, você pode ver por que um processo inesperado começa a ser executado às 5 da manhã para tentar medir o tamanho das tabelas do MySQL. WTF?

  • Há muito potencial para ter seus dados MySQL AES_ENCRYPT "farejados" mesmo que não estejam em repouso no banco de dados, mas se o site for comprometido (ou pior, o código PHP for inseguro), os ataques de tempo podem funcionar conteúdo de dados por pesquisas de consulta de tempo e retornos de pacotes de dados.

  • A segurança é um buraco negro; em algum momento ou outro você vai pensar "Ei, eu já fiz o suficiente". Ninguém nunca tem segurança total, algumas organizações muito dedicadas têm o suficiente segurança. Você precisa descobrir o quanto está disposto a caminhar antes de percorrer a distância.

* Por que impossível? Porque para proteger seus dados de todas as ameaças, o tempo todo, eles precisariam ser ilegíveis, inutilizáveis, como um hash. Um hash é protegido de todos, o tempo todo. Mas um hash nunca pode ser descompactado.