In this guide, we’ll explore how to encrypt the communication between primary and standby databases in an Oracle Data Guard environment spread across different data centers. The focus is on encrypting only the Data Guard traffic without affecting other sessions like applications or regular user connections.
Table of Contents
- Introduction
- Prerequisites
- Understanding SQL*Net Encryption
- Configuring Network Encryption for Data Guard
- Testing the Configuration
- Conclusion
- References
Introduction
When setting up Oracle Data Guard across different data centers, it’s crucial to secure the communication channel between the primary and standby databases. Encrypting the Data Guard traffic ensures that sensitive data is protected during transmission. However, we want to limit the encryption to Data Guard operations without impacting other database sessions.
Prerequisites
Before proceeding, ensure the following:
- Oracle Database Enterprise Edition installed on both primary and standby servers.
- Oracle Data Guard is set up and configured between the primary and standby databases.
- Basic understanding of Oracle Net Services and SQL*Net configurations.
Understanding SQL*Net Encryption
Oracle Net Services provides network encryption capabilities through SQL*Net to secure data in transit. By configuring parameters in the sqlnet.ora file, you can control how encryption is applied between clients and servers.
Encryption Parameters
The primary parameters used for encryption are:
- SQLNET.ENCRYPTION_CLIENT: Specifies the encryption behavior when the client initiates a connection.
- SQLNET.ENCRYPTION_SERVER: Specifies the encryption behavior when the server accepts a connection.
- SQLNET.ENCRYPTION_TYPES_CLIENT: Defines the encryption algorithms the client supports.
- SQLNET.ENCRYPTION_TYPES_SERVER: Defines the encryption algorithms the server supports.
Encryption Settings
The possible values for SQLNET.ENCRYPTION_CLIENT and SQLNET.ENCRYPTION_SERVER are:
- REQUIRED: Encryption is mandatory; connections fail if encryption cannot be negotiated.
- REQUESTED: Encryption is requested but not required; connections proceed even if encryption isn’t established.
- ACCEPTED: Encryption is accepted if requested by the other side.
- REJECTED: Encryption is not used, and connections fail if the other side requires it.
Configuring Network Encryption for Data Guard
Our goal is to enforce encryption between the primary and standby databases for Data Guard communication while leaving other sessions unaffected. We’ll achieve this by setting specific parameters in the sqlnet.ora files on both the primary and standby servers.
Primary Database Configuration
On the primary server (which acts as the client when sending redo logs), add the following parameters to the sqlnet.ora file:
SQLNET.ENCRYPTION_SERVER = REQUESTED
SQLNET.ENCRYPTION_TYPES_SERVER = (AES128) Explanation:
- SQLNET.ENCRYPTION_SERVER = REQUESTED: The server requests encryption but will accept unencrypted connections. This setting ensures that regular client connections (like applications) are not forced to use encryption.
- SQLNET.ENCRYPTION_TYPES_SERVER = (AES128): Specifies that AES128 is the preferred encryption algorithm.
Standby Database Configuration
On the standby server (which acts as the client when receiving redo logs), add the following parameters to the sqlnet.ora file:
SQLNET.ENCRYPTION_CLIENT = REQUIRED
SQLNET.ENCRYPTION_TYPES_CLIENT = (AES128) Explanation:
- SQLNET.ENCRYPTION_CLIENT = REQUIRED: The client requires encryption; connections fail if encryption cannot be established. This ensures that the standby database only accepts encrypted redo data from the primary database.
- SQLNET.ENCRYPTION_TYPES_CLIENT = (AES128): Specifies that AES128 is the encryption algorithm to be used.
Handling Switchover and Failover
To accommodate switchover or failover scenarios where the standby becomes the primary, it’s recommended to have both sets of parameters on both servers:
On Both Primary and Standby Servers
SQLNET.ENCRYPTION_CLIENT = REQUIRED
SQLNET.ENCRYPTION_TYPES_CLIENT = (AES128)
SQLNET.ENCRYPTION_SERVER = REQUESTED
SQLNET.ENCRYPTION_TYPES_SERVER = (AES128) This configuration ensures that regardless of which database is primary or standby, the encryption settings remain consistent, and Data Guard communication stays encrypted.
Testing the Configuration
After updating the sqlnet.ora files, it’s essential to test the configuration to verify that Data Guard communication is encrypted.
Restart the Listener and Database Instances
On both servers, restart the Oracle Net Listener and database instances to apply the new settings:
-- Restart Listener
$ lsnrctl stop
$ lsnrctl start
-- Restart Database
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP; Verify Data Guard Synchronization
Ensure that the standby database is still receiving redo logs from the primary:
-- On Standby
SQL> SELECT THREAD#, SEQUENCE#, APPLIED
FROM V$ARCHIVED_LOG
ORDER BY SEQUENCE#; Check Network Encryption Status
To confirm that encryption is in effect, you can use Oracle’s tracing facilities or network packet analysis tools like Wireshark to inspect the traffic between the primary and standby databases.
Also use an SQL to check encryption configuration, mainly at Standby (Server) side:
SQL> SELECT SID, NETWORK_SERVICE_BANNER FROM V$SESSION_CONNECT_INFO WHERE SID IN (SELECT SID FROM V$SESSION WHERE USERNAME = 'SYS');Conclusion
By carefully configuring the sqlnet.ora parameters on both the primary and standby databases, we’ve successfully encrypted the Data Guard communication between data centers without impacting other database sessions. This approach enhances security while maintaining flexibility for client connections.