Oracleデータベース ユーザー作成手順を解説 (CREATE USER)

By /

Oracleデータベース ユーザー作成手順解説：CREATE USERコマンド徹底詳解

はじめに

Oracleデータベースは、世界の多くの企業システムにおいて基幹を成す、堅牢で高機能なリレーショナルデータベース管理システム（RDBMS）です。このOracleデータベースを安全かつ効率的に利用するためには、ユーザー管理が不可欠です。ユーザーはデータベースへのアクセスポイントであり、データベース内のオブジェクト（テーブル、ビュー、プロシージャなど）を所有し、操作するための主体となります。適切なユーザー管理は、セキュリティの維持、リソースの効率的な利用、そしてデータベース運用の透明性を確保する上で、極めて重要な要素となります。

本記事では、Oracleデータベースにおいて新しいユーザーを作成するための基本的なコマンドであるCREATE USERに焦点を当て、その構文、詳細なオプション、利用例、そしてユーザー作成に関連する重要な概念やベストプラクティスについて、約5000語のボリュームで網羅的に解説します。単にコマンドの使い方を説明するだけでなく、なぜそのオプションが必要なのか、その設定がデータベースにどのような影響を与えるのかといった背景知識も深く掘り下げていきます。Oracleデータベースの管理者や開発者、あるいは学習者にとって、ユーザー管理の基礎を固め、より安全で効率的なデータベース運用を実現するための手助けとなることを目指します。

Oracleデータベースにおけるユーザーとは

Oracleデータベースにおける「ユーザー」とは、データベースに接続し、操作を行うためのアカウントです。各ユーザーは一意の名前を持ち、通常はパスワードまたは別の認証方法によって識別されます。ユーザーはデータベース内の特定の操作を実行するための権限を持ち、また自身が作成したオブジェクト（テーブルなど）の所有者となります。

ユーザーは「スキーマ」と密接に関連しています。Oracleデータベースでは、ユーザーを作成すると、そのユーザー名と同じ名前のスキーマが自動的に作成されます。スキーマは、そのユーザーが所有するデータベースオブジェクト（テーブル、ビュー、インデックス、ストアドプロシージャなど）の集合です。したがって、「ユーザー」はデータベースに接続する実体を指し、「スキーマ」はそのユーザーが所有するオブジェクトの名前空間を指す、と理解できます。多くの文脈では、ユーザー名とスキーマ名は同じであるため、これらはしばしば同義のように扱われますが、厳密には異なる概念です。例えば、あるユーザーが別のユーザーのスキーマに属するオブジェクトにアクセスする場合、そのオブジェクト名を[スキーマ名].[オブジェクト名]の形式で指定する必要があります。

Oracleデータベースには、システム運用に必要な標準ユーザーがいくつか存在します。代表的なものとしては、データベースの最高権限を持つSYSユーザーや、管理操作やデータディクショナリの多くを所有するSYSTEMユーザーがあります。これらの標準ユーザーは、通常のアプリケーションやユーザーが直接利用することは推奨されず、管理作業に限定して使用するのが一般的です。アプリケーションや一般ユーザーには、別途適切な権限を持つユーザーを作成して割り当てるべきです。

CREATE USERコマンドの基本構文

新しいデータベースユーザーを作成するための基本的なコマンドはCREATE USERです。その基本構文は以下の通りです。

sql
CREATE USER user
IDENTIFIED { BY password | EXTERNALLY | GLOBALLY AS 'external_name' }
[ DEFAULT TABLESPACE default_tablespace ]
[ TEMPORARY TABLESPACE temporary_tablespace ]
[ QUOTA { integer [ K | M | G | T | P | E ] | UNLIMITED } ON tablespace [, QUOTA ...] ]
[ PROFILE profile_name ]
[ ACCOUNT { LOCK | UNLOCK } ]
[ EXTERNAL NAME 'external_name' ];

この構文は多くのオプションを含んでいますが、必須なのは以下の部分です。

  1. CREATE USER user: 作成するユーザーの名前を指定します。ユーザー名は、データベース内で一意である必要があります。
  2. IDENTIFIED ...: ユーザーを認証する方法を指定します。これは以下のいずれかである必要があります。
    • IDENTIFIED BY password: パスワードによる認証。最も一般的です。
    • IDENTIFIED EXTERNALLY: オペレーティングシステム（OS）による認証（OS認証）。
    • IDENTIFIED GLOBALLY AS 'external_name': LDAPなどのディレクトリサービスを利用した認証（グローバルユーザー認証）。

これらの必須句に加え、ユーザーのデフォルト設定やリソース制限を定義するための様々なオプション句を指定できます。各句について、以下で詳細に解説します。

CREATE USERコマンドの詳細オプション

IDENTIFIED { BY password | EXTERNALLY | GLOBALLY AS 'external_name' }

この句は、ユーザーがデータベースに接続する際にどのように自身を認証するかを定義します。これはCREATE USER文において必須の句です。

1. IDENTIFIED BY password

