データベースに接続するユーザーや他のエンティティを認証(アイデンティティを検証)するようにOracle Databaseを構成できます。認証は、データベース自体を利用したり、オペレーティング・システムやネットワーク経由など、様々な方法で構成できます。
内容は次のとおりです。
認証とは、データ、リソースまたはアプリケーションの使用を希望するユーザーやデバイスなどのエンティティの身元を検証することです。
アイデンティティを検証することで、その後の対話に関する信頼関係が確立されます。認証によって、アクセスとアクションを特定の識別にリンクでき、アカウンタビリティも有効化されます。認証後は、認可プロセスでそのエンティティが実行できるアクセスとアクションのレベルを許可または制限できます。
Oracle Databaseのデータベース・ユーザーと非データベース・ユーザーの両方を認証できます。簡潔性を考慮して、すべてのデータベース・ユーザーに同じ認証方式を使用するのが一般的ですが、Oracle Databaseでは1つのデータベース・インスタンスで一部またはすべての方法を使用できます。Oracle Databaseでは、データベース管理者が特別なデータベース操作を実行するため、そのための特別な認証プロシージャが必要です。また、Oracle Databaseでは、ネットワーク認証のセキュリティを確保するために送信時にパスワードの暗号化も実行されます。
認証後は、認可プロセスでそのエンティティが実行できるアクセスとアクションのレベルを許可または制限できます。認可については、「権限とロール認可の構成」を参照してください。
ユーザーのパスワードは様々な方法で保護できます。たとえば、パスワードの作成要件の制御、パスワード管理ポリシーの使用などの方法があります。
内容は次のとおりです。
関連項目:
パスワードの保護に関するガイドラインは、パスワードの保護に関するガイドラインを参照してください
パスワードを暗号化してユーザーを認証するようにOracle XML DBを構成するとき、他のデータは暗号化する必要がない場合(例: イントラネットの電子メール)の詳細は、『Oracle XML DB開発者ガイド』を参照してください
Oracle Databaseでは、ユーザーのパスワードを保護するように設計された組込みパスワード保護が提供されています。
提供されるパスワード保護は、次のとおりです。
パスワード暗号化。Oracle Databaseでは、Advanced Encryption Standard(AES)を使用して、ネットワーク(クライアントとサーバー間、双方のサーバー間)接続中にパスワードを自動的かつ透過的に暗号化し、その後ネットワーク経由で送信します。ただし、SQL文内で指定されたパスワード(例: CREATE USER user_name IDENTIFIED BY password;
)は、ネットワーク・トレース・ファイル内のクリアテキストでネットワーク経由で送信されます。このため、アドバンスト・セキュリティ・オプションのネイティブ・ネットワーク暗号化を有効にするか、Secure Sockets Layer (SSL) 暗号化を構成する必要があります。
パスワードの複雑度のチェック。デフォルトのインストールでは、Oracle Databaseには、ora12c_verify_function
およびora12c_strong_verify_function
パスワード検証ファンクションがあります。これらの機能では、新しいパスワードや変更されたパスワードの複雑性が十分であり、パスワードを推測してシステムに侵入しようとする侵入者を防ぐことができるかどうかを確認します。パスワードの複雑性チェックを手動で有効にする必要があります。さらに、ユーザーのパスワードの複雑度はカスタマイズできます。詳細は、「パスワードの複雑度検証の概要」を参照してください。
パスワード突破の防止。ユーザーが誤ったパスワードを使用してOracle Databaseへのログインを複数回試行した場合、Oracle Databaseによってログインが1秒ずつ遅延されます。この保護は、異なるIPアドレスまたは複数のクライアント接続からのログインに適用されます。この機能により、侵入者がログインを試みるときに一定時間内に試すことができるパスワードの数が大幅に減少します。ログイン失敗による遅延によって、各ログイン試行の失敗にかかる時間が延び、(通常、こうした攻撃では非常に多くの試行に失敗せざるを得ないため)パスワード推測攻撃全体にかかる時間が増加します。
非管理ログインの場合、Oracle Databaseは、ログイン失敗による遅延に対して排他ロックを設定することによって、同時パスワード推測攻撃からデータを保護します。これによって、侵入者がログイン失敗による遅延を回避しようとする(最初の推測に失敗して遅延された後すぐに別のデータベース・セッションで次の同時推測を試行した場合)のを阻止します。侵入者は、このタイプの同時パスワード推測攻撃に対してサーバー使用率を利用します。サーバーを制圧せずに、すべてのCPUリソースを使い果たします。この結果、侵入者が未検出のままになると同時に、侵入者は1秒間に可能なかぎり多くの同時推測を実行できます。
攻撃対象のアカウントに対して排他ロックを保持することによって、Oracle Databaseでは同時パスワード推測攻撃が緩和されますが、同時にそのアカウントはサービス拒否(DoS)攻撃を受けやすいままになります。この問題に対処するには、FAILED_LOGIN_ATTEMPTS
パラメータがUNLIMITED
に設定されたパスワード・プロファイルを作成し、このパスワード・プロファイルをそのユーザー・アカウントに適用する必要があります。FAILED_LOGIN_ATTEMPTS
パラメータの設定によって、ログイン失敗による遅延は実施されず、ログイン試行失敗回数は制限されません。このようなタイプのアカウントについては、長いランダムなパスワードを使用することをお薦めします。
同時パスワード推測攻撃の保護は、管理ユーザー接続には適用されません。これは、このような接続は常に使用可能な状態である必要があり、サービス拒否攻撃の影響を受けない必要があるためです。したがって、すべての管理権限アカウントに対して長いパスワードを選択することをお薦めします。
パスワードでの大/小文字の区別の規定。パスワードは大/小文字が区別されます。たとえば、パスワードがhPP5620qr
の場合、hpp5620QR
またはhPp5620Qr
と入力すると失敗します。パスワードでの大/小文字の区別、およびパスワード・ファイルやデータベース・リンクへの影響については、「パスワードでの大/小文字の区別の管理」を参照してください。
12Cパスワード・バージョンを使用したパスワードのハッシュ化。ユーザーのパスワードを検証し、パスワード作成で大/小文字の区別を適用するために、12C
パスワード・バージョンが使用されていて、これは、パスワードベースの鍵導出関数(PBKDF2)およびSHA-512暗号化ハッシュ関数を含む非最適化されたアルゴリズムに基づいています。「パスワードのセキュリティへの脅威からの12Cパスワード・バージョンによる保護」を参照してください。
パスワードに関する最低要件のセットが提供されています。
パスワードは30バイト以内にする必要があります。パスワードを保護するには、パスワードが適切な長さになるよう要求することから、サイトで適用されるパスワード複雑度ポリシー要件を強制するカスタムのパスワード複雑度検証スクリプトの作成まで、様々な方法があります。「パスワードの保護に関するガイドライン」で説明する追加ガイドラインを参照してください。
IDENTIFIED BY
句を受け入れるSQL文でもパスワードを作成できます。
ユーザーのパスワードを作成するには、CREATE USER
、ALTER USER
、GRANT 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;
関連項目:
パスワードがサイトに対して十分な複雑度を備えていることを確認する方法は、パスワードの複雑度検証の概要を参照してくださいパスワード管理ポリシーで、ユーザーのパスワードの安全性を強化できる一連の制限事項を作成して実施できます。
内容は次のとおりです。
関連項目:
この項で説明するSQL文の構文および各文に固有の情報は、『Oracle Database SQL言語リファレンス』を参照してください
パスワードに依存しているデータベース・セキュリティ・システムでは、パスワードの機密を常に保つ必要があります。
パスワードは盗難や悪用などの被害を受けやすいため、Oracle Databaseではパスワード管理ポリシーが使用されています。データベース管理者およびセキュリティ管理者がユーザー・プロファイルを介してパスワード管理ポリシーを制御することで、データベース・セキュリティの管理を強化できます。
ユーザー・プロファイルの作成には、CREATE PROFILE
文が使用できます。プロファイルは、CREATE USER
またはALTER USER
文を使用してユーザーに割り当てます。
DBA_USERS_WITH_DEFPWD
データ・ディクショナリ・ビューで、デフォルトのパスワードを使用するユーザー・アカウントを確認できます。
データベースを作成すると、ほとんどのデフォルト・アカウントは、パスワードが期限切れのためロックされます。以前のリリースのOracle Databaseからアップグレードした場合は、デフォルト・パスワードが設定されているユーザー・アカウントが存在している可能性があります。それらは、データベースの作成時に作成されたデフォルト・アカウント(HR
、OE
、SCOTT
アカウントなど)です。
セキュリティを強化するために、それらのアカウントのパスワードを変更してください。周知されているデフォルト・パスワードを使用すると、データベースが侵入者から攻撃を受けやすくなります。
プロファイルとは、データベース・リソースに関する制限を設定するパラメータの集合です。
プロファイルをユーザーに割り当てた場合、そのユーザーはそれらの制限を超えることはできません。プロファイルを使用すると、ユーザーごとのセッション数、ロギングやトレースの機能など、データベース設定を構成できます。また、プロファイルによってユーザー・パスワードも制御できます。プロファイル内の現行のパスワード設定に関する情報は、DBA_PROFILES
データ・ディクショナリ・ビューを問い合せることで確認できます。
表3-1に、デフォルト・プロファイルのパスワード固有のパラメータ設定を示します。
表3-1 デフォルト・プロファイルのパスワード固有の設定
パラメータ | デフォルト設定 | 説明 |
---|---|---|
|
|
ユーザーがログインを試行して失敗する最大回数。この回数を超えるとアカウントがロックされます。 注意:
|
|
|
パスワードが期限切れになる前に、ユーザーがパスワードを変更するための日数を設定します。 詳細は、パスワード・エイジングおよび期限切れの制御についてを参照してください。 |
|
|
ユーザーが現行のパスワードを使用できる日数を設定します。 詳細は、パスワード・エイジングおよび期限切れの制御についてを参照してください。 |
|
|
ログインを指定の回数だけ連続して失敗した後に、アカウントがロックされる日数を設定します。この期間が経過すると、アカウントのロックは解除されます。このユーザー・プロファイル・パラメータは、管理者のメンテナンス負荷を高めることなく、ユーザー・パスワードに対する総当り攻撃を容易に防止するのに役立ちます。 詳細は、ログイン失敗後のユーザー・アカウントの自動ロックを参照してください。 |
|
|
現行のパスワードを再利用できるようになるまでに必要なパスワード変更の回数を設定します。 詳細は、ユーザーによる以前のパスワードの再利用の制御を参照してください。 |
|
|
パスワードを再利用できない日数を設定します。 詳細は、ユーザーによる以前のパスワードの再利用の制御を参照してください。 |
ログイン試行の失敗、パスワードのロック回数、パスワードの再利用、その他の設定などのプロファイルの制限を変更できます。
これらの設定については、表3-1で説明されています。セキュリティを強化するために、必要に応じて、この表に示すデフォルト設定を使用してください。
ALTER PROFILE
文を使用して、ユーザーのプロファイル制限を変更します。
例:
ALTER PROFILE prof LIMIT FAILED_LOGIN_ATTEMPTS 9 PASSWORD_LOCK_TIME 10;
関連項目:
CREATE PROFILE
文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
ALTER PROFILE
文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
この項で説明しているパスワード関連パラメータの詳細は、『Oracle Databaseリファレンス』を参照してください
Oracleは、デフォルトのパスワード・セキュリティ設定を無効化および有効化するために使用できるスクリプトを提供しています。
データベースを手動で作成した場合は、secconf.sql
スクリプトを実行して、Oracleのデフォルトのパスワード設定をデータベースに適用する必要があります。Database Configuration Assistant(DBCA)を使用して作成されたデータベースではこの設定が使用されますが、手動で作成したデータベースでは使用されません。
secconf.sql
スクリプトは$ORACLE_HOME/rdbms/admin
ディレクトリにあります。secconf.sql
スクリプトはパスワード設定と監査設定の両方に影響を与えます。他のセキュリティ設定には影響しません。
Oracle Databaseでは、ログイン試行に指定の回数だけ連続して失敗した後、ユーザーのアカウントをロックできます。
指定した時間間隔が経過した後で自動的にユーザー・アカウントをロックするか、またはロックを解除するためにデータベース管理者の介入を必要とするには、CREATE PROFILE
文またはALTER PROFILE
文でユーザーのPASSWORD_LOCK_TIME
プロファイル・パラメータを設定します。
たとえば、次に時間間隔を10日に設定します。
PASSWORD_LOCK_TIME = 10
次のことに注意してください。
また、データベース管理者が明示的に解除する必要があるように、手動でアカウントをロックすることもできます。
ログインの失敗が許容される回数は、CREATE PROFILE
文を使用して指定します。また、アカウントがロックされる時間の長さも指定できます。
ユーザーがログインに失敗するたびに、Oracle Databaseでは次第に遅延時間が長くなります。
アカウントのロック解除の間隔を指定しない場合、PASSWORD_LOCK_TIME
はデフォルト・プロファイルに指定されている値を想定します。(推奨値は1日です。)PASSWORD_LOCK_TIME
をUNLIMITED
として指定すると、ALTER USER
文を使用してアカウントを明示的にロック解除する必要があります。たとえば、PASSWORD_LOCK_TIME
UNLIMITED
がjohndoe
に指定されていると想定して、次の文を使用してjohndoe
アカウントをロック解除します。
ALTER USER johndoe ACCOUNT UNLOCK;
ユーザーが正常にアカウントにログインすると、Oracle Databaseでは、そのユーザーが失敗したログインの回数が0(ゼロ)にリセットされます(0でない場合)。
マルチテナント環境では、ロックされた共通ユーザー・アカウントがルート内のすべてのPDBでロックされるようになります。
CREATE PROFILE
文で、ユーザーのログイン試行がCREATE PROFILE設定に違反した場合にユーザー・アカウントをロックできます。
例3-1では、ユーザーjohndoe
に対して許容されているログイン失敗の最大回数は10回(デフォルト)、アカウントがロックされる時間の長さは30日です。アカウントのロックは、30日が経過すると自動的に解除されます。
例3-1 CREATE PROFILE文を使用したアカウントのロック
CREATE PROFILE prof LIMIT FAILED_LOGIN_ATTEMPTS 10 PASSWORD_GRACE_TIME 3 ALTER USER johndoe PROFILE prof;
ユーザー・アカウントを明示的にロックした場合、アカウントのロックは自動的には解除されません。セキュリティ管理者のみがアカウントのロックを解除できます。
ユーザー・アカウントを明示的にロックするには、CREATE USER
文またはALTER USER
文を使用します。
たとえば、次の文はユーザー・アカウントsusan
をロックします。
ALTER USER susan ACCOUNT LOCK;
指定した期間、または指定したパスワード変更回数を経過するまで、ユーザーが以前のパスワードを再利用しないようにできます。
指定した期間、ユーザーが以前のパスワードを再利用できないようにするには、CREATE
PROFILE
文またはALTER PROFILE
文を使用してパスワードの再利用のルールを構成できます。
表3-2に、ユーザーによる前のパスワードの再利用を制御するCREATE PROFILE
とALTER PROFILE
のパラメータを示します。
表3-2 前のパスワードの再利用を制御するパラメータ
パラメータ名 | 説明および使用方法 |
---|---|
|
次のいずれかを指定する必要があります。
|
|
次のいずれかを指定する必要があります。
|
パラメータを指定しない場合は、ユーザーがいつでもパスワードを再利用できる状況になります。これはセキュリティの方法としては適切ではありません。
どちらもUNLIMITED
ではない場合、両方の条件に一致した場合にのみ再利用できます。つまり、そのパスワードを最後に使用してから、指定された回数のパスワード変更を行っていること、および指定された日数が経過している必要があります。
たとえば、ユーザーAのプロファイルでPASSWORD_REUSE_MAX
が10
、PASSWORD_REUSE_TIME
が30
に指定されている場合を考えます。ユーザーAのパスワードは、そのパスワードを最後に使用してから30日が経過し、パスワードを10回再設定するまでは再利用できません。
一方のパラメータがUNLIMITED
に指定されている場合、ユーザーはパスワードを再利用できません。
両方のパラメータをUNLIMITED
に設定している場合は、両方が無視され、ユーザーはいつでもパスワードを再利用できます。
注意:
いずれかのパラメータにDEFAULT
を指定すると、DEFAULT
のプロファイルに定義されている値が使用されます。このプロファイルでは、すべてのパラメータがUNLIMITED
に設定されています。したがって、DEFAULT
のプロファイルでそのパラメータの設定を変更していない場合は、DEFAULT
として指定されているパラメータにはUNLIMITED
が使用されます。
関連項目:
CREATE PROFILE
文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
ALTER PROFILE
文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
パスワードの存続期間を指定して、この期間を過ぎるとパスワードを期限切れにできます。
つまり、ユーザーは現行の正しいパスワードを使用して次回ログインする際に、パスワードの変更を求められるということです。デフォルトでは、複雑度チェックやパスワード履歴チェックは行われないため、ユーザーは以前のパスワードや脆弱なパスワードを再利用できます。PASSWORD_REUSE_TIME
、PASSWORD_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.
パスワードの存続期間を設定した場合、存続期間の終了時にユーザーは新しいパスワードを作成する必要があります。
パスワードのライフ・サイクルの詳細は、パスワード変更のライフ・サイクルを参照してください。
パスワードの存続期間を指定するには、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;
アカウント・ステータスは、オープン、猶予期間、期限切れのいずれの場合も確認できます。
ユーザー・アカウントのステータスをチェックするには、DBA_USERS
データ・ディクショナリ・ビューのACCOUNT_STATUS
列を問い合せます。
例:
SELECT ACCOUNT_STATUS FROM DBA_USERS WHERE USERNAME = 'username';
パスワードが作成されると、そのパスワードは、次の4つのフェーズのライフ・サイクルと猶予期間をたどります。
図3-1は、パスワードの存続期間および猶予期間のライフ・サイクルを示しています。
この図の内容は次のとおりです。
フェーズ1: ユーザー・アカウントが作成されたか、既存のアカウントのパスワードが変更された後、パスワードの存続期間が開始されます。
フェーズ2: このフェーズは、パスワードの存続期間が終了した後で、正しいパスワードを使用してユーザーが再度ログインする前の期間を表しています。Oracle Databaseによってアカウント・ステータスが更新されるためには、正しい資格証明が必要です。それ以外の場合、アカウント・ステータスは変更されません。Oracle Databaseには、アカウント・ステータスを更新するためのバックグラウンド・プロセスは存在しません。アカウント・ステータスの変更はすべて、認証されたユーザーにかわって、Oracle Databaseのサーバー・プロセスによって実行されます。
フェーズ3: 最終的にユーザーがログインすると、猶予期間が開始されます。Oracle Databaseによって、現在の時間にそのアカウントのパスワード・プロファイルのPASSWORD_GRACE_TIME
設定の値を加えた値が使用されて、DBA_USERS.EXPIRY_DATE
列の値が更新されます。この時点でユーザーは、近い将来にパスワードが期限切れするというORA-28002
警告メッセージ(たとえば、PASSWORD_GRACE_TIME
が7
日に設定されている場合は、「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
文にパスワードの期限切れを解除する句はありませんが、アカウントのパスワードを変更することによって、期限切れは解除されます。
CREATE PROFILE
またはALTER PROFILE
のPASSWORD_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
に設定できますが、この設定が作用するのは猶予期間に入っていないアカウントのみです。猶予期間に入っているユーザーは、その期間を過ぎるとパスワードを変更する必要があります。
Oracle Databaseには、パスワードの複雑度の管理に使用できる一連の関数があります。
内容は次のとおりです。
複雑度検証では、パスワードを推定してシステムに入ろうとする侵入者から保護できるだけの複雑性が各パスワードに備わっているかがチェックされます。
複雑度検証ファンクションを使用すると、データベース・ユーザー・アカウントに対して強力で安全性の高いパスワードが強制的に作成されます。ユーザーのパスワードは、パスワードを推定してシステムに入ろうとする侵入者に対して、十分保護可能な複雑なものである必要があります。
Oracle Databaseにはパスワードの複雑度をチェックするパスワード検証機能が4つ用意されています。
これらの関数はutlpwdmg.sql
PL/SQLスクリプト内にあります($ORACLE_HOME/rdbms/admin
にある)。これらの関数が有効になっている場合、ユーザーがパスワードを正しく作成または変更したかどうかを確認できます。有効にすると、パスワードの複雑度のチェックはユーザーSYS
に対して適用されず、SYS
以外のユーザーにのみ適用されます。パスワードのセキュリティを強化するには、パスワード検証ファンクションとデフォルト・プロファイルを関連付けることをお薦めします。パスワード複雑度検証のカスタマイズについてには、これを実行する方法の例が示されています。
パスワード複雑度ファンクションを使用すると、ユーザーがデータにアクセスする方法をカスタマイズできます。
パスワード複雑度検証ファンクションをCREATE PROFILE
文またはALTER PROFILE
文で使用する前に、そのファンクションに対するEXECUTE
権限が付与される必要があります。
パスワード検証ファンクションは、SYS
スキーマにあります。
verify_function_11G
ファンクションは、Oracle Databaseリリース11gから開始されました。
このファンクションでは、ユーザーがパスワードを作成または変更したときに、次の要件をチェックします。
パスワードがユーザー名と同一でないこと。ユーザー名のスペルを逆にしたり、ユーザー名に数字1から100を追加したパスワードでないこと。
サーバー名と同一であったり、サーバー名に数字1から100を追加したパスワードでないこと。
パスワードを単純にしすぎないこと(たとえば、oracle
、数値1から100を追加したoracle
、welcome1
、database1
、account1
、user1234
,、password1
、oracle123
、computer1
、abcdefg1
、change_on_install
など)。
パスワードに少なくとも数字が1つと英字が1つ含まれていること。
以前のパスワードとの違いが3文字以上あること。
次の内部チェックも適用されます。
パスワードの長さが8文字以上30文字以内であること。
パスワードは二重引用符文字("
)を含みません。ただし、二重引用符で囲むことができます。
ora12c_verify_function
ファンクションは、Department of Defense Database Security Technical Implementation Guideで推奨されている要件を提供します。
このファンクションでは、ユーザーがパスワードを作成または変更したときに、次の要件をチェックします。
パスワードの長さが8文字以上であり、少なくとも数字が1つと英字が1つ含まれていること。
パスワードがユーザー名またはユーザー名のスペルを逆にしたものと同一でないこと。
パスワードがデータベース名と同一でないこと。
パスワードにoracle
(oracle123
など)の語が含まれていないこと。
パスワードを単純にしすぎないこと(たとえば、welcome1
、database1
、account1
、user1234
、password1
、oracle123
、computer1
、abcdefg1
またはchange_on_install
)。
以前のパスワードとの違いが3文字以上あること。
パスワードに少なくとも1つの特殊文字が含まれていること。
次の内部チェックも適用されます。
パスワードの長さが30文字以内であること。
パスワードは二重引用符文字("
)を含みません。ただし、二重引用符で囲むことができます。
ora12c_strong_verify_function
ファンクションは、Department of Defense Database Security Technical Implementation Guideの要件を満たしています。
このファンクションでは、ユーザーがパスワードを作成または変更したときに、次の要件をチェックします。
パスワードは、少なくとも2つの大文字、2つの小文字、2つの数値および2つの特殊文字を含む必要があります。これらの特殊文字は次のとおりです。
‘ ~ ! @ # $ % ^ & * ( ) _ - + = { } [ ] \ / < > , . ; ? ' : | (space)
パスワードは、少なくとも4つの文字が以前のパスワードと異なる必要があります。
次の内部チェックも適用されます。
パスワードの長さが9文字以上30文字以内であること。
パスワードは二重引用符文字("
)を含みません。ただし、二重引用符で囲むことができます。
Oracle Databaseを使用すると、サイトのパスワード複雑度をカスタマイズできます。
utlpwdmg.sql
スクリプトをバックアップして、このスクリプトで作成された関数を編集して、独自のパスワードの複雑度検証関数を作成できます。サイトのパスワードの保護を強化するために、独自のパスワード複雑度検証関数を作成することをお薦めします。
カスタムのパスワードの複雑度検証関数にデータ定義言語(DDL)文を含めないでください。パスワードの複雑度検証関数の実行中、DDLは使用できません。
パスワードの作成に関するガイドラインは、パスワードの保護に関するガイドラインのガイドライン1も参照してください。パスワードの複雑度のチェックはSYS
ユーザーに対して適用されないことに注意してください。utlpwdmg.sql
スクリプトを変更しない場合、デフォルト関数としてora12c_verify_function
関数を使用します。
スクリプトをカスタマイズして、パスワードの複雑度検証を有効にできます。utlpwdmg.sql
パスワード複雑度検証は、使用可能にするとすぐに有効になります。無効にする必要がある場合、次の文を実行します。
ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION NULL;
注意:
ALTER USER
文でREPLACE
句を使用できます。ユーザーは、この句を使用して、自身を認証するために以前のパスワードを指定し、期限が切れていない自分のパスワードを変更できます。
パスワードが期限切れになると、ユーザーはSQLにログインしてALTER USER
コマンドを発行できません。かわりにOCIPasswordChange()
関数を使用しますが、この場合は以前のパスワードも必要になります。
ALTER ANY USER
権限が付与されているデータベース管理者は、古いパスワードを指定せずにユーザーのパスワードを変更(新しいパスワードを適用)できます。
以前のリリースで作成されたユーザー・アカウントのパスワードに対して、パスワードの大/小文字の区別を管理できます。
内容は次のとおりです。
SEC_CASE_SENSITIVE_LOGON
初期化パラメータは、パスワードでの大/小文字の区別の使用を制御します。
SEC_CASE_SENSITIVE_LOGON
パラメータを設定できるのは、ALTER SYSTEM
権限を持つユーザーのみです。このパラメータがTRUE
に設定されていて、ユーザーがパスワードを入力するときに大/小文字の区別が適用されることを確認する必要があります。(ただし、SEC_CASE_SENSITIVE_LOGON
パラメータが非推奨ですが、下位互換性のために現在残されていることに注意してください。)
ユーザー・アカウントを作成または変更するとき、パスワードはデフォルトで大/小文字の区別があります。大/小文字の区別は、ユーザーが手動で入力するパスワードのみでなく、パスワード・ファイルにも影響を与えます。
セキュリティを強化するために、パスワードで大/小文字の区別を使用することをお薦めします。ただし、アプリケーションで互換性の問題がある場合は、SEC_CASE_SENSITIVE_LOGON
パラメータを使用して、パスワードで大/小文字の区別を無効にできます。アプリケーションでの互換性の問題の例として、Oracleサーバーに対して認証するために使用する前にパスワードが強制的に大文字になるアプリケーションやデータベース・セッションを起動するために資格証明を送信するときに複数のアプリケーション・モジュール間で大/小文字の区別が一貫していない場合などがあります。
SQLNET.ALLOWED_LOGON_VERSION_SERVER
パラメータが12
または12a
に設定されている場合は、SEC_CASE_SENSITIVE_LOGON
パラメータがFALSE
に設定されていないことを確認します。これは、このモードで使用されているセキュリティ度の強いパスワード・バージョンでは、大文字/小文字を区別するパスワード・チェックのみがサポートされているためです。互換性上の理由により、Oracle DatabaseではSQLNET.ALLOWED_LOGON_VERSION_SERVER
が12
または12a
に設定されているときにSEC_CASE_SENSITIVE_LOGON
でFALSE
の使用が禁止されてはいません。SQLNET.ALLOWED_LOGON_VERSION_SERVER
が12
または12a
に設定されている場合にSEC_CASE_SENSITIVE_LOGON
をFALSE
に設定すると、すべてのアカウントがアクセス不能になります。SQLNET.ALLOWED_LOGON_VERSION_SERVER
が11
以下の値に設定されている場合は、Oracle Database 12cの排他モード(SQLNET.ALLOWED_LOGON_VERSION_SERVER
が12
または12a
の場合)で使用されるセキュリティ度の強いパスワード・バージョンが大文字/小文字を区別しないパスワード照合をサポートしないため、SEC_CASE_SENSITIVE_LOGON
をTRUE
に設定することをお薦めします。
サーバー側の設定に加えて、ユーザーが接続しているクライアント・ソフトウェアにO5L_NP
機能フラグがあることを確認する必要があります。Oracle Databaseリリース11.2.0.4以上のすべてのクライアントにO5L_NP
機能があります。以前のクライアントがある場合は、CPUOct2012
パッチをインストールする必要があります。
パスワードの大/小文字の区別が無効化されている場合、有効化するには、SEC_CASE_SENSITIVE_LOGON
パラメータをTRUE
に設定します。
セキュリティを強化するために、安全性の高いロールのためのパスワードは、大/小文字が区別されるようにする必要があります。
Oracle Database 12cリリース1 (12.1)にアップグレードする前に、CREATE ROLE
文のIDENTIFIED BY
句を使用して安全性の高いロールを作成し、リリース12cへのアップグレード時にSQLNET.ALLOWED_LOGON_VERSION_SERVER
パラメータを12
または12a
に設定する場合、これらの安全性の高いロールを引き続き使用可能にするには、パスワードを変更する必要があります。
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";
Oracle Databaseの以前のリリースでは、パスワードで大文字と小文字は区別されませんでした。
以前のリリース(たとえば、リリース10gなど)から現在のデータベース・リリースにユーザー・アカウントをインポートする場合、デフォルトでは、これらのユーザーは、パスワードを大文字/小文字のどちらで入力しても依然としてデータベースにログインできます。しかし、以前のリリースのユーザー・アカウントのパスワードは変更されると、大/小文字が区別されるようになります。
10G
パスワード・バージョンを使用するユーザー・アカウントを検索して、これらのアカウントのパスワードを再設定する必要があります。これにより、SQLNET.ALLOWED_LOGON_VERSION_SERVER
パラメータの設定に基づく適切なパスワード・バージョンが次のように生成されます。
SQLNET.ALLOWED_LOGON_VERSION_SERVER=8
は、3つのすべてのパスワード・バージョン10G
、11G
および12C
を生成します。
SQLNET.ALLOWED_LOGON_VERSION_SERVER=12
は、11G
および12C
パスワード・バージョンを生成し、10G
パスワード・バージョンを削除します。
SQLNET.ALLOWED_LOGON_VERSION_SERVER=12a
は、12C
パスワード・バージョンのみ生成します。
10G
パスワード・バージョンを使用するユーザー・アカウントのパスワードを確認および再設定できます。
DBA_USERSビューの詳細は、『Oracle Databaseリファレンス』
を参照してください。
デフォルトでは、パスワード・ファイルは大/小文字を区別します。ORAPWD
コマンドライン・ユーティリティのIGNORECASE
引数は、パスワード・ファイルの大/小文字の区別を制御します。
IGNORECASE
のデフォルト値はN
(no)で、大/小文字の区別が適用されます。セキュリティを強化するために、IGNORECASE
をN
に設定するか、ignorecase
引数全体を省略します。IGNORECASE
は非推奨なので注意してください。
次の例は、パスワード・ファイルで大/小文字の区別を有効にする方法を示しています。
orapwd file=orapw entries=100
Enter password for SYS: password
このコマンドは、orapw
と呼ばれる大/小文字を区別するパスワード・ファイルを作成します。デフォルトでは、パスワードでは大文字と小文字が区別されます。その後、このパスワードを使用して接続する場合、パスワードの作成時と大/小文字を同じにして入力すれば成功します。同じパスワードでありながら大/小文字の区別が異なるパスワードを入力すると、失敗します。
以前のリリースからユーザー・アカウントをインポートし、そのアカウントがSYSDBA
またはSYSOPER
管理権限を使用して作成されている場合、アカウントはパスワード・ファイルに格納されます。この時点で、アカウントのパスワードは大/小文字が区別されません。大/小文字の区別が有効な場合、次にユーザーがパスワードを変更すると、パスワードは大/小文字が区別されます。セキュリティを強化するために、そのユーザーに対してパスワードを変更するように要請してください。
パスワード・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。
データベース・リンク接続を作成する場合は、接続用のユーザー名とパスワードを定義する必要があります。
データベース・リンク接続を作成すると、パスワードは大/小文字が区別されます。ユーザーが接続用のパスワードをどのように入力するかは、データベース・リンクが作成されたリリースによって決まります。
ユーザーは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リファレンス』を参照してください。
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エンタープライズ・ユーザー・セキュリティなど)をデプロイすることをお薦めします。
関連項目:
O7L_MRの詳細は、『Oracle Database Net Services管理者ガイド』を参照してください。
デフォルトでは、Oracle Databaseによるユーザーの認証には、3つのバージョンのパスワード・ハッシュ(10G
パスワード・バージョン、11G
パスワード・バージョンおよび12C
パスワード・バージョン)が使用されます。
10G
バージョンのパスワード・ハッシュでは、大文字と小文字が区別されません。11G
と12C
の両パスワード・バージョンでは大/小文字は区別されます。
Oracle Database 12cでは、sqlnet.ora
パラメータSQLNET.ALLOWED_LOGON_VERSION_SERVER
のデフォルトは11
(排他モードであり、10G
パスワード・バージョンの使用を禁止します)、およびSQLNET.ALLOWED_LOGON_VERSION_CLIENT
パラメータのデフォルトは、11
です。新しいアカウントについては、クライアントがOracle Database 12cの場合、Oracle Databaseは、Oracle Database 12cリリース・ソフトウェアを実行しているクライアントで12C
パスワード・バージョンを排他的に使用します。リリース12cの前に作成されたアカウントについては、SQLNET.ALLOWED_LOGON_VERSION_SERVER
パラメータが11
に設定されている場合、11G
パスワード・バージョンがアカウントに存在するかぎり、SHA-1アルゴリズムを使用したログインは成功します。アカウントのSHA-1ベリファイアを作成するため、ユーザーのパスワードを再設定する必要がある場合があります。新しいアカウントを作成する際、または既存のアカウント・パスワードを変更する際に、12C
パスワード・バージョンを生成するようこのサーバーを構成するには、SQLNET.ALLOWED_LOGON_VERSION_SERVER
パラメータを11
または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
パスワード・バージョンのみを持つ(11G
や12C
といったよりセキュアなパスワード・バージョンを持たない)アカウントのパスワードを期限切れにする必要があります。データベースはこれらのパスワード・バージョンを使用してより強固なセキュリティを提供しているため、これらのパスワード・バージョンを生成する必要があります。これらのユーザーは次のようにして検出できます。(10G
に後に空白を含めます。)
SELECT USERNAME FROM DBA_USERS WHERE PASSWORD_VERSIONS='10G ';
次に、各アカウントを次のようにして期限切れにします。
ALTER USER username PASSWORD EXPIRE;
各アカウントを期限切れにした後、これらのユーザーにログインするよう通知します。ログインの際、パスワードを変更するよう求められます。パスワードを変更すると、11G
および12C
のパスワード・バージョンがデフォルトで生成されます。Oracle Database 12cクライアントの認証には、12C
パスワード・バージョンのみが使用されます。以前のOracle Databaseクライアントの認証には、11G
パスワード・バージョンが使用されます。12C
パスワード・バージョンを排他的に使用するには、すべてのクライアントをOracle Database 12cにアップグレードする必要があります。アカウント・パスワードの期限が切れ、ALLOWED_LOGON_VERSION_SERVER
パラメータが12
または12a
に設定されている場合、10G
パスワード・バージョンは削除され、パラメータの設定に応じて次のように1つまたは2つの新しいパスワード・バージョンが作成されます。
ALLOWED_LOGON_VERSION_SERVER
が12
(デフォルト)に設定されている場合、11G
と12C
の2つのパスワード・バージョンが生成されます。
ALLOWED_LOGON_VERSION_SERVER
が12a
に設定されている場合、12C
パスワード・バージョンのみが生成されます。
詳細は、『Oracle Database Net Servicesリファレンス』のSQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの使用上の注意に関する項の表内の生成されるパスワードのバージョンの列を参照してください。
10Gおよび11Gパスワード・バージョンを使用したアカウント: リリース10g以上のクライアントを使用しているユーザーは、11G
パスワード・バージョンが使用されるため、ユーザー・ログインは成功します。ただし、最新のパスワード・バージョンを使用するには、前述のアカウントに関する箇条書き項目での説明のようにこれらのパスワードを期限切れにします。
11Gパスワード・バージョンのみを使用したアカウント: 認証で11G
パスワード・バージョンを使用します。最新のパスワード・バージョンを使用するには、1つ目の箇条書き項目での説明のようにパスワードを期限切れにします。
Oracle Database 12cのデフォルト構成(SQLNET.ALLOWED_LOGON_VERSION_SERVER
は11
)は、OCIベースのドライバを使用するOracle Database 11g以降の製品(SQL*Plus、ODBC、Oracle .NET、Oracle Forms、そして様々なサード・パーティ製Oracle Databaseアダプタなど)と互換性があることを意味します。Oracle Database 11g以降のJDBCタイプ4(シン)バージョンおよびOracle Database 10gリリース2 (10.2)以降のOracle Database Clientインタフェース(OCI)ベースのドライバとも互換性があります。
侵入者がより脆弱なパスワード・バージョンを使用するよう認証のダウングレードを試みることが多くあります。このような脆弱なパスワード・バージョンを使用しないようにサーバーを構成するには、サーバーを排他モードで実行する必要があります。
管理ユーザーとしてSQL*Plusにログインします。
次のSQL文を実行して、ユーザーのパスワード・バージョンを確認します。
SELECT USERNAME,PASSWORD_VERSIONS FROM DBA_USERS;
11G
または12C
パスワード・バージョンを持たない各ユーザーのアカウントを期限切れにします。
たとえば、ユーザーblake
がまだ10G
パスワード・バージョンを使用しているとします。
ALTER USER blake PASSWORD EXPIRE;
これらのユーザーが次にログインする際、パスワードの変更が強制され、サーバーが排他モードに必要なパスワード・バージョンを生成できます。
しかるべき期間(30日間など)内にログインするようユーザーに通知します。
ログイン時、パスワードを変更するよう求められ、排他モードでの認証に必要なパスワード・バージョンがサーバーによって生成されます。(排他モードの機能の詳細は、『Oracle Database Net Servicesリファレンス』のSQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータの使用上の注意に関する項を参照してください。)
パスワードの大/小文字を含めてこれらのテスト・スクリプトまたはバッチ・ジョブで使用されるパスワードと正確に一致するように、テスト・スクリプトまたはバッチ・ジョブで使用されるアカウントのパスワードを手動で変更します。
次のようにして排他モード構成を有効にします。
sqlnet.ora
パラメータ・ファイルのバックアップ・コピーを作成します。このファイルのデフォルトの場所は、UNIXオペレーティング・システムでは$ORACLE_HOME/network/admin
ディレクトリ、Microsoft Windowsオペレーティング・システムでは%ORACLE_HOME%\network\admin
ディレクトリです。
マルチテナント環境では、sqlnet.ora
ファイルの設定がすべてのPDBに適用されることに注意してください。
SQLNET.ALLOWED_LOGON_VERSION_SERVER
パラメータを12
または12a
に設定します。Oracle Database 12cクライアントのみを使用する場合、SQLNET.ALLOWED_LOGON_VERSION_SERVER
を12a
に設定します。
パスワード・バージョン生成のSQLNET.ALLOWED_LOGON_VERSION_SERVER
設定の効果を次の表に示します。
SQLNET.ALLOWED_LOGON_VERSION_SERVER設定 | 8 | 11 | 12 | 12a |
---|---|---|---|---|
サーバーを排他モードで実行しますか |
いいえ |
いいえ |
はい |
はい |
|
はい |
はい |
いいえ |
いいえ |
|
はい |
はい |
はい |
いいえ |
|
はい |
はい |
はい |
はい |
設定を高くすると、パスワード・バージョンの使用がさらに制限されます。8
に設定すると、ほとんどのパスワード・バージョン(つまり、10G
、11G
および12C
パスワード・バージョン)がすべて許可され、12a
に設定すると、12C
パスワード・バージョンのみが許可されます。セキュリティを強化するために、12a
へのSQLNET.ALLOWED_LOGON_VERSION_SERVER
の設定を検討してください。12
に設定すると、11G
および12C
パスワード・バージョンが許可され、認証に使用されます。
SQLNET.ALLOWED_LOGON_VERSION_SERVER
パラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。
sqlnet.ora
ファイルを保存します。
以前のリリースを実行しているターゲット・データベースへの固定データベース・リンクをホストするシステムで、SQLNET.ALLOWED_LOGON_VERSION_CLIENT
パラメータを設定します。
次の図には接続方法が示されています。SQLNET.ALLOWED_LOGON_VERSION_CLIENT
パラメータは、データベース・リンク(H)をホストするサーバーのクライアントが許可されたログオン・バージョンに影響します。この設定により、Oracle 9i(T)を実行しているサーバーなどの古いサーバーへのデータベース・リンクを通じてHを接続し、古いパッチが適用されていないクライアント(U)の接続を引き続き拒否できます。Oracle Net Servicesプロトコル・ネゴシエーションに失敗し、Oracle 9i ソフトウェアを使用して認証を試行しているこのクライアントのORA-28040: 一致する認証プロトコルがありません
エラー・メッセージが表示されます。クリティカル・パッチ・アップデートCPUOct2012が適用されているため、リリース10.2.0.xクライアント(E)のOracle Net Servicesプロトコル・ネゴシエーションに成功します。安全性の高いパスワード・バージョンを使用するため、リリース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: 一致する認証プロトコルがありません
エラーになります。SQLNET.ALLOWED_LOGON_VERSION_CLIENT
パラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。
注意:
古いOracle Databaseクライアント(リリース11.1.0.7など)を使用している場合は、アップグレードしてクリティカル・パッチ・アップデートCPUOct2012を使用することをお薦めします。CPUOct2012の詳細は、Oracle Technology Networkのサイトを参照してください。
http://www.oracle.com/technetwork/topics/security/cpuoct2012-1515893.html
侵入者が偽のサーバーを用意し、認証をダウングレードして、クライアントが、より脆弱なバージョンのパスワード・ハッシュを使用するよう仕向けることが多くあります。
10G
バージョンのパスワード・ハッシュまたは10G
と11G
のパスワード・バージョンが使用されないようにするには、サーバーの構成後に、次に示すようにクライアントを構成して排他モードで稼働するようにします。
クライアント排他モード設定を使用して、11G
および12C
の2つのパスワード・バージョンを許可する方法は、次のとおりです。
SQLNET.ALLOWED_LOGON_VERSION_CLIENT = 12
より制限の厳しいクライアント排他モード設定を使用して、12C
バージョンのパスワード・ハッシュのみを許可する方法は、次のとおりです(この設定では、クライアントはリリース12.1.0.2以降のサーバーにのみ接続できます)。
SQLNET.ALLOWED_LOGON_VERSION_CLIENT = 12a
サーバーとクライアントの両方が同じコンピュータにインストールされている場合、それぞれのTNS_ADMIN
環境変数が各Oracle Net Services構成ファイルの正しいディレクトリを指していることを確認します。そうしないと、変数が両方で同じ場合、サーバーが誤ってクライアントのSQLNET.ALLOWED_LOGON_VERSION_CLIENT
設定をかわりに使用することがあります。
古いOracle Databaseクライアント(リリース11.1.0.7など)を使用している場合は、これらのクライアントにCPUOct2012以上を適用する必要があります。このパッチを適用しないと、ユーザーはログインできなくなります。
関連項目:
SQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。
CPUOct2012の詳細は、次のOracle Technology Networkサイトを参照してください。
http://www.oracle.com/technetwork/topics/security/cpuoct2012-1515893.html
安全性の高い外部パスワード・ストアは、ストア・パスワードの資格証明に使用されるクライアント側のウォレットになります。
内容は次のとおりです。
パスワード資格証明データベース接続は、クライアント側のOracleウォレットを使用して格納できます。
Oracleウォレットは、認証および署名用資格証明を格納する安全性の高いソフトウェア・コンテナです。このウォレットの使用方法により、データベースに接続する際にパスワード資格証明に依存する大規模な配置を簡素化できます。この機能が構成されている場合、アプリケーション・コードおよびスクリプトにユーザー名とパスワードを埋め込む必要がありません。これによりパスワードが危険にさらされることがなくなるため、リスクが軽減します。また、ユーザー名またはパスワードが変更されるたびにアプリケーション・コードを変更する必要がなくなるため、パスワード管理ポリシーの適用が容易になります。
注意:
ウォレットの外部パスワード・ストアは、公開鍵インフラストラクチャ(PKI)資格証明が格納されている領域とは別の場所にあります。そのため、ウォレットの外部パスワード・ストアの資格証明管理には、Oracle Wallet Managerを使用できません。かわりに、コマンドライン・ユーティリティmkstore
を使用して資格証明を管理します。
関連項目:
Oracleウォレットの一般情報は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
ユーザー(アプリケーション、バッチ・ジョブ、スクリプトを含む)は、データベース接続文字列を指定した標準の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.com
、tnsnames.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ウォレットに格納されています。このウォレットの自動ログイン機能が使用状態になるため、システムにはウォレットを開くためのパスワードは不要です。ウォレットから、システムはデータベースにアクセスするための資格証明を、資格を証明するユーザーのために取得します。
関連項目:
自動ログイン・ウォレットの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
クライアントがWindowsネイティブ認証やSSLなどの外部認証を使用するように構成されている場合、Oracle Databaseではその認証方式が使用されます。
通常は、そのタイプの認証で使用されるものと同じ資格証明が、データベースへのログインにも使用されます。データベース認証として、その認証方式を使用しないかまたは変更するクライアントには、sqlnet.ora
のSQLNET.WALLET_OVERRIDE
パラメータをTRUE
に設定できます。SQLNET.WALLET_OVERRIDE
のデフォルト値はFALSE
で、今までと同様に認証資格証明の標準的な使用が許可されます。
安全性の高い外部パスワード・ストア機能を使用するようにクライアントを構成するには、mkstore
コマンドライン・ユーティリティを使用します。
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/ora11/network/admin)
)
)
SQLNET.WALLET_OVERRIDE = TRUE
SSL_CLIENT_AUTHENTICATION = FALSE
SSL_VERSION = 0
mkstore
コマンドライン・ユーティリティを使用すると、外部パスワード・ストアからの資格証明の表示、外部パスワード・ストアへの資格証明の追加、外部パスワード・ストアでの資格証明の変更、外部パスワード・ストアからの資格証明の削除を行うことができます。
内容は次のとおりです。
クライアント・ウォレットの外部パスワード・ストアの内容(資格証明など)を表示できます。
外部パスワード・ストアの内容をリスト表示することによって、ストアに資格証明を追加または削除するかどうかの判断に使用できる情報が提供されます。
外部パスワード・ストアの内容をリスト表示するには、コマンドラインで次のコマンドを入力します。
mkstore -wrl wallet_location -listCredential
例:
mkstore -wrl c:\oracle\product\12.1.0\db_1\wallets -listCredential
wallet_location
では、表示する外部パスワード・ストアの内容が格納されているウォレットのディレクトリ・パスを指定します。このコマンドにより、資格証明にあるデータベース・サービス名(別名)および対応するユーザー名(スキーマ)がすべてリスト表示されます。パスワードはリスト表示されません。
1つのクライアント・ウォレットに複数の資格証明を格納できます。
たとえば、クライアントのバッチ・ジョブがhr_database
に接続し、スクリプトがsales_database
に接続する場合、同じクライアント・ウォレットにこのログイン資格証明を格納できます。ただし、同じウォレット内の同じデータベースに対する、(複数のスキーマにログインするための)複数の資格証明を格納することはできません。同じデータベースに対する複数のログイン資格証明がある場合、別のウォレットに格納する必要があります。
既存のクライアント・ウォレットにデータベース・ログイン資格証明を追加するには、コマンドラインで次のコマンドを指定します。
mkstore -wrl wallet_location -createCredential db_alias username
次に例を示します。
mkstore -wrl c:\oracle\product\12.1.0\db_1\wallets -createCredential orcl system
Enter password: password
次のように値を指定します。
wallet_location
は、資格証明を追加するクライアント・ウォレットが格納されるディレクトリのパスです。
db_alias
は、tnsnames.ora
ファイルでデータベースを指定するために使用するTNS別名、またはOracleネットワーク上のデータベースを識別するために使用するサービス名です。
username
は、アプリケーションが接続するスキーマに対するデータベース・ログイン資格証明です。プロンプトが表示された後に、このユーザーのパスワードを入力します。
データベース接続文字列が変わった場合は、ウォレットに格納されているデータベース・ログイン資格証明を変更できます。
ウォレット内のデータベース・ログイン資格証明を変更するには、コマンドラインで次のコマンドを入力します。
mkstore -wrl wallet_location -modifyCredential db_alias username
次に例を示します。
mkstore -wrl c:\oracle\product\12.2.0\db_1\wallets -modifyCredential sales_db
Enter password: password
次のように値を指定します。
wallet_location
は、ウォレットが格納されているディレクトリのパスです。
db_alias
は、データベースの識別に使用する新規または個別の別名です。これは、tnsnames.ora
ファイルでデータベースを指定するために使用するTNS別名、もしくはOracleネットワークのデータベースを識別するために使用する任意のサービス名になります。
username
は、新規または他のデータベース・ログイン資格証明です。プロンプトが表示された後に、このユーザーのパスワードを入力します。
データベースが現存しない場合や、特定のデータベースへの接続を無効にする場合は、データベースのログイン資格証明をウォレットから削除できます。
ウォレットのデータベース・ログイン資格証明を削除するには、コマンドラインで次のコマンドを入力します。
mkstore -wrl wallet_location -deleteCredential db_alias
次に例を示します。
mkstore -wrl c:\oracle\product\12.1.0\db_1\wallets -deleteCredential orcl
次のように値を指定します。
wallet_location
は、ウォレットが格納されているディレクトリのパスです。
db_alias
は、tnsnames.ora
ファイルでデータベースを指定するために使用するTNS別名、またはOracle Databaseネットワーク上のデータベースを識別するために使用するサービス名です。
データベース管理者を認証するには、強力な認証を使用するか、オペレーティング・システムから行うか、パスワードを使用してデータベースから行います。
内容は次のとおりです。
データベース管理者は、データベースの起動や停止などの特別な管理操作を実行します。
Oracle Databaseには、SYSDBA
、SYSOPER
、SYSBACKUP
、SYSDG
またはSYSKM
管理権限を持つデータベース管理者の認証を保護するための方式が用意されています。
データベース管理者を一元管理するための強力な認証方式として、直接認証、Kerberos認証、Secure Sockets Layer (SSL)認証があります。
内容は次のとおりです。
厳密認証を使用すると、複数のデータベースに対するSYSDBA
およびSYSOPER
のアクセスを集中管理できます。
データベース管理のこのような認証は、次の状況で使用を検討してください。
パスワード・ファイルの脆弱性が懸念される場合。
サイトで非常に強固なセキュリティが要求される場合。
アイデンティティ管理をデータベースから分離する必要がある場合。たとえば、Oracle Internet Directory(OID)などのディレクトリ・サーバーを使用すると、そのサーバーを個別にメンテナンス、保護および管理できます。
Oracle Internet Directoryサーバーを使用してSYSDBA
およびSYSOPER
の接続を認可するには、使用している環境に応じて、この項で説明する次のいずれかの方式を使用します。
Oracle Internet Directoryで、管理ユーザーのディレクトリ認証を構成します。
この結果、ユーザーは、SQL*PlusでCONNECT
文にネット・サービス名を指定してログインできるようになります。たとえば、ネット・サービス名がorcl
の場合、SYSDBA
としてログインするには、次のように入力します。
CONNECT SOMEUSER@ORCL AS SYSDBA
Enter password: password
リモート認証でパスワード・ファイルを使用するようにデータベースが構成されている場合、Oracle Databaseでは最初にパスワード・ファイルをチェックします。
関連項目:
信頼できるユーザーへの権限付与に関するガイドラインは、「ユーザー・アカウントと権限の保護に関するガイドライン」を参照してください
LDAP_DIRECTORY_SYSAUTH
の詳細は、Oracle Databaseリファレンスを参照してください
LDAP_DIRECTORY_ACCESS
の詳細は、Oracle Databaseリファレンスを参照してください
Oracle Internet Directoryを使用して、管理ユーザーのKerberos認証を構成できます。
この結果、ユーザーは、SQL*PlusでCONNECT
文にネット・サービス名を指定してログインできるようになります。たとえば、ネット・サービス名がorcl
の場合、SYSDBA
としてログインするには、次のように入力します。
CONNECT /@orcl AS SYSDBA
Secure Sockets Layer (SSL)を使用して、クライアント側とサーバー側の両方で管理ユーザーを認証できます。
SSLを使用するように、次の手順でクライアントを構成します。
クライアント・ウォレットおよびユーザー証明書を構成します。sqlnet.ora
構成ファイルのウォレットの場所を更新します。
ウォレット・マネージャを使用して、クライアント・ウォレットおよびユーザー証明書を構成します。詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
サーバーDNを含み、SSLとともにTCP/IPを使用するように、tnsnames.ora
のOracleネット・サービス名を構成します。
listener.ora
でSSLとともにTCP/IPを構成します。
sqlnet.ora
で、クライアントSSL暗号スイートおよび必要なSSLバージョンを設定し、SSLを認証サービスとして設定します。
SSLを使用するように、次の手順でサーバーを構成します。
TCPSのデータベース・リスナーに対してSSLを使用可能にし、対応するTNS名を指定します。TNS名はNet Configuration Assistantを使用して構成できます。
データベースPKI資格証明をデータベース・ウォレットに格納します。この操作は、ウォレット・マネージャを使用して実行できます。
LDAP_DIRECTORY_ACCESS
初期化パラメータをSSL
に設定します。
ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = SSL;
LDAP_DIRECTORY_ACCESS
の詳細は、『Oracle Databaseリファレンス』を参照してください。
SSLユーザー認証用にOracle Internet Directoryを構成します。
エンタープライズ・ユーザー・セキュリティのSSL認証の構成方法は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
Oracle Internet Directoryで、このユーザーが管理するデータベースに対して、SYSDBA
またはSYSOPER
権限をユーザーに付与します。
サーバー・コンピュータで、LDAP_DIRECTORY_SYSAUTH
初期化パラメータをYES
に設定します。
ALTER SYSTEM SET LDAP_DIRECTORY_SYSAUTH = YES;
LDAP_DIRECTORY_SYSAUTH
パラメータをYES
に設定すると、SYSDBA
およびSYSOPER
ユーザーは、厳密認証方式を使用してデータベースへの認証を行うことができます。LDAP_DIRECTORY_SYSAUTH
の詳細は、『Oracle Databaseリファレンス』を参照してください。
この結果、ユーザーは、SQL*PlusでCONNECT
文にネット・サービス名を指定してログインできるようになります。たとえば、ネット・サービス名がorcl
の場合、SYSDBA
としてログインするには、次のように入力します。
CONNECT /@orcl AS SYSDBA
WindowsおよびUNIXの両システムで、DBA
権限のあるグループを使用してオペレーティング・システムに対して認証します。
通常、データベース管理者のオペレーティング・システム認証には、オペレーティング・システムにグループを作成すること、そのグループにDBA
権限を付与すること、および権限を付与する管理者の名前をグループに追加することが含まれます。(UNIXシステムでは、このグループはdbaグループです。)
注意:
マルチテナント環境では、PDBではなくCDBルートにのみ、データベース管理者のオペレーティング・システム認証を使用できます。
Microsoft Windowsシステムの場合:
SYSDBA
管理権限で接続するユーザーはWindowsネイティブ認証を利用できます。このユーザーがドメイン・アカウントを使用してOracle Databaseを操作する場合は、ローカル管理権限およびORA_DBA
メンバーシップを明示的に付与する必要があります。
Microsoft Windows組込みのアカウントではなく、権限の低いMicrosoft Windowsのユーザー・アカウントを使用して、Oracle Databaseサービスを実行することをお薦めします。
関連項目:
Windows固有のオペレーティング・システム・グループの詳細は、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』を参照してください。
WindowsのOracle Databaseサービスの詳細は、『Oracle Databaseプラットフォーム・ガイドfor Microsoft Windows』を参照してください。
データベース管理者のオペレーティング・システム認証の構成の詳細は、オペレーティング・システム固有のOracle Databaseマニュアルを参照してください。
SYSDBA
、SYSOPER
、SYSASM
、SYSBACKUP
、SYSDG
およびSYSKM
管理権限を付与されたOracle Databaseユーザーは、データベース固有のパスワード・ファイルを使用して最初に認証されます。
これらの権限によって、次のアクティビティが使用可能になります。
SYSOPER
システム権限によって、データベース管理者はSTARTUP
、SHUTDOWN
、ALTER DATABASE
OPEN/MOUNT
、ALTER DATABASE
BACKUP
、ARCHIVE
LOG
およびRECOVER
の各操作を実行できます。また、SYSOPER
権限には、RESTRICTED
SESSION
権限も含まれます。
SYSDBA
管理権限には、ADMIN
OPTION
およびSYSOPER
システム権限も含めて、すべてのシステム権限が含まれます。CREATE
DATABASE
と時間ベースのリカバリが許可されます。
SYSDBA
またはSYSOPER
の権限のあるユーザーを含むパスワード・ファイルを、異なるデータベース間で共有できます。SYS
ユーザー以外のユーザーが含まれた共有パスワード・ファイルも保持できます。異なるデータベース間でパスワード・ファイルを共有するには、init.ora
ファイルのREMOTE_LOGIN_PASSWORDFILE
パラメータをSHARED
に設定します。
REMOTE_LOGIN_PASSWORDFILE
初期化パラメータの設定をNONE
からEXCLUSIVE
またはSHARED
に変更する場合は、パスワード・ファイルとディクショナリ・パスワードを必ず同期化してください。詳細は、『Oracle Database管理者ガイド』を参照してください。
パスワード・ファイル・ベースの認証が、デフォルトで使用可能です。つまり、データベースは、SYSDBA
またはSYSOPER
管理権限のあるユーザーの認証についてパスワード・ファイルを使用できます。パスワード・ファイル・ベースの認証は、ORAPWD
ユーティリティを使用してパスワード・ファイルを作成すると、アクティブになります。
$ORACLE_HOME/dbs
ディレクトリに対してEXECUTE
権限および書込み権限を持つユーザーがORAPWD
ユーティリティを実行できます。
自動ストレージ管理(ASM)環境では、共有ASMパスワード・ファイルを作成できます。ASMパスワード・ファイルを作成するSYSASM
システム権限が必要なことに注意してください。詳細は、『Oracle Automatic Storage Management管理者ガイド』を参照してください。
SESSIONS_PER_USER
およびIDLE_TIME
などのリソース制限は、管理ログインには適用されません。
注意:
パスワード・ファイルに含まれているユーザーのリストを検索するには、V$PWFILE_USERS
データ・ディクショナリ・ビューを問い合せることができます。
AS SYSDBA
またはAS SYSOPER
で要求された接続は、これらのフレーズを使用する必要があります。使用していない場合、接続は失敗します。Oracle DatabaseパラメータO7_DICTIONARY_ACCESSIBILITY
はデフォルトではFALSE
に設定されており、大切なデータ・ディクショナリへのアクセスを認可ユーザーのみに制限しています。このパラメータによって、AS SYSDBA
またはAS SYSOPER
構文も必須になります。
パスワード・ファイルの使用は、セキュリティ上のリスクを伴う可能性があることに注意してください。
このため、「管理者の厳密認証と集中管理」で説明した認証方式を使用することを検討してください。
パスワードによるセキュリティのリスクの例は、次のとおりです。
侵入者がパスワード・ファイルを盗んだり攻撃する可能性があります。
多くのユーザーがデフォルト・パスワードを変更しない場合があります。
パスワードが簡単に推定される場合があります。
パスワードがディレクトリ内に存在すると、無防備になります。
短かすぎたり簡単に入力できるパスワードは、侵入者がパスワードの暗号化ハッシュを取得した場合に無防備になります。
注意:
パスワード・ファイルの作成およびメンテナンスの詳細は、『Oracle Database管理者ガイド』を参照してください。
ユーザーのデータベース認証では、認証を実行するためにデータベース自体の情報を使用する必要があります。
内容は次のとおりです。
Oracle Databaseでは、データベース自体に格納されている情報を使用して、データベースに接続しようとするユーザーを認証できます。
データベース認証を使用するようにOracle Databaseを構成するには、対応するパスワードを指定して各ユーザーを作成する必要があります。ユーザー名にはNational Language Support (NLS)の文字書式を使用できますが、パスワードに二重引用符文字を含めることはできません。ユーザーは、接続の確立時にそのユーザー名およびパスワードを入力する必要があります。
Oracle Databaseは、ユーザーのパスワードの一方向ハッシュを生成し、入力されたログイン・パスワードの検証時に使用するため格納します。古いクライアントをサポートするために、様々なハッシング・アルゴリズムを使用してユーザーのパスワードの一方向ハッシュを生成するようにOracle Databaseを構成できます。生成されたパスワード・ハッシュはパスワード・バージョンと呼ばれ、その略称は10G
、11G
および12C
です。略称10G
、11G
および12C
は、一方向パスワード・ハッシング・アルゴリズムの詳細を略したものに相当します。その詳細は、ドキュメントとしてDBA_USERS
ビューのPASSWORD_VERSIONS
列で説明されています。指定したユーザーのパスワード・バージョンのリストを確認するには、DBA_USERS
ビューのPASSWORD_VERSIONS
列を問い合せます。
クライアントまたはクライアントとして機能するデータベース・サーバーの認証中に許可する認証プロトコルを指定するには、サーバーsqlnet.oraファイルのSQLNET.ALLOWED_LOGON_VERSION_SERVER
パラメータを明示的に設定できます。(このパラメータのクライアント・バージョンは、SQLNET.ALLOWED_LOGON_VERSION_CLIENT
です。)各接続がテストされ、クライアントまたはサーバーがパートナが指定する最低バージョンを満たしていない場合は、認証に失敗してORA-28040「一致する認証プロトコルがありません」
エラーが発生します。このパラメータの値には、11、10、9または8を指定できます。デフォルト値は11です。これらの値はデータベース・サーバーのバージョンを表します。保護レベルを最大にするには、値11をお薦めします。ただし、SQLNET.ALLOWED_LOGON_VERSION_SERVER
およびSQLNET.ALLOWED_LOGON_VERSION_CLIENT
を11に設定した場合、JDBCシン・クライアントを含むOracle Databaseリリース11.1以前のクライアント・アプリケーションは、パスワード・ベースの認証を使用してOracleデータベースへの認証を行うことができない点に注意してください。
データベース認証使用時のセキュリティを高めるために、アカウントのロック、パスワード・エイジングと期限切れ、パスワード履歴およびパスワードの複雑度検証も含めたパスワード管理の使用をお薦めします。
関連項目:
パスワード複雑度検証関数の詳細は、「パスワードの複雑度検証の概要」を参照してください。
パスワード管理の詳細は、「パスワード管理ポリシーの使用」を参照してください。
データベースを使用したユーザーの認証では、次の3つのメリットがあります。
これらのメリットは次のとおりです。
ユーザー・アカウントとすべての認証がデータベースによって制御されます。データベースの外部のものには依存しません。
Oracle Databaseには、データベース認証使用時のセキュリティを高めるために、強力なパスワード管理機能が組み込まれています。
小規模なユーザー・コミュニティがある場合の管理が容易になります。
データベースで認証されるユーザーを作成する場合、このユーザーにパスワードを割り当てます。
データベースで認証されるユーザーを作成するには、ユーザーの作成時にIDENTIFIED BY
句を指定します。
たとえば、次のSQL文は、Oracle Databaseによって識別および認証されるユーザーを作成します。ユーザーsebastian
は、Oracle Databaseに接続するたびに割り当てられたパスワードを指定する必要があります。
CREATE USER sebastian IDENTIFIED BY password;
関連項目:
データベースで認証されるユーザーの作成の詳細は、ユーザー・アカウントの作成を参照してください
Oracle Databaseではオペレーティング・システムで管理されている情報を使用した認証が可能です。
オペレーティング・システムを使用したユーザーの認証には、メリットとデメリットの両方があります。
この機能には次の利点があります。
オペレーティング・システムから認証を受けたユーザーは、より簡単にOracle Databaseに接続できます。ユーザー名やパスワードを指定する必要はありません。たとえば、オペレーティング・システムにより認証されたユーザーはSQL*Plusを起動して、コマンドラインで次のコマンドを入力することによりユーザー名とパスワードのプロンプトを省略できます。
SQLPLUS /
SQL*Plusで、次のように入力します。
CONNECT /
ユーザー認証はオペレーティング・システムで集中管理され、Oracle Databaseがユーザーのパスワードを格納したり管理する必要がなくなります。ただし、ユーザー名は引き続きデータベース内で管理されます。
データベースとオペレーティング・システムの監査証跡には、同じユーザー名を使用できます。
同じシステムで、オペレーティング・システム・ユーザーと非オペレーティング・システム・ユーザーの両方を認証できます。例:
オペレーティング・システムによってユーザーを認証します。CREATE USER
文のIDENTIFIED EXTERNALLY
句を使用してユーザー・アカウントを作成し、OS_AUTHENT_PREFIX
初期化パラメータを設定して、サーバーに接続しようとするユーザーをOracle Databaseが認証するために使用する接頭辞を指定します。
非オペレーティング・システム・ユーザーを認証します。これは、パスワードが割り当てられ、データベースによって認証されるユーザーです。
Oracle Database Enterprise User Securityユーザーを認証します。このユーザー・アカウントはCREATE USER
文のIDENTIFIED GLOBALLY
句を使用して作成され、現行の同じデータベースでOracle Internet Directory(OID)によって認証されます。
ただし、オペレーティング・システムを使用してユーザーを認証する場合には、次のデメリットがあります。
ユーザーには、アクセスが必要なコンピュータのオペレーティング・システム・アカウントが必要です。必ずしもすべてのユーザー(特に管理ユーザー以外のユーザー)がオペレーティング・システム・アカウントを持っているわけではありません。
ユーザーがこの方式を使用してログインし、端末の前から離れた場合、別のユーザーはパスワードや資格証明が必要ないため簡単にログインできます。これは、深刻なセキュリティ問題になる可能性があります。
データベース・ユーザーの認証にオペレーティング・システムを使用する場合は、分散データベース環境とデータベース・リンクの管理に特別な注意が必要です。オペレーティング・システム認証のデータベース・リンクは、セキュリティ上の弱点を生み出す可能性があります。そのため、これらのリンクは使用しないことをお薦めします。
関連項目:
認証、オペレーティング・システム、分散データベースの概要および分散データ管理の詳細は、『Oracle Database管理者ガイド』を参照してください。
オペレーティング・システムによる認証の詳細は、そのオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。
ネットワークでのユーザーの認証は、サード・パーティ・サービスでSecure Sockets Layerを使用して行うことができます。
内容は次のとおりです。
Secure Sockets Layer(SSL)プロトコルは、アプリケーション・レイヤー・プロトコルです。
SSLは、Oracle Internet Directoryでのグローバル・ユーザー管理とは関係なく、データベースに対するユーザー認証に使用できます。つまり、ユーザーは、ディレクトリ・サーバーを指定しなくても、SSLを使用してデータベースへの認証を行うことができます。
関連項目:
SSLの構成の詳細は、Secure Sockets Layer認証の構成を参照してください
ネットワーク経由でOracle Databaseを認証するには、サード・パーティのサービス(Kerberos、RADIUS、ディレクトリベース・サービス、公開鍵インフラストラクチャ)を使用する必要があります。
内容は次のとおりです。
ネットワーク上のOracle Databaseユーザーを認証する場合は、サード・パーティ・ネットワーク認証サービスを使用する必要があります。
よく知られている例としては、Kerberos、PKI (公開鍵インフラストラクチャ)、RADIUS (Remote Authentication Dial-In User Service)、およびディレクトリ・ベース・サービスがあります。
ネットワーク認証サービスを使用できる場合、Oracle Databaseはこれらのネットワーク・サービスによる認証を受け入れることができます。ネットワーク認証サービスを使用する場合は、ネットワーク・ロールとデータベース・リンクについて特別な考慮事項があります。
Kerberosは、共有秘密を使用するサード・パーティの認証システムです。
Kerberosは、サード・パーティがセキュアであることを保証し、シングル・サインオン機能、集中化されたパスワード・ストレージ、データベース・リンク認証、拡張されたPCセキュリティを提供します。これは、Kerberos認証サーバーまたはCybersafe Active Trust (Kerberosをベースとした商用の認証サーバー)を介して提供されます。
関連項目:
Kerberosの詳細は、Kerberos認証の構成を参照してください
Remote Authentication Dial-In User Service (RADIUS)はユーザー認証、認可、およびアカウンティングに使用される標準のライトウェイト・プロトコルです。
RADIUSにより、ユーザーはRSA One-Time Password Specifications (OTPS)を使用してOracleデータベースに対する認証もできるようになります。
関連項目:
RADIUSの構成の詳細は、RADIUS認証の構成を参照してください
OTPSに関するRSAのドキュメント
中核となるディレクトリを使用すると、認証とその管理が効率的になります。
次のようなディレクトリベース・サービスがあります。
Lightweight Directory Access Protocol (LDAP)を使用するOracle Internet Directoryにより、中央リポジトリを使用してユーザー(エンタープライズ・ユーザーと呼ばれます)に関する情報を格納および管理できます。エンタープライズ・ユーザーのアカウントは、分散環境で作成されます。データベース・ユーザーの場合は、アクセスするデータベースごとにパスワードとともに作成する必要がありますが、エンタープライズ・ユーザーの情報にはOracle Internet Directoryで集中的にアクセスできます。このディレクトリをMicrosoft Active DirectoryやSunOneと統合することもできます。
Oracle Enterprise Security Managerを使用すると、Oracle Internet Directoryからのロールの取得と保管ができ、これにより権限の集中管理が可能になることで管理が容易になり、セキュリティ・レベルが向上します。
公開鍵インフラストラクチャ(PKI)に基づく認証システムでは、ユーザー・クライアントに電子証明書が発行されます。
これらのクライアントはこの証明書を使用して直接企業内のサーバーに身分を証明し、認証に直接的に関与しません。Oracle Databaseで提供されている、公開鍵と証明書を使用するためのPKIは、次のコンポーネントで構成されています。
SSLによる認証および保護セッション鍵管理。詳細は、Secure Sockets Layerを使用した認証を参照してください。
信頼できる証明書。識別情報を検証するときに、ユーザー証明書の署名者として信頼するサード・パーティ・エンティティを識別するために使用します。ユーザーの証明書が確認されるとき、署名者は、検証システムに格納されている認証局のトラスト・ポイントまたは信頼できる証明連鎖を使用してチェックされます。この連鎖内に複数レベルの信頼できる証明書がある場合は、下位レベルの証明書を信頼するため、それより上のレベルの証明書をすべて再検証する必要はありません。
Oracle Wallet Manager。Oracleウォレットは、ユーザーの秘密鍵、ユーザー証明書および一連のトラスト・ポイント(信頼できる認証局)を含むデータ構造です。Oracleウォレットの管理の詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
Oracle Wallet Managerを使用してOracleウォレットを管理できます。これは、Oracleウォレットのセキュリティ資格証明を管理および編集するために使用するスタンドアロンのJavaアプリケーションです。次の操作を実行します。
公開鍵と秘密鍵のペアを生成し、認証局に提出する証明書要求を作成して、ウォレットを作成します。
エンティティの証明書をインストールします。
Oracle Databaseのクライアントとサーバー上でX.509v3証明書を管理します。
エンティティの信頼できる証明書を構成します。
ウォレットをオープンして、PKIベースのサービスにアクセスできるようにします。
信頼できるエンティティ、認証局から取得された(署名された) X.509バージョン3証明書。認証局は信頼されているため、これらの証明は要求側エンティティの情報が正確であることと証明書上の公開鍵が認定されるエンティティに属していることを証明します。証明書はOracleウォレットにロードされるため、今後の認証が可能になります。
ユーザーのグローバル認証とグローバル認可を使用すると、ユーザー関連情報を一元管理できます。
内容は次のとおりです。
LDAPベースのディレクトリ・サービスで、認可も含めたユーザー関連情報を集中管理します。
これにより、ユーザーおよび管理者はデータベース内でグローバル・ユーザーとして識別されます。これは、そのユーザーがSSLによって認証され、ユーザーの管理がデータベースの外部で集中化されたディレクトリ・サービスによって行われることを意味します。グローバル・ロールはデータベース内で定義され、そのデータベースに対してのみ認識されますが、グローバル・ロールに対する認可はディレクトリ・サービスによって行われます。
注意:
ユーザーはSecure Sockets Layer (SSL)で認証されるユーザーであっても構いません。この場合、認可はディレクトリで管理されておらず、これらのユーザーが持っているのはローカル・データベース・ロールのみです。
このような集中管理によって、エンタープライズ・ユーザーとエンタープライズ・ロールの作成が可能になります。エンタープライズ・ユーザーの定義と管理は、ディレクトリ内で行います。エンタープライズ・ユーザーには企業内で一意の識別情報があり、複数データベースにまたがるアクセス権限を決定するエンタープライズ・ロールを割り当てることができます。エンタープライズ・ロールは1つ以上のグローバル・ロールで構成されているため、グローバル・ロールのコンテナとみなすことができます。
関連項目:
Secure Sockets Layer認証の詳細は、「管理ユーザーのSecure Sockets Layer認証の構成」を参照してください。
SYSDBA
またはSYSOPER
のアクセスを集中管理する場合は、「管理者の厳密認証と集中管理」を参照してください。
ディレクトリ・サービスで認可されるようにグローバル・ユーザーまたは複数のエンタープライズ・ユーザーを構成できます。
内容は次のとおりです。
プライベート・スキーマを持つユーザー・アカウントを作成するには、エンタープライズ・ディレクトリにとって有意義な識別子(識別名または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
は、組織の例が配置される国US
を示します。
複数のエンタープライズ・ユーザーがデータベース内の1つのスキーマを共有できます
これらのユーザーは、エンタープライズ・ディレクトリ・サービスによって認可されますが、データベース内に個々のプライベート・スキーマを持ちません。また、ユーザーはデータベース内に個別に作成されません。ユーザーは、データベース内の共有スキーマに接続します。
ほとんどのユーザーは専用スキーマを必要としないため、スキーマに依存しないユーザーを実装することで、ユーザーをデータベースから切り離すことができます。データベース内で同じスキーマを共有する複数のユーザーを作成すると、各ユーザーは他のデータベース内の共有スキーマにもエンタープライズ・ユーザーとしてアクセスできます。
ユーザーのグローバル認証とグローバル認可には、複数のメリットがあります。
SSL、KerberosまたはWindowsネイティブ認証を使用して、厳密な認証が行われます。
ユーザーと権限を全社規模で集中管理できます。
管理が容易です。ユーザーごとに、社内の各データベースにスキーマを作成する必要がありません。
シングル・サインオンが容易になります。ユーザーは1回のサインオンのみで複数のデータベースおよびサービスにアクセスできます。さらに、パスワードを使用しているユーザーは、パスワード認証されたエンタープライズ・ユーザーを受け入れる複数データベースにアクセスするための単一パスワードを持つことができます。
グローバルなユーザー認証と認可はパスワード・ベースのアクセスを提供するため、以前に定義されたパスワード認証方式のデータベース・ユーザーを、集中管理されているディレクトリに(ユーザー移行ユーティリティを使用して)移行できます。これによって、以前のリリースのOracle Databaseクライアントで使用可能だったグローバル認証と認可が引き続きサポートされます。
CURRENT_USER
データベース・リンクはグローバル・ユーザーとして接続します。ローカル・ユーザーはストアド・プロシージャとの関連においてグローバル・ユーザーとして、グローバル・ユーザー・パスワードをリンク定義に保管することなく、接続できます。
関連項目:
グローバル認証と認可、エンタープライズ・ユーザーおよびエンタープライズ・ロールの詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
外部サービス(オペレーティング・サービスまたはネットワークのいずれか)は、パスワードの管理とユーザーの認証に使用されます。
内容は次のとおりです。
外部認証を使用する場合、ユーザー・アカウントはOracle Databaseでメンテナンスされますが、パスワード管理とユーザー認証は外部サービスによって実行されます。
この外部サービスは、オペレーティング・システムでもOracle Netのようなネットワーク・サービスでもかまいません。
外部認証の場合、データベースはデータベース・アカウントへのアクセス制限を、その基礎となるオペレーティング・システムまたはネットワーク認証サービスに依存します。データベース・パスワードは、このタイプのログインには使用されません。オペレーティング・システムまたはネットワーク・サービスで許可されている場合は、それにより、ユーザーがデータベースにログインする前にユーザーを認証できます。
外部認証には、複数のメリットがあります。
これらのメリットは次のとおりです。
スマートカード、指紋、Kerberos、オペレーティング・システムなど、使用可能な認証メカニズムの選択肢が増えます。
Kerberosなどのネットワーク認証サービスの多くがシングル・サインオンをサポートしているため、ユーザーは多数のパスワードを記憶する必要がありません。
前述の外部認証メカニズムのいずれかをすでに使用している場合は、そのメカニズムをデータベースで使用することで、管理費用を節減できます。
外部認証を使用可能にするには、初期化パラメータOS_AUTHENT_PREFIX
を設定し、この接頭辞をOracle Databaseユーザー名で使用します。
このOS_AUTHENT_PREFIX
パラメータは、Oracle Databaseで全ユーザーのオペレーティング・システム・アカウント名の先頭に追加する接頭辞を定義します。Oracle Databaseは、ユーザーが接続しようとすると、接頭辞付きのユーザー名をデータベース内のOracle Databaseユーザー名と比較します。
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マニュアルを参照してください。
外部認証されるユーザーは、オペレーティング・システムやネットワーク・サービスで認証されます。
外部認証されるユーザーを作成できます。Oracle Databaseがこの外部ログイン認証に依存するのは、特定のユーザーのデータベース・リソースへのアクセス権を特定のオペレーティング・システム・ユーザーに付与する場合です。
CREATE USER
文のIDENTIFIED EXTERNALLY
句を使用して、外部認証されるユーザーを作成します。
次の例では、Oracle Databaseによって識別され、オペレーティング・システムまたはネットワーク・サービスによって認証されるユーザーを作成します。この例では、OS_AUTHENT_PREFIX
パラメータは空白(" "
)に設定されていると想定しています。
CREATE USER psmith IDENTIFIED EXTERNALLY;
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に迅速かつ簡便に接続できます。ユーザー・エントリも、データベースとオペレーティング・システムの各監査証跡で互いに対応します。
中間層アプリケーションを保護するために、Oracle Databaseは権限を制限し、すべての層のクライアントの識別情報を保持し、クライアントによるアクションを監査します。
トランザクション処理モニターのようにタスクの非常に多い中間層を使用するアプリケーションでは、中間層に接続しているクライアントの識別情報が保持される必要があります。中間層を使用することの1つの利点が接続プーリングであり、これにより複数のユーザーは、それぞれが個別の接続を必要とせずに、データベース・サーバーにアクセスできるようになります。このような環境では、接続を非常に迅速に設定および停止できる必要があります。
この種の環境では、Oracle Call Interfaceを使用して、各ユーザーのデータベース・パスワード認証を可能にする軽量セッションを作成できます。この方法によって、中間層を介して実際のユーザーの識別性が保たれるため、各ユーザーの個別のデータベース接続によるオーバーヘッドは生じません。
パスワードあり、またはパスワードなしで軽量セッションを作成できます。ただし、中間層がファイアウォールの外部またはファイアウォールにある場合は、軽量セッションごとに専用パスワードを設定する方がセキュリティが向上します。内部アプリケーション・サーバーの場合は、パスワードなしの軽量セッションの方が適している場合があります。
複数層環境では、アプリケーション・サーバーはクライアントにデータを提供し、1つ以上のデータベース・サーバーとのインタフェースとして機能します。
アプリケーション・サーバーでは、Webブラウザなどのクライアントの資格証明を検証できます。また、データベース・サーバーでは、アプリケーション・サーバーで実行される操作を監査できます。監査対象の操作には、クライアントで表示する情報の要求など、クライアントのためにアプリケーション・サーバーが実行する操作が含まれます。特定のクライアントに関連しないアプリケーション・サーバー操作の例には、データベース・サーバーへの接続要求があります。
複数層環境における認証は、トラスト領域に基づいています。クライアント認証は、アプリケーション・サーバーのドメインで実行されます。アプリケーション・サーバー自身は、データベース・サーバーによって認証されます。次の操作が行われます。
エンド・ユーザーは通常、パスワードまたはX.509証明書を使用して、アプリケーション・サーバーに認証の証明を提供します。
アプリケーション・サーバーは、エンド・ユーザーを認証してから、それ自体をデータベース・サーバーに対して認証します。
データベース・サーバーは、アプリケーション・サーバーを認証し、エンド・ユーザーの存在を検証して、そのエンド・ユーザーへの接続権限がアプリケーション・サーバーにあることを検証します。
アプリケーション・サーバーでは、かわりに接続するエンド・ユーザーのロールを使用可能にすることもできます。アプリケーション・サーバーは、これらのロールを認証リポジトリとして機能するディレクトリから取得できます。アプリケーション・サーバーが要求できるのは、これらのロールを使用可能にすることのみです。データベースは、次の要件を検証します。
クライアント内部のロール・リポジトリをチェックして、そのクライアントにこれらのロールがあることを検証します。
アプリケーション・サーバーに、ユーザーのために接続し、これらのロールをユーザーのように使用できる権限があることを検証します。
図3-2に、複数層認証の例を示します。
次のアクションが実行されます。
ユーザーは、パスワードまたはSecure Sockets Layerを使用してログインします。認証情報はOracle Application Serverを介して渡されます。
Oracle Internet Directoryはユーザーを認証し、そのユーザーに対応付けられたロールをウォレットから取得して、この情報をOracle Application Serverに戻します。
Oracle Application Serverは、ユーザーの識別情報が格納されているウォレットを含むOracle Databaseでこの情報をチェックし、そのユーザーのロールを設定します。
中間層アプリケーションのセキュリティでは、次のような重要な問題に対処する必要があります。
アカウンタビリティ。データベース・サーバーは、アプリケーションのアクションとアプリケーションがクライアントのかわりに行うアクションを識別できる必要があります。この2種類のアクションを監査できる必要があります。
最低限の権限。不慮または不正による無許可のアクティビティの危険性を排除するため、ユーザーと中間層には、それぞれのアクションを実行するために必要最小限の権限を与える必要があります。
Oracle Databaseでは、プロキシ認証に対する中間層サーバーの使用や、データベースが認識しないアプリケーション・ユーザーを識別する場合のクライアント識別子の使用をサポートします。
内容は次のとおりです。
Oracle Call Interface (OCI)、JDBC/OCIまたはJDBCシン・ドライバによって、データベース・ユーザーまたはエンタープライズ・ユーザーのプロキシ認証に中間層を使用できます。
内容は次のとおりです。
Oracle Databaseでは、Oracle Call Interface(OCI)、JDBC/OCIまたはJDBCシン・ドライバによって、データベース・ユーザーまたはエンタープライズ・ユーザーにプロキシ認証を提供します。
エンタープライズ・ユーザーは、Oracle Internet Directoryで管理されるユーザーで、データベースの共有スキーマにアクセスします。
次の3つの形式のプロキシ認証を使用して、クライアントを認証する中間層サーバーを安全な方法で設計できます。
中間層サーバーは、データベース・サーバーを使用してそれ自体を認証し、クライアント(この場合はアプリケーション・ユーザーまたは別のアプリケーション)は、この中間層サーバーを使用してそれ自体を認証します。クライアントの識別情報は、データベースに到達するまで確実に保持されます。
クライアント(この場合はデータベース・ユーザー)は、中間層サーバーによって認証されません。クライアントの識別情報とデータベース・パスワードは、中間層サーバーを経由してデータベース・サーバーに渡され、そこで認証されます。
クライアント(この場合はグローバル・ユーザー)は中間層サーバーによって認証され、中間層を介して次のいずれかを渡します。クライアントのユーザー名はそこから取得されます。
識別名(DN)
証明書
いずれの場合でも、中間層サーバーにクライアントの代理としての機能を与えるために、管理者は中間層サーバーを認可する必要があります。
関連項目:
プロキシ認証の詳細は、『Oracle Database JDBC開発者ガイド』を参照してください。
複数層環境の場合、プロキシ認証は、中間層アプリケーションのすべての層を通じて、クライアント・アクションを監査してクライアントの識別情報と権限を保持します。
たとえば、この機能によって、Webアプリケーション(プロキシとして機能する)を使用するユーザーの識別情報を、アプリケーションを介してデータベース・サーバーに渡すことができます。
3層システムは、組織にとって次のようなメリットがあります。
組織は、アプリケーション・ロジックをアプリケーション・サーバーに、データ記憶域をデータベースにパーティション化することによって、アプリケーション・ロジックとデータ記憶域を分離できます。
アプリケーション・サーバーおよびWebサーバーを使用して、データベースに格納されているデータにアクセスできます。
ユーザーは、操作が簡単で使い慣れたブラウザ・インタフェースを使用できます。
組織では、多数のシック・クライアントを多数のシン・クライアントと1つのアプリケーション・サーバーに置き換えることによって、コンピューティング・コストを低く抑えることもできます。
さらに、Oracle Databaseのプロキシ認証には、次のセキュリティ上のメリットがあります。
中間層がかわりに接続できるユーザー、および中間層がユーザーに対して想定できるロールを制御することによって制限付きトラスト・モデルが実現します。
OCI、JDBC/OCIまたはJDBCシン・ドライバでユーザー・セッションをサポートし、クライアント再認証のためのオーバーヘッドを排除することによってスケーラビリティが得られます。
実際のユーザーの識別情報をデータベースに到達するまで保持し、実際のユーザーのかわりに行われるアクションの監査を可能にすることによって、アカウンタビリティが得られます。
ユーザーがデータベースに認識されている環境と、ユーザーが単なるアプリケーション・ユーザーでデータベースには認識されていない環境の両方をサポートすることによって柔軟性が得られます。
注意:
Oracle Databaseはこのプロキシ認証機能を3つの層のみでサポートしています。複数の中間層を横断してのサポートはありません。
プロキシ・ユーザー・アカウントを作成するためには、ユーザーには特別な権限が必要です。
これらの権限は次のとおりです。
プロキシ・ユーザー・アカウントとして使用されるデータベース・ユーザー・アカウントを作成するためのCREATE USER
システム権限
Oracle Database Vaultが有効な場合にプロキシ・ユーザー・アカウントを作成するためのDV_ACCTMGR
ロール
CREATE SESSION
システム権限をプロキシ・ユーザー・アカウントに付与できること
既存のユーザー・アカウントがプロキシ・アカウントを介してデータベースに接続できるようにするためのALTER USER
システム権限
プロキシ・ユーザー・アカウントを作成する際の特別なガイドラインがあります。
セキュリティを高めて最小限の権限の原則を守るために、プロキシ・ユーザー・アカウントにCREATE SESSION
権限のみを付与します。このユーザーに他の一切の権限を付与しないでください。プロキシ・ユーザー・アカウントは、他のユーザーがプロキシ・アカウントを使用して接続できるようにする場合にのみ使用されます。接続中に実施されるすべての権限は、プロキシ・アカウントではなく、接続しているユーザーに属する必要があります。
すべてのパスワードと同様、プロキシ・ユーザーに作成するパスワードも強力であり容易に推測されないものにしてください。複数のユーザーがプロキシ・ユーザーとして接続することになるため、このパスワードを強力にすることが特に重要であることを忘れないでください。強力なパスワードの作成に関するガイドラインは、「パスワードの保護に関するガイドライン」を参照してください。
Oracle厳密認証ネットワーク接続機能を使用してネットワーク傍受を防ぐことを検討してください。
接続ユーザーが持っている制御の量をさらに微調整する場合は、接続ユーザーがプロキシ・アカウントを介して接続しているときに使用するロールを制限することを検討してください。ALTER USER
文のWITH ROLE
句を使用すると、指定されたロールまたは指定されたロール以外のロールを使用して接続するユーザー、あるいはロールをまったく使用せずに接続するユーザーを構成できます。プロキシ・ユーザーは、WITH ROLE
句に含まれているロールのみアクティブにできることに注意してください。プロキシ・ユーザー・セッションには、クライアント(つまり現在の)ユーザーに直接付与されたすべての権限が付与されます。
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パスワードの期限切れは、プロキシを介して認証されたアカウントに適用されません。パスワードを期限切れにするかわりに、アカウントをロックしてください。
関連項目:
エンタープライズ・ユーザー環境におけるプロキシ・ユーザーの管理に関する詳細は、『Oracle Databaseエンタープライズ・ユーザー・セキュリティ管理者ガイド』を参照してください。
ユーザーのかわりに中間層が行う監査操作の詳細は、「複数層環境におけるSQL文および権限の監査」を参照してください。
CREATE USER
およびALTER USER
文を使用してプロキシ・ユーザーを作成し、このプロキシ・ユーザーを介したユーザーの接続を認可できます。
これらの手順が完了した後で、ユーザーpreston
は、次のようにappuser
プロキシ・ユーザーを使用して接続できます。
CONNECT appuser[preston]
Enter password: appuser_password
関連項目:
CREATE USER
文に関する詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
ALTER USER
文に関する詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
不正なユーザーが取得するプロキシ認証で使用されるパスワードが懸念される場合、安全性の高い外部パスワード・ストアを使用します。
これを実行するには、ウォレットにパスワード資格証明を格納するためにプロキシ認証とともに安全性の高い外部パスワード・ストアを使用します。
プロキシ認証と安全性の高い外部パスワード・ストアを使用したOracle Databaseへの接続は、バッチ・ファイルを実行するなどの状況に理想的です。プロキシ・ユーザーがデータベースに接続し、安全性の高い外部パスワードを使用して認証を行うと、不正なユーザーが取得しようとしてもパスワードは公開されません。
安全性の高い外部パスワード・ストアとプロキシ認証を使用する手順は、次のとおりです。
その後、ユーザーはパスワードを指定せずにプロキシを使用して接続できます。例:
sqlplus [preston]/@db_alias
安全性の高い外部パスワード・ストアを使用すると、ユーザーはログイン時にユーザー名とパスワードを入力する必要がありません。指定する必要があるのは、tnsnames.ora
ファイルのSERVICE_NAME
値(つまり、db_alias
)のみです。
エンタープライズ・ユーザーまたはデータベース・ユーザー用のOracle Call Interface、JDBC/OCIまたはシン・ドライバを使用できます。
これらのツールにより、中間層で単一データベース接続内の複数のユーザー・セッションを設定できます。それぞれ接続されたユーザーを一意に識別します(接続プーリング)
これらのセッションにより、中間層からデータベースまで別個のネットワーク接続を作成することによるネットワーク・オーバーヘッドが削減されます。
クライアントから中間層を介してデータベースに対して認証する場合の完全な認証順序は次のようになります。
クライアントは、中間層が受け入れる任意の認証形式を使用して、中間層に対する認証を行います。たとえば、クライアントは、ユーザー名とパスワード、またはSSLによるX.509証明書を使用して、中間層に対する認証を実行できます。
中間層は、データベースが受け入れる任意の認証形式を使用して、中間層自体をデータベースに対して認証します。認証形式には、パスワード、またはKerberosチケットやX.509証明書(SSL)などのOracle Databaseがサポートしている認証メカニズムがあります。
次に、中間層はOCI、JDBC/OCIまたはシン・ドライバを使用して、ユーザーに対して1つ以上のセッションを作成します。
ユーザーがデータベース・ユーザーの場合、セッションには少なくともデータベース・ユーザー名が含まれている必要があります。データベースで必要な場合は、このセッションにパスワードを含めることができます(データベースでは、このパスワードをデータベース内のパスワード・ストアに対して検証します)。また、ユーザーに対するデータベース・ロールのリストを含めることもできます。
ユーザーがエンタープライズ・ユーザーの場合、セッションはユーザーの認証方法に応じて異なる情報を提供します。
例1: ユーザーがSSLを介して中間層に認証された場合、中間層は、そのユーザーのX.509証明書またはセッション内の証明書自体からDNを提供できます。データベースは、DNを使用してOracle Internet Directoryでユーザーを検索します。
例2: ユーザーがパスワード認証方式のエンタープライズ・ユーザーの場合、中間層は、少なくともユーザーのグローバルな一意の名前を提供する必要があります。データベースは、この名前を使用してOracle Internet Directoryでユーザーを検索します。セッションがユーザーのパスワードも提供する場合、データベースでは、このパスワードをOracle Internet Directoryに対して検証します。ユーザー・ロールは、セッションが確立した後でOracle Internet Directoryから自動的に取得されます。
中間層は、必要に応じてクライアントに対するデータベース・ロールのリストを提供する場合があります。クライアントのかわりにロールを使用する権限がプロキシにある場合は、これらのロールが使用可能になります。
データベースは、ユーザーのかわりにセッションを作成する権限が中間層にあるかどうかを検証します。
アプリケーション・サーバーがクライアントのかわりにプロキシ認証を実行することを管理者によって許可されていない場合、またはアプリケーション・サーバーが指定されたロールをアクティブにすることを許可されていない場合、OCISessionBegin
コールは失敗します。
「最低限の権限」とは、ユーザーの権限は各自の職務を行うのに必要な最小限の権限までにする必要があるという原則です。
これを中間層アプリケーションに当てはめると、中間層は必要以上の権限を持つ必要はないということを意味します。
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
から削除されています。
ロールの詳細は、「権限とロール認可の構成」を参照してください。
ユーザーとして接続する中間層サーバーを認可できます。
ユーザーとして接続する中間層サーバーを認可するには、ALTER USER
文を使用します。
次の文は、中間層サーバーappserve
がユーザーbill
として接続するのを認可します。WITH ROLE
句を使用して、appserve
がbill
に関連付けられた、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;
他の方式で認証されたユーザーのプロキシとして機能するための中間層を認可できます。
現在サポートされている認証方式は、PASSWORD
のみです。
ALTER USER ... GRANT CONNECT THROUGH
文の AUTHENTICATION REQURED
句を使用して、中間層がプロキシ化するユーザーを認可するが、認証はしません。
次に例を示します。
ALTER USER mary GRANT CONNECT THROUGH midtier AUTHENTICATION REQUIRED;
この文の中間層サーバーmidtier
は、mary
としての接続を認可されており、midtier
は、認証のためにユーザー・パスワードをデータベース・サーバーにも渡す必要があります。
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
に変換されます。
パスワード・ベースのプロキシ認証を使用すると、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. */
プロキシ認証の中間層の応答方法は、ユーザーの認証方法(エンタープライズ・ユーザーまたはパスワード認証ユーザーのいずれか)によって異なります。
中間層がエンタープライズ・ユーザーであるクライアントとしてデータベースに接続している場合は、識別名または識別名を含む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では、最初にユーザー名をデータベースに対してチェックします。ユーザーが見つからなかった場合、データベースはディレクトリ内のユーザー名をチェックします。このユーザー名はグローバルに一意である必要があります。
クライアント識別子を使用して、中間層システムでユーザー識別情報を保持できます。また、グローバル・アプリケーション・コンテキストとは独立してこれらを使用することもできます。
内容は次のとおりです。
Oracle Databaseでは、アプリケーション・ユーザーに対して、組込みアプリケーション・コンテキスト・ネームスペースUSERENVのCLIENT_IDENTIFIER
属性を提供します。
これらのアプリケーション・ユーザーは、アプリケーションには認識されますが、データベースには認識されません。CLIENT_IDENTIFIER
属性は、アプリケーションで識別またはアクセス制御に使用する任意の値を取得し、その値をデータベースに渡すことができます。CLIENT_IDENTIFIER
属性は、OCI、JDBC/OCIまたはシン・ドライバでサポートされています。
多くのアプリケーションがセッション・プーリングを使用して、複数のアプリケーション・ユーザーが再利用する複数のセッションを設定します。
ユーザーは、単一識別情報を使用してデータベースにログイン後、すべてのユーザー接続を維持する中間層アプリケーションに対して認証します。このモデルでは、アプリケーション・ユーザーはアプリケーションの中間層に対して認証されているがデータベースには認識されていないユーザーです。ここでは、これらのタイプのアプリケーションのアプリケーション・ユーザー・プロキシのように機能するCLIENT_IDENTIFIER
属性を使用できます。
このモデルでは、中間層はセッション確立時にクライアント識別子をデータベースに渡します。クライアント識別子は、中間層に接続しているクライアント表す任意のもの(たとえばCookieやIPアドレスなど)です。アプリケーション・ユーザーを表しているクライアント識別子はユーザー・セッション情報の中にあり、(USERENV
ネーミング・コンテキストを使用して)アプリケーション・コンテキストによりアクセスすることもできます。このようにして、アプリケーションはセッションを設定して再利用できると同時に、セッション内でアプリケーション・ユーザーを追跡できます。アプリケーションはクライアント識別子をリセットできるため、異なるユーザーでセッションを再利用し、パフォーマンスが向上します。
組込みアプリケーション・コンテキスト・ネームスペース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
を使用して適切なアプリケーション・コンテキストにアクセスし、データ・アクセスを制限できます。これには、セッションを再利用できるということと、セッションごとにアプリケーション・コンテキストを個別に初期化する必要がなく、一度設定したグローバル・アプリケーション・コンテキストにアクセスできるというパフォーマンス上のメリットがあります。
関連項目:
グローバル・アプリケーション・コンテキストの実装方法は、「グローバル・アプリケーション・コンテキスト」を参照してください
CLIENT_IDENTIFIER
属性は、ユーザーがデータベースに認識されていないアプリケーションで特に役立ちます。
このような場合、アプリケーションは通常、単一のデータベース・ユーザーとして接続し、すべてのアクションがそのユーザーで実行されます。
すべてのユーザー・セッションが同じユーザーとして作成されるため、このセキュリティ・モデルでは、ユーザーごとにデータを分離することが困難になります。これらのアプリケーションでは、CLIENT_IDENTIFIER
属性を使用すると、実際のアプリケーション・ユーザーの識別情報をデータベースに保持できます。
この方法によると、CLIENT_IDENTIFIER
属性の値を変更することで、複数のユーザーがセッションを再利用できます(この属性は、実際のアプリケーション・ユーザーの名前を取得します)。結果として、ユーザーごとに個別のセッションと属性を設定するためのオーバーヘッドが回避され、アプリケーションによるセッションの再利用が可能になります。CLIENT_IDENTIFIER
属性の値が変更されると、その変更は次のOCIコール、JDBC/OCIコールまたはシン・ドライバ・コールに伝達されるため、パフォーマンスが向上します。
たとえば、ユーザーDanielはWeb Expenseアプリケーションに接続します。Danielはデータベース・ユーザーではなく、一般的なWeb Expenseアプリケーション・ユーザーです。アプリケーションは組込みアプリケーション・コンテキスト・ネームスペースにアクセスして、DANIEL
をCLIENT_IDENTIFIER
属性値として設定します。DanielはWeb Expenseフォームを記入し終わるとアプリケーションを終了します。その後に、AjitがWeb Expenseアプリケーションに接続します。Ajitのために新しいセッションを設定するかわりに、アプリケーションはCLIENT_IDENTIFIER
をAJIT
に変更することにより、現在Danielに存在しているセッションを再利用します。これによりデータベースに新しい接続を設定するオーバーヘッドと、グローバル・アプリケーション・コンテキストを設定するオーバーヘッドを回避できます。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");
関連項目:
OCI_ATTR_CLIENT_IDENTIFIER
ユーザー・セッション・ハンドル属性の中間層アプリケーションでの使用方法は、『Oracle Call Interfaceプログラマーズ・ガイド』を参照してください。
JDBCおよびDMSメトリックを使用してクライアント接続を構成する方法の詳細は、『Oracle Database JDBC開発者ガイド』を参照してください
setClientInfo
メソッドの詳細は、『Oracle Database JDBC開発者ガイド』を参照してください
DBMS_SESSION
PL/SQLパッケージは、中間層とデータベース自体の両方でクライアント識別子を管理します。
DBMS_SESSION
パッケージを使用して、中間層でCLIENT_IDENTIFIER
の値を設定および消去するには、SET_IDENTIFIER
プロシージャとCLEAR_IDENTIFIER
プロシージャを使用します。
中間層では、SET_IDENTIFIER
を使用してデータベース・セッションを特定のユーザーまたはグループに対応付けます。この結果、CLIENT_IDENTIFIER
はセッションの属性になるため、セッション情報で確認できます。
DBMS_SESSION.SET_IDENTIFIER
プロシージャを使用する場合、次の点に注意してください。
DBMS_SESSION.SET_IDENTIFIER
のclient_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
ALTER SYSTEM
文では、システム全体でCLIENTID_OVERWRITE
イベントを有効化できます。
関連項目:
クライアント識別子をグローバル・アプリケーション・コンテキストで使用する方法は、「グローバル・アプリケーション・コンテキスト」を参照してください
DBMS_SESSION
パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください
ALTER SESSION
文では、現在のセッションのみに対してCLIENTID_OVERWRITE
イベントを有効化できます。
Oracle Databaseには、ユーザーのロールや使用しているプロファイルなど、ユーザー認証に関する情報を表示するデータ・ディクショナリ・ビューが用意されています。
表3-3に、データ・ディクショナリ・ビューのリストを示します。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
表3-3 ユーザー認証を示すデータ・ディクショナリ・ビュー
ビュー | 説明 |
---|---|
|
設定や制限など、プロファイルに関する情報を表示します。 |
|
データベース・ロールがデータベースにログインする際に使用する認証の種類を表示します。 |
|
その他のユーザー情報から、次の情報を表示します。
|
|
ユーザー・アカウント・パスワードがデフォルト・パスワードかどうかを表示します |
|
現在中間層経由での接続が認可されているユーザーを表示します |
|
既存のデータベース・リンク用のユーザー・アカウントを表示します( |
|
パスワード・ファイルに含まれている管理ユーザーの名前と付与されている管理権限を表示します。 |
|
|