MySQL/MariaDB 管理者認証情報のローテーションと root 復旧：2026 ガイド

2026 年メンテナンス注記：既知の管理者認証情報のローテーションと、失われた管理者アクセスの復旧は別の作業です。前者は認証済みセッションから行う管理された変更で、後者はクラウド事業者、データベースベンダー、OS ディストリビューション、またはローカルスタックの公式復旧経路に従う必要があります。管理権限を持つシステムだけを対象にしてください。

最初に正しい分岐を選ぶ

現在の状態	正しい経路	行わないこと
有効で承認済みの管理セッションがあり、計画ローテーションを行う	身元、プラグイン、利用者、ロールバックを棚卸しし、製品/版に合う ALTER USER を使う	システムテーブルの編集、プロセス引数への秘密の指定
Ubuntu/MySQL または MariaDB が auth_socket/unix_socket を使用	ローカル OS 身元認証を維持し、パスワード管理者が本当に必要か判断	socket アカウントへのパスワードの強制
マネージド DB のマスター認証情報が既知、または復旧が必要	事業者のコントロールプレーン、秘密管理、監査手順を使う	自己管理サーバー用の起動フラグやファイルパスの流用
管理者アクセスを失い、有効な管理セッションがない	ローテーション手順を止め、正確な製品/版の公式復旧資料またはサポートへ進む	一般的な権限迂回手順の実行
XAMPP/ローカル開発スタック	実際の同梱製品が MySQL か MariaDB か、版、ポート、ローカル公開範囲を確認	空パスワードの想定、XAMPP の本番利用

phpMyAdmin はデータベースクライアントであり、独立した権限システムではありません。身元と操作をサーバーへ渡します。パスワード変更のために mysql.user、mysql.global_priv などのシステムテーブルを閲覧・編集したり、古い PASSWORD 関数の手順を使ったりしないでください。

変更の判断門と復旧点

1. 対象環境、データ所有者、承認者、メンテナンス時間、ロールバック責任者を確認します。マネージド DB では、先にコントロールプレーンのアカウント、リージョン、インスタンス/クラスター識別子、適用動作、監査証跡を確認します。
2. 既存の復元テスト済み機能でバックアップまたはスナップショットを作り、設定と権限の基準を保存します。レプリケーション、プロキシ、プール、定期ジョブ、高可用性切替への影響を確認します。
3. 秘密管理、アプリ、phpMyAdmin、ジョブ、CI/CD、監視、バックアップ、移行ツール、運用者をすべて棚卸しします。アプリに root やクラウドのマスターユーザーを使わせず、個別の最小権限アカウントを与えます。
4. 組織のパスワード方針、秘密管理、二者確認に従い新しい秘密を準備します。shell 履歴、プロセス引数、チケット、チャット、コード、イメージ、ログへ書かないでください。
5. 新しいセッションの検証が終わるまで、認証済み管理セッション一つと独立した復旧経路を維持します。一度に正確な一アカウントだけを変更します。

1. 接続先サーバーとアカウントを証明する

対象ホストまたは承認済み管理ネットワークから、インストール済み製品に対応するクライアントを選びます。--password の後ろに値を付けず安全なプロンプトを使います。短いオプションへ秘密を連結したり、値付き長形式やパスワード環境変数を使ったりしないでください。

mysql --host=REPLACE_WITH_APPROVED_HOST --user=REPLACE_WITH_ADMIN_USER --password
mariadb --host=REPLACE_WITH_APPROVED_HOST --user=REPLACE_WITH_ADMIN_USER --password

この二つは製品別の分岐で、順番に試す命令ではありません。接続後、サーバーの身元を読み取り専用で確認します。CURRENT_USER() は実際に一致した権限アカウント、USER() はクライアントが提示した身元です：

SELECT CURRENT_USER(), USER(), @@version, @@version_comment, @@hostname, @@port;

完全な 'user'@'host' を記録します。'root'@'localhost'、'root'@'127.0.0.1'、別の host 部分を持つアカウントは別物です。host の省略は広い既定値を意味し得るため、変更文では省略しません。ローカル socket、TCP、プロキシ、マネージドエンドポイントのどれかを確認し、TLS 要件も照合します。