これは最も一般的で広く利用されている認証方法です。ユーザーは接続時に指定されたパスワードを入力する必要があります。

  • password: 作成するユーザーに割り当てるパスワードを指定します。パスワードは、二重引用符で囲まなくても構いませんが、特定の文字（スペース、特殊文字など）を含む場合や、Oracleの予約語や識別子としての規則に反する場合は、二重引用符で囲む必要があります。セキュリティの観点から、推測されにくい、複雑なパスワードを設定することが強く推奨されます。大文字、小文字、数字、記号を組み合わせた、十分な長さ（例えば8文字以上）のパスワードを使用するべきです。

  • パスワード認証の仕組み: Oracleデータベースは、設定されたパスワードそのものをデータベース内に平文で保存することはありません。代わりに、パスワードのハッシュ値を計算し、そのハッシュ値を保存します。ユーザーが接続時にパスワードを入力すると、データベースは入力されたパスワードから同じハッシュ値を計算し、保存されているハッシュ値と比較します。両者が一致すれば認証成功となります。これにより、たとえデータベースの情報が漏洩しても、パスワードそのものが直接的に漏洩するリスクを低減しています。Oracleのバージョンによって使用されるハッシュアルゴリズムは異なりますが、よりセキュアなアルゴリズム（例: SHA-512）が新しいバージョンで採用されています。

  • パスワードのセキュリティ管理: パスワード認証を使用する場合、パスワードの管理がセキュリティの鍵となります。Oracleデータベースでは、ユーザーのパスワードポリシーを詳細に設定するための「プロファイル」という仕組みを提供しています。プロファイルを利用することで、パスワードの有効期限、再利用の制限、失敗ログイン回数の上限、パスワードの複雑性をチェックする検証関数の適用などを定義できます（詳細は後述のPROFILE句で解説）。これらの設定を適切に行うことで、パスワードに関するセキュリティリスクを大幅に軽減できます。

  • 例:
    sql
    CREATE USER myuser1
    IDENTIFIED BY mypassword123;
    この例では、myuser1という名前のユーザーを、パスワードmypassword123で作成しています。実際の運用では、より複雑で推測されにくいパスワードを使用してください。また、本番環境ではユーザー名とパスワードをSQLスクリプトに平文で含めることは避け、セキュアな方法で実行する必要があります。

2. IDENTIFIED EXTERNALLY

この認証方法は、Oracleデータベースの外部にある認証メカニズムを利用します。最も一般的なのはOS認証です。データベースに接続しようとするユーザーが、データベースサーバーが存在するOSにログインしていることを利用して認証を行います。

  • OS認証の仕組み: OS認証を利用するには、データベースサーバー上で特定のOSユーザーがログインしている必要があります。Oracleデータベースは、そのOSユーザー名とデータベースユーザー名を関連付けて認証を行います。デフォルトでは、OSユーザー名の先頭にOS_AUTHENT_PREFIXというデータベース初期化パラメータで指定されたプレフィックス（デフォルトはOPS$）を付加した名前が、対応するデータベースユーザー名とみなされます。例えば、OS_AUTHENT_PREFIXがOPS$で、OSユーザー名がorauserであれば、データベースはOPS$ORAUSERというユーザー名を検索します。

  • 設定方法:

    1. データベースサーバーOSに、対応するOSユーザーを作成します。
    2. Oracleデータベース内で、そのOSユーザー名に対応する（プレフィックス付きの）データベースユーザーをIDENTIFIED EXTERNALLY句を指定して作成します。
    3. データベースへの接続時に、パスワードではなくOS認証を利用することを指定して接続します（接続文字列で認証方法を指定するか、環境変数などで設定します）。

  • メリット: パスワード管理が不要になります。OSレベルでユーザーを管理するため、データベース管理者とOS管理者が連携することで、認証の一元化が図れる場合があります。自動化されたスクリプトなどからパスワードなしでデータベースに接続する場合に便利です。

  • デメリット: データベースサーバーのOSセキュリティに依存します。OSユーザーが侵害されると、対応するデータベースユーザーも侵害されるリスクがあります。また、クライアントから直接OS認証で接続するには、クライアント側にも特別な設定が必要になる場合があります。デフォルトのプレフィックス（OPS$）はセキュリティ上の懸念（総当たり攻撃の対象になりやすいなど）から、より推測しにくい名前に変更することが推奨される場合もあります。SQLNET.AUTHENTICATION_SERVICES=(OS)のように、クライアントまたはサーバー側のsqlnet.oraファイルで認証サービスとしてOS認証を有効にする設定が必要になる場合があります。

  • 例:
    sql
    -- OSユーザー 'orauser' に対応するデータベースユーザーを作成（OS_AUTHENT_PREFIXがOPS$の場合）
    CREATE USER OPS$ORAUSER
    IDENTIFIED EXTERNALLY;
    このユーザーは、OSユーザーorauserとしてデータベースサーバーにログインしている状態であれば、パスワードなしでデータベースに接続できます。

3. IDENTIFIED GLOBALLY AS 'external_name'

この認証方法は、LDAP（Lightweight Directory Access Protocol）ディレクトリサービスなどの外部認証局を利用してユーザーを認証します。Oracle Database Enterprise Editionで利用可能なEnterprise User Security (EUS) 機能の一部として提供されます。

  • グローバルユーザー認証の仕組み: ユーザー情報はLDAPディレクトリに一元管理され、OracleデータベースはLDAPサーバーと連携してユーザー認証を行います。データベース自体はユーザーのパスワードを持つ必要がなく、認証は外部のディレクトリサービスで行われます。

  • 設定方法: グローバルユーザーを構成するには、データベース、LDAPディレクトリサーバー（Oracle Unified Directory, Microsoft Active Directoryなど）、そしてそれらを連携させるためのOracle Net Configuration Assistant (NETCA) やOracle Wallet Managerなどのツールを用いた複雑な設定が必要です。LDAPディレクトリには、Oracleスキーマ（ユーザー情報、ロール、権限などを含むディレクトリ構造）が拡張されている必要があります。'external_name'には、LDAPディレクトリにおけるユーザーのDN (Distinguished Name) などの識別名を指定します。

  • メリット:

    • 一元管理: 複数のOracleデータベース、さらには他のアプリケーションのユーザー情報もLDAPディレクトリで一元管理できるため、管理負荷が軽減されます。
    • シングルサインオン (SSO): LDAP認証を利用することで、ユーザーは一度ログインすれば、複数のデータベースやアプリケーションにパスワードなしでアクセスできるようになります。
    • セキュリティ向上: 認証ポリシー（パスワードポリシー、アカウントロックなど）をディレクトリサービス側で強力に管理できます。

  • デメリット: 設定が複雑であり、LDAPディレクトリサービスの構築・運用スキルが必要です。Enterprise Editionのライセンスが必要です。

  • 例:
    sql
    -- LDAPディレクトリに存在するDN "cn=johndoe,ou=Users,dc=mycompany,dc=com" に対応する
    -- グローバルユーザーを作成
    CREATE USER johndoe
    IDENTIFIED GLOBALLY AS 'cn=johndoe,ou=Users,dc=mycompany,dc=com';
    この例では、johndoeというOracleデータベースユーザーを作成し、認証をLDAPディレクトリ内の特定のDNを持つエントリに委任しています。ユーザーjohndoeがデータベースに接続しようとすると、Oracleデータベースは指定されたDNを用いてLDAPディレクトリサービスに認証を要求します。

