Configuring Oracle GoldenGate Security

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

Security feature

Description

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

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

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.

Encrypting a Database Password

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.

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

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.

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

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.
```
## Key name            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.
```

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

Open a new ASCII text file.
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.
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".