MariaDB
 sql >> Base de Dados >  >> RDS >> MariaDB

Explorando as diferentes maneiras de criptografar seus dados MariaDB


Criptografar seu banco de dados MariaDB, seja em trânsito ou em repouso, é uma das coisas mais importantes que uma organização deve considerar se você valoriza seus dados.

As organizações que lidam com transações financeiras, registros médicos, informações confidenciais ou até mesmo dados pessoais devem exigir esse tipo de proteção de dados. Fundamentalmente, a criptografia do banco de dados transformará seus dados legíveis em um formato ilegível (ou pelo menos difícil de ser descriptografado) por qualquer usuário não autorizado.

Criptografar seus dados evita o uso indevido ou intenção maliciosa por hackers ou pessoal não autorizado que pode prejudicar seus negócios. Dados não criptografados são propensos a ataques de hackers que injetam dados maliciosos que podem danificar sua infraestrutura ou roubar informações. A Quartz divulgou recentemente um artigo sobre a maior violação que aconteceu nesse sentido e é alarmante que dados tenham sido roubados de bilhões de contas nas últimas duas décadas.
Recursos relacionados Como criptografar seus backups MySQL e MariaDB Segurança do banco de dados - Criptografia de backup em trânsito e em repouso Atualizado:Torne-se um DBA ClusterControl - Gerenciamento de chave SSL e criptografia de dados MySQL em trânsito
Neste blog, discutiremos várias maneiras de criptografar seus dados MariaDB, estejam eles em repouso e em trânsito. Forneceremos a você uma compreensão básica da criptografia e como usá-la para que você possa utilizar essas abordagens para manter seus dados seguros.

Criptografia de dados MariaDB:em trânsito


O MariaDB, por padrão, não usa criptografia durante a transmissão de dados pela rede do servidor para o cliente. No entanto, usar a configuração padrão pode provocar um hacker em potencial a espionar um canal não seguro/não criptografado. Se você estiver operando em um ambiente isolado ou altamente seguro, esse estado padrão pode ser aceitável. Isso, no entanto, não é ideal quando seu cliente e rede estão em redes diferentes, pois configura seu banco de dados para um possível ataque “man-in-the-middle”.

Para evitar esses ataques, o MariaDB permite criptografar dados em trânsito entre o servidor e os clientes usando o protocolo Transport Layer Security (TLS) (anteriormente conhecido como Secure Socket Layer ou SSL). Para começar, você precisa garantir que seu servidor MariaDB foi compilado com suporte a TLS. Você pode verificar isso executando a instrução SHOW GLOBAL VARIABLES, conforme mostrado abaixo:
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)

Você pode estar confuso em como o SSL e o TSL diferem. A documentação pode usar o termo SSL e as variáveis ​​para configuração também usam ssl_* como prefixo, no entanto, o MariaDB suporta apenas seus sucessores seguros e não mais as versões SSL mais antigas. Você pode ter que identificar e usar as versões corretas do MariaDB que requerem o suporte correto das versões TLS que você precisa usar. Por exemplo, o PCI DSS v3.2 recomenda o uso de uma versão mínima do protocolo TLSv1.2 que as versões antigas do MariaDB suportam. No entanto, com TLS 1.3, requer OpenSSL 1.1.1, é mais rápido devido a um handshake mais eficiente entre os dois sistemas se comunicando e isso é suportado desde o MariaDB 10.2.16 e MariaDB 10.3.8.

Para utilizar as cifras disponíveis para uma versão TLS específica, você pode defini-la usando o --ssl-cipher no mysqld comando ou ssl-cipher variável no arquivo de configuração. Observe que as cifras TLSv1.3 não podem ser excluídas ao usar o OpenSSL, mesmo usando a variável de sistema ssl_cipher.

Parâmetros de configuração para criptografar dados em trânsito


Para criptografar seus dados em trânsito, você pode executar a sequência de comandos listada abaixo:

Gerar um 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

Gerar um 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

Gerar um 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

Observe que seu nome comum (CN) no -subj argumento deve ser exclusivo em relação aos certificados de CA, servidor e cliente que você está gerando. Tecnicamente, CA e Servidor podem ter o mesmo CN, mas é melhor torná-lo um identificador exclusivo para esses três. Caso contrário, você receberá um erro como tal:
ERROR 2026 (HY000): SSL connection error: tlsv1 alert unknown ca

