ユーザー関連のSQLです。

項目を選択してください。

子ページから目的の操作を選ぶ

• ユーザー作成：OracleのPDB/CREATE USERとログイン権限
• ユーザー定義変更：元のOracleの説明と、保持したMySQLの教材を製品別に確認
• ユーザー削除：Oracleの接続/所有オブジェクト/CASCADEの影響

これはSQL→DDL→ユーザー関連の親ページです。上の3記事が実際の子ページで、順序や親を変えていません。以下は製品比較の参考情報です。同名のSQL文でも構文/識別子/権限/影響は異なるため、一つの実行スクリプトとして使いません。

アカウント・権限・接続を分けて確認する

アカウント作成、ログイン権限、表の操作権限、接続済みセッションの扱いは別です。OracleのPDBローカルユーザーとMySQLのUser/Hostを混同せず、OracleでCONNECT/RESOURCEを一括付与することを最小構成とは扱いません。必要な権限を個別に確認し、ロールの内容も対象版/実環境で調べます。

Oracleの読取り例は次の通りです。製品と接続済みPDB/ユーザーを確認するためのもので、管理権限を新たに付与する命令ではありません。MySQL/PostgreSQL/SQL Serverへそのまま貼り付けません。

-- Read only. Confirm the intended product, PDB service and authorized account.
SELECT USER, SYS_CONTEXT('USERENV','CON_NAME') AS container_name FROM dual;
SELECT privilege FROM user_sys_privs ORDER BY privilege;

変更には、既存アプリの保管する資格情報と接続プールの更新計画も必要です。パスワード変更やロックが既存セッションを必ず終了させるとは考えず、新しい接続の結果を別に確認します。削除には別スキーマの依存、バックアップ/復旧手順と承認が必要で、CASCADEを「エラーを消すオプション」としません。

製品比較の読み方

MySQLとMariaDBは認証や権限を全版共通には扱いません。通常のCREATE USER/GRANT等に念のためのFLUSHは不要で、旧認証への差し戻しを通常対処にしません。PostgreSQLのdefault privilegesは対象となる作成ロールやschema、将来/既存のオブジェクトを分けて確認します。SQL Serverもloginに紐付くuserの例が全方式ではなく、contained user等があります。

以下のコードは既存の比較資料として保持し、危険な全権限/資格情報直書き/重複作成や対象順序を各例の直前でも訂正します。今回これら4製品の全例を新しく実行確認したわけではありません。新しい実行検査はOracleの隔離検体に限定しています。

既存の製品別比較と注意

比較例の注意：製品別の概要です。CONNECT/RESOURCE一括付与やSQL Server全方式の二段階必須という誤記はセル内も訂正しています。

この記事の要点

アカウントと権限管理: CREATE USER / ALTER USER / DROP USER / GRANT / REVOKE が基本 MySQL: CREATE USER 'name'@'host' IDENTIFIED BY 'pw' 形式、ホスト指定がユーザー識別子の一部 PostgreSQL: CREATE ROLE がベース、CREATE USER は LOGIN 属性つきの別名 Oracle: PDB/対象を確認し、CREATE USERと必要なログイン/操作権限を個別に設計 SQL Server: loginに対応するuserの方式がある。contained user等は別条件

SQL のユーザー管理 DDL の概要

RDBMS には「誰が接続して、何ができるか」を管理する仕組みがあり、アカウントの作成/属性変更/削除と、GRANT/REVOKEによる権限管理を分けます。全製品でこれらを同一のDDL分類とする意味ではありません。基本となるコマンドは以下の 5 つです。

• CREATE USER: ユーザー作成
• ALTER USER: パスワード変更、属性変更
• DROP USER: ユーザー削除
• GRANT: 権限付与
• REVOKE: 権限剥奪

ただし細かい構文は DB ごとに大きく異なるため、本記事では主要 4 DB（MySQL / PostgreSQL / Oracle / SQL Server）の差を整理します。

MySQL / MariaDB のユーザー管理

ユーザーの作成と削除

比較例の注意：別hostの3つは別アカウントの例で、まとめて作る推奨ではありません。%はネットワーク/firewallを自動開放する意味ではなく、範囲を広げて認証失敗を直しません。公開パスワードを使わず、mysql.userには読取権限が必要です。

