第26回: 権限管理の基本（GRANT） — rootを共用し続けると何が起きるか

(Updated: )
1 min read

章: 第6章: セキュリティと本番運用

本番DBにアプリが root で接続していませんか？

開発環境の便利さそのままに、本番でも root ユーザーをアプリに使わせているケースがあります。この状態では、SQLインジェクション攻撃を受けた場合やアプリのバグでDROPが実行された場合に、データベース全体が被害を受けるリスクがあります。

最小権限の原則（Principle of Least Privilege） に従い、アプリに必要な操作だけを許可した専用ユーザーを作ることが、セキュリティ強化の第一歩です。

権限設計の比較：rootと最小権限ユーザー

観点 root共用 専用ユーザー（最小権限）
影響範囲 全データベース・全テーブル 対象DBのみ
事故時のリスク DROP TABLE・DROP DATABASEまで実行可能 許可した操作のみ
環境ごとの分離 不可（全環境同一） 本番・ステージング・開発で別ユーザー設定が可能
監査ログの活用 誰が何をしたか不明 ユーザーごとに操作を追跡しやすい
推奨度 非推奨（本番では使用しない） 推奨

チェックポイント: アプリユーザーに GRANT ALL PRIVILEGES を付与するのは root と同義です。SELECT, INSERT, UPDATE, DELETE の4つから始め、必要になった権限だけを追加する方針を取ってください。また、パスワードは強固な値を使い、.env ファイルで管理してリポジトリに含めないことを徹底してください。

実際のコードサンプル


CREATE USER 'app_user'@'%' IDENTIFIED BY 'strong_password';
GRANT SELECT, INSERT, UPDATE, DELETE ON blog_app.* TO 'app_user'@'%';
FLUSH PRIVILEGES;

まとめ & 次のステップ

  • 本番アプリには専用DBユーザーを作成し、rootの共用を廃止する
  • GRANT は必要最小限の操作のみ付与し、GRANT ALL は避ける
  • 環境（本番・ステージング・開発）ごとにユーザーを分離する
  • SHOW GRANTS FOR 'ユーザー名'@'ホスト'; で現在の権限を定期的に確認する
  • パスワードはランダムな強固な値を使い、バージョン管理に含めない

次回は SQLインジェクション対策 を学びます。文字列連結でSQLを組み立てる危険性と、プリペアドステートメントによる根本的な防御方法を解説します。

Related Articles