Antecipando o início de uma nova inscrição para o curso continuamos a publicar uma série de artigos sobre criptografia no MySQL.
No artigo anterior desta série, discutimos . Hoje, com base no conhecimento adquirido anteriormente, vamos ver a rotação das chaves principais.
A rotação da chave mestra envolve gerar uma nova chave mestra e criptografar novamente as chaves do tablespace (que são armazenadas nos cabeçalhos do tablespace) com essa nova chave.
Vamos relembrar como é o cabeçalho de um tablespace criptografado:
Do artigo anterior, sabemos que o servidor lê os cabeçalhos de todos os tablespaces criptografados na inicialização e lembra o maior KEY ID. Por exemplo se tivermos três tabelas com KEYID = 3 e uma tabela com KEYID = 4, então o ID máximo da chave será 4. Vamos chamar isso de KEY ID - MAX KEY ID.
Como funciona a rotação da chave mestra
1. O usuário executa ALTER INNODB MASTER KEY.
2. O servidor solicita que o chaveiro gere uma nova chave mestra com o UUID e a CHAVE do servidorID igual a um mais MAXKEYEU IA. Portanto, obtemos o id da chave mestra igual a INNODBKEY-UUID-(MAXKEYidentidade + 1). Após a geração bem-sucedida da chave mestra, MAX KEY ID é incrementado em um (ou seja, MAXKEYID=MAXKEYidentidade + 1).
3. O servidor varre todos os tablespaces criptografados com a chave mestra e para cada tablespace:
-
criptografa a chave do tablespace com a nova chave mestra;
-
atualiza o ID da chave para o novo MAXKEYEU IA;
-
se o UUID for diferente do UUID do servidor, atualize o UUID do servidor.
Como sabemos, o Master Key ID usado para descriptografar uma tabela consiste em um UUID e um KEY ID lidos do cabeçalho do tablespace. O que estamos fazendo agora é atualizar essas informações no cabeçalho de criptografia do tablespace para que o servidor receba a chave mestra correta.
Se tivermos tablespaces de locais diferentes, como backups diferentes, eles podem usar chaves mestras diferentes. Todas essas chaves mestras precisarão ser recuperadas do repositório quando o servidor for iniciado. Isso pode retardar a inicialização do servidor, especialmente se um armazenamento de chaves do lado do servidor for usado. Com a rotação de chave mestra, criptografamos novamente as chaves de espaço de tabela com uma única chave mestra que é a mesma para todos os espaços de tabela. O servidor agora deve receber apenas uma chave mestra na inicialização.
Isso, é claro, é apenas um efeito colateral agradável. O principal objetivo da rotação da chave mestra é tornar nosso servidor mais seguro. Caso a chave mestra tenha sido roubada do cofre (por exemplo, do Vault Server), é possível gerar uma nova chave mestra e criptografar novamente as chaves do tablespace, invalidando a chave roubada. Estamos seguros... quase.
Em um artigo anterior, falei sobre como uma vez que uma chave de espaço de tabela é roubada, um terceiro pode usá-la para descriptografar dados. Desde que haja acesso ao nosso disco. Se a chave mestra for roubada e você tiver acesso aos dados criptografados, poderá usar a chave mestra roubada para descriptografar a chave do tablespace e obter os dados descriptografados. Como você pode ver, a rotação da chave mestra não ajuda neste caso. Criptografamos novamente a chave do tablespace com a nova chave mestra, mas a chave real usada para criptografar/descriptografar os dados permanece a mesma. Portanto, o "hacker" pode continuar a usá-lo para descriptografar os dados. Anteriormente eu insinuei que pode realizar a recriptografia verdadeira do tablespace, não apenas a recriptografia simples da chave do tablespace. Esse recurso é chamado de encadeamentos de criptografia. No entanto, essa funcionalidade ainda é experimental no momento.
A rotação da chave mestra é útil quando a chave mestra é roubada, mas não há como um invasor usá-la e descriptografar as chaves do tablespace.
Consulte Mais informação:
Fonte: habr.com