-- ユーザー作成: 'ユーザー名'@'接続元ホスト' が識別子
CREATE USER 'app_user'@'localhost' IDENTIFIED BY 'StrongP@ss1';
CREATE USER 'app_user'@'%'         IDENTIFIED BY 'StrongP@ss1';  -- どこからでも
CREATE USER 'app_user'@'192.168.1.%' IDENTIFIED BY 'StrongP@ss1';  -- 特定セグメント

-- 一覧確認
SELECT user, host FROM mysql.user;

-- パスワード変更
ALTER USER 'app_user'@'localhost' IDENTIFIED BY 'NewP@ss2';

-- ユーザー削除
DROP USER 'app_user'@'localhost';

権限付与・剥奪

比較例の注意：ALL ON *.*とWITH GRANT OPTIONは広い影響を持ち、アプリ/読取ユーザーへ与えません。readonlyという名前でもINSERT権限の例があります。通常のCREATE USER/GRANT/ALTER USERで念のためのFLUSHは不要です。

-- 全 DB の全テーブルに全権限 (管理者)
GRANT ALL PRIVILEGES ON *.* TO 'admin'@'localhost' WITH GRANT OPTION;

-- 特定 DB の全テーブル
GRANT ALL PRIVILEGES ON shopdb.* TO 'app_user'@'%';

-- 特定テーブルの SELECT / INSERT のみ
GRANT SELECT, INSERT ON shopdb.orders TO 'readonly'@'%';

-- カラム単位の SELECT
GRANT SELECT (id, name) ON shopdb.users TO 'limited'@'%';

-- 反映
FLUSH PRIVILEGES;   -- ALTER 系では自動で反映、念のため

-- 権限確認
SHOW GRANTS FOR 'app_user'@'%';

-- 権限剥奪
REVOKE INSERT ON shopdb.orders FROM 'readonly'@'%';

認証プラグイン (MySQL 8.0)

MySQL 8.0 では既定の認証プラグインが caching_sha2_password に変わり、クライアントの対応版/認証方式/TLS等を確認する必要があります。

比較例の注意：mysql_native_passwordへの差し戻しは通常対処にしません。8.4は既定無効/9.0は削除で、pwは公開された弱い値です。MySQLとMariaDBや各版の認証を一律に扱いません。

-- プラグイン指定の作成
CREATE USER 'old_app'@'%'
  IDENTIFIED WITH mysql_native_password BY 'pw';   -- 旧互換

CREATE USER 'new_app'@'%'
  IDENTIFIED WITH caching_sha2_password BY 'pw';   -- 推奨（8.0 既定）

-- 既存ユーザーの認証方式を切替
ALTER USER 'old_app'@'%'
  IDENTIFIED WITH caching_sha2_password BY 'pw';

PostgreSQL のユーザー管理

PostgreSQL ではロールがユーザー / グループ両方を表す概念です。CREATE USER は CREATE ROLE ... LOGIN のシンタックスシュガーです。

比較例の注意：CREATE USERと同義のCREATE ROLEは二者択一で、連続実行すると重複になります。SUPERUSERをアプリへ与えず、公開パスワードを使いません。\duはpsqlのメタコマンドです。

-- ユーザー（ログイン可能なロール）作成
CREATE USER app_user WITH PASSWORD 'StrongP@ss1';
-- 同義
CREATE ROLE app_user LOGIN PASSWORD 'StrongP@ss1';

-- スーパーユーザー
CREATE ROLE admin SUPERUSER LOGIN PASSWORD 'StrongP@ss1';

-- 一覧確認
\du
SELECT rolname, rolsuper, rolcanlogin FROM pg_roles;

-- パスワード変更
ALTER USER app_user WITH PASSWORD 'NewP@ss2';

-- 接続制限
ALTER USER app_user CONNECTION LIMIT 50;

-- 削除
DROP USER app_user;

権限付与

比較例の注意：readonly_roleは使用前に存在させる必要があり、下のまま初期化から順次実行できません。DEFAULT PRIVILEGESは対象作成ロール/schemaの将来オブジェクト用で、既存表や全所有者の権限を一括変更しません。ロール継承条件も確認します。

-- DB レベルの権限
GRANT CONNECT ON DATABASE shopdb TO app_user;

-- スキーマレベル
GRANT USAGE ON SCHEMA public TO app_user;

