なぜ「SHOW GRANTS」だけでは不十分なのか
DBAとして運用に携わっていると、セキュリティ監査や棚卸しのタイミングで「全ユーザーの権限一覧を出してほしい」と依頼されることがよくあります。多くのエンジニアは、まず各ユーザーに対して「SHOW GRANTS FOR ‘user’@’host’;」を個別に実行しようとします。しかし、ユーザー数が数十名を超えると、この手動作業は非効率なだけでなく、情報の見落としという致命的なリスクを伴います。実務において最も怖いのは、退職者のアカウントや、検証用に一時的に付与した「GRANT ALL」が放置されている状況です。
システムテーブルを直接クエリする効率的なアプローチ
MySQLを例に挙げると、権限情報は「mysql.user」や「mysql.db」といったシステムテーブルに格納されています。これらを統合的にクエリすることで、権限の可視化を自動化できます。例えば、特定のデータベースに対するアクセス権を横断的に確認したい場合、以下の視点を持つことが重要です。
まず、「mysql.db」テーブルを結合して、どのユーザーがどのDBにアクセスできるかを一覧化するクエリを作成します。ここで注意すべきは、ワイルドカード（%）によるホスト指定です。現場では「ユーザー名が同じでもホストが異なるために意図しない権限が付与されていた」という事例が頻発します。必ず「user」と「host」のペアで権限を管理・抽出する習慣をつけましょう。
「権限の肥大化」を防止する実務的な運用ルール
権限管理で失敗しないために、私は以下の3つのルールをチームに徹底させています。
1. ロールベースアクセス制御（RBAC）の導入：個別のユーザーに直接権限を付与せず、役割に応じたロールを作成し、そこに権限を紐付けます。これにより、権限変更時の影響範囲を最小限に抑えられます。
2. クエリの定期的なエクスポート：週次や月次で、ユーザー権限情報をCSVとして出力し、構成管理ツール（Gitなど）で差分を追跡します。誰がいつ権限を変更したかが不明確な状態は、障害発生時の切り分けを極めて困難にします。
3. 「GRANT OPTION」の厳格な制限：権限を委譲できる「GRANT OPTION」は、開発環境であっても原則付与しません。この権限が漏れると、DBAの管理外で権限が拡散するリスクがあるからです。
まとめ：ツールに頼りすぎない「DBAの眼」を持つ
現在はクラウド環境のIAM管理など、便利なツールも増えています。しかし、データベースの内部構造を理解し、システムテーブルを直接操作して「生の情報」を確認できるスキルは、トラブルシューティングの最後の砦となります。
権限管理は地味な作業ですが、システムの堅牢性を守るための最も強力な防壁です。今回紹介したような「横断的な情報取得」をルーチン化し、「誰が、どこに、どのような権限を持っているか」を常に把握できている状態を目指しましょう。それが、DBAとしての信頼を構築する第一歩です。
コメント