「とりあえず管理者権限」が招く長期的なリスク
データベース管理者として現場に立っていると、新規ユーザー作成の依頼で「とりあえず管理権限（SUPERUSERやDBA権限）を付与してほしい」という要望を耳にすることがあります。開発スピードを優先したい気持ちは理解できますが、実務においてこれは負債の始まりです。不要な権限を持つアカウントが放置されると、万が一のクレデンシャル流出時に被害がデータベース全体に拡大します。私は、ユーザー作成時は「スキーマ単位の権限」かつ「特定の操作（DMLのみなど）に限定する」ことを、DBAの譲れないラインとして運用しています。
「ユーザー作成」を属人化させない仕組み作り
個別の依頼ごとに手動でSQLを発行していると、どうしても「誰にどの権限を与えたか」という台帳管理が形骸化します。私の現場では、ユーザー作成をIaC（Infrastructure as Code）のプロセスに組み込んでいます。TerraformやAnsibleを用いて、Gitリポジトリ上でユーザー定義を管理するのです。これにより、「いつ、誰が、何の目的で作成したか」という監査ログがプルリクエストの履歴として自動的に残るようになります。手作業を排除することで、設定の打ち間違いというヒューマンエラーを防ぐのが最大の目的です。
退職者対応を見越した「ライフサイクル管理」
ユーザー作成時に見落とされがちなのが「削除のタイミング」です。作成時の承認フローは厳格でも、削除フローが曖昧なケースは非常に多いです。実務では、作成時に「有効期限（Expiration Date）」をメタデータとして付与するか、またはアプリケーションのサービスアカウントであれば、定期的なパスワードローテーションを強制する仕組みを併せて構築しています。
DBAとしての独自の視点：権限の「棚卸し」を習慣化する
最近導入して効果的だったのは、四半期ごとの「権限棚卸し会」です。作成したユーザーが現在もアクティブに使われているか、接続ログを確認し、長期間接続のないユーザーは即座に無効化（DROPではなくLOCK）します。いきなり削除して業務が止まるリスクを避けるため、まずはアカウントをロックして反応を待つという段階を踏むのが、現場の混乱を最小限に抑えるコツです。ユーザー作成とは単なるコマンド実行ではなく、運用という長い旅の始まりであることを、改めて意識してみてください。
コメント