日本語PDF

3 認証の構成

認証とは、データベースに接続するユーザーや他のエンティティを認証することです。

3.1 認証について

認証とは、データ、リソースまたはアプリケーションの使用を希望するユーザーやデバイスなどのエンティティの身元を検証することです。

アイデンティティを検証することで、その後の対話に関する信頼関係が確立されます。また、認証により、アクセスとアクションを特定のアイデンティティにリンクでき、アカウンタビリティが有効化されます。認証後は、認可プロセスでそのエンティティが実行できるアクセスとアクションのレベルを許可または制限できます。

Oracle Databaseのデータベース・ユーザーと非データベース・ユーザーの両方を認証できます。簡潔性を考慮して、すべてのデータベース・ユーザーに同じ認証方式を使用するのが一般的ですが、Oracle Databaseでは1つのデータベース・インスタンスで一部またはすべての方法を使用できます。Oracle Databaseでは、データベース管理者が特別なデータベース操作を実行するため、そのための特別な認証プロシージャが必要です。また、Oracle Databaseでは、ネットワーク認証のセキュリティを確保するために送信時にパスワードの暗号化も実行されます。

認証後は、認可プロセスでそのエンティティが実行できるアクセスとアクションのレベルを許可または制限できます。

3.2 パスワード保護の構成

ユーザーのパスワードは様々な方法で保護できます。たとえば、パスワードの作成要件の制御、パスワード管理ポリシーの使用などの方法があります。

3.2.1 Oracle Databaseの組込みパスワード保護の概要

Oracle Databaseでは、ユーザーのパスワードを保護するように設計された一連の組込みパスワード保護が提供されています。

提供されるパスワード保護は、次のとおりです。

  • パスワード暗号化。Oracle Databaseでは、Advanced Encryption Standard(AES)を使用して、ネットワーク(クライアントとサーバー間、双方のサーバー間)接続中にパスワードを自動的かつ透過的に暗号化し、その後ネットワーク経由で送信します。ただし、SQL文内で指定されたパスワード(例: CREATE USER user_name IDENTIFIED BY password;)は、ネットワーク・トレース・ファイル内のクリアテキストでネットワーク経由で送信されます。このため、ネイティブ・ネットワーク暗号化を有効にするか、Transport Layer Security (TLS)暗号化を構成する必要があります。

  • パスワードの複雑度のチェック。デフォルトのインストールでは、Oracle Databaseには、ora12c_verify_functionおよびora12c_strong_verify_functionパスワード検証ファンクションがあります。これらの機能では、新しいパスワードや変更されたパスワードの複雑性が十分であり、パスワードを推測してシステムに侵入しようとする侵入者を防ぐことができるかどうかを確認します。パスワードの複雑性チェックを手動で有効にする必要があります。さらに、ユーザーのパスワードの複雑度はカスタマイズできます。

  • パスワード突破の防止。ユーザーが誤ったパスワードを使用してOracle Databaseへのログインを複数回試行した場合、Oracle Databaseによってログインが1秒ずつ遅延されます。この保護は、異なるIPアドレスまたは複数のクライアント接続からのログインに適用されます。この機能により、侵入者がログインを試みるときに一定時間内に試すことができるパスワードの数が大幅に減少します。ログイン失敗による遅延によって、各ログイン試行の失敗にかかる時間が延び、(通常、こうした攻撃では非常に多くの試行に失敗せざるを得ないため)パスワード推測攻撃全体にかかる時間が増加します。

    非管理ログインの場合、Oracle Databaseは、ログイン失敗による遅延に対して排他ロックを設定することによって、同時パスワード推測攻撃からデータを保護します。これによって、侵入者がログイン失敗による遅延を回避しようとする(最初の推測に失敗して遅延された後すぐに別のデータベース・セッションで次の同時推測を試行した場合)のを阻止します。

    攻撃対象のアカウントに対して排他ロックを保持することによって、Oracle Databaseでは同時パスワード推測攻撃が緩和されますが、同時にそのアカウントはサービス拒否(DoS)攻撃を受けやすいままになります。この問題に対処するには、FAILED_LOGIN_ATTEMPTSパラメータがUNLIMITEDに設定されたパスワード・プロファイルを作成し、このパスワード・プロファイルをそのユーザー・アカウントに適用する必要があります。FAILED_LOGIN_ATTEMPTSパラメータに値UNLIMITEDを設定することで、ログイン失敗による遅延が無効になり、ログイン試行失敗回数は制限されません。このようなタイプのアカウントについては、長いランダムなパスワードを使用することをお薦めします。

    同時パスワード推測攻撃の保護は、管理ユーザー接続には適用されません。これは、このような接続は常に使用可能な状態である必要があり、サービス拒否攻撃の影響を受けない必要があるためです。したがって、すべての管理権限アカウントに対して長いパスワードを選択することをお薦めします。

  • パスワードでの大/小文字の区別の規定。パスワードは大/小文字が区別されます。たとえば、パスワードがhPP5620qrの場合、hpp5620QRまたはhPp5620Qrと入力すると失敗します。大/小文字の区別は、パスワード・ファイルおよびデータベース・リンクに影響します。

  • 12Cパスワード・バージョンを使用したパスワードのハッシュ化。ユーザーのパスワードを検証し、パスワード作成で大/小文字の区別を適用するために、12Cパスワード・バージョンが使用されていて、これは、パスワードベースのキー導出関数(PBKDF2)およびSHA-512暗号化ハッシュ関数を含む非最適化されたアルゴリズムに基づいています。

3.2.2 パスワードの最低要件

パスワードに関する最低要件のセットが提供されています。

パスワードは30バイト以内にする必要があります。パスワードを保護するには、パスワードが適切な長さになるよう要求することから、サイトで適用されるパスワード複雑度ポリシー要件を強制するカスタムのパスワード複雑度検証スクリプトの作成まで、様々な方法があります。

3.2.3 IDENTIFIED BY句を使用したパスワードの作成

IDENTIFIED BY句を受け入れるSQL文でもパスワードを作成できます。

  • ユーザーのパスワードを作成するには、CREATE USERALTER USERGRANT CREATE SESSIONまたはCREATE DATABASE LINK SQL文を使用します。

次のSQL文は、IDENTIFIED BY句でパスワードを作成します。

CREATE USER psmith IDENTIFIED BY password;
GRANT CREATE SESSION TO psmith IDENTIFIED BY password;
ALTER USER psmith IDENTIFIED BY password;
CREATE DATABASE LINK AUTHENTICATED BY psmith IDENTIFIED BY password;

3.2.4 パスワード管理ポリシーの使用

パスワード管理ポリシーで、ユーザーのパスワードの安全性を強化できる一連の制限事項を作成して実施できます。

3.2.4.1 パスワード管理について

パスワードに依存しているデータベース・セキュリティ・システムでは、パスワードの機密を常に保つ必要があります。

パスワードは盗難や悪用などの被害を受けやすいため、Oracle Databaseではパスワード管理ポリシーが使用されています。データベース管理者およびセキュリティ管理者がユーザー・プロファイルを介してパスワード管理ポリシーを制御することで、データベース・セキュリティの管理を強化できます。

CREATE PROFILE文を使用して、ユーザー・プロファイルを作成できます。プロファイルは、CREATE USERまたはALTER USER文を使用してユーザーに割り当てます。

3.2.4.2 デフォルト・パスワードが設定されているユーザー・アカウントの検索

DBA_USERS_WITH_DEFPWDデータ・ディクショナリ・ビューで、デフォルトのパスワードを使用するユーザー・アカウントを確認できます。

データベースを作成すると、ほとんどのデフォルト・アカウントは、パスワードが期限切れのためロックされます。以前のリリースのOracle Databaseからアップグレードした場合は、デフォルト・パスワードが設定されているユーザー・アカウントが存在していることがあります。それらは、データベースの作成時に作成されたデフォルト・アカウント(HROESCOTTアカウントなど)です。

セキュリティを強化するために、それらのアカウントのパスワードを変更してください。周知されているデフォルト・パスワードを使用すると、データベースが侵入者から攻撃を受けやすくなります。

  1. SYSDBA管理権限を持つSQL*Plusを使用して、データベース・インスタンスにログインします。

    たとえば:

    sqlplus sys as sysdba
    Enter password: password
    
  2. DBA_USERS_WITH_DEFPWDデータ・ディクショナリ・ビューを問い合せます。

    たとえば、デフォルトのパスワードが設定されているアカウントの名前とステータスの両方を検索するには:

    SELECT d.username, u.account_status
    FROM DBA_USERS_WITH_DEFPWD d, DBA_USERS u
    WHERE d.username = u.username
    ORDER BY 2,1;
    
    USERNAME  ACCOUNT_STATUS
    --------- ---------------------------
    SCOTT     EXPIRED & LOCKED
    
  3. DBA_USERS_WITH_DEFPWDビューにリストされたアカウントのパスワードを変更します。

    これらのアカウントに、旧リリースのOracle Databaseで指定されていた可能性のあるパスワードを割り当てないことをお薦めします。

    たとえば:

    ALTER USER SCOTT ACCOUNT UNLOCK IDENTIFIED BY password;
    

    「パスワードの最低要件」のガイドラインに従って、passwordを安全なパスワードに置き換えます。

3.2.4.3 デフォルト・プロファイルのパスワード設定

プロファイルとは、データベース・リソースに関する制限を設定するパラメータの集合です。

プロファイルをユーザーに割り当てた場合、そのユーザーはそれらの制限を超えることはできません。プロファイルを使用すると、ユーザーごとのセッション数、ロギングやトレースの機能など、データベース設定を構成できます。また、プロファイルによってユーザー・パスワードも制御できます。プロファイル内の現行のパスワード設定に関する情報は、DBA_PROFILESデータ・ディクショナリ・ビューを問い合せることで確認できます。

表3-1に、デフォルト・プロファイルのパスワード固有のパラメータ設定を示します。

表3-1 デフォルト・プロファイルのパスワード固有の設定

パラメータ デフォルト設定 説明

INACTIVE_ACCOUNT_TIME

UNLIMITED

指定した日数の間データベース・インスタンスにログインしていないデータベース・ユーザーのアカウントをロックします。

FAILED_LOGIN_ATTEMPTS

10

ユーザーがログインを試行して失敗する最大回数。この回数を超えるとアカウントがロックされます。

ノート:

  • このパラメータを設定する場合、CONNECT THROUGH権限を使用してログインするユーザーを考慮します。

  • 未認可ユーザー(侵入者の可能性があります)がOracle Call Interface(OCI)アプリケーションにログインを試行する回数の制限を設定するには、SEC_MAX_FAILED_LOGIN_ATTEMPTS初期化パラメータを使用できます。

PASSWORD_GRACE_TIME

7

パスワードが期限切れになる前に、ユーザーがパスワードを変更するための日数を設定します。

PASSWORD_LIFE_TIME

180

ユーザーが現行のパスワードを使用できる日数を設定します。

PASSWORD_LOCK_TIME

1

ログインを指定の回数だけ連続して失敗した後に、アカウントがロックされる日数を設定します。この期間が経過すると、アカウントのロックは解除されます。このユーザー・プロファイル・パラメータは、管理者のメンテナンス負荷を高めることなく、ユーザー・パスワードに対する総当り攻撃を容易に防止するのに役立ちます。

PASSWORD_LOCK_TIMEで設定された値がパスワードの有効期限が切れていることを示した後でも、DBA_USERSデータ・ディクショナリ・ビューにはアカウントがロックされていることが示されます。ただし、ユーザーが接続すると、DBA_USERSの情報が正しいOPENステータスで更新されます。

PASSWORD_REUSE_MAX

UNLIMITED

現行のパスワードを再利用できるようになるまでに必要なパスワード変更の回数を設定します。

PASSWORD_REUSE_TIME

UNLIMITED

パスワードを再利用できない日数を設定します。

3.2.4.4 ALTER PROFILE文を使用したプロファイル制限の設定

ログイン試行の失敗、パスワードのロック回数、パスワードの再利用、その他の設定などのプロファイルの制限を変更できます。

これらの設定については、表3-1で説明されています。セキュリティを強化するために、必要に応じて、この表に示すデフォルト設定を使用してください。

  • ALTER PROFILE文を使用して、ユーザーのプロファイル制限を変更します。

たとえば:

ALTER PROFILE prof LIMIT
 FAILED_LOGIN_ATTEMPTS 9
 PASSWORD_LOCK_TIME 10
 INACTIVE_ACCOUNT_TIME 21;
3.2.4.5 デフォルトのパスワード・セキュリティ設定の有効化および無効化

デフォルトのパスワード・セキュリティ設定を無効または有効にするスクリプトが用意されています。

アプリケーションでOracle Database 10g リリース2 (10.2)のデフォルトのパスワード・セキュリティ設定を使用している場合、Oracle Databaseリリース11g以降のデフォルトのパスワード・セキュリティ設定を使用するようにアプリケーションを変更しないかぎり、それらの設定の復元が可能です。
  1. Oracle Database 11g以降のパスワード・セキュリティ設定に準拠するように、アプリケーションを変更します。
  2. 次のいずれかの方法で、ビジネス・ニーズに合うセキュリティ構成を使用するようにデータベースを更新します。
    • データベース・セキュリティ構成を手動で更新します。

    • secconf.sqlスクリプトを実行して、Oracle Database 11g以降のデフォルトのパスワード設定を適用します。必要に応じて、異なるセキュリティ設定を使用するようにこのスクリプトをカスタマイズできますが、元のスクリプトにリストされている設定は、Oracle推奨の設定であることに注意してください。

データベースを手動で作成した場合は、secconf.sqlスクリプトを実行して、Oracleのデフォルトのパスワード設定をデータベースに適用する必要があります。Database Configuration Assistant(DBCA)を使用して作成されたデータベースではこの設定が使用されますが、手動で作成したデータベースでは使用されません。

secconf.sqlスクリプトは$ORACLE_HOME/rdbms/adminディレクトリにあります。secconf.sqlスクリプトはパスワード設定と監査設定の両方に影響を与えます。他のセキュリティ設定には影響しません。

3.2.4.6 非アクティブなデータベース・ユーザー・アカウントの自動ロック

INACTIVE_ACCOUNT_TIMEプロファイル・パラメータで、指定した日数の間データベース・インスタンスにログインしていないユーザー・アカウントをロックします。

定期的にログインしているユーザーはアクティブであると見なされます。INACTIVE_ACCOUNT_TIMEの計時は、最後にユーザーが正常にログインしてからの日数に基づきます。
  • 指定した日数が経過した後で自動的にユーザー・アカウントをロックするには、CREATE PROFILEまたはALTER PROFILE文でINACTIVE_ACCOUNT_TIMEプロファイル・パラメータを設定します。
    次のことに注意してください。
    • INACTIVE_ACCOUNT_TIMEのデフォルト値はUNLIMITEDです。

    • 日数には整数を指定する必要があります。最小値は15、最大値は24855です。

    • ユーザーのアカウントの非アクティブ時間を無制限に設定するには、INACTIVE_ACCOUNT_TIMEUNLIMITEDに設定します。

    • デフォルト・プロファイルで指定された時間を使用するようにユーザーのアカウントを設定するには、INACTIVE_ACCOUNT_TIMEDEFAULTに設定します。

    • このパラメータは、管理ユーザーを含むすべてのデータベース認証ユーザーに対して設定できますが、外部またはグローバル認証ユーザーには設定できません。

    • 読取り専用のデータベースでは、最後の正常なログインはINACTIVE_ACCOUNT_TIMEの計時において考慮されません。読取り専用のデータベースでユーザー・アカウントをロックすることはできません(ログイン失敗の連続回数がアカウントのFAILED_LOGIN_ATTEMPTSパスワード・プロファイル設定の値に達した場合を除きます)。

    • 新規作成したユーザー・アカウントの場合、計時はアカウント作成時に開始されます。このユーザーがログアウトして再度ログインした場合、計時はユーザーが正常にログインしたときに開始されます。

    • マルチテナント環境では、INACTIVE_ACCOUNT_TIME設定は、共通ユーザーが最後にルートにログインした時点で適用されます。PDBのいずれかまたはルートにログインしている共通ユーザーはアクティブであると見なされます。

    • プロキシ・ユーザー・アカウントのログインの場合、INACTIVE_ACCOUNT_TIMEの計時は、プロキシ・ユーザーが正常にログインしたときに開始されます。

たとえば、アクティブでない状態で60日間経過すると、アカウントをロックするプロファイルを作成するとします。

CREATE PROFILE time_limit LIMIT 
 INACTIVE_ACCOUNT_TIME 60;
3.2.4.7 ログイン試行に指定の回数だけ失敗した後のユーザー・アカウントの自動ロック

Oracle Databaseでは、ログイン試行に指定の回数だけ連続して失敗した後、ユーザーのアカウントをロックできます。

  • 指定した時間間隔が経過した後で自動的にユーザー・アカウントをロックするか、またはロックを解除するためにデータベース管理者の介入を必要とするには、CREATE PROFILE文またはALTER PROFILE文でユーザーのPASSWORD_LOCK_TIMEプロファイル・パラメータを設定します。

    たとえば、時間間隔を10日に設定するには、次のようにします。

    PASSWORD_LOCK_TIME = 10

次のことに注意してください。

  • データベース管理者による明示的な解除を強制するため、手動でアカウントをロックできます。

  • ログインの失敗が許容される回数は、CREATE PROFILE文を使用して指定します。また、アカウントがロックされる時間の長さも指定できます。

  • ユーザーがログインに失敗するたびに、Oracle Databaseでは次第に遅延時間が長くなります。

  • アカウントのロック解除の間隔を指定しない場合、PASSWORD_LOCK_TIMEはデフォルト・プロファイルに指定されている値を想定します。(推奨値は1日です。)PASSWORD_LOCK_TIMEUNLIMITEDとして指定すると、ALTER USER文を使用してアカウントを明示的にロック解除する必要があります。たとえば、PASSWORD_LOCK_TIME UNLIMITEDjohndoeに指定されていると想定して、次の文を使用してjohndoeアカウントをロック解除します。

    ALTER USER johndoe ACCOUNT UNLOCK;
    
  • ユーザーが正常にアカウントにログインすると、Oracle Databaseでは、そのユーザーが失敗したログインの回数がリセットされます。ゼロでない場合、回数はゼロに設定されます。

  • マルチテナント環境では、ロック対象のCDB共通ユーザー・アカウントは、CDB内のすべてのPDBにわたってロックされます。ロック対象のアプリケーション共通ユーザー・アカウントは、アプリケーション・ルートに関連付けられたすべてのPDBにわたってロックされます。

3.2.4.8 例: CREATE PROFILE文を使用したアカウントのロック

CREATE PROFILE文で、ユーザーのログイン試行がCREATE PROFILE設定に違反した場合にユーザー・アカウントをロックできます。

例3-1では、ユーザーjohndoeに対して許容されているログイン失敗の最大回数は10回(デフォルト)、アカウントがロックされる時間の長さは30日です。アカウントのロックは、30日が経過すると自動的に解除されます。

例3-1 CREATE PROFILE文を使用したアカウントのロック

CREATE PROFILE prof LIMIT
 FAILED_LOGIN_ATTEMPTS 10
 PASSWORD_LOCK_TIME 30

ALTER USER johndoe PROFILE prof;
3.2.4.9 ユーザー・アカウントの明示的ロック

ユーザー・アカウントを明示的にロックした場合、アカウントのロックは自動的には解除されません。セキュリティ管理者のみがアカウントのロックを解除できます。

マルチテナント環境では、CDBルートでCDB共通ユーザー・アカウントをロックすると、このユーザーはこのルートに関連付けられたすべてのPDBにログインできなくなり、PDBでこのアカウントのロックを解除することもできなくなります。また、CDB共通アカウントをPDBでローカルにロックできます。これにより、CDB共通ユーザーがそのPDBにログインできなくなります。同様に、アプリケーション・ルートでロックされたアプリケーション共通ユーザー・アカウントは、アプリケーション・ルートに関連付けられたすべてのPDBにログインできず、アプリケーションPDBでこのアプリケーション共通ユーザーのロックを解除することもできません。アプリケーションPDB内でローカルに、アプリケーション共通ユーザーを明示的にロックすることもできます。
  • ユーザー・アカウントを明示的にロックするには、CREATE USER文またはALTER USER文を使用します。

たとえば、次の文はユーザー・アカウントsusanをロックします。

ALTER USER susan ACCOUNT LOCK;
3.2.4.10 ユーザーによる以前のパスワードの再利用の制御

一定の期間、または一定のパスワード変更回数を経過するまで、ユーザーが前のパスワードを再利用しないようにできます。

  • 指定した期間、ユーザーが以前のパスワードを再利用できないようにするには、CREATE PROFILE文またはALTER PROFILE文を使用してパスワードの再利用のルールを構成できます。

次の表に、ユーザーによる前のパスワードの再利用を制御するCREATE PROFILEALTER PROFILEのパラメータを示します。

表3-2 前のパスワードの再利用を制御するパラメータ

パラメータ名 説明および使用方法

PASSWORD_REUSE_TIME

次のいずれかを指定する必要があります。

  • 以前に使用していた同じパスワードを次に使用できるようになるまでの日数(または1日の一部分)を示す数字

  • UNLIMITEDの文字

PASSWORD_REUSE_MAX

次のいずれかを指定する必要があります。

  • パスワードを再利用できるようになるまでに必要なパスワード変更の回数を示す整数

  • UNLIMITEDの文字

パラメータを指定しない場合は、ユーザーがいつでもパスワードを再利用できる状況になります。これはセキュリティの方法としては適切ではありません。

どちらもUNLIMITEDではない場合、両方の条件に一致した場合にのみ再利用できます。つまり、そのパスワードを最後に使用してから、指定された回数のパスワード変更を行っていること、および指定された日数が経過している必要があります。

たとえば、ユーザーAのプロファイルでPASSWORD_REUSE_MAX10PASSWORD_REUSE_TIME30に指定されている場合を考えます。ユーザーAのパスワードは、そのパスワードを最後に使用してから30日が経過し、パスワードを10回再設定するまでは再利用できません。

一方のパラメータがUNLIMITEDに指定されている場合、ユーザーはパスワードを再利用できません。

両方のパラメータをUNLIMITEDに設定している場合は、両方が無視され、ユーザーはいつでもパスワードを再利用できます。

ノート:

いずれかのパラメータにDEFAULTを指定すると、DEFAULTのプロファイルに定義されている値が使用されます。このプロファイルでは、すべてのパラメータがUNLIMITEDに設定されています。したがって、DEFAULTのプロファイルでそのパラメータの設定を変更していない場合は、DEFAULTとして指定されているパラメータにはUNLIMITEDが使用されます。

3.2.4.11 パスワード・エイジングおよび期限切れの制御について

パスワードの存続期間を指定して、この期間を過ぎるとパスワードを期限切れにできます。

つまり、ユーザーは現行の正しいパスワードを使用して次回ログインする際に、パスワードの変更を求められるということです。デフォルトでは、複雑度チェックやパスワード履歴チェックは行われないため、ユーザーは以前のパスワードや脆弱なパスワードを再利用できます。PASSWORD_REUSE_TIMEPASSWORD_REUSE_MAXおよびPASSWORD_VERIFY_FUNCTIONパラメータを設定することによって、これらの要素を制御します。

さらに、猶予期間を設定できます。この期間中は、データベース・アカウントへのログインを試行するたびに、パスワードの変更を求める警告メッセージが発行されます。ユーザーがこの期間内にパスワードを変更しないと、Oracle Databaseではアカウントを期限切れにします。

データベース管理者は、手動でパスワードを期限切れ状態に設定できます(アカウント・ステータスをEXPIREDに設定します)。この場合、ユーザーはログオンを続行する前に、プロンプトに従ってパスワードを変更する必要があります。

たとえば、SQL*Plusにおいて、ユーザーSCOTTは正しい資格証明を使用してログインを試行しますが、パスワードが期限切れだとします。続いて、ユーザーSCOTT「ORA-28001: パスワードが期限切れです。」エラーが表示され、次のようにパスワードの変更を求められます。

Changing password for scott
New password: new_password
Retype new password: new_password
Password changed.
3.2.4.12 CREATE PROFILE文またはALTER PROFILE文を使用したパスワード存続期間の設定

パスワードの存続期間を設定した場合、存続期間の終了時にユーザーは新しいパスワードを作成する必要があります。

  • パスワードの存続期間を指定するには、CREATE PROFILE文またはALTER PROFILE文を使用します。

次の例は、プロファイルを作成してユーザーjohndoeに割り当てる方法を示しています。PASSWORD_LIFE_TIME句によって、johndoeはパスワードの期限が切れるまで180日間同じパスワードを使用できることが指定されています。

CREATE PROFILE prof LIMIT
 FAILED_LOGIN_ATTEMPTS 4
 PASSWORD_GRACE_TIME 3
 PASSWORD_LIFE_TIME 180;
ALTER USER johndoe PROFILE prof;
3.2.4.13 ユーザー・アカウントのステータスの確認

アカウント・ステータスは、オープン、猶予期間、期限切れのいずれの場合も確認できます。

  • ユーザー・アカウントのステータスをチェックするには、DBA_USERSデータ・ディクショナリ・ビューのACCOUNT_STATUS列を問い合せます。

たとえば:

SELECT ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'username';
3.2.4.14 パスワード変更のライフ・サイクル

パスワードが作成されると、そのパスワードは、次の4つのフェーズのライフ・サイクルと猶予期間をたどります。

次の図は、パスワードの存続期間および猶予期間のライフ・サイクルを示しています。

図3-1 パスワード変更のライフ・サイクル

図3-1の説明が続きます
「図3-1 パスワード変更のライフ・サイクル」の説明

この図の内容は次のとおりです。

  • フェーズ1: ユーザー・アカウントが作成されたか、既存のアカウントのパスワードが変更された後、パスワードの存続期間が開始されます。

  • フェーズ2: このフェーズは、パスワードの存続期間が終了したで、正しいパスワードを使用してユーザーが再度ログインするの期間を表しています。Oracle Databaseによってアカウント・ステータスが更新されるためには、正しい資格証明が必要です。それ以外の場合、アカウント・ステータスは変更されません。Oracle Databaseには、アカウント・ステータスを更新するためのバックグラウンド・プロセスは存在しません。アカウント・ステータスの変更はすべて、認証されたユーザーにかわって、Oracle Databaseのサーバー・プロセスによって実行されます。

  • フェーズ3: 最終的にユーザーがログインすると、猶予期間が開始されます。Oracle Databaseによって、現在の時間にそのアカウントのパスワード・プロファイルのPASSWORD_GRACE_TIME設定の値を加えた値が使用されて、DBA_USERS.EXPIRY_DATE列の値が更新されます。この時点でユーザーは、近い将来にパスワードが期限切れするというORA-28002警告メッセージ(たとえば、PASSWORD_GRACE_TIME7日に設定されている場合は、「ORA-28002 パスワードは、7日以内に期限切れになります。」)を受け取りますが、依然としてパスワードを変更することなくログインできます。DBA_USERS.EXPIRY_DATE列には、ユーザーがパスワードを変更するよう求められる将来の時間が示されます。

  • フェーズ4: 猶予期間(フェーズ3)が終了した後、ユーザーが現行の正しいパスワードを入力すると、認証が続行される前に「ORA-28001: パスワードが期限切れです。」エラーが表示されて、パスワードを変更するよう求められます。ユーザーが、Oracle Active Data Guard構成を使用しており(その場合は、プライマリ・データベースとスタンバイ・データベースが存在します)、認証がスタンバイ・データベース(読取り専用データベース)で試行された場合は、「ORA-28032: パスワードの期限が切れており、データベースは読取り専用に設定されています」エラーが表示されます。ユーザーは、プライマリ・データベースにログインして、そこでパスワードを変更する必要があります。

