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 () falamos sobre armazéns de chaves. Neste artigo, abordaremos como é utilizado a chave mestra (master key), além de discutir as vantagens e desvantagens da criptografia por envelopes (envelope encryption).
A ideia da criptografia por envelopes é que as chaves utilizadas para a criptografia (chaves de tablespace) são criptografadas por outra chave (a chave mestra, master key). As chaves de tablespace são, de fato, utilizadas para criptografar os dados. Graficamente, isso pode ser representado da seguinte forma:
A chave mestra (master key) está no armazém de chaves (keyring), enquanto as chaves de tablespace estão nos cabeçalhos dos tablespaces criptografados (na página 0 do tablespace).
Na figura acima:
A Tabela A é criptografada com a chave 1 (Key 1). A chave 1 é criptografada usando a chave mestra (master key) e armazenada de forma criptografada no cabeçalho da Tabela A.
A Tabela B é criptografada com a chave 2 (Key 2). A chave 2 é criptografada usando a chave mestra (master key) e armazenada de forma criptografada no cabeçalho da Tabela B.
E assim por diante.
Quando o servidor precisa descriptografar a Tabela A, ele obtém a chave mestra do armazém, lê a chave 1 criptografada do cabeçalho da Tabela A e a descriptografa. A chave 1 descriptografada é armazenada em cache na memória do servidor e utilizada para descriptografar a Tabela A.
InnoDB
No InnoDB, a criptografia e descriptografia reais são realizadas no nível de entrada e saída. Ou seja, a página é criptografada imediatamente antes de ser gravada no disco e descriptografada imediatamente após a leitura do disco.
No InnoDB, a criptografia funciona apenas no nível de tablespaces. E por padrão, todas as tabelas são criadas em tablespaces separados (). Em outras palavras, um tablespace é criado para conter apenas uma tabela. Embora você também possa criar tabelas no tablespace principal (). Mas, em qualquer caso, a tabela sempre está em algum tablespace. E como a criptografia é realizada no nível do tablespace, ela é ou totalmente criptografada ou não. Ou seja, não é possível criptografar apenas uma parte das tabelas no tablespace principal.
Se por algum motivo você tiver o file-per-table desativado, todas as tabelas serão criadas dentro do tablespace do sistema. É possível criptografar o tablespace do sistema usando a variável innodbsystablespaceencrypt ou usando threads de criptografia, mas essa ainda é uma função experimental. No MySQL isso não existe.
Antes de prosseguir, precisamos considerar a estrutura do identificador da chave mestra (master key ID). Ele consiste em UUID, ID da chave e o prefixo "INNODBKey". Ele se parece com isso: INNODBKey-UUID-KEYID.UUID é o UUID do servidor com o tablespace criptografado. O ID da chave é simplesmente um valor que aumenta continuamente. Ao criar pela primeira vez a chave mestra, o ID da chave é 1. Quando a chave é rotacionada e uma nova chave mestra é criada, o ID da chave = 2 e assim por diante. Discutiremos mais detalhadamente sobre a rotação das chaves mestras nos próximos artigos desta série.
Agora que sabemos como é o identificador da chave mestra, vamos dar uma olhada no cabeçalho do tablespace criptografado. Quando o tablespace é criptografado, informações sobre a criptografia são adicionadas ao cabeçalho. Ele se parece com isto:O ID da chave é o ID da chave do identificador da chave mestra que já discutimos. UUID é o UUID do servidor, que também é usado no identificador da chave mestra. A CHAVE DO TABLESPACE é uma chave de tablespace que consiste em 256 bits, gerados aleatoriamente pelo servidor. O vetor de inicialização (IV, initialization vector) também consiste em 256 bits gerados aleatoriamente (embora deva ser de 128 bits). O IV é utilizado para inicializar a criptografia e a descriptografia do AES (dos 256 bits, apenas 128 são utilizados). No final, há uma soma de verificação CRC32 para a CHAVE DO TABLESPACE e o IV.Durante todo esse tempo, eu simplifiquei um pouco, dizendo que no cabeçalho existem uma chave de tablespace criptografada. Na verdade, a chave do tablespace e o vetor de inicialização são armazenados e criptografados juntos com a chave mestra. Lembre-se de que antes de criptografar a chave do tablespace e o vetor de inicialização, um CRC32 é calculado para eles.Por que o CRC32 é necessário?
Agora que sabemos como é o identificador da chave principal, vamos analisar o cabeçalho do espaço de tabela criptografado. Quando o espaço de tabela é criptografado, as informações de criptografia são adicionadas ao cabeçalho. Ele se apresenta da seguinte forma:
ID DA CHAVE — é a CHAVEID do identificador da chave principal que já discutimos. UUID é o uuid do servidor, que também é utilizado no identificador da chave principal. A CHAVE DO ESPAÇO DE TABELA — é uma chave de espaço de tabela composta por 256 bits, gerada aleatoriamente pelo servidor. O vetor de inicialização (IV, initialization vector) também consiste em 256 bits gerados aleatoriamente (embora deva ser de 128 bits). O IV é usado para inicializar a criptografia e a descriptografia AES (dos 256 bits, apenas 128 são utilizados). No final, há uma soma de verificação CRC32 para a CHAVE DO ESPAÇO DE TABELA e IV.
Durante todo esse tempo, simplifiquei um pouco, dizendo que o cabeçalho contém a chave criptografada do espaço de tabela. Na verdade, a chave do espaço de tabela e o vetor de inicialização são armazenados e criptografados juntos com a chave principal. Lembre-se de que, antes da criptografia da chave do espaço de tabela e do vetor de inicialização, a CRC32 é calculada para eles.
Por que é necessário o CRC32?
Em poucas palavras, para verificar a validade da chave principal. Após a decodificação da chave do espaço de tabela e do vetor de inicialização, calcula-se a soma de verificação e compara-se com o CRC32 armazenado no cabeçalho. Se as somas de verificação coincidirem, temos a chave principal correta e a chave do espaço de tabela. Caso contrário, o espaço de tabela é marcado como ausente (ainda não conseguiremos decifrá-lo).
Você pode perguntar: em que momento ocorre a verificação das chaves? A resposta é — no início do servidor. O servidor com tabelas / espaços de tabela criptografados lê UUID, KEYID do cabeçalho e gera o identificador da chave principal. Em seguida, obtém a chave principal necessária do armazenamento (keyring), decifra a chave do espaço de tabela e verifica a soma de verificação. Novamente, se a soma de verificação coincidir, tudo está em ordem; se não, o espaço de tabela é marcado como ausente.
Se você leu o artigo anterior desta série (), talvez se lembre de que ao usar o armazenamento de chaves do servidor, o servidor obtém apenas a lista de identificadores de chaves, mais precisamente, o key id e o user id, uma vez que esse par identifica a chave de forma inequívoca. Agora eu digo que o servidor, ao iniciar, obtém todas as chaves necessárias para verificar a possibilidade de decifrar as chaves dos espaços de tabela. Então, por que, na inicialização, no caso do armazenamento de servidor, são carregados apenas o keyid e userid, e não todas as chaves? Porque você pode não precisar de todas as chaves. Isso está principalmente relacionado à rotação da chave principal. Ao rotacionar a chave principal, um novo chave principal é criado no armazenamento, mas as chaves antigas não são excluídas. Assim, no armazenamento de chaves do servidor, você pode ter muitas chaves que não são necessárias para o servidor e, portanto, não são extraídas ao iniciar o servidor.
Chegou a hora de falar um pouco sobre as vantagens e desvantagens da criptografia utilizando a chave principal. A maior vantagem é que você precisa apenas de uma chave de criptografia (a chave principal), que será armazenada separadamente dos seus dados criptografados. Isso torna o lançamento do servidor rápido e o armazenamento pequeno, facilitando a gestão. Além disso, a única chave principal é fácil de regenerar.
No entanto, a criptografia com a chave principal tem uma grande desvantagem: depois que o espaço de tabelas é criptografado com tablespace_key, ele permanece criptografado com a mesma chave. A rotação da chave principal aqui não ajuda. Por que isso é uma desvantagem? Sabemos que o MySQL possui bugs que podem levar a falhas inesperadas e à criação de arquivos core. Como o arquivo core contém um dump da memória do servidor, pode acontecer que no dump haja uma chave de espaço de tabelas descriptografada. O que é pior, as chaves descriptografadas do espaço de tabelas são armazenadas em memória que pode ser trocada para o disco. Você pode dizer que isso não é uma desvantagem, uma vez que são necessários direitos de root para acessar esses arquivos e a partição de swap. Sim. Mas o root é necessário apenas por um tempo. Assim que alguém obtiver acesso à chave descriptografada do espaço de tabelas, ele / ela poderá continuar usando-a para descriptografar os dados, mesmo sem direitos de root. Além disso, o disco pode ser roubado e a partição swap / arquivos core podem ser lidos por meio de ferramentas de terceiros. O objetivo do TDE é torná-lo ilegível, mesmo que o disco seja roubado. existe a possibilidade de recriptografar o espaço de tabelas com novas chaves geradas. Este recurso é chamado de threads de criptografia (encryption threads) e, até o momento da redação deste artigo, ainda é experimental.
Leia mais:
Fonte: habr.com