-- テーブルレベル
GRANT SELECT, INSERT ON public.orders TO app_user;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO app_user;

-- 今後作るテーブルにも自動付与
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO readonly_role;

-- ロールベース（グループロール）
CREATE ROLE readonly_role;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly_role;
GRANT readonly_role TO app_user;   -- app_user は readonly_role の権限を継承

-- 権限剥奪
REVOKE INSERT ON public.orders FROM app_user;

Oracle のユーザー管理

比較例の注意：CONNECTが表作成等を全て持つという旧コメントを採用しません。ロールの実権限を確認し、必要なCREATE SESSION/個別権限とquotaを設計します。無制限quota/DBA/CASCADEを通常の接続修復に使わず、PDBを確認します。

-- ユーザー作成
CREATE USER app_user IDENTIFIED BY "StrongP@ss1"
  DEFAULT TABLESPACE users
  TEMPORARY TABLESPACE temp
  QUOTA UNLIMITED ON users;

-- 基本権限の付与（事前定義ロール）
GRANT CONNECT, RESOURCE TO app_user;
-- CONNECT  : セッション作成、テーブル作成等
-- RESOURCE : オブジェクト作成権限
-- DBA      : ★ 強力すぎるので注意

-- 個別権限
GRANT SELECT, INSERT ON hr.employees TO app_user;
GRANT CREATE TABLE TO app_user;
GRANT CREATE SESSION TO app_user;   -- 接続権

-- パスワード変更
ALTER USER app_user IDENTIFIED BY "NewP@ss2";

-- ロック / アンロック
ALTER USER app_user ACCOUNT LOCK;
ALTER USER app_user ACCOUNT UNLOCK;

-- 削除（所有オブジェクトもまとめて削除）
DROP USER app_user CASCADE;

-- 一覧
SELECT username, account_status, created FROM dba_users;

SQL Server のユーザー管理

SQL Serverにはログインと対応するDBユーザーを使う方式があります。contained user等を含む全方式でログイン作成が必須という意味ではありません。同じ名前で対応付けるのが一般的ですが、別名にもできます。

比較例の注意：login対応userの例で、contained user等は別です。Windows/SQL認証は選択肢で、広いschema権限やdb_datawriterを一括付与しません。ユーザー/ログインの削除を一覧確認とまとめて実行しません。

-- 1. ログインを作成（master DB で）
USE master;
CREATE LOGIN app_login WITH PASSWORD = 'StrongP@ss1';
-- Windows 認証の場合
CREATE LOGIN [DOMAIN\app_user] FROM WINDOWS;

-- 2. 各 DB でユーザーを作成し、ログインに紐付け
USE shopdb;
CREATE USER app_user FOR LOGIN app_login;

-- 3. 権限付与
GRANT SELECT, INSERT, UPDATE, DELETE ON SCHEMA::dbo TO app_user;

-- 既定のロール
ALTER ROLE db_datareader ADD MEMBER app_user;   -- 読み取り
ALTER ROLE db_datawriter ADD MEMBER app_user;   -- 書き込み

-- パスワード変更
ALTER LOGIN app_login WITH PASSWORD = 'NewP@ss2';

-- ログイン無効化
ALTER LOGIN app_login DISABLE;

-- 削除（順序に注意）
USE shopdb;  DROP USER app_user;
USE master;  DROP LOGIN app_login;

-- 一覧
SELECT name, type_desc, is_disabled FROM sys.server_principals;
SELECT name, type_desc FROM sys.database_principals;

権限の最小化（最小権限の原則）

セキュリティの観点では、アプリケーションが使う DB ユーザーには業務に必要な最小限の権限のみを与えるのが鉄則です。

比較例の注意：役割ごとの必要性を設計する表です。CRUD/TRUNCATE/DDL/監視ビュー権限を名前だけで自動付与する規則ではありません。

役割	典型的な権限
アプリ DB ユーザー（業務用）	業務に必要な操作/対象だけ。CRUDの全部が必須でも、全アプリでDDL不要でもない
レポート / BI 用	必要な参照対象に限定。接続/schema等の条件も製品別に確認
バッチ管理者	ジョブごとに必要な操作を設計。TRUNCATE/一時表権限を一律追加しない
マイグレーション用	承認された変更だけを別の権限/配備方針で実施。全製品共通の固定運用ではない
監査 / 監視	必要な監視情報への権限を製品/版別に確認。ビューSELECTだけとは限らない