これら4フェーズのいずれの間も、DBA_USERSデータ・ディクショナリ・ビューに問い合せて、DBA_USERS.ACCOUNT_STATUS列でユーザーのアカウント・ステータスを検索できます。

次の例では、johndoeに割り当てられたプロファイルに、猶予期間PASSWORD_GRACE_TIME = 3(推奨値)が指定されています。johndoeは90日後に初めてデータベースにログインしようとすると(これは90日目より後の任意の日、つまり91日目や100日目でも構いません)、パスワードが3日で期限切れになるという警告メッセージを受け取ります。3日経過してもパスワードを変更しない場合は、パスワードの期限が切れます。その後、このユーザーがログインしようとするたびに、パスワードの変更を求めるプロンプトが表示されます。

CREATE PROFILE prof LIMIT
 FAILED_LOGIN_ATTEMPTS 4
 PASSWORD_LIFE_TIME 90
 PASSWORD_GRACE_TIME 3;

ALTER USER johndoe PROFILE prof;

データベース管理者またはALTER USERシステム権限を持つユーザーは、CREATE USER文およびALTER USER文を使用して、任意のパスワードを明示的に期限切れにできます。次の文は、期限切れのパスワードを持つユーザーを作成します。この設定によって、ユーザーがデータベースにログインする前に、強制的にパスワードを変更させることができます。

CREATE USER jbrown 
 IDENTIFIED BY password
 ...
 PASSWORD EXPIRE;

CREATE USER文にパスワードの期限切れを解除する句はありませんが、アカウントのパスワードを変更することによって、期限切れは解除されます。

3.2.4.15 PASSWORD_LIFE_TIMEプロファイル・パラメータの低い値

CREATE PROFILEまたはALTER PROFILEPASSWORD_LIFE_TIMEパラメータを低い値(たとえば1日)に設定する場合は、注意が必要です。

プロファイルのPASSWORD_LIFE_TIME制限は、アカウントのパスワードが最後に変更された時点、またはパスワードが一度も変更されていない場合はアカウントの作成時点から測定されます。これらの日付は、SYS.USER$システム表のPTIME (パスワード変更時間)列およびCTIME (アカウント作成時間)列に記録されています。PASSWORD_LIFE_TIME制限の測定は、PASSWORD_LIFE_TIMEプロファイル・パラメータが最後に変更された時点のタイムスタンプから開始されるのではありません(最初はそう考えがちです)。そのため、変更されたプロファイルによって影響を受けるアカウントで、パスワードの最終変更時間がPASSWORD_LIFE_TIME日前より以前のアカウントは、ただちに期限切れとなり、次回の接続時点で猶予期間に入り、「ORA-28002: パスワードは、n日以内に期限切れになります。」警告が発行されます。

データベース管理者は、次の方法で、アカウントのパスワードの最終変更時間を調べることができます。

ALTER SESSION SET NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS';
SELECT PTIME FROM SYS.USER$ WHERE NAME = 'user_name'; -- Password change time

アカウントの作成時間とパスワードの有効期限を調べるには、次の問合せを発行します。

SELECT CREATED, EXPIRY_DATE FROM DBA_USERS WHERE USERNAME = 'user_name';

管理者がPASSWORD_LIFE_TIMEパラメータを設定した時点で、このプロファイルを割り当てられているユーザーがログイン中であり、そのままログインし続ける場合、現在記載されている有効期限を過ぎても、このユーザーのアカウント・ステータスは、OPENからEXPIRED(GRACE)に変更されません。時間測定が開始されるのは、ユーザーがデータベースにログインした時点のみです。ユーザーの最終ログイン時間を確認する方法は次のとおりです。

SELECT LAST_LOGIN FROM DBA_USERS WHERE USERNAME = 'user_name';

パスワードのプロファイルを変更する際にデータベース管理者が注意すべきなのは、このプロファイルの対象となるユーザーの一部が、管理者がパスワードのプロファイルを更新している時点でOracle Databaseにログイン中であれば、これらのユーザーは、パスワードの有効期限を越えてシステムにログインし続けることが可能だということです。現在ログインしているユーザーを見つけるには、V$SESSIONビューのUSERNAME列を問い合せます。

これは、ユーザーのパスワードの有効期限が、パスワード最終変更時点のタイムスタンプに、管理者の設定したPASSWORD_LIFE_TIMEパスワード・プロファイル・パラメータの値を加えたものに基づいているためです。パスワード・プロファイル自体の最終変更時点のタイムスタンプに基づいているのではありません

次のことに注意してください。

  • PASSWORD_LIFE_TIMEを低い値に設定しているときにユーザーがログインしていない場合、ユーザーのアカウント・ステータスはユーザーがログインするまで変わりません。

  • PASSWORD_LIFE_TIMEパラメータをUNLIMITEDに設定できますが、この設定が作用するのは猶予期間に入っていないアカウントのみです。猶予期間に入っているユーザーは、その期間を過ぎるとパスワードを変更する必要があります。

3.2.5 アプリケーションの段階的データベース・パスワード・ロールオーバーの管理

段階的データベース・パスワード・ロールオーバーを行うと、古いパスワードを指定した期間有効なままにすることで、アプリケーションの停止時間が発生しないようにしながら、新しいパスワードがアプリケーション・クライアントに伝播されている間にアプリケーションのデータベース・パスワードを更新できます。

3.2.5.1 アプリケーションの段階的データベース・パスワード・ロールオーバーの管理について

データベース管理者がアプリケーションのデータベース・パスワードを変更するときに、データベース・アプリケーション・クライアントに対して開始するように段階的なデータベース・パスワード・ロールオーバー・プロセスを構成できます。

データベース管理者またはアプリケーション管理者がデータベース内のアプリケーションのパスワードを変更するときに、アプリケーションを新しいデータベース・パスワードで更新する必要があります。ユーザーのプロファイルにPASSWORD_ROLLOVER_TIMEパラメータを設定すると、アプリケーションが古いパスワードを使用しようとした結果発生する可能性のある停止時間やアプリケーション停止のリスクを回避しながら、パスワード変更を実行できます。パスワード・ロールオーバーはサーバーからシームレスに実行され、サポートされている既存のすべてのクライアント・バージョンで実行されます。

段階的なデータベース・パスワード・ロールオーバー機能は、アプリケーションのデータベース・アカウント(サービス・アカウント)用に設計されています。アプリケーションは、単一のサーバー(データベース・クライアント)にすることも、複数のデータベース・クライアントを持つ複数のサーバーにスケール・アウトすることもできます。管理ユーザー向けには設計されていないため、管理ユーザーは、関連付けられているプロファイルに関係なく、この機能の使用が制限されます。パスワード・ロールオーバーが有効なプロファイルを持つユーザーには管理権限を付与できません。

ネイティブ・パスワード認証ユーザー接続の段階的データベース・パスワード・ロールオーバーを構成できます。パスワード・データベース・アカウントをNO AUTHENTICATIONアカウントに変換すると、Oracle Databaseはこのアカウントに関連付けられているパスワードおよびベリファイアを削除します。パスワード認証済ユーザー・アカウントがGLOBALEXTERNALまたはNO AUTHENTICATIONアカウントに変換されると、ユーザーはパスワードのロールオーバー期間を暗黙的に終了します。段階的パスワード・ロールオーバーは、11gパスワード・バージョン以降をサポートしています。

また、接続されたユーザー・データベース・リンクを使用する環境について、段階的データベース・パスワード・ロールオーバーを構成することもできます。この場合、段階的データベース・パスワード・ロールオーバーを構成するときに、接続されているユーザー・データベース・リンクのターゲットでターゲット・アカウントをロールオーバーにすることを確認してから、これらのリンクのターゲット・アカウントもロールオーバーします。ターゲット・アカウントをロールオーバーにするには、次の構文を使用します。

ALTER USER username IDENTIFIED BY same_new_rollover_password;

段階的データベース・パスワード・ロールオーバーは、次の接続には構成できません。

  • Oracle Real Application Securityユーザーの直接ログイン
  • Kerberosベース、証明書ベースまたはRADIUSベースの外部認証接続
  • 集中管理ユーザー(CMU)接続
  • 外部パスワード・ファイルを使用する管理接続
  • プライマリとスタンバイ間のOracle Data Guard接続
3.2.5.2 段階的データベース・パスワード・ロールオーバー中のパスワード変更ライフ・サイクル

パスワードが作成または変更されると、そのパスワードは、4つのフェーズのライフ・サイクルと猶予期間をたどります。

次の図は、パスワードの存続期間および猶予期間のライフ・サイクルを示しています。

図3-2 段階的データベース・パスワード・ロールオーバー中のパスワード変更ライフ・サイクル

図3-2の説明が続きます
「図3-2 段階的データベース・パスワード・ロールオーバー中のパスワード変更ライフ・サイクル」の説明

この図の内容は次のとおりです。

  • フェーズ1: パスワードの存続期間は、ユーザー・アカウントが作成された後、またはパスワードが変更されたときに始まります。既存のアカウントのパスワードが変更され、ユーザーのプロファイルのPASSWORD_ROLLOVER_TIME値がゼロ以外の場合、パスワードの存続期間は1aと1bの2つのフェーズで構成されます。

    • フェーズ1aはパスワード変更から始まります。フェーズ1aでは、ユーザーは旧パスワードまたは新規パスワードのいずれかを使用してログインできます。フェーズ1aの期間は通常PASSWORD_ROLLOVER_TIMEですが、管理者がこれより早くすべてのクライアント・アプリケーションでパスワードを更新できる場合は、次のコマンドを発行してパスワード・ロールオーバー期間を早く終了できます。これにより、新しいパスワードが受け入れられる唯一のパスワードになります。
      ALTER USER username EXPIRE PASSWORD ROLLOVER PERIOD;
    • フェーズ1bは、パスワード・ロールオーバー期間が終了してからPASSWORD_LIFE_TIMEが終了するまでの残り時間に対応します。フェーズ1bでは、ユーザーは新しいパスワードのみを使用してログインできます。
  • フェーズ2: このフェーズは、パスワードの存続期間が終了したで、正しいパスワードを使用してユーザーが再度ログインするの期間を表しています。Oracle Databaseによってアカウント・ステータスが更新されるためには、正しい資格証明が必要です。それ以外の場合、アカウント・ステータスは変更されません。Oracle Databaseには、アカウント・ステータスを更新するためのバックグラウンド・プロセスは存在しません。アカウント・ステータスの変更はすべて、認証されたユーザーにかわって、Oracle Databaseのサーバー・プロセスによって実行されます。

  • フェーズ3: 最終的にユーザーがログインすると、猶予期間が開始されます。Oracle Databaseによって、現在の時間にそのアカウントのパスワード・プロファイルのPASSWORD_GRACE_TIME設定の値を加えた値が使用されて、DBA_USERS.EXPIRY_DATE列の値が更新されます。この時点でユーザーは、近い将来にパスワードが期限切れするというORA-28002警告メッセージ(たとえば、PASSWORD_GRACE_TIME7日に設定されている場合は、「ORA-28002 パスワードは、7日以内に期限切れになります。」)を受け取りますが、依然としてパスワードを変更することなくログインできます。DBA_USERS.EXPIRY_DATE列には、ユーザーがパスワードを変更するよう求められる将来の時間が示されます。

  • フェーズ4: 猶予期間(フェーズ3)が終了した後、ユーザーが現行の正しいパスワードを入力すると、認証が続行される前に「ORA-28001: パスワードが期限切れです。」エラーが表示されて、パスワードを変更するよう求められます。ユーザーが、Oracle Active Data Guard構成を使用しており(その場合は、プライマリ・データベースとスタンバイ・データベースが存在します)、認証がスタンバイ・データベース(読取り専用データベース)で試行された場合は、「ORA-28032: パスワードの期限が切れており、データベースは読取り専用に設定されています」エラーが表示されます。ユーザーは、プライマリ・データベースにログインして、そこでパスワードを変更する必要があります。

これら4フェーズのいずれの間も、DBA_USERSデータ・ディクショナリ・ビューに問い合せて、DBA_USERS.ACCOUNT_STATUS列でユーザーのアカウント・ステータスを検索できます。

次の例では、johndoeに割り当てられたプロファイルに、猶予期間PASSWORD_GRACE_TIME = 3(推奨値)が指定されています。johndoeは90日後に初めてデータベースにログインしようとすると(これは90日目より後の任意の日、つまり91日目や100日目でも構いません)、パスワードが3日で期限切れになるという警告メッセージを受け取ります。3日経過してもパスワードを変更しない場合は、パスワードの期限が切れます。その後、このユーザーがログインしようとするたびに、パスワードの変更を求めるプロンプトが表示されます。

CREATE PROFILE prof LIMIT
 FAILED_LOGIN_ATTEMPTS 4
 PASSWORD_LIFE_TIME 90
 PASSWORD_GRACE_TIME 3;

ALTER USER johndoe PROFILE prof;

データベース管理者またはALTER USERシステム権限を持つユーザーは、CREATE USER文およびALTER USER文を使用して、任意のパスワードを明示的に期限切れにできます。次の文は、期限切れのパスワードを持つユーザーを作成します。この設定によって、ユーザーがデータベースにログインする前に、強制的にパスワードを変更させることができます。

CREATE USER jbrown 
 IDENTIFIED BY password
 ...
 PASSWORD EXPIRE;

CREATE USER文にパスワードの期限切れを解除する句はありませんが、アカウントのパスワードを変更することによって、期限切れは解除されます。

3.2.5.3 段階的データベース・パスワード・ロールオーバーの有効化

段階的データベース・パスワード・ロールオーバーを有効にするには、PASSWORD_ROLLOVER_TIMEユーザー・プロファイル・パラメータを構成する必要があります。

  • 段階的データベース・パスワード・ロールオーバーを構成するには、CREATE PROFILE文またはALTER PROFILE文でPASSWORD_ROLLOVER_TIMEパラメータを設定します。
    たとえば、段階的パスワード・ロールオーバー期間を1日に設定するには、次のようにします。
    CREATE PROFILE prof LIMIT
     ...
     PASSWORD_ROLLOVER_TIME 1;

    次のことに注意してください。

    • ロールオーバー期間は日数で指定しますが、必要に応じて時間を指定できます。たとえば、1/24と入力して1時間を指定したり、6/24(または1/4)と入力して6時間を指定します。
    • アクティブなロールオーバー時間の最小値は1時間です。最大値は60日か、PASSWORD_LIFE_TIMEまたはPASSWORD_GRACE_TIMEパラメータの小さいほうの値です。PASSWORD_GRACE_TIME0 (ゼロ)に設定されている場合、PASSWORD_ROLLOVER_TIMEによる制限に関して無視されます。次の表に、これらの制限を示します。

      表3-3 パスワード・ロールオーバー時間制限

      プロファイル名 PASSWORD_LIFE_TIME PASSWORD_GRACE_TIME PASSWORD_ROLLOVER_TIME
      デフォルト 180 7
      • 最小: 1/24 (1時間)
      • 最大: 7 (日)
      ORA_STIG_PROFILE 60 5
      • 最小: 1/24 (1時間)
      • 最大: 5 (日)
      ユーザー・カスタム・プロファイル 365 90
      • 最小: 1/24 (1時間)
      • 最大: 60 (日)
    • PASSWORD_ROLLOVER_TIMEのデフォルト設定は0またはNULLで、これは無効化です。
    • パスワード・ロールオーバー・プロセスに現在存在するデータベース・アカウントを確認するには、DBA_USERSデータ・ディクショナリ・ビューのACCOUNT_STATUS列を問い合せます。ステータスはIN ROLLOVERになります。
    • パスワード・ロールオーバー期間は、管理者がデータベース・アカウントのパスワードを変更した時点から始まります。
3.2.5.4 段階的データベース・パスワード・ロールオーバー期間を開始するためのパスワードの変更

ゼロ以外のPASSWORD_ROLLOVER_TIME値を設定した後、ユーザーのパスワードを変更し、すべてのアプリケーションでパスワードを更新します。

ALTER USER文を使用して、アプリケーションの新しいロールオーバー・パスワードをプロビジョニングします。ユーザーの新規パスワードがデータベースにプロビジョニングされたら、アプリケーション・サーバー上のパスワードを更新できます。PASSWORD_ROLLOVER_TIME期間が終了する前に、パスワードの更新を完了しておく必要があります。
DBA_USERSデータ・ディクショナリ・ビューのACCOUNT_STATUS列を問い合せて、ユーザーのパスワード・ロールオーバー・ステータスを確認できます。ロールオーバー期間内のユーザー・アカウントのステータスはIN ROLLOVERになります。
  • CREATE USER文およびALTER USER文を使用して、ユーザー、関連付けられたプロファイルおよびパスワード・ロールオーバー期間を構成します。CREATE USERを使用すると、管理者はパスワード・ロールオーバー付きのプロファイルに関連付けられた新しいアプリケーション・サービス・アカウントを作成できます。ALTER USERは、既存のユーザーに新規または変更されたプロファイルを関連付けるケースに適しています。プロファイルを変更するには、ALTER PROFILE文を使用します。

    次の例のCREATE USERでは、パスワードp1とプロファイルprof1を使用して、新しいユーザーu1PASSWORD_ROLLOVER_TIME付きで構成します。ALTER USER文は、ユーザーのパスワードを変更してパスワードのロールオーバー期間を開始します。ユーザー・ステータスを確認するには、DBA_USERSデータ・ディクショナリ・ビューを問い合せます。

    1. プロファイルprof1を作成します。
      CREATE PROFILE prof1
      LIMIT
      PASSWORD_ROLLOVER_TIME 1;
    2. ユーザーu1を作成し、このユーザーをprof1プロファイルに関連付けます。
      CREATE USER u1 IDENTIFIED BY p1 PROFILE prof1;
    3. ユーザーのパスワードを変更します。
      
      ALTER USER u1 IDENTIFIED BY p2;
    4. DBA_USERデータ・ディクショナリ・ビューを問い合せて、ユーザーのロールオーバー・ステータスを確認します。
      SELECT USERNAME, ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'U1';
      
      USERNAME ACCOUNT_STATUS
      –------- –-----------------
      U1       OPEN & IN ROLLOVER
3.2.5.5 段階的データベース・パスワード・ロールオーバー期間中のパスワードの変更

ロールオーバー期間の開始後も、パスワードを変更できます。

たとえば、誤ってパスワードを入力したとします。次の手順では、ロールオーバー・プロセスがすでに開始されている場合でも、パスワードを修正できます。
  • ロールオーバー・プロセスの開始後にパスワードを変更するには、REPLACE句を指定して、または指定せずにALTER USER文を使用します。
    たとえば、ユーザーu1が元のパスワードp1を使用しており、ロールオーバー・プロセスを開始した新しいパスワードがp2のときに、パスワードp2のかわりに別のパスワードp3を使用するように切り替えるとします。次の文のいずれかが機能します。
    ALTER USER u1 IDENTIFIED BY p3;
    
    ALTER USER u1 IDENTIFIED BY p3 REPLACE p1;
    
    ALTER USER u1 IDENTIFIED BY p3 REPLACE p2;
パスワードをp3に変更した後、ユーザーはp1またはp3を使用してログインできます。p2を使用してログインしようとすると、「ORA-1017 無効なユーザー名/パスワード」エラーが返され、失敗したログイン試行として記録されます。同様に、ロールオーバー期間中にパスワードが次にp3からp4に変更された後、ユーザーはp1またはp4のいずれかを使用してログインできます。p2またはp3を使用してログインしようとすると、「ORA-1017 無効なユーザー名/パスワード」エラーが返され、失敗したログイン試行として記録されます。

ロールオーバーの開始時間は、ユーザーがパスワードを初めて変更したときに固定されます。パスワードのロールオーバー期間中にさらにパスワードを変更しても、開始時間は影響を受けません。この設計により、パスワードがパスワード・ロールオーバー期間外に変更された後、古いパスワードをPASSWORD_ROLLOVER_TIME期間に使用できる期間が制限されます。

3.2.5.6 パスワード・ロールオーバー期間の終了

パスワード・ロールオーバー期間を終了するには、複数の方法があります。

たとえば、p1がユーザーu1の元のパスワードであり、p2がすべてのクライアントに更新された新しいパスワードであるとします。
  • 次のいずれかの方法で、パスワード・ロールオーバー期間を終了します。
    • パスワード・ロールオーバー期間をそのまま期限切れにします。たとえば、パスワード・ロールオーバー期間が1日の場合、1日待機すると、パスワード・ロールオーバー期間は自動的に期限切れになります。

    • ユーザーまたは管理者として、次の文を実行して、パスワード・ロールオーバー期間を手動で終了します。
      ALTER USER u1 EXPIRE PASSWORD ROLLOVER PERIOD;
    • 管理者として、ALTER USER username PASSWORD EXPIRE文を実行してパスワードを期限切れにします。ユーザーが次にログインすると、パスワードの変更を求められます。

パスワード・ロールオーバー期間が経過した後の最初の接続試行以降、Oracle Databaseは以前のパスワードp1を削除します。古いパスワードp1を使用してログインしようとすると、「ORA-1017 無効なユーザー名/パスワード」エラーが返され、失敗したログイン試行として記録されます。実際には、ロールオーバー期間後の接続は新しいパスワードでのみ認証され、古いパスワードで試行された接続は失敗したログイン試行として記録されます。ログイン試行の失敗が、古いパスワードを使用した連続ログオン試行が一定回数を超えると、アカウントがロックされる可能性があります。

PASSWORD_ROLLOVER_TIMEの有効期限が切れた後に読取り専用データベース・サーバーへの接続を試行するには、新しいパスワード(p2)が必要です。p2へのパスワード変更は、すべてのデータベース・クライアントに対して有効になります。

3.2.5.7 段階的パスワード・ロールオーバー期間中のデータベース動作

ユーザーは、パスワード・ロールオーバー期間中に標準のパスワード変更およびログインを実行できます。

ロールオーバー期間中には、次のデータベース動作が実装されます。

  • ユーザーは、新しいパスワードまたは古いパスワードのいずれかを使用してデータベースにログインできます。これにより、PASSWORD_ROLLOVER_TIMEで設定された時間だけ、古いパスワードの存続期間が事実上長くなります。
  • パスワードは、次の方法で変更できます。
    • 管理者またはユーザーは、ALTER USER文を使用して自分のパスワードを変更します。
    • ユーザーは、SQL*Plusのpasswordコマンドを使用して自分のパスワードを変更します。
    • ユーザーのパスワードは、Oracle Call Interface (Oracle OCI)のOCIPasswordChange関数の実行時にプログラムによって変更されます。
  • Oracle Databaseは、ユーザー・アカウントがパスワード・ロールオーバー期間内であることを示す特別なメッセージをデータベース・クライアントに送信しません。この設計により、ユーザーがログインしたときのエラーおよび警告メッセージを処理するように設定されていない可能性のあるアプリケーションからのエラーを回避できます。
  • 失敗したログイン試行が多すぎると、プロファイル制限PASSWORD_LOCK_TIMEの値に応じて、ユーザー・アカウントがタイム・ロック状態に移行します。タイム・ロック期間が経過すると、パスワード・ロールオーバー期間の状態によって、ユーザーがログインを試行したときの処理が決まります。
  • ユーザー管理者は、ACCOUNT LOCKACCOUNT UNLOCKEXPIRE PASSWORD操作など、他のパスワード・ライフサイクル関連のアクションを通常どおりに実行できます。
  • ユーザー・プロファイルのPASSWORD_REUSE_TIMEおよびPASSWORD_REUSE_MAXによって設定されたパスワード制限は、ロールオーバー期間中も引き続き適用されます。ロールオーバー期間中のパスワード変更は、パスワード変更履歴に対して検証され、パスワード変更履歴に追加されます。
  • ユーザー・アカウントを期限切れにしても、パスワードのロールオーバー・ステータスには影響しません。ロックされたアカウントと同様に、Oracle Databaseはパスワード・ベリファイアを現在の状態で保持します。ユーザーは、古いパスワードまたは新しいパスワード(p1またはp2)を使用してログインできます。ただし、ユーザーがパスワードを正常に(p3に)変更した後、ユーザーは最新のパスワード(p3)のみを使用してログインできます。古いパスワードは両方とも期限切れとして扱われます。
  • Oracle Data Pumpは、パスワード・ロールオーバー期間中のユーザー・アカウントの最新パスワードのパスワード・ハッシュ(ベリファイアとも呼ばれる)をエクスポートします。たとえば、ユーザーu1に古いパスワードp1と新しいパスワードp2がある場合、Oracle Data Pumpはパスワードp2のパスワード・ハッシュのみをエクスポートします。
3.2.5.8 パスワード・ロールオーバー期間終了後のデータベース・サーバーの動作

Oracle Databaseは、段階的データベース・パスワード・ロールオーバー期間の終了後にクリーン・アップ操作を実行します。

パスワード・ロールオーバー期間が終了すると、新しいパスワードのみが許可され、古いパスワードは機能しなくなります。古いパスワードを使用しようとすると、「ORA-1017 無効なユーザー名/パスワード」エラーが返され、失敗したログイン試行として記録されます。パスワード・ロールオーバー期間後の接続では新しいパスワードのみが使用され、以前のパスワードを使用しようとすると、読取り専用データベースと読取り/書込みデータベースの両方で失敗します。ログイン試行に失敗すると、パスワード・プロファイルのFAILED_LOGIN_ATTEMPTS制限に基づいて、古いパスワードを使用した連続するログイン試行回数に応じて、ユーザー・アカウントがロックされる可能性があります。

3.2.5.9 漏えいしたパスワードの処理に関するガイドライン

データベース・アカウント・パスワードが漏えいしたと思われる場合は、すぐにパスワードを変更する必要があります。

2つのコマンドを順番に実行するのではなく、1回の実行でALTER USER文を使用して、古いパスワードを変更および期限切れにすることによって、パスワード・ロールオーバー期間を経由せずにこの変更を実行できます。このオプションは、他のアカウントが影響を受けるため、関連するユーザー・プロファイルのPASSWORD_ROLLOVER_TIMEの変更よりも優先されます。

次の構文を使用して、古いパスワードを変更および期限切れにします。

ALTER USER user_name IDENTIFIED BY new_password EXPIRE PASSWORD ROLLOVER PERIOD;
3.2.5.10 Oracle Data Pumpのエクスポート時の段階的データベース・パスワード・ロールオーバーの動作

パスワード・ロールオーバー期間中のユーザーがエクスポートされた場合、そのユーザーの新しいパスワードに対応するベリファイアのみがエクスポートされます。

古いパスワードに対応するベリファイアは、Oracle Data Pumpダンプ・ファイルには含まれません。ユーザーがインポートされた後は、認証には新しいパスワードのみを使用できます。

3.2.5.11 Oracle Data Guard環境での段階的データベース・パスワード・ロールオーバーの使用

Oracle Data Guard環境で、段階的データベース・パスワード・ロールオーバーを使用するには、ADG_ACCOUNT_INFO_TRACKING環境変数をGLOBALに設定する必要があります。

ADG_ACCOUNT_INFO_TRACKING=GLOBAL

それ以外の場合、PASSWORD_ROLLOVER_TIMEの有効期限後にロールオーバー・パスワードを使用しているユーザーによってOracle Data Guardスタンバイで初期ログオンが実行されると、「ORA-16000: データベースまたはプラガブル・データベースは読取り専用アクセスでオープンされています」エラーになります。

