MySQL データベースのセキュリティ

JPKODA 編集部 May 11, 2026

データベースのセキュリティとは、アクセス権限を制限し、必要不可欠な人員のみにアクセスを許可することで、データの完全性（Integrity）、機密性（Confidentiality）、および可用性（Availability）を保護するプラクティスです。デフォルト設定や「オープンな」構成に依存することは、意図しないデータの削除、悪意のある改ざん、または不正なデータ漏洩のリスクを増大させます。

1. 最小特権の原則 (PoLP)

最も効果的なセキュリティポリシーは、最小特権の原則（Principle of Least Privilege：PoLP）です。これは、すべてのユーザー、アプリケーション、またはサービスが、特定のタスクを実行するために必要な最小限の権限のみを保持すべきであるという概念です。

例えば、ある Web アプリケーションがプロダクトリストの読み取り（Read）のみを必要とする場合、そのデータベースのユーザーアカウントはテーブルの DROP やユーザー認証情報（Credential）の UPDATE 権限を持つべきではありません。権限のスコープを制限することで、特定のアカウントが侵害（クラッキング）された際に生じる被害を最小限に抑えることができます。

2. スコープを制限したアクセスの実装

アプリケーションの接続に root アカウントを使用してはなりません。代わりに、特定の機能に特化した専用ユーザーを作成すべきです。

-- 特定のホストに限定されたユーザーを作成する
CREATE USER 'web_app_user'@'localhost' IDENTIFIED BY 'Strong_Password_123!';

-- 特定のデータベースに対する SELECT 権限のみを付与する
GRANT SELECT ON world.* TO 'web_app_user'@'localhost';

-- 変更を即座に適用する
FLUSH PRIVILEGES;

3. ネットワークと認証のセキュリティ

MySQL サーバーは通常、アプリケーション層（Application Layer）の背後に配置されますが、依然としてネットワーク境界（Network Boundary）において保護されなければなりません。

ネットワークの分離（Network Isolation）： 多くのインストール環境では、デフォルトですべてのネットワークインターフェースをリッスン（Listen）するようになっています。リモートアクセスの要件がない場合は、ローカルインターフェース（127.0.0.1）のみをリッスンするようにサーバーを構成すべきです。あるいは、ファイアウォール（ufw や iptables など）を使用して、アクセスをアプリケーションサーバーの特定の IP アドレスに制限します。
認証情報の管理（Credential Management）： 認証（Authentication）のセキュリティはパスワードの複雑さから始まりますが、それらのパスワードをどのように取り扱うかも含まれます。ソースコード内に認証情報をハードコーディング（Hardcoding）することは厳禁です。環境変数（Environment Variables）またはセキュアな構成管理（Configuration Management）ツールを使用して、ランタイム（Runtime）時に認証情報をインジェクト（Inject）すべきです。

4. 匿名アクセスとテストデータベースの排除

デフォルトの MySQL インストールでは、通常「匿名（Anonymous）」ユーザーと、誰もが認証なしでアクセスできる test データベースが作成されます。これらは、不正なプロービング（探索）の潜在的なエントリーポイントとなります。

-- 匿名ユーザーを削除する
DROP USER ''@'localhost';
DROP USER ''@'hostname';

-- テストデータベースを削除する
DROP DATABASE IF EXISTS test;

5. データの暗号化と監査 (Auditing)

保存データの暗号化（Encryption at Rest）： データベースファイルが物理的に盗まれた場合（例えば、パブリックサーバー上に暗号化されていないバックアップファイルが放置されていた場合など）でも、データが読み取れない状態を確保します。MySQL が提供する透過的データ暗号化（TDE：Transparent Data Encryption）に加えて、最も基礎的なセキュリティレイヤーは、ファイルシステムの権限を制限し、mysql オペレーティングシステムユーザーのみがデータディレクトリを読み取れるようにすることです。
監査（Auditing）： 誰が、いつ、何にアクセスしたかをトラッキングすることを含みます。フルセットの監査ログはパフォーマンスに影響を与える可能性がありますが、インシデント後の分析において、一般クエリログ（General Query Log）やエラーログを有効にすることは極めて重要です。

不正なアクセス試行のフロー：

認証情報は有効か？

いいえ → コネクションを拒否し、IP アドレスをログに記録する。
はい → 続行。

必要な権限を保持しているか？

いいえ → クエリを拒否し、エラーをログに記録する。
はい → クエリを実行する → オペレーションを監査証跡（Audit Trail）に記録する。

6. セキュアなバックアップのプラクティス

バックアップは、セキュリティチェーンにおいて最も脆弱なリンクになりがちです。暗号化されていないバックアップは、データベース全体の単なるプレーンテキストのコピーに過ぎません。mysqldump などのツールを使用してデプロイする際は、以下の点を確保してください：

アクセスの制限（Restricted Access）： 厳格なファイルシステム権限を持つ暗号化されたディレクトリにバックアップをストレージします。
暗号化ストレージ（Encrypted Storage）： クラウド（Amazon S3 など）に保存する場合、ファイルはマネージドキー（Managed Keys）を使用して暗号化されなければなりません。
転送のセキュリティ（Transport Security）： データベースのダンプファイルは、暗号化トンネル（SSH / TLS など）を通じて転送すべきであり、通常の FTP や暗号化されていない HTTP 経由で転送しては絶対にいけません。