2. ハッシュを出さず製品、版、認証プラグインを識別する

すべての認証プラグインがパスワードを保存するわけではありません。秘密でないメタデータだけを取得し、認証文字列やパスワードハッシュを表示し得る文は実行・共有しません。

MySQL 8.0/8.4 の承認済みローカル管理者は、対象アカウントの非秘密フィールドを確認できます：

SELECT User, Host, plugin, account_locked, password_expired
FROM mysql.user
WHERE User = 'root';

MariaDB 10.4+ は mysql.global_priv を使います。次のクエリは認証文字列を返さずプラグイン名だけを抽出します：

SELECT User,
       Host,
       JSON_UNQUOTE(JSON_EXTRACT(Priv, '$.plugin')) AS primary_plugin,
       JSON_EXTRACT(Priv, '$.auth_or[*].plugin') AS alternate_plugins
FROM mysql.global_priv
WHERE User = 'root';

版、列、JSON 構造が一致しない場合、構文を推測せず、その正確な版の公式資料または事業者メタデータを使います。MariaDB 10.4+ は一アカウントに複数の認証方式を設定でき、誤った ALTER USER 形式は unix_socket など既存方式を削除し得ます。

3. socket 認証を識別し、パスワードを強制しない

Ubuntu パッケージの MySQL は一般に 'root'@'localhost' に auth_socket を使い、MariaDB 10.4+ のシステム導入は一般に unix_socket を使います。これはローカル OS 身元を認証するもので、「root パスワードが空」という意味ではありません。承認済み Ubuntu 管理セッションから、実際の製品に合うローカル socket 接続を選びます：

sudo mysql --protocol=socket --user=root
sudo mariadb --protocol=socket

この経路が機能し運用要件を満たすなら、古い記事に合わせてプラグインを切り替えず維持します。リモート管理は管理された踏み台、VPN、Session Manager、DB 事業者経路を通ってローカル管理経路へ到達させます。リモート root、'root'@'%'、公開インターネットへの管理ポート公開は行いません。

4. 既知の認証情報を管理された方法でローテーションする

以下の SQL は認証済み・監査済みの管理セッション専用です。承認された秘密管理で生成・配送された値に置き換え、実際の文をログへ出力しないでください。MySQL クライアントは通常 IDENTIFIED/PASSWORD を含む履歴を除外しますが、クライアント履歴、general log、監査プラグイン、プロキシのログ方針も確認します。

MySQL 8.0/8.4

正確なアカウントが対応するパスワード型プラグインを使用すると証明した場合だけ、版に合う ALTER USER を使います。新しいプラグインを指定しないことで意図しない切替を避けます：

ALTER USER 'root'@'localhost'
  IDENTIFIED BY 'REPLACE_WITH_NEW_SECRET';

MySQL 8.0.14+ は二重パスワードに対応しますが、プラグイン、権限、方針の制約があります。実際に旧秘密を使う利用者がおり、廃止手順を演習済みの場合だけ、段階移行で旧パスワードを保持します：

ALTER USER 'root'@'localhost'
  IDENTIFIED BY 'REPLACE_WITH_NEW_SECRET'
  RETAIN CURRENT PASSWORD;

全利用者の切替と観察期間の完了後、同じ正確なアカウントから第二パスワードを廃止します：

ALTER USER 'root'@'localhost' DISCARD OLD PASSWORD;

便宜のためパスワード方針を無効にしないでください。有効期限、履歴、再利用制限、失敗ロックを設定する前に、MySQL の版、全体方針、緊急用アカウント、クライアントの期限切れパスワード対応を確認し、唯一の管理者をロックアウトしないようにします。

MariaDB

MariaDB の構文と複数プラグイン動作は MySQL と互換ではありません。対象が単一の対応パスワード認証アカウントであり、正確な MariaDB 版の資料で必要な動作が保持されると確認できた場合だけ実行します：

ALTER USER 'root'@'localhost'
  IDENTIFIED BY 'REPLACE_WITH_NEW_SECRET';

