sql >> Base de Datos >  >> RDS >> MariaDB

Explorando las diferentes formas de cifrar sus datos de MariaDB

Cifrar su base de datos MariaDB, ya sea en tránsito o en reposo, es una de las cosas más importantes que una organización debe considerar si valora sus datos.

Las organizaciones que se ocupan de transacciones financieras, registros médicos, información confidencial o incluso datos personales deben exigir este tipo de protección de datos. Fundamentalmente, el cifrado de la base de datos transformará sus datos legibles en un formato ilegible (o al menos difícil de descifrar) por cualquier usuario no autorizado.

El cifrado de sus datos evita el uso indebido o la intención maliciosa por parte de piratas informáticos o personal no autorizado que podría dañar su negocio. Los datos no cifrados son propensos a ser atacados por piratas informáticos que inyectan datos maliciosos que podrían dañar su infraestructura o robar información. Quartz publicó recientemente un artículo sobre la mayor brecha que ocurrió en este sentido y es alarmante que se hayan robado datos de miles de millones de cuentas en las últimas dos décadas.

Recursos relacionados Cómo cifrar sus copias de seguridad de MySQL y MariaDB Seguridad de la base de datos - Cifrado de copia de seguridad en tránsito y en reposo Actualizado:Conviértase en un DBA de ClusterControl - Administración de claves SSL y cifrado de datos MySQL en tránsito

En este blog, analizaremos varias formas de cifrar sus datos de MariaDB, ya sea que estén en reposo o en tránsito. Le proporcionaremos una comprensión básica del cifrado y cómo usarlo para que pueda utilizar estos enfoques para mantener sus datos seguros.

Cifrado de datos de MariaDB:en tránsito

MariaDB, de forma predeterminada, no utiliza el cifrado durante la transmisión de datos a través de la red desde el servidor al cliente. Sin embargo, el uso de la configuración predeterminada podría provocar que un hacker potencial escuche a escondidas un canal no seguro/no encriptado. Si está operando en un entorno aislado o muy seguro, este estado predeterminado puede ser aceptable. Sin embargo, esto no es ideal cuando su cliente y su red están en una red diferente, ya que configura su base de datos para un posible ataque de "intermediario".

Para evitar estos ataques, MariaDB le permite cifrar los datos en tránsito entre el servidor y los clientes utilizando el protocolo Transport Layer Security (TLS) (anteriormente conocido como Secure Socket Layer o SSL). Para comenzar, debe asegurarse de que su servidor MariaDB se compiló con soporte TLS. Puede verificar esto ejecutando la instrucción SHOW GLOBAL VARIABLES como se muestra a continuación:

MariaDB [(none)]> SHOW GLOBAL VARIABLES LIKE 'version_ssl_library';
+---------------------+---------------------------------+
| Variable_name       | Value                           |
+---------------------+---------------------------------+
| version_ssl_library | OpenSSL 1.0.1e-fips 11 Feb 2013 |
+---------------------+---------------------------------+
1 row in set (0.001 sec)

Es posible que esté confundido en cuanto a las diferencias entre SSL y TSL. La documentación puede usar el término SSL y las variables para la configuración también usan ssl_* como prefijo, sin embargo, MariaDB solo admite sus sucesores seguros y ya no las versiones anteriores de SSL. Es posible que deba identificar y usar las versiones correctas de MariaDB que requieren el soporte adecuado de las versiones de TLS que necesita usar. Por ejemplo, PCI DSS v3.2 recomienda usar una versión de protocolo mínima de TLSv1.2 compatible con versiones anteriores de MariaDB. Sin embargo, con TLS 1.3, requiere OpenSSL 1.1.1, es más rápido debido a un protocolo de enlace más eficiente entre los dos sistemas que se comunican y esto es compatible desde MariaDB 10.2.16 y MariaDB 10.3.8.

