Teradata Database security

Teradata Database security is based on the following concepts.

Security Element	Description
User	An individual or group of individuals represented by a single user identity.
Privileges	The database privileges explicitly or automatically granted to a user or database.
Logon	The process of submitting user credentials when requesting access to the database.
Authentication	The process by which the user identified in the logon is verified.
Authorization	The process that determines the database privileges available to the user.
Security Mechanism	A method that provides specific authentication, confidentiality, and integrity services for a database session.
Network Traffic Protection	The process for protecting message traffic between Teradata Database and network-attached clients against interception, theft, or other form of attack.
Message Integrity	Checks data sent across the network against what was received to ensure no data was lost or changed.
Access Logs	Logs that provide the history of users accessing the database and the database objects accessed.

Users

Users that access Teradata Database must be defined in the database or a supported directory.

Permanent Database Users

The CREATE USER statement defines permanent database users. Teradata recommends that the username represent an individual. Each username must be unique in the database.

Directory-based Users

Directory-based users that access the database must be defined in a supported directory.

Creation of a matching database user may or may not be required, depending upon implementation. One or more configuration tasks must be completed before directory users can access the database.

Proxy Users

Proxy users are end users who access Teradata Database through a middle-tier application set up for trusted sessions. They are authenticated by the application rather than the database.

The GRANT CONNECT THROUGH statement assigns role-based database privileges to proxy users. To establish privileges for a particular connection to the database, the application submits the SET QUERY_BAND statement when it connects the user. The SET QUERY_BAND statement and the rules for how it is applied to each proxy user must be coded into the application as part of setup for trusted sessions.

Database Privileges

Users can access only database objects on which they have privileges. The following table lists the types of database privileges and describes how they are acquired by a user.

Privilege	Description
Implicit (Ownership)	Privileges implicitly granted by the database to the owner of the space in which database objects are created.
Automatic	Privileges automatically provided by the system to: • The creator of a database, user, or other database object. • A newly created user or database.
Inherited	Privileges that are passed on indirectly to a user based on its relationship to another user or role to which the privileges were granted directly. • Directory users inherit the privileges of the database users to which they are mapped. Directory users who are members of groups also inherit the privileges defined in external roles to which the groups are mapped. • All users inherit the privileges of PUBLIC, the default database user, whether or not they have any other privileges.
Explicit (GRANT)	Privileges granted explicitly to a user or database in one of the following ways: • GRANT directly to a user or database. • GRANT to a role, then GRANT the role to one or more users.

Directly Granted Privileges

Privileges can be directly given to users with the GRANT statement. Administrators GRANTing a privilege must have been previously granted the privilege they are granting, as well as the WITH GRANT OPTION privilege on the privilege.

Roles

Roles can be used to define privileges on database objects for groups of users with similar needs, rather than granting the privileges to individual users. Roles also require less dictionary space than individually granted privileges. Use the CREATE ROLE statement to define each role, then use the GRANT statement to grant roles to users. The CREATE USER statement must also specify the default role for the user. The MODIFY USER statement can be used to assign additional user roles.

A member of a role may access all objects to which a role has privileges. Users can employ the SET ROLE statement to switch from the default to any alternate role of which the user is a member, or use SET ROLE ALL to access all roles.

Roles for Proxy Users

Proxy users are users that access the database through a middle-tier application set up to offer trusted sessions. Proxy users are limited to privileges defined in roles that are assigned to them using the GRANT CONNECT THROUGH statement.

External Roles

Use external roles to assign role privileges to directory users. External roles are created exactly like database roles; however, they cannot be granted to directory users because these users do not exist in the database. Instead, directory users must be members of groups that are mapped to external roles in the directory.

Directory users mapped to multiple external roles have access to all of them at logon to the database.

Profiles

To simplify user management, an administrator can define a profile and assign it to a group of users who share similar values for the following types of parameters:

• Default database assignment

• Spool space capacity

• Temporary space capacity

• Account strings permitted

• Password security attributes

User Authentication

At logon to the database, users are authenticated, meaning their identity is verified and checked against a list of approved users. Authentication comprises the following elements:

• Authentication method

• Logon formats and controls

• Password formats and controls

Authentication Method

To identify the method by which they will be authenticated, users must choose a security mechanism as part of the logon string. Security mechanisms also contain configurable properties for customizing user authentication and authorization. If a mechanism is not specified in the logon string, the system will use the default mechanism.

Two categories of authentication are available:

• Teradata Database authentication

• External authentication

Teradata Database Authentication

Authentication by Teradata Database requires that the user and its privileges be defined in the database. Teradata Database authentication requires use of the TD2 mechanism, which is the default. Unless another mechanism has been set as the default, TD2 need not be specified at logon.

External Authentication

External authentication allows Teradata Database users to be authenticated by an agent running on the same network as Teradata Database and its clients.

External authentication is dependent upon two elements:

• The authenticating agent indicated by the security mechanism specified in the logon.

