Configuring Oracle GoldenGate Security

This topic discusses the security features that you can use to protect your Oracle GoldenGate for HP NonStop environment as well as the data that is being processed.

This topic includes the following sections:

The following tables summarizes the security features that are available in Oracle GoldenGate for HP NonStop:

Table 1 Oracle GoldenGate Security Features

Security feature Description
Extract and Logger trail Extract and Logger trail files write locations are restricted from the Oracle GoldenGate Install subvol, $SYSTEM, and all TMF auditvol drives.
Encryption

Options are available for encrypting and decrypting:

  • data in an extract file or trail

  • database passwords

  • data sent across TCP/IP
Command security Sets user-level permissions for accessing Oracle GoldenGate commands through GGSCI.

Using Encryption

This section contains instructions for encrypting and decrypting the following:

How Data is Encrypted?

The following encryption methods are available:

Encrypting Trail or Extract Files

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

  1. 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 creating trails all with the same method of AES and KEYNAME.
ENCRYPTTRAIL (<AES>, KEYNAME <name>)
  1. To disable encryption for any files or trails listed in the Extract parameter file, precede their entries with the following parameter:
NOENCRYPTTRAIL
  1. In the Replicat parameter file, include the following parameter so that Replicat decrypts the data for processing.
DECRYPTTRAIL(<AES>, KEYNAME <name>)
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. For more information on `ENCRYPTTRAIL` and `DECRYPTTRAIL`, see *Reference Guide for Oracle GoldenGate for HP NonStop*.

Encrypting a Database Password

Use the following steps to encrypt the database password used by the Oracle GoldenGate processes.

  1. Run GGSCI and issue the ENCRYPT PASSWORD command to generate an encrypted password. The command provides the following options.

    • ENCRYPT PASSWORD with the KEYNAME keyname generates an encrypted password using a user-defined key contained in the ENCKEYS lookup file.

      ENCRYPT PASSWORD password KEYNAME *`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.

  2. Copy the encrypted password and paste it into the Oracle GoldenGate parameter file as follows.

    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.

    • KEYNAME keyname is required if the password was encrypted using ENCRYPT PASSWORD with the KEYNAME keyname option. Specify the logical name of the key as it appears in the ENCKEYS lookup file.

Encrypting Data Sent Across TCP/IP

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

  1. On the source system, generate one or more encryption keys and create an ENCKEYS file. See “Generating Encryption Keys” for more information.

  2. 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.
  1. 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 <AES>, KEYNAME *keyname*
  1. If using a static Collector and AES encryption, append the following additional parameters in the Collector startup string:
-KEYNAME *<name>*

-ENCRYPT <AES>
Where:

- `KEYNAME` *name* specifies the name of the key.

- `ENCRYPT` `<AES>` specifies `AES` encryption.

An example of encrypting data sent across TCP/IP:

RMTHOST sys1, MGRPORT 7840, ENCRYPT AES128, KEYNAME superkey
Collector matches these parameters to those specified with the `KEYNAME` and `ENCRYPT` options of `RMTHOST`.

Generating Encryption Keys

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:

You can define your own key or run the Oracle GoldenGate KEYGEN utility to create a key randomly.

To define your own key

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:

To store the keys for use by Oracle GoldenGate

  1. 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.

    ## Key name            Key Value
key128                 0x1c61821128a88711ef8f26046708918c
key192                 0xfcdca572c54491a21eda817de0fe71abbde14710dabf2864
key256                 0xb4abb3bd608e1c0567589dd38749e6cd51f6c55f6409da628b18c7d23f313df4

  2. Save the file as ENCKEYS without an extension in the Oracle GoldenGate installation location. The name must be in upper case.

  3. 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.

    Example 4-1 Using KEYGEN to Generate a Key

    TACL> RUN KEYGEN 128 4

Using Command Security

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

  1. Open a new ASCII text file.

  2. Referring to the following syntax and the example on “Table 4-2”, 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.
  1. 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 2 Sample Cmdsec File with Explanations

File Contents Explanation 
--GG command security
 Comment line 
STATUS REPLICAT 100 15 NO
 STATUS REPLICAT is denied to user 15 of group 100. 
STATUS * 100 * YES
 Except for the preceding rule, all users in 100 are granted all STATUS commands. 
START REPLICAT 255 * YES
 START REPLICAT is granted to all members of the Super (255) group. 
START REPLICAT * * NO
 Except for the preceding rule, START REPLICAT is denied to all users. 
* EXTRACT 200 * NO
 All EXTRACT commands are denied to all groups with ID of 200. 
* * 255 255 YES
 Grants the Super.Super user any command. 
* * * * 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 3 Incorrect CMDSEC Entries

File Contents Description 
STATUS REPLICAT 100 15 NO
 STATUS REPLICAT is denied to user 15 of group 100. 
STOP * 100 * NO
 All STOP commands are denied to everyone in group 100. 
STOP * * 15 YES
 All STOP commands are granted to user 15.

The above incorrect example illustrates what to avoid when creating a CMDSEC file. The order of the entries in Table 4-3 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.

Securing the CMDSEC File

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”.