Com a proximidade do início de um novo ciclo de inscrições para o curso continuamos publicando uma série de artigos sobre criptografia no MySQL.
No artigo anterior desta série, discutimos . Hoje, com base no conhecimento adquirido anteriormente, vamos analisar a rotação das chaves mestras.
A rotação das chaves mestras envolve gerar uma nova chave mestra e recriptografar as chaves dos espaços de tabelas (que estão armazenadas nos cabeçalhos dos espaços de tabelas) com essa nova chave.
Vamos relembrar como é o cabeçalho de um espaço de tabela criptografado:
Do artigo anterior, sabemos que o servidor, ao iniciar, lê os cabeçalhos de todos os espaços de tabelas criptografados e memoriza o maior KEY ID. Por exemplo, se temos três tabelas com KEYID = 3 e uma tabela com KEYID = 4, o maior identificador de chave será 4. Vamos chamar esse KEY ID de MAX KEY ID.
Como funciona a rotação da chave mestra
1. O usuário executa ALTER INNODB MASTER KEY.
2. O servidor solicita ao armazenamento de chaves (keyring) a geração de uma nova chave mestra com o UUID do servidor e KEYID, que é igual ao MAXKEYID aumentado em um.Assim, obtemos um identificador de chave mestra igual a INNODBKEYKEY-UUID-(MAXKEYID + 1). Após a geração bem-sucedida da chave mestra, o MAX KEY ID é incrementado em um (ou seja, MAXKEYID = MAX
ID + 1).
3. O servidor verifica todos os espaços de tabelas criptografados com a chave mestra e para cada espaço de tabela:
criptografa a chave do espaço de tabela com a nova chave mestra;KEYatualiza o identificador da chave para o novo MAX
ID;
se o UUID for diferente do UUID do servidor, atualiza o UUID do servidor. Sabemos que o identificador da chave mestra (Master Key ID), usado para descriptografar a tabela, consiste no UUID e KEY ID, lidos do cabeçalho do espaço de tabela. O que estamos fazendo agora é atualizar essa informação no cabeçalho de criptografia do espaço de tabela, para que o servidor receba a chave mestra correta.
Se tivermos espaços de tabela adquiridos de diferentes locais, como de diferentes backups, podem usar chaves principais diferentes. Todas essas chaves principais precisarão ser obtidas do armazenamento ao iniciar o servidor. Isso pode retardar a inicialização do servidor, especialmente se um armazenamento de chaves estiver em uso. Com a rotação da chave principal, recriptografamos as chaves dos espaços de tabela com uma única chave principal, a mesma para todos os espaços de tabela. Agora, ao iniciar, o servidor deve obter apenas uma chave principal.
Isso, é claro, é apenas um efeito colateral agradável. O objetivo principal da rotação das chaves principais é tornar o nosso servidor mais seguro. Caso a chave principal tenha sido de alguma forma roubada do armazenamento (por exemplo, do Vault Server), pode-se gerar uma nova chave principal e recriptografar as chaves dos espaços de tabela, tornando a chave roubada inválida. Estamos a salvo... quase.
No artigo anterior, falei que após o roubo da chave do espaço de tabela, um terceiro poderia usá-la para descriptografar os dados, desde que tenha acesso ao nosso disco. No caso do roubo da chave principal e tendo acesso aos dados criptografados, pode-se usar a chave principal roubada para descriptografar a chave do espaço de tabela e obter os dados descriptografados. Como vemos, a rotação da chave principal não ajuda nesse caso. Recriptografamos a chave do espaço de tabela com uma nova chave principal, mas a verdadeira chave usada para criptografar/descriptografar os dados permanece a mesma. Portanto, um "hacker" ainda pode usá-la para descriptografar os dados. Anteriormente, insinuei que pode realizar a verdadeira recriptografia dos espaços de tabela, e não apenas uma simples recriptografia da chave do espaço de tabela. Essa função é chamada de threads de criptografia (encryption threads). Contudo, no momento, essa funcionalidade ainda é experimental.
A rotação da chave principal é útil quando a chave principal é roubada, mas o invasor não tem a capacidade de usá-la e descriptografar as chaves dos espaços de tabela.
Leia mais:
Fonte: habr.com
