Opções para criptografia de dados transparente nos bancos de dados do SQL 2005 e 2008

Question

Recentemente, em Massachusetts, foi aprovada uma lei (em vez de forma silenciosa) de que dados contendo dados pessoais identificáveis informações, devem ser criptografadas. PII é definido pelo estado, como contendo o nome e sobrenome do residente, em combinação com qualquer um,

SSN

carteira de motorista ou carteira de identidade #

C. Débito ou CC #

Devido à natureza do software que fazemos, todos os nossos clientes usam o SQL como back-end. Normalmente, os servidores estarão executando o SQl2005 Standard ou superior, às vezes o SQL 2008. Quase todas as máquinas clientes usam o SQL2005 Express. Usamos replicação entre cliente e servidor. Infelizmente, para obter o TDE , você precisa ter o SQL Enterprise em cada máquina, o que não é absolutamente uma opção. Eu estou procurando recomendações de produtos que irão criptografar um banco de dados. No momento, não estou interessado em criptografia completa de disco.

    

Answer 1

Esse também é um requisito de PCI de quando se trabalha com informações de cartão de crédito. Você provavelmente está olhando para criptografar os dados reais nas próprias tabelas. Quando passei por isso, tive que criar novas colunas na (s) tabela (s), gerar os dados criptografados de suas respectivas colunas de origem e, em seguida, remover as colunas de origem (não criptografadas). O problema é que seus aplicativos precisam ser alterados para poder trabalhar com os dados criptografados.

Você também desejará ativar a Encriptação do protocolo Force no servidor.

    

Answer 2

No que diz respeito ao regulamento, existem duas cláusulas que implicam quando usar a criptografia:

• Criptografia de todos os registros e arquivos transmitidos contendo informações pessoais que viajar através de redes públicas e criptografia de todos os dados contendo informações pessoais a serem transmitidas sem fio.
• Criptografia de todas as informações pessoais armazenadas em laptops ou outros dispositivos portáteis.

Assim, a menos que o banco de dados esteja em um laptop ou dispositivo portátil, não é necessário que você criptografe o banco de dados em si (embora haja outras partes do regulamento que se aplicam aos dados nesse estado). Além disso, criptografar os dados nesse estado não o cobriria para o propósito pretendido; quando os dados estão em trânsito. Eu recomendaria que você analisasse a segurança no nível de transporte (ex: HTTPS) quanto à aderência a isso.

No entanto, se a natureza da sua pergunta é realmente sobre como obter os dados criptografados no nível do banco de dados, eu certamente recomendaria usar um produto como TrueCrypt , que permite criptografar um disco virtual representado como um arquivo no sistema de arquivos padrão. Do ponto de vista da praticidade, no entanto, eu recomendaria que você considerasse a criptografia em nível de campo. Isto é, criptografar / descriptografar os campos no nível de aplicativo / serviço e armazenar os valores criptografados nos campos de dados.

    

Answer 3

O TDE só criptografa dados em repouso. Esse é um ponto importante. Portanto, se alguém invadir o SQL Server enquanto estiver em execução, os dados não serão criptografados. Portanto, a abordagem de Squillman é a única maneira de garantir que os dados sejam realmente criptografados, a menos que você saiba com que chaves decodificar. Se isso for suficiente (dados em repouso), o sistema de arquivos com criptografia (EFS) fornecido pelo sistema operacional é uma opção. Isso pode ser definido em arquivos individuais ou no nível da pasta (melhor fazê-lo no nível da pasta). Uma diferença é que o EFS não criptografará os backups. Backups de bancos de dados habilitados para TDE são criptografados. Você precisaria usar um produto de terceiros como o SQL LiteSpeed ou o Red Gate SQL Backup para garantir que os backups sejam protegidos.

E com relação à criptografia do protocolo Force, eu não seguiria esse caminho. Eu prefiro usar uma diretiva IPSEC no nível do sistema operacional usando o Kerberos para gerar o túnel seguro. Isso elimina a necessidade de um certificado SSL ser instalado para ser usado pelo SQL Server.

    

Answer 4

Se a TDE não for aceitável, sua única opção é a criptografia no nível de volume do BitLocker. Para trabalhar com o SQL Server de uma maneira eficiente, a criptografia tem que ser capaz de criptografar / descriptografar uma página em um arquivo, o que significa que deve ser capaz de definir a chave de criptografia no estado correspondente para acessar o deslocamento da página no arquivo. Arquivo. Isso exclui todas as soluções de criptografia em nível de arquivo, porque elas não podem descriptografar / criptografar o bloco X do arquivo sem primeiro descriptografar / criptografar o bloco X-1 (para definir a chave no estado adequado).