DEFAULT TABLESPACE default_tablespace

この句は、ユーザーがスキーマオブジェクト（テーブル、インデックスなど）を明示的に表領域を指定せずに作成した場合に、それらがデフォルトで格納される表領域を指定します。

  • default_tablespace: デフォルトとして割り当てる表領域の名前を指定します。この表領域は事前に作成されている必要があります。

  • なぜデフォルト表領域が必要か: ユーザーがCREATE TABLEやCREATE INDEXなどのDDL（データ定義言語）を実行する際、通常はTABLESPACE tablespace_name句を指定して、どの表領域にオブジェクトを作成するかを明示的に指定します。しかし、この指定を省略した場合に、どこにオブジェクトを格納するかをOracleデータベースは知る必要があります。その指定を行うのが、このデフォルト表領域の設定です。

  • 指定しない場合の挙動: CREATE USER文でDEFAULT TABLESPACE句を省略した場合、ユーザーのデフォルト表領域はデータベースのデフォルト表領域（SYSTEM表領域ではない）になります。もしデータベースにデフォルト表領域が明示的に設定されていない場合、SYSTEM表領域がデフォルトとして使用されます。SYSTEM表領域にユーザーオブジェクトを作成することは、データディクショナリとユーザーデータを混在させることになり、管理上およびパフォーマンス上の問題を引き起こす可能性があるため、絶対に避けるべきです。したがって、ユーザーを作成する際には、必ず適切なデフォルト表領域を指定することが強く推奨されます。

  • 重要性:

    • 管理の容易性: ユーザーやアプリケーションごとにデフォルト表領域を分けることで、データの格納場所を論理的に分離し、管理しやすくなります。
    • パフォーマンス: I/O負荷の分散や、特定のタイプのデータ（例: LOBデータ）を特定の表領域に格納することで、パフォーマンスの最適化に繋がる場合があります。
    • ディスク領域管理: ユーザーがオブジェクトを作成する際のディスク領域消費を、デフォルト表領域のクォータと組み合わせて管理できます。

  • 例:
    sql
    CREATE USER myuser2
    IDENTIFIED BY mypassword456
    DEFAULT TABLESPACE users_data;
    この例では、myuser2のデフォルト表領域としてusers_dataを指定しています。このユーザーがCREATE TABLE mytable (...)のように表領域を指定せずにテーブルを作成した場合、mytableはusers_data表領域に格納されます。

TEMPORARY TABLESPACE temporary_tablespace

この句は、ユーザーが一時的なデータ操作（ソート処理、ハッシュ結合、一時表の作成など）を行う際に使用される一時セグメントを格納するための表領域を指定します。

  • temporary_tablespace: 一時セグメントの格納先として割り当てる一時表領域の名前を指定します。この表領域は事前にCREATE TEMPORARY TABLESPACEコマンドで作成されている必要があります。

  • なぜ一時表領域が必要か: 大量のデータを扱うクエリ（例: ORDER BY句を含むSELECT文、GROUP BY句を含むSELECT文、結合処理）を実行する際、Oracleデータベースは中間結果や作業領域として一時的なディスク領域を使用することがあります。これは一時セグメントとして一時表領域に格納されます。ソート処理がメモリ（PGA – Program Global Area）に収まらない場合や、ハッシュ結合でビルドテーブルがPGAに収まらない場合などに、一時表領域への書き出し（ディスクソート、ディスクハッシュ）が発生します。また、CREATE GLOBAL TEMPORARY TABLEで作成した一時表のデータも一時表領域に格納されます。

  • 指定しない場合の挙動: CREATE USER文でTEMPORARY TABLESPACE句を省略した場合、ユーザーの一時表領域はデータベースのデフォルト一時表領域になります。もしデータベースにデフォルト一時表領域が明示的に設定されていない場合、一時表領域としてSYSTEM表領域が使用される可能性がありますが、これは非常に稀であり、通常はインストール時にデフォルト一時表領域が設定されます。デフォルト一時表領域は、DATABASE_PROPERTIESビューで確認できます。

  • 重要性:

    • パフォーマンス: 一時表領域は頻繁に読み書きされる可能性があるため、パフォーマンスの高いディスクに配置することが推奨されます。適切に設定された一時表領域は、ソートやハッシュ結合などの処理性能に直接影響します。複数のデータファイルを持つ一時表領域や、一時表領域グループを利用することで、一時的なI/Oを分散させ、パフォーマンスを向上させることができます。
    • 管理: 一時表領域は永続的なデータを保持せず、セッション終了時などに領域が解放されます。専用の一時表領域を使用することで、永続データと一時データを明確に分離し、管理が容易になります。
    • リソース管理: 一時表領域の使用量が過大になると、データベースサーバーのディスク領域を圧迫する可能性があります。適切なサイズの見積もりや監視が必要です。

  • 一時表領域グループ: Oracle Database 10g以降では、一時表領域の集合である「一時表領域グループ」を指定することも可能です。これにより、ユーザーはグループ内の複数の一時表領域をラウンドロビンで使用でき、一時セグメントのI/O負荷をより均等に分散させることができます。

  • 例:
    sql
    CREATE USER myuser3
    IDENTIFIED BY mypassword789
    TEMPORARY TABLESPACE temp_data;
    この例では、myuser3の一時表領域としてtemp_dataを指定しています。

    一時表領域グループを指定する例：
    “`sql
    — まず一時表領域グループを作成（例: temps_group）
    — 次に temps_group に一時表領域を追加（例: temp_01, temp_02）
    — ALTER TABLESPACE temp_01 TABLESPACE GROUP temps_group;
    — ALTER TABLESPACE temp_02 TABLESPACE GROUP temps_group;

    — ユーザー作成時に一時表領域グループを指定
    CREATE USER myuser4
    IDENTIFIED BY mypasswordabc
    TEMPORARY TABLESPACE temps_group; — 一時表領域グループ名を指定
    “`

