| Oracle Databaseセキュリティ・ガイド 11g リリース1（11.1） E05730-05 |
|
 戻る |
 次へ |
この章の内容は、次のとおりです。
認証とは、データ、リソースまたはアプリケーションの使用を希望するエンティティ（ユーザーやデバイスなど）の識別を検証することです。識別を検証することで、その後の対話に関する信頼関係が確立されます。認証によって、アクセスとアクションを特定の識別にリンクでき、アカウンタビリティも有効化されます。認証後は、認可プロセスでそのエンティティが実行できるアクセスとアクションのレベルを許可または制限できます。
Oracle Databaseのデータベース・ユーザーと非データベース・ユーザーの両方を認証できます。簡潔性を考慮して、すべてのデータベース・ユーザーに同じ認証方式を使用するのが一般的ですが、Oracle Databaseでは1つのデータベース・インスタンスで一部またはすべての方法を使用できます。Oracle Databaseでは、データベース管理者が特別なデータベース操作を実行するため、そのための特別な認証プロシージャが必要です。また、Oracle Databaseでは、ネットワーク認証のセキュリティを確保するために送信時にパスワードの暗号化も実行されます。
認証後は、認可プロセスでそのエンティティが実行できるアクセスとアクションのレベルを許可または制限できます。認可については、第4章「権限とロール認可の構成」を参照してください。
この項の内容は、次のとおりです。
パスワードの保護に関するガイドラインは、「パスワードの保護に関するガイドライン」も参照してください。パスワードを暗号化してユーザーを認証するようにOracle XML DBを構成するとき、他のデータは暗号化する必要がない場合（例: イントラネットの電子メール）の詳細は、『Oracle XML DB開発者ガイド』を参照してください。
Oracle Databaseでは、ユーザーのパスワードを保護するように設計された一連の組込みパスワード保護が提供されています。提供されるパスワード保護は、次のとおりです。
パスワード暗号化。 Oracle Databaseでは、Advanced Encryption Standard（AES）を使用して、ネットワーク（クライアントとサーバー間、双方のサーバー間）接続中にパスワードを自動的かつ透過的に暗号化し、その後ネットワーク経由で送信します。暗号化の詳細は、第8章「データ暗号化APIを使用したアプリケーションの開発」を参照してください。透過的なデータ暗号化については、『Oracle Database Advanced Security管理者ガイド』を参照してください。
パスワードの複雑度のチェック。Oracle Databaseのデフォルト・インストールでは、パスワードを推定してシステムに入ろうとする侵入者に対して、新規または変更後のパスワードが十分に複雑であることをチェックします。さらに、ユーザーのパスワードの複雑度はカスタマイズできます。詳細は、「パスワードの複雑度検証の規定」を参照してください。
パスワード突破の防止。 ユーザーが誤ったパスワードを使用してOracle Databaseへのログインを複数回試行した場合、Oracle Databaseでは4回目以降のログインが遅延します。この保護は、異なるIPアドレスまたは複数のクライアント接続からのログインに適用されます。最初の3回のログイン試行では遅延はありません。4回目以降は、ユーザーが別のパスワードを使用してログインを試行するまで、次第に遅延時間が長くなり、最大10秒まで遅延します。ユーザーが正しいパスワードを入力すると、遅延なしで正常にログインできます。
この機能によって、侵入者がログインを試みる際に入力するパスワードの数が大幅に減少します。この機能は、パスワード・チェックに対する繰返しの攻撃を防ぐために設計されています。
パスワードでの大/小文字の区別の規定。パスワードは大/小文字が区別されます。たとえば、パスワードがhPP5620qrの場合、hpp5620QRまたはhPp5620Qrと入力すると失敗します。以前のリリースでは、パスワードは大/小文字が区別されませんでした。パスワードでの大/小文字の区別、およびパスワード・ファイルやデータベース・リンクへの影響については、「パスワードでの大/小文字の区別の有効化または無効化」を参照してください。
Secure Hash Algorithm（SHA）の暗号化ハッシュ関数SHA-1を使用したパスワードのハッシュ化。Oracle Databaseでは、SHA-1検証を使用して、ユーザー・パスワードを認証し、ユーザーのセッションを確立します。さらに、大/小文字の区別を規定し、パスワードを160ビットに制限します。SHA-1検証を使用する利点は、Oracle Databaseの顧客によって一般的に使用され、ネットワークをアップグレードしなくても適切なセキュリティが得られることです。また、適度に強力なパスワード・ハッシュ・アルゴリズムで保護された強力なパスワードの使用を規定するコンプライアンス規制にも準拠しています。詳細は、「パスワードのセキュリティへの脅威からのSHA-1ハッシュ・アルゴリズムによる保護」を参照してください。
最低要件として、パスワードは30文字以内にする必要があります。ただし、より高いセキュリティを確保するには、「パスワードの保護に関するガイドライン」で説明する追加ガイドラインに従ってください。
ユーザーのパスワードを作成するには、CREATE USERまたはALTER USER PL/SQL文を使用します。IDENTIFIED BY句を受け入れるPL/SQL文でもパスワードを作成できます。例3-1では、IDENTIFIED BY句でパスワードを作成するPL/SQL文をいくつか示しています。
例3-1 パスワード作成のPL/SQL文
CREATE USER psmith IDENTIFIED BY password; GRANT CREATE SESSION TO psmith IDENTIFIED BY password; CREATE DATABASE USER psmith IDENTIFIED BY password; CREATE DATABASE LINK AUTHENTICATED BY psmith IDENTIFIED BY password;
|
関連項目:
|
この項の内容は、次のとおりです。
パスワードに依存しているデータベース・セキュリティ・システムでは、パスワードの機密を常に保つ必要があります。パスワードは盗難、偽造および悪用などの被害を受けやすいため、Oracle Databaseではパスワード管理ポリシーが使用されています。データベース管理者およびセキュリティ管理者がユーザー・プロファイルを介してパスワード管理ポリシーを制御することで、データベース・セキュリティの管理を強化できます。
ユーザー・プロファイルを作成するには、CREATE PROFILE文を使用します。プロファイルは、CREATE USERまたはALTER USER文を使用してユーザーに割り当てます。ここでは、データベース・ユーザーの作成と変更の詳細は説明しません。 この項で取り上げるのは、CREATE PROFILE（またはALTER PROFILE）文で指定できるパスワード・パラメータです。
Oracle Database 11g リリース1（11.1）でデータベースを作成すると、デフォルト・アカウントの大部分は期限切れのパスワードでロックされます。以前のリリースのOracle Databaseからアップグレードした場合は、デフォルト・パスワードが設定されているユーザー・アカウントが存在していることがあります。それらは、データベースの作成時に作成されたデフォルト・アカウント（HR、OE、SCOTTアカウントなど）です。
セキュリティを強化するために、それらのアカウントのパスワードを変更してください。周知されているデフォルト・パスワードを使用すると、データベースが侵入者から攻撃を受けやすくなります。デフォルト・パスワードを使用するアカウント（ロック済とロック解除済の両方）を検索するには、SYSDBA権限を使用してSQL*Plusにログインし、DBA_USERS_WITH_DEFPWDデータ・ディクショナリ・ビューを問い合せます。
次に、デフォルトのパスワードが設定されているアカウントの名前とステータスの両方を検索する例を示します。
CONNECT / AS SYSDBA
Enter password: password
Connected.
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
次に、DBA_USERS_WITH_DEFPWDビューにリストされたアカウントのパスワードを変更します。これらのアカウントに、旧リリースのOracle Databaseで指定されていた可能性のあるパスワードを割り当てないことをお薦めします。
ALTER USER SCOTT ACCOUNT UNLOCK IDENTIFIED BY password;
passwordを安全なパスワードに置き換えます。パスワードの最低要件については、「パスワードの最低要件」を参照してください。
プロファイルとは、データベース・リソースに関する制限を設定するパラメータの集合です。プロファイルをユーザーに割り当てた場合、そのユーザーはそれらの制限を超えることはできません。プロファイルを使用すると、ユーザーごとのセッション数、ロギングやトレースの機能など、データベース設定を構成できます。また、プロファイルによってユーザー・パスワードも制御できます。
表3-1に、デフォルト・プロファイルのパスワード固有のパラメータ設定を示します。
表3-1 デフォルト・プロファイルのパスワード固有の設定
| パラメータ | デフォルト設定 | 説明 |
|---|---|---|
|
|
ユーザーがログインを試行して失敗する最大回数。この回数を超えるとアカウントがロックされます。 注意:
|
|
|
|
パスワードが期限切れになる前に、ユーザーがパスワードを変更するための日数を設定します。 詳細は、「パスワード・エイジングおよび期限切れの制御」を参照してください。 |
|
|
|
ユーザーが現行のパスワードを使用できる日数を設定します。 詳細は、「パスワード・エイジングおよび期限切れの制御」を参照してください。 |
|
|
|
ログインを指定の回数だけ連続して失敗した後に、アカウントがロックされる日数を設定します。 詳細は、「ログイン失敗後のユーザー・アカウントの自動ロック」を参照してください。 |
|
|
|
現行のパスワードを再利用できるようになるまでに必要なパスワード変更の回数を設定します。 詳細は、「ユーザーによる古いパスワードの再利用の制御」を参照してください。 |
|
|
|
パスワードを再利用できない日数を設定します。 詳細は、「ユーザーによる古いパスワードの再利用の制御」を参照してください。 |
セキュリティを強化するために、必要に応じて、表3-1に示すデフォルト設定を使用してください。プロファイルのパスワード設定を作成または変更するには、次のいずれかの方法を使用します。
Database Configuration Assistant（DBCA）。 新規データベースの作成時または既存データベースの変更時に、「セキュリティ設定」ウィンドウを使用して、デフォルトのセキュリティ設定を使用可能または使用禁止にできます。表3-1のパスワード固有の設定は、デフォルト設定の一部です。デフォルトのセキュリティ設定には、「セキュリティに関連するSQL文および権限に対するデフォルト監査の使用」で説明する監査設定も含まれています。デフォルトのセキュリティ設定は使用可能にすることをお薦めします。
CREATE PROFILE文またはALTER PROFILE文。CREATE PROFILE文またはALTER PROFILE文を使用して、パスワード固有のパラメータを個別に作成または変更できます。次に例を示します。
ALTER PROFILE prof FAILED_LOGIN_ATTEMPTS 10 PASSWORD_LOCK_TIME 1;
CREATE PROFILE、ALTER PROFILE、およびこの項で説明したパスワード関連のパラメータの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
Oracle Databaseでは、ログイン試行に指定の回数だけ連続して失敗した後、ユーザーのアカウントをロックできます。指定した時間間隔の後で自動的にロックするか、またはロックを解除するにはデータベース管理者の介入を必要とするように、アカウントを構成できます。データベース管理者はアカウントを手動でロックすることもできるため、そのロックはデータベース管理者が明示的に解除する必要があります。
ログインの失敗が許容される回数は、CREATE PROFILE文を使用して指定します。また、アカウントがロックされる時間の長さも指定できます。
例3-2では、ユーザーjohndoeに対して許容されているログイン失敗の最大回数は10回（デフォルト）、アカウントがロックされる時間の長さは30日です。アカウントのロックは、30日が経過すると自動的に解除されます。
例3-2 CREATE PROFILE文を使用したアカウントのロック
CREATE PROFILE prof LIMIT FAILED_LOGIN_ATTEMPTS 10 PASSWORD_LOCK_TIME 30; ALTER USER johndoe PROFILE prof;
ユーザーがログインに失敗するたびに、Oracle Databaseでは次第に遅延時間が長くなります。
アカウントのロックを解除する時間間隔を指定しないと、PASSWORD_LOCK_TIMEはデフォルトのプロファイルに指定されている値になります。（推奨値は1日です）。PASSWORD_LOCK_TIMEをUNLIMITEDに指定した場合は、ALTER USER文を使用してアカウントのロックを明示的に解除する必要があります。たとえば、johndoeのPASSWORD_LOCK_TIMEをUNLIMITEDに指定した場合は、次の文を使用してjohndoeアカウントのロックを解除します。
ALTER USER johndoe ACCOUNT UNLOCK;
ユーザーが正常にアカウントにログインすると、Oracle Databaseでは、そのユーザーが失敗したログインの回数が0（ゼロ）にリセットされます（0でない場合）。
セキュリティ管理者が明示的にユーザー・アカウントをロックすることもできます。その場合、アカウントのロックは自動的には解除されません。セキュリティ管理者がアカウントのロックを解除する必要があります。CREATE USER文またはALTER USER文を使用して、ユーザー・アカウントを明示的にロックまたはロック解除します。たとえば、次の文はユーザー・アカウントsusanをロックします。
ALTER USER susan ACCOUNT LOCK;
指定した期間、または指定したパスワード変更回数を経過するまで、ユーザーが古いパスワードを再利用しないようにできます。これを行うには、CREATE PROFILE文またはALTER PROFILE文を使用してパスワードの再利用のルールを構成します。これらの文の構文の詳細は、『Oracle Database SQL言語リファレンス』を参照してください。
表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が使用されます。 |
パスワードの存続期間を指定できます。この期間をすぎるとパスワードは期限切れになり、アカウントへのログインが再度許可されるには、パスワードを変更する必要があります。さらに、猶予期間を設定できます。この期間中は、データベース・アカウントへのログインを試行するたびに、パスワードの変更を求める警告メッセージが発行されます。ユーザーがこの期間内にパスワードを変更しないと、Oracle Databaseではアカウントをロックします。それ以降、そのアカウントには、データベース管理者の介入がなければログインできなくなります。
また、パスワードの状態を手動で期限切れに設定することもできます。この場合は、ユーザーのアカウントの状態を期限切れに設定します。そのユーザーがデータベースにログインするには、自分で、またはデータベース管理者に依頼して、PASSWORD文またはALTER USER文を使用してパスワードを変更する必要があります。
パスワードの最長存続期間を指定するには、CREATE PROFILE文またはALTER PROFILE文を使用します。指定された時間が経過してパスワードの期限が切れた場合は、ユーザーまたはDBAがパスワードを変更する必要があります。
例3-3は、プロファイルを作成してユーザーjohndoeに割り当てる方法を示しています。PASSWORD_LIFE_TIME句によって、johndoeはパスワードの期限が切れるまで180日間同じパスワードを使用できることが指定されています。
例3-3 CREATE PROFILE文を使用したパスワード・エイジングと期限切れの設定
CREATE PROFILE prof LIMIT FAILED_LOGIN_ATTEMPTS 4 PASSWORD_LOCK_TIME 30 PASSWORD_LIFE_TIME 180; ALTER USER johndoe PROFILE prof;
パスワードの期限切れに猶予期間を指定することもできます。ユーザーは、パスワードの期限が切れた後、初めてデータベース・アカウントにログインしようとしたときに、猶予期間に入ります。猶予期間中は、ユーザーがアカウントにログインしようとするたびに警告メッセージが表示され、猶予期間が終わるまで表示され続けます。ユーザーは、猶予期間内にパスワードを変更する必要があります。猶予期間内にパスワードを変更しないと、その後ユーザーには、アカウントにアクセスしようとするたびに新しいパスワードの入力を求めるプロンプトが表示されます。新しいパスワードを入力しないかぎり、アカウントへのアクセスは拒否されます。
図3-1は、パスワードの存続期間と猶予期間の推移を示しています。
次の例では、johndoeに割り当てられたプロファイルに、猶予期間PASSWORD_GRACE_TIME = 3（推奨値）が指定されています。johndoeが90日経過後（90日目以降の任意の日。91日目、100日目なども指定可能）初めてデータベースにログインしようとすると、パスワードが3日以内に期限切れになることを示す警告メッセージが表示されます。3日経過してもパスワードを変更しない場合は、パスワードの期限が切れます。その後、このユーザーには、ログインしようとするたびにパスワードの変更を求めるプロンプトが表示され、パスワードを変更するまでログインできません。
CREATE PROFILE prof LIMIT FAILED_LOGIN_ATTEMPTS 4 PASSWORD_LOCK_TIME 30 PASSWORD_LIFE_TIME 90 PASSWORD_GRACE_TIME 3; ALTER USER johndoe PROFILE prof;
パスワードを明示的に期限切れにするには、CREATE USER文およびALTER USER文を使用します。次の文は、期限切れのパスワードを持つユーザーを作成します。この設定によって、ユーザーがデータベースにログインする前に、強制的にパスワードを変更させることができます。
CREATE USER jbrown
IDENTIFIED BY password
...
PASSWORD EXPIRE;
複雑度検証では、各パスワードが、パスワードを推定してシステムに入ろうとする侵入者に対して十分に保護できる複雑なものであることがチェックされます。このため、ユーザーはデータベース・ユーザー・アカウント用に強固で安全性の高いパスワードを作成するように要求されます。ユーザーのパスワードは、パスワードを推定してシステムに入ろうとする侵入者に対して、十分保護可能な複雑なものである必要があります。
Oracle Databaseによるパスワードの複雑度のチェック方法
Oracle Databaseでは、サンプルのパスワード検証関数がPL/SQLスクリプトUTLPWDMG.SQL（ORACLE_BASE/ORACLE_HOME/RDBMS/ADMINにあります）で提供されています。このスクリプトを使用可能にすると、ユーザーがパスワードを正しく作成または変更したかどうかがチェックされます。UTLPWDMG.SQLスクリプトには、2つのパスワード検証関数があります。1つは以前のリリースのOracle Database用で（コメント・アウトされています）、もう1つはOracle Databaseリリース11g用に更新された関数です。
UTLPWDMG.SQLスクリプトでは、ユーザーがパスワードを作成または変更したときに、次の要件をチェックします。
パスワードの長さが8文字以上30文字以内であること。
パスワードがユーザー名と同一でないこと。ユーザー名のスペルを逆にしたり、ユーザー名に数字を追加したパスワードでないこと。
サーバー名と同一であったり、サーバー名に数字1〜100を追加したパスワードでないこと。
単純なパスワードでないこと（例: welcome1、database1、account1、user1234、password1、oracle、oracle123、computer1、abcdefg1、change_on_install）。
パスワードに少なくとも数字が1つと英字が1つ含まれていること。
以前のパスワードとの違いが3文字以上あること。
パスワードの複雑度検証のカスタマイズ
独自のパスワード複雑度検証関数を作成するには、UTLPWDMG.SQLスクリプトのPASSWORD_VERIFY関数をバックアップしてカスタマイズします。サイトのパスワードの保護を強化するために、独自のパスワード複雑度検証関数を作成することをお薦めします。パスワードの作成に関するガイドラインは、「パスワードの保護に関するガイドライン」のガイドライン1も参照してください。
デフォルトでは、パスワードの複雑度検証は使用可能ではありません。パスワードの複雑度検証を使用可能にする手順は、次のとおりです。
管理権限でSQL*Plusにログインし、UTLPWDMG.SQLスクリプト（または、このスクリプトを変更したバージョン）を実行して、SYSスキーマにパスワード複雑度検証関数を作成します。
CONNECT SYS/AS SYSDBA
Enter password: password
Connected.
@$ORACLE_HOME/RDBMS/ADMIN/utlpwdmg.sql
デフォルト・プロファイルまたはユーザー・プロファイルで、PASSWORD_VERIFY_FUNCTION設定を、UTLPWDMG.SQLスクリプトのサンプルのパスワード複雑度関数か、カスタマイズした関数に設定します。次のいずれかの方法を使用します。
管理者権限でSQL*Plusにログインし、CREATE PROFILE文またはALTER PROFILE文を使用して関数を使用可能にします。たとえば、デフォルト・プロファイルを更新してverify_function_11G関数を使用するには、次のようにします。
ALTER PROFILE default PASSWORD_VERIFY_FUNCTION verify_function_11G;
Oracle Enterprise Managerで、「プロファイルの編集」ページに移動し、「複雑なパスワード検証」の下にある「複雑なパスワード検証のための関数」リストからパスワード複雑度関数の名前を選択します。
パスワード複雑度検証は、使用可能にするとすぐに有効になります。
ユーザー・アカウントを作成または変更するとき、パスワードはデフォルトで大/小文字の区別があります。パスワードでの大/小文字の区別の使用を制御するには、SEC_CASE_SENSITIVE_LOGON初期化パラメータを設定します。SEC_CASE_SENSITIVE_LOGONパラメータを設定できるのは、ALTER SYSTEM権限を持つユーザーのみです。このパラメータをTRUEに設定すると大/小文字の区別が有効になり、FALSEに設定すると大/小文字の区別が無効になります。
セキュリティを強化するために、パスワードで大/小文字の区別を有効にすることをお薦めします。ただし、アプリケーションで互換性の問題がある場合は、このパラメータを使用して、パスワードで大/小文字の区別を無効にできます。アプリケーションでの互換性の問題の例として、アプリケーションのパスワードが大/小文字の区別なしでハードコードされている場合、または、データベース・セッションを起動するために資格証明を送信するときに複数のアプリケーション・モジュール間で大/小文字の区別が一貫していない場合があります。
パスワードで大/小文字を区別できるようにする手順は、次のとおりです。
パスワード・ファイルを使用している場合は、IGNORECASEパラメータをNに設定して作成したことを確認します。
IGNORECASEパラメータによりSEC_CASE_SENSITIVE_LOGONパラメータが上書きされます。デフォルトでは、IGNORECASEはパスワードの大/小文字が区別されることを意味するYに設定されます。パスワード・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。
次のALTER SYSTEM文を入力します。
ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = TRUE
以前のリリースのOracle Databaseでは、パスワードは大/小文字が区別されませんでした。以前のリリース（たとえば、リリース10g）から現行のデータベース・リリースへユーザー・アカウントをインポートした場合、そのアカウントの大/小文字が区別されないパスワードは、ユーザーがパスワードを変更するまで大/小文字が区別されません。SYSDBAまたはSYSOPER権限が付与されているアカウントは、パスワード・ファイルにインポートされます（詳細は、「大/小文字の区別がパスワード・ファイルに与える影響」を参照）。以前のリリースからのユーザー・アカウントのパスワードを変更すると、そのパスワードは大/小文字が区別されます。
大/小文字の区別があるパスワード、または大/小文字の区別がないパスワードが設定されているユーザーを検索するには、DBA_USERSビューを問い合せます。このビューのPASSWORD_VERSIONS列に、パスワードが作成されたリリースが示されます。次に例を示します。
SELECT USERNAME,PASSWORD_VERSIONS FROM DBA_USERS; USERNAME PASSWORD_VERSIONS ------------------------------ ----------------- JONES 10G 11G ADAMS 10G 11G CLARK 10G 11G PRESTON 11G BLAKE 10G
アカウントjones、adamsおよびclarkのパスワードは、最初にリリース10gで作成され、その後、リリース11gで再設定されています。大/小文字の区別が有効になっている場合、これらのパスワードは、prestonのパスワードと同様に大/小文字が区別されます。しかし、blakeのアカウントはリリース10g基準のままであるため、大/小文字は区別されません。この場合は、セキュリティ強化のために、大/小文字が区別されるようにパスワードの再設定を要請します。
DBA_USERSビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
大/小文字の区別がパスワード・ファイルに与える影響
パスワード・ファイルの大/小文字の区別を有効または無効にするには、ORAPWDコマンドライン・ユーティリティでignorecase引数を使用します。ignorecaseのデフォルト値はn（no）で、大/小文字の区別が適用されます。
例3-4に、パスワード・ファイルで大/小文字の区別を有効にする方法を示します。
例3-4 パスワードでの大/小文字の区別の有効化
orapwd file=orapw entries=100 ignorecase=n
Enter password for SYS: password
これによってorapwdというパスワード・ファイルが作成されます。ignorecaseがn（いいえ）に設定されているため、passwordパラメータに入力されるパスワードは大/小文字が区別されます。 その後、このパスワードを使用して接続する場合、パスワードの作成時と大/小文字を同じにして入力すれば成功します。入力したパスワードが同じでも大/小文字が異なる場合、接続に失敗します。
ignorecaseをyに設定した場合、パスワード・ファイル内のパスワードは大/小文字が区別されません。これは、大/小文字を自由に使用してパスワードを入力できることを意味します。
以前のリリースからユーザー・アカウントをインポートし、そのアカウントがSYSDBAまたはSYSOPER権限を使用して作成されている場合、アカウントはパスワード・ファイルに格納されます。この時点で、アカウントのパスワードは大/小文字が区別されません。大/小文字の区別が有効な場合、次にユーザーがパスワードを変更すると、パスワードは大/小文字が区別されます。セキュリティを強化するために、そのユーザーに対してパスワードを変更するように要請してください。
パスワード・ファイルの詳細は、『Oracle Database管理者ガイド』を参照してください。
データベース・リンク接続用に作成されたアカウントに対する大/小文字の区別の影響
データベース・リンク接続を作成する場合は、接続用のユーザー名とパスワードを定義する必要があります。データベース・リンク接続を作成すると、パスワードは大/小文字が区別されます。ユーザーが接続用のパスワードをどのように入力するかは、データベース・リンクが作成されたリリースによって決まります。
ユーザーがリリース11gより前のデータベースからリリース11gのデータベースに接続するには、大/小文字の区別が有効な場合、データベース・リンクに対するパスワードをすべて大文字で再作成する必要があります。
パスワードをすべて大文字で再作成する理由は、Oracle Databaseがデータベース・リンクのパスワードを格納する方法と一致させるためです。パスワードが最初に小文字または大/小文字を使用して作成された場合でも、Oracle Databaseでは常にこのタイプのパスワードを大文字で格納します。大/小文字の区別が無効な場合、ユーザーはパスワード作成時の大/小文字を使用してパスワードを入力できます。
ユーザーがリリース11gのデータベースから別のリリース11gのデータベースに接続するには、大/小文字の区別が有効な場合、パスワードが作成されたとおりの大/小文字を使用してパスワードを入力する必要があります。
ユーザーがリリース11gのデータベースからリリース11gより前のデータベースに接続する場合、パスワードは大/小文字が区別されないため、大/小文字に関係なくパスワードを入力できます。
つまり、ユーザーがデータベース・リンクからリリース11gのデータベースに接続する場合は、常に正しい大/小文字でパスワードを入力する必要があります。
既存のデータベース・リンクのユーザー・アカウントを検索するには、V$DBLINKビューを実行します。次に例を示します。
SELECT DB_LINK, OWNER_ID FROM V$DBLINK;
SHA-1暗号化ハッシュ・アルゴリズムは、パスワードでの大/小文字、特殊文字およびマルチバイト・キャラクタの混在をサポートすることで、パスワード・ベースのセキュリティに対する脅威からデータを保護します。さらに、SHA-1ハッシュ・アルゴリズムにより、ハッシュ時にパスワードにsaltが追加され、さらなる保護が提供されます。これにより、ユーザーはさらに複雑なパスワードを作成できるため、侵入者がこれらのパスワードにアクセスするのがさらに困難になります。
多くのパスワード・クラッキング・ツールは、Oracle Databaseデータ・ディクショナリへのアクセスに依存します。ツールは最初に管理者アカウントを使用するか、バックアップ・テープやディスク・ドライブのようにデータベース・ファイルを含んだメディアに格納されているハッシュ値への直接アクセスを取得して、パスワードのハッシュ値を取得する必要があります。（このため、データベース・ファイルが格納されたバックアップ・メディアを暗号化すると有益です。）その後、クラッキング・ツールはクリア・テキスト・パスワードの組合せを使用して新しいハッシュを作成し、新しいハッシュを既存のハッシュと照合して既存のパスワードを取得します。
リリース11以降では、Oracle Databaseを排他モードで実行するように構成することもできます。排他モードを使用可能にすると、Oracle Databaseでは新しいSHA-1ハッシュ・アルゴリズムが排他的に使用されます。Oracle Database 11gの排他モードには、OCIベース・ドライバを使用するOracle Database 10g以降の製品との互換性があります。これには、SQL*Plus、ODBC、Oracle .NET、Oracle Formsおよび各種のサード・パーティOracle Databaseアダプタが含まれます。ただし、リリース11gの排他モードには、Oracle Database 11gより前のJDBCタイプ4（シン）バージョンまたはOracle Database 10gより前のOracle Database Clientインタフェース（OCI）ベース・ドライバとの互換性がないことに注意してください。排他モードを構成した後、古いパスワード・ハッシュ値をデータ・ディクショナリから削除することをお薦めします。
古いパスワードすべてを、大/小文字と特殊文字が混在するように変更します。
複雑であっても覚えやすいパスワードの作成技法と、パスワード作成に関する追加ガイドラインについては、「パスワードの保護に関するガイドライン」のガイドライン1を参照してください。
テスト・スクリプトまたはバッチ・ジョブ内のパスワードに、大/小文字と特殊文字が一貫して混在していることを確認します。
排他モードを使用可能にします。
sqlnet.oraパラメータ・ファイルのバックアップ・コピーを作成します。このファイルのデフォルトの場所は、UNIXオペレーティング・システムでは$ORACLE_HOME/network/adminディレクトリ、Microsoft Windowsオペレーティング・システムでは%ORACLE_HOME%\network\adminディレクトリです。
sqlnet.oraファイルに次の行が含まれていることを確認します。
sqlnet.allowed_logon_version=11
sqlnet.oraファイルを保存して終了します。
必要な場合は、リスナーを再起動します。コマンド・プロンプトから次のコマンドを入力します。
lsnrctl STOP listener_name lsnrctl START listener_name
listener_nameは、listener.oraファイルに定義されているリスナーの名前です。デフォルト・リスナーLISTENERを使用している場合、リスナーを識別する必要はありません。
この項の内容は、次のとおりです。
データベースに接続するためのパスワード資格証明は、クライアント側のOracleウォレットを使用して格納できます。Oracleウォレットは、認証および署名用資格証明を格納する安全性の高いソフトウェア・コンテナです。
このウォレットの使用方法により、データベースに接続する際にパスワード資格証明に依存する大規模なデプロイメントを簡素化できます。この機能が構成されている場合、アプリケーション・コード、バッチ・ジョブおよびスクリプトに埋込みユーザー名およびパスワードは必要ありません。パスワードが危険にさらされることがなくなるため、リスクが軽減します。また、ユーザー名またはパスワードが変更されるたびにアプリケーション・コードを変更する必要がなくなるため、パスワード管理ポリシーの適用が容易になります。
|
注意: ウォレットの外部パスワード・ストアは、公開鍵インフラストラクチャ（PKI）資格証明が格納されている領域とは別の場所にあります。そのため、ウォレットの外部パスワード・ストアの資格証明管理には、Oracle Wallet Managerを使用できません。かわりに、コマンドライン・ユーティリティ mkstoreを使用して資格証明を管理します。 |
通常、ユーザー（アプリケーション、バッチ・ジョブおよびスクリプトを含む）は、データベースへの接続には、データベース接続文字列を指定する標準の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ウォレットに格納されています。このウォレットの自動ログイン機能が使用状態になるため、システムにはウォレットを開くためのパスワードは不要です。ウォレットから、システムはデータベースにアクセスするための資格証明を、資格を証明するユーザーのために取得します。
クライアントがすでにWindowsネイティブ認証やSecure Sockets Layer（SSL）などの外部認証を使用するように構成されている場合、Oracle Databaseではその認証方式が使用されます。通常は、そのタイプの認証で使用されるものと同じ資格証明が、データベースへのログインにも使用されます。
データベース認証として、その認証方式を使用しないかまたは変更するクライアントには、sqlnet.oraのSQLNET.WALLET_OVERRIDEパラメータをTRUEに設定できます。SQLNET.WALLET_OVERRIDEのデフォルト値はFALSEで、今までと同様に認証資格証明の標準的な使用が許可されます。
安全性の高い外部パスワード・ストア機能をクライアントで使用する場合は、次の構成タスクを実行します。
コマンドラインで次の構文を使用して、クライアント上にウォレットを作成します。
mkstore -wrl wallet_location -create
次に例を示します。
mkstore -wrl c:\oracle\product\11.1.0\db_1\wallets -create
Enter password: password
wallet_locationは、ウォレットを作成して格納するディレクトリのパスです。このコマンドにより、指定した場所にOracleウォレットが作成され、自動ログイン機能が使用可能になります。この自動ログイン機能により、クライアントは、パスワードを指定しなくてもウォレットの内容にアクセスできます。自動ログイン・ウォレットの詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
mkstoreユーティリティの-createオプションを指定すると、パスワードの複雑度検証が使用されます。詳細は、「パスワードの複雑度検証の規定」を参照してください。
コマンドラインで次の構文を使用して、ウォレットにデータベース接続の資格証明を作成します。
mkstore -wrl wallet_location -createCredential db_connect_string username Enter passwword: password
次に例を示します。
mkstore -wrl c:\oracle\product\11.1.0\db_1\wallets -createCredential orcl system
Enter passwword: 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と同じにする必要があります。 |
クライアントの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)
)
)
クライアントの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-5では、手順3および手順4で説明したWALLET_LOCATIONおよびSQLNET.WALLET_OVERRIDEパラメータが指定されているサンプルsqlnet.oraファイルを示します。
この項では、mkstoreコマンドライン・ユーティリティを使用して、外部パスワード・ストアで資格証明を管理するために実行できる次の各タスクの概要を示します。
定期的に、クライアント・ウォレットの外部パスワード・ストアのすべての内容を表示する、または特定の資格証明を表示してチェックする必要のある場合があります。外部パスワード・ストアの内容をリスト表示することによって、ストアに資格証明を追加または削除するかどうかの判断に使用できる情報が提供されます。
外部パスワード・ストアの内容をリスト表示するには、コマンドラインで次のコマンドを入力します。
mkstore -wrl wallet_location -listCredential
次に例を示します。
mkstore -wrl c:\oracle\product\11.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\11.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 dbase_alias username
次に例を示します。
mkstore -wrl c:\oracle\product\11.1.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\11.1.0\db_1\wallets -deleteCredential orcl
次のように値を指定します。
wallet_locationは、ウォレットが格納されているディレクトリのパスです。
db_aliasは、tnsnames.oraファイルでデータベースを指定するために使用するTNS別名、またはOracle Databaseネットワーク上のデータベースを識別するために使用するサービス名です。
データベース管理者は、管理者以外のデータベース・ユーザーが実行できない特別な操作（データベースの停止や起動など）を実行します。Oracle Databaseには、SYSDBA権限またはSYSOPER権限のいずれかを持つデータベース管理者の認証を保護するために、次の方式が用意されています。
厳密認証を使用すると、複数のデータベースに対するSYSDBAおよびSYSOPERのアクセスを集中管理できます。データベース管理のこのような認証は、次の状況で使用を検討してください。
パスワード・ファイルの脆弱性が懸念される場合。
サイトで非常に強固なセキュリティが要求される場合。
アイデンティティ管理をデータベースから分離する必要がある場合。たとえば、Oracle Internet Directory（OID）などのディレクトリ・サーバーを使用すると、そのサーバーを個別にメンテナンス、保護および管理できます。
Oracle Internet Directoryサーバーを使用してSYSDBAおよびSYSOPERの接続を認可するには、使用している環境に応じて、次のいずれかの方式を使用します。
管理ユーザーのディレクトリ認証を構成する手順は、次のとおりです。
通常のユーザーを構成するのと同じ手順で、管理ユーザーを構成します。
Oracle Internet Directoryで、このユーザーが管理するデータベースに対して、SYSDBAまたはSYSOPER権限をユーザーに付与します。
SYSDBAまたはSYSOPERは信頼できるユーザーにのみ付与してください。この項の内容に関するガイドラインは、「ユーザー・アカウントと権限の保護に関するガイドライン」を参照してください。
LDAP_DIRECTORY_SYSAUTH初期化パラメータをYESに設定します。
ALTER SYSTEM SET LDAP_DIRECTORY_SYSAUTH = YES;
LDAP_DIRECTORY_SYSAUTHパラメータをYESに設定すると、SYSDBAおよびSYSOPERユーザーは、厳密認証方式を使用してデータベースへの認証を行うことができます。
LDAP_DIRECTORY_SYSAUTHの詳細は、『Oracle Databaseリファレンス』を参照してください。
LDAP_DIRECTORY_ACCESSパラメータをPASSWORDまたはSSLのいずれかに設定します。次に例を示します。
ALTER SYSTEM SET LDAP_DIRECTORY_ACCESS = PASSWORD;
LDAP_DIRECTORY_ACCESS初期化パラメータをNONEに設定しないでください。このパラメータをPASSWORDまたはSSLに設定すると、Oracle Internet DirectoryからSYSDBAまたはSYSOPER権限を使用してユーザーを認証できます。LDAP_DIRECTORY_ACCESSの詳細は、『Oracle Databaseリファレンス』を参照してください。
この結果、ユーザーは、SQL*PlusでCONNECT文にネット・サービス名を指定してログインできるようになります。たとえば、ネット・サービス名がorclの場合、SYSDBAとしてログインするには、次のように入力します。
CONNECT user@orcl AS SYSDBA
Enter password: password
リモート認証でパスワード・ファイルを使用するようにデータベースが構成されている場合、Oracle Databaseでは最初にパスワード・ファイルをチェックします。
管理ユーザーのKerberos認証を構成する手順は、次のとおりです。
通常のユーザーを構成するのと同じ手順で、管理ユーザーを構成します。
Kerberos認証用にOracle Internet Directoryを構成します。
Oracle Internet Directoryで、このユーザーが管理するデータベースに対して、SYSDBAまたはSYSOPER権限をユーザーに付与します。
SYSDBAまたはSYSOPERは信頼できるユーザーにのみ付与してください。この項の内容に関するガイドラインは、「ユーザー・アカウントと権限の保護に関するガイドライン」を参照してください。
LDAP_DIRECTORY_SYSAUTH初期化パラメータをYESに設定します。
ALTER SYSTEM SET LDAP_DIRECTORY_SYSAUTH = YES;
LDAP_DIRECTORY_SYSAUTHパラメータをYESに設定すると、SYSDBAおよびSYSOPERユーザーは、厳密認証方式を使用してデータベースへの認証を行うことができます。LDAP_DIRECTORY_SYSAUTHの詳細は、『Oracle Databaseリファレンス』を参照してください。
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リファレンス』を参照してください。
この結果、ユーザーは、SQL*PlusでCONNECT文にネット・サービス名を指定してログインできるようになります。たとえば、ネット・サービス名がorclの場合、SYSDBAとしてログインするには、次のように入力します。
CONNECT /@orcl AS SYSDBA
管理ユーザーのSecure Sockets Layer（SSL）認証を構成する手順は、次のとおりです。
SSLを使用するように、次の手順でクライアントを構成します。
クライアント・ウォレットおよびユーザー証明書を構成します。sqlnet.ora構成ファイルのウォレットの場所を更新します。
ウォレット・マネージャを使用して、クライアント・ウォレットおよびユーザー証明書を構成します。詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
サーバー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;
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
通常、データベース管理者のオペレーティング・システム認証には、オペレーティング・システムにグループを作成すること、そのグループにDBA権限を付与すること、および権限を付与する管理者の名前をグループに追加することが含まれます。（UNIXシステムでは、このグループはdbaグループです。）
|
注意: UNIXシステムでは、このようなグループはdbaグループと呼ばれます。 |
|
関連項目: データベース管理者のオペレーティング・システム認証の構成の詳細は、オペレーティング・システム固有のOracle Databaseマニュアルを参照してください。 |
Oracle Databaseでは、データベース固有のパスワード・ファイルを使用して、SYSDBAおよびSYSOPER権限を付与したデータベース・ユーザー名を追跡します。これらの権限によって、次のアクティビティが使用可能になります。
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に設定します。
パスワード・ファイル・ベースの認証が、デフォルトで使用可能です。つまり、データベースは、SYSDBAまたはSYSOPERシステム権限のあるユーザーの認証についてパスワード・ファイルを使用できます。パスワード・ファイル・ベースの認証は、ORAPWDユーティリティを使用してパスワード・ファイルを作成すると、アクティブになります。
$ORACLE_HOME/dbsディレクトリに対してEXECUTE権限および書込み権限を持つユーザーがORAPWDユーティリティを実行できます。
ただし、パスワード・ファイルの使用は、セキュリティ上のリスクを伴う可能性があることに注意してください。このため、「データベース管理者の厳密認証と集中管理」で説明した認証方式を使用することを検討してください。パスワードによるセキュリティのリスクの例は、次のとおりです。
侵入者がパスワード・ファイルを盗んだり攻撃する可能性があります。
多くのユーザーがデフォルト・パスワードを変更しない場合があります。
パスワードが簡単に推定される場合があります。
パスワードがディレクトリ内に存在すると、無防備になります。
短かすぎたり簡単に入力できるパスワードは、侵入者がパスワードの暗号化ハッシュを取得した場合に無防備になります。
|
注意: AS SYSDBAまたはAS SYSOPERが必要な接続では、これらの句を使用する必要があります。使用しない場合は接続に失敗します。Oracle DatabaseパラメータO7_DICTIONARY_ACCESSIBILITYは、機密性の高いデータ・ディクショナリへのアクセスを許可された管理者のみに制限するために、デフォルトではFALSEに設定されています。また、このパラメータによって、必要なAS SYSDBAまたはAS SYSOPERの構文が規定されます。 |
Oracle Databaseでは、データベース自体に格納されている情報を使用して、データベースに接続しようとするユーザーを認証できます。データベース認証を使用するようにOracle Databaseを構成するには、対応するパスワードを指定して各ユーザーを作成する必要があります。ユーザー名にはマルチバイトを使用できますが、各パスワードは、データベースでマルチバイト・キャラクタ・セットが使用されている場合でも、シングルバイト・キャラクタで構成する必要があります。ユーザーは、接続の確立時にそのユーザー名およびパスワードを入力する必要があります。Oracle Databaseでは、ユーザーのパスワードは暗号化された形式でデータ・ディクショナリに格納されます。
クライアントまたはデータベースで許可される認証プロトコルを識別するために、DBAはサーバーのsqlnet.oraファイルにSQLNET.ALLOWED_LOGON_VERSIONパラメータを明示的に設定できます。各接続がテストされ、クライアントまたはサーバーがパートナが指定する最低バージョンを満たしていない場合は、認証に失敗してORA-28040エラーが発生します。このパラメータの値には、11、10、9または8を指定できます。デフォルト値は8です。これらの値はデータベース・サーバーのバージョンを表します。保護レベルを最大にするには、値11をお薦めします。ただし、SQLNET.ALLOWED_LOGON_VERSIONを11に設定した場合、Oracle Databaseリリース11.1以前のクライアント・アプリケーションまたはJDBCシン・クライアントは、パスワードベースの認証を使用してOracleデータベースへの認証を行うことができない点に注意してください。
データベース認証使用時のセキュリティを高めるために、アカウントのロック、パスワード・エイジングと期限切れ、パスワード履歴およびパスワードの複雑度検証も含めたパスワード管理の使用をお薦めします。パスワード管理の詳細は、「パスワード管理ポリシーの使用」を参照してください。
ユーザー・アカウントとすべての認証がデータベースによって制御されます。データベースの外部のものには依存しません。
Oracle Databaseには、データベース認証使用時のセキュリティを高めるために、強力なパスワード管理機能が組み込まれています。
小規模なユーザー・コミュニティがある場合の管理が容易になります。
一部のオペレーティング・システムでは、オペレーティング・システムが維持している情報を、ユーザーの認証用に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）によって認証されます。
ネットワークでのユーザーの認証は、サード・パーティ・サービスでSecure Sockets Layerを使用して行うことができます。
Secure Sockets Layer（SSL）プロトコルは、アプリケーション・レイヤー・プロトコルです。SSLは、Oracle Internet Directoryでのグローバル・ユーザー管理とは関係なく、データベースに対するユーザー認証に使用できます。つまり、ユーザーは、ディレクトリ・サーバーを指定しなくても、SSLを使用してデータベースへの認証を行うことができます。
SSLを構成する手順は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
ネットワークでOracle Databaseユーザーを認証する場合は、サード・パーティのネットワーク認証サービスを使用する必要があります。代表的な例には、Kerberos、PKI（公開鍵インフラストラクチャ）、RADIUS（Remote Authentication Dial-In User Service）、ディレクトリベース・サービスなどがあります。次の各項で詳細を説明します。
ネットワーク認証サービスを使用できる場合、Oracle Databaseはこれらのネットワーク・サービスによる認証を受け入れることができます。ネットワーク認証サービスを使用する場合は、ネットワーク・ロールとデータベース・リンクについて特別な考慮事項があります。
|
注意: Oracle Databaseでネットワーク認証サービスを使用するには、Oracle Database Advanced Securityオプションを備えたOracle Database Enterprise Editionが必要です。 |
Kerberosを使用した認証
Kerberosは、共有シークレットに依存する、信頼できるサード・パーティ認証システムです。この認証では、サード・パーティの安全性が前提で、Single Sign-on機能、パスワードの集中保管およびデータベース・リンク認証によってPCのセキュリティが向上します。これは、Kerberos認証サーバー、またはKerberosベースの市販の認証サーバーであるCybersafe Active Trustを介して実行されます。
RADIUSを使用した認証
Oracle Databaseは、Remote Authentication Dial-In User Service（RADIUS）を介したユーザーのリモート認証をサポートしています。RADIUSは、ユーザー認証、許可およびアカウント処理に使用される標準軽量プロトコルです。RADIUSの構成方法は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
ディレクトリベース・サービスを使用した認証
中核となるディレクトリを使用すると、認証とその管理が効率的になります。次のようなディレクトリベース・サービスがあります。
Lightweight Directory Access Protocol（LDAP）を使用するOracle Internet Directoryにより、中央リポジトリを使用してユーザー（エンタープライズ・ユーザーと呼ばれます）に関する情報を格納および管理できます。エンタープライズ・ユーザーのアカウントは、分散環境で作成されます。データベース・ユーザーの場合は、アクセスするデータベースごとにパスワードとともに作成する必要がありますが、エンタープライズ・ユーザーの情報にはOracle Internet Directoryで集中的にアクセスできます。このディレクトリは、Microsoft Active DirectoryおよびSunOneと統合することもできます。
Oracle Internet Directoryの詳細は、『Oracle Internet Directory管理者ガイド』を参照してください。
Oracle Enterprise Security Managerにより、Oracle Internet Directoryからロールを取得して格納できます。集中的な権限管理を提供することで、管理を容易にし、セキュリティ・レベルを高めます。Oracle Enterprise Security Managerの詳細は、『Oracle Enterprise Manager構成ガイド』を参照してください。
公開鍵インフラストラクチャを使用した認証
公開鍵インフラストラクチャ（PKI）に基づく認証システムは、ユーザー・クライアントにデジタル証明書を発行します。ユーザー・クライアントはそれを使用して、認証サーバーを直接関与させずに、社内のサーバーを直接認証します。Oracle Databaseは、公開鍵と証明書を使用するためのPKIを提供します。PKIのコンポーネントは、次のとおりです。
SSLによる認証および保護セッション鍵管理。 詳細は、「Secure Sockets Layerを使用した認証」を参照してください。
信頼できる証明書。 識別情報を検証するときに、ユーザー証明書の署名者として信頼するサード・パーティ・エンティティを識別するために使用します。ユーザーの証明書が確認されるとき、署名者は、検証システムに格納されている認証局のトラスト・ポイントまたは信頼できる証明連鎖を使用してチェックされます。この連鎖内に複数レベルの信頼できる証明書がある場合は、下位レベルの証明書を信頼するため、それより上のレベルの証明書をすべて再検証する必要はありません。信頼できる証明書の詳細は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
OracleAS Certificate Authority。 Oracle Identity Managementインフラストラクチャのコンポーネントであり、統合されたソリューションをX.509v3証明書のプロビジョニング用に提供します。この証明書は、認証、SSL、S/MIMEなどPKIベースの操作に対する証明書が必要な個人、アプリケーションおよびサーバーで使用されます。OracleAS Certificate Authorityの詳細は、『Oracle Application Server Certificate Authority管理者ガイド』を参照してください。
Oracle Wallet Manager。 Oracleウォレットは、ユーザーの秘密鍵、ユーザー証明書および一連のトラスト・ポイント（信頼できる認証局）を含むデータ構造です。Oracleウォレットの管理方法は、『Oracle Database Advanced Security管理者ガイド』を参照してください。
Oracle Wallet Managerを使用してOracleウォレットを管理できます。Oracle Wallet Managerは、Oracleウォレット内のセキュリティ資格証明の管理および編集に使用される、スタンドアロンのJavaアプリケーションです。次の操作を実行できます。
公開鍵と秘密鍵のペアを生成し、認証局に提出する証明書要求を作成して、ウォレットを作成します。
エンティティの証明書をインストールします。
Oracle Databaseのクライアントとサーバー上でX.509v3証明書を管理します。
エンティティの信頼できる証明書を構成します。
ウォレットをオープンして、PKIベースのサービスにアクセスできるようにします。
X.509v3証明書。信頼できるエンティティ、つまり認証局から取得します（および署名を受けます）。 認証局が信頼できるため、この証明書は、要求したエンティティの情報が正しいこと、および証明書の公開鍵は識別されたエンティティに属していることを検証します。この証明書は、将来の認証に対応するために、Oracleウォレットにロードされます。
Oracle Advanced Securityを使用すると、認可も含めたユーザー関連情報をLDAPベースのディレクトリ・サービスで集中管理できます。これにより、ユーザーおよび管理者をデータベース内でグローバル・ユーザーとして識別できます。これは、そのユーザーがSSLによって認証され、ユーザーの管理がデータベースの外部で集中化されたディレクトリ・サービスによって処理されることを意味します。グローバル・ロールはデータベース内で定義され、そのデータベースに対してのみ認識されますが、グローバル・ロールに対する認可はディレクトリ・サービスによって処理されます。
このような集中管理によって、エンタープライズ・ユーザーとエンタープライズ・ロールの作成が可能になります。エンタープライズ・ユーザーの定義と管理は、ディレクトリ内で行います。エンタープライズ・ユーザーには企業内で一意の識別情報があり、複数データベースにまたがるアクセス権限を決定するエンタープライズ・ロールを割り当てることができます。エンタープライズ・ロールは1つ以上のグローバル・ロールで構成されているため、グローバル・ロールのコンテナとみなすことができます。
ディレクトリ・サービスによって認可されるユーザーの指定方法には、次のようなオプションがあります。
次の文は、SSLによって認証され、エンタープライズ・ディレクトリ・サービスによって認可されるプライベート・スキーマを持ったグローバル・ユーザーの作成方法を示しています。
CREATE USER psmith IDENTIFIED GLOBALLY AS 'CN=psmith,OU=division1,O=oracle,C=US';
AS句に指定されている文字列は、エンタープライズ・ディレクトリにとって意味のある識別子（識別名、つまりDN）です。
この場合は、psmithがグローバル・ユーザーです。ただし、ここでのデメリットは、このユーザーpsmithを、アクセスが必要なすべてのデータベースとディレクトリに作成する必要があることです。
複数のエンタープライズ・ユーザーがデータベース内の1つのスキーマを共有する可能性があります。これらのユーザーは、エンタープライズ・ディレクトリ・サービスによって認可されますが、データベース内に個々のプライベート・スキーマを持ちません。また、ユーザーはデータベース内に個別に作成されません。ユーザーは、データベース内の共有スキーマに接続します。
スキーマに依存しないユーザーを作成する手順は、次のとおりです。
次の例を使用して、データベースに共有スキーマを作成します。
CREATE USER appschema IDENTIFIED GLOBALLY AS '';
ディレクトリに、複数のエンタープライズ・ユーザーとマッピング・オブジェクトを作成します。
このマッピング・オブジェクトは、ユーザーのDNを共有スキーマにマップする方法をデータベースに伝えます。完全なDNマッピング（一意のDN 1つに対して1つのディレクトリ・エントリが対応する）を作成するか、または、ユーザーごとに複数のDNコンポーネントを1つのスキーマにマップできます。次に例を示します。
OU=division,O=Oracle,C=US
ほとんどのユーザーは専用スキーマを必要としないため、スキーマに依存しないユーザーを実装することで、ユーザーをデータベースから切り離すことができます。データベース内で同じスキーマを共有する複数のユーザーを作成すると、各ユーザーは他のデータベース内の共有スキーマにもエンタープライズ・ユーザーとしてアクセスできます。
SSL、KerberosまたはWindowsのシステム固有の認証を使用して、厳密な認証が行われます。
ユーザーと権限を全社規模で集中管理できます。
管理が容易です。ユーザーごとに、社内の各データベースにスキーマを作成する必要がありません。
シングル・サインオンを容易に利用できます。ユーザーは一度サインオンすれば、複数のデータベースとサービスにアクセスできます。また、パスワードを使用するユーザーは、パスワード認証方式のエンタープライズ・ユーザーを受け入れる複数のデータベースに、1つのパスワードを使用してアクセスできます。
グローバルなユーザー認証と認可はパスワード・ベースのアクセスを提供するため、以前に定義されたパスワード認証方式のデータベース・ユーザーを、集中管理されているディレクトリに（ユーザー移行ユーティリティを使用して）移行できます。これによって、以前のリリースのOracle Databaseクライアントで使用可能だったグローバル認証と認可が引き続きサポートされます。
CURRENT_USERデータベース・リンクはグローバル・ユーザーとして接続します。ローカル・ユーザーは、ストアド・プロシージャのコンテキスト内ではグローバル・ユーザーとして接続できます。グローバル・ユーザーのパスワードをリンク定義に格納する必要はありません。
この項の内容は、次のとおりです。
ユーザー・アカウントに対して外部認証を使用する場合、ユーザー・アカウントはOracle Databaseでメンテナンスされますが、パスワード管理とユーザー認証は外部サービスによって実行されます。この外部サービスは、オペレーティング・システムでもOracle Netのようなネットワーク・サービスでもかまいません。
外部認証の場合、データベースはデータベース・アカウントへのアクセス制限を、その基礎となるオペレーティング・システムまたはネットワーク認証サービスに依存します。データベース・パスワードは、このタイプのログインには使用されません。オペレーティング・システムまたはネットワーク・サービスで許可されている場合は、それにより、ユーザーがデータベースにログインする前にユーザーを認証できます。この機能を使用可能にするには、初期化パラメータOS_AUTHENT_PREFIXを設定し、この接頭辞をOracle Databaseユーザー名で使用します。このOS_AUTHENT_PREFIXパラメータは、Oracle Databaseで全ユーザーのオペレーティング・システム・アカウント名の先頭に追加する接頭辞を定義します。Oracle Databaseは、ユーザーが接続しようとすると、接頭辞付きのユーザー名をデータベース内のOracle Databaseユーザー名と比較します。
OS_AUTHENT_PREFIXをNULL文字列（空の二重引用符""で指定）に設定する必要があります。NULL文字列を使用すると、オペレーティング・システム・アカウント名に接頭辞は追加されないため、Oracle Databaseユーザー名とオペレーティング・システム・ユーザー名は完全に一致します。
OS_AUTHENT_PREFIX=" "
設定したOS_AUTHENT_PREFIXは、データベースの存続期間中は同じ設定が維持されます。接頭辞を変更した場合、古い接頭辞を含むデータベース・ユーザー名は、パスワード認証を使用するように変更しないかぎり、接続に使用できません。
このパラメータのデフォルト値はOPS$であり、これによって古いバージョンのOracle Databaseとの下位互換性を維持しています。たとえば、OS_AUTHENT_PREFIXを次のように設定する場合を想定します。
OS_AUTHENT_PREFIX=OPS$
|
注意: OS_AUTHENT_PREFIX初期化パラメータに指定する文字列は、オペレーティング・システムによって大/小文字が区別される場合があります。この初期化パラメータの詳細は、使用しているオペレーティング・システム固有のOracle Databaseマニュアルを参照してください。 |
オペレーティング・システム・アカウント名tsmithを持つユーザーが、Oracleデータベース・インストールに接続する際にオペレーティング・システムによって認証された場合、Oracle Databaseは対応するデータベース・ユーザーOPS$tsmithの存在をチェックし、存在している場合はこのユーザーを接続できます。オペレーティング・システムによって認証されたユーザーへの参照には、OPS$tsmithのように、必ず接頭辞OPS$が含まれる必要があります。
スマート・カード、指紋、Kerberos、オペレーティング・システムなど、使用可能な認証メカニズムの選択肢が増えます。
Kerberosなどのネットワーク認証サービスの多くがシングル・サインオンをサポートしているため、ユーザーは多数のパスワードを記憶する必要がありません。
前述の外部認証メカニズムのいずれかをすでに使用している場合は、そのメカニズムをデータベースで使用することで、管理費用を節減できます。
次の文は、Oracle Databaseによって識別され、オペレーティング・システムまたはネットワーク・サービスによって認証されるユーザーを作成します。この例では、OS_AUTHENT_PREFIXパラメータは空白（" "）に設定されていると想定しています。
CREATE USER psmith IDENTIFIED EXTERNALLY;
CREATE USER ... IDENTIFIED EXTERNALLY文を使用して、オペレーティング・システムまたはネットワーク・サービスによる認証が必要なデータベース・アカウントを作成できます。Oracle Databaseがこの外部ログイン認証に依存するのは、特定のユーザーのデータベース・リソースへのアクセス権を特定のオペレーティング・システム・ユーザーに付与する場合です。
デフォルトでは、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つに接続プーリングがあります。これにより、複数のユーザーが個別に接続しなくても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でこの情報をチェックし、そのユーザーのロールを設定します。
中間層アプリケーションのセキュリティでは、次のような重要な問題に対処する必要があります。
アカウンタビリティ。データベース・サーバーでは、アプリケーションのアクションと、アプリケーションがクライアントにかわって実行するアクションを区別できる必要があります。この両方のアクションを監査できることが必要です。
最低限の権限。不慮または不正による無許可のアクティビティの危険性を排除するため、ユーザーと中間層には、それぞれのアクションを実行するために必要最小限の権限を与える必要があります。
多くの組織では、中間層のメリットを犠牲にせずに、アプリケーションのすべての層でユーザーを認識する必要があります。Oracle Databaseは、次の方法によって、アプリケーションの中間層を介したユーザー識別情報の保持をサポートしています。
Oracle Databaseでは、Oracle Call Interface（OCI）、Thick JDBCまたはThin JDBCによって、データベース・ユーザーまたはエンタープライズ・ユーザーにプロキシ認証を提供します。エンタープライズ・ユーザーは、Oracle Internet Directoryで管理されるユーザーで、データベースの共有スキーマにアクセスします。
次の各項では、プロキシ認証の使用方法について説明します。
次の3つの形式のプロキシ認証を使用して、クライアントを認証する中間層サーバーを安全な方法で設計できます。
中間層サーバーは、データベース・サーバーを使用してそれ自体を認証し、クライアント（この場合はアプリケーション・ユーザーまたは別のアプリケーション）は、この中間層サーバーを使用してそれ自体を認証します。クライアントの識別情報は、データベースに到達するまで確実に保持されます。
クライアント（この場合はデータベース・ユーザー）は、中間層サーバーによって認証されません。クライアントの識別情報とデータベース・パスワードは、中間層サーバーを経由してデータベース・サーバーに渡され、そこで認証されます。
クライアント（この場合はグローバル・ユーザー）は中間層サーバーによって認証され、中間層を介して次のいずれかを渡します。クライアントのユーザー名はそこから取得されます。
識別名（DN）
証明書
|
注意: プロキシ認証と認可に対する証明書の使用は、Oracle Databaseの将来のリリースでサポートされなくなる可能性があります。 |
いずれの場合でも、中間層サーバーにクライアントの代理としての機能を与えるために、管理者は中間層サーバーを認可する必要があります。
複数層環境では、プロキシ認証を使用すると、すべての層を通じてクライアントの識別情報と権限が保持され、クライアントのかわりに実行されるアクションが監査されるため、中間層アプリケーションのセキュリティを制御できます。たとえば、この機能によって、Webアプリケーション（プロキシとして機能する）を使用するユーザーの識別情報を、アプリケーションを介してデータベース・サーバーに渡すことができます。
3層システムは、組織にとって次のようなメリットがあります。
組織は、アプリケーション・ロジックをアプリケーション・サーバーに、データ記憶域をデータベースにパーティション化することによって、アプリケーション・ロジックとデータ記憶域を分離できます。
アプリケーション・サーバーおよびWebサーバーを使用して、データベースに格納されているデータにアクセスできます。
ユーザーは、操作が簡単で使い慣れたブラウザ・インタフェースを使用できます。
組織では、多数のシック・クライアントを多数のシン・クライアントと1つのアプリケーション・サーバーに置き換えることによって、コンピューティング・コストを低く抑えることもできます。
さらに、Oracle Databaseのプロキシ認証には、次のセキュリティ上のメリットがあります。
中間層がかわりに接続できるユーザー、および中間層がユーザーに対して想定できるロールを制御することによって制限付きトラスト・モデルが実現します。
OCI、Thick JDBCまたはThin JDBCでユーザー・セッションをサポートし、クライアント再認証のためのオーバーヘッドを排除することによってスケーラビリティが得られます。
実際のユーザーの識別情報をデータベースに到達するまで保持し、実際のユーザーのかわりに行われるアクションの監査を可能にすることによって、アカウンタビリティが得られます。
ユーザーがデータベースに認識されている環境と、ユーザーが単なるアプリケーション・ユーザーでデータベースには認識されていない環境の両方をサポートすることによって柔軟性が得られます。
|
注意: Oracle Databaseは、3層環境でのみこのプロキシ認証機能をサポートします。この機能は、複数の中間層にわたってはサポートされません。 |
プロキシ・アカウントを使用して接続するようにユーザー・アカウントを認可するには、ALTER USER文のGRANT CONNECT THROUGH句を使用します。
例3-6に、プロキシ・ユーザーappuserを介して接続するようにユーザーprestonを変更する方法を示します。
この結果、ユーザーprestonは、次のようにappuserプロキシ・ユーザーを使用して接続できます。
CONNECT appuser[preston]
Enter password: password
次のことに注意してください。
中間層クライアントでのロールの使用。クライアントとして接続したときに、中間層でアクティブにすることが可能なロールも指定できます。中間層サーバーがクライアントのかわりに実行する操作は、監査の対象にすることができます。
プロキシ・ユーザーの検索。現在中間層を介した接続が認可されているユーザーを検索するには、PROXY_USERSデータ・ディクショナリ・ビューを問い合せます。次に例を示します。
SELECT * FROM PROXY_USERS;
プロキシ接続の取消し。プロキシ接続の認可を取り消すには、ALTER USER文のREVOKE CONNECT THROUGH句を使用します。たとえば、ユーザーprestonを、プロキシ・ユーザーappuserを介した接続から取り消すには、次の文を実行します。
ALTER USER preston REVOKE CONNECT THROUGH appuser
パスワードの期限切れとプロキシ接続。 中間層で使用されるパスワードの期限切れは、プロキシを介して認証されたアカウントに適用されません。パスワードを期限切れにするかわりに、アカウントをロックしてください。
|
関連項目:
|
プロキシ認証に使用しているパスワードが不正なユーザーによって取得される懸念がある場合は、プロキシ認証で安全性の高い外部パスワード・ストアを使用してパスワード資格証明をウォレットに格納できます。プロキシ認証と安全性の高い外部パスワード・ストアを使用したOracle Databaseへの接続は、バッチ・ファイルを実行するなどの状況に理想的です。 プロキシ・ユーザーがデータベースに接続し、安全性の高い外部パスワードを使用して認証を行うと、不正なユーザーが取得しようとしてもパスワードは公開されません。
安全性の高い外部パスワード・ストアとプロキシ認証を使用する手順は、次のとおりです。
プロキシ認証アカウントを例3-6のように構成します。
安全性の高い外部パスワード・ストアを構成します。詳細は、「クライアントを外部パスワード・ストアを使用するように構成」を参照してください。
その後、ユーザーはパスワードを指定せずにプロキシを使用して接続できます。次に例を示します。
sqlplus jward[preston]
エンタープライズ・ユーザーまたはデータベース・ユーザーの場合は、Oracle Call Interface、Thick JDBCまたはThin JDBCを使用して、単一のデータベース接続内で、中間層にいくつかのユーザー・セッションを設定できます。ユーザー・セッションごとに接続ユーザーが一意に識別されます（接続プーリング）。これらのセッションによって、中間層からデータベースへの個別のネットワーク接続を確立するためのネットワーク・オーバーヘッドが排除されます。
次に、クライアントからデータベースへの中間層を介した完全な認証順序を示します。
クライアントは、中間層が受け入れる任意の認証形式を使用して、中間層に対する認証を行います。たとえば、クライアントは、ユーザー名とパスワード、またはSSLによるX.509証明書を使用して、中間層に対する認証を実行できます。
中間層は、データベースが受け入れる任意の認証形式を使用して、中間層自体をデータベースに対して認証します。認証形式には、パスワード、またはKerberosチケットやX.509証明書（SSL）などのOracle Advanced Securityがサポートしている認証メカニズムがあります。
次に、中間層はOCI、Thick JDBCまたはThin JDBCを使用して、ユーザーに対して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ロールのみを使用できるように中間層を制限します。
管理者は、appsrvに対して、Sarahのclerkロールのみを使用してSarahのかわりに接続を開始する許可を効果的に付与できます。次の構文を使用します。
ALTER USER sarah GRANT CONNECT THROUGH appsrv WITH ROLE clerk;
デフォルトでは、中間層はどのクライアントに対する接続も確立できません。許可はユーザーごとに付与する必要があります。
appsrvに対して、クライアントSarahに付与されているすべてのロールの使用を許可するには、次の文を使用します。
ALTER USER sarah GRANT CONNECT THROUGH appsrv;
中間層が別のデータベース・ユーザーのOCI、Thick JDBCまたはThin JDBCセッションを開始するたびに、データベースでは指定されたロールを使用して、そのユーザーに対する接続を開始する権限が中間層にあることを検証します。
|
注意: デフォルトのロールを使用せずに、独自のロールを作成し、そのロールに必要な権限のみを割り当ててください。独自のロールを作成すると、ロールによって付与される権限を制御でき、Oracle Databaseでデフォルトのロールが変更または削除された場合も保護されます。たとえば、現在、 CONNECTロールには、データベースへの接続で直接必要になるCREATE SESSION権限のみが含まれています。
以前は、 ロールの詳細は、第4章「権限とロール認可の構成」を参照してください。 |
次の文は、中間層サーバーappserveがユーザーbillとして接続することを認可します。この文はWITH ROLE句を使用して、billに対応付けられているロールのうち、payrollを除くすべてのロールがappserveによってアクティブ化されることを指定します。
ALTER USER bill
GRANT CONNECT THROUGH appserve
WITH ROLE ALL EXCEPT payroll;
ユーザーbillとして接続するための中間層サーバーの（appserve）認可を取り消すには、次の文を使用します。
ALTER USER bill REVOKE CONNECT THROUGH appserve;
中間層がプロキシとして機能していても、中間層によって認証されないユーザーを認可するには、ALTER USER ... GRANT CONNECT THROUGH文のAUTHENTICATED USING句を使用します。現在サポートされている認証方式は、PASSWORDのみです。
次の文は、この認証方式の例を示しています。
ALTER USER mary
GRANT CONNECT THROUGH midtier
AUTHENTICATED USING PASSWORD;
この文の中間層サーバー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プロキシ句を使用した場合は、システムによってAUTHENTICATION REQUIREDに変換されます。 |
パスワード・ベースのプロキシ認証を使用すると、Oracle Databaseはクライアントのパスワードを中間層サーバーに渡します。次に、中間層サーバーは、そのパスワードを属性として、検証のためにデータ・サーバーに渡します。この認証の主な利点は、データベース操作を実行するために、クライアント・コンピュータにOracleソフトウェアをインストールする必要がないことです。
クライアントのパスワードを渡す場合、中間層サーバーは、次の疑似インタフェースを使用して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でユーザーを検索します。
クライアントの識別名を渡す場合、アプリケーション・サーバーは、属性タイプとして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属性（OCI_ATTR_USERNAME）を使用します。Oracle Databaseでは、最初にユーザー名をデータベースに対してチェックします。ユーザーが見つからなかった場合、データベースはディレクトリ内のユーザー名をチェックします。このユーザー名はグローバルに一意である必要があります。
Oracle Databaseのプロキシ認証機能を使用すると、中間層がユーザーのかわりに実行するアクションを監査できます。たとえば、アプリケーション・サーバーhrappserverがユーザーAjitおよびJaneに対して複数のセッションを作成するとします。データベース管理者は、hrappserverがjaneのかわりに開始するbonus表に対して実行されるSELECT文の監査を次のように使用可能にできます。
AUDIT SELECT TABLE BY hrappserver ON BEHALF OF jane;
また、データベース管理者は、中間層を介して接続している複数のユーザー（この場合はJaneとAjit）のかわりに、次のように監査を使用可能にすることもできます。
AUDIT SELECT TABLE BY hrappserver ON BEHALF OF ANY;
この監査オプションによって監査されるのは、hrappserverが他のユーザーのかわりに開始したSELECT文のみです。データベース管理者は別の監査オプションを使用可能にして、データベースに直接接続しているクライアントからbonus表に対するSELECT文を取得できます。
AUDIT SELECT TABLE;
実際のユーザーのかわりに実行されるアクションの監査の場合は、CONNECT ON BEHALF OF DNを監査できません。これは、LDAPディレクトリ内のユーザーはデータベースに認識されないためです。ただし、ユーザーが共有スキーマ（APPUSERなど）にアクセスする場合は、CONNECT ON BEHALF OF APPUSERを監査できます。
Oracle Databaseでは、アプリケーション・ユーザーに対して、組込みアプリケーション・コンテキスト・ネームスペースUSERENVのCLIENT_IDENTIFIER属性を提供します。アプリケーション・ユーザーは、アプリケーションには認識されますが、データベースには認識されません。CLIENT_IDENTIFIER属性は、アプリケーションで識別またはアクセス制御に使用する任意の値を取得し、その値をデータベースに渡すことができます。CLIENT_IDENTIFIER属性は、OCI、Thick JDBCおよびThin JDBCでサポートされています。
次の各項では、クライアント識別子の使用方法について説明します。
多くのアプリケーションでは、セッション・プーリングを使用して、複数のアプリケーション・ユーザーが再利用できる多数のセッションを設定します。ユーザーは中間層アプリケーションに対して自分自身を認証します。中間層アプリケーションは、単一の識別情報を使用してデータベースにログインし、すべてのユーザー接続を保持します。このモデルでは、アプリケーション・ユーザーは、アプリケーションの中間層に対して認証されますが、データベースには認識されません。このタイプのアプリケーションに対して、アプリケーション・ユーザー・プロキシのように機能するCLIENT_IDENTIFIER属性を使用できます。
このモデルでは、セッションの確立時に、中間層がクライアント識別子をデータベースに渡します。クライアント識別子は、実際には、CookieまたはIPアドレスなど中間層に接続しているクライアントを表すものなら何でもかまいません。アプリケーション・ユーザーを表すクライアント識別子は、ユーザー・セッション情報内で使用可能です。また、アプリケーション・コンテキスト（USERENVネーミング・コンテキスト）を使用してアクセスすることもできます。このように、アプリケーションはセッションを設定して再利用しながら、セッション内でアプリケーション・ユーザーを追跡できます。アプリケーションはクライアント識別子を再設定し、別のユーザーに対してそのセッションを再利用できるため、パフォーマンスが向上します。
組込みアプリケーション・コンテキスト・ネームスペースUSERENVの事前定義の属性CLIENT_IDENTIFIERを使用すると、グローバル・アプリケーション・コンテキストで使用するアプリケーション・ユーザー名を取得できます。CLIENT_IDENTIFIER属性は独立して使用することもできます。CLIENT_IDENTIFIER属性をグローバル・アプリケーション・コンテキストから独立して使用する場合、CLIENT_IDENTIFIERは、DBMS_SESSIONインタフェースを使用して設定できます。CLIENT_IDENTIFIERをデータベースに渡す機能は、Oracle Call Interface（OCI）、Thick JDBCおよびThin JDBCでサポートされています。
CLIENT_IDENTIFIER属性をグローバル・アプリケーション・コンテキストで使用すると、アプリケーションの作成に必要な柔軟性と高いパフォーマンスが得られます。たとえば、ビジネス・パートナに情報を提供するWebベース・アプリケーションに、ゴールド・パートナ、シルバー・パートナおよびブロンズ・パートナという3タイプのユーザーが用意されていて、それぞれが異なるレベルの使用可能な情報を表しているとします。アプリケーションでは、ユーザーごとに個別のアプリケーション・コンテキストを持つユーザー独自のセッションを設定するのではなく、ゴールド・パートナ、シルバー・パートナおよびブロンズ・パートナ用のグローバル・アプリケーション・コンテキストを設定できます。次に、CLIENT_IDENTIFIERを使用して正しいコンテキストのセッションを指すことによって、適切なタイプのデータを取得します。アプリケーションでは、この3つのグローバル・コンテキストを一度初期化すれば、CLIENT_IDENTIFIERを使用して適切なアプリケーション・コンテキストにアクセスし、データ・アクセスを制限できます。これには、セッションを再利用できるということと、セッションごとにアプリケーション・コンテキストを個別に初期化する必要がなく、一度設定したグローバル・アプリケーション・コンテキストにアクセスできるというパフォーマンス上のメリットがあります。
CLIENT_IDENTIFIER属性は、ユーザーがデータベースに認識されていないアプリケーションで特に役立ちます。このような場合、アプリケーションは通常、単一のデータベース・ユーザーとして接続し、すべてのアクションがそのユーザーで実行されます。すべてのユーザー・セッションが同じユーザーとして作成されるため、このセキュリティ・モデルでは、ユーザーごとにデータを分離することが困難になります。これらのアプリケーションでは、CLIENT_IDENTIFIER属性を使用すると、実際のアプリケーション・ユーザーの識別情報をデータベースに保持できます。
この方法によると、CLIENT_IDENTIFIER属性の値を変更することで、複数のユーザーがセッションを再利用できます（この属性は、実際のアプリケーション・ユーザーの名前を取得します）。結果として、ユーザーごとに個別のセッションと属性を設定するためのオーバーヘッドが回避され、アプリケーションによるセッションの再利用が可能になります。CLIENT_IDENTIFIER属性の値が変更されると、その変更は次のOCIコール、Thick JDBCコールまたはThin JDBCコールに伝達されるため、パフォーマンスが向上します。
たとえば、ユーザーDanielがWeb Expenseアプリケーションに接続するとします。Danielはデータベース・ユーザーではなく、一般的なWeb Expenseアプリケーション・ユーザーです。このアプリケーションは組込みアプリケーション・コンテキスト・ネームスペースにアクセスし、CLIENT_IDENTIFIER属性値としてDANIELを設定します。Danielは自分のWeb Expenseフォームを完了してアプリケーションを終了します。次に、Ajitが同じWeb Expenseアプリケーションに接続します。アプリケーションでは、Ajit用の新しいセッションを設定せずに、CLIENT_IDENTIFIERをAJITに変更することによって、既存のDaniel用のセッションを再利用します。これによって、データベースへの新規の接続を設定するためのオーバーヘッドと、グローバル・アプリケーション・コンテキストを設定するためのオーバーヘッドが回避されます。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アプリケーションに対してCLIENT_IDENTIFIER属性を設定するには、次のoracle.jdbc.OracleConnectionインタフェース・メソッドを使用します。
setClientIdentifier() : 接続用のクライアント識別子を設定します。
clearClientIdentifier() : 接続用のクライアント識別子を消去します。
DBMS_SESSIONパッケージを使用して、中間層でCLIENT_IDENTIFIERの値を設定および消去するには、次のインタフェースを使用します。
SET_IDENTIFIER
CLEAR_IDENTIFIER
中間層では、SET_IDENTIFIERを使用してデータベース・セッションを特定のユーザーまたはグループに対応付けます。この結果、CLIENT_IDENTIFIERはセッションの属性になるため、セッション情報で確認できます。
DBMS_SESSION.SET_IDENTIFIERプロシージャを使用する場合は、DBMS_APPLICATION_INFO.SET_CLIENT_INFOプロシージャでクライアント識別子の値を上書きできることに注意してください。通常、これらの値は一致する必要があるため、CLIENTID_OVERWRITEイベントがONに設定されている場合は、SET_CLIENT_INFOが設定されていれば、その値をSET_IDENTIFIERにより設定された値に自動的に伝播できます。
CLIENTID_OVERWRITEイベントのステータスをチェックするには、SQL*PlusにログインしてSHOW PARAMETERコマンドを入力します。たとえば、CLIENTID_OVERWRITEが使用可能になっているとします。
SHOW PARAMETER EVENT NAME TYPE VALUE ------------------------------ ------------------ ------------------ event string client_overwrite
CLIENT_OVERWRITEイベントをシステム全体で使用可能にするには、SYSDBA権限を使用してSQL*PlusにSYSとして接続し、次のALTER SYSTEM文を入力します。
ALTER SYSTEM SET EVENTS 'CLIENTID_OVERWRITE';
または、init.oraファイルに次の行を入力します。
event="clientid_overwrite"
その後、データベースを再起動します。CLIENTID_OVERWRITEイベントを使用禁止にするには、SYSDBA権限を使用してSQL*PlusにSYSでログインし、次のALTER SYSTEM文を実行します。
ALTER SYSTEM SET EVENTS 'CLIENTID_OVERWRITE OFF';
セッションについてのみCLIENT_OVERWRITEの値を変更する場合は、ALTER SESSION文を使用します。
その後、DBMS_APPLICATION_INFO.SET_CLIENT_INFOプロシージャを使用してクライアント識別子を設定する場合は、クライアント識別子の設定が同一になるようにDBMS_SESSION.SET_IDENTIFIERを実行する必要があります。
|
関連項目:
|
表3-3に、ユーザー認証に関する情報を提供するデータ・ディクショナリ・ビューを示します。これらのビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
表3-3 ユーザー認証を示すデータ・ディクショナリ・ビュー
| ビュー | 説明 |
|---|---|
|
|
データベース・ロールがデータベースにログインする際に使用する認証の種類を表示します。 |
|
|
その他のユーザー情報から、次の情報を表示ます。
|
|
|
ユーザー・アカウント・パスワードがデフォルト・パスワードかどうかを表示します |
|
|
現在中間層経由での接続が認可されているユーザーを表示します |
|
|
既存のデータベース・リンク用のユーザー・アカウントを表示します（ |
