「MySQL」と「PostgreSQL」を安全に使い続けるための「バージョン管理」を理解する

はじめに

この連載では、オープンソースのリレーショナル・データベース(RDB)の「MySQL」と「PostgreSQL」を使いこなすヒントを、両製品の共通点と違いを確認しながら解説していきます。

現在、それぞれの製品をベースとしたクラウド・データベースは複数存在しています。この連載では製品の比較を多く行いますが、製品機能や仕様の優劣についてを論ずる目的のものではないことはあらかじめご了承ください。

第5回の今回は、ガイドラインをもとにMySQLとPostgreSQLを安全に使い続けるためのポイントとバージョン管理を整理していきます。

セキュアな運用のためのガイドライン

これまで、本連載ではMySQLとPostgreSQLを対象に、通信暗号化や認証認可、保存データの暗号化、さらにSQLインジェクション対策、監査、マスキングといった個別のセキュリティ機能を見てきました。データベースの安全性は機能を知ることだけではなく、「どのように設定するか」と「その状態を更新の中でどう保つか」の両方で決まります。ここで参考になるのはそれぞれの製品向けに作成されたセキュリティのガイドラインです。

MySQLにはリファレンスマニュアルの1つとして「MySQL 8.0 Secure Deployment Guide」が用意されていますが、残念ながら最新版のLTSに対応したものは出ていません。正規のインストール用バイナリの入手と検証手順に始まり、インストール後の設定や各セキュリティ用のコンポーネントのセットアップ手順、ユーザーアカウントやロールの設定上のポイントが手短にまとめられています。

また、商用版のEnterprise Editionの機能を含めて、EU一般データ保護規則（GDPR）やクレジットカードの会員情報の保護を目的としたセキュリティ基準であるPCI DSSへ対応させる方法を整理した日本語のホワイトペーパーも公開されています。

なお、英語のみにはなりますが、「MySQL Reference Architectures for Security」ではデータベースのセキュリティ上で考慮すべき点を整理し、アクセスされる環境やデータベースで管理するデータの属性の応じてBronze、Silver、Gold、Platinumに分類したうえで、必要なセキュリティ施策を整理しています。

一方のPostgreSQLで参考になる資料はPostgreSQL エンタープライズコンソーシアムが発行した「PostgreSQLセキュリティガイド」です。このセキュリティガイドでは、PCI DSSでの要求項目に対してPostgreSQLでどのように対応できているかの状況および手法や考え方が整理されています。ただし2015年発行となっており、MySQLのSecure Deployment Guideと同じく、最新バージョンには対応していません。

最新ではないガイドラインから学べること

前項で紹介したガイドラインは、残念ながら公開されてから時間が経っています。とはいえ「データベースを安全な状態を維持できるか」という観点では重要なポイントが掲載さているので、解説していきます。

1. 配布物の真正性を確認してから導入する

MySQL 8.0 Secure Deployment Guideでは、Linux向けの.tar.gzバイナリを利用する場合にGPG署名で配布物の完全性を検証することを明示しています。オープンソースの性質上、ソースコードが自由に再配布され、バイナリを提供しているWebサイトもありますが、安全性のためにも基本的には公式のリファレンスマニュアルで示されているバイナリを利用すべきです。

2. 接続元の絞り込みと通信暗号化

MySQLではシステム変数のbind_addressで、PostgreSQLでは設定のlisten_addressesでアクセスを許可する接続元IPアドレスを限定できます。シンプルな設定ではありますが、ユーザー認証でのアクセス制御とは違った形でのアクセスの制限が可能です。
MySQLにはSERVICE_CONNECTION_ADMIN権限を持つユーザーのみが利用できる管理者専用の接続の仕組みが用意されており、こちらはadmin_addressで接続元IPアドレスを指定しておくことができます。

3. 認証方式とパスワード管理を旧式のまま残さない

MySQLにおけるパスワードのハッシュ方式はcaching_sha2_passwordが前提で、mysql_native_passwordはMySQL 8.4でデフォルト無効、9.0で削除済みです。
PostgreSQLではパスワードを暗号化するアルゴリズムの設定password_encryptionのデフォルトがscram-sha-256で、設定可能なMD5は非推奨かつ将来削除予定です。

4. 権限は最小化し、ロールで管理する

MySQLのガイドでは最小権限が原則とされ、現行MySQLではロールと動的権限(Dynamic privileges)を活用することでSUPER権限からの依存からの脱却が進んでいます。

5. 認証失敗への抑止策を入れる

MySQLとPostgreSQLにはパスワードの総当たり攻撃(ブルートフォース攻撃)を防ぐために、それぞれログイン失敗時に再度のログイン試行に遅延を入れる仕組みが用意されています。
MySQLではConnection Controlプラグイン、PostgreSQLでは拡張機能のauth_delayが該当します。auth_delayはログイン失敗時に追加する遅延をミリ秒単位で指定するシンプルな設定となっています。
MySQLのConnection Controlプラグインで特徴的なのが、遅延が追加されるまでの試行回数が設定できる点、ミリ秒単位で設定する遅延の最小値の時間がログインに失敗するごとに追加され遅延時間が長くなっていく点です。