QUOTA { integer [ K | M | G | T | P | E ] | UNLIMITED } ON tablespace [, QUOTA ...]

この句は、ユーザーが特定の表領域に格納できるデータの最大容量（クォータ）を設定します。クォータは、ユーザーが所有するオブジェクトが消費するディスク領域を制限するために使用されます。

  • integer [ K | M | G | T | P | E ]: ユーザーが指定した表領域に格納できる最大容量を数値で指定します。単位としてK (キロバイト), M (メガバイト), G (ギガバイト), T (テラバイト), P (ペタバイト), E (エクサバイト) を付加できます。単位を省略した場合、バイト単位とみなされます（ただし、通常は単位を付けて指定します）。
  • UNLIMITED: 指定した表領域において、ユーザーが格納できる容量に制限がないことを意味します。ユーザーは、その表領域が持つ物理的な容量の許す限り、オブジェクトを作成できます。

  • ON tablespace: クォータを設定する表領域の名前を指定します。

  • なぜクォータが必要か: クォータは、データベースのリソース（特にディスク領域）を管理し、ユーザーが意図せずまたは悪意を持って大量のデータを作成し、表領域を枯渇させてしまうことを防ぐために使用されます。特に複数のユーザーやアプリケーションが同じ表領域を共有する場合に、各ユーザーのリソース使用量を制限するのに有効です。

  • 指定しない場合の挙動: CREATE USER文でQUOTA句を省略した場合、そのユーザーはどの表領域に対してもオブジェクトを作成できません（デフォルト表領域であっても）。オブジェクトを作成するには、明示的にクォータを付与する必要があります。UNLIMITED QUOTAを付与するか、特定の容量制限付きのクォータを付与する必要があります。

  • クォータ設定の重要性:

    • リソース管理: ディスク領域という限られたリソースをユーザー間で公平に分配し、制御できます。
    • 障害防止: 特定のユーザーによる過剰なディスク使用が、他のユーザーやデータベース全体の可用性に影響を与えるのを防ぎます。表領域が満杯になると、その表領域への書き込みだけでなく、関連する他の操作にも影響が出ることがあります。
    • 課金/容量計画: クラウド環境などでは、使用量に基づいた課金が行われる場合があり、クォータは容量計画やコスト管理の一助となります。

  • 複数の表領域へのクォータ設定: QUOTA句はカンマ区切りで複数指定できます。これにより、ユーザーに対して複数の表領域に対するクォータを一度に設定できます。

  • 例:
    sql
    CREATE USER myuser5
    IDENTIFIED BY mypassworddef
    DEFAULT TABLESPACE app_data
    TEMPORARY TABLESPACE temp_data
    QUOTA 100M ON app_data -- app_data 表領域に100MBの制限
    QUOTA UNLIMITED ON users_large_data; -- users_large_data 表領域は無制限
    この例では、myuser5はapp_data表領域には最大100MBまでデータを格納できますが、users_large_data表領域には容量制限なくデータを格納できます。temp_dataは一時表領域なので、通常はクォータを設定する必要はありません（一時データは永続的な領域を消費しないため）。

PROFILE profile_name

この句は、作成するユーザーに割り当てるプロファイルを指定します。プロファイルは、データベースのリソース使用制限やパスワード管理ポリシーの集合です。

  • profile_name: 割り当てるプロファイルの名前を指定します。このプロファイルは事前にCREATE PROFILEコマンドで作成されている必要があります。

  • プロファイルとは: プロファイルは、ユーザーごとに、またはユーザーのグループごとに、以下の2種類の制限を設定するために使用されます。

    1. リソース制限: CPU使用時間（セッションごと、コールごと）、論理読み込み（セッションごと、コールごと）、アイドル時間（セッションが無操作でいられる時間）、接続時間などの制限。
    2. パスワード管理ポリシー: パスワードの有効期限 (PASSWORD_LIFE_TIME)、パスワードの再利用禁止期間/回数 (PASSWORD_REUSE_TIME, PASSWORD_REUSE_MAX)、失敗ログイン回数の上限 (FAILED_LOGIN_ATTEMPTS)、アカウントロックアウト期間 (PASSWORD_LOCK_TIME)、パスワード変更猶予期間 (PASSWORD_GRACE_TIME)、そしてパスワードの複雑性をチェックするための検証関数 (PASSWORD_VERIFY_FUNCTION) の設定。

  • 指定しない場合の挙動: CREATE USER文でPROFILE句を省略した場合、作成されるユーザーには自動的にDEFAULTプロファイルが割り当てられます。DEFAULTプロファイルは、特別な設定を行わない限り、全てのリソース制限が無制限 (UNLIMITED)、パスワード関連の設定もほとんど無制限または緩い設定になっています。セキュリティを強化するためには、独自のプロファイルを作成し、適切なパスワードポリシーを設定してユーザーに割り当てるべきです。

  • プロファイル作成（CREATE PROFILE）の概要: CREATE PROFILEコマンドを使って、カスタムプロファイルを作成できます。例えば、以下のような構文でパスワードポリシーを定義できます。
    sql
    CREATE PROFILE app_user_profile LIMIT
    PASSWORD_LIFE_TIME 90 -- パスワード有効期限 90日
    PASSWORD_GRACE_TIME 7 -- 有効期限切れ後猶予期間 7日
    PASSWORD_REUSE_TIME UNLIMITED -- パスワード再利用無制限 (または N 日や N 回に制限)
    PASSWORD_REUSE_MAX UNLIMITED -- パスワード再利用無制限
    FAILED_LOGIN_ATTEMPTS 5 -- 失敗ログイン回数 5回でアカウントロック
    PASSWORD_LOCK_TIME 1 -- ロックアウト期間 1日
    PASSWORD_VERIFY_FUNCTION verify_function_name; -- パスワード検証関数
    これらの設定は、ユーザーがプロファイルに割り当てられた時点から適用されます。

  • 重要性:

    • セキュリティ: パスワードポリシーを強制することで、パスワードクラッキングや不正アクセスのリスクを低減します。定期的なパスワード変更の強制、推測されにくいパスワードの使用強制、失敗ログインによるアカウントロックアウトなどは、セキュリティ対策の基本です。
    • リソース管理: セッション時間やアイドル時間などに制限を設けることで、不要なセッションの維持によるリソース浪費を防いだり、特定のユーザーによる過度なリソース消費を抑制したりできます。

  • 例:
    sql
    -- 事前に 'app_user_profile' というプロファイルが作成されているとして
    CREATE USER myuser6
    IDENTIFIED BY mypasswordxyz
    PROFILE app_user_profile; -- 作成したプロファイルを割り当てる
    この例では、myuser6にapp_user_profileというプロファイルを割り当てています。これにより、app_user_profileで定義されたパスワードポリシーやリソース制限がmyuser6に適用されます。

