This chapter describes the features and methods available to establish and maintain Teradata Database security. Topics include: • Security library • Security features • Security mechanisms • User authentication • User authorization • Encryption
• Data integrity checking
• Directory management of users • Monitoring access to the database • Defining a security policy
• Publishing a security policy
Security Library
Teradata Database security is based on Teradata Database Generic Security Services library (TDGSS), which is included when you install Teradata Database software. TDGSS is composed of:
• A set of pre-configured security mechanisms.
• Editable configuration files that allow you to revise mechanism properties to meet unique security needs.
• A set of tools and interfaces for configuring and managing network security functions.
Security Features
Teradata Database security includes the following features:
• Security Mechanism: A mechanism selected at logon to set the security context for the session. Each security mechanism defines a unique security context.
Security Mechanisms
• User Authentication: Verification of user identity at logon. The system checks user name, password, and other optional user information against user data stored in the database. Only valid users can access the database.
• User Authorization: Authorization of users specifically granted privileges to create, alter, or delete data in the database. The system evaluates user SQL requests to perform such functions and authorizes user activity according to access privileges defined for that user in the database.
• Encryption: Data transmitted across the network is encoded by the system to provide confidentiality.
• Data Integrity: The system checks messages against what was sent to ensure that data has not been lost or corrupted during transmission across the network.
• Directory Management of Users: Supported directories can be configured to authenticate users and authorized database access privileges.
• Monitoring Access to the Database: Provides the ability to monitor database activity to identify violations, violators, and potential security hazards.
Security Mechanisms
Teradata Database employs security mechanisms to define the security context in which a database session will run. Each mechanism is composed of a number of properties that define the function of the mechanism. Some properties are editable. All security mechanisms are constructed using the TDGSS library.
Users may select from among several available security mechanisms at logon. If the user does not select a mechanism at logon, the session will automatically defer to the default
mechanism. Teradata Database currently provides the following standard, predefined security mechanisms.
Mechanism Usage
Teradata Method 2 (TD 2) Requests that Teradata Database perform user authentication. Use TD 2 only if the following are true:
• The client system is at TTU8.2 or later. • The server is at V2R6.0 or later.
Teradata Method 1 (TD 1) Requests that Teradata Database perform user authentication. This mechanism is used only to maintain compatibility with legacy software. The system automatically selects TD1 when needed, even if the user selects TD2.
User Authentication
User Authentication
Users are authenticated when they log on to the database through a Teradata Database client application. Teradata Database provides the following features for controlling user
authentication:
• Logon formats and controls • Password format and controls
• Optional user authentication by external applications
Kerberos (KRB5) Requests that the Microsoft Kerberos application perform user authentication (external authentication).
Use KRB5 for external authentication if either one of the following is true:
• The client systems is at TTU8.2 or later. • The server is at V2R6.0 or later.
Kerberos (KRB5C) Requests that the Microsoft Kerberos application perform user authentication (external authentication).
This mechanism is used only to maintain compatibility with legacy software. The system automatically selects KRB5C when needed, even if the user selects KRB5.
NTLM Requests that the Microsoft NT Lan Manager application perform
user authentication.
Use the NTLM mechanism for external user authentication if the following are true:
• The client systems is at TTU8.2 or later. • The server is at V2R6.0 or later.
NTLMC Requests that the Microsoft NT Lan Manager application perform user authentication.
This mechanism is used only to maintain compatibility with legacy software. The system automatically selects NTLMC when needed, even if the user selects NTLM.
LDAP Requests that a supported LDAP-compliant external directory perform user authentication.
Directory authentication of users is only available if the following are true:
• The client systems is at TTU8.2 or later • The server is at V2R6.0 or later
For details on use of directory-based security functions, see Security Administration.
User Authentication
Logon Formats
Teradata Database provides two logon formats for access to client applications: • Command line
• Graphical User Interface (GUI)
Command-Line Logon
Users provide the following information when logging on from a network-attached client: • .logmech: Specifies the name of the security mechanism that defines the security context
under which the session will operate. If a mechanism is not specified, the logon proceeds using the designated default mechanism.
• .logdata: Specifies the external username and password for user authentication by external applications. Also specifies the domain name when required by the application.
• .logon: Specifies the tdpid, database username and password, and optional account string information for user authentication by Teradata Database.
For more information on command-line logons, see Security Administration.
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 you to enter the same data required for a command-line logon. For an example of a GUI logon, see Security Administration.
Logons from Channel-Attached Clients
Sessions logged on from channel-attached clients do not support network security features such as security mechanisms, encryption, or directory management of users. Command-line logons from channel-attached clients use only the .logon field.
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 permissions for specific users.
• Give individual users permission to log on to the database only from specific client systems.
• 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 NTLM. • Restrict access to the database based on the IP address of the machine from which a user
logs on.
Password Format
User Authentication
A password can contain: • 1 to 30 characters
• Letters A through Z and/or a through z
• Digits 0 through 9 (in single or multibyte form)
A password can be all numeric only if it is enclosed in quotes • $ (dollar sign)
• _ (underscore) • # (pound sign)
A password cannot contain: • Katakana symbols
• Greek or Cyrillic characters • Multibyte spaces
• Special characters other than $ (dollar sign) or _ (underscore) or # (pound sign) not enclosed in quotes
• User-defined characters
• Any blank characters, such as NULL, LINE FEED, or CARRIAGE RETURN.
Note: Do not try to construct a password until you read the complete password format rules in Security Administration.
Password Controls
Teradata Database provides controls to enable the administration of passwords. Administrators can, for example:
• Restrict the content of password strings, defining limitations on minimum and maximum password characters, for instance, and whether or not passwords can contain digits or special characters.
• Set the number of days for which a password is valid. • Assign a temporary password.
• Set the user 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.
External Authentication
External authentication allows Teradata Database users to be authenticated by applications running on network-attached client systems.
User Authorization
There are three types of external authentication.
For complete information on external authentication and the mechanisms that support it, see
Security Administration.
User Authorization
Once users have been authenticated, they are only authorized to take actions that are allowed by their privileges. The following table lists the various types of database privileges and describes how they are acquired by a user.
Type Description Requirements
Sign-on without user credentials
(Single Sign-on)
Once users have been authenticated by the client system, they do not have to resubmit a username and password to access the database.
• Client domain username and Teradata Database username must match.
• The user must have LOGON WITH NULL PASSWORD privileges.
• User must select a mechanism that corresponds to the authenticating application (Kerberos or NTLM) or it must be the default mechanism. Sign-on using external credentials:
Directory Sign-on The user logs on to Teradata Database with a directory username.
• The user is authenticated by the directory.
• Once authenticated, the user is also authorized access according to the following rules:
• user automatically inherits the access privileges of Teradata Database user to which he or she is mapped.
• user also takes on any Roles or Profiles to which he or she is mapped.
• The directory must be supported by Teradata Database.
• The directory must be set up to map directory users to permanent Teradata Database users, roles, and profiles. Unmapped users will be limited to the default EXTUSER privileges. • Users must log on with their directory user
name.
• Users must select the LDAP mechanism.
Sign-on As The user logs on to Teradata Database with a username and password
recognizable by the client domain, and is authenticated by Kerberos or NTLM.
• Client domain username and Teradata Database username must match
• The user must have LOGON WITH NULL PASSWORD privileges.
• User must select a mechanism that corresponds to the authenticating application (Kerberos or NTLM) or it must be the default mechanism.
User Authorization
For additional information on the full range of available privileges and how to use SQL statements to GRANT and REVOKE them, see SQL Reference: Data Definition Statements.
Roles
Roles define user privileges on database objects for groups of users. In addition to a default role, an administrator can GRANT one or more roles to each user in addition to a default role. A member of a role may access all objects to which a role has privileges. As a user, you can use
SET ROLE to switch from the default to any alternate role of which you are a member. The use of roles provides two administrative advantages:
• Simplification of administration of privileges • Reduction of dictionary disk space
For more information on roles, see Database Administration. For more information on the management of directory roles, see “Directory Managed Roles” on page 169.
Profiles
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
Privilege Type How Acquired
Implicit Privileges Implicit privileges are acquired by default when a user owns a database object or owns the space in which the object was created. These are sometimes referred to as ownership privileges.
Explicit Privileges Explicit privileges on users, databases, or objects are given to a user by employing a GRANT statement or automatically when objects are created.
Privileges can either be granted directly to a user or to a role of which the user is a member.
Inherited Privileges Privileges may be inherited in the following ways:
• Being a member of a group that has privileges, as in the case of roles. • Subclass privileges are inherited by a user that has been GRANTed a
higher level of privileges that contain them.
• A directory user mapped to Teradata Database user inherits the privileges of that user.
Encryption
The use of profiles provides two administrative advantages: • Simplification of administration of parameters
• Simplification of control for user-level password security For further information on profiles, see Database Administration.
Encryption
Teradata Database supports encryption of data transmitted between client applications and Teradata Database. There are two types of encryption:
• Logon encryption: Automatically provided by Teradata Database to ensure the security of the passwords used in logon strings.
Passwords are encrypted by default where they are stored. Passwords are never decrypted. • Message encryption: Set to provide confidentiality for all data transmitted across the
network between the client and Teradata Database (optional).
Logon Encryption
When operating under default conditions, Teradata Database Gateway accepts only encrypted logons and rejects unencrypted ones. The administrator can control encryption using an option in the Gateway Control utility. For the gateway to accept both encrypted and unencrypted logons, the administrator must set a Gateway Control option to yes.
The client application cannot enable or disable logon encryption. Encryption is determined by the settings of Teradata Database Gateway.
Message Encryption
Teradata Database supports encryption of all data transmitted between network-attached clients and Teradata Database Gateway. When logging on, users may employ any one of several selectable security mechanisms to define the network security context for a session. All mechanisms support encryption.
The encryption/decryption cycle does have an effect on system performance, especially when applied to large-scale data transmission. Most client applications allow users to enable or disable data encryption for the duration of a session.
For further information on encryption, see Security Administration.
Data Integrity Checking
Teradata Database performs an automatic check of data integrity for all message transmissions (both encrypted and non-encrypted) across the network to ensure that data has not been changed, corrupted, or lost during transmission.
Directory Management of Users
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 interfaces with the following directories that conform to the Lightweight Directory Access Protocol (LDAP), version 3.
Directory User Logons
Directory users must logon on to the database using their directory user names. The logon must include the selection of the LDAP mechanism, unless it is the default mechanism.
Integrating Directory Users
To provide directory users more than the default EXTUSER (SELECT) privileges, the administrator must configure the directory to map the directory users to Teradata Database users, roles, and profiles.
Directory Managed Roles
Directory managed roles are handled differently from the way the administrator normally uses the ANSI-defined SQL statements to create, drop, grant, or revoke roles.
For directory users, the administrator uses the CREATE EXTERNAL ROLE or DROP EXTERNAL ROLE statements.
Teradata Database Operating Systems Supported Directories
Windows Server 2003 • Active Directory (all versions)
• Sun Java System Directory Server
• Other directories that support OpenLDAP
Windows Active Directory (all versions)
MP-RAS • Active Directory (all versions)
• Sun Java System Directory Server
• Other directories that support OpenLDAP
Linux • Active Directory (all versions)
Monitoring Access to the Database
The administrator creates special external roles that are only for directory users. Once the external roles have been created, the administrator must assign (not GRANT) them to directory users.
Profiles for Directory Users
Mapped directory users inherit the profile assigned to the permanent user to which they are mapped.
Additional profiles can be created and assigned directly to the directory user and will take precedence over the inherited profile.
Profiles can also be assigned to individual users that are mapped to EXTUSER by default.
Directory Tools
Teradata Database provides the following tools to search and validate directory content: • tdsbind: Diagnostic tool that allows you to determine the mapping between Teradata
Database objects and directory users.
• tdssearch: Tool that allows you to explore directory assignments and help resolve issues with failed logon attempts or data access denials.
These tools are installed as part of TDGSS and are run to query the directory. For more information about directory tools see, Security Administration.
Monitoring Access to the Database
Teradata Database automatically tracks all logon and logoff activity. However, you can apply certain Teradata Database features to specify additional audits of specific events in Teradata Database. Monitoring can help identify the following security hazards:
• Potential break-ins.
• Attempts to gain unauthorized access to database resources.
• Attempts to alter the behavior of Teradata Database auditing functions.
The security monitoring features can help you examine or print audit data during normal operation hours, or you can archive the data for later review by means of automated views and generated reports.
Feature Description
Data Dictionary Provides a repository from which you may check
access privileges, user access, demographics, and general database access information.
System Views Provides information views about users, their
access privileges, and historical data on grants, logons, and access activities.
Defining a Security Policy
If you identify unauthorized or undesirable activity, you can take one or more of the following remedial actions to address the problem:
• Do additional auditing of the actions of particular users. • Change compromised passwords.
• Modify the privileges of some users. • Revise your security policy.
• Deny the offending users any access to Teradata Database (in extreme cases). For more information about monitoring database access, see Security Administration.
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 security strategy that includes both system-enforced and personnel-enforced security 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. You should include the following topics in this document:
• Why security is needed.
• Benefits of adhering to the security policy for both the company and the users.
• A description of the specific implementation of Teradata Database security features at your site.
System View Queries Provides query capability on system views. This
minimizes having to look for specific information in large table views.
Access Logging Provides Data Definition Language (DDL)
statements that you can use to monitor database access. These access logging checks are executed using the BEGIN LOGGING and END
LOGGING statements.
For More Information
• Suggested/required security actions for users and administrators to follow. • Who to contact when security questions arise.
For More Information
For more information on the topics presented in this chapter, see the following Teradata Database and Teradata Tools and Utilities books.
If you want to learn more about… THEN see…