Para utilizar los cifrados disponibles para una versión TLS específica, puede definirla usando --ssl-cipher en el mysqld comando o ssl-cipher variable en el archivo de configuración. Tenga en cuenta que los cifrados TLSv1.3 no se pueden excluir cuando se usa OpenSSL, incluso usando la variable de sistema ssl_cipher.

Parámetros de configuración para cifrar datos en tránsito

Para cifrar sus datos en tránsito, puede realizar la secuencia de comandos que se detalla a continuación:

Generar un certificado de CA

openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 365000 -subj "/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server"  -key ca-key.pem -out ca-cert.pem

Generar un certificado de servidor

openssl req -newkey rsa:2048 -days 365000 -nodes -keyout server-key.pem -out server-req.pem -subj "/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=DB Server" 
openssl  rsa -in server-key.pem -out server-key.pem
openssl x509 -req -in server-req.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem

Generar un certificado de cliente

openssl req -newkey rsa:2048 -days 365000 -nodes -keyout client-key.pem -out client-req.pem  -subj "/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=Client Server"
openssl rsa -in client-key.pem -out client-key.pem
openssl  x509 -req -in client-req.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem

Tenga en cuenta que su nombre común (CN) en el -subj El argumento debe ser único en comparación con los certificados de CA, servidor y cliente que está generando. Técnicamente, la CA y el servidor pueden tener el mismo CN, pero es mejor convertirlo en un identificador único para estos tres. De lo contrario, recibirá un error como este:

ERROR 2026 (HY000): SSL connection error: tlsv1 alert unknown ca

Muy bien, los certificados y las claves están en su lugar. Debe especificar la ruta utilizando las variables ssl_* en su archivo de configuración de MySQL (p. ej., /etc/my.cnf para sistemas operativos basados ​​en RHEL o /etc/mysql/my.cnf para sistemas operativos Debian/Ubuntu). Vea la configuración de ejemplo a continuación:

[msqld]
...
ssl_ca=/etc/ssl/galera/self-gen/ca-cert.pem
ssl_cert=/etc/ssl/galera/self-gen/server-cert.pem
ssl_key=/etc/ssl/galera/self-gen/server-key.pem

Por supuesto, debe especificar la ruta correcta donde ha colocado su certificado y claves.

Luego coloque estos parámetros debajo de [client-mariadb] sección de su archivo de configuración como se muestra a continuación:

[client-mariadb]
ssl_ca = /etc/ssl/galera/self-gen/ca-cert.pem
ssl_cert=/etc/ssl/galera/self-gen/client-cert.pem
ssl_key=/etc/ssl/galera/self-gen/client-key.pem

Como se mencionó anteriormente, puede especificar qué tipo de cifrado puede usar su configuración SSL/TLS. Esto se puede hacer especificando la configuración de configuración a continuación:

[mysqld]
…
ssl_ca=/etc/ssl/galera/self-gen/ca-cert.pem
ssl_cert=/etc/ssl/galera/self-gen/server-cert.pem
ssl_key=/etc/ssl/galera/self-gen/server-key.pem
ssl-cipher=AES256-GCM-SHA384

O puede usar la siguiente configuración como se muestra a continuación:

ssl-cipher=TLSv1.2      ### This will use all Ciphers available in TLS v1.2
ssl-cipher=HIGH:!DSS:!RCA-SHA:!DES-CBC3-SHA:[email protected]       ### Will list strong ciphers available and exclude ciphers in prefix.

La última línea indica el equivalente de este comando:

openssl ciphers -v 'HIGH:!DSS:!RCA-SHA:!DES-CBC3-SHA:[email protected]'

Esto excluirá los cifrados débiles y aquellos cifrados que están en forma de prefijo como DHE-DSS-AES256-GCM-SHA384 cifrado por ejemplo.

Generando su Certificado usando ClusterControl