ACCOUNT { LOCK | UNLOCK }

この句は、ユーザーアカウントを初期状態でロックするかどうかを指定します。

  • LOCK: 作成したユーザーアカウントを初期状態でロックします。ユーザーは、この状態ではデータベースに接続できません。

  • UNLOCK: 作成したユーザーアカウントを初期状態でロックしない（つまり、作成と同時に接続可能にする）ことを意味します。これはデフォルトの動作です。

  • なぜアカウントロックが必要か:

    • セキュリティ対策: 新しいユーザーを作成しても、すぐに利用可能にするのではなく、管理者による最終確認や初期権限設定が完了するまでアカウントをロックしておきたい場合があります。
    • 一時的な無効化: 特定の理由（例: ユーザーの退職、一時的な利用停止など）でユーザーアカウントの利用を一時的に停止したい場合、ALTER USER user ACCOUNT LOCK;コマンドでアカウントをロックしますが、CREATE USER時にも初期状態をロックとしておくことが可能です。

  • 指定しない場合の挙動: ACCOUNT句を省略した場合、ユーザーアカウントはデフォルトでUNLOCK状態になります。つまり、作成後すぐにパスワード（または他の認証情報）を知っていれば接続可能になります。

  • アカウントの状態変更: アカウントの状態は、ALTER USERコマンドを使っていつでも変更できます。
    sql
    ALTER USER myuser ACCOUNT LOCK; -- アカウントをロックする
    ALTER USER myuser ACCOUNT UNLOCK; -- アカウントのロックを解除する

  • 例:
    sql
    CREATE USER myuser7
    IDENTIFIED BY initial_password
    ACCOUNT LOCK; -- 初期状態でアカウントをロックする
    この例では、myuser7アカウントは作成された時点では接続できません。接続可能にするためには、後から管理者がALTER USER myuser7 ACCOUNT UNLOCK;を実行する必要があります。これは、初期パスワードを設定したが、ユーザーにまだ通知しておらず、誤った接続を防ぎたい場合などに役立ちます。

EXTERNAL NAME 'external_name'

この句は、主にIDENTIFIED EXTERNALLYまたはIDENTIFIED GLOBALLY句と組み合わせて使用され、データベースユーザーに対応する外部のユーザー名を明示的に指定します。IDENTIFIED EXTERNALLYの場合、これはOSユーザー名を指定するために使用され、OS_AUTHENT_PREFIX初期化パラメータの挙動を上書きできます。IDENTIFIED GLOBALLYの場合、これはLDAPディレクトリにおけるユーザーの識別名（DNなど）を指定するために使用されます。

  • 'external_name': 対応する外部（OSまたはディレクトリサービス）のユーザー名を文字列リテラルで指定します。

  • IDENTIFIED EXTERNALLYとの組み合わせ: 通常、IDENTIFIED EXTERNALLYではOS_AUTHENT_PREFIX + OSユーザー名でデータベースユーザー名を決定しますが、EXTERNAL NAME句を使用すると、どのOSユーザー名と関連付けるかを明示的に指定できます。この場合、データベースユーザー名とOSユーザー名が一致している必要はありません（ただし、管理の観点から一致させておく方が分かりやすいことが多いです）。OS_AUTHENT_PREFIXは無視されます。

    sql
    -- OSユーザー 'myosuser' に対応するデータベースユーザー 'app_dba' を作成
    CREATE USER app_dba
    IDENTIFIED EXTERNALLY
    EXTERNAL NAME 'myosuser'; -- 対応するOSユーザー名を明示的に指定
    この例では、OSユーザーmyosuserとしてサーバーにログインしているユーザーは、データベースユーザーapp_dbaとして接続できます。

  • IDENTIFIED GLOBALLYとの組み合わせ: IDENTIFIED GLOBALLY AS 'external_name'句と機能的には重複しますが、EXTERNAL NAME句は主に既存のユーザーに対して外部名を後から関連付ける（ALTER USER ... EXTERNAL NAME ...）場合や、旧バージョンとの互換性のために使用されることがあります。新しいバージョンではIDENTIFIED GLOBALLY AS句を使用することが推奨されます。

    sql
    -- LDAPユーザー 'cn=johndoe,ou=Users,dc=mycompany,dc=com' に対応する
    -- データベースユーザー 'johndoe_ldap' を作成 (旧形式)
    CREATE USER johndoe_ldap
    IDENTIFIED GLOBALLY
    EXTERNAL NAME 'cn=johndoe,ou=Users,dc=mycompany,dc=com';
    この例は、前述のIDENTIFIED GLOBALLY ASの例とほぼ同等です。

  • 重要性: EXTERNAL NAME句を使用すると、データベースユーザー名と外部ユーザー名の間のマッピングを柔軟に定義できます。これは、既存の外部認証環境に合わせてデータベースユーザー名を設計する必要がある場合や、OSユーザー名/LDAPユーザー名と異なる命名規則をデータベースユーザーに適用したい場合に便利です。

ユーザー作成時の注意点とベストプラクティス

