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

アプライアンス # データベースアプライアンス

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

こんにちは、UOZUです!

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

https://cloud.sakura.ad.jp/news/2026/02/20/db-tls-announcement

概要
今後、データベース(アプライアンス)をご利用時の接続に関して、原則() 「自己署名証明書による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]&gt; SELECT @@version;<br>+-----------------+<br>| @@version       |<br>+-----------------+<br>| 10.11.9-MariaDB |<br>+-----------------+<br>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)

冗長化オプションが有効な場合での確認内容(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]&gt; SHOW VARIABLES LIKE 'tls_version';<br>+---------------+-----------------+<br>| Variable_name | Value           |<br>+---------------+-----------------+<br>| tls_version   | TLSv1.2,TLSv1.3 |<br>+---------------+-----------------+<br>1 row in set (0.001 sec)

検証結果の比較

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

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

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

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

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

おわりに

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

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

それではまた!

この記事を書いた人

UOZU

ネットアシスト運用チーム10年目の運用エンジニア

さくらのクラウド検定 ベーシック (第一回)

さくらのクラウド検定 アドバンスド (第一回)

AWS Certified Solutions Architect - Associate

AWS Certified AI Practitioner