O que é criptografado
O TDE opera no nível I/O através do pool do buffer. Assim, todos os dados que são gravados no arquivo de banco de dados (* mdf) são criptografados. Dados em uso não são criptografados, porque o TDE não oferece proteção para a memória ou o nível de trânsito. O log de transações também é protegido, mas ressalvas adicionais se aplicam. Snapshots e backups são projetados para aproveitar a criptografia fornecida pelo TDE assim que estes forem criptografados no disco também.
Para os dados que estão em uso, todas as páginas são descriptografados à medida que são lidas e armazenadas no buffer e estão na memória. O sistema operacional pode paginar os dados de memória como parte do gerenciamento da memória. Neste processo, dados decifrados podem ser gravados em disco. O Windows e o SQL Server podem ser configurados para evitar que a memória seja paginada para o disco, embora o custo do desempenho possa ser elevado. Outras ações do SO, como hibernação e despejos (hibernation e crash dumps) também podem causar a gravação da memória em disco. Os dados em trânsito não são protegidos porque a informação já foi decifrada antes de chegar a este ponto; o SSL deve ser ativado para proteger a comunicação entre o servidor e todos os clientes.
Quando o arquivo de paginação do banco de dados for gravado em disco, os cabeçalhos não serão criptografados com o restante dos dados, pois esta informação será necessária para que a página seja recarregada. O cabeçalho contém detalhes de status, o nível de compatibilidade do banco de dados, a versão do banco de dados, status de espelhamento, e assim por diante. Quaisquer dados importantes (tais como a DEK) são criptografados, antes de serem inseridos no cabeçalho. O cabeçalho também inclui uma corrupção de dados checksum (CRC). Os usuários podem ter tanto uma soma de verificação sobre o texto simples, como uma soma de verificação de textos cifrados. Esta não é uma soma de verificação criptográfica, a qual detecta apenas a corrupção de dados (verificação para ver se os dados estão legíveis) e não a integridade dos dados (verificação para ver se os dados foram modificados). Todos os outros dados do usuário que estão armazenados no banco de dados da página serão criptografados, incluindo os não utilizados (ou excluídos anteriormente) nas seções de dados, para evitar vazamento de informações. Quando o TDE for ativado em qualquer banco de dados de usuário, a criptografia também é automaticamente habilitada para o banco de dados temporário (tempdb). Isso evita que os objetos temporários usados pelo banco de dados do usuário, vazem para o disco. Bases de dados de outros sistemas com tempdb não podem atualmente ser criptografadas usando TDE.
Criptografia no nível I/O também permite que os snapshots e backups a ser criptografados, portanto, todos os snapshots e backups criados pelo banco de dados sejam criptografados por TDE. O certificado que foi usado para proteger a DEK quando o arquivo foi escrito deve estar no servidor para que estes arquivos sejam restaurados ou recarregados. Desse modo, devemos manter backups de todos os certificados usados, não apenas os certificados mais atuais.O log de transações é mais complicado. Como o log de transações é concebido como uma gravação única de falha de segurança, o TDE não tenta criptografar partes dos registros que já estão gravados no disco. Da mesma forma, o cabeçalho de log não pode ser re-escrito por causa deste princípio de gravação única. Por isso não há garantia de que os dados que são gravados no log mesmo depois de TDE habilitada seja criptografada. A verificação de fundo TDE força o log para passar para o próximo limite VLF, o que permite que a chave seja armazenada no cabeçalho. Neste ponto, se a verificação do arquivo também for completa, as mudanças de estado para a DEK criptografada e todas as posteriores gravações no log serão criptografados.
Impacto sobre a base de dados
O TDE foi projetado para ser o mais transparente possível.
Enquanto as operações de TDE não forem permitidas o banco de dados mantém quaisquer grupos de arquivos como somente leitura, o TDE pode ser usado como arquivos somente leitura. Para habilitar o TDE num banco de dados que tem de arquivos somente leitura, os grupos de arquivos devem primeiro ser configurados para permitir que se grave. Após a verificação da criptografia completa, o grupo de arquivos pode ser definido de volta para somente leitura. A descriptografia deve ser realizada da mesma forma.
O impacto no desempenho da TDE é menor. Como a criptografia ocorre no nível do banco de dados, o banco de dados tem índices de alavancagem e chaves para otimização da consulta. Isto permite uma gama completa de exames de igualdade. Em testes usando dados de exemplo e TPC-C, o impacto sobre o desempenho global foi estimado em cerca de 3-5% e pode ser muito menor se a maioria dos dados acessados estiverem armazenados na memória. A criptografia é intensivamente realizada pelo I/O da CPU. Portanto, os servidores com baixo I/O e uma carga de CPU baixa terá o menor impacto de desempenho. Aplicações com alto uso da CPU sofrerão maior perda de desempenho, estimado em cerca de 28%. O custo principal é no uso da CPU, por isso mesmo aplicações ou servidores com alta utilização de I/O não devem ser muito prejudicados se o uso da CPU for suficientemente baixo. Também, devido a verificação da criptografia inicial criar um novo segmento, o impacto no desempenho seja mais forte, nestes casos, espera-se que as consultas sejam executadas sob uma magnitude pior.
O TDE não é uma forma de controle de acesso. Todos os usuários que têm permissão para acessar o banco de dados ainda o terão, não precisam de permissão para usar a DEK.O TDE está disponível apenas nas edições Enterprise e Developer do SQL Server 2008. As bases de dados utilizadas em outras edições não podem ser criptografadas usando-se o TDE, sob outras edições o servidor emitirá um erro na tentativa de anexar ou restaurar.
Backups de banco de dados
Quando TDE estiver habilitado em um banco de dados, todos os backups são criptografados. Assim, cuidados especiais devem ser tomados para garantir que o certificado que foi usado para proteger a DEK (consulte Como habilitar a TDE) é apoiado e mantido com o backup do banco de dados. Se este certificado (ou certificados) for perdido, os dados não poderão ser lidos. Faça backup do certificado, juntamente com o banco de dados. Cada backup do certificado deve ter dois arquivos; ambos os arquivos devem ser arquivados (idealmente separadamente do arquivo de backup do banco de dados para segurança). Alternativamente, considere usar o recurso da chave de gestão extensível EKM (Extensible Key Management) para armazenamento e manutenção de chaves usadas para a TDE.
Outras características que escrever para o disco
Se um recurso grava no disco através do pool do buffer, os dados são protegidos. Recursos que grava diretamente para arquivos fora da área de buffer devem gerenciar manualmente a criptografia e descriptografia. Assim, as versões mais antigas do Full-Text Search e até mesmo as características Filestream não serão protegidos por TDE.
Criptografia no Nível de Célula
O SQL Server oferece criptografia no nível da célula. A criptografia no nível de célula foi introduzido no Microsoft SQL Server 2005 e ainda é totalmente suportado. A criptografia no nível de célula é implementada como uma série de built-ins e uma hierarquia de gestão de chaves. Usar essa criptografia é um processo manual que exige uma re-estruturação do aplicativo para evocar as funções de criptografia e descriptografia. Além disso, o esquema tem de ser modificado para armazenar os dados como varbinary e, em seguida, re-convertida para os tipos de dados apropriados, ao serem lidas. As tradicionais limitações de criptografia são inerentes a este método.
Comparação com TDE
A criptografia em nível celular tem uma série de vantagens sobre o banco de dados em termos de criptografia. Oferece um nível mais granular de criptografia. Os dados não são descodificados até que sejam utilizados (quando a descodificação embutida é evocada), de modo que, mesmo que uma página seja carregado na memória, os dados disponíveis não estão claros. A criptografia no nível de célula também permite o gerenciamento explícito de chaves. As chaves podem ser atribuídas a usuários e protegidas por senhas para impedir a descriptografia automática. Isto oferece um outro grau de controle (os utilizadores podem, por exemplo, ter teclas individuais para os seus próprios dados), no entanto, o administrador fica ainda mais sobrecarregado com a manutenção das chaves (embora o Extensible Key Management possa também ser usado para facilitar a administração). Devido a criptografia no nível de célula ser altamente configurável, pode ser uma boa opção em aplicações que têm como alvo os requisitos de segurança.As desvantagens principais da criptografia no nível da aplicação são as mudanças necessárias para usá-la, as penalidades de desempenho, e os custos de administração. Como observado anteriormente, a criptografia e a descriptografia requerem que usemos built-ins. Este é um processo inteiramente manual e requer o tipo de dados varbinary, o que significa que os valroes originais das colunas devam ser alterados para o tipo varbinary. Por questões de segurança, a encriptação é sempre salgada de modo que os mesmos dados terão um valor diferente depois de criptografia. Como resultado, restrições referenciais, como chaves estrangeiras e chaves de candidatos, como chaves primárias não oferecem qualquer benefício sobre estas colunas criptografadas. Também afetará as consultas de otimização de índices e as colunas criptografadas não oferecerão nenhuma vantagem para pesquisas de alcance e em varreduras de tabela cheia. O TDE permite o pleno uso dos índices e outras ferramentas de otimização tradicionais de consulta, bem como execução da criptografia em massa.Numa comparação a grosso modo para análise de desempenho, podemos dizer que numa consulta básica (que seleciona e descriptografe uma única coluna criptografada) ao usar criptografia em nível de célula, esta tende a ser cerca de 20% pior. Este balanceamento é inversamente proporcional ao tamanho da carga de trabalho, resultando em degradações de desempenho que são diversas magnitudes pior ao tentar criptografar um banco de dados inteiro. Um exemplo de aplicativo com 10.000 linhas ficou quatro vezes pior tendo uma coluna criptografada, e 20 vezes pior com nove colunas criptografadas. Tudo isso porque o nível de criptografia a nível celular é personalizado para cada aplicação, a degradação do desempenho variará dependendo da aplicação e especificações de carga de trabalho. Conforme observado no impacto sobre o banco de dados, este compara 3-5% para a TDE, em média, e 28% no pior caso (assumindo que a verificação de criptografia não esteja em execução).Embora estas preocupações de desempenho em nível celular possa afetar mitigados por design aplicação explícita, mais cuidados devem ser tomados para evitar a fuga acidental de dados. Por exemplo, considere um sistema rápido para permitir pesquisas rápidas de igualdade usando hashes dos dados sensíveis. Se estes hashes são armazenados em uma coluna, juntamente com os dados codificados, torna-se rapidamente óbvio se duas linhas tiverem valores idênticos porque a hashes será o mesmo. Revisões de segurança adicionais devem ser utilizados para garantir que a divulgação de dados não intencionais não ocorrem assim o banco de dados e aplicação de segurança deve ser consciente. TDE impede que esses cenários de vazamento de dados por meio da criptografia no escopo mais amplo. Em criptografia em nível de célula e banco de dados de nível de criptografia, a informação é descodificada no servidor; dados descriptografados é enviado para clientes em texto simples. SSL é recomendado para proteger este canal.
Uso recomendado com TDE
Nível de célula de criptografia pode ser usada para defesa em profundidade, tanto para um banco de dados criptografado pelo TDE e para controle de acesso limitado através do uso de senhas. Dessa forma, mesmo se qualquer TDE ou autorização é subvertida, os dados podem ainda ser seguro se ele é criptografado na raiz por uma senha para que ele não pode ser tão facilmente acessado. Enquanto todas as desvantagens do uso de células de nível de criptografia aplicar, usando tanto a criptografia em nível de célula e TDE pode ser útil para um subconjunto de dados altamente sensíveis.Em geral, TDE e celular criptografia em nível de cumprir dois objetivos diferentes. Se a quantidade de dados que devem ser criptografados for muito pequeno ou se o aplicativo precisar ser reprojetado para uso (ou se o aplicativo tem requisitos de design personalizado) e o desempenho não for uma preocupação, a criptografia celular recomendada com o TDE. Caso contrário, o TDE é recomendado para criptografar as aplicações existentes ou para aplicações sensíveis de desempenho.
Gerenciamento Extensível de Chaves
O EKM (Extensible Key Management) é outro novo recurso do SQL Server 2008. Ele permite que partes da hierarquia de chave criptográfica a serem geridas por uma fonte externa, como o Hardware Security Module (HSM). Operações de criptografia e descriptografia usando essas chaves são tratadas pelo provedor de criptografia. Isto permite flexibilidade e escolha em provedores de criptografia, bem como o gerenciamento de chave comum. O TDE suporta chaves assimétricas que são provisionadas pelo EKM. Nenhuma outra forma de chave assimétrica é suportada pelo TDE e certificados de banco de dados não podem atualmente ser provisionados através do EKM. O EKM é suportado para a célula através de criptografia em nível de chaves simétricas e assimétricas. É altamente recomendado que usemos o EKM tanto no banco de dados como em nível de celular para gerenciamento de chaves mais abrangente e baseada em hardware de criptografia (se disponível através do HSM).
Tags: Raul Garcia, Sameer Tejani, Chas Jeffries, Douglas MacIver, Byron Hynes, Ruslan Ovechkin, Laurentiu Cristofor, Rick Byham, Sethu Kalavakur, SQL Server, SQL, Encryption,