ユーザーを安全かつ効率的に管理するために、以下の点に注意し、ベストプラクティスを適用することが重要です。

  • ユーザー名の命名規則: ユーザー名は、その用途や所属するアプリケーションなどが一目でわかるような規則性のある名前にすることが推奨されます。例えば、APP1_USER, HR_BATCH, SALES_READONLYのように、アプリケーション名、目的、アクセス権限レベルなどを示すプレフィックスやサフィックスを付けると管理しやすくなります。Oracleデータベースの命名規則（最大長、使用可能な文字など）に従う必要があります。共通ユーザーを作成する場合は、Oracle Database 12c以降ではC##またはc##プレフィックスが必須です。

  • パスワードのセキュリティ: IDENTIFIED BYを使用する場合、パスワードのセキュリティは最も重要です。

    • 複雑性: 推測されにくい、十分な長さと多様性（大文字、小文字、数字、記号）を持つパスワードを使用することをユーザーに義務付けます。これにはプロファイルとPASSWORD_VERIFY_FUNCTIONが有効です。
    • 定期変更: プロファイルを使用して、パスワードの有効期限を設定し、定期的な変更を強制します。
    • 再利用制限: 過去に使用したパスワードの再利用を制限します（プロファイル設定）。
    • 共有禁止: ユーザーアカウントやパスワードを複数人で共有することは、責任の所在が不明確になり監査が困難になるため、絶対に禁止します。
    • デフォルトパスワードの即時変更: CREATE USER時に設定した初期パスワードを、ユーザーが初回ログイン時に変更することを強制する設定は、プロファイルやトリガーなどを用いて実装できます（PASSWORD_CHANGE_ALLOWEDプロファイルパラメータや、ログインイベントトリガーなど）。

  • 最小権限の原則: ユーザーには、その業務遂行に必要最低限の権限のみを付与します。GRANTコマンドで広範な権限を安易に付与することは避けるべきです。必要な権限が何かを定義し、それに合致する権限セット（ロールとして定義することが多い）をユーザーに付与します。

  • デフォルト表領域と一時表領域の考慮: 前述のように、これらの表領域は必ず明示的に指定し、SYSTEM表領域をユーザーデータや一時データに使用させないようにします。アプリケーションごとに専用の表領域を作成し、それをユーザーのデフォルト表領域として割り当てることが、管理やパフォーマンスの観点から望ましい場合が多いです。

  • クォータによるリソース管理: ユーザーがオブジェクトを作成する表領域に対して、適切なクォータを設定します。UNLIMITEDは便利ですが、無制限な容量使用を許すことになるため、慎重に適用すべきです。特に、開発者やアプリケーションユーザーが本番環境で自由にオブジェクトを作成する場合、クォータはディスク枯渇を防ぐための重要な防御線となります。

  • プロファイルの適切な適用: セキュリティポリシーやリソース使用計画に基づき、適切なプロファイルを作成し、ユーザーに割り当てます。特にパスワードポリシーに関する設定は、データベース全体のセキュリティレベルに直結するため、組織のポリシーに合わせて厳格に設定する必要があります。

  • アカウントのロックと解除: アカウントのロック機能を活用し、新規作成ユーザーの初期状態を制御したり、一時的に利用停止したいユーザーアカウントを無効化したりします。

  • デフォルトユーザー（SYS, SYSTEMなど）の取り扱い: SYSやSYSTEMなどのデフォルト管理ユーザーは、極めて高い権限を持っています。これらのユーザーは日常的な操作には使用せず、管理作業に限定します。デフォルトパスワードは必ず変更し、可能な限りパスワード認証ではなくOS認証やディレクトリ認証、あるいは最小特権の原則に基づいた専用の管理者ユーザーを作成して利用することが推奨されます。

  • 開発/テスト/本番環境でのユーザー管理: 各環境の目的とセキュリティ要件に合わせて、ユーザーの作成方法、権限付与、プロファイル適用方法を変える必要があります。例えば、開発環境では比較的緩やかな設定でも良いかもしれませんが、本番環境では厳格なセキュリティ設定が必要です。環境間でユーザー管理プロセスを標準化することも重要です。

作成したユーザーへの権限付与

ユーザーを作成しただけでは、そのユーザーはデータベースに接続することすらできません（例外として、CREATE SESSIONシステム権限がPUBLICロールに付与されている場合は接続できますが、これはセキュリティリスクとなるため、本番環境ではPUBLICからCREATE SESSION権限を剥奪し、ユーザーに明示的に付与することが一般的です）。データベースに接続したり、テーブルを作成したり、他のユーザーのテーブルを参照したりといった操作を行うためには、作成したユーザーに適切な権限を付与する必要があります。

権限には大きく分けて以下の2種類があります。

  1. システム権限 (System Privileges): データベース全体に対する操作に関する権限です。例:CREATE SESSION (接続権限), CREATE TABLE (テーブル作成権限), DROP ANY TABLE (任意のテーブル削除権限), SELECT ANY TABLE (任意のテーブル参照権限), GRANT ANY ROLE (任意のロール付与権限), BACKUP ANY TABLE (任意のテーブルバックアップ権限) など、非常に多くの種類があります。
  2. オブジェクト権限 (Object Privileges): 特定のデータベースオブジェクト（テーブル、ビュー、シーケンス、プロシージャなど）に対する操作に関する権限です。例: SELECT (参照), INSERT (挿入), UPDATE (更新), DELETE (削除) (テーブル/ビューに対して), EXECUTE (実行) (プロシージャ/ファンクションに対して), ALTER (変更), INDEX (インデックス作成), REFERENCES (外部キー制約作成) など。

権限の付与は、GRANTコマンドを使用して行います。

“`sql
— システム権限の付与
GRANT system_privilege [, system_privilege …]
TO user [, user …]
[ WITH ADMIN OPTION ]; — 付与された権限を他のユーザーにも付与できるようになるオプション (強力なので注意)

— オブジェクト権限の付与
GRANT object_privilege [( column [, column …] )] [, object_privilege [( column [, column …] )] …]
ON object_name
TO user [, user …]
[ WITH GRANT OPTION ]; — 付与された権限を他のユーザーにも付与できるようになるオプション (強力なので注意)
“`

