We use Oracle native network encryption which gives us the ability to encrypt database connections, without the configuration overhead of TCP/IP and SSL/TLS and without the need to open and listen on different ports.
Below are the extra parameters we have for the encryption/data integrity
ENCRYPTION_WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /etc/wallets/<SID>/))) sqlnet.encryption_server=required sqlnet.crypto_checksum_server=required
Parameter 1 is for securing the data at ‘rest’.
Parameters 2 and 3 are related to encryption for data “in motion” .
Parameters 2 and 3 are related to encryption for data “in motion” .
Note that there can be many other parameters and parameters combinations. More details can be found in in this Oracle link: https://docs.oracle.com/cd/B28359_01/network.111/b28530/asoappa.htm#g638255
Detail of each parameter that we are using:
1) ENCRYPTION_WALLET_LOCATION
This is “Oracle Advanced Security Transparent Data Encryption” parameter
This is “Oracle Advanced Security Transparent Data Encryption” parameter
Transparent data encryption helps protect data stored on media in the event that the storage media or data file gets stolen. Transparent data encryption enables you to encrypt sensitive data, such as credit card numbers, stored in table columns.
2) SQLNET.ENCRYPTION_SERVER PARAMETER
This is “Oracle Advanced Security Network Encryption” parameter
This parameter specifies the desired encryption behavior when a client or a server acting as a client connects to this server.
This is “Oracle Advanced Security Network Encryption” parameter
This parameter specifies the desired encryption behavior when a client or a server acting as a client connects to this server.
Valid Values for this parameter:
ACCEPTED, REJECTED, REQUESTED, REQUIRED
=> ACCEPTED – The server does not request the use of encryption, but goes along if the client requests it. Compatible server parameters are REJECTED, REQUESTED, and REQUIRED.
=> REJECTED – The server does not support the use of encryption at all. Compatible client parameters are REJECTED, ACCEPTED, and REQUESTED.
=> REQUESTED – The server prefers to use encryption, but does not force the issue if the client rejects the use of encryption. Compatible client parameters are ACCEPTED, REQUESTED, and REQUIRED.
=> REQUIRED – The server demands the use of encryption, and does not connect otherwise. Compatible client parameters are ACCEPTED, REQUESTED, and REQUIRED.
ACCEPTED, REJECTED, REQUESTED, REQUIRED
=> ACCEPTED – The server does not request the use of encryption, but goes along if the client requests it. Compatible server parameters are REJECTED, REQUESTED, and REQUIRED.
=> REJECTED – The server does not support the use of encryption at all. Compatible client parameters are REJECTED, ACCEPTED, and REQUESTED.
=> REQUESTED – The server prefers to use encryption, but does not force the issue if the client rejects the use of encryption. Compatible client parameters are ACCEPTED, REQUESTED, and REQUIRED.
=> REQUIRED – The server demands the use of encryption, and does not connect otherwise. Compatible client parameters are ACCEPTED, REQUESTED, and REQUIRED.
3) SQLNET.CRYPTO_CHECKSUM_SERVER PARAMETER
This is “Oracle Advanced Security Network Data Integrity” parameter
Note that the advanced security data integrity functionality is separate to network encryption. Data encryption and integrity algorithms are selected independently of each other. Encryption can be activated without integrity, and integrity can be activated without encryption
This is “Oracle Advanced Security Network Data Integrity” parameter
Note that the advanced security data integrity functionality is separate to network encryption. Data encryption and integrity algorithms are selected independently of each other. Encryption can be activated without integrity, and integrity can be activated without encryption
This parameter specifies the desired data integrity behavior when a client or another server acting as a client connects to this server.
Valid Values for this parameter:
ACCEPTED, REJECTED, REQUESTED, REQUIRED
=> ACCEPTED – The server does not request the use of checksums, but goes along if the client requests them. Compatible server parameters are: REJECTED, REQUESTED, and REQUIRED.
=> REJECTED – The server does not support the use of checksums at all. Compatible client parameters are REJECTED, ACCEPTED, and REQUESTED.
=> REQUESTED – The server prefers to use checksums, but does not force the issue if the client rejects their use. Compatible client parameters are ACCEPTED, REQUESTED, and REQUIRED.
=> REQUIRED – The server demands the use of checksums, and does not connect otherwise. Compatible client parameters are ACCEPTED, REQUESTED, and REQUIRED.
=> ACCEPTED – The server does not request the use of checksums, but goes along if the client requests them. Compatible server parameters are: REJECTED, REQUESTED, and REQUIRED.
=> REJECTED – The server does not support the use of checksums at all. Compatible client parameters are REJECTED, ACCEPTED, and REQUESTED.
=> REQUESTED – The server prefers to use checksums, but does not force the issue if the client rejects their use. Compatible client parameters are ACCEPTED, REQUESTED, and REQUIRED.
=> REQUIRED – The server demands the use of checksums, and does not connect otherwise. Compatible client parameters are ACCEPTED, REQUESTED, and REQUIRED.
No comments:
Post a Comment