両ガイドラインは公開時期こそ古いものの、最新版でも通用する考え方や確認ポイントを多く含んでいます。ただし、具体的なコマンドや既定値は現行版と異なる場合があるため、そのまま適用せず、現在の公式ドキュメントと照合して利用すべきです。

バージョン管理の考え方

リリースサイクルやマイナー・バージョンが提供される期間は第1回で解説しています。バージョン選択の観点では、MySQLでは「安定運用を重視してLTSを利用する」か「新機能を優先してイノベーション・リリース系列を追うか」が要点になります。PostgreSQLの場合は「サポート中のメジャーバージョンにいるか」と「その系列の最新マイナーまで追従しているか」が要点です。

実務で重要なのは、単に「新しいバージョンを入れる」ことではなく、サポート切れを起こさないよう計画的に系列を維持することです。MySQLでは、すでにMySQL 8.0が2026年4月末で新規パッチが提供されないSustaining Supportのフェーズに達しており、8.0系利用者にはMySQL 8.4 LTSまたは最新のMySQL 9.7 LTS、もしくはイノベーション・リリースの系列への移行が促されています。

MySQLのバージョン・アップの組み合わせおよびバージョン・アップの方法はやや複雑になっています。

• インプレイス・アップグレード: バイナリの入れ替えと再起動のみで完了
• ダンプ・アンド・ロード: データを論理バックアップし、新しいバージョンのサーバーにロードし直す
• レプリケーション: 異なるバージョンの間でレプリケーションによるデータ複製の可否
• クローン: MySQLのクローン・プラグインによるデータ複製の可否

表：バージョン・アップの組み合わせおよびバージョン・アップの方法

いずれの方法も非対応となっている2行は、基本的に複数のメジャー・バージョンを飛ばしたバージョン・アップが不可のためで、イノベーション・リリースから次のイノベーション・リリースの場合は、いったん間にあるLTSにバージョン・アップすることが求められます。

また、MySQL 5.7からの場合は、まず8.0にバージョン・アップした上で、以降メジャー・バージョンを1つずつ上げていく必要があります。

PostgreSQLのメジャー・バージョンは5年でEoLを迎えるため、長く同じ系列を使い続けるにしても、いずれはメジャー・バージョン・アップが必要です。ただしPostgreSQLは途中のメジャー・バージョンを飛ばして上げること自体は可能で、その際も間のリリースノートを読んで影響を確認することが推奨されています。

PostgreSQLはマイナー・バージョン・アップとメジャー・バージョン・アップの区別が明快で、マイナー・バージョン・アップはデータディレクトリの互換を維持したまま、サーバー停止・バイナリ入れ替え・再起動で適用できる一方、メジャー・バージョン・アップは データのダンプとリロード、またはpg_upgradeの実行が必要です。また、場合によってはインデックスの再作成が必要となることもあります。ただしpg_upgradeは全ての拡張機能の互換性までは保証しないため、実施の運用時には事前の検証は欠かせません。

脆弱性情報の収集と確認先

セキュリティの観点はもちろん、バージョン・アップのタイミングを決定するためにも、製品の脆弱性情報を把握しておくことは重要です。

MySQLの脆弱性については、新たに「MySQL Community Edition Vulnerability Advisory」というサイトにMySQLコミュニティ版の情報を集約して公開されるようになりました。オラクルのCritical Patch Update(CPU)でも公開されます。オラクルのCPUは基本的に1、4、7、10月の第3火曜日に公開されることとなっており、MySQLのマイナー・バージョンも概ね同じタイミングでリリースされる運用になっています。また各バージョンのリリースノートにも重要な変更点として記載されるものもあります。

PostgreSQLでは、脆弱性関連の情報が比較的分かりやすく整理されています。公式のSecurity InformationページにはPostgreSQL本体だけでなく、ドライバ、拡張、インストーラ、周辺ユーティリティを含むエコシステム全体にセキュリティ問題があり得ることが明記されており、修正は原則としてマイナー・バージョン更新の一部として配布されます。

また、セキュリティ通知を受けるにはメーリングリストのpgsql-announceを購読し、必要ならSecurityタグだけを受け取る方法も案内されています。1点注意したいのは拡張機能をインストールして利用している場合、このページではカバーされていないものもあるため、個別に開発元の情報発信を監視しておくべきです。

おわりに

第1回から今回まではセキュリティをテーマに解説を進めてきましたが、次回以降はインフラ設計のポイントを多角的に見ていきます。次回は、バックアップやリカバリについての解説を予定しています。