Encriptação no Microsoft SQL Server
O Microsoft SQL Server oferece dois níveis de criptografia:Em nível de banco de dados eEm nível de célula.Ambos usam a hierarquia de gestão de chaves.
Hierarquia da Chave Criptográfica(Cryptographic Key Hierarchy)Na raiz da árvore de criptografia está o DPAPI (Windows Data Protection API), que assegura a hierarquia chave no nível da máquina e é usado para proteger o serviço de chave mestra (SMK) para a instância do servidor do banco de dados.A SMK protege a base de dados de chave mestra (DMK), que é armazenado no banco de dados no nível do utilizador e por sua vez protege certificados e chaves assimétricas. Estes, por sua vez, protegem as chaves simétricas, que protegem os dados.A TDE usa uma hierarquia semelhante até o certificado. A principal diferença é que quando usamos TDE, o DMK e o certificado deve ser armazenado no banco de dados mestre, em vez de no banco de dados do usuário. Uma nova chave, utilizada apenas para TDE e referida como a chave de encriptação de dados (DEK), é criado e armazenado na base de dados do usuário.Esta hierarquia permite que o servidor abra automaticamente as chaves e descriptografe os dados, tanto em nível de célula com em nível de banco de dados. A distinção importante é que, quando a criptografia é utilizada em nível de célula, todas as teclas do DMK para baixo podem ser protegidas por uma senha em vez de outra chave. Isso quebra a cadeia de decodificação e força o usuário a digitar uma senha para acessar os dados. Na TDE, toda a cadeia de DPAPI até a DEK deve ser mantida para que o servidor possa fornecer automaticamente o acesso a arquivos protegidos por TDE. NA criptografia em nível de célula e TDE, a criptografia e a descriptografia através dessas teclas é fornecida pela criptografia do Windows API (CAPI).A figura a seguir mostra a hierarquia de criptografia completa. As linhas pontilhadas representam a hierarquia de criptografia usado pelo TDE.
Figura: SQL Server hierarquia chave de criptografia com TDE e EKMTDE
Criptografia de dados transparente é o novo recurso de criptografia em nível de banco introduzido no SQL Server 2008.
Habilitando a TDE
Para habilitarmos a TDE, precisamos ter as permissões normais associadas com a criação de uma chave mestra de banco de dados e os certificados no banco de dados mestre. Também devemos ter permissões de controle sobre o banco de dados do usuário.
Execute as etapas a seguir no banco de dados mestre:
1. Se ele não existir, crie um banco de dados de chave mestra (DMK) para o banco de dados mestre. Certifique-se que a chave mestra de banco de dados é criptografada pelo serviço chave mestre (SMK).
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'some password';
2. Crie um certificado protetor para uso como a chave de criptografia de banco de dados (DEK). Para ter uma segurança melhor, é recomendável que criemos um novo certificado, cuja única função seja a de proteger a DEK. Assegure-se de que este certificado esteja protegido pela DMK.
CREATE CERTIFICATE tdeCert WITH SUBJECT = 'TDE Certificate';
3. Crie um backup do certificado com a chave privada e armazene-o em um local seguro. (Note que a chave privada é armazenada em um arquivo separado, certifique-se de manter os dois arquivos).
BACKUP CERTIFICATE tdeCert TO FILE = 'path_to_file'WITH PRIVATE KEY (FILE = 'path_to_private_key_file',ENCRYPTION BY PASSWORD = 'cert password');
4. Opcionalmente, ative o SSL no servidor para proteger os dados em trânsito.Execute as etapas a seguir no banco de dados do usuário. Estes necessitam de permissões CONTROL no banco de dados.5. Crie a chave de encriptação de dados (DEK) encriptada com o certificado designada a partir da etapa 2 acima. Este certificado é referenciado como um certificado de servidor para distingui-lo de outros certificados que podem ser armazenados no banco de dados do usuário.
CREATE DATABASE ENCRYPTION KEYWITH ALGORITHM = AES_256ENCRYPTION BY SERVER CERTIFICATE tdeCert
6. Ative o TDE. Este comando inicia uma discussão de fundo (referida como encryption scan), que é executado de forma assíncrona.
ALTER DATABASE myDatabase SET ENCRYPTION ON
Para monitorar o progresso, consulte a exibição sys.dm_database_encryption_keys (a permissão VIEW SERVER STATE é necessária), como no exemplo a seguir:
SELECT db_name(database_id), encryption_stateFROM sys.dm_database_encryption_keys
Como os dados são criptografados
Quando TDE é ativado (ou desativado), o banco de dados é marcado como criptografado no catálogo sys.databases e o estado DEK está definido como criptografia em andamento. O servidor inicia uma discussão de fundo (chamado de criptografia de digitalização ou digitalização) que verifica todos os arquivos de banco de dados e codifica-os (ou decifra-os se estiver desativando o TDE). Enquanto o DDL é executado, um bloqueio de atualização é tomado no banco de dados. A verificação de criptografia, é executada de forma assíncrona no DDL, numa trava compartilhada. Todas as operações normais que não entram em conflito com esses bloqueios podem prosseguir. Operações de exclusão incluem modificações na estrutura do arquivo do banco de dados. Enquanto gravações criptografadas normais no disco a partir do buffer são executadas no banco de dados, gravações no arquivo de log talvez não sejam feitas. A varredura também obriga um rollover para o arquivo de log virtual (VLF), garantindo que futuras gravações do log sejam criptografadas.
Quando a verificação da criptografia for concluída, o estado DEK está definido como criptografado. Neste ponto, todos os arquivos do banco de dados no disco estão criptografados e o arquivo de log será criptografado. Os algoritmos de criptografia suportados são:
AES de 128 bits,AES de 192 bits,Chaves de 256 bits ou3 Chaves Triple DES.
Tags: Raul Garcia, Sameer Tejani, Chas Jeffries, Douglas MacIver, Byron Hynes, Ruslan Ovechkin, Laurentiu Cristofor, Rick Byham, Sethu Kalavakur, SQL Server, SQL, Encryption,
Nenhum comentário:
Postar um comentário