| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 11gリリース1 (11.1.1) E64849-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護 11gリリース1 (11.1.1) E64849-03 |
|
前 |
次 |
この付録では、セキュリティ・データを更新するいくつかの手順について説明します。具体的には、メジャー・リリース(10.1.3.x)からメジャー・リリース(11.1.1)へのセキュリティ・データのアップグレード方法、およびマイナー・リリース(11.1.1.2.0など)から現行のマイナー・リリースへのデータのアップグレード方法について、次の各項で説明します。
OPSSスクリプトupgradeSecurityStoreは、以前のメジャー・リリース(10.1.1.3など)から現行のメジャー・リリース(11.1.1.1.0)にアプリケーション・セキュリティ・データをアップグレードする場合にのみ使用します。11gのマイナー・リリース間でのアップグレードには、「upgradeOpssを使用したOPSSセキュリティ・ストアのアップグレード」で説明しているように、upgradeOpssを使用してください。
アップグレードの対象がLDAPベースのリポジトリの場合には、スクリプトを実行する前にいくつかの設定が必要になります。第8.3.1項「LDAPベースのセキュリティ・ストアを使用する場合の前提条件」を参照してください。
このスクリプトはオフラインです。つまり、実行中のサーバーに接続しなくても動作し、WebLogicではインタラクティブ・モードまたはスクリプト・モードで、WebSphereではインタラクティブ・モードでのみ実行できます。インタラクティブ・モードの場合は、コマンドライン・プロンプトにスクリプトを入力すると、応答が即座に表示されます。スクリプト・モードの場合、スクリプトはテキスト・ファイルに記述し、シェル・スクリプトのディレクティブのように入力なしで実行できます。
OPSSスクリプトを実行するためのプラットフォーム固有の要件については、第9.4項「WLSTコマンドを使用したアプリケーション・ポリシーの管理」を参照してください。
スクリプト・モードおよびインタラクティブ・モードの構文
スクリプト構文は、アップグレードされるストアのタイプによって異なります。オプションの引数は角カッコで囲まれています。スクリプト・モードの構文では、わかりやすいように引数が別々の行に記述されています。
10.1.3.x XMLのアイデンティティ・データを11g リリース1 (11.1.1) XMLのアイデンティティ・データにアップグレードするには、次のいずれかの構文を使用します。
updateSecurityStore -type xmlIdStore
-jpsConfigFile jpsConfigFileLocation
-srcJaznDataFile srcJazn
-srcRealm jaznRealm
[-dst dstJpsContext]
updateSecurityStore(type="xmlIdStore", jpsConfigFile="jpsConfigFileLocation", srcJaznDataFile="srcJazn", srcRealm="jaznRealm", [dst="dstJpsContext"])
10.1.3.x XMLのポリシー・データを11g リリース1 (11.1.1) XMLのポリシー・データにアップグレードするには、次のいずれかの構文を使用します。
updateSecurityStore -type xmlPolicyStore
-jpsConfigFile jpsConfigFileLocation
-srcJaznDataFile srcJazn
[-dst dstJpsContext]
updateSecurityStore(type="xmlPolicyStore", jpsConfigFile="jpsConfigFileLocation", srcJaznDataFile="srcJazn", [dst="dstJpsContext"])
10.1.3.x Oracle Internet DirectoryのLDAPベースのポリシー・データを11g リリース1 (11.1.1) XMLのポリシー・データにアップグレードするには、次のいずれかの構文を使用します。
updateSecurityStore -type oidPolicyStore
-jpsConfigFile jpsConfigFileLocation
-srcJaznConfigFile srcJazn
[-dst dstJpsContext]
updateSecurityStore(type="oidPolicyStore", jpsConfigFile="jpsConfigFileLocation", srcJaznConfigFile="srcJazn", [dst="dstJpsContext"])
ファイルベースのアプリケーション・ポリシーをリリース11.1.1.1.0からリリース11.1.1.2.0にアップグレードするには、次のいずれかの構文を使用します。
updateSecurityStore -type xmlAppPolicies
-srcApp applicationStripeName
-jpsConfigFile jpsConfigFileLocation
-srcJaznDataFile srcJazn
-dstJaznDataFile dstJazn
-resourceTypeFile resTypeJazn
updateSecurityStore(type="xmlAppPolicies", srcApp="applicationStripeName", jpsConfigFile="jpsConfigFileLocation", srcJaznDataFile="srcJazn", dstJaznDataFile="dstJazn", srcJaznDataFile="resTypeJazn")
11.1.1.1.0のアプリケーション・ポリシーを11.1.1.2.0形式にアップグレードするには、次のいずれかの構文を使用します。
updateSecurityStore -type appPolicies
-srcApp applicationStripeName
-jpsConfigFile jpsConfigFileLocation
-dst dstContext
[-resourceTypeFile resTypeJazn]
updateSecurityStore(type="appPolicies", srcApp="applicationStripeName", jpsConfigFile="jpsConfigFileLocation", dst="dstContext" [, resourceTypeFile="resTypeJazn"])
このアップグレードは所定の位置で動作し、指定したリソース・タイプ、および権限内のパーミッションに対応するリソースが作成されます。
実行が完了したら、jpsConfigFileで渡された構成ファイル内のdstで渡されたコンテキストによって指定されたポリシー・ストアには、srcAppで渡されたアプリケーションに対して定義された新しいリソース・タイプと新しいリソースが格納されます。リソース・タイプはresourceTypeFileで指定されたファイルから読み取られ、リソースはアプリケーション権限内のパーミッションに対応して作成されます。
引数の意味は、次のとおりです。
typeは、アップグレードするセキュリティ・データの種類を指定します。有効な値は、xmlIdStore、xmlPolicyStore、oidPolicyStore、xmlCredStore、xmlAppPoliciesおよびappPoliciesのみです。
jpsConfigFileでは、構成ファイルjps-config.xmlの位置を、このスクリプトを実行するディレクトリを基準とした相対パスで指定します。アップグレードのターゲット・ストアは、引数dstで指定したコンテキストから読み取られます。
typeがxmlAppPoliciesの場合、構成ファイルは、ソースやターゲットの参照では使用されず、監査サービスの構成でのみ使用されます。監査サービスがjps-config.xmlファイルで指定されていない場合でも、その場所を渡す必要があることに注意してください。
srcJaznDataFileでは、10.1.3.x jazn-data.xmlファイルの位置を、このスクリプトを実行するディレクトリを基準とした相対パスで指定します。指定したtypeがxmlIdStore、xmlPolicyStoreまたはxmlCredStoreの場合、この引数は必須です。
指定したtypeがxmlAppPoliciesの場合、この引数はアプリケーション11.1.1.1.0のjazn-data.xmlファイルの場所を指定します。このファイルにはリソース・タイプの指定はありません。
srcJaznConfigFileでは、10.1.3.x jazn構成ファイルの位置を、このスクリプトを実行するディレクトリを基準とした相対パスで指定します。指定したtypeがoidPolicyStoreの場合、この引数は必須です。
usersは、それぞれrealmName/userNameという形式で表されたユーザーのカンマ区切りリストを指定します。指定したtypeがxmlCredStoreの場合、この引数は必須です。
srcRealmは、引数srcJaznDataFileで渡されるファイル内の、移行するアイデンティティを識別するレルム名を指定します。指定したtypeがxmlIdStoreの場合、この引数は必須です。
dstは、引数jpsConfigFileで渡されるファイル内の、宛先ストアを構成しているjpsContextの名前を指定しますオプション。指定しない場合は、デフォルトのjpsContextが使用されます。
srcAppでは、アプリケーション・ストライプを指定します。これは、srcJaznDataFileファイルおよびresourceTypeFileファイルに存在するアプリケーション名と一致する必要があります。この名前のストライプは、dstJaznDataFileファイルで作成します。
dstJaznDataFileでは、アプリケーション11.1.1.2.0のjazn-data.xmlファイルの場所を指定します。このファイルは、リソース・タイプとリソース・インスタンスを指定しており、srcJaznDataFileで指定した元のjazn-data.xmlにかわるものです。
resourceTypeFileでは、リソース・タイプを指定している11.1.1.2.0 jazn-data.xmlファイルの場所を指定します。
dstでは、更新するポリシー・ストアを指定している宛先コンテキストを指定します。
次の各項には、様々なシナリオでのスクリプトupgradeSecurityStoreの使用を示した例が記載されています。
次のコマンドを起動すると、10.1.3のファイルベースのアイデンティティが11g リリース1 (11.1.1)のファイルベースのアイデンティティ・ストアに移行します。
upgradeSecurityStore -type xmlIdStore
-jpsConfigFile jps-config-idstore.xml
-srcJaznDataFile jazn-data.xml
-srcRealm jazn.com
このスクリプトの使用では、(a)ファイルjps-config-idstore.xmlおよびjazn-data.xmlが、スクリプトが実行されているディレクトリに格納されていること、(b)ファイルjps-config-idstore.xml内のデフォルトのjpsContextがターゲットのアイデンティティ・ストアを参照していること、および(c)ファイルjazn-data.xmlにjazn.comという名前のレルムが含まれていることを前提としています。
上のサンプルで使用されている2つのファイルから関連する部分を抜粋したものを次に示します。
<!-- excerpt from file jps-config-idstore.xml -->
<serviceProviders>
<serviceProvider name="R11idstore" class="oracle.security.jps.internal.idstore.xml.XmlIdentityStoreProvider" type="IDENTITY_STORE">
<description>11g XML-based IdStore</description>
</serviceProvider>
</serviceProviders>
...
<serviceInstances>
<serviceInstance name="idstore.xml1" provider="R11idstore" location="./jazn-data-11.xml">
<property name="subscriber.name" value="jazn.com"/>
<property name="jps.xml.idstore.pwd.encoding" value="OBFUSCATE"/>
</serviceInstance>
</serviceInstances>
...
<jpsContexts default="default">
<jpsContext name="default">
<serviceInstanceRef ref="idstore.xml1" />
</jpsContext>
</jpsContexts>
<!-- excerpt from jazn-data.xml -->
<jazn-realm>
<realm>
<name>jazn.com</name>
<users> ... </users>
<roles> ... </roles>
</realm>
</jazn-realm>
このサンプルを実行すると、要素<users>内のすべてのユーザーがXMLアイデンティティ・ストアR11idStoreに移行します。
次のコマンドを起動すると、10.1.3のファイルベースのポリシー・ストアが11g リリース1 (11.1.1)のポリシー・ストアに移行します。
upgradeSecurityStore -type xmlPolicyStore
-jpsConfigFile jps-config.xml
-srcJaznDataFile jazn-data.xml
-dst destContext
このスクリプトの使用では、ファイルjps-config.xmlおよびjazn-data.xmlが、スクリプトが実行されているディレクトリに格納されていること、ファイルjps-config.xmlにdestContextという名前のjpsContextが含まれていることを前提としています。
上のサンプルで使用されている2つのファイルから関連する部分を抜粋したものを次に示します。
<!-- excerpt from file jps-config.xml -->
<serviceProviders>
<serviceProvider type="POLICY_STORE" name="policystore.xml.provider" class="oracle.security.jps.internal.policystore.xml.XmlPolicyStoreProvider">
<description>R11 XML-based PolicyStore Provider</description>
</serviceProvider>
</serviceProviders>
...
<serviceInstances>
<serviceInstance name="policystore1.xml" provider="policystore.xml.provider">
<property name="R11PolStore" value="jazn-data1.xml"/>
</serviceInstance>
...
<jpsContexts default="default1">
<jpsContext name="default1"> ... </jpsContext>
<jpsContext name="destContext">
...
<serviceInstanceRef ref="policystore1.xml"/>
</jpsContext>
</jpsContexts>
<!-- excerpt from jazn-data.xml -->
<jazn-realm>
<realm>
...
<roles> ... </roles>
</realm>
</jazn-realm>
...
<jazn-policy> ... </jazn-policy>
このサンプルを起動すると、要素<roles>内のすべてのロールと要素<jazn-policy>内のすべてのポリシーがXMLポリシー・ストアR11PolStoreに移行します。
次のように起動すると、10.1.4 Oracle Internet DirectoryのLDAPベースのポリシー・ストアが11g リリース1 (11.1.1) Oracle Internet DirectoryのLDAPベースのポリシー・ストアにアップグレードします。
upgradeSecurityStore -type oidPolicyStore
-jpsConfigFile jps-config.xml
-srcJaznConfigFile jazn.xml
-dst destContext
この例に含まれる2つのXMLファイルの場所についての前提は、例2の場合とほぼ同じですこの他に、(a)ターゲットのOracle Internet Directory LDAPベースのポリシー・ストアを指すjpsContext destContextがファイルjps-config.xmlに含まれていること、および(b)移行するポリシーのOracle Internet Directory LDAPサーバーの場所がファイルjazn.xmlに記述されていることを前提としています。
ファイルjazn.xmlから関連する部分を抜粋したものを次に示します。
<jazn provider="LDAP" location="ldap://myCompany.com:3843"> <property name="ldap.user" value="cn=orcladmin"/> <property name="ldap.password" value="!welcome1"/> <property name="ldap.protocol" value="no-ssl"/> <property name="ldap.cache.policy.enable" value="false"/> <property name="ldap.initctx" value="com.sun.jndi.ldap.LdapCtxFactory"/> </jazn>
次のサンプルを実行すると、アプリケーション11.1.1.1.0のファイルベースのポリシー・ストアがアプリケーション11.1.1.2.0のファイルベースのポリシー・ストアにアップグレードされます。
updateSecurityStore -type xmlAppPolicies
-srcApp PolicyServlet1
-jpsConfigFile ./folder/jps-config.xml
-srcJaznDataFile ./11.1.1.1.0/jazn-data.xml
-dstJaznDataFile ./11.1.1.2.0/final-jazn-data.xml
-resourceTypeFile ./resCat/res-jazn-data.xml
このアップグレードの重要な点は、元の11.1.1.1.0ファイルではリソース・カタログの要素が使用されていませんが、アップグレード後の11.1.1.2.0ファイルではリソース・タイプおよびリソース・インスタンスの要素が使用されることです。
このスクリプトでは、基本的に元のアプリケーションの構成ファイルとリソース・タイプの要素を指定する別のファイルを取得して新しい構成ファイルを作成します。この新しい構成ファイルは、元のファイルと同様にポリシーを指定していますが、リソース・カタログの指定を使用するように変更されています。
元の構成ファイルと新しいアプリケーション構成ファイルのアプリケーションに対する動作はまったく同じです。
このサンプルの実行では、次のことが前提となっています。
ソース・ファイル./11.1.1.1.0/jazn-data.xmlでアプリケーションPolicyServlet1のポリシーを指定しています。
リソース・タイプ・ファイル./resCat/res-jazn-data.xmlでアプリケーションPolicyServlet1のリソース・タイプを指定しています。
構成ファイル./folder/jps-config.xmlは任意の有効な構成ファイルで、監査サービス・インスタンスを使用していても、使用していなくてもかまいません。いずれの場合も、監査サービスを指定する必要があります。
次のサンプルは、3つのデータ・ファイル(入力ソースのjazn-data.xml、入力リソースのres-jazn-data.xmlおよび出力のfinal-jazn-data.xml)の関連部分を示しています。
入力ソース・ファイルjazn-data.xml
<policy-store>
<applications>
<application>
<name>PolicyServlet1</name>
<app-roles>
<app-role>
<name>myAppRole2</name>
<display-name>application role myAppRole</display-name>
<members>
<member>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole</name>
</member>
</members>
</app-role>
<app-role>
<name>myAppRole</name>
<display-name>application role myAppRole</display-name>
<members>
<member>
<class>
oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl</class>
<name>developers</name>
</member>
</members>
</app-role>
<app-role>
<name>testrole_DATA</name>
<display-name>application role test</display-name>
<members>
<member>
<class>
oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl</class>
<name>test-entrole</name>
</member>
</members>
</app-role>
<app-role>
<name>myAppRole_PRIV</name>
<display-name>application role private</display-name>
<description>app role private description</description>
<members>
<member>
<class>
oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl</class>
<name>developers</name>
</member>
<member>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole</name>
</member>
</members>
</app-role>
</app-roles>
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole_PRIV</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>getClassLoader</name>
</permission>
<permission>
<class>
oracle.adf.share.security.authorization.RegionPermission</class>
<name>dummyName</name>
<actions>view,edit</actions>
</permission>
</permissions>
</grant>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>java.lang.XYZPermission</class>
<name>newxyz</name>
</permission>
</permissions>
</grant>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl</class>
<name>test-entrole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>newxy</name>
<actions>view,edit</actions>
</permission>
</permissions>
</grant>
</jazn-policy>
</application>
</applications>
</policy-store>
入力リソース・ファイルres-jazn-data.xml
<jazn-data>
<jazn-realm default="jazn.com">
</jazn-realm>
<policy-store>
<applications>
<application>
<name>PolicyServlet1</name>
<resource-types>
<resource-type>
<name>FileResourceType</name>
<display-name>File Access</display-name>
<description>Resource Type Modelling File Access</description>
<provider-name>provider</provider-name>
<matcher-class>oracle.security.jps.JpsPermission</matcher-class>
<actions-delimiter>,</actions-delimiter>
<actions>delete,write,read</actions>
</resource-type>
</resource-types>
<jazn-policy>
</jazn-policy>
</application>
</applications>
</policy-store>
<jazn-policy>
</jazn-policy>
</jazn-data>
出力データ・ファイルfinal-jazn-data.xml
<jazn-data>
<jazn-realm>
</jazn-realm>
<policy-store>
<applications>
<application>
<name>PolicyServlet1</name>
<app-roles>
<app-role>
<name>myAppRole2</name>
<display-name>application role myAppRole</display-name>
<guid>4341CC10EAFB11DE9F7F17D892026AF8</guid>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole</name>
<guid>43428F60EAFB11DE9F7F17D892026AF8</guid>
</member>
</members>
</app-role>
<app-role>
<name>myAppRole</name>
<display-name>application role myAppRole</display-name>
<guid>43428F60EAFB11DE9F7F17D892026AF8</guid>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>weblogic.security.principal.WLSGroupImpl</class>
<name>developers</name>
</member>
</members>
</app-role>
<app-role>
<name>testrole_DATA</name>
<display-name>application role test role</display-name>
<guid>4342B670EAFB11DE9F7F17D892026AF8</guid>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>weblogic.security.principal.WLSGroupImpl</class>
<name>test-entrole</name>
</member>
</members>
</app-role>
<app-role>
<name>myAppRole_PRIV</name>
<display-name>application role private</display-name>
<description>app role private description</description>
<guid>4342B671EAFB11DE9F7F17D892026AF8</guid>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>
weblogic.security.principal.WLSGroupImpl</class>
<name>developers</name>
</member>
<member>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole</name>
<guid>43428F60EAFB11DE9F7F17D892026AF8</guid>
</member>
</members>
</app-role>
</app-roles>
<resource-types>
<resource-type>
<name>FileResourceType</name>
<display-name>File Access</display-name>
<description>Resource Type Modelling File Access</description>
<provider-name>provider</provider-name>
<matcher-class>oracle.security.jps.JpsPermission</matcher-class>
<actions-delimiter>,</actions-delimiter>
<actions>delete,write,read</actions>
</resource-type>
</resource-types>
<resources>
<resource>
<name>getClassLoader</name>
<type-name-ref>FileResourceType</type-name-ref>
</resource>
<resource>
<name>newxy</name>
<type-name-ref>FileResourceType</type-name-ref>
</resource>
</resources>
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole_PRIV</name>
<guid>4342B671EAFB11DE9F7F17D892026AF8</guid>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>getClassLoader</name>
</permission>
<permission>
<class>
oracle.adf.share.security.authorization.RegionPermission</class>
<name>dummyName</name>
<actions>view,edit</actions>
</permission>
</permissions>
<permission-set-refs>
</permission-set-refs>
</grant>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole</name>
<guid>43428F60EAFB11DE9F7F17D892026AF8</guid>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>java.lang.XYZPermission</class>
<name>newxyz</name>
</permission>
</permissions>
<permission-set-refs>
</permission-set-refs>
</grant>
<grant>
<grantee>
<principals>
<principal>
<class>
weblogic.security.principal.WLSGroupImpl</class>
<name>test-entrole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>newxy</name>
<actions></actions>
</permission>
</permissions>
<permission-set-refs>
</permission-set-refs>
</grant>
</jazn-policy>
</application>
</applications>
</policy-store>
<jazn-policy>
</jazn-policy>
</jazn-data>
upgradeOpssは、11.1.1.2.0、11.1.1.3.0、11.1.1.4.0、11.1.1.5.0、11.1.1.6.0および11.1.1.7.0 構成およびストアを11.1.1.9.0のOPSSセキュリティ・ストアに更新するオフラインのスクリプトです。
|
注意: 以前のバージョンからより新しいバージョンに更新する必要がある場合、たとえば11.1.1.2.0から11.1.1.4.0の例では、バージョン11.1.1.4.0のupgradeOpssコマンドを使用する必要があります。 |
アップグレードするストアはファイルベース、LDAPベースまたはDBベースのいずれでもかまわず、複数のWebLogicドメインで共有されている場合もあります。スクリプトは、システム・ポリシー、アプリケーション・ポリシー、jps-config.xmlファイルおよびjps-config-jse.xmlファイルを含む複数のアーティファクトをアップグレードします。
OPSSバイナリとターゲットのポリシー・ストアには、互換性のあるバージョンを使用する必要があります。詳細は、第K.9.1項「バイナリとポリシー・ストアのバージョンの非互換性」を参照してください。
動作およびスクリプトの使用方法について、次の各項で説明します。
アーティファクトおよびサービスに影響を与えるupgradeOpssの変更の詳細は次のとおりです。
資格証明ストア - 資格証明ストアで、BASE64によりエンコードされた暗号化キーを生成します。
監査サービス - 次の構成、データおよびスキーマ変更を導入し、Java SEアプリケーションでのOPSS監査サービスを有効化します。
プロパティの場所、監査ストア・タイプ、ローダー・ユーザー名およびパスワードが監査サービス構成に追加されます。
AuditUser属性およびTenantId属性は共通の属性グループに追加されます。
IAU_AUDITUSER列およびIAU_TENANTID列はIAU_BASE表およびIAU_COMMON表に追加されます。
共通グループ・バージョンを1.0から1.1に変更します。
拡張された表名はIAU_CUSTOM_01です。
トラスト・サービス - jps-config-jse.xmlファイルのトラスト・サービスの構成を変更し、次の要素を挿入してJava SEアプリケーションでのOPSSトラスト・サービスを有効化します。
trust.provider.embedded propertySet
trust.provider serviceProvider
トラスト・サービス・インスタンス
デフォルト・コンテキストでのインスタンスの参照
PDPサービス - jps-config-jse.xmlファイルのPDPサービスの構成を変更し、次の要素を挿入してJava SEアプリケーションでのOPSSトラスト・サービスを有効化します。
pdp.service.provider serviceProvider
PDPサービス・インスタンス
デフォルト・コンテキストでのインスタンスの参照
属性サービス - jps-config.xmlファイルおよびjps-config-jse.xmlファイルの属性サービスの構成を変更し、次の要素を挿入してJava EEアプリケーションおよびJava SEアプリケーションでの属性サービスを有効化します。
attribute.provider serviceProvider
属性サービス・インスタンス
デフォルト・コンテキストでのインスタンスの参照
jps-config-jse.xmlファイルおよびjps-config.xmlファイルの同期をとるためにその他の様々な変更を反映させます。
upgradeOpssの重要ポイントは次のとおりです。
サーバーの起動時にアップグレードされたデータがクラスタ内のすべての管理対象サーバーにプッシュされるように、管理サーバー・インスタンスをホストするシステム上で実行する必要があります。
これを使用する前に、アップグレードするストアをバックアップしておいてください。詳細は、「OPSSセキュリティ・ストアのバックアップとリカバリ」を参照してください。
リポジトリ・タイプの変更は行いません。
既存のドメインに適用されます。このドメインを再作成する必要はありません。
アップグレード先のストアがすでに11.1.1.7.0に更新済の場合、スクリプトを実行しても何も変更されません。
LDAPベースのストアの場合、ストアへの接続パラメータは、jps-config.xmlファイルから読み取られるか、引数としてスクリプトに渡されます。
DBベースのストアの場合、接続パラメータは引数としてスクリプトに渡されます。
アップグレードするセキュリティ・ストアが複数のドメインによって共有されている場合(結合操作により)、ストアをアップグレードする前に、そのストアを参照するすべてのドメインに新しい11.1.1.7.0バイナリをインストールする必要があります。そうしないと、OPSSセキュリティ・ストアのバージョンがOPSSバイナリのバージョンよりも新しいことを示すPolicyStoreIncompatibleVersionException例外がシステムによってスローされることがあります。
{domain.home}/config/fmwconfig/audit-store.xmlファイルが存在するかどうかをチェックします。ファイルが見つからない、およびセキュリティ・ストアがファイルベースの場合は、ファイルを作成します。ファイルが存在し、セキュリティ・ストアがLDAPベースまたはDBベースの場合は、ストア内に必要な監査データを作成します。
11.1.1.2.0、11.1.1.3.0、11.1.1.4.0、11.1.1.5.0、11.1.1.6.0または11.1.1.7.0から11.1.1.9.0にアップグレードするには、次の手順を実行します。
アプリケーション・サーバーを停止します。
新しいバイナリをインストールします。
DBベースのストアをアップグレードする場合は、Oracle Fusion Middlewareパッチ・セット・アシスタントを使用してDBスキーマを次のようにアップグレードします。
「OPSSスキーマ」ページに移動します。
「接続文字列」、「DBAユーザー名」、「DBAパスワード」、「スキーマ・ユーザー名」および「スキーマ・パスワード」にデータを入力し、「次」をクリックします。
「スクリプト構文」の説明に従って、upgradeOpssを実行します。
|
注意: 11.1.1.7.0からアップグレードする場合、audit-store.xmlファイルに関して「ファイルが見つかりません」のエラー・メッセージを受け取る可能性があります。このファイルはupgradeOpssを実行すると作成されるため、このエラー・メッセージは無視してかまいません。 |
アプリケーション・サーバーを再起動します。
ファイルベース、LDAPベースまたはDBベースのストアをアップグレードするには、次の構文を使用します。接続引数は、ファイルベースのストアについては不要であり、LDAPベースのストアについてはオプションであり、DBベースのストアについては必須であることに注意してください。
upgradeOpss(jpsConfig="<full path to the old version jps config file>",
jaznData="<full path to the new version OOTB JAZN data file>",
[auditStore="<full path to the OOTB audit-store.xml file>"],
[jdbcDriver="<jdbc driver>",
url="<jdbc-ldap url>",
user="<jdbc-ldap user>",
password="<jdbc-ldap password>"],
[upgradeJseStoreType="true" or "false"]
[transformData="true" or "false"])
引数の意味は、次のとおりです。
jpsConfigは、11.1.1.2.0、11.1.1.3.0、11.1.1.4.0、11.1.1.5.0、11.1.1.6.0または 11.1.1.7.0のjps-config.xmlドメイン構成ファイルの場所へのフルパスを指定します。そのファイルはスクリプトによって名前に接尾辞の.bakを追加したファイルとして同じディレクトリにバックアップされます。この引数は必須です。通常、$DOMAIN_HOME/config/fmwconfigディレクトリにあります。jps-config-jse.xmlファイルは同じディレクトリにあると想定されています。
jaznDataは、11.1.1.7.0の出荷時のsystem-jazn-data.xmlファイルの場所へのフル・パスを指定します。この引数は必須です。通常、${common_components_home}/modules/oracle.jps_11.1.1/domain_configディレクトリに存在します。
auditStoreは、11.1.1.7.0の出荷時のaudit-store.xmlファイルの場所へのフルパスを指定します。この引数はオプションです。指定しない場合は、jaznDataで指定されるディレクトリにあるデフォルトのaudit-store.xmlファイルが使用されます。
jdbcDriverは、ストアに対するJDBCドライバを指定します。DBベースのストアについては必須です。
urlは、JDBC URLまたはLDAP URLをdriverType:host:port:sid形式で指定します。DBベースおよびLDAPベースのストアの両方に必須です。指定しない場合は、構成ファイルから読み取られます。
userは、JDBCユーザー名またはLDAPバインド名を指定します。LDAPベースのストアについてはオプション、DBベースのストアについては必須です。指定しない場合は、構成ファイルから読み取られます。LDAPベースのストアの場合、アップグレードを実行するユーザーには、スキーマ、ルート・ノード、およびcn=OPSS,cn=OracleSchemaVersionの下のすべてのノードに対する読取りおよび書込み権限が必要です。DBベースのストアの場合は、OPSS DBスキーマ・ユーザーとしてアップグレードを実行します。
passwordは、指定されたuserに対するパスワードを指定します。これは、DBベースのストアの場合はJDBCパスワード、LDAPベースのストアの場合はJDBCバインド・パスワードになります。LDAPベースのストアについてはオプション、DBベースのストアについては必須です。指定しない場合は、構成ファイルから読み取られます。
upgradeJseStoreTypeは、jps-config.xmlファイルで指定されたストアがLDAPベースまたはDBベースの場合にのみ適用され、jps-config-jse.xmlファイルのストア・タイプ構成を、ファイルベースからLDAPベースまたはDBベースの、jps-config.xmlファイルで指定されたタイプに変更するかどうかを指定します。trueに設定する必要があります。
transformDataは、DBパフォーマンスの拡張を強化するためにいくつかのアップグレードを実行します。これはオプションで、デフォルト値はtrueです。デフォルト値の変更はお薦めしません。
この項では、ドメインの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"
企業で設定したスケジュールに従って、定期的にOPSSセキュリティ・ストアをバックアップすることをお薦めします。また、次のイベントが発生した直後は、予定外のバックアップを実行してください。
ドメイン用の新しい暗号化キーの(自動)生成
新しいポリシーの作成
新しいバインディング資格証明の設定
