This chapter describes the security features you can use to protect your Oracle GoldenGate HP NonStop environment and the data that is being processed.
This chapter includes the following sections:
The following tables summarizes the security features that are available in Oracle GoldenGate for HP NonStop:
Table 5-1 Oracle GoldenGate Security Features
| Security feature | Description |
|---|---|
|
Encryption |
Options are available for encrypting and decrypting:
|
|
Command security |
Sets user-level permissions for accessing Oracle GoldenGate commands through GGSCI. |
This section contains instructions for encrypting and decrypting the following:
The trail or extract file that holds data being processed by Oracle GoldenGate
A database password
The data sent across TCP/IP
The following encryption methods are used:
To encrypt trail or extract files, Oracle GoldenGate uses 256-key byte substitution. All records going into those files are encrypted both across any data links and within the files themselves.
To encrypt the database password or data sent across TCP/IP, Oracle GoldenGate uses Blowfish encryption. Blowfish is a symmetric block cipher that can be used as a drop-in replacement for DES or IDEA. The Oracle GoldenGate implementation of Blowfish can take a variable-length key from 32 bits to 128 bits. Blowfish encryption can be combined with Oracle GoldenGate trail encryption.
Note:
AES encryption is currently not supported on the HP NonStop.
You can encrypt the data in any local or remote trail or file.
Note:
This feature cannot be used when FORMATASCII is used to write data to a file in ASCII format. The trail or file must be written in default canonical format.
To encrypt trail or extract files
In the Extract parameter file, list the following parameter before all trails or files that you want to be encrypted. You can list multiple trails or files after one instance of this parameter.
ENCRYPTTRAIL
To disable encryption for any files or trails listed in the Extract parameter file, precede their entries with the following parameter:
NOENCRYPTTRAIL
In the Replicat parameter file, include the following parameter so that Replicat decrypts the data for processing.
DECRYPTTRAIL
You also can use DECRYPTTRAIL for an Extract data pump to decrypt the data for column mapping, filtering, transformation, and so forth. You can then leave it decrypted for downstream trails or files, or you can use ENCRYPTTRAIL to encrypt the data again before it is written to those files.
Use the following steps to encrypt the database password used by the Oracle GoldenGate processes.
Run GGSCI and issue the ENCRYPT PASSWORD command to generate an encrypted password. The command provides the following options.
The default ENCRYPT PASSWORD command, without any options, generates an encrypted password using a default key that is randomly generated by Oracle GoldenGate.
ENCRYPT PASSWORD password
ENCRYPT PASSWORD with the ENCRYPTKEY keyname generates an encrypted password using a user-defined key contained in the ENCKEYS lookup file.
ENCRYPT PASSWORD password ENCRYPTKEY keyname
For keyname, specify the logical name for the key you want to use, as it appears in the local ENCKEYS file. To use this option, you must first generate a key, create an ENCKEYS file on the local system, and create an entry in the file for the generated key. For instructions, see "Generating Encryption Keys".
The encrypted password is displayed to the screen when you run the ENCRYPT PASSWORD command.
Copy the encrypted password and paste it into the Oracle GoldenGate parameter file as follows.
USERID user_id, PASSWORD password, & [ENCRYPTKEY {DEFAULT | keyname}]
Where:
user_id is the database user name for the Oracle GoldenGate process.
password is the encrypted password that is copied from the ENCRYPT PASSWORD command results.
ENCRYPTKEY DEFAULT is required if the password was encrypted using ENCRYPT PASSWORD without the ENCRYPTKEY option.
ENCRYPTKEY keyname is required if the password was encrypted using ENCRYPT PASSWORD with the ENCRYPTKEY keyname option. Specify the logical name of the key as it appears in the ENCKEYS lookup file.
You can encrypt captured data before Oracle GoldenGate sends it across the TCP/IP network to the target system. On the target system, Oracle GoldenGate decrypts the data before writing it to the Oracle GoldenGate trails (unless trail encryption also is specified). By default, data sent across a network is not encrypted.
To encrypt data sent across TCP/IP
On the source system, generate one or more encryption keys and create an ENCKEYS file. See "Generating Encryption Keys" for more information.
Copy the finished ENCKEYS file to the Oracle GoldenGate installation location on all target systems. The key names and values in the source ENCKEYS file must match those of the target ENCKEYS file, or else the data exchange will fail and Extract and Collector will abort with the following message:
GGS error 118 – TCP/IP Server with invalid data.
In the Extract parameter file, use the ENCRYPT option of the RMTHOST parameter to specify the type of encryption and the logical key name as shown:
RMTHOST hostname, MGRPORT port, ENCRYPT BLOWFISH, KEYNAME keyname
Where:
BLOWFISH specifies Blowfish encryption.
keyname is the logical name for the encryption key you want to use, as it appears in the ENCKEYS file.
An example of encrypting data sent across TCP/IP:
RMTHOST sys1, MGRPORT 7840, ENCRYPT BLOWFISH, KEYNAME superkey
If using a static Collector and Blowfish encryption, append the following additional parameters in the Collector startup string:
-KEYNAME name
-ENCRYPT BLOWFISH
Where:
KEYNAME name specifies the name of the key.
ENCRYPT BLOWFISH specifies Blowfish encryption.
Collector matches these parameters to those specified with the KEYNAME and ENCRYPT options of RMTHOST.
You must create at least one encryption key and two ENCKEYS lookup files, one on the source and one on the target, if you want to:
Encrypt data sent across TCP/IP
Use a user-defined key to encrypt the database password
This procedure is not required if:
You are using a default key to encrypt the database password.
You are encrypting a trail or extract file.
You can define your own key or run the Oracle GoldenGate KEYGEN utility to create a key randomly.
To define your own key
The key name can be a string of 1 to 24 alphanumeric characters without spaces or quotation marks.
The key value can be up to 128 bits (16 bytes) as a quoted alphanumeric string (for example "Dailykey") or a hex string with the prefix 0x (for example 0x420E61BE7002D63560929CCA17A4E1FB).
To Use KEYGEN to Generate a Key
Change subvolumes to the Oracle GoldenGate installation location on the source system, and issue the following shell command. You can create multiple keys, if needed. The key values are returned to your screen.
TACL> RUN KEYGEN key_length number
Where:
key_length is the encryption key length, up to 128 bits.
number represents the number of keys to generate.
To store the keys for use by Oracle GoldenGate
On the source system, open a new ASCII text file.
For each key that you generated, enter a logical name followed by the key value itself. Place multiple key definitions on separate lines. Do not enclose a key name or value within quotation marks; otherwise it will be interpreted as text. Use the following sample file as a guide.
| Example Key Name | Example Key Value |
|---|---|
superkey |
0x420E61BE7002D63560929CCA17A4E1FB |
secretkey |
0x027742185BBF232D7C664A5E1A76B040 |
superkey1 |
0x42DACD1B0E94539763C6699D3AE8E200 |
superkey2 |
0x0343AD757A50A08E7F9A17313DBAB045 |
superkey3 |
0x43AC8DCE660CED861B6DC4C6408C7E8A |
Save the file as ENCKEYS without an extension in the Oracle GoldenGate installation location. The name must be in upper case.
Copy the ENCKEYS file to the target Oracle GoldenGate installation location. The key names and values in the source ENCKEYS file must match those of the target ENCKEYS file, or else the data exchange will fail and Extract and Collector will abort with the following message:
GGS error 118 – TCP/IP Server with invalid data.
You can establish command security for Oracle GoldenGate to control which users have access to which Oracle GoldenGate functions. For example, you can allow certain users to issue INFO and STATUS commands, while preventing their use of START and STOP commands. Security levels are defined by the operating system's user groups.
To implement security for Oracle GoldenGate commands, you create a CMDSEC file in the Oracle GoldenGate installation location. Without this file, access to all Oracle GoldenGate commands is granted to all users.
To implement command security
Open a new ASCII text file.
Referring to the following syntax and the example on "Sample Cmdsec File with Explanations", create one or more security rules for each command that you want to restrict, one rule per line. Order the rules from the most specific (those with no wildcards) to the least specific. Security rules are processed from the top of the CMDSEC file downward. The first rule satisfied is the one that determines whether access is allowed.
Separate each of the following components with spaces or tabs.
command_name command_object user_group user YES|NO
Where:
command_name is a GGSCI command name or a wildcard, for example START or STOP or *. Command names are not validated for accuracy.
command_object is any GGSCI command object or a wildcard, for example EXTRACT or REPLICAT or MANAGER. Command objects are not validated for accuracy.
user_group is the numeric ID of the Guardian user group, such as 100 or 255. You can use a wildcard to specify all groups.
user is the Guardian user numeric ID, such as 2 or 255. You can use a wildcard to specify all users.
YES|NO specifies whether access to the command is granted or prohibited.
Save the file as CMDSEC in the Oracle GoldenGate installation location
The following example illustrates the correct implementation of a CMDSEC file on a NonStop system.
Table 5-2 Sample Cmdsec File with Explanations
| File Contents | Explanation |
|---|---|
--GG command security |
Comment line |
STATUS REPLICAT 100 15 NO |
|
STATUS * 100 * YES |
Except for the preceding rule, all users in |
START REPLICAT 255 * YES |
|
START REPLICAT * * NO |
Except for the preceding rule, |
* EXTRACT 200 * NO |
All |
* * 255 255 YES |
Grants the |
* * * * NO |
Denies all commands to all users. This line covers security for any other users that were not explicitly granted or denied access by preceding rules. Without it, all commands would be granted to all users except for preceding explicit grants or denials. |
Table 5-3 Incorrect CMDSEC Entries
| File Contents | Description |
|---|---|
STATUS REPLICAT 100 15 NO |
|
STOP * 100 * NO |
All |
STOP * * 15 YES |
All |
The above incorrect example illustrates what to avoid when creating a CMDSEC file. The order of the entries in 4 causes a logical error. From the first rule (line 1), you can see that user 15 is a member of group 100. The second rule (line 2) denies all STOP commands to all members of group 100. The third rule (line 3) grants all STOP commands to user 15. However, because 15 is a member of the 100 group, he has been denied access to all STOP commands by the second rule.
The proper way to configure this security rule is to set the user-specific rule before the more general rules. Thus, to correct the error, you would reverse the order of the two STOP rules.
Because the CMDSEC file is a source of security, it must be secured. You can grant read access as needed, but Oracle GoldenGate recommends denying write and delete access to everyone but the Oracle GoldenGate administrator. For example, a proper security string might be "NUUU".