3.2.5.12 古いパスワードをまだ使用しているユーザーの検索

LOGIN監査レコードのAUTHENTICATION_TYPEフィールドを使用する問合せを実行して、古いパスワードをまだ使用しているユーザーを検索できます。

統合監査証跡では、古いパスワードを使用してデータベースにまだ接続しているユーザーを識別できます。LOGON監査レコードのAUTHENTICATION_TYPEフィールドは、古いベリファイアが使用されたかどうかを示すことができます。この情報を使用すると、段階的なデータベース・パスワードのロールオーバーで更新されていないアプリケーションを検索して、新しいパスワードを使用できます。LOGON監査レコードは、どのアプリケーション・サーバーを更新する必要があるかを示します。
  1. AUDIT_VIEWERまたはAUDIT_MGMTロールを持つユーザーとしてデータベースに接続します。
  2. 次の問合せを実行します。
    SELECT DBUSERNAME, AUTHENTICATION_TYPE, OS_USERNAME, USERHOST, EVENT_TIMESTAMP 
    FROM UNIFIED_AUDIT_TRAIL 
    WHERE ACTION_NAME='LOGON' AND EVENT_TIMESTAMP > SYSDATE-1
    AND REGEXP_LIKE(AUTHENTICATION_TYPE, '\(VERIFIER=.*?\-OLD\)');

    古いパスワードをまだ使用しているユーザーがいる場合は、次のような出力が表示されます。

    DBUSERNAME    AUTHENTICATION_TYPE                                                                                                                                              OS_USERNAME    USERHOST    EVENT_TIMESTAMP
    _____________ ________________________________________________________________________________________________________________________________________________________________ ______________ ___________ __________________________________
    APP_USER      (TYPE=(DATABASE));(CLIENT ADDRESS=((PROTOCOL=tcp)(HOST=192.0.2.225)(PORT=24938)));(LOGON_INFO=((VERIFIER=12C-OLD)(CLIENT_CAPABILITIES=O5L_NP,O7L_MR,O8L_LI)));    oracle         db211       14-JAN-21 08.56.34.724172000 PM
    APP_USER      (TYPE=(DATABASE));(CLIENT ADDRESS=((PROTOCOL=tcp)(HOST=192.0.2.225)(PORT=24983)));(LOGON_INFO=((VERIFIER=12C-OLD)(CLIENT_CAPABILITIES=O5L_NP,O7L_MR,O8L_LI)));    oracle         db211       14-JAN-21 09.01.18.938008000 PM
    APP_USER      (TYPE=(DATABASE));(CLIENT ADDRESS=((PROTOCOL=tcp)(HOST=192.0.2.226)(PORT=48727)));(LOGON_INFO=((VERIFIER=12C-OLD)(CLIENT_CAPABILITIES=O5L_NP,O7L_MR,O8L_LI)));    oracle         db212       14-JAN-21 10.10.48.042817000 PM
    APP_USER      (TYPE=(DATABASE));(CLIENT ADDRESS=((PROTOCOL=tcp)(HOST=192.0.2.226)(PORT=48745)));(LOGON_INFO=((VERIFIER=12C-OLD)(CLIENT_CAPABILITIES=O5L_NP,O7L_MR,O8L_LI)));    oracle         db212       14-JAN-21 10.12.53.609965000 PM
    APP_USER      (TYPE=(DATABASE));(CLIENT ADDRESS=((PROTOCOL=tcp)(HOST=192.0.2.226)(PORT=48751)));(LOGON_INFO=((VERIFIER=12C-OLD)(CLIENT_CAPABILITIES=O5L_NP,O7L_MR,O8L_LI)));    oracle         db212       14-JAN-21 10.13.41.112194000 PM
    

3.2.6 パスワードの複雑度の管理

Oracle Databaseには、パスワードの複雑度の管理に使用できる一連の関数があります。

3.2.6.1 パスワードの複雑度検証について

複雑度検証では、パスワードを推定してシステムに入ろうとする侵入者から保護できるだけの複雑性が各パスワードに備わっているかがチェックされます。

複雑度検証ファンクションを使用すると、データベース・ユーザー・アカウントに対して強力で安全性の高いパスワードが強制的に作成されます。ユーザーのパスワードは、パスワードを推定してシステムに入ろうとする侵入者に対して、十分保護可能な複雑なものである必要があります。

3.2.6.2 Oracle Databaseによるパスワードの複雑度のチェック方法

Oracle Databaseにはパスワードの複雑度をチェックするパスワード検証機能が4つ用意されています。

これらの関数は、($ORACLE_HOME/rdbms/adminにある)catpvf.sql PL/SQLスクリプト内にあります。これらの関数が有効になっている場合、ユーザーがパスワードを正しく作成または変更したかどうかを確認できます。有効にすると、パスワードの複雑度のチェックはユーザーSYSに対して適用されず、SYS以外のユーザーにのみ適用されます。パスワードのセキュリティを強化するには、パスワード検証ファンクションとデフォルト・プロファイルを関連付けることをお薦めします。パスワード複雑度検証のカスタマイズについてには、これを実行する方法の例が示されています。

3.2.6.3 パスワード複雑度ファンクションを使用できるユーザー

パスワード複雑度ファンクションを使用すると、ユーザーがデータにアクセスする方法をカスタマイズできます。

パスワード複雑度検証ファンクションをCREATE PROFILE文またはALTER PROFILE文で使用する前に、そのファンクションに対するEXECUTE権限が付与される必要があります。

パスワード検証ファンクションは、SYSスキーマにあります。

3.2.6.4 verify_function_11G関数のパスワード要件

verify_function_11Gファンクションは、Oracle Databaseリリース11gから開始されました。

ノート:

verify_function_11Gファンクションは、Oracle Databaseの以前のリリースの弱いパスワード制限が強制されるため、非推奨となりました。かわりに、より強力かつ最新のパスワード検証制限を強制するORA12C_VERIFY_FUNCTIONORA12C_STRONG_VERIFY_FUNCTIONORA12C_STIG_VERIFY_FUNCTIONファンクションを使用することが望まれます。

このファンクションでは、ユーザーがパスワードを作成または変更したときに、次の要件をチェックします。

  • パスワードの長さが8文字以上であり、少なくとも数字が1つと英字が1つ含まれていること。

  • パスワードがユーザー名と同一でないこと。ユーザー名のスペルを逆にしたり、ユーザー名に数字1から100を追加したパスワードでないこと。

  • サーバー名と同一であったり、サーバー名に数字1から100を追加したパスワードでないこと。

  • パスワードにoracleが含まれていないこと(たとえば、oracleに数字1から100を追加したものなど)。

  • パスワードを単純にしすぎないこと(たとえば、welcome1database1account1user1234password1oracle123computer1abcdefg1またはchange_on_install)。

  • 以前のパスワードとの違いが3文字以上あること。

