| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.1.3) E59413-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.1.3) E59413-03 |
|
前 |
次 |
この章では、ドメインの作成時または拡張時に、アプリケーションで、ドメイン・セキュリティ・ストアにアプリケーション固有のセキュリティ・アーティファクトのシードを指定する方法を説明します。ここでは、12.1.2へのアップグレード手順も説明します。
この章は次の項に分かれています:
11gドメインでは、デプロイメント・ディスクリプタが適切に設定されている場合に製品固有のセキュリティ・アーティファクトを指定すると、通常、それらのアーティファクトはアプリケーションEARファイルにバンドルされ、アプリケーションのデプロイ時にセキュリティ・ストアに移行されました。
12cドメインでは、製品テンプレートに製品固有のセキュリティ・アーティファクトをバンドルすると、それらのアーティファクトをドメイン・セキュリティ・ストアにシードできます。
JRFテンプレートを使用して作成または拡張されたドメインは、FMWドメインと呼ばれます。つまり、このテンプレートによって、ドメイン・セキュリティ・ストアのセキュリティ・アーティファクトのプロビジョニングが指定されます。具体的には、FMWドメインの作成時または拡張時に、次のタスクが自動的に実行されます。
OPSSセキュリティ・アーティファクトの作成
暗号化鍵でシードされるブートストラップ・ウォレットの作成
追加設定なしの、次を含むキーストア・サービスの作成
ドメイン・トラスト・ストア
デモCAキーストア
Oracle WebLogic Serverで使用するドメイン・アイデンティティ・キー・ストア
追加設定なしの、キーストア・サービスに接続されたトラスト・サービスの作成
3つのデータソースの作成: OPSSスキーマ、OPSS監査ビューア・スキーマ、OPSS監査追加スキーマそれぞれに1つずつ。
追加設定なしの、DBベースのセキュリティ・ストアの構成
デフォルトでの、DBベースの監査リポジトリの構成
|
重要事項: JRFテンプレートでは、管理対象サーバーは作成されません。JRFテンプレートによって作成または拡張されたドメインでは、そのすべてのリソースが管理サーバーにのみターゲット指定されます。後で管理対象サーバーをドメインに追加するときは、applyJRFユーティリティを起動して、リソースが管理対象サーバーにもターゲット指定されるようにする必要があります。
つまり、ドメイン再構成後のOPSSと監査データ・ソースを管理対象サーバーにターゲット指定するには、
applyJRF('managedServer1', '<domain_dir>')
|
コンポーネント・テンプレートの詳細は、「階層型コンポーネントのセキュリティ・アーティファクト」を参照してください。
本番FMWドメインは拡張ドメインである必要があり、拡張ドメインにはDBベースのOPSSセキュリティ・ストアが必要です。このデータベースは、新しいデータベースにすることも、既存のデータベースを他のFMWドメインに関連付けて共有データベースにすることもできます。管理対象サーバーにターゲット指定されているリソースおよびapplyJRFユーティリティの使用については、「FMWドメイン」の「重要事項」を参照してください。
次の各項では、FMWドメインの作成方法を説明します。
新しいデータベースと関連付けられたFMWドメインを作成または拡張するには、次の手順を実行します。
新しいデータベース・スキーマを作成します。詳細は、第9.3.1項「DBベースのセキュリティ・ストアを使用する場合の前提条件」を参照してください。
『Oracle Fusion Middleware構成ウィザードによるWebLogicドメインの作成』の第5章「構成画面」で説明されているように、構成ウィザードを使用してドメインを作成または拡張します。
このタスクでは特に、手順1で作成したデータベース・スキーマなど、使用するデータベース・スキーマに関する情報を指定したり、使用するJFRテンプレートを選択します。
|
注意1: 作成中のドメインに関連付けられるデータベース・スキーマは、新しいものである必要があり、以前に使用したものにすることはできません。 |
|
注意2: JRFテンプレートが処理されると、ドメインの作成時または拡張時に、OPSSスキーマ用、OPSS監査ビューア・スキーマ用およびOPSS監査追加スキーマ用に3つのデータ・ソースが自動作成されます。JRFテンプレートのその他の機能の詳細は、「FMWドメイン」を参照してください。 |
ドメインの作成、拡張またはアップグレードのためのすべてのツールの詳細は、『Oracle Fusion Middlewareドメイン・テンプレート・リファレンス』のテンプレート・ツールに関する説明を参照してください。
ドメインの既存のデータベースと関連付けられる拡張FMWドメインを作成するには、次の手順を実行します。
|
注意: 前述の手順では構成ウィザードを使用できたのに対して、次の手順では、WLSTコマンドのみを使用できます。 |
ドメインdomain1で(他のドメインを結合する必要のある)既存のデータベースdb1を使用していると仮定した場合、次に示すWLSTオフライン・コマンドexportEncryptionKeyを使用して、domain1から、指定された場所に暗号化鍵をエクスポートします。
exportEncryptionKey(location, password)
コマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。
次のようなWLSTスクリプトを使用して、データベースdb1を共有するための拡張FMWドメインを作成します。
## arg1 - wls.jar loc
## arg2 - jrf.jar loc
## arg3 - domain home
## arg4 - adminserver port
## arg5 - Db host
## arg6 - db port
## arg 7 - DB service name (pdb)
## arg8 - STB schema user,
readTemplate(sys.argv[1],"Expanded")
cd('/Security/base_domain/User/weblogic')
cmo.setName('weblogic')
cmo.setPassword('welcome1')
writeDomain(sys.argv[3])
closeTemplate()
#Set AdminServer Port
readDomain(sys.argv[3])
cd('/Servers/AdminServer')
set('ListenAddress','')
set('ListenPort', int(sys.argv[4]))
updateDomain()
closeDomain()
readDomain(sys.argv[3])
addTemplate(sys.argv[2])
cd('/JDBCSystemResource/LocalSvcTblDataSource/JdbcResource/LocalSvcTblDataSource')
cd('JDBCDriverParams/NO_NAME_0')
set('DriverName','oracle.jdbc.OracleDriver')
set('PasswordEncrypted', 'myPassw')
set('URL','jdbc:oracle:thin:@'+sys.argv[5]+':'+sys.argv[6]+'/'+sys.argv[7])
set('UsePasswordIndirection', 'false')
set('UseXADataSourceInterface', 'false')
create('myProps','Properties')
cd('Properties/NO_NAME_0/Property/user')
cmo.setValue(sys.argv[8])
getDatabaseDefaults()
setSharedSecretStoreWithPassword(location, password)
updateDomain()
locationおよびpasswordの値は、exportEncryptionKeyへのコールで使用した値と同じです。構文の詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。
domain1およびWLSTスクリプトで作成したドメインにあるすべてのサーバーを起動します。どちらのドメインも同じセキュリティ・ストアを共有しています。
セキュリティ・アーティファクトのシードおよびプロセスを簡略化するには、ドメインの作成または拡張時に、OPSSを使用するコンポーネントによってテンプレートが指定される必要があります。このテンプレートは、コンポーネントの実行に必要な、コンポーネントのみに固有のアーティファクトを定義およびバンドルし、表7-1に示すファイルを含みます。
表7-1 OPSSで使用されるコンポーネント・テンプレートのファイル
| ファイル名 | 説明 | テンプレートのルート・フォルダからの場所 |
|---|---|---|
|
component-security-info.xml |
必須。セキュリティ・アーティファクトのライフサイクルを指定します。 |
./security/component-security-info.xml |
|
jazn-data.xml |
オプション。認可ポリシーを指定します。 |
./security/authorization/jazn-data.xml |
|
keystore.xml |
オプション。キーストアのメタデータを指定します。 |
./security/keystore/keystore.xml |
|
credentials.xml |
オプション。コンポーネントで使用される資格証明メタデータを指定します。 |
./security/credential/credentials.xml |
|
component_events.xml |
オプション。監査メタデータを指定します。 |
./security/audit/component_events.xml |
|
component_events_xlf.jar |
オプション。ローカライズされた監査メタデータを指定します。 |
./security/audit/component_events_xlf.jar |
|
注意: 製品テンプレートにバンドルされたOPSSセキュリティ・アーティファクトでは、component-security-info.xmlファイルによって、アーティファクトの処理方法が示される必要があります。 |
この項では、セキュリティ・アーティファクトをリリース11.1.1.6、11.1.1.7または12.1.2からリリース12.1.3にアップグレードする方法を説明します。
アップグレードの完了後、キーストアをJKSからKSSに移動する必要がある場合は、第12.2.2.8項「コマンド・ラインでのキーストアのインポート」を参照してください。
OPSSセキュリティ・ストアをアップグレードする前に、アップグレードに失敗した場合にリカバリできるようバックアップを作成してください。セキュリティ・ストアのバックアップの詳細は、「OPSSセキュリティ・ストアのバックアップとリカバリ」を参照してください。
アップグレード手順は、アップグレードされるセキュリティ・ストアのタイプに応じて異なります。アップグレード可能なセキュリティ・ストアは、ファイルベース、OIDベースまたはDBベースです。ただし、次の手順は、元の監査データ・ストアのタイプ(ファイルベースまたはDBベース)に応じて異なります。
DBベースのセキュリティ・ストアを11.1.1.6、11.1.1.7または12.1.2から12.1.3にアップグレードするには、次の手順を実行します。
Oracle Fusion Middlewareのアップグレード・アシスタントを実行してOPSSスキーマをアップグレードします。元の監査データ・ストアがDBベースの場合は監査スキーマをアップグレードします。
「使用可能なコンポーネント」ページで、必ず「Oracle Platform Security Services」を選択してください。アップグレード・アシスタントの詳細は、『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』を参照してください。
12.1.2からアップグレードする場合、この手順はスキップし、手順3に進みます。それ以外の場合は、リポジトリ作成ユーティリティ(RCU)を実行して、サービス表のスキーマのみを作成します。RCUの詳細は、『Repository Creation Utilityによるスキーマの作成』を参照してください。
元の監査データ・ストアがファイルベースの場合はRCUを実行して、監査スキーマを作成します。
再構成ウィザードを実行してドメインの再構成を有効にし、OPSSデータ、DIT、構成アーティファクトおよび製品のセキュリティ・アーティファクトをアップグレードします。
この手順では、次の点に注意してください。
「データベース構成タイプ」ページで「RCUデータ」を選択し、サービス表のスキーマを入力して、「RCU構成の取得」をクリックします。
「コンポーネント・データソース」ページで次のコンポーネントを選択し、スキーマの詳細を入力します。
OPSS監査スキーマ - IAU_APPEND
OPSS監査ビューア - IAU_VIEWER
OPSSスキーマ - OPSS
元の監査データ・ストアがファイルベースの場合、監査データ・ソースが必ず存在します。詳細は、14.2.2項を参照してください。
|
注意: 12c拡張ドメインから12cのアップグレード済ドメインへの結合は、サポートされていません。 |
OPSSはエディションベースの再定義(EBR)をサポートしています。OPSSを使用する前にデフォルト・エディションを設定する方法の詳細は、次のセクションにある手順を参照してください。
『Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニング』の第2.7.5項。
『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』の第1.6.3項。
Oracle Fusion Middlewareのアップグレードの詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニング』を参照してください。
OIDベースのセキュリティ・ストアを11.1.1.6、11.1.1.7または12.1.2から12.1.3にアップグレードするには、次の手順を実行します。
Oracle Fusion Middlewareのアップグレード・アシスタントを実行してOPSSスキーマをアップグレードします。元の監査データ・ストアがDBベースの場合は監査スキーマをアップグレードします。
「使用可能なコンポーネント」ページで、必ず「Oracle Platform Security Services」を選択してください。アップグレード・アシスタントの詳細は、『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』を参照してください。
リポジトリ作成ユーティリティ(RCU)を実行して、OPSSスキーマを作成します。このスキーマの詳細は、自動的に「データベース構成タイプ」ページに挿入されます。(監査スキーマが存在しない場合は、この手順でこのスキーマも作成されます)。RCUの詳細は、『Repository Creation Utilityによるスキーマの作成』を参照してください。
再構成ウィザードを実行してドメインの再構成を有効にし、OPSSデータ、DIT、構成アーティファクトおよび製品のセキュリティ・アーティファクトをアップグレードします。
この手順では、次の点に注意してください。
「データベース構成タイプ」ページで「RCUデータ」を選択し、手順2で作成したサービス表のスキーマを入力して、「RCU構成の取得」をクリックします。
「コンポーネント・データソース」ページで次のコンポーネントを選択し、スキーマの詳細を入力します。
OPSS監査スキーマ - IAU_APPEND
OPSS監査ビューア - IAU_VIEWER
OPSSスキーマ - OPSS
元の監査データ・ストアがファイルベースの場合、監査データ・ソースが必ず存在します。詳細は、第14.2.2項「監査データ・ソースについて」を参照してください。
この項では、複数のドメインで共有(結合)されているセキュリティ・ストアのアップグレードに必要な追加手順を説明します。次の手順は、共有しているセキュリティ・ストアのバージョンによって異なります。
OPSSセキュリティ・ストアをアップグレードする前に、アップグレードに失敗した場合にリカバリできるようバックアップを作成してください。セキュリティ・ストアのバックアップの詳細は、「OPSSセキュリティ・ストアのバックアップとリカバリ」を参照してください。
この項には次のトピックが含まれます:
複数のドメインが共有している12.1.2セキュリティ・ストアを12.1.3にアップグレードするには、次の手順を実行します。
アップグレードの対象となるストアを共有しているドメインをすべてシャットダウンします。
Oracle Fusion Middlewareのアップグレード・アシスタントを実行し、共有しているセキュリティ・ストアのOPSSスキーマをアップグレードします。元の監査データ・ストアがDBベースの場合は監査スキーマをアップグレードします。
「使用可能なコンポーネント」ページで、必ず「Oracle Platform Security Services」を選択してください。アップグレード・アシスタントの詳細は、『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』を参照してください。
セキュリティ・ストアを共有しているドメインそれぞれで、再構成ウィザードを実行してドメインの再構成を有効にし、OPSSデータ、DIT、構成アーティファクトおよび製品のセキュリティ・アーティファクトをアップグレードします。
この手順では、次の点に注意してください。
「データベース構成タイプ」ページで「RCUデータ」を選択し、手順2で作成したサービス表のスキーマを入力して、「RCU構成の取得」をクリックします。
「コンポーネント・データソース」ページで次のコンポーネントを選択し、スキーマの詳細を入力します。
OPSS監査スキーマ - IAU_APPEND
OPSS監査ビューア - IAU_VIEWER
OPSSスキーマ - OPSS
|
注意: ドメインのいずれかで初めて再構成ウィザードを実行すると、OPSSデータがアップグレードされます。その後、残りのドメインのいずれかで再構成ウィザードを実行すると、そのドメインは12.1.3バイナリを使用するように再構成されます。 |
セキュリティ・ストアを共有しているドメインをすべて再起動します。
共有している11.1.1.6または11.1.1.7セキュリティ・ストアを12.1.3にアップグレードするには、次の手順を実行します。
アップグレードの対象となるストアを共有しているドメインをすべてシャットダウンします。
セキュリティ・ストアを共有しているドメインそれぞれでバイナリをアップグレードします。
Oracle Fusion Middlewareのアップグレードの詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニング』を参照してください。
Oracle Fusion Middlewareのアップグレード・アシスタントを実行し、共有しているセキュリティ・ストアのOPSSスキーマをアップグレードします。元の監査データ・ストアがDBベースの場合は監査スキーマをアップグレードします。
「使用可能なコンポーネント」ページで、必ず「Oracle Platform Security Services」を選択してください。アップグレード・アシスタントの詳細は、『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』を参照してください。
セキュリティ・ストアを共有しているドメインそれぞれで、11g upgradeOpssコマンドを実行します。あるドメインから初めてこのコマンドを実行すると、セキュリティ・ストアのデータとそのドメインの構成がアップグレードされます。その後、残りのドメインのいずれかでコマンドを実行すると、そのドメインの構成のみがアップグレードされます。
アップグレードされたドメインをすべて再起動します。
ファイルベースのセキュリティ・ストアを11.1.1.6または11.1.1.7から12.1.3にアップグレードするには、次の手順を実行します。
元の監査データ・ストアがファイルベースの場合はRCUバージョン11gを実行して、OPSSスキーマとOPSS監査スキーマの両方を作成します。それ以外の場合、監査データ・ストアがDBベースであれば、RCUバージョン11gを実行して、OPSSスキーマのみを作成します。
監査データ・ストアがファイルベースの場合、ターゲット・ストアには監査データ・ソースが必要です。第14.2.2項を参照してください。
コマンドreassociateSecurityStoreを使用して、ファイルベースのセキュリティ・ストアをDBベースのセキュリティ・ストアに再度関連付けします(詳細は、第10.4.1項「reassociateSecurityStore」を参照してください)。
「DBベースのセキュリティ・ストアのアップグレード」の説明に従って、再度関連付けしたDBベースのセキュリティ・ストアを12.1.3にアップグレードします。
この項では、ドメインのOPSSセキュリティ・ストアのバックアップ方法とリカバリ方法を説明します。その手順は、処理対象であるOPSSストアの種類(DBベースまたはOIDベース)によって異なります。
セキュリティ・ストアのバックアップに加え、リカバリを可能にするために、次のセキュリティ・ストア用の構成ファイルとデータ・ファイルも保存してください(アスタリスクでディレクトリ内のすべてのファイルを指定可能)。
{domain}/Config/config.xml
{domain}/Config/Fmwconfig/jps-config.xml
{domain}/Config/Fmwconfig/jps-config-jse.xml
{domain}/Config/Fmwconfig/cwallet.sso
{domain}/Config/Fmwconfig/keystores.cml
{domain}/Config/Fmwconfig/audit-store.xml
{domain}/Config/Fmwconfig/system-jazn-data.xml
{domain}/Config/Fmwconfig/ids-config.xml
{domain}/Config/Fmwconfig/mbeans/jps_mbeans.xml
{domain}/Config/Fmwconfig/bootstrap/cwallet.sso
前述のファイルは通常、Oracle WebLogic Serverドメイン・バックアップの一部としてバックアップされます。Oracle WebLogicドメイン・バックアップの詳細は、『Oracle Fusion Middlewareの管理』の次のトピックを参照してください。
第17.3項「バックアップの実行」
第18.2.2項「Oracle WebLogic Serverドメインのリカバリ」
この項には次のトピックが含まれます:
この項の手順では、アクティブなデータベース複製を可能にするOracle DatabaseクライアントのRecovery Manager (RMAN)を使用します。これは、バックアップ戦略とリカバリの自動化でも一般的に使用されるツールです。RMANの詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドの次のトピックを参照してください。
RMANの概要
データベースの完全リカバリの実行
次の手順では、ホストAにあるドメインのDBベースのセキュリティ・ストア・インスタンスをホストBのインスタンスにバックアップする方法を説明します。ここでは、ホストAのセキュリティ・ストアのjdbc urlがproddbに設定されていることが想定されており、その同じドメインで、jdbc urlがtestdb (ホストB)に設定されている(クローニングされた) DBベース・ストアを使用できるようにすることが目標です。
前述の想定でDBベースのセキュリティ・ストアをバックアップするには、次の手順を実行します。
次のように、ホストBのインスタンスtestdbを準備します。
新規インスタンス用のpfileを作成します。つまり、次の行の内容を持つinittestdb.oraファイルを作成します。
# db_name=testdb #
次の行に示すように、testdbをlistener.oraに追加します。
SID_LIST_LISTENER = (SID_LIST=(SID_DESC=(SID_NAME=testdb)(GLOBAL_DBNAME=testdb)(ORACLE_HOME=/ade/b/3882746433/oracle))
次の行に示すように、testdb/proddbをtnsnames.oraに追加します。
proddb=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hostA.com)(PORT=XXXX))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME= proddb)))
testdb=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hostB.com)(PORT=YYYY))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=testdb)))
次の行に示すように、リスナーを再起動します。
lsnrctl stop, lsnrctl start
次の行に示すように、nomountモードのpfileを使用して新規インスタンスを起動します。
$ export ORACLE_SID=testdb
$ sqlplus / as sysdba
SYS@testdb SQL>startup nomount pfile=/scratch/rdbms/dbs/inittestdb.ora
次のように、RMANを使用してproddbをtestdbにクローニングします。
次の行に示すように、testdb/proddbをtnsnames.oraに追加します。
proddb=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=myhostA.com)(PORT=XXXX))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME= proddb)))
testdb=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=myhostB.com)(PORT=YYYY))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=testdb)))
インスタンスproddbがspfileを使用していることを確認してください。そうでない場合は、sysdbaとしてログインし、create spfile from pfileを実行することで、初期化ファイルからバイナリspfileを生成します。次にサーバーを再起動します。
次の行に示すように、リスナーを再起動します。
lsnrctl stop, lsnrctl start
複製データベース・ファイルの名前の生成方法を決定します。具体的には、制御ファイル、データファイル、オンラインREDOログ・ファイルおよび一時ファイルの命名方法を決定します。
たとえば、proddbでは/oradata/proddbディレクトリにあるホストAのファイルを、ホストBの/oradata/testdbに保存する場合は、DB_FILE_NAME_CONVERT '/proddb',' /testdb'を次のシーケンスで指定します。
次の行に示すように、RMANを実行してproddbをtestdbにクローニングします。
$rman
RMAN> CONNECT TARGET SYS@proddb
RMAN> CONNECT AUXILIARY SYS@testdb
RMAN> DUPLICATE TARGET DATABASE TO testdb
FROM ACTIVE DATABASE
DB_FILE_NAME_CONVERT '/proddb','/testdb'
SPFILE
PARAMETER_VALUE_CONVERT '/proddb','/testdb'
SET LOG_FILE_NAME_CONVERT '/proddb','/testdb';
前述のRMANシーケンスが正常に実行されたことを確認してください。
(オプション)ドメインを切り替えて、バックアップされたばかりのデータベースをOPSSセキュリティ・ストアとして使用することで、バックアップ済のDBインスタンスtestdbが正しく機能することを確認します。
Oracle WebLogic Serverを停止します。
ファイル{domain}/config/fmwconfig/jps-config.xmlおよび{domain}/config/jdbc/*xmlで、jdbc urlをproddbからtestdbに変更します。
Oracle WebLogic Serverを再起動します。
ドメイン・セキュリティが正しく機能することを確認します。
バックアップ元のOracle Internet Directoryストアをバックアップ先のOracle Internet Directoryストアにバックアップするには、次の手順を実行します。
移行元のOracle Internet Directoryがあるシステムで、次の行に示すようにldifwriteを実行してLDIFファイルを生成します。
>ldifwrite connect="srcOidDbConnectStr" basedn="cn=jpsnode" ldiffile="srcOid.ldif"
このコマンドでは、ノードcn=jpsnode, c=us以下のすべてのエントリがファイルsrcOid.ldifに書き込まれます。このファイルを、次に実行するコマンドで使用できるように、バックアップ先のOracle Internet Directoryファイル・システムに移動します。
バックアップ先のOracle Internet Directoryシステムで、JPSスキーマがシードされていることを確認します。
移行元のOracle Internet Directoryシステムで、次の行に示すようにbulkloadを実行してスキーマ・エラーや不適切なエントリがないことを確認します。
>bulkload connect="dstOidDbConnectStr" check=true generate=true restore=true file="fullPath2SrcOidLdif"
重複するDN(バックアップ元のディレクトリとバックアップ先のディレクトリとの間で共通するエントリ)が検出された場合は、予期しない結果が生じないようにそれらのDNを確認します。
次の行に示すようにbulkloadを実行して、移行先のOracle Internet Directoryにデータをロードします。
>bulkload connect="dstOidDbConnectStr" load=true file="fullPath2SrcOidLdif"
前述のコマンドの詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の次のトピックを参照してください。
第15.6項「ldifwriteを使用したOracle Internet Directoryからファイルへのデータのダンプ」
第37.2.1項「LDIFファイルとbulkloadを使用したLDAPデータの移行」
企業で設定したスケジュールに従って、定期的にOPSSセキュリティ・ストアをバックアップすることをお薦めします。また、次のイベントが発生した直後は、予定外のバックアップを実行してください。
ドメイン用の新しい暗号化キーの(自動)生成
新しいポリシーの作成
新しいバインディング資格証明の設定
監査スキーマ・アップグレード・ツールについて
リリース11g監査モデルを使用しているコンポーネントでは、AuditSchemaUpgradeToolオフライン・ツールを使用して、監査定義をリリース12cで使用されている動的メタデータ・モデルにアップグレードできます。
ツールの構文
構文は次のとおりです:
java -classpath $MW_HOME/oracle_common/modules/oracle.jps_12.1.3/jps-manifest.jar oracle.security.audit.tools.AuditSchemaUpgradeTool -s source_file -t target_file_or_directory [, -v component_def_version]
説明:
source_fileはリリース11g監査イベント定義ファイルです(例: component_events.xml)。
target_file_or_directoryは、a)生成された12g動的モデル定義ファイルの格納先ファイル、またはb)ターゲット・ディレクトリのいずれかです。生成された動的モデル定義ファイルはデフォルト・ファイル名source_file_dynamic.xmlでここに保存されます。
component_def_versionは生成された12c定義のバージョン番号です。指定されていない場合のデフォルト値は1.0です。
例
次の例は、デフォルトのバージョン番号を使用し、ターゲット・ファイルcomponent_events_JPS.xmlを指定して、OPSSコンポーネント定義をリリース12c動的モデルにアップグレードしています。
java -classpath $MW_HOME/oracle_common/modules/oracle.jps_12.1.3/jps-manifest.jar oracle.security.audit.tools.AuditSchemaUpgradeTool -s component_events.xml -t component_events_OPSS.xml
次の例は、バージョン番号とターゲット・ディレクトリを指定して、OPSSコンポーネント定義をリリース12c動的モデルにアップグレードしています。ツールはデフォルト・ターゲット・ファイルcomponent_events_dynamic.xmlを使用します。
java -classpath $MW_HOME/oracle_common/modules/oracle.jps_12.1.3/jps-manifest.jar oracle.security.audit.tools.AuditSchemaUpgradeTool -s component_events.xml -t /scratch/example -v 2.0
注意
このツールは、コンポーネント定義を1つのみ含むリリース11g監査定義ファイルをサポートします。
リリース11g component_events.xmlファイルにコンポーネントのdisplayNameがある場合は、アップグレードの前にAuditConfig属性として追加する必要があります。例:
<AuditConfig componentType="SOA-HCFP" xmlns="http://xmlns.oracle.com/ias/audit/audit.xsd" displayName="Oracle SOA Suite for healthcare integration">
それ以外の場合、コンポーネントがdisplayNameを必要とする場合は、アップグレード後に、displayNameを手動で更新する必要があります。たとえば、ターゲット・イベント定義ファイルではAuditComponentノードに次のようなdisplayNameを付けることができます。
<AuditComponent minor="0" major="1" componentType="SOA-HCFP" displayName="Oracle SOA Suite for healthcare integration">