ロール / グループの活用

ユーザーが増えると個別に GRANT するのは破綻します。役割ごとにロールを作り、ロールに権限を付与し、ユーザーをロールに所属させるのが定番です。

比較例の注意：bob/aliceや対象DB/schemaは存在が前提です。実行者/メンバーシップと継承条件を確認し、新規/既存オブジェクトの権限を区別します。

-- PostgreSQL の例
CREATE ROLE app_reader;
GRANT CONNECT ON DATABASE shopdb TO app_reader;
GRANT USAGE ON SCHEMA public TO app_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO app_reader;

CREATE ROLE app_writer;
GRANT app_reader TO app_writer;       -- 読み権限を継承
GRANT INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_writer;

-- ユーザーを所属させる
GRANT app_reader TO bob;
GRANT app_writer TO alice;

パスワードポリシー

比較例の注意：機能の存在と実際の導入/有効化は別です。認証方式とパスワード検証を混同せず、PROFILEの複雑性は検証関数等も確認します。

DB	機能
MySQL 8.0	validate_password コンポーネント、policy=LOW/MEDIUM/STRONG
PostgreSQL	passwordcheck等と認証設定を区別。SCRAM-SHA-256をLDAP等と同じ外部認証とは扱わない
Oracle	PROFILEの期限/履歴/試行等とPASSWORD_VERIFY_FUNCTIONによる複雑性検証を分ける
SQL Server	Windows パスワードポリシー継承 (CHECK_POLICY = ON)

運用のベストプラクティス

1. 本番 DB の root / sa / postgres は直接アプリから使わない
2. アプリごとに専用ユーザー、本番 / ステージング / 開発で別アカウント
3. パスワードは シークレットマネージャ（AWS Secrets Manager、HashiCorp Vault）で管理
4. ユーザー作成 / 削除は IaC（Terraform / Ansible / Flyway 等） で履歴を残す
5. 定期的に 未使用ユーザーの棚卸し とパスワードローテーション
6. 監査ログ（MySQL Audit / Oracle Unified Auditing / SQL Server Audit）でアクセス記録

FAQ

Q: MySQL で同じユーザー名で host が違うのは別アカウント？
A: はい、'app'@'localhost' と 'app'@'%' は完全に別アカウントです。必要なアカウントだけを設計します。両方の作成や%への範囲拡大を勧める意味ではありません。

Q: PostgreSQL の ROLE と USER の違いは？
A: ROLE が上位概念で、USER は LOGIN 属性つきの ROLE のエイリアスです。CREATE USER = CREATE ROLE LOGIN。

Q: SQL Server のログインとユーザーを別名にする理由は？
A: 本番と検証で同じ DB スクリプトを動かすため、DB ユーザー名を固定にしてログイン名だけ環境ごとに変えたい場合などに利用します。

Q: アプリのパスワードを変えたら接続できなくなった
A: 接続済みセッションはパスワード変更だけで再認証されるとは限りません。新規接続の資格情報/接続先とアプリ側の秘密値を照合し、接続プールの更新を計画します。一律の再起動や全切断を最初の対処にしません。

確認範囲と関連ページ

2026年10月26日確認。新しいOracle例はOracle AI Database 26ai Free 23.26.3.0.0の隔離PDBで、公開された検体アカウント/パスワードと新規データだけを使って検査しました。ロック/パスワードと既存接続、既定表領域とquota、権限不足、空ユーザー/接続中/所有物ありの削除、別スキーマの外部キー/ビューとROLLBACKの結果を確認しています。実運用のバックアップ復元、RAC/ASM、全認証方式/全DB版やMySQL/PostgreSQL/SQL Serverの全比較例を今回実行したものではありません。本番DBのユーザー/認証/権限/表領域は変更していません。

ユーザー関連の親ページから子ページを選択できます。Oracleのユーザー作成、ユーザー定義変更、Oracleのユーザー削除を操作別に参照してください。

一次資料：Oracle ALTER USERの権限とPDB/属性、Oracle DROP USERの権限・CASCADEと制限、MySQL 8.4 ALTER USER、PostgreSQLの将来オブジェクトの権限、SQL Serverのユーザー種類。