Como alternativa, puede usar ClusterControl para generar los certificados y las claves por usted. Para hacer esto, puede hacer lo siguiente como se ve a continuación:

  1. Seleccione su clúster MariaDB, luego vaya a Seguridad y seleccione Cifrado SSL. En mi ejemplo a continuación, este es un clúster MariaDB Galera:
  2. Seleccione el cifrado SSL y actívelo. Podrá crear un nuevo certificado o elegir uno existente. Para esta muestra, elegiré la opción "Crear certificado":
  3. El último paso es configurar los días de vencimiento de su certificado. Vea abajo: Si hace clic en "Reiniciar nodos", ClusterControl realizará un reinicio continuo. Tome nota, si está utilizando MariaDB 10.4 (que actualmente se encuentra en su versión RC), puede usar SSL sin reiniciar su servidor MariaDB. Simplemente use el comando FLUSH SSL, que es una nueva función agregada en la versión MariaDB 10.4.

Otra forma de manejar sus certificados/claves TLS/SSL, también puede utilizar la Gestión de claves bajo ClusterControl. Consulte este blog para obtener más información sobre cómo hacerlo.

Cree su usuario TLS/SSL MariaDB

En caso de que pensaras que habías terminado, no es así. Debe asegurarse de que sus usuarios deban usar SSL cuando se conecten al servidor. Este usuario deberá interactuar siempre con el servidor a través de un canal privado. Esto es muy importante porque debe asegurarse de que todos sus clientes interactúen con su servidor de una manera muy segura y privada.

Para hacer esto, solo haz el siguiente ejemplo:

MariaDB [(none)]> CREATE USER [email protected]'192.168.10.200' IDENTIFIED BY '[email protected]';
Query OK, 0 rows affected (0.005 sec)
MariaDB [(none)]> GRANT ALL ON *.* TO [email protected]'192.168.10.200' REQUIRE SSL;
Query OK, 0 rows affected (0.005 sec)

Asegúrese de que, al conectarse a su cliente/host de aplicación, copie el certificado que ha generado según los pasos anteriores.

Verificando su conexión

Probar su conexión si está encriptada o no es muy importante para determinar el estado. Para hacer eso, puede hacer el siguiente comando a continuación:

mysql -e "status"|grep -i 'cipher'
SSL:                    Cipher in use is DHE-RSA-AES256-GCM-SHA384

Como alternativa, OpenSSL versión 1.1.1 agregó soporte para -starttls mysql . Hay un binario de openssl compilado estáticamente disponible que puede obtener aquí https://testssl.sh/openssl-1.0.2k-dev-chacha.pm.ipv6.Linux+FreeBSD.tar.gz (o consulte esta presentación en formato PDF) . Entonces puedes hacer el siguiente comando a continuación:

echo | bin/openssl.Linux.x86_64.static s_client -starttls mysql -connect localhost:3306 -CAfile /etc/ssl/galera/self-gen/ca-cert.pem

El resultado del ejemplo sería el siguiente:

$ echo | bin/openssl.Linux.x86_64.static s_client -starttls mysql -connect localhost:3306 -CAfile /etc/ssl/galera/self-gen/ca-cert.pem 
CONNECTED(00000003)
depth=1 C = PH, ST = Davao Del Sur, L = Davao City, O = Maximus Aleksandre, CN = CA Server
verify return:1
depth=0 C = PH, ST = Davao Del Sur, L = Davao City, O = Maximus Aleksandre, CN = DB Server
verify return:1
---
Certificate chain
 0 s:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=DB Server
   i:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
 1 s:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
   i:/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDTDCCAjQCAQEwDQYJKoZIhvcNAQELBQAwazELMAkGA1UEBhMCUEgxFjAUBgNV
