Olá Pessoal!
Hoje iremos falar sobre um assunto muito importante no mundo dos dados. Como proteger nossos dados mais importantes no SQL Server!
Dentre as features que possibilitam essa camada de proteção, iremos falar sobre o Always Encrypted.
Mas afinal de contas, o que vem a ser essa feature? Está disponível em todas as verões e edições?
Iremos responder as questões acima e muito mais nessa nossa jornada.
Always Encrypted é um recurso utilizado para proteger os dados mais sensíveis de uma empresa, pois as colunas criptografadas na tabela ficam restritas, ou seja, sem o acesso a chave de criptografia, o texto permanecerá criptografado.
Mesmo as informações estando dentro de sua empresa, o que elas representam só diz respeito ao legítimo proprietário. Dessa forma, proteger esses dados contra invasões é o dever de cada empresa juntamente com suas equipes técnicas.
Essa feature foi disponibilizada no SQL Server 2016 Enterprise e, no primeiro Service Pack para o SQL Server 2016, passou a ser disponibilizado em outras edições. Com o passar dos anos, a Microsoft vem liberando ainda mais recursos do Enterprise para as outras edições, potencializando ainda mais seu produto no mercado. Vale ressaltar que para as versões antes do SQL Server 2019, tínhamos possiblidade de trabalhar somente com igualdades utilizando a criptografia determinística.
A partir do SQL Server 2019, houve uma evolução no Always Encrypted, passamos a contar com o Encryted Enclave, que é uma região protegida da memória dentro do engine, possibilitando assim, que um código T-SQL seja analisado se contém qualquer operação em dados criptografados que possa necessitar do enclave seguro. Durante esse processo as chaves de criptografia e os dados não ficam expostos. Vale ressaltar que para essa evolução veio para nos possibilitar a utilizar as colunas com a criptografia randômica, pois em versões anteriores isso não era possível. A criptografia determinística, segue sendo possível somente com igualdades.
Depois da introdução sobre a feature, vamos explicar sobre a arquitetura do Always Encrypted, onde certamente mostrará como poderemos utilizar e como evitarmos as armadilhas que nosso ambiente poderá nos trazer.
Como parte da segurança da feature, temos dois tipos de chaves utilizadas no processo conforme descrito:
– Column Master Key (CMK):
Chave de proteção de chaves que criptografa uma ou mais chaves de criptografia de coluna (CEK). Essa chave fica armazenada no gerenciador de certificados do sistema operacional.
– Column Encryption Key (CEK):
Usada para criptografar dados em uma coluna criptografada.
Para que o processo de criptografia e descriptografia ocorra, o cliente deverá ter a Column Master Key (CMK), caso contrário, não terá como descriptografar uma coluna.
Como é indicado nos tipos de chaves, a criptografia é realizada a nível de coluna.
Existem algumas regras para que um campo possa ser criptografado pela feature, ver referência 1 em Detalhes do recurso.
A feature trabalha com dois tipos de criptografia e, iremos descrever abaixo:
– Determinística:
Sempre gera o mesmo valor criptografado para qualquer valor de texto sem formatação, ou seja, se existe alguma coluna com informações repetidas, o valor da criptografia será o mesmo para o conteúdo igual.
Nesse tipo de criptografia, é possível utilizar a coluna criptografada, desde que utilizada com operadores igualdade, joins, agrupamentos e indexação.
– Randômica:
É o tipo mais seguro de criptografia, pois gera uma nova sequência criptográfica para cada linha da coluna criptografada. Diferentemente do tipo determinístico, não é possível utilizar a coluna em pesquisas, agrupamentos, indexação e joins.
Com toda essa arquitetura, teremos que analisar com atenção as colunas que iremos criptografar e que tipo de criptografia utilizar, pois existem casos de colunas, que será necessário excluir qualquer constraint que exista nela (uma das regras).
Mas como isso funciona na prática?
Bom, isso ficará para um próximo post.
Até mais! 😊