次の内部チェックも適用されます。

  • パスワードが二重引用符文字(")を含まないこと。ただし、二重引用符で囲むことができます。

3.2.6.5 ora12c_verify_functionのパスワード要件

ora12c_verify_functionファンクションは、Department of Defense Database Security Technical Implementation Guideの要件を満たしています。

このファンクションでは、ユーザーがパスワードを作成または変更したときに、次の要件をチェックします。

  • パスワードの長さが8文字以上であり、少なくとも数字が1つと英字が1つ含まれていること。

  • パスワードがユーザー名またはユーザー名のスペルを逆にしたものと同一でないこと。

  • パスワードがデータベース名と同一でないこと。

  • パスワードにoracle (oracle123など)の語が含まれていないこと。

  • 以前のパスワードとの違いが3文字以上あること。

  • パスワードに少なくとも1つの特殊文字が含まれていること。

次の内部チェックも適用されます。

  • パスワードが二重引用符文字(")を含まないこと。ただし、二重引用符で囲むことができます。

3.2.6.6 ora12c_strong_verify_function関数のパスワード要件

ora12c_strong_verify_function関数は、厳密なパスワード検証関数です。

このファンクションでは、ユーザーがパスワードを作成または変更したときに、次の要件をチェックします。

  • パスワードが9文字以上である。

  • パスワードに大文字が2つ以上含まれている。

  • パスワードに小文字が2つ以上含まれている。

  • パスワードに少なくとも2つの数字が含まれている。

  • パスワードに少なくとも2つの特殊文字が含まれている。これらの特殊文字は次のとおりです。

    ‘ ~ ! @ # $ % ^ & * ( ) _ - + = { } [ ] \ / < > , . ; ? ' : | (space) 
  • 以前のパスワードとの違いが4文字以上あること。

次の内部チェックも適用されます。

  • パスワードが二重引用符文字(")を含まないこと。ただし、二重引用符で囲むことができます。

3.2.6.7 ora12c_stig_verify_functionのパスワード要件

ora12c_stig_verify_functionファンクションは、Security Technical Implementation Guides (STIG)の要件を満たしています。

このファンクションでは、ユーザーがパスワードを作成または変更したときに、次の要件をチェックします。

  • パスワードが15文字以上であること。

  • パスワードに少なくとも1文字以上の小文字と、1文字以上の大文字が含まれていること。

  • パスワードに少なくとも1つの数字が含まれていること。

  • パスワードに少なくとも1つの特殊文字が含まれていること。

  • 以前のパスワードとの違いが8文字以上あること。

次の内部チェックも適用されます。

  • パスワードが二重引用符文字(")を含まないこと。ただし、二重引用符で囲むことができます。

ora12c_stig_verify_functionファンクションはORA_STIG_PROFILEプロファイルのデフォルト・ハンドラであり、新しく作成されたOracleデータベースまたはアップグレードされたOracleデータベースで使用できます。

3.2.6.8 パスワード複雑度検証のカスタマイズについて

Oracle Databaseを使用すると、サイトのパスワード複雑度をカスタマイズできます。

admin/catpvf.sqlに定義される関数と同様、SYSスキーマに独自のパスワードの複雑度検証関数を作成できます。サイトのパスワードの保護を強化するために、独自のパスワード複雑度検証関数を作成することをお薦めします。

次のことに注意してください。

  • データ定義言語(DDL)文は、カスタムのパスワード複雑度検証関数に含めないでください。パスワード複雑度検証関数の実行中、DDLは使用できません。

  • admin/catpvf.sqlスクリプトまたはOracle提供のパスワード複雑度関数は変更しないでください。これらのファイルの内容に基づいて、独自の関数を作成できます。

  • utlpwdmg.sqlスクリプトを変更しない場合、デフォルト関数としてora12c_verify_function関数を使用します。

関連項目:

パスワードの作成に関するガイドラインは、「パスワードの保護に関するガイドライン」のガイドライン1を参照してください。
3.2.6.9 パスワード複雑度検証の有効化

catpvf.sqlスクリプトをカスタマイズして、パスワードの複雑度検証を有効にできます。

パスワード複雑度検証を有効にするには、必要なパスワード検証ファンクションを使用するようにcatpvf.sqlスクリプトを編集し、そのスクリプトを実行して検証を有効にする必要があります。
  1. 管理者権限を使用してSQL*Plusにログインします。

    たとえば:

    CONNECT SYSTEM
    Enter password: password
    
  2. catpvf.sqlスクリプト(またはこのスクリプトの変更されたバージョン)を実行して、SYSスキーマのパスワード複雑度関数を作成します。
    @$ORACLE_HOME/rdbms/admin/catpvf.sql
    
  3. このファンクションを使用する必要があるユーザーに、ファンクションに対するEXECUTE権限を付与します。

    たとえば:

    GRANT pmsith EXECUTE ON ora12c_strong_verify_function;
    
  4. デフォルト・プロファイルまたはユーザー・プロファイルで、PASSWORD_VERIFY_FUNCTION設定を、catpvf.sqlスクリプトのサンプルのパスワード複雑度関数か、カスタマイズした関数に設定します。次のいずれかの方法を使用します。
    • 管理者権限でSQL*Plusにログインし、CREATE PROFILE文またはALTER PROFILE文を使用して関数を使用可能にします。ファンクションに対するEXECUTE権限があることを確認します。

      たとえば、デフォルト・プロファイルを更新してora12c_strong_verify_function関数を使用するには、次のようにします。

      ALTER PROFILE default LIMIT 
       PASSWORD_VERIFY_FUNCTION ora12c_strong_verify_function;
      
    • Oracle Enterprise Manager Cloud Controlで、「管理」メニューから、「セキュリティ」を選択し、「プロファイル」を選択します。「パスワード」タブを選択します。「複雑なパスワード検証」で、「複雑なパスワード検証のための関数」リストから、使用する複雑度関数の名前を選択します。「適用」をクリックします。

パスワード複雑度検証は、使用可能にするとすぐに有効になります。無効にする必要がある場合、次の文を実行します。

ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION NULL;

ノート:

ALTER USER文でREPLACE句を使用できます。ユーザーは、この句を使用して、自身を認証するために以前のパスワードを指定し、期限が切れていない自分のパスワードを変更できます。

パスワードが期限切れになると、ユーザーはSQLにログインしてALTER USERコマンドを発行できません。かわりにOCIPasswordChange()関数を使用しますが、この場合は以前のパスワードも必要になります。

ALTER ANY USER権限が付与されているデータベース管理者は、古いパスワードを指定せずにユーザーのパスワードを変更(新しいパスワードを適用)できます。

3.2.7 パスワードでの大/小文字の区別の管理

以前のリリースのユーザー・アカウントのパスワードに対して、パスワードの大/小文字の区別を管理できます。

3.2.7.1 SEC_CASE_SENSITIVE_LOGONパラメータおよびパスワードの大/小文字の区別

SEC_CASE_SENSITIVE_LOGON初期化パラメータは、パスワードでの大/小文字の区別の使用を制御します。

SEC_CASE_SENSITIVE_LOGONパラメータを設定できるのは、ALTER SYSTEM権限を持つユーザーのみです。このパラメータがTRUEに設定されていて、ユーザーがパスワードを入力するときに大/小文字の区別が適用されることを確認する必要があります。(ただし、SEC_CASE_SENSITIVE_LOGONパラメータが非推奨ですが、下位互換性のために現在残されていることに注意してください。)

ユーザー・アカウントを作成または変更するとき、パスワードはデフォルトで大/小文字の区別があります。大/小文字の区別は、ユーザーが手動で入力するパスワードのみでなく、パスワード・ファイルにも影響を与えます。

SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータが12または12aに設定されている場合は、SEC_CASE_SENSITIVE_LOGONパラメータがFALSEに設定されていないことを確認します。これは、このモードで使用されているセキュリティ度の強いパスワード・バージョンでは、大文字/小文字を区別するパスワード・チェックのみがサポートされているためです。互換性上の理由により、Oracle DatabaseではSQLNET.ALLOWED_LOGON_VERSION_SERVER12または12aに設定されているときにSEC_CASE_SENSITIVE_LOGONFALSEの使用が禁止されてはいません。SQLNET.ALLOWED_LOGON_VERSION_SERVER12または12aに設定されている場合にSEC_CASE_SENSITIVE_LOGONFALSEに設定すると、すべてのアカウントがアクセス不能になります。SQLNET.ALLOWED_LOGON_VERSION_SERVER11以下の値に設定されている場合は、Oracle Database 12cの排他モード(SQLNET.ALLOWED_LOGON_VERSION_SERVER12または12aの場合)で使用されるセキュリティ度の強いパスワード・バージョンが大文字/小文字を区別しないパスワード照合をサポートしないため、SEC_CASE_SENSITIVE_LOGONTRUEに設定することをお薦めします。

サーバー側の設定に加えて、ユーザーが接続しているクライアント・ソフトウェアにO5L_NP機能フラグがあることを確認する必要があります。Oracle Databaseリリース11.2.0.3以上のすべてのクライアントにO5L_NP機能があります。以前のクライアントがある場合は、CPUOct2012パッチをインストールする必要があります。

3.2.7.2 ALTER SYSTEM文を使用したパスワードの大/小文字の区別の有効化

パスワードの大/小文字の区別が無効化されている場合、有効化するには、SEC_CASE_SENSITIVE_LOGONパラメータをTRUEに設定します。

  1. パスワード・ファイルを使用している場合、ORAPWDユーティリティのIGNORECASEパラメータがNに設定されて作成され、FORMATパラメータが12に設定されていることを確認します。

    IGNORECASEパラメータによりSEC_CASE_SENSITIVE_LOGONパラメータが上書きされます。デフォルトでは、IGNORECASEはパスワードの大/小文字が区別されることを意味するNに設定されます。

    IGNORECASEパラメータおよびSEC_CASE_SENSITIVE_LOGONシステム・パラメータは非推奨なので注意してください。IGNORECASENに設定するか、IGNORECASE設定全体を省略することをお薦めします。

  2. 次のALTER SYSTEM文を入力します。
    ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = TRUE;
3.2.7.3 安全性の高いロール・パスワードの大/小文字の区別の管理

セキュリティを強化するために、安全性の高いロールのためのパスワードは、大/小文字が区別されるようにする必要があります。

Oracle Database 12cリリース2 (12.2)にアップグレードする前に、CREATE ROLE文のIDENTIFIED BY句を使用して安全性の高いロールを作成した場合、およびOracle Database 12cリリース12.2へのアップグレード時にSQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを排他モード12または12aのいずれかに設定した場合、これらの安全性の高いロールを引き続き使用可能にするには、パスワードを変更する必要があります。現在排他モードがデフォルトであるため、以前のリリース(10Gパスワード・バージョンがデフォルトのOracle Database 10gなど)で作成された安全性の高いロールにつていは、そのパスワードを変更する必要があります。

DBA_ROLESデータ・ディクショナリ・ビューのPASSWORD_REQUIREDおよびAUTHENTICATION_TYPE列を問い合せて、再度使用可能にするためにOracle Database 12cへのアップグレード後にパスワードを変更する必要がある安全性の高いロールを確認できます。

それ以外の場合、SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを8に設定しないかぎり、これらの安全性の高いロールのパスワード・バージョンを使用できません。このパラメータが12または12aに設定されている場合、次のSQL文を実行して、大/小文字の区別が有効であることを確認する必要があります。そうしないと、パスワードを変更した後でも、安全性の高いロールを使用できません。

ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = "TRUE";
3.2.7.4 ユーザーのパスワード・バージョンの管理

デフォルトでは、Oracle Databaseはパスワード・バージョンの管理に排他モード(大/小文字を区別しないパスワードは許可されない)を使用します。

デフォルトのインストールでは、排他モードを有効にするため、SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータが12に設定されています。排他モードでは、パスワードベースの認証プロトコルで大/小文字を区別するパスワード・バージョン(11Gまたは12C)のいずれかを使用してアカウントを認証することが必要です。排他モードでは、以前のリリースで使用されていた10Gパスワード・バージョンの使用が除外されます。Oracle Database 12cリリース2 (12.2)にアップグレードすると、10Gパスワード・バージョンを使用するアカウントはアクセス不能になります。これは、サーバーはデフォルトで排他モードで実行され、排他モードではクライアントの認証に古い10Gパスワード・バージョンを使用できないためです。サーバーにはそのクライアントの認証に使用するパスワード・バージョンがありません。

リリース10gのユーザー・アカウントは、10Gパスワード・バージョンを使用します。したがって、10Gパスワード・バージョンを使用するユーザー・アカウントを特定して、これらのアカウントのパスワードを再設定する必要があります。これにより、SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの設定に基づく適切なパスワード・バージョンが次のように生成されます。

  • SQLNET.ALLOWED_LOGON_VERSION_SERVER=8は、3つのすべてのパスワード・バージョン10G11Gおよび12Cを生成します。

  • SQLNET.ALLOWED_LOGON_VERSION_SERVER=12は、11Gおよび12Cパスワード・バージョンを生成し、10Gパスワード・バージョンを削除します。

  • SQLNET.ALLOWED_LOGON_VERSION_SERVER=12aは、12Cパスワード・バージョンのみ生成します。

最初にSQLNET.ALLOWED_LOGON_VERSION_SERVER設定をより緩やかな値(SQLNET.ALLOWED_LOGON_VERSION_SERVER=8など)に緩和してから、Oracle Databaseリリース10g (またはそれ以前の)リリースから現在のデータベース・リリースにユーザー・アカウントをインポートする場合、(古いリリースで使用されていた) 10Gパスワード・バージョンは大/小文字を区別しないため、これらのユーザーは引き続き大/小文字を区別しないパスワードを使用してデータベースにログインできます。ただし、そうしたユーザーが自分のパスワードを変更する場合は、インスタンス初期化パラメータSEC_CASE_SENSITIVE_LOGONのデフォルト値がTRUEのため、新しい11Gおよび12Cパスワード・バージョンが自動的に生成され、そのユーザーのパスワードは自動的に大/小文字が区別されるようになります。(SEC_CASE_SENSITIVE_LOGONは非推奨ですが、下位互換性のため現在も維持されていることに注意してください。)

次の例は、SEC_CASE_SENSITIVE_LOGONパラメータをTRUEに設定した場合の影響を示しています。このシナリオでは、ユーザーrtaylorはOracle Database release 10gからインポートされたため、このアカウントのパスワード・バージョンは10Gのみです。サーバーでは、SQLNET.ALLOWED_LOGON_VERSION_SERVER8に設定されています。そうしないと、rtaylorがログインできなくなるためです。また、SEC_CASE_SENSITIVE_LOGONパラメータはTRUEに設定され、11Gおよび12Cパスワード・バージョン用に大/小文字の区別が有効になっています。

  1. ユーザーrtaylorのパスワード・バージョンを確認します。

    SELECT PASSWORD_VERSIONS FROM DBA_USERS WHERE USERNAME='RTAYLOR';
    
    PASSWORD VERSIONS
    -----------------
    10G
  2. ユーザーrtaylorとして接続します。

    CONNECT rtaylor
    Enter password: "MaresEatOats"
    
    Connected.

    ユーザーrtaylorは、まだ自分のパスワードに大/小文字を区別しない10Gパスワード・バージョンを使用しているため、データベースに接続できます。ここで、実際のパスワードはすべて小文字のmareseatoatsですが、大文字と小文字を使用してパスワードを入力しています。

  3. デフォルト・ユーザーの1人であるSCOTTのパスワード・バージョンを確認します。

    SELECT PASSWORD_VERSIONS FROM DBA_USERS WHERE USERNAME='SCOTT';
    
    PASSWORD VERSIONS
    -----------------
    11G 12C
  4. 実際のパスワードはすべて小文字のluv2walkmyk9ですが、パスワードに大文字と小文字を使用してユーザーSCOTTとして接続を試みます。

    CONNECT SCOTT
    Enter password: "LuvToWalkMyK9" 
    
    ERROR: ORA-01017: invalid username/password; logon denied
    Warning: You are no longer connected to ORACLE.

    ユーザーSCOTTのパスワード・バージョンは11Gおよび12Gであるため、パスワードは大/小文字が区別されます。この例で入力されたパスワードは合っていますが、大文字と小文字が間違っています。

  5. rtaylorのパスワードをgrumble_mumble2workに変更します。

    ALTER USER rtaylor IDENTIFIED BY grumble_mumble2work;
    
    User altered.
  6. SYSDBA管理権限を使用して接続します。

    CONNECT / AS SYSDBA
  7. ユーザーrtaylorのパスワード・バージョンを確認します。

    SELECT PASSWORD_VERSIONS FROM DBA_USERS WHERE USERNAME='RTAYLOR';
    
    PASSWORD VERSIONS
    -----------------
    10G 11G 12C

    パスワードを変更したため、SQLNET.ALLOWED_LOGON_VERSION_SERVERおよびSEC_CASE_SENSITIVE_LOGON設定で構成済の認証プロトコルによってrtaylorのパスワードの大/小文字の区別が強制されます。

  8. パスワードに大文字と小文字を使用してrtaylorとして接続を試みます。

    CONNECT rtaylor
    Enter password: "Grumble_Mumble2Work"
    
    ERROR: ORA-01017: invalid username/password; logon denied
    Warning: You are no longer connected to ORACLE.

    入力したパスワードは、パスワード作成時のものと大/小文字が異なるため失敗します。

  9. 大/小文字を正しく使用して、rtaylorとして再度接続を試みます

    CONNECT rtaylor
    Enter password: "grumble_mumble2work"
    
    Connected.
    

    ユーザーrtaylorは接続できました。

rtaylorアカウントの大/小文字の区別は、サーバーでSEC_CASE_SENSITIVE_LOGONのデフォルト設定がTRUEになっていることによるものです。この設定がFALSEの場合は、rtaylorアカウントのパスワード・バージョンには10Gもあるため、大/小文字を区別しない一致を使用できます。ただし、この設定はお薦めしません。SEC_CASE_SENSITIVE_LOGONパラメータは、この理由のため非推奨となりました。セキュリティ向上のため、大/小文字を区別するパスワード認証を有効にしたままにすることをお薦めします。

3.2.7.5 10Gパスワード・バージョンを使用するユーザーのパスワードの確認と再設定

セキュリティを向上するため、10Gバージョンのパスワードを使用しているユーザー・アカウントを確認しパスワードをリセットして、より安全なバージョンのパスワードが今後使用されるようにします。

現行ユーザーのすべてのパスワード・バージョンの確認

DBA_USERSデータ・ディクショナリ・ビューを問い合せて、ユーザー・アカウントに構成されているすべてのパスワード・バージョンのリストを確認できます。

たとえば:

SELECT USERNAME,PASSWORD_VERSIONS FROM DBA_USERS;

USERNAME                       PASSWORD_VERSIONS
------------------------------ -----------------
JONES                          10G 11G 12C 
ADAMS                          10G 11G
CLARK                          10G 11G
PRESTON                        11G
BLAKE                          10G

PASSWORD_VERSIONS列は、アカウントに存在するパスワード・バージョンのリストを示しています。10Gは以前の大/小文字を区別しないOracleパスワード・バージョン、11GはSHA-1ベースのパスワード・バージョン、12CはSHA-2ベースのSHA-512パスワード・バージョンを表します。

  • ユーザーjones: このユーザーのパスワードは、SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータ設定が8のときに、Oracle Database 12cリリース12.1で再設定されました。これにより、3つのすべてのパスワード・バージョンを作成できます。

  • ユーザーadamsおよびclark: これらのアカウントのパスワードは最初にOracle Database 10gで作成され、Oracle Database 11gで再設定されました。Oracle Database 11gソフトウェアは、その時点でSQLNET.ALLOWED_LOGON_VERSIONのデフォルト設定8を使用していました。大/小文字の区別がデフォルトで有効になっているため、これらのパスワードは、prestonのパスワードと同様に大/小文字が区別されます。

  • ユーザーpreston: このアカウントは、排他モード(SQLNET.ALLOWED_LOGON_VERSION = 12)で実行されていたOracle Database 11gデータベースからインポートされました。

  • ユーザーblake: このアカウントは、Oracle Database 10gパスワード・バージョンをまだ使用しています。この段階では、ユーザーblakeはログインできません。

10Gパスワード・バージョンを使用するユーザーのパスワードの再設定

セキュリティを強化するには、すべてのユーザーのアカウントから10Gパスワード・バージョンを削除します。次の手順では、10Gパスワード・バージョンを使用しているユーザーのパスワードを再設定するために、クライアントのログインの許可に必要な機能レベルを制御するSQLNET.ALLOWED_LOGON_VERSION_SERVER設定を一時的に緩和する必要があります。設定を緩和することで、それらのユーザーがログインしてパスワードを変更し、10Gパスワード・バージョンに加えてより新しいパスワード・バージョンを生成できるようになります。その後にデータベースが排他モードを使用するように設定して、クライアントがO5L_NP機能を使用できるようにします。その後、ユーザーはパスワードを再設定して、パスワード・バージョンに10G,を含めずに、より安全な11G12Cのパスワード・バージョンのみを含めるようにすることができます。

  1. DBA_USERSビューを問い合せて、10Gパスワード・バージョンのみを使用しているユーザーを特定します。
    SELECT USERNAME FROM DBA_USERS 
    WHERE ( PASSWORD_VERSIONS = '10G '
    OR PASSWORD_VERSIONS = '10G HTTP ')
    AND USERNAME <> 'ANONYMOUS';
    
  2. データベースを排他モードで実行しないように、次のように構成します。
    1. sqlnet.oraファイルのSQLNET.ALLOWED_LOGON_VERSION_SERVER設定を編集して、デフォルトより緩やかな設定にします。たとえば、次のようにします。
      SQLNET.ALLOWED_LOGON_VERSION_SERVER=11
    2. データベースを再起動します。
  3. DBA_USERSビューに問い合せて、10Gパスワード・バージョンのみを使用するユーザーを期限切れにします。

    10Gパスワード・バージョンのみを使用し、11Gまたは12Cパスワード・バージョンのいずれかまたは両方を使用していないユーザーを期限切れにする必要があります。

    たとえば:

    ALTER USER username PASSWORD EXPIRE;
    
  4. パスワードを期限切れにしたユーザーにログインするよう依頼します。

    ユーザーがログインすると、パスワードを変更するよう求められます。データベースは、10Gパスワード・バージョンに加えて、アカウントで欠けている11Gおよび12Cパスワード・バージョンを生成します。データベースは許可モードで実行されているため、10Gパスワード・バージョンはそのまま存在します。

  5. ユーザーが接続しているクライアント・ソフトウェアにO5L_NP機能があることを確認します。

    Oracle Databaseリリース11.2.0.3以上のすべてのクライアントにO5L_NP機能があります。以前のOracle Databaseクライアントがある場合は、CPUOct2012パッチをインストールする必要があります。

  6. すべてのクライアントにO5L_NP機能があれば、次のようにサーバーのセキュリティを排他モードに設定しなおします。
    1. インスタンス初期化ファイルからSEC_CASE_SENSITIVE_LOGONパラメータ設定を削除するか、SEC_CASE_SENSITIVE_LOGONTRUEに設定します。
      SEC_CASE_SENSITIVE_LOGON = TRUE
    2. サーバーsqlnet.oraファイルからSQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを削除するか、または、サーバーsqlnet.oraファイルのSQLNET.ALLOWED_LOGON_VERSION_SERVERの値を元の12に設定して、排他モードに設定します。
      SQLNET.ALLOWED_LOGON_VERSION_SERVER = 12
    3. データベースを再起動します。
  7. まだ10Gパスワード・バージョンを使用しているアカウントを特定します。
    SELECT USERNAME FROM DBA_USERS
    WHERE PASSWORD_VERSIONS LIKE '%10G%' 
    AND USERNAME <> 'ANONYMOUS';
  8. まだ10Gパスワード・バージョンを使用しているアカウントを期限切れにします。
    ALTER USER username PASSWORD EXPIRE;
  9. これらのユーザーに自分のアカウントにログインするよう依頼します。

    ユーザーがログインすると、パスワードを再設定するよう求められます。次に、データベースは、アカウントに対して11Gおよび12Cパスワード・バージョンのみを生成します。データベースは排他モードで実行されているため、10Gパスワード・バージョンは生成されません。

  10. 次の問合せを再実行します。
    SELECT USERNAME FROM DBA_USERS
    WHERE PASSWORD_VERSIONS LIKE '%10G%' 
    AND USERNAME <> 'ANONYMOUS';

    この問合せに何も応答がなければ、10Gパスワード・バージョンを使用しているアカウントはありません。これで、データベースは以前のバージョンよりも安全なモードで稼働しています。

3.2.7.6 大/小文字の区別がパスワード・ファイルに与える影響

デフォルトでは、パスワード・ファイルは大/小文字を区別します。ORAPWDコマンドライン・ユーティリティのIGNORECASE引数は、パスワード・ファイルの大/小文字の区別を制御します。

IGNORECASEのデフォルト値はN(no)で、大/小文字の区別が適用されます。セキュリティを強化するために、IGNORECASENに設定するか、ignorecase引数全体を省略します。IGNORECASEは非推奨なので注意してください。

次の例は、パスワード・ファイルで大/小文字の区別を有効にする方法を示しています。

orapwd file=orapw entries=100
Enter password for SYS: password

このコマンドは、orapwと呼ばれる大/小文字を区別するパスワード・ファイルを作成します。デフォルトでは、パスワードでは大文字と小文字が区別されます。その後、このパスワードを使用して接続する場合、パスワードの作成時と大/小文字を同じにして入力すれば成功します。同じパスワードでも異なる大/小文字を入力した場合、そのパスワードを使用した認証試行は失敗します。

または、ある形式から別の形式へのパスワード・ファイル移行を使用してIGNORECASEパラメータを無効にすることもできます。たとえば:

orapwd input_file=input_password_file file=output_password_file

以前のリリースからユーザー・アカウントをインポートし、そのアカウントがSYSDBAまたはSYSOPER管理権限を使用して作成されている場合、アカウントはパスワード・ファイルに格納されます。この時点で、アカウントのパスワードは大/小文字が区別されません。大/小文字の区別が有効な場合、次にユーザーがパスワードを変更すると、パスワードは大/小文字が区別されます。セキュリティを強化するために、そのユーザーに対してパスワードを変更するように要請してください。

3.2.7.7 大/小文字の区別がデータベース・リンク接続で使用されるパスワードに与える影響

データベース・リンク接続を作成する場合は、接続用のユーザー名とパスワードを定義する必要があります。

データベース・リンク接続を作成すると、パスワードは大/小文字が区別されます。ユーザーが接続用のパスワードをどのように入力するかは、データベース・リンクが作成されたリリースによって決まります。

  • ユーザーはOracle Database 12cより前のデータベースからOracle Database 12cデータベースに接続できます。大/小文字の区別が有効なため、ユーザーは、アカウントの作成時に使用された大文字/小文字を使用して、パスワードを入力する必要があります。

  • ユーザーがOracle Database 12cデータベースからOracle Database 12cより前のリリースのデータベースに接続する場合、およびリリース12cより前のデータベースのSEC_CASE_SENSITIVE_LOGONパラメータがFALSEに設定されていた場合、大文字/小文字を使用してこのデータベース・リンクのパスワードを指定できます。

既存のデータベース・リンクのユーザー・アカウントを検索するには、V$DBLINKビューを問い合せます。たとえば:

SELECT DB_LINK, OWNER_ID FROM V$DBLINK;

V$DBLINKビューの詳細は、『Oracle Databaseリファレンス』を参照してください。

3.2.8 パスワードのセキュリティへの脅威からの12Cパスワード・バージョンによる保護

12Cパスワード・バージョンを使用すると、ユーザーは、コンプライアンス基準を満たす複雑なパスワードを作成できます。

3.2.8.1 12Cバージョンのパスワード・ハッシュについて

12Cパスワード・ハッシュはパスワードベースのセキュリティ脅威に対する保護を、大文字小文字混在のパスワードをサポートすることで実現します。

12Cバージョンのパスワード・ハッシュの生成に使用される暗号化ハッシュ関数は、パスワードベースのキー導出関数(PBKDF2)およびSHA-512暗号化ハッシュ関数を含む非最適化されたアルゴリズムに基づいています。12Cバージョンのパスワード・ハッシュがある場合、PBKDF2アルゴリズムによって計算上の非対称性が生じ、侵入者が元のパスワードに戻すことが難しくなります。12Cパスワードの生成では、その最後のステップとしてPBKDF2出力のSHA-512ハッシュを実行します。12Cパスワード・バージョンの生成で使用されるこの2段階のアプローチでは、クライアントにO7L_MR機能がある場合、サーバーのCPUリソースの使用が抑えられます。これは、O5LOGON認証のパスワード検証フェーズ中に、パスワード自体でPBKDF2計算全体を繰り返すのではなく、サーバーがO7L_MR対応クライアントによって送信される値の1つのSHA-512ハッシュのみを実行すればよいためです。

さらに、12Cパスワード・バージョンにより、ハッシュ時にパスワードにsaltが追加され、さらなる保護が提供されます。12Cパスワード・バージョンでは、ユーザーはより複雑なパスワードを作成できます。12Cパスワード・バージョンでsaltおよびPBKDF2非最適化が使用され、大/小文字混在のパスワードがサポートされることで、侵入者が12Cパスワード・バージョンに対して辞書攻撃や総当り攻撃を行ってユーザーのパスワードに戻すことがより難しくなります。12Cバージョンのパスワード・ハッシュを使用することをお薦めします。

パスワード・ハッシュ値は、サーバーとログインしているユーザー間の「共有秘密」として使用されるため、非常に機密性が高いとみなされます。侵入者にこの秘密を知られると、認証の保護はただちに重大な危険にさらされます。アカウント管理権限を持つ管理ユーザー、SYSDBA管理権限を持つ管理ユーザーまたはEXP_FULL_DATABASEロールを持つユーザーがパスワード・ハッシュ値に直接アクセスできることに注意してください。したがって、データベースのパスワードベースの認証の整合性を保持するには、このタイプの管理ユーザーは信頼できるユーザーである必要があります。これらの管理者が信頼できない場合、パスワード・ハッシュ値が「エンタープライズ・ユーザー・セキュリティ」ディレクトリ内に保持され、エンタープライズ・ユーザー・セキュリティ管理者以外はアクセスできないように、ディレクトリ・サーバー(Oracle Databaseエンタープライズ・ユーザー・セキュリティなど)をデプロイすることをお薦めします。

3.2.8.2 Oracle Database 12Cパスワード・バージョン構成のガイドライン

デフォルトでは、Oracle Databaseは、11Gおよび12Cという2つのバージョンのパスワード・ハッシュを生成します。

Oracle Databaseが特定のクライアントの認証に使用するパスワード・ハッシュのバージョンは、クライアントの機能、ならびにSQLNET.ALLOWED_LOGON_VERSION_CLIENTおよびSQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの設定に依存します。パスワード・バージョンによるクライアント認証の動作の詳細は、Oracle Database Net ServicesリファレンスSQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの説明にあるSQLNET.ALLOWED_LOGON_VERSION_SERVERの設定の表で、クライアントに必要な機能の列を参照してください。

Oracle Database 10gで生成された10Gパスワード・バージョンは大/小文字を区別しません。11G12Cの両パスワード・バージョンでは大/小文字は区別されます。

Oracle Database 12g リリース2 (12.2)では、sqlnet.oraのパラメータSQLNET.ALLOWED_LOGON_VERSION_SERVERのデフォルトは12 (これは排他モードで、10Gパスワード・バージョンを使用できません)、SQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータのデフォルトは11です。新しいアカウントについては、クライアントがOracle Database 12cの場合、Oracle Databaseは、Oracle Database 12cリリース・ソフトウェアを実行しているクライアントで12Cパスワード・バージョンを排他的に使用します。Oracle Databaseリリース12cより前に作成されたアカウントの場合、クライアントにO5L_NP機能があるかぎり、ログインは成功します。これは、Oracle Databaseリリース11gなどの以前のリリースで作成されたアカウント用に11Gパスワード・バージョンが通常存在しているためです。非常に古いアカウント(Oracle Databaseリリース10gのものなど)の場合、そのアカウントにSHA-1パスワード・バージョンを作成するために、ユーザーのパスワードの再設定が必要になる可能性があります。新しいアカウントを作成する際、または既存のアカウント・パスワードを変更する際に、12Cパスワード・バージョンのみを生成するようこのサーバーを構成するには、SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを12aに設定します。ただし、古いクライアントに対してアプリケーションに互換性を持たせる場合は、SQLNET.ALLOWED_LOGON_VERSION_SERVERをデフォルトの12に設定するようにします。

SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの設定は、セキュリティと、システムに必要な古いクライアントとの相互運用性とのバランスによって決まります。セキュリティのレベルを次のように制御できます。

  • 最高レベルの互換性: 新規アカウントの作成時または既存のアカウントのパスワードの変更時に3つのバージョンのパスワード・ハッシュ(12Cパスワード・バージョン、11Gパスワード・バージョンおよびDESベースの10Gパスワード・バージョン)をすべて生成するようにサーバーを構成するには、SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを値11以下に設定します。(以前のリリースでは値8がデフォルトで使用されていたことに注意してください。)

  • 推奨レベルのセキュリティ: 新規アカウントの作成時または既存のアカウントのパスワードの変更時に12Cパスワード・バージョンと11Gパスワード・バージョンの両方を生成するように(ただし、10Gパスワード・バージョンは除く)サーバーを構成するには、SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを値12に設定します。

  • 最高レベルのセキュリティ: 新しいアカウントを作成する際、または既存のアカウント・パスワードを変更する際に、12Cパスワード・バージョンのみを生成するようサーバーを構成するには、SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを値12aに設定します。

認証中に、アカウントに存在するパスワード・バージョンの種類および使用するクライアント・ソフトウェアのバージョンに基づき、次のシナリオが可能です。

  • 10Gバージョンのパスワード・ハッシュのみを使用したアカウント: サーバーで古いアカウントに対して新しいバージョンのパスワード・ハッシュを生成するよう強制する場合、管理者は10Gパスワード・バージョンのみを持つ(11G12Cといったよりセキュアなパスワード・バージョンを持たない)アカウントのパスワードを期限切れにする必要があります。データベースはこれらのパスワード・バージョンを使用してより強固なセキュリティを提供しているため、これらのパスワード・バージョンを生成する必要があります。これらのユーザーは次のようにして検出できます。

    SELECT USERNAME FROM DBA_USERS 
    WHERE PASSWORD_VERSIONS LIKE '%10G%
    AND USERNAME <> 'ANONYMOUS';
    

    次に、各アカウントを次のようにして期限切れにします。

    ALTER USER username PASSWORD EXPIRE;
    

    各アカウントを期限切れにした後、これらのユーザーにログインするよう通知します。ログインの際、パスワードを変更するよう求められます。クライアントのバージョンによって、使用されるパスワード・バージョンが決まります。SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの設定によって、生成されるパスワード・バージョンが決まります。クライアントにO7L_MR機能(Oracle Databaseリリース12c)がある場合、12Cパスワード・バージョンが認証に使用されます。クライアントにO5L_NP機能があり、O7L_MR機能がない場合(Oracle Databaseリリース11gクライアントなど)、11Gパスワード・バージョンが認証に使用されます。認証に12Cパスワード・バージョンを排他的に使用するには、すべてのクライアントをOracle Databaseリリース12cにアップグレードする必要があります。(デフォルトでは、Oracle Databaseリリース11.2.0.3以上のクライアントにO5L_NP機能があります。これにより、11Gパスワード・バージョンを排他的に使用できるようになります。以前のOracle Databaseクライアントを使用している場合は、CPUOct2012パッチをインストールする必要があります。)

    アカウント・パスワードの期限が切れ、ALLOWED_LOGON_VERSION_SERVERパラメータが12または12aに設定されている場合、10Gパスワード・バージョンは削除され、パラメータの設定に応じて次のように1つまたは2つの新しいパスワード・バージョンが作成されます。

    • ALLOWED_LOGON_VERSION_SERVER12 (デフォルト)に設定されている場合、11G12Cの両方のバージョンのパスワード・ハッシュが生成されます。

    • ALLOWED_LOGON_VERSION_SERVER12aに設定されている場合、12Cバージョンのパスワード・ハッシュのみが生成されます。

    詳細は、Oracle Database Net ServicesリファレンスSQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの使用上のノートに関する項の表内で、生成されるパスワードのバージョンの列を参照してください。

  • 10Gおよび11Gバージョンのパスワード・ハッシュを使用したアカウント: リリース10g以上のクライアントを使用しているユーザーは、11Gバージョンのパスワード・ハッシュが使用されるため、ユーザー・ログインは成功します。ただし、最新のバージョンを使用するには、前述のアカウントに関する箇条書き項目での説明のように、これらのパスワードを期限切れにします。

  • 11Gバージョンのパスワード・ハッシュのみを使用したアカウント: 認証で11Gバージョンのパスワード・ハッシュが使用されます。最新のバージョンを使用するには、1つ目の箇条書き項目での説明のように、パスワードを期限切れにします。

Oracle Database 12cのデフォルト構成(SQLNET.ALLOWED_LOGON_VERSION_SERVER12)は、Oracle Database 12cリリース2 (12.2)の認証プロトコルおよびOCIベースのドライバを使用する以降の製品(SQL*Plus、ODBC、Oracle .NET、Oracle Forms、および様々なサード・パーティ製Oracle Databaseアダプタなど)と互換性があることを意味します。JDBCタイプ4 (シン)バージョン(CPUOct2012バンドルパッチが適用されたもの、またはOracle Database 11g以降のもの)およびOracle Database 10gリリース10.2以降のOracle Database Clientインタフェース(OCI)ベースのドライバとも互換性があります。OCIクライアント・ドライバの以前のリリースでは、パスワードベース認証を使用してOracle Databaseデータベースに対して認証することができません。

3.2.8.3 12Cパスワード・バージョンを排他的に使用するためのOracle Databaseの構成

SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを12aに設定し、12Cのパスワード・ハッシュ・バージョンのみが使用されるようにしてください。

12Cパスワード・バージョンは、パスワードハッシュ・バージョンの中で最も制限が厳しく安全性が高いものであるため、このパスワード・バージョンのみを使用することをお薦めします。デフォルトでは、SQLNET.ALLOWED_LOGON_VERSION_SERVER12に設定されているため、11G12Cの両方のパスワード・バージョンを使用できます。(SQLNET.ALLOWED_LOGON_VERSION_SERVER1212aの両方の値は排他モードと見なされるため、以前の10Gパスワード・バージョンは使用できません。)以前のリリースからアップグレードした場合、またはSQLNET.ALLOWED_LOGON_VERSION_SERVER12または以前のリリースで使用されていた別の設定に設定されている場合、このパラメータを再構成する必要があります。これは、侵入者がより脆弱なパスワード・バージョンを使用するために認証のダウングレードを試みる可能性があるためです。このトピックの後述の表では、パスワード・バージョンの生成に対するSQLNET.ALLOWED_LOGON_VERSION_SERVER設定の効果を示しています。

12Cパスワード・バージョンを排他的に使用できるのは、Oracle Database 12cリリース12.1.0.2以降のクライアントを使用している場合に限られます。SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを12aに変更する前に、サーバーに接続しているデータベース・クライアントのバージョンを確認します。

  1. ALTER USERシステム権限を持つ管理ユーザーとしてSQL*Plusにログインします。

  2. 次のSQL問合せを実行して、ユーザーのパスワード・バージョンを確認します。

    SELECT USERNAME,PASSWORD_VERSIONS FROM DBA_USERS;
    
  3. 12Cパスワード・バージョンを持たない各ユーザーのアカウントを期限切れにします。

    たとえば、ユーザーblakeがまだ10Gパスワード・バージョンを使用しているとします。

    ALTER USER blake PASSWORD EXPIRE;
    

    これらのユーザーが次にログインする際、パスワードの変更が強制され、サーバーが排他モードに必要なパスワード・バージョンを生成できます。

  4. しかるべき期間(30日間など)内にログインするようユーザーに通知します。

    ログイン時、パスワードを変更するよう求められ、排他モードでの認証に必要なパスワード・バージョンがサーバーによって生成されます。(排他モードの機能の詳細は、『Oracle Database Net Servicesリファレンス』SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの使用上のノートに関する項を参照してください。)

  5. パスワードの大/小文字を含めてこれらのテスト・スクリプトまたはバッチ・ジョブで使用されるパスワードと正確に一致するように、テスト・スクリプトまたはバッチ・ジョブで使用されるアカウントのパスワードを手動で変更します。

  6. 次のようにして排他モード構成を有効にします。

    1. sqlnet.oraパラメータ・ファイルのバックアップ・コピーを作成します。

      デフォルトでは、このファイルは、UNIXオペレーティング・システムでは$ORACLE_HOME/network/adminディレクトリに、Microsoft Windowsオペレーティング・システムでは%ORACLE_HOME%\network\adminディレクトリにあります。

      マルチテナント環境では、sqlnet.oraファイルの設定がすべてのPDBに適用されることに注意してください。

    2. 表3-4をガイダンスに使用して、SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを設定します。

    3. sqlnet.oraファイルを保存します。

パスワード・バージョン生成のSQLNET.ALLOWED_LOGON_VERSION_SERVER設定の効果を次の表に示します。

表3-4 パスワード・バージョンの生成に対するSQLNET.ALLOWED_LOGON_VERSION_SERVERの影響

SQLNET.ALLOWED_LOGON_VERSION_SERVER設定 8 11 12 12a

サーバーを排他モードで実行しますか

いいえ

いいえ

はい

はい

10Gパスワード・バージョンを生成しますか

はい

はい

いいえ

いいえ

11Gパスワード・バージョンを生成しますか

はい

はい

はい

いいえ

12Cパスワード・バージョンを生成しますか

はい

はい

はい

はい

Oracle Database 12cリリース12.1.0.2以降のクライアントを使用する場合、SQLNET.ALLOWED_LOGON_VERSION_SERVER12aに設定します。

設定を高くすると、次のようにパスワード・バージョンの使用がさらに制限されます。

  • 12a (最も制限が厳しく、安全性の高い設定)に設定すると、12Cパスワード・バージョンのみが許可されます。

  • 12に設定すると、11Gおよび12Cパスワード・バージョンが許可され、認証に使用されます。

  • 8に設定すると、ほとんどのパスワード・バージョン(10G11Gおよび12C)が許可されます。

SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの詳細は、Oracle Database Net Servicesリファレンスを参照してください。

ノート:

以前のリリースを実行しているターゲット・データベースへの固定データベース・リンクをホストするシステムの場合、サーバーとクライアントのログオン・バージョンのデータベース・リンクへの影響で説明しているように、SQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータを設定できます。
3.2.8.4 サーバーとクライアントのログオン・バージョンのデータベース・リンクへの影響

SQLNET.ALLOWED_LOGON_VERSION_SERVERSQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータで、リリースの異なるデータベースとクライアント間の接続に対応できます。

次の図に、異なるリリースのデータベースとクライアントの接続の仕組みを示します。SQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータは、データベース・リンクHをホストするサーバーにおいて、クライアントに許可されたログオン・バージョンという側面に影響します。この設定により、Hはデータベース・リンクを介して、Oracle 9iを実行しているサーバー(T)などの古いサーバーに接続できますが、パッチが適用されていない古いクライアント(U)からの接続を引き続き拒否します。この場合、Oracle Net Servicesプロトコル・ネゴシエーションが失敗し、Oracle 9Iソフトウェアを使用して認証を試行しているこのクライアントに「ORA-28040: 一致する認証プロトコルがありません」エラー・メッセージが表示されます。Oracle Database 10gリリース10.2クライアントEのOracle Net Servicesプロトコル・ネゴシエーションは、このリリースにクリティカル・パッチ・アップデートCPUOct2012が組み込まれているため成功します。リリース11.2.0.3クライアントCのOracle Net Servicesプロトコル・ネゴシエーションは、安全なパスワード・バージョンが使用されているため成功します。

このシナリオでは、データベース・リンクHをホストするシステムに次の設定を使用します。

SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8
SQLNET.ALLOWED_LOGON_VERSION_SERVER=12

リモートOracle Database Tには次の設定があることに注意してください。

SQLNET.ALLOWED_LOGON_VERSION=8

リモートのOracle Database TのリリースがホストHに設定されるSQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータで定義された値を満たしていないまたは超えていない場合、データベース・リンク・ユーザーの認証中に固定データベース・リンクの問合せに失敗し、エンドユーザーがデータベース・リンクで表にアクセスしようとすると、「ORA-28040: 一致する認証プロトコルがありません」エラーになります。

ノート:

古いOracle Databaseクライアント(Oracle Database 11gリリース11.1.0.7など)を使用している場合は、アップグレードしてクリティカル・パッチ・アップデートCPUOct2012を使用することをお薦めします。

関連項目:

3.2.8.5 12Cパスワード・バージョンを排他的に使用するためのOracle Databaseクライアントの構成

侵入者が偽のサーバーを用意し、認証をダウングレードしてクライアントがより脆弱なパスワード・ハッシュ・バージョンを使用するよう試みることが多くあります。

  • 10Gパスワード・バージョンの使用、または10Gおよび11Gパスワード・バージョンの使用を防ぐには、サーバーの構成後、次のように、排他モードで稼働するようクライアントを構成します。

    • クライアント排他モード設定を使用して、11Gおよび12Cの2つのパスワード・バージョンを許可するには:

      SQLNET.ALLOWED_LOGON_VERSION_CLIENT = 12
      
    • より制限の厳しいクライアント排他モード設定を使用して、12Cパスワード・バージョンのみを許可するには (この設定では、クライアントはOracle Database 12cリリース1 (12.1.0.2)以上のサーバーにのみ接続できます):

      SQLNET.ALLOWED_LOGON_VERSION_CLIENT = 12a
      

サーバーとクライアントの両方が同じコンピュータにインストールされている場合、それぞれのTNS_ADMIN環境変数が各Oracle Net Services構成ファイルの正しいディレクトリを指していることを確認します。変数が両方で同じ場合、サーバーがクライアントのSQLNET.ALLOWED_LOGON_VERSION_CLIENT設定をかわりに使用することがあります。

古いOracle Databaseクライアント(Oracle Database 11gリリース11.1.0.7など)を使用している場合は、これらのクライアントにCPUOct2012以上を適用する必要があります。このパッチは、O5L_NP機能を提供します。このパッチを適用しないと、ユーザーはログインできなくなります。

関連項目:

3.2.9 パスワード資格証明用の安全性の高い外部パスワード・ストアの管理

安全性の高い外部パスワード・ストアは、パスワード資格証明の格納に使用されるクライアント側のウォレットになります。

3.2.9.1 安全性の高い外部パスワード・ストアについて

パスワード資格証明データベース接続は、クライアント側のOracleウォレットを使用して格納できます。

Oracleウォレットは、認証および署名用資格証明を格納する安全性の高いソフトウェア・コンテナです。このウォレットの使用方法により、データベースに接続する際にパスワード資格証明に依存する大規模な配置を簡素化できます。この機能が構成されている場合、アプリケーション・コードおよびスクリプトにユーザー名とパスワードを埋め込む必要がありません。これによりパスワードが危険にさらされることがなくなるため、リスクが軽減します。また、ユーザー名またはパスワードが変更されるたびにアプリケーション・コードを変更する必要がなくなるため、パスワード管理ポリシーの適用が容易になります。

ノート:

ウォレットの外部パスワード・ストアは、公開キー・インフラストラクチャ(PKI)資格証明が格納されている領域とは別の場所にあります。そのため、ウォレットの外部パスワード・ストアの資格証明管理には、Oracle Wallet Managerを使用できません。かわりに、コマンドライン・ユーティリティmkstoreを使用して資格証明を管理します。

3.2.9.2 安全性の高い外部パスワード・ストアの機能

ユーザー(アプリケーション、バッチ・ジョブ、スクリプトを含む)は、データベース接続文字列を指定した標準のCONNECT文を使用してデータベースに接続します。

この文字列には、ユーザー名、パスワード、およびOracle Databaseネットワーク上のデータベースを識別するOracle Netサービス名が含まれています。パスワードを省略すると、ユーザーは接続時にパスワードが要求されます。

たとえば、このサービス名は、データベースを識別するURL、またはデータベースのtnsnames.oraファイルに入力したTNS別名になります。または、host:port:sidの文字列となる場合もあります。

次の例は、外部パスワード・ストアを使用するように構成されていないクライアントにも使用できる標準CONNECT文です。

CONNECT salesapp@sales_db.us.example.com
Enter password: password

CONNECT salesapp@orasales
Enter password: password

CONNECT salesapp@ourhost37:1527:DB17
Enter password: password

これらの例では、salesappがユーザー名で、一意のデータベースの接続文字列が3つの方法で示されています。URL形式のsales_db.us.example.comtnsnames.oraファイルでのTNS別名orasales、またはhost:port:sid形式の文字列を使用できます。

ただし、クライアントが安全性の高い外部パスワード・ストアを使用するように構成されている場合は、アプリケーションは、データベースのログイン接続情報を指定せずに、次のCONNECT文の構文を使用してデータベースに接続できます。

CONNECT /@db_connect_string

CONNECT /@db_connect_string AS SYSDBA

CONNECT /@db_connect_string AS SYSOPER

ここでdb_connect_stringは、前述の例にあったように、サービス名、URL、別名など、対象のデータベースにアクセスするための有効な接続文字列です。各ユーザー・アカウントにはそれぞれ専用の一意の接続文字列が必要です。複数のユーザー用に1つの接続文字列を作成することはできません。

この場合、データベースの資格証明、ユーザー名およびパスワードが、安全性を目的に作成されたOracleウォレットに格納されています。このウォレットの自動ログイン機能が使用状態になるため、システムにはウォレットを開くためのパスワードは不要です。ウォレットから、システムはデータベースにアクセスするための資格証明を、資格を証明するユーザーのために取得します。

3.2.9.3 安全性の高い外部パスワード・ストアの使用を目的とするクライアントの構成について

クライアントがWindowsネイティブ認証やSSLなどの外部認証を使用するように構成されている場合、Oracle Databaseではその認証方式が使用されます。

通常は、そのタイプの認証で使用されるものと同じ資格証明が、データベースへのログインにも使用されます。データベース認証として、その認証方式を使用しないかまたは変更するクライアントには、sqlnet.oraSQLNET.WALLET_OVERRIDEパラメータをTRUEに設定できます。SQLNET.WALLET_OVERRIDEのデフォルト値はFALSEで、今までと同様に認証資格証明の標準的な使用が許可されます。

3.2.9.4 安全性の高い外部パスワード・ストアの使用を目的とするクライアントの構成

安全性の高い外部パスワード・ストア機能を使用するようにクライアントを構成するには、mkstoreコマンドライン・ユーティリティを使用します。

  1. コマンドラインで次の構文を使用して、クライアント上にウォレットを作成します。
    mkstore -wrl wallet_location -create
    

    たとえば:

    mkstore -wrl c:\oracle\product\19.1.0\db_1\wallets -create
    Enter password: password
    

    wallet_locationは、ウォレットを作成して格納するディレクトリのパスです。このコマンドにより、指定した場所にOracleウォレットが作成され、自動ログイン機能が使用可能になります。この自動ログイン機能により、クライアントは、パスワードを指定しなくてもウォレットの内容にアクセスできます。

    mkstoreユーティリティの-createオプションを指定すると、パスワードの複雑度検証が使用されます。詳細は、「パスワードの複雑度検証について」を参照してください。

  2. コマンドラインで次の構文を使用して、ウォレットにデータベース接続の資格証明を作成します。
    mkstore -wrl wallet_location -createCredential db_connect_string username
    Enter password: password
    

    たとえば:

    mkstore -wrl c:\oracle\product\19.1.0\db_1\wallets -createCredential orcl system
    Enter password: password
    

    詳細は、次のとおりです。

    • wallet_locationは、ステップ1でウォレットを作成したディレクトリのパスです。

    • db_connect_stringは、tnsnames.oraファイルでデータベースを指定するために使用するTNS別名、またはOracleネットワーク上のデータベースを識別するために使用するサービス名です。デフォルトで、tnsnames.ora$ORACLE_HOME/network/adminディレクトリ(UNIXシステムの場合)またはORACLE_HOME\network\admin(Windowsの場合)にあります。

    • usernameは、データベース・ログイン資格証明です。プロンプトが表示された後に、このユーザーのパスワードを入力します。

    アクセス可能にする各データベースに対し、CONNECT /@db_connect_string構文を使用してこのステップを繰り返します。CONNECT /@db_connect_string文で使用するdb_connect_stringは、-createCredentialコマンドで指定するdb_connect_stringと同じにする必要があります。

  3. クライアントのsqlnet.oraファイルに、WALLET_LOCATIONパラメータを入力し、ステップ1で作成したウォレットのディレクトリの場所に設定します。

    たとえば、$ORACLE_HOME/network/adminにウォレットを作成し、Oracleホームが/private/ora11に設定されている場合、クライアントのsqlnet.oraファイルには次のように指定する必要があります。

    WALLET_LOCATION =
      (SOURCE =
        (METHOD = FILE)
        (METHOD_DATA =
      (DIRECTORY = /private/ora11/network/admin)
      )
     )
    
  4. クライアントのsqlnet.oraファイルにSQLNET.WALLET_OVERRIDEパラメータを入力し、それを次のようにTRUEに設定します。
    SQLNET.WALLET_OVERRIDE = TRUE
    

    この設定により、すべてのCONNECT /@db_connect_string文で、データベースへの認証に、指定された場所にあるウォレットの情報が使用されます。

    外部認証が使用されている場合、そのウォレットによる認証ユーザーはCONNECT /@db_connect_string構文を使用し、前述の手順で指定したデータベースにユーザー名およびパスワードを使用せずにアクセスできます。ただし、ユーザーがこの外部認証に失敗した場合は、これらの接続文の実行も失敗します。

    ノート:

    アプリケーションが暗号化にSSLを使用する場合、sqlnet.oraパラメータSQLNET.AUTHENTICATION_SERVICESによりSSLが指定され、SSLウォレットが作成されます。このアプリケーションが、データベースへの認証にSSL証明書ではなく秘密のストア資格証明を使用する場合、これらの資格証明をSSLウォレットに格納する必要があります。SSL認証の後、SQLNET.WALLET_OVERRIDE = TRUEに設定されている場合は、ウォレットのユーザー名およびパスワードがデータベースへの認証に使用されます。SQLNET.WALLET_OVERRIDE = FALSEの場合は、SSL証明書が使用されます。

3.2.9.5 例: ウォレット・パラメータが設定されたサンプルsqlnet.oraファイル

sqlnet.oraファイルに特別なパラメータを設定すると、ウォレットの管理方法を制御できます。

例3-2では、「安全性の高い外部パスワード・ストアの使用を目的とするクライアントの構成」のステップ3およびステップ4で説明したWALLET_LOCATIONおよびSQLNET.WALLET_OVERRIDEパラメータが指定されている、サンプルsqlnet.oraファイルを示します。

例3-2 ウォレット・パラメータが設定されたサンプルsqlnet.oraファイル

WALLET_LOCATION =
  (SOURCE =
    (METHOD = FILE)
      (METHOD_DATA =
        (DIRECTORY = /private/ora_db/network/admin)
     )
  )

SQLNET.WALLET_OVERRIDE = TRUE
SSL_CLIENT_AUTHENTICATION = FALSE
SSL_VERSION = 0
3.2.9.6 外部パスワード・ストア資格証明の管理

mkstoreコマンドライン・ユーティリティで、外部パスワード・ストアからの資格証明を管理します。

3.2.9.6.1 外部パスワード・ストアの内容のリスト表示

クライアント・ウォレットの外部パスワード・ストアの内容(資格証明など)を表示できます。

外部パスワード・ストアの内容をリスト表示することによって、ストアに資格証明を追加または削除するかどうかの判断に使用できる情報が提供されます。

  • 外部パスワード・ストアの内容をリスト表示するには、コマンドラインで次のコマンドを入力します。

    mkstore -wrl wallet_location -listCredential
    

たとえば:

mkstore -wrl c:\oracle\product\19.1.0\db_1\wallets -listCredential

wallet_locationでは、表示する外部パスワード・ストアの内容が格納されているウォレットのディレクトリ・パスを指定します。このコマンドにより、資格証明にあるデータベース・サービス名(別名)および対応するユーザー名(スキーマ)がすべてリスト表示されます。パスワードはリスト表示されません。

3.2.9.6.2 外部パスワード・ストアへの資格証明の追加

1つのクライアント・ウォレットに複数の資格証明を格納できます。

たとえば、クライアントのバッチ・ジョブがhr_databaseに接続し、スクリプトがsales_databaseに接続する場合、同じクライアント・ウォレットにこのログイン資格証明を格納できます。ただし、同じウォレット内の同じデータベースに対する、(複数のスキーマにログインするための)複数の資格証明を格納することはできません。同じデータベースに対する複数のログイン資格証明がある場合、別のウォレットに格納する必要があります。

  • 既存のクライアント・ウォレットにデータベース・ログイン資格証明を追加するには、コマンド行で次のコマンドを指定します。

    mkstore -wrl wallet_location -createCredential db_alias username
    

たとえば:

mkstore -wrl c:\oracle\product\19.1.0\db_1\wallets -createCredential orcl system
Enter password: password

詳細は、次のとおりです。

  • wallet_locationは、資格証明を追加するクライアント・ウォレットが格納されるディレクトリのパスです。

  • db_aliasは、tnsnames.oraファイルでデータベースを指定するために使用するTNS別名、またはOracleネットワーク上のデータベースを識別するために使用するサービス名です。

  • usernameは、アプリケーションが接続するスキーマに対するデータベース・ログイン資格証明です。プロンプトが表示された後に、このユーザーのパスワードを入力します。

3.2.9.6.3 外部パスワード・ストアの資格証明の変更

データベース接続文字列が変わった場合は、ウォレットに格納されているデータベース・ログイン資格証明を変更できます。

  • ウォレット内のデータベース・ログイン資格証明を変更するには、コマンドラインで次のコマンドを入力します。

    mkstore -wrl wallet_location -modifyCredential db_alias username
    

たとえば:

mkstore -wrl c:\oracle\product\19.1.0\db_1\wallets -modifyCredential sales_db
Enter password: password

詳細は、次のとおりです。

  • wallet_locationは、ウォレットが格納されているディレクトリのパスです。

  • db_aliasは、データベースの識別に使用する新規または個別の別名です。これは、tnsnames.oraファイルでデータベースを指定するために使用するTNS別名、もしくはOracleネットワークのデータベースを識別するために使用する任意のサービス名になります。

  • usernameは、新規または他のデータベース・ログイン資格証明です。プロンプトが表示された後に、このユーザーのパスワードを入力します。

3.2.9.6.4 外部パスワード・ストアからの資格証明の削除

データベースが現存しない場合や、特定のデータベースへの接続を無効にする場合は、データベースのログイン資格証明をウォレットから削除できます。

  • ウォレットのデータベース・ログイン資格証明を削除するには、コマンドラインで次のコマンドを入力します。

    mkstore -wrl wallet_location -deleteCredential db_alias
    

たとえば:

mkstore -wrl c:\oracle\product\19.1.0\db_1\wallets -deleteCredential orcl

詳細は、次のとおりです。

  • wallet_locationは、ウォレットが格納されているディレクトリのパスです。

  • db_aliasは、tnsnames.oraファイルでデータベースを指定するために使用するTNS別名、またはOracle Databaseネットワーク上のデータベースを識別するために使用するサービス名です。

3.2.10 管理ユーザーのパスワードの管理

パスワード・ファイルやパスワード複雑度ファンクションなど、管理ユーザーのパスワードには特別な保護機能があります。

3.2.10.1 管理ユーザーのパスワード管理について

管理ユーザーのパスワードはデータベースの外部に保存されるため、データベースが開かれていないときでも認証が可能です。

パスワード・ファイルには特別な保護機能はありません。データベースが開いていないときでも認証ができるように、パスワード・ベリファイアはデータベースの外部に保存する必要があります。これまでのリリースでは、パスワードの複雑性の検証機能は管理者以外のユーザーにしか使用できませんでした。Oracle Databaseリリース12c (12.2)以降では、パスワードの複雑性の検証機能を非管理ユーザーと管理ユーザーの両方に使用できます。

3.2.10.2 管理ユーザーのLOCKおよびEXPIREDステータスの設定

アカウントがロックされている管理者ユーザーはデータベースに接続できません。

  • ロックされた管理アカウントまたは期限切れの管理アカウントをロック解除するには、ALTER USER文を使用します。

たとえば:

ALTER USER hr_admin ACCOUNT UNLOCK;

管理ユーザーのパスワードが期限切れになると、次にユーザーがログインを試みるときに、新しいパスワードの作成を求められます。

3.2.10.3 管理ユーザーのパスワード・プロファイル設定

管理ユーザーに強制される、いくつかのユーザー・プロファイル・パスワード設定があります。

これらのパスワード・プロファイル・パラメータは次のとおりです。

  • FAILED_LOGIN_ATTEMPT

  • INACTIVE_ACCOUNT_TIME

  • PASSWORD_LOCK_TIME

  • PASSWORD_LIFE_TIME

  • PASSWORD_GRACE_TIME

3.2.10.4 管理ユーザーの最後の正常なログイン時間

パスワード・ファイル・ベースの認証を使用する管理ユーザー接続の最後の正常なログイン時間が取得されます。

このログイン時間を確認するには、V$PWFILE_USERS動的パフォーマンス・ビューのLAST_LOGIN列を問い合せます。

3.2.10.5 管理ユーザーのパスワード・ファイルの管理

ORAPWDユーティリティのFORMATパラメータを12.2に設定すると、管理ユーザーのパスワード・プロファイル・パラメータを管理できます。

パスワード・ファイルは、データベース自体ではなく、外部ファイルに管理ユーザーの資格証明を格納するため、管理ユーザーにとって特に重要です。これにより、管理ユーザーはオープンしていないデータベースにログインして、データ・ディクショナリ・ビューの問合せなどのタスクを実行できます。パスワード・ファイルを作成するには、ORAPWDユーティリティを使用する必要があります。

FORMATパラメータをデフォルトの12.2に設定すると、パスワード・ファイルが管理ユーザー用のパスワード・プロファイル情報に対応するようになります。

たとえば:

orapwd file=orapworcl input_file=orapwold format=12.2
...

FORMAT12.2に設定すると、次のルールが適用されます。

  • パスワードの長さが8文字以上であり、少なくとも数字が1つと英字が1つ含まれていること。

  • パスワードに、ユーザー名、またはユーザー名のスペルを逆にしたものが含まれていないこと。

  • パスワードにoracle (oracle123など)の語が含まれていないこと。

  • パスワードに少なくとも1つの特殊文字が含まれていること。

FORMAT=12.2により次の内部チェックも適用されます。

  • パスワードの長さが30バイト以内であること。

  • パスワードが二重引用符文字(")を含まないこと。ただし、二重引用符で囲むことができます。

次のユーザー・プロファイル・パスワード設定が管理ユーザーに適用されます。

  • FAILED_LOGIN_ATTEMPT

  • INACTIVE_ACCOUNT_TIME

  • PASSWORD_GRACE_TIME

  • PASSWORD_LIFE_TIME

  • PASSWORD_LOCK_TIME

パスワード・ファイルに含まれている管理ユーザーおよびその管理権限を確認するには、V$PWFILE_USERS動的ビューを問い合せます。

3.2.10.6 管理ユーザーのパスワード・ファイルの移行

ORAPWDユーティリティのinput_fileパラメータまたはDBUAを使用して、以前のパスワード・ファイルの形式を12または12.2形式に移行できます。

ORAPWDユーティリティのfileおよびinput_fileパラメータを使用して、またはOracle Database Upgrade Assistant (DBUA)を使用して、以前のパスワード・ファイル形式から12または12.2形式に移行できます。

  • ORAPWDのFILEおよびINPUT_FILEパラメータ: ORAPWDユーティリティを使用して移行するには、FILEパラメータに新しいパスワード・ファイルの名前、INPUT_FILEパラメータに以前のパスワード・ファイルの名前を設定します。

    たとえば:

    orapwd file=orapworcl input_file=orapwold format=12.2
    
  • DBUA: パスワード・ファイルの以前の形式(FORMAT = LEGACYおよびFORMAT = 12)から移行するには、以前のデータベースを現在のリリースにアップグレードするときにDBUAを使用できます。ただし、データベースが読取り専用モードでオープンしていることを確認します。データベースの読取り専用ステータスを確認するには、V$DATABASE動的ビューのOPEN_MODE列を問い合せます。

3.2.10.7 管理ユーザーのパスワード・ファイルに対するマルチテナント・オプションの影響

マルチテナント環境では、ローカル管理ユーザーと共通管理ユーザーのパスワード情報はそれぞれ異なる場所に保存されます。

  • CDB管理ユーザーの場合: CDBルートで管理権限が付与されたCDB共通管理ユーザーのパスワード情報(パスワードのハッシュ)は、パスワード・ファイルに格納されます。

  • CDBルート外で管理権限が付与された、CDB内のすべてのユーザーの場合: これらのユーザーのパスワード・ハッシュ情報に関する情報を確認するには、$PWFILE_USERS動的ビューを問い合せます。

3.2.10.8 管理ユーザーのパスワードの複雑性の検証機能

セキュリティ向上のため、管理ユーザーのパスワードには、パスワードの複雑性の検証機能を使用します。

次のことに注意してください。

  • プロファイル: SYSユーザーにパスワードの複雑性の検証機能を指定するには、CREATE PROFILEまたはALTER PROFILE文のPASSWORD_VERIFY_FUNCTION句を使用します。管理ユーザーのパスワードをより適切に保護するために、パスワードの検証ファンクションを使用することをお薦めします。

  • ORAPWDパスワード・ファイル: ORAPWDユーティリティを使用してパスワード・ファイルを作成した場合、Oracle Databaseでは、SYSユーザーに加えて、SYSDBASYSBACKUPSYSDGおよびSYSKM管理権限を使用してログインした管理ユーザーに対してパスワードの複雑性のチェックが強制されます。

    パスワードは、次の要件についてチェックされます。

    • パスワードの長さが8文字以上であり、数字、英字および特殊文字が少なくとも1つずつ含まれていること。

    • パスワードがユーザー名またはユーザー名のスペルを逆にしたものと同一でないこと。

    • パスワードにoracle (oracle123など)の語が含まれていないこと。

    • 以前のパスワードとの違いが3文字以上あること。

    次の内部チェックも適用されます。

    • パスワードの長さが30バイト以内であること。

    • パスワードが二重引用符文字(")を含まないこと。ただし、二重引用符で囲むことができます。

3.3 データベース管理者の認証

データベース管理者を認証するには、強力な認証を使用するか、オペレーティング・システムから行うか、パスワードを使用してデータベースから行います。

3.3.1 データベース管理者の認証について

データベース管理者は、データベースの起動や停止などの特別な管理操作を実行します。

Oracle Databaseには、SYSDBASYSOPERSYSBACKUPSYSDGまたはSYSKM管理権限を持つデータベース管理者の認証を保護するための方式が用意されています。

3.3.2 管理者の厳密認証と集中管理

一元管理するデータベースの厳密認証方式として、ディレクトリ認証、Kerberos認証、SSL認証があります。

3.3.2.1 データベース管理者の厳密認証について

厳密認証を使用すると、複数のデータベースに対するSYSDBAおよびSYSOPERのアクセスを集中管理できます。

データベース管理のこのような認証は、次の状況で使用を検討してください。

  • パスワード・ファイルの脆弱性が懸念される場合。

  • サイトで非常に強固なセキュリティが要求される場合。

  • アイデンティティ管理をデータベースから分離する必要がある場合。たとえば、Oracle Internet Directory(OID)などのディレクトリ・サーバーを使用すると、そのサーバーを個別にメンテナンス、保護および管理できます。

Oracle Internet Directoryサーバーを使用してSYSDBAおよびSYSOPERの接続を認可するには、使用している環境に応じて、この項で説明する次のいずれかの方式を使用します。

3.3.2.2 管理ユーザーのディレクトリ認証の構成

Oracle Internet Directoryで、管理ユーザーのディレクトリ認証を構成します。

  1. 通常のユーザーを構成するのと同じ手順で、管理ユーザーを構成します。
  2. Oracle Internet Directoryで、このユーザーが管理するデータベースに対して、SYSDBAまたはSYSOPER管理権限をユーザーに付与します。

    SYSDBAまたはSYSOPERは信頼できるユーザーにのみ付与してください。

  3. LDAP_DIRECTORY_SYSAUTH初期化パラメータをYESに設定します。
    ALTER SYSTEM SET LDAP_DIRECTORY_SYSAUTH = YES;
    

    LDAP_DIRECTORY_SYSAUTHパラメータをYESに設定すると、SYSDBAおよびSYSOPERユーザーは、厳密認証方式を使用してデータベースへの認証を行うことができます。

  4. LDAP_DIRECTORY_ACCESSパラメータをPASSWORDまたはSSLのいずれかに設定します。たとえば、次のようにします。
    ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = PASSWORD;
    

    LDAP_DIRECTORY_ACCESS初期化パラメータをNONEに設定しないでください。このパラメータをPASSWORDまたはSSLに設定すると、Oracle Internet DirectoryからSYSDBAまたはSYSOPER管理権限を使用してユーザーを認証できます。

    Oracle Real Application Clusters (Oracle RAC)環境では、ALTER SYSTEM文またはinit.oraファイルで、すべてのインスタンスのLDAP_DIRECTORY_ACCESS設定が同じであることを確認します。

    Oracle Data GuardまたはActive Data Guard環境では、スタンバイ・データベースのLDAP_DIRECTORY_ACCESS設定がプライマリ・データベースと同じであることを確認します。この環境では、ALTER SYSTEM文を使用すると、その設定がプライマリ・データベースからスタンバイ・データベースに伝播されます。init.oraのパラメータはプライマリ・データベースとスタンバイ・データベースの両方で使用されているので、init.oraファイルを更新する場合に、この設定をデータベース間で手動で伝播する必要はありません。

この結果、ユーザーは、SQL*PlusでCONNECT文にネット・サービス名を指定してログインできるようになります。たとえば、ネット・サービス名がorclの場合、SYSDBAとしてログインするには、次のように入力します。

CONNECT someuser@orcl AS SYSDBA
Enter password: password

リモート認証でパスワード・ファイルを使用するようにデータベースが構成されている場合、Oracle Databaseでは最初にパスワード・ファイルをチェックします。

3.3.2.3 管理ユーザーのKerberos認証の構成

Oracle Internet Directoryを使用して、管理ユーザーのKerberos認証を構成できます。

  1. 通常のユーザーを構成するのと同じ手順で、管理ユーザーを構成します。

    詳細は、Kerberos認証の構成を参照してください。

  2. Kerberos認証用にOracle Internet Directoryを構成します。
  3. Oracle Internet Directoryで、このユーザーが管理するデータベースに対して、SYSDBAまたはSYSOPER管理権限をユーザーに付与します。

    SYSDBAまたはSYSOPERは信頼できるユーザーにのみ付与してください。この項の内容に関するガイドラインは、ユーザー・アカウントと権限の保護に関するガイドラインを参照してください。

  4. LDAP_DIRECTORY_SYSAUTH初期化パラメータをYESに設定します。
    ALTER SYSTEM SET LDAP_DIRECTORY_SYSAUTH = YES;
    

    LDAP_DIRECTORY_SYSAUTHパラメータをYESに設定すると、SYSDBAおよびSYSOPERユーザーは、厳密認証方式を使用してデータベースへの認証を行うことができます。LDAP_DIRECTORY_SYSAUTHの詳細は、『Oracle Databaseリファレンス』を参照してください。

  5. LDAP_DIRECTORY_ACCESSパラメータをPASSWORDまたはSSLのいずれかに設定します。たとえば、次のようにします。
    ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = SSL;
    

    LDAP_DIRECTORY_ACCESS初期化パラメータをNONEに設定しないでください。このパラメータをPASSWORDまたはSSLに設定すると、Oracle Internet DirectoryからSYSDBAまたはSYSOPERを使用してユーザーを認証できます。LDAP_DIRECTORY_ACCESSの詳細は、『Oracle Databaseリファレンス』を参照してください。

    Oracle Real Application Clusters (Oracle RAC)環境では、ALTER SYSTEM文またはinit.oraファイルで、すべてのインスタンスのLDAP_DIRECTORY_ACCESS設定が同じであることを確認します。

    Oracle Data GuardまたはActive Data Guard環境では、スタンバイ・データベースのLDAP_DIRECTORY_ACCESS設定がプライマリ・データベースと同じであることを確認します。この環境では、ALTER SYSTEM文を使用すると、その設定がプライマリ・データベースからスタンバイ・データベースに伝播されます。init.oraのパラメータはプライマリ・データベースとスタンバイ・データベースの両方で使用されているので、init.oraファイルを更新する場合に、この設定をデータベース間で手動で伝播する必要はありません。

この結果、ユーザーは、SQL*PlusでCONNECT文にネット・サービス名を指定してログインできるようになります。たとえば、ネット・サービス名がorclの場合、SYSDBAとしてログインするには、次のように入力します。

CONNECT /@orcl AS SYSDBA
3.3.2.4 Transport Layer Securityを使用したユーザー認証の構成

Transport Layer Security (TLS)を使用して、クライアント側とサーバー側の両方で管理ユーザーを認証できます。

  1. クライアントとサーバーの両方は、同じルート認証局(CA)証明書で署名されたユーザー証明書(公開または自己署名)を取得します。
  2. TLSを使用するようにクライアントを構成します。
    1. クライアント・ウォレットに署名付きユーザー証明書を追加します。CAルート信頼証明書は、クライアント・ウォレットに存在している必要があります。ユーザー証明書の追加前に、ユーザー証明書に必要な中間証明書がウォレットに追加されていることを確認します。
      orapkiを使用して、クライアント・ウォレットおよびユーザー証明書を構成できます。
    2. sqlnet.oraファイルで認証サービスとしてTLSを設定します。
      SSL_CLIENT_AUTHENTICATION=TRUE
    3. オプションで、セキュリティを向上させるために、完全または部分的なDN一致を使用するようにクライアントを設定します。
      DN一致が有効になっている場合、クライアントはサーバー証明書をチェックして、ホスト名がクライアントで一致するように構成されたものと一致することを確認します。このステップは、Oracle Internet DirectoryでTLSの使用を有効にする場合に実行します。

      ノート:

      データベース・クライアントとサーバーは、最強のTLSプロトコルと暗号スイートを使用して接続を確立するようになります。そのため、このTLSバージョンと暗号スイートは、それが必要になる特定のセキュリティ要件がないかぎり、指定する必要はありません。特定のTLSバージョンと暗号スイートを設定する場合は、古いバージョンが使用されなくなったときに構成の更新が必要になる点に注意してください。
  3. クライアント、リスナーおよびサーバーでTLSのリスナーを構成します。
    1. 安全なデータベース・ポート1522を使用して、TLS接続用に個別のリスナー・エントリを作成します。
      たとえば:
      LISTENER =
        (DESCRIPTION_LIST =
          (DESCRIPTION =
            (ADDRESS = (PROTOCOL = TCP)(HOST = example.com)(PORT = 1521))
            (ADDRESS = (PROTOCOL = TCPS)(HOST = example.com)(PORT = 1522))
          )
        )
    2. TLS以外のリスナー・エントリ(PROTOCOL = TCPの行など)をコメント・アウトするか、TLS以外の必須接続の場合はそのままにします。
    3. データベース・サーバーがリスナーではなくクライアントを認証するように、sqlnet.oraファイルにSSL_CLIENT_AUTHENTICATION = FALSEを追加します。
      サーバーが使用するものと同じウォレットを、同じサーバー証明書とともにリスナーで使用できます。リスナーは、標準のOracle Databaseウォレット検索順序を使用してウォレットを検索するようになります。または、WALLET_LOCATIONパラメータを設定すると、リスナーのウォレットの場所を指定できます。(リスナーでは使用できないため、この目的にWALLET_ROOTパラメータは使用できません)。
  4. TLSを使用するようにサーバーを構成します。
    1. sqlnet.oraファイルで、SSL_CLIENT_AUTHENTICATIONFALSE (またはOFF)に設定して一方向TLSを有効にします。
    2. TLSサーバー・ウォレットの場合は、次を実行します。
      • WALLET_ROOTパラメータをTLSサーバーの場所に設定します。
      • WALLET_ROOT/pdb_guidの下にtlsディレクトリを作成します。
      • TLSサーバー・ウォレットをWALLET_ROOT/pdb_guid/tlsディレクトリに移動します。
    3. sqlnet.oraファイルで、次のパラメータを追加します。
      SSL_CLIENT_AUTHENTICATION=TRUE

      認証をTCPSのみに制限する場合は、AUTHENTICATION_SERVICESTCPSに設定します。

  5. 新しいスキーマを作成するか、ユーザーにマップするように既存のスキーマを変更します。
    CREATE USER user_name IDENTIFIED EXTERNALLY AS 'user DN on certificate';
  6. SYSDBASYSOPERなどの適切な管理権限にデータベース・スキーマを付与します。
    TLS認証を使用する管理ユーザーはTLSで認証できます。こうしたユーザーを有効にするには、適切な管理権限をユーザー・スキーマに付与します。管理ユーザーは、この管理権限を使用してログインする必要があります。SYSOPER管理権限を付与されたユーザーの例:
    CONNNECT /@pdb_name AS SYSOPER
この結果、ユーザーは、SQL*PlusでCONNECT文にネット・サービス名を指定してログインできるようになります。たとえば、ネット・サービス名がorclの場合、SYSDBAとしてログインするには、次のように入力します。
CONNECT /@orcl AS SYSDBA

3.3.3 オペレーティング・システムを使用したデータベース管理者の認証

WindowsおよびUNIXの両システムで、DBA権限のあるグループを使用してオペレーティング・システムに対して認証します。

通常、データベース管理者のオペレーティング・システム認証には、オペレーティング・システムにグループを作成すること、そのグループにDBA権限を付与すること、および権限を付与する管理者の名前をグループに追加することが含まれます。(UNIXシステムでは、このグループはdbaグループです。)

ノート:

マルチテナント環境の場合、データベース管理者のオペレーティング・システム認証を使用できるのはCDBルートのみです。PDB、アプリケーション・ルートおよびアプリケーションPDBには使用できません。

Microsoft Windowsシステムの場合:

  • SYSDBA管理権限で接続するユーザーはWindowsネイティブ認証を利用できます。このユーザーがドメイン・アカウントを使用してOracle Databaseを操作する場合は、ローカル管理権限およびORA_DBAメンバーシップを明示的に付与する必要があります。

  • Microsoft Windows組込みのアカウントではなく、権限の低いMicrosoft Windowsのユーザー・アカウントを使用して、Oracle Databaseサービスを実行することをお薦めします。

関連項目:

データベース管理者のオペレーティング・システム認証の構成の詳細は、オペレーティング・システム固有のOracle Databaseマニュアルを参照してください。

3.3.4 パスワードを使用したデータベース管理者の認証

パスワード・ファイルを使用してデータベース管理者を認証します。

つまり、SYSDBASYSOPERSYSASMSYSBACKUPSYSDGおよびSYSKM管理権限を付与されたOracle Databaseユーザーは、データベース固有のパスワード・ファイルを使用して最初に認証されます。

これらの権限によって、次のアクティビティが使用可能になります。

  • SYSOPERシステム権限によって、データベース管理者はSTARTUPSHUTDOWNALTER DATABASE OPEN/MOUNTALTER DATABASE BACKUPARCHIVE LOGおよびRECOVERの各操作を実行できます。また、SYSOPER権限には、RESTRICTED SESSION権限も含まれます。

  • SYSDBA管理権限には、ADMIN OPTIONおよびSYSOPER管理権限も含めて、すべてのシステム権限が含まれます。CREATE DATABASEと時間ベースのリカバリが許可されます。

  • SYSDBASYSOPERSYSASMSYSBACKUPSYSDGおよびSYSKM管理権限を持つユーザーが含まれるパスワード・ファイルは、異なるデータベース間で共有できます。また、このタイプのパスワード・ファイル認証は、Transport Layer Security (TLS)またはKerberos構成で、マルチテナント環境の共通管理ユーザーに対して使用できます。SYSユーザー以外のユーザーが含まれた共有パスワード・ファイルも保持できます。異なるデータベース間でパスワード・ファイルを共有するには、init.oraファイルのREMOTE_LOGIN_PASSWORDFILEパラメータをSHAREDに設定します。

    REMOTE_LOGIN_PASSWORDFILE初期化パラメータの設定をNONEからEXCLUSIVEまたはSHAREDに変更する場合は、パスワード・ファイルとディクショナリ・パスワードを必ず同期してください。詳細は、Oracle Database管理者ガイドを参照してください。

  • 自動ストレージ管理(ASM)環境では、共有ASMパスワード・ファイルを作成できます。ASMパスワード・ファイルを作成するSYSASMシステム権限が必要なことに注意してください。詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。

  • SYSDG シャーディング管理者がファイル転送およびOracle Recovery Manager (RMAN)のアクティビティを伴うタスクを実行できるように、パスワード・ファイルに管理権限を含める必要があります。

  • パスワード・ファイル・ベースの認証が、デフォルトで使用可能です。これは、SYSDBASYSOPERSYSASMSYSBACKUPSYSDGおよびSYSKM管理権限を持つユーザーを認証するために、データベースでパスワード・ファイルを使用する準備が整っていることを意味します。パスワード・ファイル・ベースの認証は、ORAPWDユーティリティを使用してパスワード・ファイルを作成すると、アクティブになります。

    $ORACLE_HOME/dbsディレクトリに対してEXECUTE権限および書込み権限を持つユーザーがORAPWDユーティリティを実行できます。

  • Oracle Database 12cリリース2 (12.2)形式でパスワード・ファイルが作成されると、FAILED_LOGIN_ATTEMPTSPASSWORD_LIFE_TIMEなどのパスワード制限が管理ログインに対して強制されます。

ノート:

  • パスワード・ファイルに含まれているユーザーのリストを検索するには、V$PWFILE_USERSデータ・ディクショナリ・ビューを問い合せることができます。

  • AS SYSDBAまたはAS SYSOPERで要求された接続は、これらのフレーズを使用する必要があります。使用していない場合、接続は失敗します。

3.3.5 データベース管理者認証のパスワード・ファイルを使用するリスク

パスワード・ファイルの使用は、セキュリティ上のリスクを伴う可能性があることに注意してください。

このため、管理者の厳密認証と集中管理で説明した認証方式を使用することを検討してください。

パスワードによるセキュリティのリスクの例は、次のとおりです。

  • 侵入者がパスワード・ファイルを盗んだり攻撃する可能性があります。

  • 多くのユーザーがデフォルト・パスワードを変更しない場合があります。

  • パスワードが簡単に推定される場合があります。

  • パスワードがディレクトリ内に存在すると、無防備になります。

  • 短かすぎたり簡単に入力できるパスワードは、侵入者がパスワードの暗号化ハッシュを取得した場合に無防備になります。

ノート:

パスワード・ファイルの作成およびメンテナンスの詳細は、『Oracle Database管理者ガイド』を参照してください。

3.4 ユーザーのデータベース認証

ユーザーのデータベース認証では、認証を実行するためにデータベース自体の情報を使用する必要があります。

3.4.1 ユーザーのデータベース認証について

Oracle Databaseでは、データベース自体に格納されている情報を使用して、データベースに接続しようとするユーザーを認証できます。

データベース認証を使用するようにOracle Databaseを構成するには、対応するパスワードを指定して各ユーザーを作成する必要があります。ユーザー名にはNational Language Support (NLS)の文字書式を使用できますが、パスワードに二重引用符文字を含めることはできません。ユーザーは、接続の確立時にそのユーザー名およびパスワードを入力する必要があります。

Oracle Databaseは、ユーザーのパスワードの一方向ハッシュを生成し、入力されたログイン・パスワードの検証時に使用するため格納します。古いクライアントをサポートするために、様々なハッシング・アルゴリズムを使用してユーザーのパスワードの一方向ハッシュを生成するようにOracle Databaseを構成できます。生成されたパスワード・ハッシュはパスワード・バージョンと呼ばれ、その略称は10G11Gおよび12Cです。略称10G11Gおよび12Cは、一方向パスワード・ハッシング・アルゴリズムの詳細を略したものに相当します。その詳細は、ドキュメントとしてDBA_USERSビューのPASSWORD_VERSIONS列で説明されています。指定したユーザーのパスワード・バージョンのリストを確認するには、DBA_USERSビューのPASSWORD_VERSIONS列を問い合せます。

デフォルトでは、Oracle Databaseで現在使用されている一方向ハッシング・アルゴリズムには、salt処理済のSHA-1ハッシング・アルゴリズムとsalt処理済のPKBDF2 SHA-2 SHA-512ハッシング・アルゴリズムの2つのバージョンがあります。salt処理済のSHA-1ハッシング・アルゴリズムでは、11Gパスワード・バージョンに使用されるハッシュが生成されます。salt処理済のPKBDF2 SHA-2 SHA-512ハッシング・アルゴリズムでは、12Cパスワード・バージョンに使用されるハッシュが生成されます。このハッシュ生成は同じパスワードに対して行われます。つまり、両方のアルゴリズムが同じパスワードに対して実行されます。Oracle Databaseでは、これらのパスワード・バージョンがDBA_USERSデータ・ディクショナリ・ビューに記録されます。このビューを問い合せると、2つのパスワード・バージョンが表示されます。例:

SELECT USERNAME, PASSWORD_VERSIONS FROM DBA_USERS;

USERNAME  PASSWORD_VERSIONS
--------  -----------------
ADAMS     11G, 12C
SYS       11G, 12C
...

クライアントまたはクライアントとして機能するデータベース・サーバーの認証中に許可する認証プロトコルを指定するには、サーバーsqlnet.oraファイルのSQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを明示的に設定できます。(このパラメータのクライアント・バージョンは、SQLNET.ALLOWED_LOGON_VERSION_CLIENTです。)各接続がテストされ、パートナが指定するクライアント機能要件をクライアントまたはサーバーが満たしていない場合は、認証に失敗して、『Oracle Database Net Servicesリファレンス』SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの説明の下にあるSQLNET.ALLOWED_LOGON_VERSION_SERVER設定の表のクライアントに必要な機能の列に示されている「ORA-28040 一致する認証プロトコルがありません」エラーが発生します。このパラメータの値には、12a1211109または8を指定できます。デフォルト値は12で、排他モードです。これらの値は、認証プロトコルのバージョンを表します。値12をお薦めします。ただし、SQLNET.ALLOWED_LOGON_VERSION_SERVERおよびSQLNET.ALLOWED_LOGON_VERSION_CLIENT11に設定した場合、JDBCシン・クライアントを含むOracle Databaseリリース11.1以前のクライアント・アプリケーションは、パスワード・ベースの認証を使用してOracleデータベースへの認証を行うことができない点に注意してください。

データベース認証使用時のセキュリティを高めるために、アカウントのロック、パスワード・エイジングと期限切れ、パスワード履歴およびパスワードの複雑度検証も含めたパスワード管理の使用をお薦めします。

外部認証を使用せず、ローカル・データベース・パスワード認証のみを使用する場合は、クライアントのsqlnet.oraファイルでAUTHENTICATION_SERVICES=(none)を設定します。この設定では、この値のデフォルトはALLであり、クライアントが外部認証およびデータベース・パスワード認証を確認するように強制されるため、パフォーマンスが向上します。

3.4.2 データベース認証の利点

データベースを使用したユーザーの認証では、次の3つのメリットがあります。

これらのメリットは次のとおりです。

  • ユーザー・アカウントとすべての認証がデータベースによって制御されます。データベースの外部のものには依存しません。

  • Oracle Databaseには、データベース認証使用時のセキュリティを高めるために、強力なパスワード管理機能が組み込まれています。

  • 小規模なユーザー・コミュニティがある場合の管理が容易になります。

3.4.3 データベースで認証されるユーザーの作成

データベースで認証されるユーザーを作成する場合、このユーザーにパスワードを割り当てます。

  • データベースで認証されるユーザーを作成するには、ユーザーの作成時にIDENTIFIED BY句を指定します。

たとえば、次のSQL文は、Oracle Databaseによって識別および認証されるユーザーを作成します。ユーザーsebastianは、Oracle Databaseに接続するたびに割り当てられたパスワードを指定する必要があります。

CREATE USER sebastian IDENTIFIED BY password;

3.5 スキーマ限定アカウント

スキーマ限定アカウントを作成できます。つまり、スキーマ・ユーザーにはパスワードがありません。

3.5.1 スキーマ限定アカウントについて

スキーマ限定アカウントはデータベースにログインできませんが、単一セッション・プロキシでプロキシとなることができます。

このタイプのアカウントは、Oracle提供のスキーマおよび一部のユーザー作成スキーマ用に設計され、パスワードや認証タイプを指定せずに作成できます。これは、ALTER USER文を使用して認証方式が割り当てられない限り認証できません。スキーマ限定アカウントでは、DBA_USERS_WITH_DEFPWDデータ・ディクショナリ・ビューにエントリが含まれていません。

デフォルトでは、サンプル・スキーマ・ユーザー・アカウント(たとえばHR)など、Oracle Databaseで使用可能な事前定義済のスキーマ・ユーザー・アカウントのほとんどがスキーマ限定アカウントです。これらのアカウントのパスワードは、必要に応じて割り当てることができますが、セキュリティを強化するために、後でスキーマ限定に戻すように設定することをお薦めします。スキーマ・ユーザー・アカウントがスキーマ限定かどうかを確認するには、DBA_USERSデータ・ディクショナリ・ビューのAUTHENTICATION_TYPE列を問い合せます。NONEは、アカウントがスキーマ限定であることを示します。

スキーマ限定アカウントの使用に関する次のルールに注意してください。

  • スキーマ限定アカウントは管理者アカウントおよび非管理者アカウントの両方に使用できます。

  • スキーマ限定アカウントはデータベース・インスタンスでのみ作成する必要があり、Oracle Automatic Storage Management (ASM)環境では作成できません。

  • スキーマ限定アカウントにはシステム権限(CREATE ANY TABLEなど)や管理者ロール(DBAなど)を付与できます。スキーマ限定アカウントは、付与された権限を修正する必要があることを前提として、表またはプロシージャのようなオブジェクトを作成できます。

  • スキーマ限定アカウントは、単一セッション・プロキシのプロキシ認証でクライアント・ユーザーとして使用されるように構成できます。これは単一セッション・プロキシの場合、プロキシ・ユーザーの資格証明のみが検証され、クライアント・ユーザーの資格証明が検証されないためです。したがって、スキーマ限定アカウントがクライアント・ユーザーになることができます。ただし、2つのプロキシが存在するシナリオの場合はクライアントの資格証明を検証する必要があるため、スキーマ限定アカウントを構成することはできません。したがって、スキーマ限定アカウントの認証は失敗します。

  • スキーマ限定アカウントは、接続されたユーザー・リンク、固定ユーザー・リンク、または現行ユーザー・リンクのいずれかを使用してデータベース・リンク経由で接続することはできません。

3.5.2 スキーマ限定アカウントの作成

CREATE USER SQL文でスキーマ限定アカウントを作成します。

NO AUTHENTICATION句を指定したCREATE USER文は、データベース・インスタンス上でのみ実行できます。Oracle Automatic Storage Management(ASM)インスタンス上ではこれを実行できません。
  • NO AUTHENTICATION句を指定してCREATE USER文を使用します。
    たとえば:
    CREATE USER psmith NO AUTHENTICATION;

3.5.3 スキーマ限定アカウントの変更

ALTER USER SQL文でスキーマ限定アカウントを変更できます。

  1. スキーマ・ユーザーが管理者権限を持っているかどうかを確認します。
    V$PWFILE_USERSを問い合せてスキーマ・ユーザーが管理者権限を持っているかどうかを確認できます。
  2. スキーマ・ユーザーが管理者権限を持っている場合、REVOKE文を使用して、これらの権限を取り消します。
  3. NO AUTHENTICATION句を指定してALTER USER SQL文を使用して、スキーマ・アカウントが認証されないように修正します。
    たとえば:
    ALTER USER psmith NO AUTHENTICATION;
ALTER USERを使用してスキーマ限定アカウントの認証を有効にできます。

3.6 ユーザーのオペレーティング・システム認証

Oracle Databaseではオペレーティング・システムで管理されている情報を使用した認証が可能です。

オペレーティング・システムを使用したユーザーの認証には、メリットとデメリットの両方があります。

この機能には次の利点があります。

  • オペレーティング・システムから認証を受けたユーザーは、より簡単にOracle Databaseに接続できます。ユーザー名やパスワードを指定する必要はありません。たとえば、オペレーティング・システムにより認証されたユーザーはSQL*Plusを起動して、コマンドラインで次のコマンドを入力することによりユーザー名とパスワードのプロンプトを省略できます。

    SQLPLUS / 
    

    SQL*Plusで、次のように入力します。

    CONNECT / 
    
  • ユーザー認証はオペレーティング・システムで集中管理されるため、ユーザー・パスワードの暗号化されたハッシュ値(ベリファイアとも呼ばれる)をOracle Databaseが格納または管理する必要がなくなります。ただし、ユーザー名は引き続きデータベース内で管理されます。

  • 監査証跡は、オペレーティング・システムのユーザー名とデータベース・ユーザー名を取得します。この場合データベース・ユーザー名には、OS_AUTHENT_PREFIXインスタンス初期化パラメータの値がオペレーティング・システムのユーザー名に接頭辞として付加されます。たとえば、OS_AUTHENT_PREFIXOPS$に設定されていて、オペレーティング・システムのユーザー名がpsmithである場合、データベース・ユーザー名はOPS$PSMITHになります。

  • 同じシステムで、オペレーティング・システム・ユーザーと非オペレーティング・システム・ユーザーの両方を認証できます。たとえば:

    • オペレーティング・システムによってユーザーを認証します。CREATE USER文のIDENTIFIED EXTERNALLY句を使用してユーザー・アカウントを作成し、OS_AUTHENT_PREFIX初期化パラメータを設定して、サーバーに接続しようとするユーザーをOracle Databaseが認証するために使用する接頭辞を指定します。

    • 非オペレーティング・システム・ユーザーを認証します。これは、パスワードが割り当てられ、データベースによって認証されるユーザーです。

    • Oracle Database Enterprise User Securityユーザーを認証します。このユーザー・アカウントはCREATE USER文のIDENTIFIED GLOBALLY句を使用して作成され、現行の同じデータベースでOracle Internet Directory(OID)によって認証されます。

ただし、ユーザーの認証にオペレーティング・システムを使用する場合は特別な注意が必要です。

  • ユーザーには、アクセスが必要なコンピュータのオペレーティング・システム・アカウントが必要です。必ずしもすべてのユーザー(特に管理ユーザー以外のユーザー)がオペレーティング・システム・アカウントを持っているわけではありません。

  • ユーザーがこの方式を使用してログインし、端末の前から離れた場合、別のユーザーはパスワードや資格証明が必要ないため簡単にログインできます。これは、深刻なセキュリティ問題になる可能性があります。

  • データベース・ユーザーの認証にオペレーティング・システムを使用する場合は、分散データベース環境とデータベース・リンクの管理に特別な注意が必要です。オペレーティング・システム認証のデータベース・リンクは、セキュリティ上の弱点を生み出す可能性があります。そのため、これらのリンクは使用しないことをお薦めします。

  • マルチテナント環境の場合、データベース管理者のオペレーティング・システム認証を使用できるのはCDBルートのみです。PDB、アプリケーション・ルートおよびアプリケーションPDBには使用できません。

関連項目:

  • 認証、オペレーティング・システム、分散データベースの概要および分散データ管理の詳細は、『Oracle Database管理者ガイド』を参照してください。

  • オペレーティング・システムによる認証の詳細は、そのオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。

3.7 ユーザーのネットワーク認証

ネットワークでのユーザーの認証は、サード・パーティ・サービスでTransport Layer Securityを使用して行うことができます。

3.7.1 Transport Layer Securityを使用した認証

Transport Layer Security (TLS)プロトコルは、アプリケーション・レイヤー・プロトコルです。

TLSは、Oracle Internet Directoryでのグローバル・ユーザー管理とは関係なく、データベースに対するユーザー認証に使用できます。つまり、ユーザーは、ディレクトリ・サーバーを指定しなくても、TLSを使用してデータベースへの認証を行うことができます。

3.7.2 サード・パーティ・サービスを使用した認証

サード・パーティのサービス(Kerberos、RADIUS、ディレクトリベース・サービス、公開キー・インフラストラクチャ)を使用して、ネットワーク経由でOracle Databaseを認証できます。

3.7.2.1 サード・パーティ・サービスを使用した認証について

ネットワーク上のOracle Databaseユーザーを認証する場合は、サード・パーティ・ネットワーク認証サービスを使用する必要があります。

よく知られている例としては、Kerberos、PKI (公開キー・インフラストラクチャ)、RADIUS (Remote Authentication Dial-In User Service)、およびディレクトリ・ベース・サービスがあります。

ネットワーク認証サービスを使用できる場合、Oracle Databaseはこれらのネットワーク・サービスによる認証を受け入れることができます。ネットワーク認証サービスを使用する場合は、ネットワーク・ロールとデータベース・リンクについて特別な考慮事項があります。

3.7.2.2 Kerberosを使用した認証

Kerberosは、共有秘密を使用するサード・パーティの認証システムです。

Kerberosは、サード・パーティがセキュアであることを保証し、シングル・サインオン機能、集中化されたパスワード・ストレージ、データベース・リンク認証、拡張されたPCセキュリティを提供します。これは、Kerberos認証サーバーまたはCybersafe Active Trust (Kerberosをベースとした商用の認証サーバー)を介して提供されます。

3.7.2.3 RADIUSを使用した認証

Remote Authentication Dial-In User Service (RADIUS)はユーザー認証、認可、およびアカウンティングに使用される標準のライトウェイト・プロトコルです。

RADIUSにより、ユーザーはRSA One-Time Password Specifications (OTPS)を使用してOracleデータベースに対する認証もできるようになります。

関連項目:

3.7.2.4 ディレクトリベース・サービスを使用した認証

中核となるディレクトリを使用すると、認証とその管理が効率的になります。

次のようなディレクトリベース・サービスがあります。

  • Lightweight Directory Access Protocol (LDAP)を使用するOracle Internet Directoryにより、中央リポジトリを使用してユーザー(エンタープライズ・ユーザーと呼ばれます)に関する情報を格納および管理できます。エンタープライズ・ユーザーのアカウントは、分散環境で作成されます。データベース・ユーザーの場合は、アクセスするデータベースごとにパスワードとともに作成する必要がありますが、エンタープライズ・ユーザーの情報にはOracle Internet Directoryで集中的にアクセスできます。このディレクトリをMicrosoft Active DirectoryやSunOneと統合することもできます。

  • Oracle Enterprise Security Managerを使用すると、Oracle Internet Directoryからのロールの取得と保管ができ、これにより権限の集中管理が可能になることで管理が容易になり、セキュリティ・レベルが向上します。

3.7.2.5 公開キー・インフラストラクチャを使用した認証

公開キー・インフラストラクチャ(PKI)に基づく認証システムでは、ユーザー・クライアントに電子証明書が発行されます。

これらのクライアントはこの証明書を使用して直接企業内のサーバーに身分を証明し、認証に直接的に関与しません。Oracle Databaseで提供されている、公開キーと証明書を使用するためのPKIは、次のコンポーネントで構成されています。

  • SSLによる認証および保護セッション・キー管理。詳細は、Transport Layer Securityを使用した認証を参照してください。

  • 信頼できる証明書識別情報を検証するときに、ユーザー証明書の署名者として信頼するサード・パーティ・エンティティを識別するために使用します。ユーザーの証明書が確認されるとき、署名者は、検証システムに格納されている認証局のトラスト・ポイントまたは信頼できる証明連鎖を使用してチェックされます。この連鎖内に複数レベルの信頼できる証明書がある場合は、下位レベルの証明書を信頼するため、それより上のレベルの証明書をすべて再検証する必要はありません。

  • Oracle Wallet Manager。Oracleウォレットは、ユーザーの秘密キー、ユーザー証明書および一連のトラスト・ポイント(信頼できる認証局)を含むデータ構造です。Oracleウォレットの管理の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。

    Oracle Wallet Managerを使用してOracleウォレットを管理できます。これは、Oracleウォレットのセキュリティ資格証明を管理および編集するために使用するスタンドアロンのJavaアプリケーションです。次の操作を実行します。

    • 公開キーと秘密キーのペアを生成し、認証局に提出する証明書要求を作成して、ウォレットを作成します。

    • エンティティの証明書をインストールします。

    • Oracle Databaseのクライアントとサーバー上でX.509v3証明書を管理します。

    • エンティティの信頼できる証明書を構成します。

    • ウォレットをオープンして、PKIベースのサービスにアクセスできるようにします。

  • 信頼できるエンティティ、認証局から取得された(署名された) X.509バージョン3証明書。認証局は信頼されているため、これらの証明は要求側エンティティの情報が正確であることと証明書上の公開キーが認定されるエンティティに属していることを証明します。証明書はOracleウォレットにロードされるため、今後の認証が可能になります。

3.8 PDBのオペレーティング・システム・ユーザーの構成

DBMS_CREDENTIAL.CREATE_CREDENTIALプロシージャで、ユーザー・アカウントをPDBのオペレーティング・システム・ユーザーに設定します。

3.8.1 PDBのオペレーティング・システム・ユーザーの構成について

oracleオペレーティング・システム・ユーザーのかわりに、特定のユーザー・アカウントをそのPDBのオペレーティング・システム・ユーザーに設定できます。

特定のユーザーをPDBのオペレーティング・システム・ユーザーとして設定しない場合、PDBではデフォルトでoracleオペレーティング・システム・ユーザーが使用されます。ルートについては、オペレーティング・システムと対話する必要がある場合、oracleオペレーティング・システム・ユーザーを使用できます。

セキュリティ向上のため、マルチテナント環境の各PDBに対して一意のオペレーティング・システム・ユーザーを設定することをお薦めします。そうすることで、oracleオペレーティング・システム・ユーザーより権限の低いユーザーとしてオペレーティング・システムとの対話を行えるほか、PDBに属するデータを、他のPDBに接続しているユーザーのアクセスから保護することにも役立ちます。

3.8.2 PDBのオペレーティング・システム・ユーザーの構成

DBMS_CREDENTIAL.CREATE_CREDENTIALプロシージャで、PDBのオペレーティング・システム・ユーザーを設定できます。

  1. DBMS_CREDENTIAL PL/SQLパッケージに対するEXECUTE権限およびALTER SYSTEMシステム権限を持つユーザーとして、データベース・インスタンスのルートにログインします。
    たとえば:
    sqlplus c##sec_admin
    Enter password: password
  2. DBMS_CREDENTIAL.CREATE_CREDENTIALプロシージャを実行して、オペレーティング・システム・ユーザーのOracle資格証明を作成します。
    たとえば、os_adminという名前のユーザーの資格証明を設定するには、次のようにします。
    BEGIN 
     DBMS_CREDENTIAL.CREATE_CREDENTIAL (
        credential_name => 'PDB1_OS_USER',
        username        => 'os_admin',
        password        => 'password');
    END;
    /
    
  3. オペレーティング・システム・ユーザーが使用されるPDBに接続します。
    たとえば:
    CONNECT cc##sec_admin@hrpdb
    Enter password: password
    

    使用可能なPDBを検索するには、show pdbsコマンドを実行します。現在のPDBを確認するには、show con_nameコマンドを実行します。

  4. ステップ2で資格証明を設定したユーザーに対して、PDB_OS_CREDENTIAL初期化パラメータを設定します。
    たとえば:
    ALTER SYSTEM SET PDB_OS_CREDENTIAL = PDB1_OS_USER SCOPE = SPFILE;

    PDB_OS_CREDENTIALパラメータは静的なパラメータであるため、SCOPE = SPFILE句を使用して設定する必要があります。

  5. データベース・インスタンスを再起動します。
    SHUTDOWN IMMEDIATE
    STARTUP

関連トピック

3.9 ユーザーのグローバル認証とグローバル認可

ユーザーのグローバル認証とグローバル認可を使用すると、ユーザー関連情報を一元管理できます。

3.9.1 グローバルなユーザー認証と認可の構成について

LDAPベースのディレクトリ・サービスで、認可も含めたユーザー関連情報を集中管理します。

これにより、ユーザーおよび管理者はデータベース内でグローバル・ユーザーとして識別されます。これは、そのユーザーがTLSによって認証され、ユーザーの管理がデータベースの外部で集中化されたディレクトリ・サービスによって行われることを意味します。グローバル・ロールはデータベース内で定義され、そのデータベースに対してのみ認識されますが、グローバル・ロールに対する認可はディレクトリ・サービスによって行われます。

ノート:

ユーザーはTransport Layer Security (TLS)で認証されるユーザーであっても構いません。この場合、認可はディレクトリで管理されておらず、これらのユーザーが持っているのはローカル・データベース・ロールのみです。

このような集中管理によって、エンタープライズ・ユーザーエンタープライズ・ロールの作成が可能になります。エンタープライズ・ユーザーの定義と管理は、ディレクトリ内で行います。エンタープライズ・ユーザーには企業内で一意の識別情報があり、複数データベースにまたがるアクセス権限を決定するエンタープライズ・ロールを割り当てることができます。エンタープライズ・ロールは1つ以上のグローバル・ロールで構成されているため、グローバル・ロールのコンテナとみなすことができます。

また、集中管理されたユーザーを使用して、Microsoft Active Directoryなどのディレクトリ・サービスを介してユーザーを認証および認可することもできます。

3.9.2 ディレクトリ・サービスで認可されるユーザーの構成

ディレクトリ・サービスで認可されるようにグローバル・ユーザーまたは複数のエンタープライズ・ユーザーを構成できます。

3.9.2.1 プライベート・スキーマを持つグローバル・ユーザーの作成

プライベート・スキーマを持つユーザー・アカウントを作成するには、エンタープライズ・ディレクトリにとって有意義な識別子(識別名またはDN)を指定します。

ただし、ユーザーによるアクセスが必要なすべてのデータベースとディレクトリにこのユーザーを作成する必要があることに注意してください。
  • プライベート・スキーマを持つグローバル・ユーザーを作成するには、CREATE USER ... IDENTIFIED GLOBALLY SQL文を使用します。

    標準のLDAPデータ交換形式(LDIF)フィールドを含めることができます。たとえば、SSLによって認証され、エンタープライズ・ディレクトリ・サービスによって認可される、プライベート・スキーマを持つグローバル・ユーザー(psmith_gl)を作成するには、次のようにします。

    CREATE USER psmith_gl IDENTIFIED GLOBALLY AS 'CN=psmith,OU=division1,O=example,C=US';

    詳細は、次のとおりです。

    • CNは、このユーザーの共通名psmith_glを指します。

    • OUは、ユーザーの組織単位division1を指します。

    • Oは、ユーザーの組織Exampleを指します。

    • Cは、組織Exampleが存在する国USを指します。

3.9.2.2 スキーマを共有する複数のエンタープライズ・ユーザーの作成

複数のエンタープライズ・ユーザーがデータベース内の1つのスキーマを共有できます

これらのユーザーは、エンタープライズ・ディレクトリ・サービスによって認可されますが、データベース内に個々のプライベート・スキーマを持ちません。また、ユーザーはデータベース内に個別に作成されません。ユーザーは、データベース内の共有スキーマに接続します。

  1. 次の例を使用して、データベースに共有スキーマを作成します。
    CREATE USER appschema IDENTIFIED GLOBALLY AS '';
    
  2. ディレクトリに、複数のエンタープライズ・ユーザーとマッピング・オブジェクトを作成します。

    このマッピング・オブジェクトは、ユーザーのDNを共有スキーマにマップする方法をデータベースに伝えます。完全な識別名(DN)マッピング(一意のDN 1つに対して1つのディレクトリ・エントリが対応する)を作成するか、または、ユーザーごとに複数のDNコンポーネントを1つのスキーマにマップできます。たとえば:

    OU=division1,O=Example,C=US
    

    関連項目:

    これらのマッピングの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』 を参照してください。

ほとんどのユーザーは専用スキーマを必要としないため、スキーマに依存しないユーザーを実装することで、ユーザーをデータベースから切り離すことができます。データベース内で同じスキーマを共有する複数のユーザーを作成すると、各ユーザーは他のデータベース内の共有スキーマにもエンタープライズ・ユーザーとしてアクセスできます。

3.9.3 グローバル認証とグローバル認可の利点

ユーザーのグローバル認証とグローバル認可には、複数のメリットがあります。

  • SSL、KerberosまたはWindowsネイティブ認証を使用して、厳密な認証が行われます。

  • ユーザーと権限を全社規模で集中管理できます。

  • 管理が容易です。ユーザーごとに、社内の各データベースにスキーマを作成する必要がありません。

  • シングル・サインオンが容易になります。ユーザーは1回のサインオンのみで複数のデータベースおよびサービスにアクセスできます。さらに、パスワードを使用しているユーザーは、パスワード認証されたエンタープライズ・ユーザーを受け入れる複数データベースにアクセスするための単一パスワードを持つことができます。

  • グローバルなユーザー認証と認可はパスワード・ベースのアクセスを提供するため、以前に定義されたパスワード認証方式のデータベース・ユーザーを、集中管理されているディレクトリに(ユーザー移行ユーティリティを使用して)移行できます。これによって、以前のリリースのOracle Databaseクライアントで使用可能だったグローバル認証と認可が引き続きサポートされます。

  • CURRENT_USERデータベース・リンクはグローバル・ユーザーとして接続します。ローカル・ユーザーはストアド・プロシージャとの関連においてグローバル・ユーザーとして、グローバル・ユーザー・パスワードをリンク定義に保管することなく、接続できます。

3.10 ユーザーとパスワード認証のための外部サービスの構成

外部サービス(オペレーティング・システムまたはネットワーク)でパスワードを管理し、ユーザーを認証できます。

3.10.1 外部認証について

外部認証を使用する場合、ユーザー・アカウントはOracle Databaseでメンテナンスされますが、パスワード管理とユーザー認証は外部サービスによって実行されます。

この外部サービスは、オペレーティング・システムでもOracle Netのようなネットワーク・サービスでもかまいません。パスワード・ファイルを使用してユーザーを認証する場合、SYSDBASYSOPERSYSASMSYSBACKUPSYSDGおよびSYSKM管理権限を付与されたユーザーに対して外部認証を構成できます。

外部認証の場合、データベースはデータベース・アカウントへのアクセス制限を、その基礎となるオペレーティング・システムまたはネットワーク認証サービスに依存します。データベース・パスワードは、このタイプのログインには使用されません。オペレーティング・システムまたはネットワーク・サービスで許可されている場合は、それにより、ユーザーがデータベースにログインする前にユーザーを認証できます。

また、集中管理されたユーザーを使用して、Microsoft Active Directoryなどのディレクトリ・サービスを介してユーザーを認証および認可することもできます。

3.10.2 外部認証の利点

外部認証には、複数のメリットがあります。

これらのメリットは次のとおりです。

  • スマートカード、指紋、Kerberos、オペレーティング・システムなど、使用可能な認証メカニズムの選択肢が増えます。

  • Kerberosなどのネットワーク認証サービスの多くがシングル・サインオンをサポートしているため、ユーザーは多数のパスワードを記憶する必要がありません。

  • 前述の外部認証メカニズムのいずれかをすでに使用している場合は、そのメカニズムをデータベースで使用することで、管理費用を節減できます。

3.10.3 外部認証の有効化

外部認証を使用可能にするには、初期化パラメータOS_AUTHENT_PREFIXを設定し、この接頭辞をOracle Databaseユーザー名で使用します。

このOS_AUTHENT_PREFIXパラメータは、Oracle Databaseで全ユーザーのオペレーティング・システム・アカウント名の先頭に追加する接頭辞を定義します。Oracle Databaseは、ユーザーが接続しようとすると、接頭辞付きのユーザー名をデータベース内のOracle Databaseユーザー名と比較します。

  1. OS_AUTHENT_PREFIXをNULL文字列(空の二重引用符""で指定)に設定します。NULL文字列を使用すると、オペレーティング・システム・アカウント名に接頭辞は追加されないため、Oracle Databaseユーザー名とオペレーティング・システム・ユーザー名は完全に一致します。

    たとえば:

    OS_AUTHENT_PREFIX=" "
    
  2. OS_AUTHENT_PREFIXはデータベースの存続期間中は必ず同じままにします。接頭辞を変更した場合、古い接頭辞を含むデータベース・ユーザー名は、パスワード認証を使用するように変更しないかぎり、接続に使用できません。

OS_AUTHENT_PREFIXパラメータのデフォルト値はOPS$であり、これによって古いバージョンのOracle Databaseとの下位互換性を維持しています。たとえば、OS_AUTHENT_PREFIXを次のように設定する場合を想定します。

OS_AUTHENT_PREFIX=OPS$

オペレーティング・システム・アカウント名tsmithを持つユーザーが、Oracleデータベース・インストールに接続する際にオペレーティング・システムによって認証された場合、Oracle Databaseは対応するデータベース・ユーザーOPS$tsmithの存在をチェックし、存在している場合はこのユーザーを接続できます。オペレーティング・システムによって認証されたユーザーへの参照には、OPS$tsmithのように、必ず接頭辞OPS$が含まれる必要があります。

ノート:

OS_AUTHENT_PREFIX初期化パラメータに指定する文字列は、オペレーティング・システムによって大/小文字が区別される場合があります。この初期化パラメータの詳細は、使用しているオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。

3.10.4 外部認証されるユーザーの作成

外部認証されるユーザーは、オペレーティング・システムやネットワーク・サービスで認証されます。

外部認証されるユーザーを作成できます。Oracle Databaseがこの外部ログイン認証に依存するのは、特定のユーザーのデータベース・リソースへのアクセス権を特定のオペレーティング・システム・ユーザーに付与する場合です。

  • CREATE USER文のIDENTIFIED EXTERNALLY句を使用して、外部認証されるユーザーを作成します。

次の例では、Oracle Databaseによって識別され、オペレーティング・システムまたはネットワーク・サービスによって認証されるユーザーを作成します。この例では、OS_AUTHENT_PREFIXパラメータは空白(" ")に設定されていると想定しています。

CREATE USER psmith IDENTIFIED EXTERNALLY;

3.10.5 オペレーティング・システムを使用したユーザー・ログインの認証

Oracle Databaseで許可されるオペレーティング・システム認証ログインは、保護された接続のみを介したログインであるため、Oracle Netおよび共有サーバー構成を使用したログインは含まれません。

このタイプのオペレーティング・システム認証がデフォルトです。この制限によって、リモート・ユーザーが、ネットワーク接続を介して別のオペレーティング・システムのユーザーになりすますことを防止します。

データベース初期化パラメータ・ファイルでREMOTE_OS_AUTHENTパラメータをTRUEに設定すると、データベースは保護されていない接続を介して受け取ったクライアント・オペレーティング・システム・ユーザー名を受け入れてアカウント・アクセスに使用します。一般にPCなどのクライアントは、オペレーティング・システムの認証を適切に実行していない場合があるため、この機能を有効にするとセキュリティが非常に低下します。

デフォルトの設定REMOTE_OS_AUTHENT = FALSEを使用すると、安全性の高い構成となり、Oracleデータベースに接続するクライアントがサーバーベースで適切に認証されます。

REMOTE_OS_AUTHENTパラメータは、Oracle Database 11g リリース1(11.1)では非推奨となっており、下位互換性のためにのみ保持されている点に注意してください。

このパラメータに対する変更は、次回インスタンスを起動して、データベースをマウントしたときに有効となります。一般的に、ホスト・オペレーティング・システムを介したユーザー認証では、個別のデータベース・ユーザー名やパスワードを指定せずに、Oracle Databaseに迅速かつ簡便に接続できます。ユーザー・エントリも、データベースとオペレーティング・システムの各監査証跡で互いに対応します。

3.10.6 ネットワーク認証を使用したユーザー・ログインの認証

Oracle厳密認証が実行するネットワーク認証は、Kerberosなどのサード・パーティ・サービスを使用するよう構成できます。

Oracle厳密認証を唯一の外部認証サービスとして使用している場合、Oracle厳密認証で可能になるのは保護された接続のみであるため、REMOTE_OS_AUTHENTパラメータの設定は無意味になります。

3.11 複数層の認証と認可

中間層アプリケーションを保護するために、Oracle Databaseは権限を制限し、すべての層のクライアントの識別情報を保持し、クライアントによるアクションを監査します。

トランザクション処理モニターのようにタスクの非常に多い中間層を使用するアプリケーションでは、中間層に接続しているクライアントの識別情報が保持される必要があります。中間層を使用することの1つの利点が接続プーリングであり、これにより複数のユーザーは、それぞれが個別の接続を必要とせずに、データベース・サーバーにアクセスできるようになります。このような環境では、接続を非常に迅速に設定および停止できる必要があります。

この種の環境では、Oracle Call Interfaceを使用して、各ユーザーのデータベース・パスワード認証を可能にする軽量セッションを作成できます。この方法によって、中間層を介して実際のユーザーの識別性が保たれるため、各ユーザーの個別のデータベース接続によるオーバーヘッドは生じません。

パスワードあり、またはパスワードなしで軽量セッションを作成できます。ただし、中間層がファイアウォールの外部またはファイアウォールにある場合は、軽量セッションごとに専用パスワードを設定する方がセキュリティが向上します。内部アプリケーション・サーバーの場合は、パスワードなしの軽量セッションの方が適している場合があります。

3.12 クライアント、アプリケーション・サーバーおよびデータベース・サーバーの管理とセキュリティ

複数層環境では、アプリケーション・サーバーはクライアントにデータを提供し、1つ以上のデータベース・サーバーとのインタフェースとして機能します。

アプリケーション・サーバーではWebブラウザなどのクライアントの資格証明を検証でき、データベース・サーバーではアプリケーション・サーバーで実行される操作を監査できます。監査対象の操作には、クライアントで表示する情報の要求など、クライアントのためにアプリケーション・サーバーが実行する操作が含まれます。特定のクライアントに関連しないアプリケーション・サーバー操作の例には、データベース・サーバーへの接続要求があります。

複数層環境における認証は、トラスト領域に基づいています。クライアント認証は、アプリケーション・サーバーのドメインで実行されます。アプリケーション・サーバー自身は、データベース・サーバーによって認証されます。次の操作が行われます。

  • エンド・ユーザーは通常、パスワードまたはX.509証明書を使用して、アプリケーション・サーバーに認証の証明を提供します。

  • アプリケーション・サーバーは、エンド・ユーザーを認証してから、それ自体をデータベース・サーバーに対して認証します。

  • データベース・サーバーは、アプリケーション・サーバーを認証し、エンド・ユーザーの存在を検証して、そのエンド・ユーザーへの接続権限がアプリケーション・サーバーにあることを検証します。

アプリケーション・サーバーでは、かわりに接続するエンド・ユーザーのロールを使用可能にすることもできます。アプリケーション・サーバーは、これらのロールを認証リポジトリとして機能するディレクトリから取得できます。アプリケーション・サーバーが要求できるのは、これらのロールを使用可能にすることのみです。データベースは、次の要件を検証します。

  • クライアント内部のロール・リポジトリをチェックして、そのクライアントにこれらのロールがあることを検証します。

  • アプリケーション・サーバーに、ユーザーのために接続し、これらのロールをユーザーのように使用できる権限があることを検証します。

次の図は、複数層認証の例を示しています。

次のアクションが実行されます。

  1. ユーザーは、パスワードまたはTransport Layer Securityを使用してログインします。認証情報はOracle Application Serverを介して渡されます。

  2. Oracle Internet Directoryはユーザーを認証し、そのユーザーに対応付けられたロールをウォレットから取得して、この情報をOracle Application Serverに戻します。

  3. Oracle Application Serverは、ユーザーの識別情報が格納されているウォレットを含むOracle Databaseでこの情報をチェックし、そのユーザーのロールを設定します。

中間層アプリケーションのセキュリティでは、次のような重要な問題に対処する必要があります。

  • アカウンタビリティ。データベース・サーバーは、アプリケーションのアクションとアプリケーションがクライアントのかわりに行うアクションを識別できる必要があります。この2種類のアクションを監査できる必要があります。

  • 最低限の権限。不慮または不正による無許可のアクティビティの危険性を排除するため、ユーザーと中間層には、それぞれのアクションを実行するために必要最小限の権限を与える必要があります。

3.13 複数層環境でのユーザー識別情報の保持

中間層サーバーを使用してプロキシ認証を行ったり、クライアント識別子を使用してデータベースが認識しないアプリケーション・ユーザーを識別したりできます。

3.13.1 プロキシ認証に対する中間層サーバーの使用

Oracle Call Interface (OCI)、JDBC/OCIまたはJDBCシン・ドライバでは、データベース・ユーザーまたはエンタープライズ・ユーザーのプロキシ認証に対する中間層がサポートされます。

3.13.1.1 プロキシ認証について

Oracle Databaseでは、Oracle Call Interface(OCI)、JDBC/OCIまたはJDBCシン・ドライバによって、データベース・ユーザーまたはエンタープライズ・ユーザーにプロキシ認証を提供します。

エンタープライズ・ユーザーは、Oracle Internet Directoryで管理されるユーザーで、データベースの共有スキーマにアクセスします。

次の3つの形式のプロキシ認証を使用して、クライアントを認証する中間層サーバーを安全な方法で設計できます。

  • 中間層サーバーは、データベース・サーバーを使用してそれ自体を認証し、クライアント(この場合はアプリケーション・ユーザーまたは別のアプリケーション)は、この中間層サーバーを使用してそれ自体を認証します。クライアントの識別情報は、データベースに到達するまで確実に保持されます。

  • クライアント(この場合はデータベース・ユーザー)は、中間層サーバーによって認証されません。クライアントの識別情報とデータベース・パスワードは、中間層サーバーを経由してデータベース・サーバーに渡され、そこで認証されます。

  • クライアント(この場合はグローバル・ユーザー)は中間層サーバーによって認証され、中間層を介して次のいずれかを渡します。クライアントのユーザー名はそこから取得されます。

    • 識別名(DN)

    • 証明書

いずれの場合でも、中間層サーバーにクライアントの代理としての機能を与えるために、管理者は中間層サーバーを認可する必要があります。

3.13.1.2 プロキシ認証の利点

複数層環境では、プロキシ認証を使用すると、中間層アプリケーションのすべての層を通じてクライアント識別情報と権限が保持され、クライアントのアクションが監査されます。

たとえば、この機能によって、Webアプリケーション(プロキシとして機能する)を使用するユーザーの識別情報を、アプリケーションを介してデータベース・サーバーに渡すことができます。

3層システムは、組織にとって次のようなメリットがあります。

  • 組織は、アプリケーション・ロジックをアプリケーション・サーバーに、データ記憶域をデータベースにパーティション化することによって、アプリケーション・ロジックとデータ記憶域を分離できます。

  • アプリケーション・サーバーおよびWebサーバーを使用して、データベースに格納されているデータにアクセスできます。

  • ユーザーは、操作が簡単で使い慣れたブラウザ・インタフェースを使用できます。

  • 組織では、多数のシック・クライアントを多数のシン・クライアントと1つのアプリケーション・サーバーに置き換えることによって、コンピューティング・コストを低く抑えることもできます。

さらに、Oracle Databaseのプロキシ認証には、次のセキュリティ上のメリットがあります。

  • 中間層がかわりに接続できるユーザー、および中間層がユーザーに対して想定できるロールを制御することによって制限付きトラスト・モデルが実現します。

  • OCI、JDBC/OCIまたはJDBCシン・ドライバでユーザー・セッションをサポートし、クライアント再認証のためのオーバーヘッドを排除することによってスケーラビリティが得られます。

  • 実際のユーザーの識別情報をデータベースに到達するまで保持し、実際のユーザーのかわりに行われるアクションの監査を可能にすることによって、アカウンタビリティが得られます。

  • ユーザーがデータベースに認識されている環境と、ユーザーが単なるアプリケーション・ユーザーでデータベースには認識されていない環境の両方をサポートすることによって柔軟性が得られます。

    ノート:

    Oracle Databaseはこのプロキシ認証機能を3つの層のみでサポートしています。複数の中間層を横断してのサポートはありません。

3.13.1.3 プロキシ・ユーザー・アカウントの作成者とは

プロキシ・ユーザー・アカウントを作成するためには、ユーザーには特別な権限が必要です。

これらの権限は次のとおりです。

  • プロキシ・ユーザー・アカウントとして使用されるデータベース・ユーザー・アカウントを作成するためのCREATE USERシステム権限

  • Oracle Database Vaultが有効な場合にプロキシ・ユーザー・アカウントを作成するためのDV_ACCTMGRロール

  • CREATE SESSIONシステム権限をプロキシ・ユーザー・アカウントに付与できること

  • 既存のユーザー・アカウントがプロキシ・アカウントを介してデータベースに接続できるようにするためのALTER USERシステム権限

3.13.1.4 プロキシ・ユーザー・アカウントの作成のガイドライン

プロキシ・ユーザー・アカウントを作成する際の特別なガイドラインがあります。

  • セキュリティを高めて最小限の権限の原則を守るために、プロキシ・ユーザー・アカウントにCREATE SESSION権限のみを付与します。このユーザーに他の一切の権限を付与しないでください。プロキシ・ユーザー・アカウントは、他のユーザーがプロキシ・アカウントを使用して接続できるようにする場合にのみ使用されます。接続中に実施されるすべての権限は、プロキシ・アカウントではなく、接続しているユーザーに属する必要があります。

  • すべてのパスワードと同様、プロキシ・ユーザーに作成するパスワードも強力であり容易に推測されないものにしてください。複数のユーザーがプロキシ・ユーザーとして接続することになるため、このパスワードを強力にすることが特に重要であることを忘れないでください。

  • Oracle厳密認証ネットワーク接続機能を使用してネットワーク傍受を防ぐことを検討してください。

  • 接続ユーザーが持っている制御の量をさらに微調整する場合は、接続ユーザーがプロキシ・アカウントを介して接続しているときに使用するロールを制限することを検討してください。ALTER USER文のWITH ROLE句を使用すると、指定されたロールまたは指定されたロール以外のロールを使用して接続するユーザー、あるいはロールをまったく使用せずに接続するユーザーを構成できます。プロキシ・ユーザーは、WITH ROLE句に含まれているロールのみアクティブにできることに注意してください。プロキシ・ユーザー・セッションには、クライアント(つまり現在の)ユーザーに直接付与されたすべての権限が付与されます。

  • プロキシ・セッションのプロキシ・ユーザーは、WITH ROLEまたはWITH ROLE ALL句でロールを有効にできる場合にのみ、パスワード保護されたロールまたはセキュア・アプリケーション・ロールを有効にできます。(この句を指定しない場合、WITH ROLE ALLがデフォルトになります。)WITH ROLEでセキュア・ロールを指定しない場合、正しいパスワードによってもこれらのロールを有効にできません。

3.13.1.5 プロキシ・ユーザー・アカウントの作成と、作成したプロキシ・ユーザー・アカウントを介したユーザー接続の認可

CREATE USER文およびALTER USER文を使用して、プロキシ・ユーザーを作成し、このユーザーを介して接続するユーザーを認可できます。

プロキシ・セッションのプロキシ・ユーザーは、WITH ROLEまたはWITH ROLE ALL句でロールを有効にできる場合にのみ、パスワード保護されたロールまたはセキュア・アプリケーション・ロールを有効にできます。(この句を指定しない場合、WITH ROLE ALLがデフォルトになります。)WITH ROLEでセキュア・ロールを指定しない場合、正しいパスワードによってもこれらのロールを有効にできません。

  1. CREATE USER文を使用してプロキシ・ユーザー・アカウントを作成します。

    たとえば:

    CREATE USER appuser IDENTIFIED BY password;
    
  2. ALTER USER文のGRANT CONNECT THROUGH句を使用して、既存のユーザーがプロキシ・ユーザー・アカウントを介して接続できるようにします。

    たとえば:

    ALTER USER preston GRANT CONNECT THROUGH appuser;
    

    ユーザー名とプロキシの組合せは、250文字を超えないように注意してください。

    ユーザーprestonは多数のロールを持っているが、このユーザーがappuserプロキシ・アカウントを介してデータベースに接続しているときに使用するのは1つのロール(たとえばappuser_role)のみになるようにするとします。次のALTER USER文を使用できます。

    ALTER USER preston GRANT CONNECT THROUGH appuser WITH ROLE appuser_role;
    

    ユーザーprestonが持っている他のロールはすべて、このユーザーがappuserプロキシとして接続しているかぎり使用できなくなります。

これらのステップが完了した後で、ユーザーprestonは、次のようにappuserプロキシ・ユーザーを使用して接続できます。

CONNECT appuser[preston]
Enter password: appuser_password
3.13.1.6 プロキシ・ユーザー・アカウントと、そのアカウントを介して接続するユーザーの認可

CREATE USER文を使用すると、次のタイプのユーザー・アカウントを作成でき、これらのすべてがプロキシ・アカウントとして使用できます。

これらのアカウントを次に示します。

  • パスワードによって認証されるデータベース・ユーザー・アカウント

  • 外部ユーザー・アカウント。Secure Socket Layer (SSL)やKerberosなどの外部ソースによって認証されます。

  • グローバル・ユーザー・アカウント。エンタープライズ・ディレクトリ・サービス(Oracle Internet Directory)によって認証されます。

次のことに注意してください。

  • プロキシ・ユーザーが実行できるのは、ユーザーprestonに実行権限があるアクティビティのみです。プロキシ・ユーザーのappuser自身が持っているのは、最低限の権限(CREATE SESSION)のみであることに注意してください。

  • 中間層クライアントでのロールの使用。クライアントとして接続したときに、中間層でアクティブにすることが可能なロールも指定できます。中間層サーバーがクライアントのかわりに実行する操作は、監査の対象にできます。

  • プロキシ・ユーザーの検索。現在中間層経由での接続が認可されているユーザーを検索するには、PROXY_USERSデータ・ディクショナリ・ビューを、たとえば次のように問い合せます。

    SELECT * FROM PROXY_USERS;
    
  • プロキシ接続の取消し。プロキシ接続の認可を取り消すには、ALTER USER文のREVOKE CONNECT THROUGH句を使用します。たとえば、ユーザーprestonを、プロキシ・ユーザーappuserを介した接続から取り消すには、次の文を実行します。

    ALTER USER preston REVOKE CONNECT THROUGH appuser;
    
  • パスワードの期限切れとプロキシ接続。中間層で使用されるuse ofパスワードの期限切れは、プロキシを介して認証されたアカウントに適用されません。パスワードを期限切れにするかわりに、アカウントをロックしてください。

3.13.1.7 安全性の高い外部パスワード・ストアとプロキシ認証の使用

プロキシ認証に使用しているパスワードが不正なユーザーによって取得される懸念がある場合は、安全性の高い外部パスワード・ストアを使用します。

これを行うには、プロキシ認証で安全性の高い外部パスワード・ストアを使用してパスワード資格証明をウォレットに格納します。

プロキシ認証と安全性の高い外部パスワード・ストアを使用したOracle Databaseへの接続は、バッチ・ファイルを実行するなどの状況に理想的です。プロキシ・ユーザーがデータベースに接続し、安全性の高い外部パスワードを使用して認証を行うと、不正なユーザーが取得しようとしてもパスワードは公開されません。

安全性の高い外部パスワード・ストアとプロキシ認証を使用するには:

  1. 「プロキシ・ユーザー・アカウントと、そのアカウントを介して接続するユーザーの認可の手順に示すように、プロキシ認証アカウントを構成します。
  2. 「安全性の高い外部パスワード・ストアの使用を目的とするクライアントの構成について」で説明されているように、安全性の高い外部パスワード・ストアを構成します。

その後、ユーザーはパスワードを指定せずにプロキシを使用して接続できます。たとえば:

sqlplus [preston]/@db_alias

安全性の高い外部パスワード・ストアを使用すると、ユーザーはログイン時にユーザー名とパスワードを入力する必要がありません。指定する必要があるのは、tnsnames.oraファイルのSERVICE_NAME値(つまり、db_alias)のみです。

3.13.1.8 プロキシ認証を使用した実際のユーザーの識別情報の引渡し

エンタープライズ・ユーザーまたはデータベース・ユーザーにOracle Call Interface、JDBC/OCIまたはシン・ドライバを使用できます。

これらのツールによって、中間層は複数のユーザー・セッションを1つのデータベース接続内で設定して各々のユーザー・セッションが接続ユーザーを一意に識別するようにできます(接続プーリング)。

これらのセッションにより、中間層からデータベースまで別個のネットワーク接続を作成することによるネットワーク・オーバーヘッドが削減されます。

クライアントから中間層を介してデータベースに対して認証する場合の完全な認証順序は次のようになります。

  1. クライアントは、中間層が受け入れる任意の認証形式を使用して、中間層に対する認証を行います。たとえば、クライアントは、ユーザー名とパスワード、またはSSLによるX.509証明書を使用して、中間層に対する認証を実行できます。

  2. 中間層は、データベースが受け入れる任意の認証形式を使用して、中間層自体をデータベースに対して認証します。認証形式には、パスワード、またはKerberosチケットやX.509証明書(SSL)などのOracle Databaseがサポートしている認証メカニズムがあります。

  3. 次に、中間層はOCI、JDBC/OCIまたはシン・ドライバを使用して、ユーザーに対して1つ以上のセッションを作成します。

    • ユーザーがデータベース・ユーザーの場合、セッションには少なくともデータベース・ユーザー名が含まれている必要があります。データベースで必要な場合は、このセッションにパスワードを含めることができます(データベースでは、このパスワードをデータベース内のパスワード・ストアに対して検証します)。また、ユーザーに対するデータベース・ロールのリストを含めることもできます。

    • ユーザーがエンタープライズ・ユーザーの場合、セッションはユーザーの認証方法に応じて異なる情報を提供します。

      例1: ユーザーがSSLを介して中間層に認証された場合、中間層は、そのユーザーのX.509証明書またはセッション内の証明書自体からDNを提供できます。データベースは、DNを使用してOracle Internet Directoryでユーザーを検索します。

      例2: ユーザーがパスワード認証方式のエンタープライズ・ユーザーの場合、中間層は、少なくともユーザーのグローバルな一意の名前を提供する必要があります。データベースは、この名前を使用してOracle Internet Directoryでユーザーを検索します。セッションがユーザーのパスワードも提供する場合、データベースでは、このパスワードをOracle Internet Directoryに対して検証します。ユーザー・ロールは、セッションが確立した後でOracle Internet Directoryから自動的に取得されます。

    • 中間層は、必要に応じてクライアントに対するデータベース・ロールのリストを提供する場合があります。クライアントのかわりにロールを使用する権限がプロキシにある場合は、これらのロールが使用可能になります。

  4. データベースは、ユーザーのかわりにセッションを作成する権限が中間層にあるかどうかを検証します。

    アプリケーション・サーバーがクライアントのかわりにプロキシ認証を実行することを管理者によって許可されていない場合、またはアプリケーション・サーバーが指定されたロールをアクティブにすることを許可されていない場合、OCISessionBeginコールは失敗します。

3.13.1.9 中間層の権限の制限

「最低限の権限」とは、ユーザーの権限は各自の職務を行うのに必要な最小限の権限までにする必要があるという原則です。

これを中間層アプリケーションに当てはめると、中間層は必要以上の権限を持つ必要はないということを意味します。

Oracle Databaseでは、中間層が特定のデータベース・ユーザーのかわりとしてのみ、特定のデータベース・ロールのみを使用して接続できるように、中間層を制限できます。LDAPディレクトリに保存されたエンタープライズ・ユーザーのかわりに接続するよう中間層の権限を制限するために、マップされたデータベース・ユーザーとして接続する権限を中間層に付与します。たとえば、エンタープライズ・ユーザーがAPPUSERスキーマにマップされている場合は、少なくともAPPUSERのかわりに接続する機能を中間層に付与する必要があります。そうでない場合は、エンタープライズ・ユーザーのセッションを作成しようとした場合に失敗します。

ただし、中間層がエンタープライズ・ユーザーのかわりに接続する機能は制限できません。たとえば、ユーザーSarahが中間層appsrv(データベース・ユーザーでもある)を介してデータベースに接続するとします。Sarahには複数のロールがありますが、Sarahのかわりにclerkロールのみを使用できるように中間層を制限します。

管理者は、次のSQL文を使用して、appsrvに対して、Sarahのclerkロールのみを使用してSarahのかわりに接続を開始する許可を付与できます。

ALTER USER sarah GRANT CONNECT THROUGH appsrv WITH ROLE clerk;

デフォルトでは、中間層はどのクライアントに対する接続も確立できません。許可はユーザーごとに付与する必要があります。

appsrvに対して、クライアントSarahに付与されているすべてのロールの使用を許可するには、次の文を使用します。

ALTER USER sarah GRANT CONNECT THROUGH appsrv;

中間層が別のデータベース・ユーザーのOCI、JDBC/OCIまたはシン・ドライバ・セッションを開始するたびに、データベースでは指定されたロールを使用して、そのユーザーに対する接続を開始する権限が中間層にあることを検証します。

ノート:

デフォルトのロールを使用せずに、独自のロールを作成し、そのロールに必要な権限のみを割り当ててください。独自のロールを作成すると、ロールによって付与される権限を制御でき、Oracle Databaseでデフォルトのロールが変更または削除された場合も保護されます。たとえば、現在、CONNECTロールには、データベースへの接続で直接必要になるCREATE SESSION権限のみが含まれています。しかし以前、CONNECTには、ほとんどのユーザーには不要または不適切ないくつかの追加権限がありました。余分な権限は、データベースやアプリケーションのセキュリティを危険にさらす可能性があります。これらは、CONNECTから削除されています。

プロキシ・セッションのプロキシ・ユーザーは、WITH ROLEまたはWITH ROLE ALL句でロールを有効にできる場合にのみ、パスワード保護されたロールまたはセキュア・アプリケーション・ロールを有効にできます。(この句を指定しない場合、WITH ROLE ALLがデフォルトになります。)WITH ROLEでセキュア・ロールを指定しない場合、正しいパスワードによってもこれらのロールを有効にできません。

3.13.1.10 ユーザーのプロキシとして機能し、ユーザーを認証する中間層を認可する方法

ユーザーとして接続する中間層サーバーを認可できます。

プロキシ・セッションのプロキシ・ユーザーは、WITH ROLEまたはWITH ROLE ALL句でロールを有効にできる場合にのみ、パスワード保護されたロールまたはセキュア・アプリケーション・ロールを有効にできます。(この句を指定しない場合、WITH ROLE ALLがデフォルトになります。)WITH ROLEでセキュア・ロールを指定しない場合、正しいパスワードによってもこれらのロールを有効にできません。

  • ユーザーとして接続する中間層サーバーを認可するには、ALTER USER文を使用します。

次の文は、中間層サーバーappserveがユーザーbillとして接続するのを認可します。WITH ROLE句を使用して、appservebillに関連付けられた、payrollを除くすべてのロールをアクティブにするよう指定します。

ALTER USER bill
    GRANT CONNECT THROUGH appserve 
    WITH ROLE ALL EXCEPT payroll;

ユーザーbillとして接続するための中間層サーバーの(appserve)認可を取り消すには、REVOKE CONNECT THROUGH句を使用できます。たとえば:

ALTER USER bill REVOKE CONNECT THROUGH appserve;
3.13.1.11 他の方式で認証されたユーザーのプロキシとして機能するために、中間層を認可する方法

他の方式で認証されたユーザーのプロキシとして機能するための中間層を認可できます。

現在サポートされている認証方式は、PASSWORDのみです。

  • ALTER USER ... GRANT CONNECT THROUGH文の AUTHENTICATION REQURED句を使用して、中間層がプロキシ化するユーザーを認可するが、認証はしません。

たとえば:

ALTER USER mary
    GRANT CONNECT THROUGH midtier
    AUTHENTICATION REQUIRED;

この文の中間層サーバーmidtierは、maryとしての接続を認可されており、midtierは、認証のためにユーザー・パスワードをデータベース・サーバーにも渡す必要があります。

3.13.1.12 中間層を介したデータベースへのユーザーの再認証

ALTER USER SQL文でAUTHENTICATION REQUIREDプロキシ句を使用して、認証が必要であることを指定できます。

この場合、中間層はユーザーの認証資格証明を提供する必要があります。

たとえば、ユーザーSarahが中間層appsrvを介してデータベースに接続するとします。

  • appsrvに対してユーザーSarahの認証資格証明を提供するように要求するには、次の構文を使用します。

    ALTER USER sarah GRANT CONNECT THROUGH appsrv AUTHENTICATION REQUIRED;
    

AUTHENTICATION REQUIRED句は、ユーザーが指定されたプロキシを介して認証される場合に、ユーザーの認証資格証明が提示される必要があることを示しています。

ノート:

下位互換性を維持するために、AUTHENTICATED USING PASSWORDプロキシ句を使用した場合は、Oracle DatabaseによってAUTHENTICATION REQUIREDに変換されます。

3.13.1.13 パスワード・ベースのプロキシ認証の使用

パスワード・ベースのプロキシ認証を使用すると、Oracle Databaseはクライアントのパスワードを中間層サーバーに渡します。

次に、中間層サーバーは、そのパスワードを属性として、検証のためにデータ・サーバーに渡します。

この認証の主な利点は、データベース操作を実行するために、クライアント・コンピュータにOracleソフトウェアをインストールする必要がないことです。

  • クライアントのパスワードを渡す場合、設定する属性のタイプとしてOCI_ATTR_PASSWORDを渡して、次のようにOCIAttrSet()関数をコールするように中間層サーバーを構成します。

    OCIAttrSet(
      session_handle,    /* Pointer to a handle whose attribute gets modified. */
      OCI_HTYPE_SESSION, /* Handle type: OCI user session handle. */
      password_ptr,      /* Pointer to the value of the password attribute. */
      0,                 /* The size of the password attribute value is already
                            known by the OCI library. */
      OCI_ATTR_PASSWORD, /* The attribute type. */
      error_handle);     /* An error handle used to retrieve diagnostic
                            information in the event of an error. */ 
3.13.1.14 エンタープライズ・ユーザーでのプロキシ認証の使用

プロキシ認証に対する中間層の応答方法は、ユーザーがエンタープライズ・ユーザーとして認証されているか、パスワード認証ユーザーとして認証されているかによって異なります。

中間層がエンタープライズ・ユーザーであるクライアントとしてデータベースに接続している場合は、識別名または識別名を含むX.509証明書のいずれかが、データベース・ユーザー名のかわりに渡されます。ユーザーがパスワード認証方式のエンタープライズ・ユーザーの場合、中間層は、少なくともユーザーのグローバルな一意の名前を提供する必要があります。データベースは、この名前を使用してOracle Internet Directoryでユーザーを検索します。

  • エンタープライズ・ユーザーでプロキシ認証を構成するには、適切なOracle Call Interface設定を使用するようにアプリケーション・サーバーと中間層を構成します。

    • クライアントの識別名を渡す場合、次のように、属性タイプとしてOCI_ATTR_DISTINGUISHED_NAMEを指定して、Oracle Call InterfaceメソッドOCIAttrSet()をコールするようにアプリケーション・サーバーを構成します。

      OCIAttrSet(session_handle,
                 OCI_HTYPE_SESSION,
                 distinguished_name,
                 0,
                 OCI_ATTR_DISTINGUISHED_NAME,
                 error_handle); 
      
    • 証明書全体を渡す場合、次のように、属性タイプとしてOCI_ATTR_CERTIFICATEを指定して、OCIAttrSet()をコールするように中間層を構成します。

      OCIAttrSet(session_handle,
                 OCI_HTYPE_SESSION,
                 certificate,
                 certificate_length,
                 OCI_ATTR_CERTIFICATE,
                 error_handle);
      

証明書のタイプが指定されていない場合、データベースはデフォルトの証明書タイプX.509を使用します。

ノート:

  • OCI_ATTR_CERTIFICATEは、Distinguished Encoding Rules(DER)でエンコードされています。

  • OCI_ATTR_CERTIFICATEを使用する証明書ベースのプロキシ認証は、Oracle Databaseの将来のリリースではサポートされない予定です。かわりに、OCI_ATTR_DISTINGUISHED_NAMEまたはOCI_ATTR_USERNAME属性を使用してください。

パスワード認証方式のエンタープライズ・ユーザーにプロキシ認証を使用する場合は、パスワードで認証されるデータベース・ユーザーと同じOCI属性(OCI_ATTR_USERNAME)を使用します。Oracle Databaseでは、最初にユーザー名をデータベースに対してチェックします。ユーザーが見つからなかった場合、データベースはディレクトリ内のユーザー名をチェックします。このユーザー名はグローバルに一意である必要があります。

3.13.2 データベースに認識されないアプリケーション・ユーザーの識別でのクライアント識別子の使用

クライアント識別子は、中間層システムでユーザー識別情報を保持します。また、グローバル・アプリケーション・コンテキストとは独立してこれらを使用することもできます。

3.13.2.1 クライアント識別子について

Oracle Databaseでは、アプリケーション・ユーザーに対して、組込みアプリケーション・コンテキスト・ネームスペースUSERENVのCLIENT_IDENTIFIER属性を提供します。

これらのアプリケーション・ユーザーは、アプリケーションには認識されますが、データベースには認識されません。CLIENT_IDENTIFIER属性は、アプリケーションで識別またはアクセス制御に使用する任意の値を取得し、その値をデータベースに渡すことができます。CLIENT_IDENTIFIER属性は、OCI、JDBC/OCIまたはシン・ドライバでサポートされています。

3.13.2.2 中間層システムでのクライアント識別子の使用方法

多くのアプリケーションがセッション・プーリングを使用して、複数のアプリケーション・ユーザーが再利用する複数のセッションを設定します。

ユーザーは、単一識別情報を使用してデータベースにログイン後、すべてのユーザー接続を維持する中間層アプリケーションに対して認証します。このモデルでは、アプリケーション・ユーザーはアプリケーションの中間層に対して認証されているがデータベースには認識されていないユーザーです。ここでは、これらのタイプのアプリケーションのアプリケーション・ユーザー・プロキシのように機能するCLIENT_IDENTIFIER属性を使用できます。

このモデルでは、中間層はセッション確立時にクライアント識別子をデータベースに渡します。クライアント識別子は、中間層に接続しているクライアント表す任意のもの(たとえばCookieやIPアドレスなど)です。アプリケーション・ユーザーを表しているクライアント識別子はユーザー・セッション情報の中にあり、(USERENVネーミング・コンテキストを使用して)アプリケーション・コンテキストによりアクセスすることもできます。このようにして、アプリケーションはセッションを設定して再利用できると同時に、セッション内でアプリケーション・ユーザーを追跡できます。アプリケーションはクライアント識別子をリセットできるため、異なるユーザーでセッションを再利用し、パフォーマンスが向上します。

3.13.2.3 CLIENT_IDENTIFIER属性を使用したユーザー識別情報の保持

組込みアプリケーション・コンテキスト・ネームスペースUSERENVの事前定義の属性CLIENT_IDENTIFIERは、グローバル・アプリケーション・コンテキストで使用するアプリケーション・ユーザー名を取得します。

CLIENT_IDENTIFIER属性は独立して使用することもできます。

CLIENT_IDENTIFIER属性をグローバル・アプリケーション・コンテキストから独立して使用する場合、CLIENT_IDENTIFIERは、DBMS_SESSIONインタフェースを使用して設定できます。CLIENT_IDENTIFIERをデータベースに渡す機能は、Oracle Call Interface(OCI)、JDBC/OCIまたはシン・ドライバでサポートされています。

CLIENT_IDENTIFIER属性をグローバル・アプリケーション・コンテキストで使用すると、アプリケーションの作成に必要な柔軟性と高いパフォーマンスが得られます。たとえば、ビジネス・パートナに情報を提供するWebベース・アプリケーションに、ゴールド・パートナ、シルバー・パートナおよびブロンズ・パートナという3タイプのユーザーが用意されていて、それぞれが異なるレベルの使用可能な情報を表しているとします。アプリケーションでは、ユーザーごとに個別のアプリケーション・コンテキストを持つユーザー独自のセッションを設定するのではなく、ゴールド・パートナ、シルバー・パートナおよびブロンズ・パートナ用のグローバル・アプリケーション・コンテキストを設定できます。次に、CLIENT_IDENTIFIERを使用して正しいコンテキストのセッションを指すことによって、適切なタイプのデータを取得します。アプリケーションでは、この3つのグローバル・コンテキストを一度初期化すれば、CLIENT_IDENTIFIERを使用して適切なアプリケーション・コンテキストにアクセスし、データ・アクセスを制限できます。これには、セッションを再利用できるということと、セッションごとにアプリケーション・コンテキストを個別に初期化する必要がなく、一度設定したグローバル・アプリケーション・コンテキストにアクセスできるというパフォーマンス上のメリットがあります。

3.13.2.4 グローバル・アプリケーション・コンテキストから独立したCLIENT_IDENTIFIERの使用

CLIENT_IDENTIFIER属性は、ユーザーがデータベースに認識されていないアプリケーションで特に役立ちます。

このような場合、アプリケーションは通常、単一のデータベース・ユーザーとして接続し、すべてのアクションがそのユーザーで実行されます。

すべてのユーザー・セッションが同じユーザーとして作成されるため、このセキュリティ・モデルでは、ユーザーごとにデータを分離することが困難になります。これらのアプリケーションでは、CLIENT_IDENTIFIER属性を使用すると、実際のアプリケーション・ユーザーの識別情報をデータベースに保持できます。

この方法によると、CLIENT_IDENTIFIER属性の値を変更することで、複数のユーザーがセッションを再利用できます(この属性は、実際のアプリケーション・ユーザーの名前を取得します)。結果として、ユーザーごとに個別のセッションと属性を設定するためのオーバーヘッドが回避され、アプリケーションによるセッションの再利用が可能になります。CLIENT_IDENTIFIER属性の値が変更されると、その変更は次のOCIコール、JDBC/OCIコールまたはシン・ドライバ・コールに伝達されるため、パフォーマンスが向上します。

たとえば、ユーザーDanielはWeb Expenseアプリケーションに接続します。Danielはデータベース・ユーザーではなく、一般的なWeb Expenseアプリケーション・ユーザーです。アプリケーションは組込みアプリケーション・コンテキスト・ネームスペースにアクセスして、DANIELCLIENT_IDENTIFIER属性値として設定します。DanielはWeb Expenseフォームを記入し終わるとアプリケーションを終了します。その後に、AjitがWeb Expenseアプリケーションに接続します。Ajitのために新しいセッションを設定するかわりに、アプリケーションはCLIENT_IDENTIFIERAJITに変更することにより、現在Danielに存在しているセッションを再利用します。これによりデータベースに新しい接続を設定するオーバーヘッドと、グローバル・アプリケーション・コンテキストを設定するオーバーヘッドを回避できます。CLIENT_IDENTIFIER属性は、アプリケーションがアクセス制御のベースにする任意の値に設定できます。アプリケーション・ユーザー名である必要はありません。

3.13.2.5 グローバル・アプリケーション・コンテキストから独立したCLIENT_IDENTIFIERの設定

グローバル・アプリケーション・コンテキストから独立するように、Oracle Call InterfaceによってCLIENT_IDENTIFIER設定を設定できます。

  • CLIENT_IDENTIFIER属性をOCIによって設定する場合は、OCIAttrSet()のコールでOCI_ATTR_CLIENT_IDENTIFIER属性を使用します。この結果、サーバーに対する次のリクエスト時にその情報が伝播され、サーバー・セッションに格納されます。

たとえば:

OCIAttrSet (session,
OCI_HTYPE_SESSION,
(dvoid *) "appuser1",
(ub4)strlen("appuser1"),
OCI_ATTR_CLIENT_IDENTIFIER,
*error_handle);

JDBCを使用するアプリケーションの場合、JDBCではクライアント識別子が設定されないことに注意してください。クライアント識別子を接続プール環境で設定するには、Dynamic Monitoring Service (DMS)メトリックを使用します。DMSを使用できない場合は、connection.setClientInfoメソッドを使用してください。たとえば:

connection.setClientInfo("E2E_CONTEXT.CLIENT_IDENTIFIER", "appuser"); 

関連項目:

3.13.2.6 DBMS_SESSION PL/SQLパッケージを使用したクライアント識別子の設定とクリア

DBMS_SESSION PL/SQLパッケージは、中間層とデータベース自体の両方でクライアント識別子を管理します。

DBMS_SESSIONパッケージを使用して、中間層でCLIENT_IDENTIFIERの値を設定および消去するには、SET_IDENTIFIERプロシージャとCLEAR_IDENTIFIERプロシージャを使用します。

中間層では、SET_IDENTIFIERを使用してデータベース・セッションを特定のユーザーまたはグループに対応付けます。この結果、CLIENT_IDENTIFIERはセッションの属性になるため、セッション情報で確認できます。

DBMS_SESSION.SET_IDENTIFIERプロシージャを使用する場合は、次の点に注意してください。

  • DBMS_SESSION.SET_IDENTIFIERclient_idパラメータの最大バイト数は64バイトです。64を超えると、超えた分のバイトは切り捨てられます。

  • DBMS_APPLICATION_INFO.SET_CLIENT_INFOプロシージャでクライアント識別子の値を上書きできます。通常、これらの値は一致する必要があるため、CLIENTID_OVERWRITEイベントがONに設定されている場合は、SET_CLIENT_INFOが設定されていれば、その値をSET_IDENTIFIERにより設定された値に自動的に伝播できます。CLIENTID_OVERWRITEイベントの状態をチェックするには、SHOW PARAMETERコマンドをEVENTパラメータで実行します。

    たとえば、CLIENTID_OVERWRITEが使用可能になっているとします。

    SHOW PARAMETER EVENT
    
    NAME                           TYPE               VALUE
    ------------------------------ ------------------ ------------------
    event                          string             clientid_overwrite
3.13.2.7 システム全体でのCLIENTID_OVERWRITEイベントの有効化

ALTER SYSTEM文は、システム全体でCLIENTID_OVERWRITEイベントを有効化できます。

  1. 次のALTER SYSTEM文を入力します。
    ALTER SYSTEM SET EVENTS 'CLIENTID_OVERWRITE';
    

    または、init.oraファイルに次の行を入力します。

    event="clientid_overwrite"
    
  2. データベースを再起動します。

    たとえば:

    SHUTDOWN IMMEDIATE
    STARTUP

関連項目:

3.13.2.8 現在のセッションに対するCLIENTID_OVERWRITEイベントの有効化

ALTER SESSION文は、現在のセッションのみに対してCLIENTID_OVERWRITEイベントを有効化できます。

  1. ALTER SESSION文を使用して、セッションのみに対してCLIENTID_OVERWRITEの値を設定します。

    たとえば:

    ALTER SESSION SET EVENTS 'CLIENTID_OVERWRITE OFF';
    
  2. DBMS_APPLICATION_INFO.SET_CLIENT_INFOプロシージャを使用してクライアント識別子を設定する場合は、クライアント識別子の設定が同一になるようにDBMS_SESSION.SET_IDENTIFIERを実行します。

    たとえば:

    DBMS_SESSION.SET_IDENTIFIER(session_id_p);
3.13.2.9 CLIENTID_OVERWRITEイベントの無効化

ALTER SYSTEM文は、CLIENTID_OVERWRITEイベントを無効化できます。

  1. 次のALTER SYSTEM文を入力します。
    ALTER SYSTEM SET EVENTS 'CLIENTID_OVERWRITE OFF';
    
  2. データベースを再起動します。

    たとえば:

    SHUTDOWN IMMEDIATE
    STARTUP

3.14 ユーザー認証のデータ・ディクショナリ・ビュー

Oracle Databaseには、ユーザーのロールや使用しているプロファイルなど、ユーザー認証に関する情報を表示するデータ・ディクショナリ・ビューが用意されています。

表3-5に、データ・ディクショナリ・ビューを示します。

表3-5 ユーザー認証を示すデータ・ディクショナリ・ビュー

ビュー 説明

DBA_PROFILES

設定や制限など、プロファイルに関する情報を表示します。

DBA_ROLES

データベース・ロールがデータベースにログインする際に使用する認証の種類を表示します。NONEまたはGLOBALなどがあります(AUTHENTICATION_TYPE列を問い合せます)

DBA_USERS

その他のユーザー情報から、次の情報を表示します。

  • PASSWORDまたはEXTERNALなどの、ユーザーがデータベースにログインする際に使用する認証の種類を表示します(AUTHENTICATION_TYPE列)

  • ユーザー・アカウントに存在するパスワード・バージョン(ハッシュとも呼ばれる)のバージョンのリスト(PASSWORD_VERSIONS列)

DBA_USERS_WITH_DEFPWD

ユーザー・アカウント・パスワードがデフォルト・パスワードかどうかを表示します

PROXY_USERS

現在中間層経由での接続が認可されているユーザーを表示します

V$DBLINK

既存のデータベース・リンク用のユーザー・アカウントを表示します(DB_LINKOWNER_ID列)。現在のプラガブル・データベース(PDB)に適用します

V$PWFILE

パスワード・ファイルに含まれている管理ユーザーの名前と付与された管理権限をリストします

V$SESSION

USERNAME列を問い合せると、現在のPDBに同時ログインしているユーザーが表示されます