Após finalizar a primeira série de posts que trata sobre acessos e permissões, vamos avançar sobre o assunto segurança, tratando da criptografia, suas chaves e como nos beneficiar com esse recurso.
E o que a criptografia faz?
A criptografia é a forma de ocultar informações de terceiros não autorizados até que a mensagem seja recebida e descriptografada pelo alvo. O engine do banco de dados aqui, suporta dois níveis de encriptação:
- A nível de coluna, ocultando apenas colunas sensíveis
- Nível de banco como um todo, criptografando o banco no disco
Esses dois modelos garantem que mesmo com acesso, a pessoa que não está autorizada, não conseguirá acessar nenhuma informação criptografada, seja na coluna ou no banco.
NOTA: no nível de banco (que vamos abordar no próximo tema) usuários até conseguem acessar a informação, seja ela sensível ou não. Porém , se ele quiser subir o arquivo .BAK em outro ambiente, precisará da chave e dos certificados, o que estará fora do seu alcance.
CRIPTOGRAFANDO OS DADOS
Como sabemos, a criptografia é o processo de esconder dados via algoritmos e chaves e teoricamente, só quem tem a outra chave de acesso consegue visualizar o que está trafegando entre as pontas de comunicação.
No SQL Server não é diferente, baseado em chaves de segurança ele também consegue prover um sistema hierárquico de segurança protegendo os dados que estão ali armazenados.
Na imagem abaixo, temos a estrutura e a organização do modelo de criptografia adotado pelo SQL Server.
- O sistema de criptografia começa quando instalamos a software no sistema operacional.
- Quando ele é instalado, ele se comunica com o ‘Service Master Key’ do Windows que através de uma API chamada “Data Protection API’ cria um sistema de criptografia e encriptação para o serviço de banco de dados.
- Após, o próprio SQL Server cria seu ‘Service Master Key’ que é um serviço de gerenciamento para a chave mestra que criamos no banco de sistema Master. (essa chave é única. Somente uma por instância).
- Com a Master key criada, estamos aptos a criar as chaves de encriptação dos bancos de dados, certificados de segurança, chaves simétricas e assimétricas que compõem toda a criptografia e sistemas de segurança dentro do SQL Server.
TIPOS DE CHAVES E CERTIFICADOS
- Service Master Key – é o principal componente e o topo da hierarquia quando falamos de criptografia no banco. Antes de criarmos qualquer chave ou certificado precisamos da Master Key, que é gerenciada pela Service Master Key
- Master key – é uma chave mestra e simétrica de toda instância. Serve de parâmetro para todo o sistema de criptografia; somente uma por instância e fica armazenada no banco Master.
- Database Master key – é a chave mestra a nível de banco de dados, sendo única para cada um. é uma chave simétrica que criptografa o banco no storage system. No Azure SQL ela é criada automaticamente pelo próprio serviço.
- Chave Assimétrica – É um padrão de chave usado para criptografia de certificados e chaves simétricas e possui em sua composição duas chaves, uma privada e uma pública; Não é recomendada para criptografar dados devido a sua complexidade, pode causar overhead de performance no ambiente.
- Chave simétrica – é uma chave única, o que a torna mais rápida de processar, por esse motivo, sua preferência na criptografia de colunas em detrimento a chave assimétrica. Não é aconselhada para ambientes distribuídos, pois, pode ser decifrada e quebrada por ataques maliciosos.
- Certificados – são assinaturas digitais que possuem uma chave pública e por opção, uma chave privada.
Quando criamos um certificado, se não declaramos a forma como ele será protegido com a cláusula ENCRYPTION BY, ele automaticamente usará a master key.
Atenção com certificados, eles também são custosos em seus processamentos, logo, devem ser usados com cautela
NOTA: O padrão de criptografia é usar a chave simétrica e a chave assimétrica para criptografar a chave simétrica, assim, não compromete a performance.
E assim, finalizamos a introdução a criptografia e no próximo post, vamos aprender como criptografar o banco no disco com o Transparent Data Encryption.
Vejo vocês no próximo post.