Certo, certificados e chaves estão em vigor. Você precisa especificar o caminho usando as variáveis ​​ssl_* em seu arquivo de configuração do MySQL (por exemplo, /etc/my.cnf para sistema operacional baseado em RHEL ou /etc/mysql/my.cnf para sistema operacional Debian/Ubuntu). Veja o exemplo de configuração abaixo:
[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

Claro, você deve especificar o caminho correto onde você colocou seu certificado e chaves.

Em seguida, coloque esses parâmetros em [client-mariadb] seção do seu arquivo de configuração como tal abaixo:
[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

Conforme mencionado anteriormente, você pode especificar o tipo de cifra que sua configuração SSL/TLS pode usar. Isso pode ser feito especificando a configuração abaixo:
[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

Ou você pode usar a seguinte configuração como abaixo:
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.

A última linha denota o equivalente a este comando:
openssl ciphers -v 'HIGH:!DSS:!RCA-SHA:!DES-CBC3-SHA:[email protected]'

Isso excluirá as cifras fracas e as cifras que estão na forma de prefixo, como DHE-DSS-AES256-GCM-SHA384 cifra por exemplo.

Gerando seu certificado usando ClusterControl


Como alternativa, você pode usar o ClusterControl para gerar os certificados e chaves para você. Para fazer isso, você pode fazer o seguinte, como visto abaixo:
  1. Selecione seu cluster MariaDB e vá para Segurança guia e selecione Criptografia SSL. No meu exemplo abaixo, este é um Cluster MariaDB Galera:
  2. Selecione a Criptografia SSL e ative-a. Você poderá criar um novo certificado ou escolher um existente. Para este exemplo, escolherei a opção "Criar certificado":
  3. A última etapa é configurar os dias de expiração do seu certificado. Ver abaixo: Se você clicar em "Reiniciar nós", o ClusterControl executará uma reinicialização contínua. Tome nota, se você estiver usando o MariaDB 10.4 (que está atualmente em sua versão RC), você pode usar SSL sem reiniciar seu servidor MariaDB. Basta usar o comando FLUSH SSL, que é um novo recurso adicionado na versão MariaDB 10.4.

Outra maneira de lidar com seus certificados/chaves TLS/SSL, você também pode usar o Gerenciamento de chaves em ClusterControl. Confira este blog para saber mais sobre como fazer isso.

Crie seu usuário TLS/SSL MariaDB


No caso de você pensar que está pronto, você não está. Você precisa garantir que seus usuários sejam obrigados a usar SSL quando se conectarem ao servidor. Este usuário deverá interagir sempre com o servidor através de um canal privado. Isso é muito importante porque você precisa ter certeza de que todos os seus clientes estarão interagindo com seu servidor de maneira muito segura e privada.

Para isso, basta fazer o seguinte exemplo:
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)

Certifique-se de que, ao conectar-se ao host do cliente/aplicativo, copie o certificado que você gerou com base nas etapas anteriores.

Verificando sua conexão


Testar sua conexão se está criptografada ou não é muito importante para determinar o status. Para isso, você pode fazer o seguinte comando abaixo:
mysql -e "status"|grep -i 'cipher'
SSL:                    Cipher in use is DHE-RSA-AES256-GCM-SHA384

Como alternativa, o OpenSSL versão 1.1.1 adicionou suporte para -starttls mysql . Existe um binário openssl compilado estaticamente disponível que você pode obter aqui https://testssl.sh/openssl-1.0.2k-dev-chacha.pm.ipv6.Linux+FreeBSD.tar.gz (ou confira esta apresentação em formato PDF) . Então você pode fazer o seguinte comando abaixo:
echo | bin/openssl.Linux.x86_64.static s_client -starttls mysql -connect localhost:3306 -CAfile /etc/ssl/galera/self-gen/ca-cert.pem

O resultado do exemplo seria como abaixo:
$ 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
ClusterControlSingle Console para toda a sua infraestrutura de banco de dados Descubra o que mais há de novo no ClusterControlInstale o ClusterControl GRATUITAMENTE

Criptografia de dados MariaDB:em repouso


Os dados criptografados que são armazenados fisicamente em seu armazenamento de hardware (ou seja, em repouso) fornecem mais estabilidade e proteção contra uma violação de dados. Se um invasor mal-intencionado puder fazer login em seu banco de dados MariaDB, ele poderá ler os dados em texto simples. Semelhante ao uso de um comando de strings no Linux, você poderá recuperar facilmente os dados do banco de dados. Além disso, adiciona mais perigo se o invasor tiver uma compreensão avançada do formato de arquivo do tablespace.

A criptografia em repouso é uma proteção adicional, mas não substitui um bom firewall, senhas fortes, permissões de usuário corretas e criptografia em trânsito entre o cliente e o servidor.

O suporte do MariaDB para criptografia em tabelas e tablespaces foi adicionado na versão 10.1.3. Com suas tabelas sendo criptografadas, seus dados são quase impossíveis para alguém roubar. Esse tipo de criptografia também permite que sua organização esteja em conformidade com os regulamentos governamentais, como GPDR.,

Depois de habilitar a criptografia de dados em repouso no MariaDB, as tabelas definidas com ENCRYPTED=YES ou com innodb_encrypt_tables=ON terão seus dados armazenados criptografados. Ele é descriptografado apenas quando acessado através do banco de dados do MariaDB, caso contrário, os dados são ilegíveis.

Por exemplo, lendo um dado não criptografado, ele mostrará a você como tal:
$ 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

mas com dados criptografados, seu tablespace não será legível como no exemplo abaixo:
# strings user_logs.ibd |head -10
E?*Pa
[+YQ
KNmbUtQ
T_lPAW
\GbQ.
] e2
#Rsd
ywY%o
kdUY
{]~GE

Também é digno de nota que a criptografia de dados em repouso do MariaDB adiciona uma sobrecarga de tamanho de dados de aproximadamente 3-5%. A criptografia MariaDB também é totalmente suportada ao usar os mecanismos de armazenamento XtraDB e InnoDB. A criptografia também é suportada pelo mecanismo de armazenamento Aria, mas apenas para tabelas criadas com ROW_FORMAT=PAGE (o padrão) e para o log binário (log de replicação). O MariaDB ainda permite ao usuário flexibilidade no que criptografar. No XtraDB ou InnoDB, pode-se optar por criptografar:
  • tudo — todos os espaços de tabela (com todas as tabelas)
  • mesas individuais
  • tudo, exceto tabelas individuais

Além disso, pode-se optar por criptografar os arquivos de log do XtraDB/InnoDB (o que é recomendado).

MariaDB tem suas limitações. O Galera Cluster gcache, por exemplo, não é criptografado, mas está planejado como parte da versão MariaDB 10.4. Você pode encontrar uma lista completa de limitações aqui.

Como configurar e configurar MariaDB para criptografia de dados em repouso

  1. Gere chaves de criptografia aleatórias usando o comando openssl rand. 
    $ mkdir -p /etc/mysql/encryption
$ for i in {1..5}; do openssl rand -hex 32 >> /etc/mysql/encryption/keyfile;  done;
    Agora, abra e edite o arquivo /etc/mysql/encryption/keyfile e adicione os IDs da chave aos quais isso será referência ao criar tabelas criptografadas, pois é o ID da chave de criptografia. Consulte ENCRYPTION_KEY_ID para obter mais detalhes. Portanto, o formato a seguir deve ser o seguinte:
    <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 criar ou gerar uma senha aleatória usando o comando semelhante da etapa 1:
    $ openssl rand -hex 128 > /etc/mysql/encryption/keyfile.key
  3. Antes de prosseguir para a próxima etapa, é importante observar os seguintes detalhes sobre a criptografia do arquivo de chave:
    • O único algoritmo que o MariaDB atualmente suporta para criptografar o arquivo de chave é o modo Cipher Block Chaining (CBC) do Advanced Encryption Standard (AES).
    • O tamanho da chave de criptografia pode ser de 128 bits, 192 bits ou 256 bits.
    • A chave de criptografia é criada a partir do hash SHA-1 da senha de criptografia.
    • A senha de criptografia tem um comprimento máximo de 256 caracteres.
    Agora, para criptografar o arquivo de chave usando o comando openssl enc, execute o seguinte comando abaixo:
    $ 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. Adicione as seguintes variáveis ​​em seu arquivo de configuração do MySQL (ou seja, /etc/my.cnf no sistema operacional Linux baseado em RHEL ou /etc/mysql/my.cnf no sistema operacional baseado em Linux Debian/Ubuntu) 
    [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 o servidor MariaDB agora 
    $ systemctl start mariadb

Verifique e teste a criptografia


Para verificar e testar a criptografia, basta criar uma tabela de amostra. Por exemplo, crie a tabela fazendo as seguintes instruções SQL abaixo:
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)

Então, vamos adicionar alguns dados às tabelas:
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 e ver quais são as tabelas criptografadas, basta executar o seguinte SELECT consulta abaixo:
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)

A criação da tabela InnoDB não precisa especificar a palavra-chave ENCRYPTED=YES. Ele é criado automaticamente conforme especificamos no arquivo de configuração para ter innodb_encrypt_tables =ON.

Se você quiser especificar o id de criptografia da tabela a ser usada, você também pode fazer o seguinte:
MariaDB [test]> CREATE TABLE c (i int) ENGINE=InnoDB ENCRYPTION_KEY_ID = 4;
Query OK, 0 rows affected (0.003 sec)

O ENCRYPTION_KEY_ID foi obtido do arquivo de chave de criptografia que geramos anteriormente.

Além disso, se você quiser mais testes através do shell, você pode usar as strings comando que lhe mostrei anteriormente.

Informações adicionais sobre criptografia MariaDB


Se sua instância MariaDB não deve conter nenhuma tabela não criptografada, apenas configure a variável em seu arquivo de configuração my.cnf dentro do [mysqld] seção da seguinte forma:
innodb_encrypt_tables = FORCE.

Para criptografia de log binário, basta adicionar o seguinte 
encrypt_binlog = 1

O redo-log do InnoDB não é criptografado por padrão. Para criptografá-lo basta adicionar a variável abaixo após a seção [mysqld], 
innodb-encrypt-log

Se você precisar de criptografia para suas tabelas temporárias em disco e arquivos temporários, poderá adicionar o seguinte:
encrypt-tmp-disk-tables=1
encrypt-tmp-files=1