unix_socket または複数認証方式を使う MariaDB root へ適用しないでください。認証経路を変更・削除する可能性があります。その版の担当 DBA が公式 ALTER USER 資料に従い、完全な認証規則を保持します。

5. アプリと phpMyAdmin に root を使わせない

アプリ用の個別アカウントを作り、必要な schema 操作だけを許可します。以下はローカル単一 DB の読み書き例にすぎません。実需要まで権限を減らし、host を確認し、安全な SQL 入力経路でプレースホルダーを置換します。

CREATE USER 'app_user'@'localhost'
  IDENTIFIED BY 'REPLACE_WITH_APP_SECRET';
GRANT SELECT, INSERT, UPDATE, DELETE
  ON app_database.*
  TO 'app_user'@'localhost';

グローバル権限や WITH GRANT OPTION を与えないでください。phpMyAdmin は cookie または組織が承認した認証モードを使い、操作者自身の DB 身元を入力させます。config.inc.php に root パスワードを固定しません。設定ストレージ用の control user が必要でも、それは専用の低権限アカウントであり管理者の代替ではありません。

Apache Friends は XAMPP を開発環境と明記しています。XAMPP コンソールで同梱エンジンと版を確認してから、そのエンジンの公式手順に従います。DB と phpMyAdmin はローカルホストだけから到達可能にします。古いバンドルで root が空パスワードだったとしても、現在の導入や本番基準の証拠にはなりません。

6. 検証、利用者の切替、ロールバック期間の終了

まず新しいセッションを開き、正確な身元と読み取り専用操作を確認してから、必要最小限の管理能力を検証します：

mysql --host=REPLACE_WITH_APPROVED_HOST --user=root --password --execute='SELECT CURRENT_USER(), 1;'
mariadb --host=REPLACE_WITH_APPROVED_HOST --user=root --password --execute='SELECT CURRENT_USER(), 1;'

ここでも製品に応じて一方を選びます。続いて認証済み SQL セッションから権限基準を確認します。出力はアカウント構成を漏らす可能性があるため、管理された監査記録に保存し、共有前に編集します：

SHOW GRANTS FOR 'root'@'localhost';

棚卸しに沿って秘密管理と各利用者を更新し、管理された再接続を発生させ、認証失敗、プール、レプリケーション/バックアップ/監視、アプリ正常性を確認します。DB 再起動をパスワード修復として扱わないでください。アカウント管理文は新しい接続へ反映され、再起動は正確な公式復旧または設定変更手順が要求する場合だけです。

ロールバックには維持した復旧経路と承認済みの新たな認証情報変更を使い、古い設定ファイルやログから回収したパスワードは使いません。MySQL の二重パスワードでは全利用者の検証まで旧パスワードを保持し、観察期間後に DISCARD OLD PASSWORD を実行します。時刻、操作者、正確なアカウント、製品/版、理由、利用者状態、旧秘密の破棄証明を記録しますが、秘密やハッシュは記録しません。

7. 管理者アクセス喪失：停止して公式復旧へ進む

有効な管理者セッションが残っていない場合、このガイドは意図的に起動フラグ、権限迂回、システムテーブル変更の手順を提供しません：

• マネージド DB：事業者のコントロールプレーンでマスターユーザーをリセット/ローテーションし、即時適用、フェイルオーバー、プロキシ、レプリカ、秘密管理の動作を確認します。Amazon RDS などは、アプリがマスターユーザーを直接使わないよう明記しています。
• 自己管理 MySQL：正確なメジャー版、OS、パッケージ元、サービス管理方式に一致する MySQL 公式 root 復旧資料を選び、停止時間、ネットワーク隔離、一時資料の保護、監査影響を管理します。
• 自己管理 MariaDB：まず承認済みローカル unix_socket 身元が使えるか判断し、使えなければその版の担当 DBA が MariaDB/ディストリビューションの公式復旧手順に従います。
• Ubuntu：まずパッケージ標準の auth_socket/unix_socket 経路を確認します。パスワード拒否だけでは管理者アクセス喪失を意味しません。
• XAMPP：隔離されたローカル開発機だけで、正確な XAMPP リリースと同梱エンジンに合う Apache Friends/ベンダーの復旧説明を使います。重要データなら先にデータディレクトリと設定をバックアップします。