• The logon type, which determines how user credentials are submitted.

The following table shows the different types of external authentication logons.

Type	Description		Requirements
Sign-on without resubmitting user credentials
Single Sign-on	Users are authenticated in the client domain. Subsequent logons to Teradata Database do not require them to resubmit a username and password.	• The username employed to log on to the client domain must match the Teradata Database username. • The logon must specify a mechanism that corresponds to the authenticating application (Kerberos, NTLM, or SPNEGO) or it must be the default mechanism. • The logon must specify the tdpid of the database, and optional account string information.
Sign-on with user credentials
Directory Sign-on	The user is authenticated by the directory.	• The user must log on with a directory username. • The logon must specify the LDAP mechanism.
Sign-on As	The user logs on to Teradata Database with a username and password recognizable by the client domain.	• The username must be defined in the database. • The user must select a mechanism that corresponds to the authenticating application (Kerberos, LDAP, NTLM, or SPNEGO) or it must be the default mechanism.

Logon Format

Logons to Teradata Database can take the following forms:

• Command line

• Graphical User Interface (GUI)

• Logon from a mainframe-attached client

• Logon through a middle-tier application

Command-Line Logon

Users provide the following information when logging on from a workstation-attached client:

• .logmech: Specifies the name of the security mechanism that defines the method by which the user will be authenticated and authorized. If a mechanism is not specified, the logon proceeds using the designated default mechanism.

• .logdata: Used only for external authentication. Specifies the username and password, and optionally names an individual username, profile, or role where the logon user has access to multiple user identities, profiles, or roles.

• .logon: Must be used for Teradata Database authentication. May be used for external authentication except when the logon requires specification of user=, profile=, or realm= to differentiate among multiple user identities, profiles, or realms.

For either authentication type, .logon specifies the tdpid, username, password, and optional account string information.

Note: The format required for the username and password information varies depending on the user is sign-on method.

GUI Logons

Some Teradata Database client applications provide a logon GUI in the form of dialog boxes. The dialog boxes provide fields and buttons that prompt the user to enter the same logon information shown for command-line logons.

Logons from Mainframe-Attached Clients

Sessions logged on from mainframe-attached clients do not support network security features, such as security mechanisms, encryption, or directory management of users. Such logons require submittal of only the username, password, tdpid, and optional account string information using the .logon command.

Logons Through Connection Pools

Some users access the database through a middle-tier application. The application must log on to Teradata Database with a database username. The application then sets up a connection pool that allows individual end users access to the database but does not require that the users formally logon. End user privileges are determined by whether or not the application and its end-users are set up for trusted sessions.

Logon Controls

Teradata Database automatically grants permission for all users defined in the database to logon from all connected client systems. But administrators can, for example:

• Modify current or default logon privileges for specific users.

• Give individual users permission to log on to the database only from specific mainframe or workstation interfaces.

• Set the maximum number of times a user can submit an unsuccessful logon string.

• Enable authentication of the user by an external application, such as Kerberos or LDAP.

• Restrict access to the database based on the IP address of the machine from which a user logs on.

Password Format Requirements

Passwords must conform to password format rules, which govern the type and number of characters allowed in the password.

Password Controls

Teradata Database provides controls to enable the administration of passwords.

Administrators can, for example:

• Restrict the content of passwords:

• Define limits on minimum and maximum password characters.

• Allow or require that passwords contain upper and lowercase characters, digits, or special characters.

• Allow or deny use of restricted words.

• Set the number of days for which a password is valid.

• Assign a temporary password.

• Set the lockout time after the user has exceeded the maximum number of logon attempts.

• Define the period during which a user may not reuse a previous password.

User Authorization

Once users have been authenticated, they are authorized database privileges according to their defined privileges.

Authorization of Permanent Database Users

Permanent database users are defined in the database with a CREATE USER statement. Once authenticated at logon, permanent users are authorized the following privileges:

• Privileges granted directly to the user with the GRANT statement.

• Privileges indirectly given to the user (automatic, implicit, and inherited privileges).

• Privileges granted to a role that has been granted to the user.

Note: Users with more than one role automatically have access to the default role or all their roles, as specified in the CREATE USER statement. The SET ROLE statement allows users to access roles other than their default role.

Authorization of Directory-Based Users

After being authenticated by the directory, directory-based users are authorized database access privileges according to the following rules:

• If the directory maps users to Teradata Database objects (users, external roles, and profiles), each directory user is authorized the privileges of the objects to which it is mapped.

• If the directory does not map users to Teradata Database objects, but the directory username matches a Teradata Database username, the directory user is authorized all the privileges belonging to the matching Teradata Database user.

• If a directory user is neither mapped to any database objects, nor does the directory

username match a Teradata Database username, the directory user has no privileges to

access the database.

Note: One or more setup tasks (depending on implementation) must be completed before a directory user can access the database.

Authorization of Middle-tier Application Users