例えば、myuser1がデータベースに接続し、自身のスキーマにテーブルを作成し、anotheruserのsalesテーブルからデータを参照できるようにするには、以下のような権限が必要になります。

“`sql
— 接続権限 (CREATE SESSION) の付与
GRANT CREATE SESSION TO myuser1;

— 自身のスキーマにテーブルを作成する権限 (CREATE TABLE) の付与
GRANT CREATE TABLE TO myuser1; — デフォルト表領域へのQUOTAも必要です！

— anotheruser の sales テーブルから SELECT する権限の付与
GRANT SELECT ON anotheruser.sales TO myuser1;
“`

権限管理を効率化するために、Oracleデータベースでは「ロール（Role）」という仕組みが提供されています。ロールは、システム権限やオブジェクト権限の集合体に名前を付けたものです。ユーザーに直接個々の権限を付与する代わりに、必要な権限を含むロールをユーザーに付与することで、権限管理を簡素化し、変更にも強くできます。

“`sql
— ロールを作成 (例: app_readonly_role)
CREATE ROLE app_readonly_role;

— ロールに権限を付与
GRANT CREATE SESSION TO app_readonly_role;
GRANT SELECT ON anotheruser.sales TO app_readonly_role;
GRANT SELECT ON app_schema.products TO app_readonly_role;

— ユーザーにロールを付与
GRANT app_readonly_role TO myuser1;
``
これにより、myuser1はapp_readonly_role`に含まれるすべての権限を行使できるようになります。新しいユーザーに同じ権限セットが必要な場合、そのユーザーにも同じロールを付与するだけで済みます。権限セットに変更があった場合も、ロールの内容を変更するだけで、そのロールが付与されているすべてのユーザーに変更が反映されます。

補足：古いOracleのバージョンでは、CONNECTロールとRESOURCEロールが広く使われていましたが、これらは非常に多くの（そして通常は不要な）システム権限を含んでおり、セキュリティ上のリスクとなります。現在では、必要な最小限の権限を個別に付与するか、より適切な権限を含むカスタムロールを作成して使用することが推奨されています。CONNECTロールは主にCREATE SESSION権限のみを含むように変更されていますが、依然として利用は非推奨です。

ユーザー情報の確認

作成したユーザーや既存のユーザーに関する情報は、様々なデータディクショナリビューから確認できます。管理者がユーザーの状態や設定を把握するために、これらのビューは非常に役立ちます。

  • DBA_USERS: データベース内のすべてのユーザーに関する情報が含まれます。user_id, username, account_status, lock_date, expiry_date, default_tablespace, temporary_tablespace, profile, initial_rsrc_consumer_group, external_name, proxy_userなどのカラムが含まれます。管理者はこのビューを使って、ユーザーの一覧、状態、割り当てられているデフォルト表領域、プロファイルなどを確認できます。
  • ALL_USERS: カレントユーザーがアクセス可能なユーザーに関する情報が含まれます。通常、データベース内のすべてのユーザーが表示されます。
  • USER_USERS: カレントユーザー自身の情報のみが含まれます。

例:
“`sql
— すべてのユーザー情報を確認 (DBA権限が必要)
SELECT username, account_status, default_tablespace, temporary_tablespace, profile
FROM dba_users
ORDER BY username;

— 特定ユーザーの情報を確認 (DBA権限が必要)
SELECT username, account_status, lock_date, expiry_date
FROM dba_users
WHERE username = ‘MYUSER1’;
“`

クォータ情報はDBA_TS_QUOTASビューで確認できます。
sql
-- すべてのユーザーのクォータ情報を確認 (DBA権限が必要)
SELECT username, tablespace_name, bytes, max_bytes, blocks, max_blocks
FROM dba_ts_quotas
ORDER BY username, tablespace_name;
max_bytesカラムにUNLIMITEDの場合は-1が表示されます。

プロファイルの内容はDBA_PROFILESビューで確認できます。
sql
-- 特定プロファイルのリソース制限設定を確認 (DBA権限が必要)
SELECT resource_name, limit
FROM dba_profiles
WHERE profile = 'APP_USER_PROFILE'
AND resource_type = 'PASSWORD'; -- パスワード関連の設定のみ表示

付与されている権限やロールは、DBA_SYS_PRIVS, DBA_TAB_PRIVS, DBA_ROLE_PRIVSなどのビューで確認できます（DBA権限が必要）。

ユーザーの変更と削除

ユーザーは作成後も、その設定を変更したり、不要になった場合に削除したりすることができます。

  • ユーザーの変更 (ALTER USER):
    ALTER USERコマンドを使用すると、パスワードの変更、アカウント状態のロック/解除、デフォルト表領域や一時表領域、プロファイル、クォータなどの設定を変更できます。
    “`sql
    — パスワードの変更 (管理者またはユーザー自身)
    ALTER USER myuser IDENTIFIED BY new_password;

    — アカウントのロック/解除 (管理者)
    ALTER USER myuser ACCOUNT LOCK;
    ALTER USER myuser ACCOUNT UNLOCK;

    — デフォルト表領域の変更 (管理者)
    ALTER USER myuser DEFAULT TABLESPACE new_data_ts;

    — クォータの変更 (管理者)
    ALTER USER myuser QUOTA 500M ON app_data;
    ALTER USER myuser QUOTA UNLIMITED ON users_large_data;
    “`

  • ユーザーの削除 (DROP USER):
    DROP USERコマンドを使用すると、データベースからユーザーを削除できます。
    sql
    DROP USER user; -- ユーザーのみを削除 (スキーマオブジェクトは残る)
    DROP USER user CASCADE; -- ユーザーとそのユーザーが所有するすべてのスキーマオブジェクトを削除
    DROP USER userとした場合、そのユーザーがオブジェクト（テーブルなど）を所有していると削除できません。ユーザーが所有するオブジェクトも一緒に削除したい場合は、必ずCASCADEオプションを付けます。CASCADEオプションは強力な操作であり、元に戻せないため、実行には細心の注意が必要です。ユーザーを削除する前に、そのユーザーが所有するオブジェクトが他のユーザーやアプリケーションに依存されていないか、バックアップが必要ないかなどを十分に確認する必要があります。

