Autores Anderson de Souza e Rodrigo Dornel

Na parte I discorremos sobre a feature em si, agora iremos demostrar como realizar o processo.

Todo processo de criptografia poderá ser realizado pelo SSMS ou por PowerShell. No SSMS temos a maneira mais amigável, onde o DBA irá escolher a tabela e com um click do botão direito do mouse escolhe a opção Encrypt Columns, conforme figura abaixo:

Nesse nosso exemplo, é possível verificar que algumas colunas não permitem utilizar a feature, conforme a figura abaixo, identificadas na coluna State alguns ícones de proibido. Para saber a causa de não permitir, basta parar com o cursor do mouse em cima do símbolo, conforme exemplo abaixo.

A cada coluna que escolher para criptografar, será necessário definir o tipo de criptografia na coluna Encryption Type, lembrando que temos que escolher entre Determinística ou Randomizado.

Depois de definido as colunas na tela anterior (Column Selection), na tela seguinte iremos definir alguns itens importantes:

Select column master key: Por padrão será o auto generate, mas nada impede de se criar a CMK antes.

Select the key store provider: Selecionar onde a CMK será armazenada, seja no Gerenciador de Certificados do Windows ou no Azure Key Vault, sendo que neste último será necessário ter uma conta no Azure.

Select a master key source: Definir o local onde armazenar a CMK, seja na área de certificado do usuário corrente ou na máquina local. Escolha sempre na máquina local.

Após definir as informações sobre a CMK, o próximo passo será executar os procedimentos (Run Settings):

Podemos gerar um script PowerShell com a criação da CMK e as definições da coluna para executarmos num momento oportuno ou seguir com a execução através da opção Proceed to finish now.

Em dando continuidade com procedimento, uma tela com o resumo será mostrada para que seja analisado o que foi selecionado.

Ao finalizar a análise, escolher o botão Finish para que os procedimentos sejam executados e ao final a tela Results será apresentada, seja indicando sucesso ou falha.

Ao final de todo processo, as colunas definidas estarão criptografadas, nesse caso a coluna Suffix.

Agora temos nossa primeira coluna criptografada!

E se precisarmos fazer um backup desse database e restaurar em outro computador?

Tranquilo, o procedimento pode ser realizado sem problemas e, ao restaurar a coluna seguirá criptografada. Caso necessite ler os dados descriptografados, será necessário exportar a CMK e importar para a máquina onde foi realizado o restore.

Caso queira remover a criptografia momentaneamente, basta alterar o Encrypted Type para PlainText, que os dados da coluna estarão descriptografados.

Se a decisão for por remover a CMK e CEK, todas as colunas utilizando as mesmas chaves, deverão passar pela transformação para PlainText, feito isso, excluir primeiro a CEK e depois CMK.

Um alerta importante: Se perder as chaves, não terá como recuperar os dados, ficarão criptografados, sendo assim, lembre-se de fazer o backup e guardar os mesmos em lugar seguro.

Agora, toda essa segurança não tem ônus?

Sim! Podemos notar pelo gráfico acima, que utilizando Always Encrypted, temos um custo maior no insert e um pouco de leitura randômica de linhas.

No quesito armazenamento, temos um aumento considerável no armazenamento em disco, o que poderá impactar se for um ambiente muito transacionado, pois numa única carga de dados pode facilmente ocupar todo o disco.

Então, vale a pena utilizar essa feature?

Sim, mas como falamos no início desse artigo, é necessário realizar uma análise criteriosa das colunas que irão utilizar a feature e, garantir que o servidor de banco de dados tenha espaço em disco para o crescimento do arquivo de dados (datafiles) e que o tempo de insert não seja algo que possa impactar seu negócio.

Esperamos ter contribuído um pouco e que essa leitura possa direcionar como realizar o procedimento e mostrar que uma boa análise poderá trazer benefícios.

Por hoje é isso, mas em caso de dúvidas é só entrar em contato!

Até o próximo Post!