Requiring Confidentiality | Teradata Vantage - 17.10 - Requiring Confidentiality - Advanced SQL Engine - Teradata Database

Teradata Vantage™ - Advanced SQL Engine Security Administration

Product
Advanced SQL Engine
Teradata Database
Release Number
17.10
Release Date
July 2021
Content Type
Administration
Security
Publication ID
B035-1100-171K
Language
English (United States)

You can use the gtwcontrol RequireConfidentiality flag to require the use of encryption globally, for all messages between the client and database.

Turning on RequireConfidentiality on the database system enforces message encryption for new sessions that are logged on after the flag is turned on, but traffic between client systems and the database system for existing (already logged on) sessions is not encrypted. In order to enforce traffic encryption on all the sessions that connect to the database system, all existing sessions must be logged off prior to turning on RequireConfidentiality. It is recommended to turn on the RequireConfidentiality option only when the system is quiescent.

To enable this functionality, use gtwcontrol:

gtwcontrol -x YES

If the system is set up with host groups, which are separate Vantage gateways for groups of IP addresses, you can set the confidentiality requirement separately for each host group, for example:

gtwcontrol -x YES -g [host_ID]

Also see Restricting Logons by Host Group, and Gateway Control (gtwcontrol) in Teradata Vantage™ - Database Utilities, B035-1102.

If no other confidentiality policy applies, a session that is subject to the RequireConfidentiality flag uses the DEFAULT QOP, as configured in the TdgssUserConfigFile.xml.

Teradata Tools and Utilities (TTU) clients: If the RequireConfidentiality flag is set, the gateway server sends the security policy information in the logon response back to the client, informing the client interface (such as ODBC, JDBC, CLI, or .NET Data Provider for Teradata) that all requests must be encrypted for this session. TTU client interfaces are able to read and comply with the security policy information in the logon response. This means the client silently follows the policy and encrypts the messages, whether or not the application enables or disables the data encryption option. So messages are automatically encrypted even though the enable data encryption option was not set. For example, if the user did not set the ODBC DSN encrypt option and RequireConfidentiality is set, messages are encrypted.

If other security policies that require the use of a stronger QOP also apply to the session, the system defers to the stronger QOP.