Antes de decidir sobre esses assuntos de segurança, você deve avaliar o modelo de ameaça. Sem uma ideia contra a qual você está se defendendo, qualquer medida que você tome provavelmente terá pouco valor.
Agora, há algumas coisas com as quais você pode se preocupar neste contexto:
- Os invasores obtêm acesso físico aos seus dados (por exemplo, invadir o datacenter, roubar fitas de backup etc.)
- Atacantes obtendo acesso de leitura ao seu banco de dados bruto
- Os invasores comprometem sua aplicação, por exemplo, através de injeção de SQL, saturação de buffer, etc.
Para o primeiro cenário, armazenar o banco de dados e todos os backups em volumes criptografados deve funcionar, desde que o servidor esteja sem cabeça - roubar o servidor ou as fitas exigiriam a quebra da criptografia no nível do disco.
Para o segundo cenário, criptografar dados do banco de dados ajuda, mas apenas se você não armazenar as chaves ou senhas necessárias em qualquer lugar.
No terceiro cenário, tudo depende do contexto em que o ataque ocorre: se, por exemplo, é um ataque XSS ou CSRF, um invasor pode fazer o que o usuário legítimo puder e criptografar seus dados não ajuda em nada. .
O modelo de ameaça, portanto, é um invasor que obtém acesso de leitura ao banco de dados bruto, localizando as credenciais de logon e gerenciando o logon no servidor de banco de dados de fora ou obtendo acesso root ao servidor de banco de dados. Um caminho típico é obter primeiro acesso ao shell no servidor da web; a partir daí, um invasor pode ler as credenciais de acesso do arquivo de configuração e conectar-se ao banco de dados.
Uma consideração adicional é onde você mantém as chaves e as senhas, especialmente se estiver usando uma plataforma com um modelo de execução sem estado, como o PHP. Idealmente, você deve digitar a senha do cliente quando necessário e mantê-la apenas na memória, ou melhor ainda, descriptografar no lado do cliente (mas isso geralmente não é possível). Em uma plataforma sem estado, o estado geralmente é transportado usando sessões, memcache, bancos de dados ou arquivos simples; mas tudo isso é muito mais vulnerável do que manter o estado na própria memória de um aplicativo da Web estável. Evitar isso é um problema de galinha e ovo, porque se você criptografar o estado antes de persistir, acabou de criar outro segredo do qual precisa se lembrar com segurança. Lembrar a senha no cliente e enviá-la juntamente com cada solicitação que precisar pode ser a solução menos horrível;