En previsión do inicio dunha nova matrícula para o curso Seguimos publicando unha serie de artigos sobre o cifrado en MySQL.
No artigo anterior desta serie () falamos de bóvedas de chaves. Neste artigo, analizaremos como se usa a chave mestra e analizaremos as vantaxes e desvantaxes do cifrado de sobre.
A idea detrás do cifrado de sobre é que as claves utilizadas para o cifrado (as chaves de espazo de táboa) están cifradas con outra chave (a chave mestra). As claves de espazo de táboa úsanse realmente para cifrar datos. Gráficamente pódese representar así:
A chave mestra atópase no anel de chaves e as chaves do espazo de táboas están nas cabeceiras cifradas do espazo de táboas (na páxina 0 do espazo de táboas).
Na imaxe superior:
-
A táboa A está cifrada coa clave 1 (clave 1). A clave 1 cífrase mediante a chave mestra e gárdase cifrada na cabeceira da táboa A.
-
A táboa B está cifrada coa chave 2. A clave 2 cífrase mediante a chave mestra (chave de enmascaramento) e gárdase cifrada na cabeceira da táboa B.
-
E así por diante.
Cando o servidor necesita descifrar a táboa A, recupera a clave mestra do almacenamento, le a clave cifrada 1 da cabeceira da táboa A e descifra a clave 1. A clave descifrada 1 almacénase na memoria do servidor e úsase para descifrar a táboa A. .
InnoDB
En InnoDB, o cifrado e descifrado real realízase na capa de E/S. É dicir, a páxina cífrase xusto antes de ser descargada no disco e descifrada inmediatamente despois de lida desde o disco.
En InnoDB, o cifrado só funciona a nivel de espazo de táboa. E por defecto, todas as táboas créanse en espazos de táboa separados (). Noutras palabras, créase un espazo de táboa que só pode conter unha táboa. Aínda que tamén pode crear táboas no espazo de táboa principal (). Pero en calquera caso, a táboa sempre está situada nalgún espazo de táboa. E dado que o cifrado realízase a nivel de espazo de táboa, ou está completamente cifrado ou non. É dicir, é imposible cifrar só parte das táboas no espazo principal da táboa.
Se por algún motivo ten desactivado o ficheiro por táboa, todas as táboas créanse dentro do espazo de táboa do sistema. EN pode cifrar o espazo de táboa do sistema usando a variable innodbsistemaespazo de táboacifrar ou usar fíos de cifrado, pero esta aínda é unha función experimental. MySQL non ten isto.
Antes de seguir adiante, necesitamos ver a estrutura do ID da chave mestra. Consta de UUID, KEYID e prefixo "INNODBKey". Parece así: INNODBKey-UUID-KEYID.
UUID é o uuid do servidor co espazo de táboa cifrado. CLAVEA identificación é simplemente un valor cada vez maior. Ao crear a chave mestra KEY por primeira vezO ID é 1. Durante a rotación da chave, cando se crea unha nova chave mestra, KEYID = 2 e así por diante. Falaremos máis sobre a rotación da chave mestra nos próximos artigos desta serie.
Agora que sabemos o que parece un identificador de chave mestra, vexamos a cabeceira do espazo de táboa cifrado. Cando se cifra un espazo de táboa, a información de cifrado engádese á cabeceira. Parece así:
KEY ID é KEYID do ID da chave mestra que xa comentamos. UUID é o uuid do servidor, que tamén se usa no identificador da chave mestra. TABLESPACE KEY: unha clave de espazo de táboa, que consta de 256 bits xerados aleatoriamente polo servidor. O vector de inicialización (IV) tamén consta de 256 bits xerados aleatoriamente (aínda que debería ser de 128 bits). IV utilízase para inicializar o cifrado e descifrado AES (de 256 bits, só se utilizan 128). Ao final hai unha suma de verificación CRC32 para TABLESPACE KEY e IV.
Durante todo este tempo fun simplificando un pouco dicindo que a cabeceira contén a clave cifrada do espazo de táboa. De feito, a clave de espazo de táboa e o vector de inicialización almacénanse e cífranse xuntos mediante a chave mestra. Lembre que antes de cifrar a clave de espazo de táboa e o vector de inicialización, calcúlase un CRC32 para eles.
Por que é necesario CRC32?
En poucas palabras, para garantir a validez da chave mestra. Despois de descifrar a clave do espazo de táboa e o vector de inicialización, a suma de verificación calcúlase e compárase co CRC32 almacenado na cabeceira. Se as sumas de verificación coinciden, entón temos a chave mestra e a clave de espazo de táboa correctas. En caso contrario, o espazo de táboa está marcado como ausente (non poderemos descifralo de todos os xeitos).
Podes preguntar: en que momento se realiza a verificación da chave? A resposta é cando se inicia o servidor. Un servidor con táboas/espazos de táboa cifrados le UUID, KEY ao inicioID da cabeceira e xera o ID da chave mestra. A continuación, obtén a chave mestra necesaria do anel de chaves, descifra a chave do espazo de táboa e verifica a suma de verificación. Unha vez máis, se a suma de verificación coincide, todo está ben, se non, o espazo de táboa está marcado como falta.
Se les o artigo anterior desta serie (), entón pode lembrar que cando se utiliza un almacén de claves baseado no servidor, o servidor ao iniciar só recibe unha lista de identificadores de chave, ou mellor dito, ID de chave e ID de usuario, xa que este par identifica a chave de forma única. Agora digo que cando o servidor se inicia, recibe todas as claves que precisa para comprobar que pode descifrar as chaves do espazo de táboa. Entón, por que durante a inicialización, no caso do almacenamento do servidor, só se carga a chaveid e usuarioid, e non todas as claves? Porque quizais non necesites todas as chaves. Isto débese principalmente á rotación da chave mestra. Cando se xira unha chave mestra, créase unha nova chave mestra na bóveda, pero as chaves antigas non se eliminan. Así, pode ter moitas claves no almacén de claves do servidor que o servidor non precisa e, polo tanto, non se recuperan cando se inicia o servidor.
É hora de falar un pouco sobre os pros e contras do cifrado da chave mestra. A maior vantaxe é que só necesitas unha clave de cifrado (a chave mestra), que se almacenará por separado dos teus datos cifrados. Isto fai que o inicio do servidor sexa rápido e o almacenamento sexa pequeno, polo que é fácil de xestionar. E tamén a chave mestra única é fácil de rexenerar.
Non obstante, o cifrado da chave mestra ten un gran inconveniente: unha vez que se cifra un espazo de táboa con tablespace_key, sempre permanece cifrado coa mesma clave. Xirar a chave mestra non axuda aquí. Por que isto é unha desvantaxe? Sabemos que MySQL ten erros que poden provocar un fallo repentino e a creación dun ficheiro principal. Dado que o ficheiro principal contén un volcado de memoria do servidor, pode ocorrer que o volcado conteña a clave de espazo de táboa descifrada. Para empeorar as cousas, as claves de espazo de táboa descifradas gárdanse na memoria, que se pode trocar ao disco. Podes dicir que isto non é unha desvantaxe xa que necesitas dereitos de root para acceder a estes ficheiros e á partición de intercambio. Si. Pero o root só é necesario por un tempo. Unha vez que alguén ten acceso á clave de espazo de táboa descifrado, pode seguir usándoa para descifrar datos, aínda que non teña privilexios de root. Ademais, o disco pódese roubar e os ficheiros de partición de intercambio/núcleo pódense ler mediante ferramentas de terceiros. O obxectivo de TDE é facelo ilegible aínda que o disco sexa roubado. EN É posible volver cifrar o espazo da táboa con novas claves xeradas. Esta función chámase fíos de cifrado e aínda é experimental no momento de escribir.
Le máis:
Fonte: www.habr.com