MENU

さくらのクラウド「データベースアプライアンスにおけるTLS有効化」について確認する【2026年4月追記】4月1日以降の検証結果

目次

さくらのクラウド「データベースアプライアンスにおけるTLS有効化」について確認する

こんにちは、UOZUです!

今やWebだけでなくデータベースとの接続経路も暗号化することが求められる時代です。
そんな中、さくらのクラウドから「データベースアプライアンスにおいて、原則としてTLSによる通信経路の暗号化が有効な状態で作成されるようになる」というニュースリリースが発表されました。

さくらのクラウドニュース
データベースアプライアンスにおけるTLS有効化について さくらのクラウドに関連するニュースをお届けします

概要
今後、データベース(アプライアンス)をご利用時の接続に関して、原則() 「自己署名証明書によるTLS1.2, 1.3に対応した通信経路の暗号化が有効」な状態で作成されるようになります。 通信経路の暗号化のみに対応しており、CA証明書による接続先の検証およびクライアント証明書認証には対応しておりません。 証明書の期限は5年間であり、証明書のローテーションには対応しておりません。 () TLS有効化対象の既存アプライアンスは 3月31日時点でサポートされているMariaDB 10.11およびPostgreSQL 14のみです。

4月1日の仕様変更を前に、現時点(2月23日)で「シングル構成」と「冗長化構成」でどのような差があるのか、AlmaLinuxを使って検証環境を構築して確認してみました。

検証環境の用意と確認

検証の為、以下の環境を用意しました。

