転送中および保存中のMariaDBデータベースを暗号化することは、データを評価する場合に組織が考慮する必要がある最も重要なことの1つです。
金融取引、医療記録、機密情報、さらには個人データを扱う組織は、このタイプのデータ保護を必要とします。基本的に、データベースの暗号化は、読み取り可能なデータを、許可されていないユーザーが読み取れない（または少なくとも復号化するのが難しい）形式に変換します。
データを暗号化することで、ハッカーや許可されていない人がビジネスに損害を与える可能性のある誤用や悪意を防ぐことができます。暗号化されていないデータは、インフラストラクチャに損害を与えたり情報を盗んだりする可能性のある悪意のあるデータを注入するハッカーによって攻撃される傾向があります。 Quartzは最近、これらの線に沿って発生した最大の違反に関する記事をリリースしました。過去20年間に、数十億のアカウントからデータが盗まれたことは憂慮すべきことです。
関連リソースMySQLとMariaDBのバックアップを暗号化する方法データベースのセキュリティ-転送中および保存中のバックアップ暗号化更新：ClusterControlDBAになる-SSLキー管理と転送中のMySQLデータの暗号化このブログでは、MariaDBデータが保存中か転送中かを問わず、暗号化するさまざまな方法について説明します。暗号化の基本的な理解とその使用方法を提供し、これらのアプローチを利用してデータを安全に保つことができるようにします。
MariaDBデータの暗号化：転送中
MariaDBは、デフォルトでは、サーバーからクライアントへのネットワークを介したデータ送信中に暗号化を使用しません。ただし、デフォルトの設定を使用すると、潜在的なハッカーがセキュリティで保護されていない/暗号化されていないチャネルを盗聴する可能性があります。隔離された環境または安全性の高い環境で操作している場合は、このデフォルト状態が許容される場合があります。ただし、これは、潜在的な「中間者」攻撃に備えてデータベースをセットアップするため、クライアントとネットワークが異なるネットワーク上にある場合には理想的ではありません。
これらの攻撃を回避するために、MariaDBでは、トランスポート層セキュリティ（TLS）プロトコル（旧称Secure Socket LayerまたはSSL）を使用して、サーバーとクライアント間で転送中のデータを暗号化できます。開始するには、MariaDBサーバーがTLSサポートでコンパイルされていることを確認する必要があります。これは、以下に示すようにSHOWGLOBALVARIABLESステートメントを実行することで確認できます。
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)SSLとTSLの違いに戸惑うかもしれません。ドキュメントではSSLという用語を使用する場合があり、構成の変数ではプレフィックスとしてssl_ *も使用されますが、MariaDBは安全な後継者のみをサポートし、古いSSLバージョンはサポートしていません。使用する必要のあるTLSバージョンの適切なサポートを必要とするMariaDBの正しいバージョンを識別して使用する必要がある場合があります。たとえば、PCI DSS v3.2では、古いバージョンのMariaDBがサポートするTLSv1.2の最小プロトコルバージョンを使用することをお勧めします。ただし、TLS 1.3では、OpenSSL 1.1.1が必要であり、通信する2つのシステム間のハンドシェイクがより効率的であるため高速です。これは、MariaDB10.2.16およびMariaDB10.3.8以降でサポートされています。
特定のTLSバージョンで使用可能な暗号を利用するには、 -ssl-cipherを使用して暗号を定義できます。 mysqldで コマンドまたはssl-cipher 構成ファイルの変数。 OpenSSLを使用する場合、ssl_cipherシステム変数を使用していても、TLSv1.3暗号を除外できないことに注意してください。
転送中のデータを暗号化するための構成パラメーター
転送中のデータを暗号化するには、以下に示す一連のコマンドを実行できます。
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サーバー証明書を生成する
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クライアント証明書を生成する
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-subj の共通名（CN）に注意してください 引数は、生成するCA、サーバー、およびクライアントの証明書に対して一意である必要があります。技術的には、CAとサーバーは同じCNを持つことができますが、これら3つの一意の識別子にするのが最善です。そうしないと、次のようなエラーが発生します：
ERROR 2026 (HY000): SSL connection error: tlsv1 alert unknown ca了解しました。証明書とキーが用意されています。 MySQL構成ファイルのssl_*変数を使用してパスを指定する必要があります（たとえば、RHELベースのOSの場合は/etc/my.cnf、Debian / UbuntuOSの場合は/etc/mysql/my.cnf）。以下の設定例を参照してください：
[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もちろん、証明書とキーを配置した正しいパスを指定する必要があります。
次に、これらのパラメータを [client-mariadb]の下に配置します 以下のような構成ファイルのセクション：
[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前述のように、SSL/TLS構成で使用できる暗号のタイプを指定できます。これは、以下の構成設定を指定することで実行できます。
[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または、以下の構成を以下のように使用できます。
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.最後の行は、このコマンドに相当するものを示しています：
openssl ciphers -v 'HIGH:!DSS:!RCA-SHA:!DES-CBC3-SHA:[email protected]'これにより、弱い暗号と、 DHE-DSS-AES256-GCM-SHA384などのプレフィックス形式の暗号は除外されます。 たとえば暗号。
ClusterControlを使用した証明書の生成
または、ClusterControlを使用して証明書とキーを生成することもできます。これを行うには、以下に示すように次のことを行うことができます。
- MariaDBクラスターを選択し、セキュリティに移動します タブをクリックし、SSL暗号化を選択します。以下の私の例では、これはMariaDBGaleraクラスターです。
- SSL暗号化を選択して有効にします。新しい証明書を作成することも、既存の証明書を選択することもできます。このサンプルでは、「証明書の作成」オプションを選択します。
- 最後のステップは、証明書の有効期限を構成することです。下記参照：
[ノードの再起動]をクリックすると、ClusterControlはローリングリスタートを実行します。 MariaDB 10.4（現在RCバージョン）を使用している場合は、MariaDBサーバーを再起動せずにSSLを使用できることに注意してください。 MariaDB10.4バージョンで追加された新機能であるFLUSHSSLコマンドを使用するだけです。
TLS / SSL証明書/キーを処理する別の方法として、キー管理を使用することもできます。 ClusterControlの下。これを行う方法の詳細については、このブログをチェックしてください。
TLS /SSLMariaDBユーザーを作成する
終わったと思ったとしても、そうではありません。ユーザーがサーバーに接続するときにSSLを使用する必要があることを確認する必要があります。このユーザーは、常にプライベートチャネルを介してサーバーと対話する必要があります。すべてのクライアントが非常に安全でプライベートな方法でサーバーと対話することを確認する必要があるため、これは非常に重要です。
これを行うには、次の例を実行します。
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)クライアント/アプリケーションホストに接続するときに、前の手順に基づいて生成した証明書をコピーしてください。
接続の確認
接続が暗号化されているかどうかをテストすることは、ステータスを判断するために非常に重要です。これを行うには、以下のコマンドを実行できます。
mysql -e "status"|grep -i 'cipher'
SSL: Cipher in use is DHE-RSA-AES256-GCM-SHA384または、OpenSSLバージョン1.1.1で -starttls mysqlのサポートが追加されました 。 https://testssl.sh/openssl-1.0.2k-dev-chacha.pm.ipv6.Linux+FreeBSD.tar.gz（またはPDF形式でこのプレゼンテーションをチェックアウト）で入手できる、静的にコンパイルされたopensslバイナリが利用可能です。 。次に、以下のコマンドを実行できます。
echo | bin/openssl.Linux.x86_64.static s_client -starttls mysql -connect localhost:3306 -CAfile /etc/ssl/galera/self-gen/ca-cert.pem結果の例は次のようになります。
$ 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)
---
DONEMariaDBデータの暗号化：保存データ
ハードウェアストレージ内に物理的に保存されている（つまり、保存されている）暗号化されたデータは、データ侵害に対する安定性と保護を強化します。悪意のある攻撃者がMariaDBデータベースにログインできる場合、攻撃者はプレーンテキストでデータを読み取ることができます。 Linuxでstringsコマンドを使用するのと同様に、データベースからデータを簡単に取得できます。さらに、攻撃者がテーブルスペースのファイル形式を高度に理解していると、さらに危険が増します。
保管時の暗号化は追加の保護ですが、優れたファイアウォール、強力なパスワード、正しいユーザー権限、およびクライアントとサーバー間の転送中の暗号化に代わるものではありません。
テーブルとテーブルスペースでの暗号化に対するMariaDBのサポートは、バージョン10.1.3で追加されました。テーブルが暗号化されているため、誰かがデータを盗むことはほとんど不可能です。このタイプの暗号化により、組織はGPDRなどの政府規制に準拠することもできます。
MariaDBで保存データの暗号化を有効にすると、ENCRYPTED=YESまたはinnodb_encrypt_tables=ONで定義されたテーブルで、保存されているデータが暗号化されます。 MariaDBのデータベースを介してアクセスされた場合にのみ復号化されます。それ以外の場合、データは読み取れません。
たとえば、暗号化されていないデータを読み取ると、次のように表示されます。
$ 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ただし、暗号化されたデータを使用すると、以下の例のようにテーブルスペースを読み取ることができなくなります。
# strings user_logs.ibd |head -10
E?*Pa
[+YQ
KNmbUtQ
T_lPAW
\GbQ.
] e2
#Rsd
ywY%o
kdUY
{]~GEMariaDBの保存データ暗号化により、データサイズのオーバーヘッドが約3〜5％増加することも注目に値します。 XtraDBおよびInnoDBストレージエンジンを使用する場合、MariaDB暗号化も完全にサポートされます。暗号化はAriaストレージエンジンでもサポートされていますが、ROW_FORMAT =PAGE（デフォルト）で作成されたテーブルとバイナリログ（レプリケーションログ）でのみサポートされています。 MariaDBを使用すると、ユーザーは何を暗号化するかを柔軟に選択できます。 XtraDBまたはInnoDBでは、暗号化を選択できます：
- すべて—すべてのテーブルスペース（すべてのテーブルを含む）
- 個別のテーブル
- 個々のテーブルを除くすべて
さらに、XtraDB / InnoDBログファイルの暗号化を選択できます（これをお勧めします）。
MariaDBには制限があります。たとえば、Galera Cluster gcacheは暗号化されていませんが、MariaDB10.4バージョンの一部として計画されています。制限事項の完全なリストはここにあります。
保存データの暗号化のためにMariaDBをセットアップおよび構成する方法
- opensslrandコマンドを使用してランダムな暗号化キーを生成します。
次に、ファイル/ etc / mysql / encoding / keyfileを開いて編集し、暗号化されたテーブルを作成するときに参照されるキーIDを暗号化キーIDとして追加します。詳細については、ENCRYPTION_KEY_IDを参照してください。したがって、次の形式は次のようになります。$ mkdir -p /etc/mysql/encryption $ for i in {1..5}; do openssl rand -hex 32 >> /etc/mysql/encryption/keyfile; done;
In my example keyfile, this looks as the following:<encryption_key_id1>;<hex-encoded_encryption_key1> <encryption_key_id2>;<hex-encoded_encryption_key2>$ cat keyfile 1;687a90b4423c10417f2483726a5901007571c16331d2ee9534333fef4e323075 2;e7bf20f1cbde9632587c2996871cff74871890d19b49e273d13def123d781e17 3;9284c9c80da9a323b3ac2c82427942dfbf1718b57255cc0bc0e2c3d6f15ac3ac 4;abf80c3a8b10643ef53a43c759227304bcffa263700a94a996810b0f0459a580 5;bdbc5f67d34a4904c4adc9771420ac2ab2bd9c6af1ec532e960335e831f02933 - 手順1と同様のコマンドを使用して、ランダムパスワードを作成または生成しましょう。
$ openssl rand -hex 128 > /etc/mysql/encryption/keyfile.key - 次の手順に進む前に、キーファイルの暗号化に関する次の詳細に注意することが重要です。
- キーファイルを暗号化するためにMariaDBが現在サポートしている唯一のアルゴリズムは、Advanced Encryption Standard（AES）のCipher Block Chaining（CBC）モードです。
- 暗号化キーのサイズは、128ビット、192ビット、または256ビットにすることができます。
- 暗号化キーは、暗号化パスワードのSHA-1ハッシュから作成されます。
- 暗号化パスワードの最大長は256文字です。
$ 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 - MySQL構成ファイルに次の変数を追加します（つまり、RHELベースのLinuxOSの場合は/etc/my.cnf、Debian / UbuntuLinuxベースのOSの場合は/etc/mysql/my.cnf）
[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 - MariaDBサーバーを今すぐ再起動します
$ systemctl start mariadb
暗号化の検証とテスト
暗号化を検証およびテストするには、サンプルテーブルを作成するだけです。たとえば、以下のSQLステートメントを実行してテーブルを作成します。
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)次に、テーブルにデータを追加しましょう：
MariaDB [test]> insert into a values(1),(2);
Query OK, 2 rows affected (0.001 sec)
Records: 2 Duplicates: 0 Warnings: 0MariaDB [test]> insert into b values(1),(2);
Query OK, 2 rows affected (0.001 sec)
Records: 2 Duplicates: 0 Warnings: 0暗号化されているテーブルを確認するには、次の SELECTを実行します。 以下のクエリ：
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)InnoDBテーブルの作成では、ENCRYPTED=YESキーワードを指定する必要はありません。構成ファイルでinnodb_encrypt_tables=ONに指定したとおりに自動的に作成されます。
使用するテーブルの暗号化IDを指定する場合は、次の操作も実行できます。
MariaDB [test]> CREATE TABLE c (i int) ENGINE=InnoDB ENCRYPTION_KEY_ID = 4;
Query OK, 0 rows affected (0.003 sec)ENCRYPTION_KEY_IDは、以前に生成した暗号化キーファイルから取得されました。
さらに、シェルを介してさらにテストが必要な場合は、文字列を使用できます。 先ほどお見せしたコマンド。
MariaDB暗号化に関する追加情報
MariaDBインスタンスに暗号化されていないテーブルが含まれていてはならない場合は、 [mysqld]内のmy.cnf構成ファイルで変数を設定するだけです。 次のセクション：
innodb_encrypt_tables = FORCE.binlog暗号化の場合は、次を追加するだけです
encrypt_binlog = 1InnoDBのREDOログはデフォルトでは暗号化されていません。暗号化するには、[mysqld]セクションの後に以下の変数を追加するだけです
innodb-encrypt-logディスク上の一時テーブルと一時ファイルの暗号化が必要な場合は、次を追加できます。
encrypt-tmp-disk-tables=1
encrypt-tmp-files=1