4 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 4-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:

  • The trail or extract file that holds data being processed by Oracle GoldenGate

  • A database password

  • The data sent across TCP/IP

How Data is Encrypted?

The following encryption methods are available:

  • GGS: (Deprecated) GGS uses a 256-key byte substitution to obfuscate data.
  • Blowfish: (Deprecated). Blowfish is a symmetric block cipher that has a 64-bit block size and a variable key length from 32 bits up to 448. The Oracle GoldenGate implementation can take a variable-length key from 32 bits to 128 bits.
  • Advanced Encryption Standard: AES is a Symmetric-key encryption using a block cipher with a fixed block size of 128 bits. The Oracle GoldenGate implementation supports all three key sizes of 128, 192, or 256 bits.
  • Encrypting data sent across TCP/IP: AES encryption methods are available to encrypt data over TCP/IP when used from NSK to NSK. This is not supported for an OpenSys target.
  • Encrypting trails or extract files.

    AES encryption method is available to encrypt trails or extract files.

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 parameter.
    ENCRYPTTRAIL

  2. To disable encryption for any files or trails listed in the Extract parameter file, precede their entries with the following parameter:

    NOENCRYPTTRAIL

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

  2. Copy the encrypted password and paste it into the Oracle GoldenGate parameter file as follows.
    USERID user_id, PASSWORD password, ENCRYPTKEY 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 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.

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.
  3. In the Extract parameter file, use the ENCRYPT option of the RMTHOST parameter to specifythe type of encryption and the logical key
  4. If using a static Collector , append the following additional parameters in the Collector startup string:
    -ENCRYPT <type>
-KEYNAME <name>

    Where:

    • KEYNAME name specifies the name of the key.
    • ENCRYPT type specifies the encryption type.

    Collector matches these parameters to those specified with the KEYNAME and ENCRYPT options of RMTHOST.

For more information about ENCRYPT and KEYNAME, see Reference Guide for Oracle GoldenGate for HP NonStop (Guardian)

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:

  • Encrypt data sent across TCP/IP

  • Use a user-defined key to encrypt the database password

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 128 bits (16 bytes), 192 bits (24 Bytes), or 256 bits (32 bytes) as a quoted alphanumeric string or a hex string with the prefix 0x.

    Note:

    The Hex format is twice the count.

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.

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.

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