Encriptação de base de dados ou encriptação de nível de Aplicação?
Quando É necessário armazenar dados sensíveis como CCs ou SSNs, faz:
1) Crie a sua própria rotina de encriptação dentro da aplicação, defina uma chave secreta algures num ficheiro de configuração e depois encripte/descriptografe manualmente os dados que vão para a base de dados.
2) empurrar todo o problema para a base de dados, usando as capacidades construídas em DB (eu acho que a maioria dos vendedores chamam de criptografia de banco de dados transparente).
Que compromissos encontraste para a tua solução? Escrever o seu próprio a rotina teve um mau desempenho quando comparada com o TDE? É a manutenção do código, ou inversamente DB lock-in um problema?4 answers
Eu usei uma variedade de técnicas de criptografia e eu acredito que é mais fácil e mais seguro para criptografar no lado da aplicação usando uma rotina de criptografia comprovada (isto é, bibliotecas.net).
Se cifrar na base de dados, isso significa que os dados são enviados de e para a base de dados de forma não cifrada. Isto permite, potencialmente, bisbilhotar/adulterar entre a aplicação e as rotinas de encriptação na base de dados. Mesmo se você armazenar a chave no lado da aplicação, ainda é necessário no lado da base de dados para executar a encriptação. Se a base de dados estiver comprometida, seus dados estão em sério risco (Basta imaginar alguém executando o profiler enquanto sua aplicação corre).
Se cifrar/descodificar na aplicação, os dados sensíveis (incluindo a chave) nunca são revelados fora do servidor de aplicações. Alguém teria que comprometer tanto o servidor Web e servidor de banco de dados para acessar todos os seus dados.
Além disso, recomendo que não role o seu próprio. rotina de encriptação. É provável que cometa um erro que reduza a segurança geral da sua solução.Editar:
Também queria adicionar outro factor que irá influenciar a tua decisão. Precisa de consultar os dados encriptados? Se você encriptar ao nível da aplicação, você precisará trazer os dados para a aplicação, descriptografar e trabalhar a partir daí. Isto torna-se proibitivo à medida que o conjunto de dados cresce mais - enquanto que com a encriptação de banco de dados você pode filtrar os dados antes de ser enviado de volta para a aplicação.
Quando encripta dados sensíveis, está essencialmente a restringir o acesso àqueles que têm acesso a uma chave. O problema torna-se então um problema de gestão de chaves: garantir que apenas pessoas/sistemas autorizados tenham acesso à chave necessária para descriptografar os dados.
Você deve, naturalmente, usar um algoritmo de criptografia padrão, fácil o suficiente nos dias de hoje, mas o que você precisa pensar é sobre quais ameaças você está protegendo contra, Como você está indo para controlar o acesso à(s) Chave (s), e como você controle o acesso físico aos servidores.
O uso do TDE garante que o conteúdo de uma base de dados e seus backups são criptografados, com impacto mínimo para usuários autorizados da base de dados. Assim, qualquer um que possa acessar o servidor de banco de dados com credenciais válidas será capaz de ver os dados não criptografados. Também qualquer DBA normalmente terá acesso à chave e será capaz de ver os dados não cifrados. Mas um terceiro que, digamos, obtém um backup offsite não será capaz de acessar os dados - que pode ser importante para o cumprimento dos requisitos regulamentares.Por outro lado, se cifrar na lista de aplicações, poderá usar uma chave que só é acessível pelos administradores do servidor de aplicações. Isso potencialmente lhe dá mais segurança, se, por exemplo, servidores de banco de dados e administradores de servidores de aplicações são mantidos separados (por exemplo, membros de diferentes organizações). DBAs que não tem acesso à chave do servidor de aplicação não será capaz de ver os dados.
Na tua post original, você fala sobre esconder uma chave secreta em um arquivo de configuração no servidor de Aplicação. Face a isto, parece o equivalente de segurança a esconder a chave da porta da frente debaixo do tapete. Se você fizer isso, você precisa pensar sobre como você vai garantir que pessoas não autorizadas não podem ter acesso à chave.
Concordo com a Mayo, mas a encriptação no DB pode simplificar a manutenção de todo o sistema.
A encriptação para o nível da aplicação necessita que você gerencie as chaves, a fase de autenticação e autorização para as chaves e a visualização dos dados (de acordo com o que Mayo escreveu).
Se escolher a encriptação da aplicação, terá de se preocupar com a correcção do algoritmo não só na fase de desenvolvimento, mas também na fase de manutenção. Tens de o fazer. aplicar o ensaio unitário de não regressão. Você tem que gerenciar a mudança de algoritmo de criptografia porque talvez você queira um algoritmo diferente e melhor.
E tens de ter a certeza que os dados encriptados serão sempre descodificados. Não é uma coisa óbvia, porque o software tem bugs e assim por diante. dados perdidos são piores do que dados claros. ;-)
Claro que pode usar uma biblioteca de encriptação bem conhecida, mas todas as coisas remanescentes são um trabalho enorme para fazer para si.
Encriptação no DB protege APENAS no DB, mas você pode considerar a utilização de algum tipo de comunicação SSL com o DB. Eu penso (mas não tenho certeza) TDE implementa este tipo de comunicação segura.
A aplicação é usada pelo Utilizador, uma entidade não confiável. Você tem que considerar que os dados na aplicação estão perdidos. Por quê? Se eu quiser roubar dados de um sistema que implementa a criptografia dos dados no nível de aplicação ou nível DB, poderia o suficiente para usar uma câmera fotográfica para obter os dados! Muito simples!
Você tem que considerar a segurança do sistema, mas a funcionalidade também. Mais é a segurança, menos é a funcionalidade. Espero que as minhas considerações sejam úteis para si.
Ser compatível com o PCI-DSS não elimina a sua responsabilidade legal...
Actualmente, existem apenas dois estados que prevêem essa isenção.: Washington & Minnesota...A DBA está a promover a TDE como uma solução PCI-DSS cuidado!
O TDE protege apenas os dados em repouso, não os dados em trânsito ou os dados em memória... Qualquer pessoa que tenha lido acesso pode ler todos os dados com qualquer ferramenta...
O IMHO TDE é bom quando combinado com uma encriptação robusta de Nível de Aplicação solucao... Como uma solução independente usando TDE sozinho, é uma bomba-relógio que o PCI QSA está comprando como compatível com PCI-DSS falharam miseravelmente para tomar nota... Espera até os advogados perceberem esta falha fundamental...
Qualquer guru da segurança dir-lhe-á que as camadas de segurança são a melhor abordagem....