【検証環境】
• クライアント: AlmaLinux release 10.1 / MariaDB Client 10.11.15 (192.168.0.2)
• DBアプライアンス①: MariaDB 10.11.9(シングル構成 / 192.168.0.3)
• DBアプライアンス②: MariaDB 10.11.9(冗長化構成 / 192.168.0.4

通常のプランでの確認内容(2月23日時点)

まずは通常のデータベースベースアプライアンス(シングル構成)に、mariadbコマンドでTLS接続オプション(–ssl)を付けて接続してみます。
tls_versionが「TLSv1.2,TLSv1.3」と対応している事は確認出来ますが、現時点では、TLS接続自体は有効に出来ません。

opensslコマンドでも確認しますが、やはり現時点では接続が出来ないようです。

冗長化オプションが有効な場合での確認内容(2月23日時点)

冗長化オプションが有効な構成の場合はどうでしょうか?
ニュースリリース記載の通り、tls_versionは「TLSv1.2」までとなりますが、2月23日時点でもTLS接続自体は可能な事が確認できます。

opensslコマンドでも、TLS1.2で接続が可能な事が確認できます。

【2026年4月追記】4月1日以降の検証結果

4月1日を過ぎましたので、改めてデータベースアプライアンスにおけるTLSの状況を確認してみます。
データベースアプライアンスはMariaDB 10.11 で指定して新規に作成しています。

通常のプランでの確認内容(4月6日時点)

[root@uozu-web ~]# mariadb -h 192.168.0.3 -P 3306 -u uozu -D uozu -p --ssl
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 28
Server version: 10.11.9-MariaDB MariaDB Server
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [uozu]> SELECT @@version;
+-----------------+
| @@version |
+-----------------+
| 10.11.9-MariaDB |
+-----------------+
1 row in set (0.001 sec)
MariaDB [uozu]> SHOW VARIABLES LIKE 'tls_version';
+---------------+-----------------+
| Variable_name | Value |
+---------------+-----------------+
| tls_version | TLSv1.2,TLSv1.3 |
+---------------+-----------------+
1 row in set (0.001 sec)

MariaDB [uozu]> SHOW VARIABLES LIKE ‘%ssl%’;
+———————+—————————————————+
| Variable_name | Value |
+———————+—————————————————+
| have_openssl | YES |
| have_ssl | YES |
| ssl_ca | /etc/pki/tls/private/db_appliance/ca.pem |
| ssl_capath | |
| ssl_cert | /etc/pki/tls/private/db_appliance/server-cert.pem |
| ssl_cipher | |
| ssl_crl | |
| ssl_crlpath | |
| ssl_key | /etc/pki/tls/private/db_appliance/server-key.pem |
| version_ssl_library | OpenSSL 1.1.1k FIPS 25 Mar 2021 |
+———————+—————————————————+
10 rows in set (0.001 sec)

tt[root@uozu-web ~]# openssl s_client -connect 192.168.0.3:3306 -starttls mysql
Connecting to 192.168.0.3
CONNECTED(00000003)
Can’t use SSL_get_servername
depth=1 CN=Sakura_DBAppliance_Auto_Generated_CA_Certificate
verify error:num=19:self-signed certificate in certificate chain
verify return:1
depth=1 CN=Sakura_DBAppliance_Auto_Generated_CA_Certificate
verify return:1
depth=0 CN=Sakura_DBAppliance_Auto_Generated_Server_Certificate
verify return:1

Certificate chain
0 s:CN=Sakura_DBAppliance_Auto_Generated_Server_Certificate
i:CN=Sakura_DBAppliance_Auto_Generated_CA_Certificate
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Apr 6 09:48:33 2026 GMT; NotAfter: Apr 5 09:48:33 2031 GMT
1 s:CN=Sakura_DBAppliance_Auto_Generated_CA_Certificate
i:CN=Sakura_DBAppliance_Auto_Generated_CA_Certificate
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Apr 6 09:48:33 2026 GMT; NotAfter: Apr 5 09:48:33 2031 GMT

Server certificate
—–BEGIN CERTIFICATE—–
MIIDAjCCAeqgAwIBAgIBAjANBgkqhkiG9w0BAQsFADA7MTkwNwYDVQQDDDBTYWt1
cmFfREJBcHBsaWFuY2VfQXV0b19HZW5lcmF0ZWRfQ0FfQ2VydGlmaWNhdGUwHhcN
MjYwNDA2MDk0ODMzWhcNMzEwNDA1MDk0ODMzWjA/MT0wOwYDVQQDDDRTYWt1cmFf
REJBcHBsaWFuY2VfQXV0b19HZW5lcmF0ZWRfU2VydmVyX0NlcnRpZmljYXRlMIIB
~省略
—–END CERTIFICATE—–
subject=CN=Sakura_DBAppliance_Auto_Generated_Server_Certificate
issuer=CN=Sakura_DBAppliance_Auto_Generated_CA_Certificate

No client certificate CA names sent
Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:RSA-PSS+SHA256:rsa_pss_pss_sha384:RSA-PSS+SHA384:rsa_pss_pss_sha512:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224:UNDEF:UNDEF
Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:RSA-PSS+SHA256:rsa_pss_pss_sha384:RSA-PSS+SHA384:rsa_pss_pss_sha512:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512
Peer signing digest: SHA256
Peer signature type: rsa_pss_rsae_sha256
Peer Temp Key: X25519, 253 bits

SSL handshake has read 2272 bytes and written 451 bytes
Verification error: self-signed certificate in certificate chain

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 19 (self-signed certificate in certificate chain)
~省略

冗長化オプションが有効な場合での確認内容(4月6日時点)

[root@uozu-web ~]# mariadb -h 192.168.0.4 -P 3306 -u uozu -D uozu -p --ssl
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 35
Server version: 10.11.13-MariaDB-log MariaDB Server
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [uozu]> SELECT @@version;
+----------------------+
| @@version |
+----------------------+
| 10.11.13-MariaDB-log |
+----------------------+
1 row in set (0.000 sec)
MariaDB [uozu]> SHOW VARIABLES LIKE 'tls_version';
+---------------+-----------------+
| Variable_name | Value |
+---------------+-----------------+
| tls_version | TLSv1.2,TLSv1.3 |
+---------------+-----------------+
1 row in set (0.001 sec)

MariaDB [uozu]> SHOW STATUS LIKE ‘Ssl_cipher’;
+—————+————————+
| Variable_name | Value |
+—————+————————+
| Ssl_cipher | TLS_AES_256_GCM_SHA384 |
+—————+————————+
1 row in set (0.001 sec)

MariaDB [uozu]> SHOW VARIABLES LIKE ‘%ssl%’;
+———————+———————————-+
| Variable_name | Value |
+———————+———————————-+
| have_openssl | YES |
| have_ssl | YES |
| ssl_ca | |
| ssl_capath | |
| ssl_cert | /etc/pki/tls/certs/mysql.crt |
| ssl_cipher | |
| ssl_crl | |
| ssl_crlpath | |
| ssl_key | /etc/pki/tls/private/mysql.key |
| version_ssl_library | OpenSSL 1.1.1k FIPS 25 Mar 2021 |
+———————+———————————-+
10 rows in set (0.002 sec)

[root@uozu-web ~]# openssl s_client -connect 192.168.0.4:3306 -starttls mysql
Connecting to 192.168.0.4
CONNECTED(00000003)
Can’t use SSL_get_servername
depth=0 CN=localhost
verify error:num=18:self-signed certificate
verify return:1
depth=0 CN=localhost
verify return:1

Certificate chain
0 s:CN=localhost
i:CN=localhost
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Apr 1 02:59:22 2026 GMT; NotAfter: Mar 31 02:59:22 2031 GMT

Server certificate
—–BEGIN CERTIFICATE—–
MIIDCTCCAfGgAwIBAgIUYX16D4qIaosHSFpP/ht6elgC1Z0wDQYJKoZIhvcNAQEL
BQAwFDESMBAGA1UEAwwJbG9jYWxob3N0MB4XDTI2MDQwMTAyNTkyMloXDTMxMDMz
MTAyNTkyMlowFDESMBAGA1UEAwwJbG9jYWxob3N0MIIBIjANBgkqhkiG9w0BAQEF
AAOCAQ8AMIIBCgKCAQEA6X5QW3HupRYmul68IzR09bpO9MVvS9IU6L1M+rWRyfnL
~省略
—–END CERTIFICATE—–
subject=CN=localhost
issuer=CN=localhost

No client certificate CA names sent
Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:RSA-PSS+SHA256:rsa_pss_pss_sha384:RSA-PSS+SHA384:rsa_pss_pss_sha512:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224:UNDEF:UNDEF
Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:RSA-PSS+SHA256:rsa_pss_pss_sha384:RSA-PSS+SHA384:rsa_pss_pss_sha512:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512
Peer signing digest: SHA256
Peer signature type: rsa_pss_rsae_sha256
Peer Temp Key: X25519, 253 bits

SSL handshake has read 1506 bytes and written 451 bytes
Verification error: self-signed certificate

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Protocol: TLSv1.3
Server public key is 2048 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 18 (self-signed certificate)
~省略

検証結果の比較

事前のアナウンス通り、データベースアプライアンスがシングル構成、冗長化オプションが有効な際のいずれも場合も、
TLSv1.2,TLSv1.3で利用可能な事が確認できました。

また先のニュースに掲載の通り、いずれのTLS接続も自己証明書での設定となる為、実際にアプリケーション側で接続する際には、自己証明書を受ける設定が必要になる点は注意が必要かと思います。

ネットワーク設計における「セキュリティ」の考え方

今回のアップデートにより、4月1日以降はより安価な「シングル構成」であっても、PCI DSSやISMSなどの要件で求められる「サービス間通信の暗号化」をクリアできるようになりました。

以前、さくらのクラウドのパケットフィルタによるアクセス制限について解説しましたが、パケットフィルタで物理的な「入り口」を絞り、さらにTLSで「中身」を秘匿する。この多層防御こそが、クラウド時代のインフラ設計における「最適解」ではないでしょうか。

おわりに

今回の検証で、4月のアップデートでシングル構成・冗長化オプションのいずれでも、TLS 1.3を含む最新の暗号化プロトコルが利用可能になりました。

「DBの暗号化接続の設定がうまくいかない……」「セキュリティ要件を満たすインフラ構成を相談したい」という方がいらっしゃれば、ぜひネットアシストにご相談ください。

それではまた!

お問い合わせ

この記事をシェアする
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

ネットアシスト運用チームのシニアエンジニア
さくらのクラウド検定ベーシック所持

目次