一般的な skip-grant-tables 手順をコピーしないでください。これは権限システムを迂回し、隔離、起動、文の順序、後始末が製品、版、プラットフォームで異なります。mysql.user や mysql.global_priv を直接編集せず、認証ハッシュを貼り付けず、phpMyAdmin でシステムテーブルを編集しません。

停止してエスカレーションする条件

• 対象製品、正確な版、'user'@'host'、認証プラグイン、接続経路を証明できない；
• 唯一の管理者が socket、PAM、LDAP、証明書、MFA、MariaDB 複数プラグイン認証を使い、計画がプラグインを変更する；
• 復旧点、復旧経路、メンテナンス承認、利用者一覧がない；
• レプリケーション、クラスター、プロキシ、マネージドコントロールプレーン、構成管理が変更を上書きする；
• 新パスワードが方針違反、クライアントが現在のプラグイン非対応、検証が本番通信に影響する；
• 引数、ログ、出力、チケット、チャットで秘密またはハッシュを公開する必要がある。

公式資料

• MySQL 8.4：`ALTER USER`
• MySQL 8.0：`ALTER USER`
• MySQL 8.4：アカウント名とパスワード
• MySQL 8.4：プラガブル認証
• MySQL 8.4：パスワード管理
• MySQL 8.4：パスワードとログ
• MySQL 8.0：公式 root パスワード復旧入口
• MariaDB：`ALTER USER`
• MariaDB：`unix_socket` 認証プラグイン
• MariaDB 10.4+：認証モデル
• Ubuntu Server：MySQL の導入と設定
• phpMyAdmin：ユーザー管理
• phpMyAdmin：導入と認証モード
• Apache Friends：XAMPP Windows FAQ
• Apache Friends：XAMPP Linux FAQ
• Amazon RDS：マスターユーザーのベストプラクティス
• Amazon RDS：Secrets Manager によるマスター認証情報管理

2011 年の原文資料（現行手順ではありません）

以下に source_export の可視本文を完全に保持し、行末空白だけを正規化しています。他の変更はありません。安全でないコマンドラインのパスワード渡し、空パスワードの想定、phpMyAdmin によるシステムテーブル編集、失効した HTTP 画像、廃止された関数を含むため、歴史資料としてのみ扱い、実行しないでください。

如何修改 MySQL 用户 root 的密码

由于在创建 CONFIG 文件的时候需要输入 MySql 的用户和密码，默认用户是 root，而密码为空。很多朋友都在询问如何修改 root 的密码，以避免安全问题。其实修改密码非常简单。

方法1：
 命令行方式下输入：
 xamppmysqlbinmysqladmin -u root password(你原来的密码)
 即把数据库恢复为你原来的密码

方法2：

下面以本地服务器为例给大家提供一下步骤以供参考：

1. 在浏览器上输入 http://localhost/phpmyadmin/ 进入数据库管理界面。

2. 在左边数据库选择框内选择 mysql 数据库。然后在右边的数据库表的底部选择浏览 USER 表。
[![select-mysql](http://earn.yesmall.biz/wp-content/uploads/auto_save_image/2011/08/042805ISr.jpg)](http://earn.yesmall.biz/wp-content/uploads/auto_save_image/2011/08/042805ISr.jpg)

3. 选择修改用户 root 的密码。
[![edit](http://earn.yesmall.biz/wp-content/uploads/auto_save_image/2011/08/042807Joj.jpg)](http://earn.yesmall.biz/wp-content/uploads/auto_save_image/2011/08/042807Joj.jpg)

修改密码时在 FUNCTION 一栏需选择 PASSWORD

[![modify](http://earn.yesmall.biz/wp-content/uploads/auto_save_image/2011/08/042808Cj0.jpg)](http://earn.yesmall.biz/wp-content/uploads/auto_save_image/2011/08/042808Cj0.jpg)

密码修改好以后用户再创建 CONFIG 文件，或者使用 MYSQL 数据库时就需要输入新密码了。