Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 12c (12.2.1) E72537-01 |
|
前 |
次 |
この章では、WebLogic Serverドメインの作成または拡張時に、アプリケーションでセキュリティ・ストアにシードすることを指定できるセキュリティ・アーティファクトについて説明します。また、セキュリティ・ストアをリリース12.2.1にアップグレードする手順についても説明します。
この章の内容は次のとおりです。
11gドメインでは、デプロイメント・ディスクリプタが適切に設定されている場合、製品固有のセキュリティ・アーティファクトの指定はアプリケーションのエンタープライズ・アーカイブ(EAR)ファイルにバンドルされ、それらのアーティファクトはアプリケーションのデプロイ時にセキュリティ・ストアに移行されます。
12cドメインでは、製品固有のセキュリティ・アーティファクトの指定は、それらのアーティファクトをドメインの作成時にセキュリティ・ストアにシードする手段となる製品テンプレートで構成されます。
FMWドメインは、Java Required Files (JRF)テンプレートを使用して作成または拡張されたドメインです。テンプレートにより、セキュリティ・ストアのアーティファクトのプロビジョニングが指定されます。具体的には、次のものが作成されます。
OPSSセキュリティ・アーティファクト。
暗号化鍵でシードされるcwallet.sso
ブートストラップ・ファイル。
キーストア(トラストストア、デモ・キーストア、Oracle WebLogic Serverで使用されるドメイン・アイデンティティ・キーストアを含む)。
トラストストアに接続されたトラスト・サービス。
3つのデータ・ソース: OPSSスキーマ、OPSS監査ビューア・スキーマ、OPSS監査追加スキーマそれぞれに1つずつ。
データベース・セキュリティ・ストアおよび監査ストアの構成。
JRFテンプレートでは、管理対象サーバーは作成されません。FMWドメインでは、すべてのリソースが管理サーバーにのみターゲット設定されます。後で管理対象サーバーをドメインに追加する場合は、リソースがその管理対象サーバーにもターゲット設定されるようにapplyJRF
をコールする必要があります。
ドメイン再構成後にOPSSおよび監査データ・ソースを管理対象サーバーにターゲット設定するには、applyJRF
WebLogic Scripting Tool (WLST)コマンドを使用します。
関連項目: 『Oracle Fusion Middlewareインフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のapplyJFRに関する項 |
本番用のFMWドメインにはDBセキュリティ・ストアが必要です。データベースは、新しいデータベースでも、他のFMWドメインに関連付けられたデータベースでもかまいません。
次の各項では、FMWドメインの作成方法について説明します。
新しいデータベースに関連付けられたFMWドメインを作成または拡張するには、次の手順を実行します。
新しいデータベース・スキーマを作成します。DBセキュリティ・ストアの詳細は、第9.3.1項「DBセキュリティ・ストアを使用する場合の前提条件」を参照してください。
『Oracle Fusion Middleware構成ウィザードによるWebLogicドメインの作成』の第5章「構成ウィザード画面」で説明されているように、Fusion Middleware構成ウィザードを使用してドメインを作成または拡張します。
このタスクでは、手順1で作成したデータベース・スキーマなど、使用するデータベース・スキーマに関する情報を指定したり、JFRテンプレートの使用を選択します。作成したドメインに関連付けるデータベース・スキーマは新しいスキーマである必要があります。
JRFテンプレートを使用すると、3つのデータ・ソース(OPSSスキーマ、OPSS監査ビューア・スキーマ、OPSS監査追加スキーマそれぞれに1つずつ)が自動的に作成されます。
次の手順では、WLSTコマンドのみを使用します。ドメイン・データベースに関連付けられたFMWドメインを作成または拡張するには、次の手順を実行します。
domain1
ドメインで(他のドメインを結合する)db1
データベースを使用しているとした場合、exportEncryptionKey
コマンドを使用して、domain1
ドメインから指定された場所に暗号化鍵をエクスポートします。
exportEncryptionKey(location, password)
次のようなスクリプトを使用して、db1
データベースを共有するドメインを作成します。
## 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
コマンドへのコールで使用した値と同じです。
スクリプトを実行して、domain1
および新しいドメイン内のサーバーをすべて起動します。どちらのドメインも同じセキュリティ・ストアを共有しています。
注意: スクリプトからsetSharedSecretStoreWithPassword で始まる行を削除すると、domain1 などのFMWドメインの作成に使用できることがあります。 |
関連項目: 『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のexportEncryptionKeyに関する項 |
セキュリティ・アーティファクトのシードおよび処理を簡略化するには、ドメインの作成または拡張時に、OPSSを使用するコンポーネントによってテンプレートが指定される必要があります。このテンプレートは、コンポーネントの実行に必要な、コンポーネントのみに固有のアーティファクトを定義およびバンドルし、表7-1に示すファイルを含みます。
表7-1 OPSSで使用されるコンポーネント・テンプレートのファイル
ファイル名 | 説明 | テンプレートのルート・フォルダからの場所 |
---|---|---|
|
必須。セキュリティ・アーティファクトのライフ・サイクルを指定します。 |
./security/component-security-info.xml |
|
オプション。ポリシーを指定します。 |
./security/authorization/jazn-data.xml |
|
オプション。キーストアのメタデータを指定します。 |
./security/keystore/keystore.xml |
|
オプション。コンポーネントで使用される資格証明メタデータを指定します。 |
./security/credential/credentials.xml |
|
オプション。監査データを指定します。 |
./security/audit/component_events.xml |
|
オプション。ローカライズされた監査データを指定します。 |
./security/audit/component_events_xlf.jar |
製品テンプレートにバンドルされたOPSSセキュリティ・アーティファクトには、アーティファクトの処理方法を指定するcomponent-security-info.xml
ファイルが必要です。
次の各項では、セキュリティ・アーティファクトをリリース11.1.1.6、11.1.1.7、11.1.1.9、12.1.2または12.1.3からリリース12.2.1にアップグレードする方法について説明します。
アップグレード後のシステムでは、古いデータ・ソースを使用せず、新しく作成されたデータ・ソースのみを使用します。11gからアップグレードすると、重複するOPSSデータ・ソースが表示されることがありますが、一方はアップグレード前から存在し、もう一方はアップグレードによって作成されたものです。この重複は機能的に影響することはなく、古いデータ・ソースはアップグレード後のシステムで使用されません。
アップグレード後に、キーストアをJavaキーストア(JKS)からキーストア・サービス(KSS)キーストアに移行することを検討してください。12.2.1にアップグレードしたドメインでは、system
ストライプのKSSキーストアは以前のリリースのものとは異なります。証明書の詳細は、第12.4項「証明書について」を参照してください。
セキュリティ・ストアをアップグレードする前に、アップグレードに失敗した場合にリカバリできるようバックアップを作成します。バックアップの詳細は、「セキュリティ・ストアのバックアップとリカバリ」を参照してください。
この項に記載されている手順を実行して、FMWの古いバージョンがリリース12.2.1.0.0へのアップグレードに適しているかどうかを判断します。次の手順ではアップグレードは実行されません。
アップグレード・アシスタントを起動します。
> cd oracle_common/upgrade/bin > ./ua-readiness
左側のペインで「選択したスキーマ」をクリックします。
「選択したスキーマ」ページで、「個別に選択されたスキーマ」を選択して「次」をクリックします。
「使用可能なコンポーネント」ページで、「Oracle Platform Security Services」を選択して「次」をクリックします。
「ドメイン・ディレクトリ」で、ドメインのディレクトリを入力します。
必要に応じて、IAUスキーマおよびOPSSスキーマの情報を入力します。
左側のペインで「準備状況サマリー」をクリックします。「準備状況サマリー」ページに、チェック対象のスキーマの詳細が表示されます。
「次」をクリックします。「準備状況チェック」ページに、チェックの進行状況および最終ステータスが表示されます。
エラーがレポートされた場合は、ログ出力を確認します。問題が12.2.1へのアップグレードで修正されることがログに示されている場合は、そのエラーを無視します。
「準備状況成功」ページに、チェック結果が表示されます。
次の各表は、セキュリティ・ストアおよび監査ストアのタイプに応じて、システムをアップグレードするために実行する手順をまとめたものです。いずれの手順でも、バイナリが12.2.1 Oracle Fusion Middlewareバイナリにアップグレードされていることを前提としています。
表7-2 12.1.2または12.1.3から12.2.1へのアップグレード
セキュリティ・ストア・タイプ | 監査ストア・タイプ | 12.2.1へのアップグレード手順 |
---|---|---|
Oracle Internet Directory |
DB |
|
DB |
DB |
|
注意: 12cファイル・セキュリティ・ストアからのアップグレードはサポートされていません。 |
表7-3 11.1.1.6、11.1.1.7または11.1.1.9から12.2.1からのアップグレード
セキュリティ・ストア・タイプ | 監査ストア・タイプ | 12.2.1へのアップグレード手順 |
---|---|---|
ファイル |
ファイル |
|
ファイル |
DB |
|
Oracle Internet Directory |
ファイル |
|
Oracle Internet Directory |
DB |
|
DB |
ファイル |
|
DB |
DB |
|
注意: 11gファイル・セキュリティ・ストアは、DBセキュリティ・ストアに自動的にアップグレードされます。 |
12.2.1リポジトリ作成ユーティリティを実行して、スキーマを作成します。手順の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。
この項に記載されている手順を実行してスキーマをアップグレードします。代替手順の「アップグレード・アシスタントを使用したスキーマのアップグレード」では、少ないユーザー入力で同じ結果になりますが、既存のスキーマが必要となることに注意してください。
アップグレード・アシスタントを起動します。
> cd oracle_common/upgrade/bin > ./ua
左側のペインで「スキーマ」をクリックします。
「スキーマ」ページで、「スキーマ」を選択して「次」をクリックします。
「使用可能なコンポーネント」ページで、「Oracle Platform Security Services」を選択して「次」をクリックします。
「前提条件」ページで、示された前提条件がすべて満たされていることを確認して「次」をクリックします。
必要に応じて、IAUスキーマおよびOPSSスキーマの情報を入力してから、入力内容を確認します。
左側のペインで「アップグレード・サマリー」をクリックします。「アップグレード・サマリー」ページに、アップグレードされるスキーマが表示されます。
「アップグレード」をクリックします。「アップグレードの進行状況」ページに、アップグレードの進行状況および最終ステータスが表示されます。
「アップグレード成功」ページに、アップグレード結果が表示されます。
関連項目: Oracle Fusion Middleware Upgrade Assistantによるアップグレード |
ドメイン支援スキーマ・アップグレード(DASU)を使用すると、ドメイン・ディレクトリからスキーマの詳細を自動的にロードできるため、そのようなスキーマの詳細を入力する必要がありません。
この項に記載されている手順を実行して、DASUモードでスキーマをアップグレードします。
アップグレード・アシスタントを起動します。
> cd oracle_common/upgrade/bin > ./ua
左側のペインで「スキーマ」をクリックします。
「スキーマ」ページで、「ドメインで使用されるすべてのスキーマ」を選択してスキーマの詳細のロード元となるドメイン・ディレクトリを入力し、「次」をクリックします。
「コンポーネント・リスト」ページで、コンポーネント・スキーマを表示して「次」をクリックします。
「アップグレードの進行状況」ページに、アップグレードの進行状況および最終ステータスが表示されます。
「アップグレード成功」ページに、アップグレード結果が表示されます。
この項に記載されている手順を実行し、Fusion Middleware再構成ウィザードを使用してドメインを再構成します。
Fusion Middleware再構成ウィザードを起動します。
> cd oracle_common/common/bin > ./reconfig.sh
「ドメインの選択」ページで、再構成するドメインのディレクトリを指定して「次」をクリックします。
「データベース構成タイプ」ページで「RCUデータ」ラジオ・ボタンを選択し、データベース接続の詳細を入力して「RCU構成の取得」をクリックします。取得結果が表示されます。
「次」をクリックします。
「JDBCコンポーネント・スキーマ」ページに、影響を受けるスキーマの表が表示されます。必要に応じて行を選択し、「次」をクリックします。
「JDBCコンポーネント・スキーマ・テスト」ページで「選択された接続のテスト」をクリックします。テスト結果が表示されます。「次」をクリックします。
「拡張構成」ページで、必要に応じてボックスを選択して「次」をクリックします。
「構成サマリー」に、選択したオプションが表示されます。「再構成」をクリックします。
複数のドメインが共有(結合)しているセキュリティ・ストアをアップグレードするには、次のタスクのいずれかを実行します。
この項に記載されている手順を実行し、12.1.2または12.1.3の共有しているセキュリティ・ストアを12.2.1にアップグレードします。
アップグレードするストアを共有しているドメインをすべて停止します。
アップグレード・アシスタントを実行し、共有しているセキュリティ・ストアのOPSSスキーマと、ソース監査データがデータベース・ストアの場合は監査スキーマをアップグレードします。「アップグレード・アシスタントを使用したスキーマのアップグレード」を参照してください。
セキュリティ・ストアを共有しているドメインそれぞれで、Fusion Middleware再構成ウィザードを実行してドメインを再構成し、OPSSデータ、ディレクトリ情報ツリーおよび製品のセキュリティ・アーティファクトをアップグレードします。「Fusion Middleware再構成ウィザードを使用したドメインの再構成」を参照してください。
セキュリティ・ストアを共有しているドメインをすべて再起動します。
この項に記載されている手順を実行し、11.1.1.6、11.1.1.7または11.1.1.9の共有しているセキュリティ・ストアを12.2.1にアップグレードします。
アップグレードするストアを共有しているドメインをすべて停止します。
アップグレード・アシスタントを実行し、共有しているセキュリティ・ストアのOPSSスキーマと、ソース監査がデータベース・ストアの場合は監査スキーマをアップグレードします。「アップグレード・アシスタントを使用したスキーマのアップグレード」を参照してください。
セキュリティ・ストアを共有しているドメインのそれぞれで、Fusion Middleware再構成ウィザードを実行します。初めて実行すると、セキュリティ・ストアのデータおよびドメインの構成がアップグレードされます。他のドメインから実行すると、そのドメインの構成のみアップグレードされます。「Fusion Middleware再構成ウィザードを使用したドメインの再構成」を参照してください。
アップグレードされたドメインをすべて再起動します。
この項では、セキュリティ・ストアをバックアップおよびリカバリする方法について説明します。セキュリティ・ストアのバックアップに加えて、次の構成ファイルおよびデータ・ファイルも保存する必要があることに注意してください。
{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
この項には次のトピックが含まれます:
注意: migrateSecurityStore WLSTコマンドを使用して、セキュリティ・データをバックアップおよびリカバリできます。セキュリティ・データをバックアップするには、セキュリティ・データをファイル・ストアに移行します。リカバリするには、ファイル・ストアをターゲット・セキュリティ・ストアに移行します。 |
関連項目: 『Oracle Fusion Middlewareの管理』のバックアップの実行に関する項 『Oracle Fusion Middlewareの管理』のOracle WebLogic Serverドメインのリカバリに関する項 |
この項に記載されている手順では、バックアップ計画およびリカバリの自動化とデータベースの複製に使用するツールであるOracle Database Utility Recovery Manager (RMAN)を使用します。
次の手順を使用してホストAのDBセキュリティ・ストアをホストBのDBセキュリティ・ストアにバックアップします。ホストAのセキュリティ・ストアではjdbc
URLがproddb
に設定されており、ホストBのセキュリティ・ストアではjdbc
URLがtestdb
に設定されています。この手順では、ホストBのクローニングされたDBセキュリティ・ストアと連動するようにドメインを設定します。
DBセキュリティ・ストアをバックアップするには、次の手順を実行します。
ホストBでtestdb
データベースを設定します。
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
を実行し、init
ファイルからバイナリspfile
を生成します。次にサーバーを再起動します。
リスナーを再起動します。
lsnrctl stop, lsnrctl start
複製データベース・ファイルの名前を生成する方法を決定します。具体的には、制御ファイル、データ・ファイル、オンラインREDOログ・ファイルおよび一時ファイルに名前を付ける方法を決定します。
たとえば、proddb
データベースでは、ホストAのディレクトリ/oradata/proddb
にあるファイルを、ホスト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がエラーなしで完了したことを確認します。
ドメインを切り替えて、バックアップしたデータベースをセキュリティ・ストアとして使用することで、testdb
データベースが予期したとおりに機能することを確認します。
WebLogic Serverを停止します。
{domain}/config/fmwconfig/jps-config.xml
ファイルおよび{domain}/config/jdbc/*xml
ファイルで、jdbc
URLをproddb
からtestdb
に変更します。
WebLogic Serverを再起動します。
ドメイン・セキュリティが正しく機能することを確認します。
この項に記載されている手順を使用し、ソースLDAPストアをターゲットLDAPストアにバックアップします。
ソースLDAPシステムで、ldifwrite
を実行してLDAPデータ交換形式(LDIF)ファイルを作成します。
>ldifwrite connect="srcOidDbConnectStr" basedn="cn=jpsnode" ldiffile="srcOid.ldif"
このコマンドでは、cn=jpsnode, c=us
ノード下のすべてのエントリがsrcOid.ldif
ファイルに書き込まれます。
このファイルをターゲットLDAPシステムに移動します。
ターゲットLDAPシステムで、スキーマがシードされていることを確認します。
ターゲットLDAPシステムで、bulkload
を実行してスキーマ・エラーや不適切なエントリがないことを確認します。
>bulkload connect="dstOidDbConnectStr" check=true generate=true restore=true file="fullPath2SrcOidLdif"
重複する識別名(ソース・ディレクトリとターゲット・ディレクトリとの間で共通するエントリ)が検出された場合は、予期しない結果が生じないようにその識別名を確認します。
bulkload
を実行して、ターゲットLDAPにデータをロードします。
>bulkload connect="dstOidDbConnectStr" load=true file="fullPath2SrcOidLdif"
関連項目: 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の次の項
|
企業に適したスケジュールに従って、定期的にセキュリティ・ストアをバックアップすることをお薦めします。また、ドメインに対して新しい暗号化鍵が(自動的に)生成されたり、ポリシーや資格証明など新しいセキュリティ・データを作成した後には、すぐにスケジュール外のバックアップをお薦めします。
監査静的モデルを使用しているコンポーネントでは、AuditSchemaUpgradeTool
を使用して、リリース12cで使用されている監査動的モデルに監査定義をアップグレードできます。このツールは、コンポーネント定義を1つしか含まない監査静的定義ファイルをサポートします。
コンポーネントをアップグレードする前に、displayName
コンポーネントをcomponent_events.xml
ファイルのAuditConfig
プロパティに追加します。
<AuditConfig componentType="SOA-HCFP" xmlns="http://xmlns.oracle.com/ias/audit/audit.xsd" displayName="Oracle SOA Suite Integration">
構文
java -classpath $MW_HOME/oracle_common/modules/oracle.jps_12.2.1/jps-manifest.jar oracle.security.audit.tools.AuditSchemaUpgradeTool -s source_file -t target_file_or_directory [, -v component_def_version]
説明:
source_file
は、component_events.xml
などの監査定義ファイルです。
target_file_or_directory
は、a) 12g定義ファイルの格納先ファイル、またはb) ターゲット・ディレクトリで、このディレクトリにモデル定義ファイルがデフォルト・ファイル名source_file_dynamic.xml
で格納されます。
component_def_version
は生成された12c定義のバージョン番号です。指定しない場合は、デフォルトの1.0に設定されます。
例
次の例では、デフォルトのバージョン番号とターゲット・ファイルcomponent_events_OPSS.xml
を使用して、OPSSコンポーネント定義をリリース12c動的モデルにアップグレードする方法を示します。
java -classpath $MW_HOME/oracle_common/modules/oracle.jps_12.2.1/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.2.1/jps-manifest.jar oracle.security.audit.tools.AuditSchemaUpgradeTool -s component_events.xml -t /scratch/example -v 2.0