BAgMDURhdmFvIERlbCBTdXIxEzARBgNVBAcMCkRhdmFvIENpdHkxGzAZBgNVBAoM
Ek1heGltdXMgQWxla3NhbmRyZTESMBAGA1UEAwwJQ0EgU2VydmVyMCAXDTE5MDYx
MDAyMTMwNFoYDzMwMTgxMDExMDIxMzA0WjBrMQswCQYDVQQGEwJQSDEWMBQGA1UE
CAwNRGF2YW8gRGVsIFN1cjETMBEGA1UEBwwKRGF2YW8gQ2l0eTEbMBkGA1UECgwS
TWF4aW11cyBBbGVrc2FuZHJlMRIwEAYDVQQDDAlEQiBTZXJ2ZXIwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDNwFuoqJg8YlrDinxDZN4+JjFUTGlDfhmy
9H/1C4fZToegvd3RzU9mz3/Fgyuoez4szHDgkn7o4rqmKAH6tMm9R44qtBNGlxka
fn12PPXudDvij4A9C3nVatBJJXTSvSD4/eySY33kAS1DpKsgsTgKAKOsyadcvXYU
IP5nfFc7pxX/8qZADVmyeik4M+oLxO6ryurt0wmUhOmlz5zQghh9kFZLA49l+p95
m5D53d/O+Qj4HSb2ssZD2ZaRc2k4dMCVpa87xUbdP/VVLeu0J4BE3OJiwC0N1Jfi
ZpP2DOKljsklaAYQF+tPnWi5pgReEd47/ql0fNEjeheF/MJiJM1NAgMBAAEwDQYJ
KoZIhvcNAQELBQADggEBAAz7yB+UdNYJ1O5zJI4Eb9lL+vNVKhRJ8IfNrwKVbpAT
eQk9Xpn9bidfcd2gseqDTyixZhWjsjO2LXix7jRhH1DrJvhGQ7+1w36ujtzscTgy
ydLH90CnE/oZHArbBhmyuqmu041w5rB3PpI9i9SveezDrbVcaL+qeGo8s4ATB2Yr
Y3T3OTqw6o/7cTJJ8S1aXBLTyUq5HAtOTM2GGZMSYwVqUsmBHA3d7M8i7yp20RVH
78j1H6+/hSSY4SDhwr04pSkzmm6HTIBCgOYrmEV2sQ/YeMHqVrSplLRY3SZHvqHo
gbSnasOQAE1oJnSNyxt9CRRAghM/EHEnsA2OlFa9iXQ=
-----END CERTIFICATE-----
subject=/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=DB Server
issuer=/C=PH/ST=Davao Del Sur/L=Davao City/O=Maximus Aleksandre/CN=CA Server
---
No client certificate CA names sent
Client Certificate Types: RSA fixed DH, DSS fixed DH, RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: DH, 2048 bits
---
SSL handshake has read 3036 bytes and written 756 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : DHE-RSA-AES256-GCM-SHA384
    Session-ID: 46E0F6FA42779DB210B4DF921A68E9E4CC39ADD87D28118DB0073726B98C0786
    Session-ID-ctx: 
    Master-Key: 2A2E6137929E733051BE060953049A0553F49C2F50A183EEC0C40F7EFB4E2749E611DF54A88417518A274EC904FB3CE6
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 4a dd f3 7f 1e b7 9e cb-77 58 b9 75 53 34 5c 61   J.......wX.uS4\a
    0010 - 3a 4d 0e aa e2 6b 27 8e-11 ff be 24 ad 66 88 49   :M...k'....$.f.I
    0020 - c1 ba 20 20 d8 9f d5 5c-23 9d 64 dc 97 f2 fa 77   ..  ...\#.d....w
    0030 - bf e6 26 1f 2c 98 ee 3b-71 66 0c 04 05 3e 54 c1   ..&.,..;qf...>T.
    0040 - 88 b6 f7 a9 fd b8 f9 84-cd b8 99 9f 6e 50 3b 13   ............nP;.
    0050 - 90 30 91 7d 48 ea 11 f7-3f b7 6b 65 2e ea 7e 61   .0.}H...?.ke..~a
    0060 - 70 cd 4e b8 43 54 3d a0-aa dc e5 44 a7 41 3a 5e   p.N.CT=....D.A:^
    0070 - 3e cb 45 57 33 2b a4 8f-75 d8 ce a5 9e 00 16 50   >.EW3+..u......P
    0080 - 24 aa 7a 54 f8 26 65 74-11 d7 f3 d6 66 3b 14 60   $.zT.&et....f;.`
    0090 - 33 98 4a ef e2 17 ba 33-4e 7f 2b ce 46 d7 e9 11   3.J....3N.+.F...

    Start Time: 1560133350
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
DONE
ClusterControlConsola única para toda su infraestructura de base de datosDescubra qué más hay de nuevo en ClusterControlInstale ClusterControl GRATIS

Cifrado de datos de MariaDB:en reposo

Los datos cifrados que se almacenan físicamente dentro de su almacenamiento de hardware (es decir, en reposo) brindan más estabilidad y protección contra una violación de datos. Si un atacante malicioso puede iniciar sesión en su base de datos MariaDB, entonces puede leer los datos en texto sin formato. De manera similar al uso de un comando de cadenas en Linux, podrá recuperar fácilmente los datos de la base de datos. Además, agrega más peligro si el atacante tiene una comprensión avanzada del formato de archivo del tablespace.

El cifrado en reposo es una protección adicional, pero no sustituye a un buen cortafuegos, contraseñas seguras, permisos de usuario correctos y cifrado en tránsito entre el cliente y el servidor.

El soporte de MariaDB para el cifrado en tablas y espacios de tabla se agregó en la versión 10.1.3. Con sus tablas encriptadas, es casi imposible que alguien robe sus datos. Este tipo de encriptación también permite que su organización cumpla con las regulaciones gubernamentales como GPDR.,

Una vez que haya habilitado el cifrado de datos en reposo en MariaDB, las tablas que están definidas con ENCRYPTED=YES o con innodb_encrypt_tables=ON tendrán sus datos almacenados cifrados. Se descifra solo cuando se accede a través de la base de datos de MariaDB; de lo contrario, los datos son ilegibles.

Por ejemplo, al leer datos que no están encriptados, se mostrarán como tales:

$ strings admin_logs.ibd|head -10
=r7N
infimum
supremum
infimum
supremum/
failThe verification code you entered is incorrect.KK
elmo1234failThe password or username you entered is invalidKK
elmo1234failThe password or username you entered is invalidKK
elmoasfdfailThe verification code you entered is incorrect.KK
safasffailThe verification code you entered is incorrect.KK

pero con datos encriptados, su tablespace no será legible como en el siguiente ejemplo:

# strings user_logs.ibd |head -10
E?*Pa
[+YQ
KNmbUtQ
T_lPAW
\GbQ.
] e2
#Rsd
ywY%o
kdUY
{]~GE

También cabe destacar que el cifrado de datos en reposo de MariaDB agrega una sobrecarga de tamaño de datos de aproximadamente 3-5%. El cifrado de MariaDB también es totalmente compatible cuando se utilizan los motores de almacenamiento XtraDB e InnoDB. El cifrado también es compatible con el motor de almacenamiento Aria, pero solo para las tablas creadas con ROW_FORMAT=PAGE (valor predeterminado) y para el registro binario (registro de replicación). MariaDB incluso permite que el usuario tenga flexibilidad para cifrar. En XtraDB o InnoDB, uno puede elegir cifrar:

  • todo — todos los tablespaces (con todas las tablas)
  • mesas individuales
  • todo, excepto mesas individuales

Además, se puede optar por cifrar los archivos de registro de XtraDB/InnoDB (lo cual se recomienda).

MariaDB tiene sus limitaciones. Galera Cluster gcache, por ejemplo, no está encriptado pero está planeado como parte de la versión MariaDB 10.4. Puede encontrar una lista completa de limitaciones aquí.

Cómo instalar y configurar MariaDB para el cifrado de datos en reposo

  1. Genera claves de encriptación aleatorias usando el comando openssl rand. 
    $ mkdir -p /etc/mysql/encryption
$ for i in {1..5}; do openssl rand -hex 32 >> /etc/mysql/encryption/keyfile;  done;
    Ahora, abra y edite el archivo /etc/mysql/encryption/keyfile y agregue los ID de clave a los que se hará referencia al crear tablas cifradas como su ID de clave de cifrado. Consulte ENCRYPTION_KEY_ID para obtener más detalles. Por lo tanto, el siguiente formato debe ser el siguiente:
    <encryption_key_id1>;<hex-encoded_encryption_key1>
<encryption_key_id2>;<hex-encoded_encryption_key2>
    In my example keyfile, this looks as the following:
    $ cat keyfile
1;687a90b4423c10417f2483726a5901007571c16331d2ee9534333fef4e323075
2;e7bf20f1cbde9632587c2996871cff74871890d19b49e273d13def123d781e17
3;9284c9c80da9a323b3ac2c82427942dfbf1718b57255cc0bc0e2c3d6f15ac3ac
4;abf80c3a8b10643ef53a43c759227304bcffa263700a94a996810b0f0459a580
5;bdbc5f67d34a4904c4adc9771420ac2ab2bd9c6af1ec532e960335e831f02933
  2. Vamos a crear o generar una contraseña aleatoria usando el comando similar del paso 1:
    $ openssl rand -hex 128 > /etc/mysql/encryption/keyfile.key
  3. Antes de continuar con el siguiente paso, es importante tomar nota de los siguientes detalles sobre el cifrado del archivo clave:
    • El único algoritmo que MariaDB admite actualmente para cifrar el archivo clave es el modo Cipher Block Chaining (CBC) del estándar de cifrado avanzado (AES).
    • El tamaño de la clave de cifrado puede ser de 128 bits, 192 bits o 256 bits.
    • La clave de cifrado se crea a partir del hash SHA-1 de la contraseña de cifrado.
    • La contraseña de cifrado tiene una longitud máxima de 256 caracteres.
    Ahora, para encriptar el archivo clave usando el comando openssl enc, ejecute el siguiente comando a continuación:
    $ openssl enc -aes-256-cbc -md sha1 -pass file:/etc/mysql/encryption/keyfile.key -in /etc/mysql/encryption/keyfile    -out /etc/mysql/encryption/keyfile.enc
  4. Agregue las siguientes variables en su archivo de configuración de MySQL (es decir, /etc/my.cnf en el sistema operativo Linux basado en RHEL o /etc/mysql/my.cnf en el sistema operativo basado en Debian/Ubuntu Linux) 
    [mysqld]
…
#################### DATABASE ENCRYPTION ##############################
plugin_load_add = file_key_management
file_key_management_filename = /etc/mysql/encryption/keyfile.enc
file_key_management_filekey = FILE:/etc/mysql/encryption/keyfile.key
file_key_management_encryption_algorithm = aes_cbc 
encrypt_binlog = 1

innodb_encrypt_tables = ON
innodb_encrypt_log = ON
innodb_encryption_threads = 4
innodb_encryption_rotate_key_age = 0 # Do not rotate key
  5. Reinicie el servidor MariaDB ahora 
    $ systemctl start mariadb

Verificar y probar el cifrado

Para verificar y probar el cifrado, simplemente cree una tabla de muestra. Por ejemplo, cree la tabla haciendo las siguientes instrucciones SQL a continuación:

MariaDB [test]> CREATE TABLE a (i int) ENGINE=InnoDB ENCRYPTED=YES;
Query OK, 0 rows affected (0.018 sec)
MariaDB [test]> CREATE TABLE b (i int) ENGINE=InnoDB;
Query OK, 0 rows affected (0.003 sec)

Luego, agreguemos algunos datos a las tablas:

MariaDB [test]> insert into a values(1),(2);
Query OK, 2 rows affected (0.001 sec)
Records: 2  Duplicates: 0  Warnings: 0
MariaDB [test]> insert into b values(1),(2);
Query OK, 2 rows affected (0.001 sec)
Records: 2  Duplicates: 0  Warnings: 0

Para verificar y ver cuáles son las tablas que están encriptadas, simplemente ejecute el siguiente SELECCIONAR consulta a continuación:

MariaDB [test]> SELECT * FROM information_schema.innodb_tablespaces_encryption\G
*************************** 1. row ***************************
                       SPACE: 4
                        NAME: mysql/gtid_slave_pos
           ENCRYPTION_SCHEME: 1
          KEYSERVER_REQUESTS: 1
             MIN_KEY_VERSION: 1
         CURRENT_KEY_VERSION: 1
    KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
              CURRENT_KEY_ID: 1
        ROTATING_OR_FLUSHING: 0
*************************** 2. row ***************************
                       SPACE: 2
                        NAME: mysql/innodb_index_stats
           ENCRYPTION_SCHEME: 1
          KEYSERVER_REQUESTS: 1
             MIN_KEY_VERSION: 1
         CURRENT_KEY_VERSION: 1
    KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
              CURRENT_KEY_ID: 1
        ROTATING_OR_FLUSHING: 0
*************************** 3. row ***************************
                       SPACE: 1
                        NAME: mysql/innodb_table_stats
           ENCRYPTION_SCHEME: 1
          KEYSERVER_REQUESTS: 1
             MIN_KEY_VERSION: 1
         CURRENT_KEY_VERSION: 1
    KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
              CURRENT_KEY_ID: 1
        ROTATING_OR_FLUSHING: 0
*************************** 4. row ***************************
                       SPACE: 3
                        NAME: mysql/transaction_registry
           ENCRYPTION_SCHEME: 1
          KEYSERVER_REQUESTS: 0
             MIN_KEY_VERSION: 1
         CURRENT_KEY_VERSION: 1
    KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
              CURRENT_KEY_ID: 1
        ROTATING_OR_FLUSHING: 0
*************************** 5. row ***************************
                       SPACE: 5
                        NAME: test/a
           ENCRYPTION_SCHEME: 1
          KEYSERVER_REQUESTS: 1
             MIN_KEY_VERSION: 1
         CURRENT_KEY_VERSION: 1
    KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
              CURRENT_KEY_ID: 1
        ROTATING_OR_FLUSHING: 0
*************************** 6. row ***************************
                       SPACE: 6
                        NAME: test/b
           ENCRYPTION_SCHEME: 1
          KEYSERVER_REQUESTS: 1
             MIN_KEY_VERSION: 1
         CURRENT_KEY_VERSION: 1
    KEY_ROTATION_PAGE_NUMBER: NULL
KEY_ROTATION_MAX_PAGE_NUMBER: NULL
              CURRENT_KEY_ID: 1
        ROTATING_OR_FLUSHING: 0
6 rows in set (0.000 sec)

La creación de la tabla InnoDB no necesita especificar la palabra clave ENCRYPTED=YES. Se crea automáticamente como especificamos en el archivo de configuración para tener innodb_encrypt_tables =ON.

Si desea especificar el ID de cifrado de la tabla que se utilizará, también puede hacer lo siguiente:

MariaDB [test]> CREATE TABLE c (i int) ENGINE=InnoDB ENCRYPTION_KEY_ID = 4;
Query OK, 0 rows affected (0.003 sec)

ENCRYPTION_KEY_ID se tomó del archivo de claves de cifrado que generamos anteriormente.

Además, si desea realizar más pruebas a través de shell, puede utilizar las cadenas comando que te mostré antes.

Información adicional sobre el cifrado MariaDB

Si su instancia de MariaDB no debe contener tablas sin cifrar, simplemente configure la variable en su archivo de configuración my.cnf dentro de [mysqld] sección de la siguiente manera:

innodb_encrypt_tables = FORCE.

Para el cifrado binlog, simplemente agregue lo siguiente

encrypt_binlog = 1

El registro de rehacer de InnoDB no está cifrado de forma predeterminada. Para encriptarlo simplemente agregue la siguiente variable después de la sección [mysqld],

innodb-encrypt-log

Si necesita encriptación para sus archivos temporales y tablas temporales en disco, puede agregar lo siguiente:

encrypt-tmp-disk-tables=1
encrypt-tmp-files=1