This chapter includes the following topics:
When using Oracle GoldenGate Veridata, you select, view, and store data values from the tables or files of your business applications. Ensure to protect access to the following components:
Files, programs, and directories in the Oracle GoldenGate Veridata installation directories. installation directories
Data files that contain the results of data comparisons
Oracle GoldenGate Veridata web user interface, where data values can be viewed
Oracle GoldenGate Veridata supports SSL and plain socket communication between Oracle GoldenGate Veridata Server (server) and multiple Oracle GoldenGate Veridata Agents (agents) that are connected over a network. This section describes how to configure SSL and secure communication between the server and the agents.
Note:
The Oracle GoldenGate Veridata Agent for NonStop platforms doesn't support SSL communication.
In an SSL scenario, the server is considered the SSL Client and the agents are considered the SSL Servers. The server and the agents authenticate each other's identity. The data exchanged between the server and agent is also encrypted.
SSL can be configured one-way or two-way in Oracle GoldenGate Veridata.
In a one-way SSL connection, the SSL client (Oracle GoldenGate Veridata Server) must trust the SSL server (Oracle GoldenGate Veridata Agent). In a two-way SSL connection, mutual trust is required between the SSL server and client. To enable SSL, you can use either self-signed certificates or Certificate Authority (CA) signed certificates.
To establish one-way SSL using self-signed certificates:
Create self-signed certificates for all agents.
VeridataWebTrustStore
of the server. See Managing the Server Identity and Trust Keystores.To establish two-way SSL by using CA signed certificates:
Create self-signed certificates for all agents.
Upload all agent certificates to the VeridataWebTrustStore
of the server.
Create a self-signed certificate for the identity store of the server.
Upload the server identity certificate to all agent truststores.
For more information about creating and importing certificates, see Creating Keystores and Self-Signed Certificates.
To establish one-way SSL by using CA signed certificates:
Use certificates issued by the same CA for all agents.
Trust the root CA certificate in the server.
To establish two-way SSL by using CA signed certificates:
Use certificates issued by the same CA for all agents.
Trust the root CA certificate in the server.
Use the certificate issued by a CA for the identity store of the server.
Trust the root CA certificate used in the previous step in the agent truststore.
By default, the server and the agents are not enabled for SSL. If you decide to use SSL, you must enable the server and agent properties.
You must also create the identity and trust keystores. Create self-signed certificates if you are not using a CA certificate.
To establish an SSL connection between the server and the agent:
Configure SSL for the server. See Configuring SSL Settings for the Oracle GoldenGate Veridata Server.
Restart the server.
Shut down the agent. Configure SSL for the agent. See Configuring SSL Settings for the Oracle GoldenGate Veridata Agent.
Obtain the agent-side keystores. See Managing the Server Identity and Trust Keystores.
Configure the agent-side keystores in the agent configuration properties file.
Run configure_agent_ssl.sh
and supply the password to the keystores configured in the agent configuration file. See Modifying the Oracle GoldenGate Veridata Agent Wallet.
Start the agent.
If the trust is established properly between agent keystores and their server counterpart in the Oracle Platform Security Services Keystore Service, then SSL communication is established.
By default, SSL is disabled for the agent. To configure SSL, edit the following properties in the agent.properties
file for your agent.
Table 2-1 SSL Parameters in agent.properties file
Parameter | Description | Default Value |
---|---|---|
server.useSsl |
Enables or disables SSL communication between the agent and the server. Possible values are:
|
false |
server.use2WaySsl |
Specifies whether the SSL communication false value is one way or two way. Options are:
|
false |
server.identitystore.type |
Specifies the type of keystore used for the SSL configuration. |
JKS |
server.identitystore.path |
Specifies the path for the server identity keystore. |
./certs/serverIdentity.jks(Self Signed) |
server.truststore.type |
Specifies the type of truststore used for SSL configuration. |
JKS |
server.truststore.path |
Specifies the path for the server truststore. |
./certs/serverTrust.jks(Self Signed) |
server.identitystore.keyfactory.alg.name |
Algorithm name of the keyfactory used for the SSL server identity store. |
SunX509 |
server.truststore.keyfactory.alg.nam |
Algorithm name of the keyfactory used for SSL server trust store. |
SunX509 |
server.ssl.algorithm.name |
SSL algorithm name. Note: The value of this parameter must be same for the agent and the server. |
TLS |
To enable SSL communication for all server-agent connections, you must set the SSL parameters in the veridata.cfg
file located in the DOMAIN_HOME
/config/veridata
directory of your installation. Table 2-2 describes the various parameters that you must set in the veridata.cfg
file for SSL communication.
To establish SSL communication only for certain connections, edit the connection properties in the Oracle GoldenGate Veridata web user interface. For more information, see the online help.
Note:
In addition to these settings, configure the server identity keystore and trust keystore by using the OPSS Keystore Service in the Oracle WebLogic Server domain. For more details, Managing the Server Identity and Trust Keystores.
Table 2-2 SSL Settings in the veridata.cfg file
Parameter | Description | Default Value |
---|---|---|
server.useSsl |
Enables or disables SSL communication between the agent and the server. Possible values are:
|
false |
server.ssl.client.identitystore.keyfactory.alg.name |
Algorithm name of the keyfactory used for the SSL server identity store. |
SunX509 |
server.ssl.client.truststore.keyfactory.alg.name |
Algorithm name of the keyfactory used for the SSL server trust store. |
SunX509 |
server.ssl.algorithm.name |
SSL algorithm name. Note: The value of this parameter must be the same for the agent and the server. |
TLS |
For mutual authentication and to establish SSL communication, the server and the agents should mutually trust the add certificates in the respective truststores.
This section explains how to create keystores and self-signed certificates by using the keytool
utility that is available as part of the Java Runtime Environment (JRE). For more details about keytool
, refer to the Java documentation at http://docs.oracle.com/javase/7/docs/technotes/tools/#security
.
To create a keystore
containing a self-signed certificate:
keytool -genkey -keystore certs -keyalg rsa -alias vdt_alias -storepass server_ks_pwd -keypass server_pwd
At the prompts, enter the requested details about the certificate.
keytool -genkey -alias agent.server.keys -keyalg RSA -keystore agent.server.keystore -storepass ks_password -keypass keypwd
keytool
command:
keytool -export -alias agent.server.keys -keystore agent.server.keystore -storepass ks_password -file agent.server.cer
keytool
command:
keytool -genkey -alias vdt.web.client.keys -keyalg RSA -keystore vdt.web.client.keystore -storepass ks_password -keypass keypwd
keytool
command:
keytool -export -alias vdt.web.client.keys -keystore vdt.web.client.keystore -storepass ks_password -file vdt.web.client.cer
keytool -import -v -keystore agent.server.truststore -storepass ks_password -file vdt.web.client.cer
keytool
command:
keytool -import -v -keystore vdt.web.client.truststore -storepass ks_password -file agent.server.cer
keytool -genkey -alias vdt.agent.id -keyalg RSA -keystore vdtAgentID.jks -storepass changeit -keypass changeit -validity 365
C:\java\Java8\jdk1.8.0_40\bin>keytool -genkey -alias vdt.agent.id -keyalg RSA -keystore vdtAgentID.jks -storepass changeit -keypass c hangeit -validity 365 What is your first and last name? [Unknown]: COMPANY A What is the name of your organizational unit? [Unknown]: NA What is the name of your organization? [Unknown]: COMPANY A What is the name of your City or Locality? [Unknown]: USA What is the name of your State or Province? [Unknown]: USA What is the two-letter country code for this unit? [Unknown]: US Is CN=COMPANY A, OU=NA, O=COMPANY A, L=USA, ST=USA, C=US correct? [no]: yes
keytool -export -alias vdt.agent.id -keystore vdtAgentID.jks -storepass changeit -file vdtAgentID.cer
C:\java\Java8\jdk1.8.0_40\bin>keytool -export -alias vdt.agent.id -keystore vdtAgentID.jks -storepass changeit -file vdtAgentID.cer
The certificate is stored in the vdtAgentID.cer
file.
keytool -genkey -alias vdt.server.id -keyalg RSA -keystore vdtServerID.jks -storepass changeit -keypass changeit -validity 365
C:\java\Java8\jdk1.8.0_40\bin>keytool -genkey -alias vdt.server.id -keyalg RSA -keystore vdtServerID.jks -storepass changeit -keypass changeit -validity 365 What is your first and last name? [Unknown]: ORACLE GOLDENGATE VERIDATA SERVER What is the name of your organizational unit? [Unknown]: NA What is the name of your organization? [Unknown]: COMPANY A What is the name of your City or Locality? [Unknown]: USA What is the name of your State or Province? [Unknown]: USA What is the two-letter country code for this unit? [Unknown]: US Is CN=COMPANY A, OU=NA, O=COMPANY A, L=USA, ST=USA, C=US correct? [no]: yes
keytool -export -alias vdt.server.id -keystore vdtServerID.jks -storepass changeit -file vdtServerID.cer
C:\java\Java8\jdk1.8.0_40\bin>keytool -export -alias vdt.server.id -keystore vdtServerID.jks -storepass changeit -file vdtServerID.cer
The certificate is stored in the vdtAgentID.cer
file.
keytool -import -v -keystore vdtAgentTrust.jks -storepass changeit -file vdtServerID.cer -alias vdt.server.id
C:\java\Java8\jdk1.8.0_40\bin>keytool -import -v -keystore vdtAgentTrust.jks -storepass changeit -file vdtServerID.cer -alias vdt.ser ver.id Owner: CN=ORACLE GOLDENGATE VERIDATA SERVER, OU=NA, O=COMPANY A, L=USA, ST=USA, C=US Issuer: CN=ORACLE GOLDENGATE VERIDATA SERVER, OU=NA, O=COMPANY A, L=USA, ST=USA, C=US Serial number: 2aded02f Valid from: Thu May 14 12:18:09 IST 2015 until: Fri May 13 12:18:09 IST 2016 Certificate fingerprints: MD5: 4E:7D:89:F7:C8:E8:64:37:E5:0C:D3:03:8F:3E:94:0A SHA1: 1B:00:9D:44:BD:73:6E:71:9D:44:56:4A:29:4E:F5:D7:1C:49:57:F3 SHA256: 25:CB:77:3F:BC:5F:88:4B:09:D2:2D:C1:F8:E6:BA:70:DB:2B:55:53:48:7D:BA:F1:A3:01:18:AB:AA:D1:56:6A Signature algorithm name: SHA256withRSA Version: 3 Extensions: #1: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: EF C3 25 BB 83 4E 2D 0D 15 3D EF 50 F7 F2 D0 A6 ..%..N-..=.P.... 0010: 94 5F 87 F2 ._.. ] ] Trust this certificate? [no]: yes Certificate was added to keystore [Storing vdtAgentTrust.jks]
keytool -import -v -keystore vdtServerTrust.jks -storepass changeit -file vdtAgentID.cer -alias vdt.agent.id
C:\java\Java8\jdk1.8.0_40\bin>keytool -import -v -keystore vdtServerTrust.jks -storepass changeit -file vdtAgentID.cer -alias vdt.age nt.id Owner: CN=COMPANY A, OU=NA, O=COMPANY A, L=USA, ST=USA, C=US Issuer: CN=COMPANY A, OU=NA, O=COMPANY A, L=USA, ST=USA, C=US Serial number: 6b590df2 Valid from: Thu May 14 12:08:00 IST 2015 until: Fri May 13 12:08:00 IST 2016 Certificate fingerprints: MD5: 3E:75:A3:96:40:60:10:96:DD:10:7B:4D:E4:3F:4C:04 SHA1: D1:CC:EB:67:A1:C6:CD:CA:62:27:EA:F8:82:BF:AB:E4:E7:2B:45:6D SHA256: E7:20:CF:D4:48:E2:AE:1E:1C:C7:06:1A:B3:0A:17:1F:8F:02:88:B7:A6:A0:5D:F7:12:BC:26:68:5B:C3:C9:C8 Signature algorithm name: SHA256withRSA Version: 3 Extensions: #1: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: C0 D5 02 D9 24 6F 58 F6 63 D7 34 D3 9D C4 9E 33 ....$oX.c.4....3 0010: FC 16 4E 5F ..N_ ] ] Trust this certificate? [no]: yes Certificate was added to keystore [Storing vdtServerTrust.jks]
Use the Oracle Platform Security Services keystore service as a repository for storing the server identity and trust keystores. You can also use it to manage the agent keystores. For more information, see "Managing Keys and Certificates with the Keystore Service" in Oracle® Fusion Middleware Securing Applications with Oracle Platform Security Services .
Table 2-3 lists the default values for the OPSS settings.
Table 2-3 Oracle Platform Security Services Settings
Setting | Value |
---|---|
Name of the application stripe created by the server |
|
Name of the identity keystore under the |
|
Name of the trust keystore under the |
|
To configure two-way SSL by using the Oracle Platform Security Services keystore service:
For each agent, create an identity and trust keystore.
Update VeridataWebIdentityStore
with the identity certificate of the server.
Update VeridataWebTrustStore
with all agent certificates.
Update each agent truststore with the identity certificate of the server.
Export the agent keystore and truststore as JKS files and note the passwords.
Distribute the JKS files to corresponding agent machines.
Run the configure_agent_ssl
tool to update the agent wallet with the keystore passwords.
For each agent, configure the agent.properties
file to enable SSL.
To configure one-way SSL by using the Oracle Platform Security Services keystore service:
For each agent, create an identity keystore.
Update the VeridataWebIdentityStore
with the identity certificate of the server.
Export the agent keystore and truststore as JKS files and write down the passwords.
Distribute the JKS files to corresponding agent machines.
Run the configure_agent_ssl
tool to update the agent wallet with the keystore passwords.
For each agent, configure the agent.properties
file to enable SSL.
Before you start the agent in SSL mode, you must update the agent wallet with the identity and trust keystore passwords. Otherwise, the agent doesn't start.
To update the wallet:
Run the configure_agent_ssl
script that is available in the agent home:
AGENT_HOME\configure_agent_ssl.sh AgentID
AgentID
is the name of the agent properties file, without the .properties
extension. The default value for AgentID
is agent
.At the prompts enter the entry or unlock password for the identity and trust keystores for the agent.
This topic describes how to secure your business data and control access to the Oracle GoldenGate Veridata installation directories and user interface.
Controlling Access to the Installation Directories
Standard operating system permissions apply to the programs, files, and directories in the server, agent, and web user interface installation directories. You should adjust the permissions for these objects based on your business security rules.
Securing Files That Contain Business Data
The server creates data files that contain sensitive application data. By default, these files reside in DOMAIN_HOME/veridata/reports
. The subdirectories contain files that may reflect business data.
The following types of files contain sensitive data:
Comparison report (rpt
subdirectories)
Out-of-sync report (oosxml
and oos
subdirectories)
These files inherit the same file permissions as those of the user that runs the server installation program. Do not change the permissions; if you do, then Oracle GoldenGate Veridata may be unable to maintain them. Keep these files just as secure as you would keep your business data. Users of the Oracle GoldenGate Veridata web user interface do not require access to these files because they see the same information through the client interface. You can encrypt the contents of all report files.
You assign security roles to control user access to the software functions, some of which expose selected data values from the database. Table 2-4 describes the user roles.
Table 2-4 User Roles
Oracle GoldenGate Veridata | Type | Description |
---|---|---|
|
Type-A |
The administrator role is the highest level security role. This role can perform all functions that configure, execute, and monitor Oracle GoldenGate Veridata. |
|
Type-A |
The power user role is the second highest role. This role can perform all functions that configure, execute, and monitor Oracle GoldenGate Veridata from the web user interface. It cannot perform any configuration functions for the server. |
|
Type-B |
The report viewer role cannot perform functions that configure Oracle GoldenGate Veridata or execute jobs. This role can only view configuration and job information, and view comparison reports. |
|
Type-B |
The detail report viewer role cannot perform any functions that configure Oracle GoldenGate Veridata or execute jobs. This role can only view configuration and job information. It can also view comparison reports and out-of-sync report information through the web user interface or at the file level. |
|
Additional |
The repair operator role can use the Repair feature in Oracle GoldenGate Veridata. |
|
Additional |
The command-line user role provides access to the Oracle GoldenGate Veridata command-line tools, |
These roles are categorized into as follows:
Type A and Type B: By default, Type A and Type B users are not given any privileges of the additional user roles. Assign additional roles to users of these types.
Additional: WebLogic Administrators can assign these Additional roles to Type A users to perform the required Oracle GoldenGate Veridata functions.
Security is controlled through the Oracle WebLogic Server Administration Console, where a user with the administrator role can:
Create a user and assign it a security role.
Create user groups and assign them security roles. Users can be added to these groups without being given a security role. A user inherits the role of its group.
Create a user and assign it a security role, and then add that user to a group. The user inherits the role of its group and keeps its individual role.
Table 2-5 Active Directory Roles
Oracle GoldenGate Veridata | Type | Description |
veridataAdministrator |
Type-A |
The administrator role is the highest-level security role in Oracle GoldenGate Veridata. This role can perform all of the functions that configure, execute, and monitor Oracle GoldenGate Veridata. |
veridataPowerUser |
Type-A |
The power user role is the second-highest role in Oracle GoldenGate Veridata. This role can perform all of the functions that configure, execute, and monitor Oracle GoldenGate Veridata from the Oracle GoldenGate Veridata Web User Interface, but this role cannot perform any configuration functions for the Oracle GoldenGate Veridata Server. |
veridataReportViewer |
Type-B |
The report viewer role cannot perform functions that configure Oracle GoldenGate Veridata or execute jobs. This role can only view configuration and job information, and view comparison reports. |
veridataDetailReportViewer |
Type-B |
The detail report viewer role cannot perform any functions that configure Oracle GoldenGate Veridata or execute jobs. This role can only view configuration and job information, and view comparison reports and out-of-sync report information through the Oracle Oracle GoldenGate Veridata web user interface or at the file level. |
veridataRepairOperator |
Additional |
The |
veridataCommandLineUser |
Additional |
The |
To open the Oracle WebLogic Server Administration Console:
In your browser, connect to the Oracle WebLogic Server Administration Console by entering the following address:
http://weblogic_admin_server_hostname:admin_server_port/console
weblogic_admin_server_hostname
is the name or IP address of the system where the server and web components are hosted, and admin_server_port
is the port number assigned to the server (default is 7001).
Log on as an Oracle GoldenGate Veridata administrator user. A default administrator user was created when the Oracle GoldenGate Veridata domain was set up.
To create or edit a user:
In the left pane of the Oracle WebLogic Server Administration Console, select Security Realms.
On the Summary of Security Realms page select the name of the security realm.
On the Settings for Veridata Security realm page, select Users and Groups, and then select Users. The User table displays the names of all users defined in the Authentication provider.
Select an existing user and edit the settings or click New to create a user and enter the user’s properties.
To assign a role to the user, click Groups on the Settings for user_name page.
Select appropriate roles for the user as described inTable 2-4.
For example, an administrator, VeridataAdmin, can be given the privileges shown in the figure.
For example, a Veridata power user, PowerUser, can be given the privileges shown in the next figure.
Click Save .
You can change database schema passwords when a schema password expires, an account is locked, or a password change is necessary. This topic applies to all database schemas that are prefixed with 'OGG', such as OGG_IAU, OGG_IAU_APPEND
, or OGG_IAU_VIEWER
.
T change a database schema password:
Stop your Oracle GoldenGate Veridata Server.
DOMAIN_HOME/veridata/veridata/bin/veridataServer.sh stop
Stop your Oracle WebLogic Server.
DOMAIN_HOME//veridata/bin/stopWebLogic.sh
Start the Oracle WebLogic Scripting Tool, wlst.sh
. For example:
/home/oracle/Oracle/Middleware/Oracle_Home/oracle_common/common/bin/wlst.sh
Modify the database schema password as in this example:
modifyBootStrapCredential(jpsConfigFile='/home/oracle/wls_domains/veridata/config/fmwconfig/jps-config.xml',username='OGG_OPSS',password='welcome123')
username=
is your database schema name and password=
is the new password.
Exit the scripting tool by using exit()
.
Log in to the metadata repository database and change the schema passwords and unlock the schema.
OGG_OPSS
schema:
alter user OGG_OPSS identified by welcome123; alter user OGG_IAU identified by welcome123; alter user OGG_IAU_APPEND identified by welcome123; alter user OGG_IAU_VIEWER identified by welcome123; alter user OGG_STB identified by welcome123; alter user OGG_VERIDATA identified by welcome123; alter user OGG_OPSS account unlock;
Start the Oracle WebLogic Server Configuration Wizard. For example:
/home/oracle/Oracle/Middleware/Oracle_Home/oracle_common/common/bin/config.sh
Select Update an Existing Domain, and then click Next.
Select JDBC Component Schema, and then enter the new database schema passwords.
Click Next until you reach the Configuration Summary screen, and then click Update.
To save your schema password changes, click Next and then Finish.
Start Oracle WebLogic Server.
DOMAIN_HOME//veridata/bin/startWebLogic.sh
Start your Oracle GoldenGate Veridata Server.
DOMAIN_HOME/veridata/veridata/bin/veridataServer.sh start
You can encrypt the comparison report files (.rpt
, .oos
, .oosxml
) in Oracle GoldenGate Veridata. The following sections explain report encryption:
The encryption is controlled by the following parameters in the veridata.cfg
configuration file:
server.encryption
server.encryption.bits
To enable encryption, set server.encryption
to true
.
Encryption of report files uses Advanced Encryption Standard (AES) encryption, and the default encryption strength is 128 bits. You can increase the encryption strength to 192 or 256 bits by editing the value of the server.encryption.bits
parameter in veridata.cfg
. However, for encryption strength greater than 128, you must use a JRE installed with the Unlimited Strength Cryptography Extension.
For more information about these parameters, see "Parameters for Report File Encryption".
Encrypted report files have the following extensions in the file names:
.xrpt
: Encrypted comparison or repair report file
.xoos
: Encrypted binary out-of-sync file
.xoosxml
: Encrypted out-of-sync XML file
.xNNN
: Encrypted out-of-sync XML chunk file (NNN
is a decimal number)
When report encryption is enabled, all report files are encrypted by using an encryption key, which is initially a large random value. If necessary, then you can change the encryption key.
Before you can read encrypted files, you must decrypt them. The Oracle GoldenGate Veridata web user interface automatically decrypts files before displaying them. Use the reportutil.sh/.bat
utility to display the encrypted contents. This utility is located in the VERIDATA_DOMAIN_HOME\veridata\bin
directory.
To display encrypted files, run the reportutil.sh/.bat
utility located in the VERIDATA_DOMAIN_HOME\veridata\bin
directory.
reportutil [-wlport port ] -wluser weblogic_user { options }
wlport
is the server port number (the default port is 8830), and wluser
is the server user name.
The valid options
are:
-version
, -v
: Displays the current version
-help
: Displays the help message
-r
: Rolls report encryption
-f
filename
[-d
directory
]: Decrypts and prints the report file to the specified file if a directory is specified by the -d
option. Otherwise, the command prints the decrypted file to the standard output.
The user running the reportutil
utility must be in the appropriate user group to perform the operations:
-r
, -f
: Allowed only if the user is a member of the veridataCommandLineUser
group.
-r
: Allowed if the user is a member of the veridataAdministrator
group.
-f
: Allowed if the user is a member of the veridataAdministrator
group, or a member of veridataPowerUser
group, the veridataPowerUser
group, or the veridataDetailReportViewer
group.
For more information about the user roles, see Securing Access to Oracle GoldenGate Veridata by Defining User Roles.