1. 導入
データベースのセキュリティにおいて、定期的なパスワード変更や適切な権限管理はDBAの基本業務です。MariaDBではパスワードを変更する方法として「SET PASSWORD文」と「ALTER USER文」の2種類が存在します。一見すると同じ結果をもたらすように思えますが、運用の現場では「どちらを標準採用すべきか」という基準が重要になります。本稿では、実務での混乱を避けるために、それぞれの使い分けと実装方法を解説します。
2. 基礎知識
MariaDBのユーザー認証は、通常 `mysql` データベース内の `user` テーブルで管理されています。パスワードは平文で保存されることはなく、ハッシュ化されて格納されます。
SET PASSWORD文は、主にパスワード変更に特化したコマンドです。一方でALTER USER文は、パスワード変更だけでなく、アカウントのロック・アンロックや認証プラグインの指定など、ユーザーアカウントの設定全般を管理するための包括的なコマンドです。
3. 実装/解決策
実務における推奨は、特別な理由がない限り「ALTER USER文」を使用することです。これは、MySQL/MariaDBのバージョンアップにおいても互換性が高く、拡張性があるためです。
SET PASSWORD文は古いバージョンとの互換性を維持するために残されている側面があるため、スクリプトや運用手順書にはALTER USERを記載するのがモダンな手法と言えます。
4. サンプルプログラム
以下に、ユーザーのパスワードを変更する実用的なSQLコード例を示します。開発環境や検証環境で確認してください。
— 1. ALTER USER文による変更（推奨）
— ‘username’@’host’ の形式で対象を指定します
ALTER USER ‘shika’@’localhost’ IDENTIFIED BY ‘new_secure_password123’;
— 2. SET PASSWORD文による変更（レガシーな方法）
— 現在ログイン中のユーザー自身のパスワードを変更する場合
SET PASSWORD = PASSWORD(‘another_password’);
— 特定ユーザーのパスワードを変更する場合
SET PASSWORD FOR ‘shika’@’localhost’ = PASSWORD(‘deer_password’);
— 変更後は、権限を反映させるためにフラッシュを行うのが確実です
FLUSH PRIVILEGES;
5. 応用・注意点
現場で陥りやすいバグや注意点は以下の通りです。
・FLUSH PRIVILEGESの必要性について
基本的にはALTER USER文を実行すれば即座に反映されますが、直接テーブルを操作した場合などはFLUSH PRIVILEGESが必要です。習慣として実行しても害はありませんが、ALTER文の特性を理解しておくことが重要です。
・ユーザー名の指定ミス
`’shika’@’localhost’` と `’shika’@’%’` は別物として扱われます。特に外部接続を許可しているユーザーの場合、誤ったホスト指定でパスワードを変更すると、意図しない場所で接続エラーが発生するリスクがあります。
・バージョン互換性
古いMariaDBやMySQLのバージョンでは、PASSWORD()関数が非推奨となっていたり、異なるハッシュ化アルゴリズムを使用していたりする場合があります。パスワードポリシー（パスワードの長さや複雑さ）が有効な環境では、単純なパスワードを設定しようとするとエラーになるため、事前に設定値を確認してください。
DBAとしては、手動での変更履歴を必ず「変更管理ログ」に残し、誰がどのタイミングでパスワードを変更したかを追跡できるようにしておく運用を推奨します。
コメント