| Oracle Access Managerアップグレード・ガイド 10g（10.1.4.2.0） E05837-01 |
|
 戻る |
 次へ |
この章のタスクは、以前のアクセス・システムのカスタマイズをアップグレードおよび再デプロイする管理者を対象としています。アップグレードしてから、独立した小規模な環境でアップグレード後のカスタマイズをテストすることをお薦めします。
特に明記されていない場合、この章に記載されている情報はどちらのアップグレード・メソッドにも適用されます。ここで行うタスクは、以前のインストールの実装内容によって異なります。以前の環境に該当しないタスクはスキップしてください。内容は次のとおりです。
|
注意: 停止時間ゼロのアップグレードを実行している場合、これらのタスクを実行して、アップグレード後のカスタマイズをクローン環境でテストすることをお薦めします。詳細は、「停止時間ゼロのアップグレード・メソッドを使用したカスタマイズのアップグレード」を参照してください。 |
アクセス・システムのカスタマイズのアップグレードを開始する前に、次を行うことをお薦めします。
アイデンティティ・システムのカスタマイズをアップグレードし、そのアップグレードを再デプロイします（第12章を参照）。
「カスタマイズのアップグレード計画」の情報を確認します。
必要に応じて後でこのカスタマイズにロールバックできるように、以前のカスタマイズが含まれているディレクトリをバックアップして新しい場所に保存しておきます。
各カスタマイズのアップグレードとアップグレード内容のテストが終了したら、アップグレードしたカスタマイズが含まれているディレクトリをバックアップして新しい場所に保存しておくことをお薦めします。
前述のように、監査およびアクセス・レポートの環境がOracle Access Manager 10g（10.1.4.0.1）用に正しく設定されるようにするには、いくつかのアクティビティを実行する必要があります。アクセス・サーバー用のアクティビティを実行するには、次のファイルに含まれている情報を利用します。
AccessServer_install_dir\oblix\reports\crystal\audit.sql
この手順は、次に概説するように、アイデンティティ・サーバー用に実行した手順に似ています。監査スキーマのアップロードなど、このタスクに含まれる各手順の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。各手順の一般情報は、「アイデンティティ・システムの監査およびアクセス・レポートのアップグレード」を参照してください。
タスクの概要: Microsoft SQL Serverによる監査およびレポートのアップグレード
元のデータを保持しておくため、元のデータベースはそのまま残しておいてください。
すべてのポリシー・マネージャをアップグレードした後、最初のアクセス・サーバーをアップグレードします（ただし、アクセス・サーバー・サービスは再起動しないでください）。
MS SQLデータベースを使用している場合は、「データベースのレコード・サイズ」の情報を確認します。
新旧両方のデータベースのデータを使用するレポートを問合せまたは生成するには、各アクセス・サーバー・インスタンスで監査した以前のデータを10g（10.1.4.0.1）データベースにインポートし、そのデータが正しくインポートされたことを確認する必要があります。この手順を、アップグレードする各アクセス・サーバー・インスタンスに対して繰り返します。
監査表のserverIdフィールドは、そのレコードを監査したアクセス・サーバーのIDを示します。serverIdフィールドに基づき、各アクセス・サーバーで監査したレコードを識別できます。これは、アイデンティティ・サーバーでも同様です。
|
注意: MS SQLデータベース・インスタンスの以前のデータは切り捨てられる場合があります（「データベースのレコード・サイズ」を参照）。Oracleデータベース・インスタンスのデータは切り捨てられません。 |
このコンピュータのDSN（監査およびレポート・アプリケーションのRDBMSプロファイルで使用しているODBCのデータ・ソース名）を、新規データベース・インスタンスを指すように変更します。
|
注意: 同じコンピュータ上で複数のアクセス・サーバーを使用している場合は、新規データベースを指すようにDSNを変更する前に、このコンピュータのアクセス・サーバー・インスタンスを必ずすべてアップグレードしてください。 |
アクセス・サーバー・サービスを起動します。
このアクセス・サーバーによって、データの監査および格納が、新規データベース・インスタンスにおいて行われるようになります。ただし、他のアクセス・サーバーでは、データの監査および格納は引き続き以前のデータベース・インスタンスにおいて行われます。
次の手順に従い、残りのアクセス・サーバー・インスタンスをアップグレードします。
次のアクセス・サーバー・インスタンスをアップグレードします（ただし、アクセス・サーバー・サービスは再起動しないでください）。
ステップ4を繰り返し、このアクセス・サーバー・インスタンスのデータをインポートします。
|
注意: 同じコンピュータ上で複数のアクセス・サーバーを使用している場合は、新規データベースを指すようにDSNを変更する前に、このコンピュータのアクセス・サーバー・インスタンスを必ずすべてアップグレードしてください。 |
ステップ5を繰り返し、このコンピュータのDSN（監査およびレポート・アプリケーションのRDBMSプロファイルで使用しているODBCのデータ・ソース名）を、新規データベース・インスタンスを指すように変更します。
ステップ6を繰り返し、このコンピュータ上でアクセス・サーバー・サービスを再起動します。
使用環境内のすべてのアクセス・サーバーに対して、このステップ7を繰り返します。
すべてのアクセス・サーバー・インスタンスをアップグレードし終わったら、この章の後半にあるアクセス・システムのデプロイに固有のアクティビティを実行します。「WebGateのインプレース・アップグレード」の説明に従って、WebGateをアップグレードしてください。
監査を開始します（『Oracle Access Manager IDおよび共通管理ガイド』を参照）。
以前のアクセス・システムのインストールがフェイルオーバーまたはロード・バランシングを行うように構成されていた場合は、その構成がアップグレード後も正しく機能することを確認することをお薦めします。
ポリシー・マネージャをアップグレードしている場合: リリース6.5への段階的アップグレード中にディレクトリ・サーバー・プロファイルを作成する場合は、ディレクトリ・サーバーの資格証明は次のファイルから読み取られます。
PolicyManager_install_dir/access/oblix/config/userDB.lst
構成ツリーがユーザー・ディレクトリ・サーバー内でユーザー・ノードの下にある場合、構成ディレクトリ・プロファイルは作成されません。これ以外の場合は、構成ディレクトリ・プロファイルは、次のファイルにあるディレクトリ・サーバー情報を使用して作成されます。
PolicyManager_install_dir/oblix/config/ldap/configdb.lst
構成ディレクトリ・プロファイルは、ポリシー・マネージャのみで使用されるようマークされます。ポリシー・マネージャ・フェイルオーバー・サーバー用に使用されるプロファイルが作成されなくなります。リリース6.1では、ポリシー・ツリーが別のディレクトリ・サーバー上にある場合に、ポリシー・データのプロファイルが用意されていました。
アクセス・サーバーをアップグレードする場合: 構成用またはポリシー・ツリー用に使用されるプロファイルは、この時点では作成されません。リリース6.5より前では、アクセス・システム接続プールの「最初の接続数」および「最大接続数」の値がUserDB.lstおよびUserDBFailover.lstにありました。これらの値は保持されません。なお、多くの.lstファイルは、グローバリゼーション作業の一環として.xmlファイルに変換されます。
アクセス・システム・コンポーネントをアップグレードし終わったら、新規作成したディレクトリ・サーバー・プロファイルのデータベース・インスタンス・プロファイルで「最初の接続数」および「最大接続数」の値を検証することをお薦めします。
アクセス・システムのアップグレード後にフェイルオーバー、ロード・バランシングおよび接続プールの詳細を確認する手順
アクセス・システム・コンソールから、「システム構成」→「サーバー設定」を選択します。
「LDAPディレクトリ・サーバー・プロファイルの構成」ヘッダーの下で、確認するプロファイルの名前を選択します。
ディレクトリ・サーバー・プロファイル・ページで、フェイルオーバー情報を使用するサーバーを確認し、その情報が以前の設定に一致することを確認します。次に例を示します。
最大アクティブ・サーバー数
フェイルオーバーしきい値
スリープ時間（秒）
最長セッション時間
ディレクトリ・サーバー・プロファイル・ページで「データベース・インスタンス」リストに移動し、確認するデータベース・インスタンス・プロファイルの名前を選択します。
データベース・インスタンス・プロファイルで、「最初の接続数」および「最大接続数」の値を確認します。
必要な変更を行い、プロファイルを保存します。
すべてが意図したとおりに動作することを確認するためのテストを行います。
フェイルオーバーおよびロード・バランシングの構成の詳細は、『Oracle Access Managerデプロイメント・ガイド』を参照してください。
第4章で説明されているように、10g（10.1.4.0.1）では、フォーム・ベース認証で非ASCIIのログイン資格証明（ユーザー名/パスワード）がサポートされます。フォーム・ベース認証を10g（10.1.4.0.1）WebGateで使用するには、ログイン・フォームのキャラクタ・セット・エンコーディングをUTF-8に設定する必要があります。
10g（10.1.4.0.1）のための、UTF-8へエンコーディングするログイン・フォームを設定する手順
次のMETAタグを、ログイン・フォームHTMLページのHEADタグに追加します。
<META http-equiv="Content-Type" content="text/html;charset=utf-8">
以前のWebGateを10g（10.1.4.0.1）にアップグレードする場合は、アップグレード後にログイン・フォームのHTMLページも更新する必要があります。
|
注意: Basic認証は、非ASCIIのログイン資格証明では失敗します。非ASCIIのログイン資格証明には、フォーム・ベース認証を使用してください。Basic認証は、ASCIIのログイン資格証明に使用します。 |
カスタムのアクセス・システム・プラグインは、アクセス・サーバーのアップグレード中にターゲット・ディレクトリにコピーされます。ただし、前述のように、以前のプラグインは、Latin-1エンコーディングでデータを送受信します。
国際化されたデータを送受信するには、UTF-8エンコーディングを使用するようにプラグインの設計を変更する必要があります。また、SolarisおよびLinuxでは、リリース5.2および6.xのプラグインは、GCC v3.3.2 C++コンパイラを使用して再コンパイルする必要があります。詳細は、「プラグイン」を参照してください。
|
注意: リリース7.0のプラグイン、および実行可能ファイルとして実装されている以前のプラグインやスクリプト言語（Perlなど）を使用するプラグインは、アップグレード後の再コンパイルを必要としません。ただし、以前のプラグインで国際化されたデータを送受信するには、以前のプラグインをUTF-8エンコーディングで通信するように設計を変更する必要があります。 |
必要に応じて、UTF-8エンコーディングを使用するようにカスタム認証および認可プラグインの設計を変更します。
SolarisおよびLinuxプラットフォーム上のリリース5.2または6.xのプラグインは、GCC v3.3.2コンパイラを使用して再コンパイルします。
|
警告: オペレーティング・システムに付属のコンパイラがある場合でも、GCC v3.3.2コンパイラを使用する必要があります。 |
プラグインが10g（10.1.4.0.1）で正しく動作することを確認するためのテストを行います。
Latin-1エンコーディングでデータを送受信するプラグインを使用する場合は、アップグレードした環境に追加した新規アクセス・サーバーに下位互換性があることを確認します（第4章を参照）。
リリース6.5以降からアップグレードした場合は、この作業をスキップしてください。
アップグレード中に、リリース6.1.1の認可ルールの名前が、対応するポリシー・ドメインの「認可ルール」タブに移動されます。また、元のルールの名前は、そのルールが属するポリシーの名前の後に認可ルール名を付加したものに変更されます（PolicyName_AuthorizationRuleName）。
たとえば、6.1.1のインストール環境に1つのポリシー・ドメイン（MyPolicyDomain）と2つのポリシー（P1およびP2）が含まれているとします。そして、3つの認可ルールがこの2つのポリシーに（ルールA1とA2がポリシーP1に、ルールA3がポリシーP2に）関連付けられているとします。この場合、アップグレード後に「ポリシー・ドメイン」の「認可ルール」タブの下に次のように表示されます。
P1_A1 P1_A2 P2_A3
リリース6.1.1のポリシー・ドメインの認可ルール名を確認する手順
リリース6.1.1からのアップグレード後は、環境に応じたURLを使用してポリシー・マネージャのアクセス・システム・コンソールに移動します。次に例を示します。
http://hostname:port/access/oblix
ここで、hostnameはWebサーバーをホストするコンピュータ、portはWebPassのWebサーバー・インスタンスのHTTPポート番号をそれぞれ指し、/access/oblixはポリシー・マネージャおよびアクセス・システム・コンソールに接続します。
アクセス・システムのランディング・ページで、「ポリシー・マネージャ」リンクを選択します。
ポリシー・マネージャのメイン・ページで、ページの左側にある「ポリシー・ドメイン」を選択します。
「ポリシー・ドメイン」ページで、以前のポリシー・ドメインの1つ（DomainName）へのリンクを選択します。
そのドメインのページで、「認可ルール」タブを選択します。
「認可ルール」ページで、名前が変更された当該のルールを探します（ルールはアルファベット順にソートされています）。
ポリシー・ドメイン内の各認可ルールには、アクセスの許可条件およびアクセスの拒否条件を指定できます。ルールのアクセスの許可条件は、保護されているリソースに誰がアクセスする権限があるかを指定します。認可ルールのアクセスの拒否条件は、ルールで保護されるリソースへのアクセスを明示的に拒否するエンドユーザーおよびユーザー・グループを指定します。アクセスの許可条件、アクセスの拒否条件またはこの両方が指定されていて、ユーザーがこれらの条件に該当しない場合、ユーザーはルールの対象外とされます。ユーザーがルールの対象外とされると、デフォルトでは、ユーザーはリクエストしたリソースへのアクセスを拒否されます。
リリース7.xでは、新しい認可の状態が導入されました（認可の成功および失敗とは別の状態）。この新しい状態は、「未確定」という状態です。以前のインストールに認可失敗のリダイレクトが含まれていた場合にこの新しい状態に対応するには、次の手順を実行して、明示的な拒否ルールを指定し、認可ルールの「一般」パネルにある「許可を優先」を「はい」に変更します。
リリース6.1.1からのアップグレード後は、環境に応じたURLを使用してポリシー・マネージャのアクセス・システム・コンソールに移動します。次に例を示します。
http://hostname:port/access/oblix
ここで、hostnameはWebサーバーをホストするコンピュータ、portはWebPassのWebサーバー・インスタンスのHTTPポート番号をそれぞれ指し、/access/oblixはポリシー・マネージャおよびアクセス・システム・コンソールに接続します。
アクセス・システムのランディング・ページで、「ポリシー・マネージャ」リンクを選択します。
ポリシー・マネージャのメイン・ページで、ページの左側にある「ポリシー・ドメイン」を選択します。
「ポリシー・ドメイン」ページで、以前のポリシー・ドメインの1つ（DomainName）へのリンクを選択します。
そのドメインのページで、「認可ルール」タブを選択します。
「認可ルール」ページで、名前が変更された当該のルールを探し（ルールはアルファベット順にソートされています）、変更するルールを選択します。
「一般」パネルで、「許可を優先」が「はい」に設定されていることを確認します。
「アクセスの拒否」パネルを選択し、「人々」、「ロール」、「ルール」および「IPアドレス」コントロールを使用して、このルールで保護するリソースへのアクセスを拒否するユーザーおよびグループを指定するルールを作成または変更します（『Oracle Access Managerアクセス管理ガイド』を参照）。
以前のインストールで、ポリシー・マネージャで作成した、ObAMMasterAuditRule_getEscapeCharacterを含むCコードを使用していない場合は、この項目をスキップしてください。
ObAMMasterAuditRuleクラスのオブジェクトは、マスター監査ルールを表します。このルールは、グローバル監査パラメータと、特定のポリシーに対して監査ルールが未指定の場合に使用されるデフォルトを指定します。以前のリリースでは、ObAMMasterAuditRule_getEscapeCharacterにより監査エスケープ文字が返されました。10g（10.1.4.0.1）のC言語のAPIでは、ObAMMasterAuditRule_getEscapeCharacterが残っており、引き続き使用できます。ただし、監査のエスケープ文字はASCII文字でなければならず、それ以外の場合は戻り値が正しくありません。
UTF-8でエンコードされた監査エスケープ文字へのポインタを返す新しいObAMMasterAuditRule_getUTF8EscapeCharacterを使用するよう、Cコードを必要に応じて変更できます。
詳細は、「ポリシー・マネージャAPI」を参照してください。ポリシー・マネージャAPIの使用方法の詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
アップグレードしたアクセス・システムのカスタマイズは、アップグレードした本番環境にデプロイする前に、テストまたは開発環境でテストする必要があります。
アクセス・システムのカスタマイズのアップグレードを検証する手順
アップグレードした各カスタマイズ内容を実行する具体的操作を実行し、カスタマイズが適切にリストアされていることを確認します。
監査およびアクセス・レポートが正しく動作していることを確認します。
アップグレードが失敗した場合: 「アクセス・システムのカスタマイズのアップグレードの失敗からのリカバリ」に進みます。
アップグレードが成功した場合: 次の「アップグレードしたアクセス・システムのカスタマイズのバックアップ」に進みます。
前述のように、各アップグレードを終了する際には、該当する10g（10.1.4.0.1）ディレクトリをバックアップすることをお薦めします。これにより、アップグレード直後の環境にリストアする必要が生じたときに簡単にリストアできるようになります。
アクセス・システムのカスタマイズをアップグレードした後にバックアップする手順
アップグレードしたカスタマイズを含む10g（10.1.4.0.1）ディレクトリをバックアップし、新しい場所に保存します。
すべてのカスタマイズを完了して再デプロイしたら、第14章で説明する操作の検証に進みます。
アクセス・システムのカスタマイズが失敗した場合は、次の手順を実行してこのアップグレードをロールバックし、アップグレードしなおすことができます。
アクセス・システム・コンポーネントのアップグレードの失敗からリカバリする手順
アップグレードの前にバックアップした以前のカスタマイズのファイルまたはディレクトリをリストア（以前のカスタマイズをリカバリ）してから、これを再度バックアップします。一方をバックアップ・コピーとして保存し、他方を次の手順で使用します。
以前のカスタマイズ・ファイルのバックアップ・コピーを使用して、この章の説明に従ってアップグレードを再実行します。