高度なトピック（簡潔に触れる）

コンテナ・データベース (CDB) とプラガブル・データベース (PDB) におけるユーザー作成

Oracle Database 12c以降で導入されたマルチテナント・アーキテクチャでは、ユーザーは共通ユーザー (Common User) と ローカルユーザー (Local User) の2種類に分けられます。

  • 共通ユーザー: CDB$ROOTコンテナで作成され、その共通ユーザーがアクセス権を持つ全てのコンテナ（CDB$ROOT、PDBなど）で認識されるユーザーです。ユーザー名はC##またはc##のプレフィックスで始める必要があります。共通ユーザーは主にCDB全体の管理に使われます。
  • ローカルユーザー: 特定のPDBコンテナ内で作成され、そのPDB内でのみ認識されるユーザーです。プレフィックスは不要です（C##/c##以外の名前）。アプリケーションユーザーや通常の業務ユーザーは、通常ローカルユーザーとしてPDB内に作成されます。

CREATE USERコマンドは、どのコンテナに接続して実行するかによって、共通ユーザーを作成するかローカルユーザーを作成するかが決まります。CDB$ROOTに接続して実行すれば共通ユーザーが、特定のPDBに接続して実行すればローカルユーザーが作成されます。

例:
“`sql
— CDB$ROOT に接続して実行: 共通ユーザーを作成
CREATE USER c##common_user
IDENTIFIED BY password
CONTAINER = ALL; — CDB$ROOT と全てのPDBで認識されるユーザー (デフォルト)
— CONTAINER = CURRENT; — CDB$ROOT でのみ認識されるユーザー (稀)

— 特定のPDB (例: pdb1) に接続して実行: ローカルユーザーを作成
ALTER SESSION SET CONTAINER = pdb1;
CREATE USER local_user_in_pdb1
IDENTIFIED BY password
CONTAINER = CURRENT; — カレントのPDB (pdb1) でのみ認識されるユーザー (デフォルト)
``CONTAINER = ALL句は共通ユーザーにのみ指定可能で、その共通ユーザーがCDB$ROOTを含む全てのコンテナで認識されることを示します。CONTAINER = CURRENT句は、共通ユーザー/ローカルユーザーどちらにも指定可能で、コマンドを実行したカレントコンテナでのみユーザーが認識されることを示します。共通ユーザーの場合はCONTAINER = ALLが一般的で、ローカルユーザーの場合はCONTAINER = CURRENT`がデフォルトかつ必須です。

プロキシ認証

プロキシ認証は、あるユーザー（プロキシユーザー）が、別のユーザー（クライアントユーザー）に代わってデータベースに接続し、操作を実行する機能です。例えば、アプリケーションサーバーが単一のデータベースユーザー（プロキシユーザー）として接続し、アプリケーションにログインしたエンドユーザー（クライアントユーザー）に代わって操作を行う場合などに使用されます。これにより、データベース側で個々のエンドユーザーを識別し、監査や権限管理をきめ細かく行うことが可能になります。プロキシユーザーはALTER USERコマンドで設定します。

リアルアプリケーションセキュリティ (RAS) / アプリケーションユーザー

Oracle Database 12c以降で導入されたリアルアプリケーションセキュリティ（RAS）は、アプリケーションレベルでのきめ細かいアクセス制御を可能にするフレームワークです。RASでは、データベースユーザーとは異なる「アプリケーションユーザー」という概念を導入し、アプリケーション内で認証されたユーザーに基づいて、データベースオブジェクトへのアクセスを制御できます。これは、多数のアプリケーションユーザーをOracleデータベースユーザーとして直接作成・管理するのが非効率な場合に有効です。

まとめ

Oracleデータベースにおけるユーザー管理は、データベースのセキュリティ、管理性、そしてパフォーマンスの基盤となる非常に重要な要素です。本記事では、その第一歩であるユーザー作成コマンドCREATE USERに焦点を当て、その基本的な使い方から、IDENTIFIED BY, IDENTIFIED EXTERNALLY, IDENTIFIED GLOBALLY, DEFAULT TABLESPACE, TEMPORARY TABLESPACE, QUOTA, PROFILE, ACCOUNTといった詳細なオプション句に至るまで、それぞれの役割、必要性、設定方法、そして関連する重要な概念や注意点について深く解説しました。

CREATE USERコマンドは、単にユーザー名とパスワードを設定するだけでなく、そのユーザーがデータベース内でどのように振る舞い、どのようなリソースを利用できるかを定義するための強力なツールです。適切なデフォルト表領域と一時表領域の割り当てはパフォーマンスと管理の容易性に関わり、クォータの設定はリソースの適切な利用を保証します。そして、プロファイルの活用は、セキュリティポリシーの適用（特にパスワード管理）やリソース制限の強制において不可欠です。

ユーザーを作成しただけでは何もできないという点も重要です。作成したユーザーには、GRANTコマンドを用いて必要なシステム権限やオブジェクト権限を付与する必要があります。権限管理を効率化するためには、ロールを積極的に活用することが推奨されます。

Oracle Database 12c以降のCDB/PDB環境における共通ユーザーとローカルユーザーの違いや、外部認証（OS認証、LDAP認証）、プロキシ認証といった高度な認証オプションについても触れました。これらの機能は、データベースの利用形態や組織のセキュリティ要件に応じて適切に選択・設定する必要があります。

最後に、ユーザー管理は一度設定すれば終わりではなく、データベースの運用ライフサイクルを通じて継続的に行うべき活動です。ユーザーアカウントの棚卸し、不要になったアカウントの削除、パスワードポリシーの定期的な見直しと適用、失敗ログインの監視と対応など、運用フェーズでの管理も同様に重要です。

本記事を通じて、OracleデータベースのCREATE USERコマンドとその関連概念に対する理解が深まり、より安全で効率的なデータベースユーザー管理を実践できるようになることを願っています。データベースセキュリティの確保と円滑な運用のためにも、本記事で解説した内容を日々の管理業務に活かしていただければ幸いです。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール