Like other database systems, the Teradata provides solutions for system security. Security is the protection of data against unauthorized access. The controls available to maintain Teradata security include:
 

• Software-enforced access restrictions
• Physical access restrictions
• System auditing of security-related user actions in the Teradata RDBMS
• Security policy

Resource access control is one of the most important protections, the Teradata provides software tools to enforce access restrictions, including user identifiers, client identifiers, logon policies, password security, etc. Besides the general methods, there are a number of add-on features to enhance Teradata RDBMS security.


Resource Access Control
 

There are two aspects of resource access control, controlling access to the Teradata RDBMS and controlling data access. That means, we should not only be able to prevent unauthorized persons from gaining access to stored data, but also be able to restrict legitimate Teradata RDBMS users access to only those resources they are authorized to use.  There are three major phases of system access control. First, identifying and verifying each parameter of the logon request; second, identifying each session in association with the conducting user, third, controlling user access to stored data during that session.
 

Controlling Access to the Teradata RDBMS

Generally, controlling access to the Teradata RDBMS is based on logon process. It identifies the username and password, and acknowledges only users it recognizes as currently authorized to access the system. In addition, the Teradata RDBMS also can verify that the logon request originated from a client system connection such as LAN, WAN, or mainframe channel that has been specifically associated with the user name. The Teradata software tools supporting these controls including:

• User identifiers (user names)
• Channel or LAN identifiers (host, or client identifiers)
• Logon policies
• Password control
• TDP user security interface
• Client security

Besides the general features of these software tools which are also applied in many other database systems, several password control features enhance Teradata security as shown in the table.
 
 

Password Feature	Description	Rules
Expiration	Defines a time span which the password is valid.	DBC.SysSecDefaults table maintains a password change date, which will be compared to the current date to determine if the password is still valid.
Password Format	Restricts the number of characters, digits, or special characters permitted in a password.	Rules are identical to those for naming objects.
Maximum logon attempts	Defines the sequential number of erroneous logon attempts permitted before locking the user from further attempts.	If the number of erroneous logon attempts reaches the value specified in DBC. SysSecDefaults, the User ID is locked out from further attempts for the duration of the password lockout time.
Lockout time	Sets the time duration of the user lock after the user has exceeded the max. number of erroneous logon attempts.	The LockedUserExpire column of table DBC. SysSecDefaults contains the Lockout time value.
Reuse	Defines the time span that must elapse before a previously used password can be reassigned to the same user	The Department of Defense recommends that password not be reused for at least six months after expiration. The reuse denial period should be at least as long as the password lifetime.
Password Encryption	Storing Encrypted password characters.	The encrypted password is stored in the password string field of the DBC.DBase table.

 

Password default are controlled by a row in the table underlying the system view DBC.SecurityDefaults. One row defines all default parameters. The current default settings by selecting all columns of the DBC.SecurityDefaults view as follows:

select * from dbc.securitydefaults;

Upon successful logon, the user name is associated with a unique session number and associated with a default storage area. The user activities during a session will be controlled by the rules of Data Access control which is associated with access right.


Controlling Data Access

Controlling data access is mainly deal with access right. Access right are granted in the following ways:
 

• Automatically by the system to the creator of an object
• Explicitly to a user by the GRANT statement
• Implicitly to the owner of an object

Automatic rights mean the system automatically grants to the creator of a database, user, or object, and to a newly created user or database. For example, a new user or database is automatically granted all rights on itself, like create tables, views, and macros with in his own user space.

Implicit rights, also called ownership rights, are implicitly granted to the immediate owner and to all indirect owners. Ownership rights can not be revoked, but they are subject to logon control when access logging is specified for the particular right.

The GRANT and REVOKE statements are used for explicit rights, for example, user A can create user B and grant explicit rights by the GRANT statement:
 

GRANT TABLE, VIEW, MACRO, SELECT, INSERT, UPDATE, DELETE, DUMP, RESTORE, CHECKPOINT, EXECUTE ON b TO b;

GRANT USER, DATABASE, TABLE, VIEW, MACRO, SELECT, INSERT, UPDATE, DELETE, WITH GRANT OPTION, DUMP, RESTORE,  CHECKPOINT, EXECUTE ON b TO a;

Examples of GRANT and REVOKE statements and output

The user submitting the GRANT or REVOKE statement must be an owner of the object, or must have the GRANT privilege, plus all of the privileges that are to be conferred or revoked, on the object. DBC is the initial user in the Teradata system, it has all privileges. When creating other users, DBC has the right to grant any or all these privileges to any or all users.


Auditing and Monitoring Access
 

Auditing and monitoring access to the Teradata RDBMS can provide security administrator system safety information on the following:

• potential break-ins;
• attempts to gain unauthorized access to database resources;
• attempts to alter the behavior of the Teradata RDBMS auditing facilities.

These information are important reference for establishing the security policy.

The Teradata RDBMS supplies software tools for monitoring access information. Views in the Data Dictionary provide information about users and access rights and grant, logon and access activities. It can be used to automatically audit all logon and logoff activity, or access the specified attempts. For example, security administrator can monitor all access requests, or only those denied request, depending on the situations. During normal operations, data is selected from the auditing log using statements composed in the Teradata Structure Query Language (SQL). Queries regarding the use of system monitoring or production control features can be made much like other SELECT queries. All parameters of the SELECT statement may be used to query system views.

Sample queries regarding system auditing and monitoring and outputs
 

BEGIN LOGGING and END LOGGING is the DDL statement, which start and stop the auditing of data access requests, can be used to monitor the access rights checks performed by the Teradata RDBMS. When a user named in a BEGIN LOGGING statement attempts to execute a specified action against a specified object, Teradata checks the access rights necessary to execute the statement according to the rules in AccLogRulesTb1. The privilege checks made and/or the access results are logged in the system table DBC.AccLogTb1. The BEGIN LONGGING statement can request checks on type of access, text of the request, frequency of access, action requested, name of the requesting user, and objects referenced. Logging can be terminated by submitting an END LOGGING statement. Following are BEGIN LOGGING and END LOGGING sample statements:
 

BEGIN LOGGING ON FIRST AND LAST ALTER ON DatabaseA;

...........

END LOGGING ON FIRST AND LAST ALTER ON DatabaseA;

This way, a log entry will be generated for the first and last ALTER against tables in DatabaseA, both the first and last granted and denied entry will be recorded. The contents of DBC.AccLogRuleTb1 can be monitored via the DBC.AccessLogRules system view, while the content of  DBC.AccLogTb1 can be monitored via the DBC.AccessLog system view. When an unauthorized or undesirable activity has been identified, the security administrator can implement remedial action to correct the problem, such as any of the following:

• Changing the security policy
• Changing passwords that have been compromised
• Intensive auditing of all actions by particular users
• Changing access rights
• In extreme cases, denying the offending users any access to the Teradata RDBMS

Physical access control involves controlling access to the physical components of the computer system. Generally, controls need to be applied in the following area:
 

• Controlling machine room access
• Controlling access to outside devices
• Controlling access to dump files
• Controlling access to operating system

The primary consideration for physical access control is establishing a security policy, which can be used to ensure physical access to the Teradata RDBMS and the hardware on which it runs.


Establishing security policy
 

The security policy consists of those procedures and regulations intended to maintain the desired level of system security. The security policy for the Teradata RDBMS should include two essential implementation elements:

• System-enforced security features
• Personnel-enforced security features ( via the administrator, operator, and end users)

• Identification of security needs.
• Identification of policies and procedures to meet those needs.

Identifying Security needs and security levels
 

The first step to establish a security policy is to identify security needs, which will involve the following:
 

• Identifying the business importance of the data and its associated processing system.
• Assigning a security priority to the data, based on the business case evaluation.
• Identifying the classes of users requiring access to the Teradata RDBMS and the data under its control.
• Identifying the system resources requiring protection to ensure continued availability to all valid Teradata users.

The security requirements should be based on the business value of the data processed on the system. A system that stores and processes highly sensitive data probably has a greater need for security than one that does not.

There are three levels of data security, including minimal, moderate, and high. Each level will have its advantages and disadvantages:
 

• Minimal security    Anyone who has successfully logged on to the system has unrestricted access to all data and Teradata RDBMS resources. No security-related auditing is done, and there is no formal security policy. The only security-related access restriction is that a user must first gain access to a client system that is capable of communicating with the Teradata RDBMS. All these make sharing information is extremely simple, and the system performance is enhanced by the lack of security enforcement activities. On the other hand, obviously, the data is subject to destroy or corrupt due to the luck of the system security control.

• Moderate security    In this class, users are grouped according to their needs and trustworthiness. Under moderate security, unlimited access is reserved for a small, privileged subgroup. Only occasional auditing of security-related events is performed, and no formal security policy exists for the users. In this class, security-related events that have a little or no effect on system performance, and users are subject to little or no demand for additional effort to perform their work, but the disadvantage is  that it's possible that serious violation attempt can go undetected for extended periods.

• High security    At this level, a security administrator is identified and charged with establishing and maintaining Teradata RDBMS security. Physical access to processors, disk storage units, and system consoles is carefully controlled. Security-related events are audited regularly. Random security audits of individual users are performed. In this class, data and processing resources are afforded a high level of protection. If an unauthorized access is attempted, the auditing policy is designed to both detect the attempt and permit corrective measures to be implemented. The disadvantage is that shared data requires additional effort on the part of owner, as they must define who is authorized to access the owned information. Also, based on the frequency and scope of the audit, system performance can be negatively affected by the demands of auditing security-related events.

Formulating Security Policy
 

Once the security needs of the system have been defined, a security policy can be formulated. The security documents should cover:
 

• Extent of  the need for security
• Benefits to be derived form a secure system
• A defined management policy when a user is discovered attempting to violate security
• Password protection
• Granting access to data
• Computer room staff
• Contacting the security administrator

A system security policy does not remain static. Periodic reviews should be conducted to constantly reevaluate how the current policy meets current needs of the system. The factors including changes in the profiles of users, changes in business needs, new releases of Teradata software, discovery of security violations need to be considered for reviewing the security policy.