Middle-tier applications may stand between end users and Teradata Database, accepting requests from users, constructing queries from those requests, passing the queries to the database, and then returning results to the users. The middle-tier application logs on to the database, is authenticated as a permanent database user, and establishes a connection pool. The application then authenticates the individual application end users, some of whom may request access to the database through the connection pool.

By default, all end-users accessing the database through a middle-tier application are authorized database privileges and are audited in access logs, based on the single permanent database user identity of the application. For sites that require end users to be individually identified, authorized, and audited, the middle-tier application can be configured to offer trusted sessions. Application end-users that access the database through a trusted session must be set up as proxy users and assigned one or more database roles, which determine their privileges in the database. When a proxy user requests database access, the application automatically forwards the user identity and applicable role information to the database.

Data Protection

Teradata Database provides the following features to enhance data protection:

• By default, the logon string is encrypted to maintain the confidentiality of the username and password employed to log on to Teradata Database.

• Optional data encryption of messages maintains confidentiality of the data transmitted to and from Teradata Database.

• Automatic integrity checking insures that the data is not corrupted during the encryption/ transmission/decryption cycle.

• Optional BAR and DSA encryption provides confidentiality of data backups between the BAR server and the storage device.

• Optional SSL/TLS protection for systems using LDAP authentication with simple binding, including:

• Encryption of the LDAP authentication sequence between Teradata Database and the directory server.

• Advanced TLS protection, which requires that the database authenticate itself to the directory or that the database and directory mutually authenticate.

• Optional SASL protection for systems using LDAP authentication with Digest-MD5 binding:

• Protection of the LDAP authentication token exchange sequence between Teradata Database and the directory server.

Directory Management of Users

Normally, users that log on to Teradata Database have been defined in the database using a CREATE USER request. However, because many potential database users may already be defined in a directory running within the client network, Teradata Database allows for authentication and authorization of users by supported directories. Integration of directory managed users simplifies administration by eliminating the need to create a database instance for every user.

Supported Directories

Teradata Database is certified for use with the following directories:

• Active Directory

• Active Directory Application Mode (ADAM)

• Novell eDirectory

• Sun Java System Directory Server

• Other LDAPv3-compliant directories may be usable. Contact Teradata Professional Services for integration assistance.

Database Security Monitoring

To ensure optimal database security, the security administrator should configure the system to audit security events, and then monitor the logs to detect breaches in security and, where necessary, repel security threats. If unauthorized or undesirable activity is detected, the administrator can take remedial actions to address the problem.

Security Monitoring

Teradata Database provides the capability for two types of user security monitoring:

• All user logon and logoff activity is automatically collected in the Event Log and can be accessed using the DBC.LogOnOffV system view.

Listed parameters include:

• Database username

• Session number

• Logon events, including the causes of any unsuccessful logons

• Optional access logging records user attempts to access the database and can be accessed using the DBC.AccessLogV view, including the following access parameters:

• Type of access

• Type of request

• Requesting database username

• Referenced database object

• Frequency of access

Note: Access log entries are generated each time the database checks a privilege to determine whether or not it will honor a user request.

Logging of Directory Users

Directory users are logged by directory username rather than by the name of any database

user they may be mapped to.

Logging of Middle-tier Application Users

Users that access the database through a middle-tier application by means of a trusted session and who are set up as proxy users are logged by their proxy user name. If the middle-tier application and its end users are not set up for trusted sessions, all such users will appear in the log as the same username, that is, the name used by the application.

Enabling and Disabling Access Logging Use the BEGIN and END LOGGING statements to enable and disable logging and to indicate which access parameters should be logged. Access logging can be set up for almost any database object, for instance, users, databases, or tables.

Security-related System Views

The Data Dictionary provides s number of security-related system views, including the following.

View	Description
DBC.AccessLogV	Each entry indicates a privileges check that has resulted from a user request.
DBC.AccLogRulesV	Lists the access logging rules contained in each BEGIN and END LOGGING statement. These rules are used by the database to determine the access logging criteria for a particular user or database object.
DBC.LogOnOffV	Lists all logon and logoff activity.
DBC.LogonRulesV	Lists the logon rules that result from GRANT and REVOKE LOGON statements. These rules are used by the database to determine whether or not to allow logon privileges to a particular user.

Defining a Security Policy

Your security policy should be based on the following considerations:

• Determine your security needs to balance the need for secure data against user needs for quick and efficient data access.

• Review Teradata Database security features to meet your needs.

• Develop a policy that includes both system-enforced and personnel-enforced features.

Publishing a Security Policy

To ensure administrators and users at your site understand and follow site-specific security procedures, the administrator should create a security handbook. The handbook should summarize how you are using Teradata Database security features for your database and should be published and made available to all users.

A security policy document should include:

• Why security is needed.

• Benefits for both the company and the users of adhering to the security policy.

• A description of the specific implementation of Teradata Database security features at your site.

• Suggested/required security actions for users and administrators to follow.

• Whom to contact when security questions arise.

Credits:

Pankaj Chahar