Security Administration

Security Administration

Release V2R5.1

B035-1100-083ANovember 2003

Teradata Database

The product described in this book is a licensed product of NCR Corporation.

BYNET is an NCR trademark registered in the U.S. Patent and Trademark Office.CICS, CICS/400, CICS/600, CICS/ESA, CICS/MVS, CICSPLEX, CICSVIEW, CICS/VSE, DB2, DFSMS/MVS, DFSMS/VM, IBM, NQS/MVS, OPERATING SYSTEM/2, OS/2, PS/2, MVS, QMS, RACF, SQL/400, VM/ESA, and VTAM are trademarks or registered trademarks of International Business Machines Corporation in the U. S. and other countries.DEC, DECNET, MICROVAX, VAX and VMS are registered trademarks of Digital Equipment Corporation.HEWLETT-PACKARD, HP, HP BRIO, HP BRIO PC, and HP-UX are registered trademarks of Hewlett-Packard Co.KBMS is a trademark of Trinzic Corporation.INTERTEST is a registered trademark of Computer Associates International, Inc.MICROSOFT, MS-DOS, MSN, The Microsoft Network, MULTIPLAN, SQLWINDOWS, WIN32, WINDOWS, WINDOWS 2000, and WINDOWS NT are trademarks or registered trademarks of Microsoft Corporation.SAS, SAS/C, SAS/CALC, SAS/CONNECT, and SAS/CPE are registered trademarks of SAS Institute Inc.SOLARIS, SPARC, SUN and SUN OS are trademarks of Sun Microsystems, Inc.TCP/IP protocol is a United States Department of Defense Standard ARPANET protocol.TERADATA and DBC/1012 are registered trademarks of NCR International, Inc.UNICODE is a trademark of Unicode, Inc.UNIX is a registered trademark of The Open Group.X and X/OPEN are registered trademarks of X/Open Company Limited.YNET is a trademark of NCR Corporation.

THE INFORMATION CONTAINED IN THIS DOCUMENT IS PROVIDED ON AN “AS-IS” BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. IN NO EVENT WILL NCR CORPORATION (NCR) BE LIABLE FOR ANY INDIRECT, DIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS OR LOST SAVINGS, EVEN IF EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

The information contained in this document may contain references or cross references to features, functions, products, or services that are not announced or available in your country. Such references do not imply that NCR intends to announce such features, functions, products, or services in your country. Please consult your local NCR representative for those features, functions, products, or services available in your country.

Information contained in this document may contain technical inaccuracies or typographical errors. Information may be changed or updated without notice. NCR may also make improvements or changes in the products or services described in this information at any time without notice.

To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization, and value of this document. Please e-mail: [email protected]

or write:

Information EngineeringNCR Corporation100 North Sepulveda BoulevardEl Segundo, CA 90245-4361U.S.A.

Any comments or materials (collectively referred to as “Feedback”) sent to NCR will be deemed non-confidential. NCR will have no obligation of any kind with respect to Feedback and will be free to use, reproduce, disclose, exhibit, display, transform, create derivative works of and distribute the Feedback and derivative works thereof without limitation on a royalty-free basis. Further, NCR will be free to use any ideas, concepts, know-how or techniques contained in such Feedback for any purpose whatsoever, including developing, manufacturing, or marketing products or services incorporating Feedback.

Copyright © 2002–2003, NCR CorporationAll Rights Reserved

mailto:[email protected]

Preface

Supported Software Release

This book supports Teradata® Database V2R5.1.

Changes to This Book

This book includes the following changes to support the current release:

Date Description

November 2003 • Added network data encryption and logon encryption in Chapter 2.

December 2002 • Added information on Roles and Profiles under “Roles” on page 3-15 and “Profiles” on page 3-17.

• Added information on user level security control.• Added information on maximum lockout duration of a

user.

June 2001 • Added information on new Single Sign On feature under “Logon Policy” on page 2-3.

• Added information about USER DBC lock out under “Maximum Logon Attempts” on page 2-16.

June 2000 • In Chapter 4: “Monitoring Access to Teradata Database,” END LOGGING statement has been updated to reflect that frequency cannot be included.

• In Chapter 2: “Controlling Access to Teradata Database,” information has been added about setting passwords and temporary passwords.

• Added stored procedures information in applicable chapters.

December 1998 • All references to syntax and usage information for Teradata Structured Query Language (SQL) were moved to Teradata RDBMS SQL Reference.

• All references to syntax and usage information for Data Definition Language (DDL) were moved to Teradata RDBMS SQL Reference.

• Detailed description of Account String Expansion (ASE) was moved to Teradata RDBMS SQL Reference.

Security Administration i

PrefaceAbout This Book

About This Book

Purpose

The purpose of this book is to assist security and system administrators in formulating, implementing, and auditing a security policy for a Teradata Database system. This book provides information and guidelines to help the administrator define a level of protection appropriate for the uses of the system.

Scope

This book contains subjects related to Teradata Database security but does not address disaster recovery and the larger issues of general system administration.

This book covers the following subjects:

• Establishing a security policy• Determining the need for user access privileges and assigning those

privileges• Available security features• Databases and tables requiring protection and how to protect them• Parts of the physical system requiring protection

Audience

The authors wrote this book for those who plan and implement system security measures including:

• The database administrator• The security administrator• Operations personnel• Other employees associated with these functions

How This Book Is Organized

This book contains five chapters and one appendix:

Chapter 1: “Introduction to Teradata Database Security”

• Presents the basic elements of security for the Teradata Database, including access control and accountability

• Explains how to identify the level of security required for the system and the access needs of the users

• Defines the role of the security administrator as a user of the Teradata Database

Security Administrationii


Chapter 2: “Controlling Access to Teradata Database”

• Describes the controls for initial access to the Teradata Database• Defines various terminology • Describes the logon policy• Suggests ways to protect password confidentiality • Describes system controls for handling sessions, user access privileges, and

user logons• Describes network data encryption and logon encryption

Chapter 3: “Managing Data Access”

• Explains the management of space allocation, space and object ownership, and rights verification

• Discusses setting up the system administration user • Defines the types of access rights • Describes how to grant and revoke rights• Discusses Roles and Profiles

Chapter 4: “Monitoring Access to Teradata Database”

• Introduces the Data Dictionary• Discusses the system views from which you can extract useful audit reports• Provides general rules for controlling access log entries• Describes the BEGIN LOGGING and END LOGGING statements for

invoking and suspending audit trails• Explains the use of the Account String Expansion (ASE) for detailed

security audit information

Chapter 5: “Physical System Security”

• Proposes methods of restricting access to the physical components of the computer system

Appendix A: “Running a Secure Teradata Database”

• Details the requirements for configuring and running a secure Teradata Database as suggested by the National Computer Security Center (NCSC).

Security Administration iii


Prerequisites

This book assumes you have some basic knowledge of computer system hardware and software. To help you understand the terms and concepts in this book, you may want to review the following books:

Review the book titled... For information about...

Introduction to Teradata Warehouse system hardware.

Database Design relational database management concepts.

SQL Reference the syntax and usage of Teradata Structured Query Language (SQL).

Data Dictionary the structure, content, and purpose of the Data Dictionary.

Teradata Director Program Reference programming the logon and security exits in the Teradata Director Program (TDP).

Security Administrationiv

PrefaceList of Acronyms

List of Acronyms

This book uses the following acronyms, which the table below lists in alphabetical order:

AMP Access Module Processor

AP Application Processor

ASE Account String Expansion

AWS Administration Workstation

BTEQ Basic Teradata Query

BYNET Banyan Network (high-speed interconnect)

CLIv2 Call Level Interface version 2

DBC Database Computer

DD Data Dictionary

DDL Data Definition Language

DES Data Encryption Standard

LAN Local Area Network

MVS Multiple Virtual Storage

NCSC National Computer Security Center

PC Personal Computer

PE Parsing Engine

RDBMS Relational Database Management System

SQL Structured Query Language

SSO Single Sign On

TCB Trusted Computing Base

TDI Trusted Database Interpretation

TDP Teradata Director Program

TSC Teradata Support Center

UDF User-Defined Function

WAN Wide Area Network

Security Administration v

PrefaceTechnical Information on the Web

Technical Information on the Web

The NCR home page ( http://www.ncr.com) provides links to numerous sources of information about Teradata. Among the links provided are sites that deal with the following subjects:

• Contacting technical support• Enrolling in customer education courses• Ordering and downloading product documentation• Accessing case studies of customer experiences with Teradata• Accessing third party industry analyses of Teradata Warehouse products• Accessing white papers• Viewing or subscribing to various online periodicals

Security Administrationvi

http://www.ncr.com

Contents

Preface

Supported Software Release ............................................................................................ iChanges to This Book ....................................................................................................... i

About This Book .................................................................................................................. iiList of Acronyms .................................................................................................................vTechnical Information on the Web...................................................................................vi

Chapter 1: Introduction to Teradata Database SecuritySecurity Controls ............................................................................................................. 1–2

Introduction................................................................................................................... 1–2Access Control .............................................................................................................. 1–2Resource Access Control ............................................................................................ 1–2Physical System Access Control................................................................................. 1–3Auditing and Accountability ...................................................................................... 1–3

Establishing a Security Policy........................................................................................ 1–5Introduction................................................................................................................... 1–5Identifying Security Requirements ............................................................................ 1–5Identifying Security Levels ......................................................................................... 1–5Minimal Security .......................................................................................................... 1–6Moderate Security ........................................................................................................ 1–7High Security ................................................................................................................ 1–7

Identifying Users and Their Needs............................................................................... 1–8Introduction................................................................................................................... 1–8Common User Groups................................................................................................. 1–8

Formulating the Security Policy.................................................................................... 1–9Introduction................................................................................................................... 1–9System-Enforced Security Features ........................................................................... 1–9Key Elements of a Security Policy.............................................................................. 1–9Reevaluating the Security Policy................................................................................ 1–9

Security Administrator Role ........................................................................................ 1–11Introduction................................................................................................................. 1–11Duties of the Security Administrator ...................................................................... 1–11Assigning Security Administrator Attributes to a User ....................................... 1–11

Security Administration vii

Contents

Chapter 2: Controlling Access to Teradata DatabaseIdentifiers.......................................................................................................................... 2–2

Introduction................................................................................................................... 2–2Username Identifiers.................................................................................................... 2–2Client System Identifiers ............................................................................................. 2–2

Logon Policy..................................................................................................................... 2–3Introduction................................................................................................................... 2–3Tdpid .............................................................................................................................. 2–3Account String .............................................................................................................. 2–3Password........................................................................................................................ 2–4Single Sign On............................................................................................................... 2–4

Password Control ............................................................................................................ 2–6Introduction................................................................................................................... 2–6SysSecDefaults Table.................................................................................................... 2–6Password Expiration .................................................................................................. 2–10Resetting an Expired Password................................................................................ 2–10Setting Password for New User ............................................................................... 2–11Setting a Temporary Password................................................................................. 2–11

Password Format........................................................................................................... 2–13Introduction................................................................................................................. 2–13Rules for Creating a Password ................................................................................. 2–13Examples of Using UPDATE to Set Password Values.......................................... 2–14Specifying Password Length..................................................................................... 2–14Submitting a Password String .................................................................................. 2–15Error Messages............................................................................................................ 2–15

Maximum Logon Attempts.......................................................................................... 2–16Password Lockout Time ............................................................................................... 2–18Password Reuse ............................................................................................................. 2–19Session Handling........................................................................................................... 2–21

Introduction................................................................................................................. 2–21Handling Space Allocation........................................................................................ 2–21Handling Data Access................................................................................................ 2–21

Logon Control ................................................................................................................ 2–23Introduction................................................................................................................. 2–23Description of GRANT/REVOKE LOGON Statements ....................................... 2–23Rules for Submitting GRANT/REVOKE LOGON Statements ........................... 2–23Providing Access Control.......................................................................................... 2–24General Rules and Precedence of Clauses .............................................................. 2–24

Encryption ...................................................................................................................... 2–25Network Data Encryption ......................................................................................... 2–25

Security Administrationviii

Contents

Logon Encryption....................................................................................................... 2–25

Chapter 3: Managing Data AccessUser DBC .......................................................................................................................... 3–2

Introduction................................................................................................................... 3–2User DBC Contents ...................................................................................................... 3–2

Establishing a System Administrator ........................................................................... 3–3User and Database........................................................................................................... 3–5

Introduction................................................................................................................... 3–5Space Allocation ........................................................................................................... 3–5

Access Rights.................................................................................................................... 3–6Introduction................................................................................................................... 3–6Ownership Rights......................................................................................................... 3–6Automatic Rights.......................................................................................................... 3–6Examples Using GRANT Statement .......................................................................... 3–8Example 1: User A Creating Database X................................................................... 3–8Example 2: User A Creating User B ........................................................................... 3–9Example 3: User C Creating Table Z.Y...................................................................... 3–9Example 4: User D Creating Stored Procedure Z.SpSample.................................. 3–9Explicit Rights ............................................................................................................... 3–9

Forms of GRANT Statement........................................................................................ 3–11Forms of REVOKE Statement ...................................................................................... 3–12Owners and Parents...................................................................................................... 3–13

Introduction................................................................................................................. 3–13Object Ownership....................................................................................................... 3–13Giving Ownership...................................................................................................... 3–13Rights Verification...................................................................................................... 3–14

Roles ................................................................................................................................ 3–15Advantages of Using Roles ....................................................................................... 3–15Related Topics ............................................................................................................. 3–15

Profiles ............................................................................................................................ 3–17Definition ..................................................................................................................... 3–17Advantages of Using Profiles ................................................................................... 3–17Related Topics ............................................................................................................. 3–17System-Wide Password Security.............................................................................. 3–18Controlling User-Level Password Security ............................................................ 3–18

Chapter 4: Monitoring Access to Teradata DatabaseSystem Views ................................................................................................................... 4–2

Security Administration ix

Contents

System View Queries ...................................................................................................... 4–4Introduction................................................................................................................... 4–4MONITOR-Related Queries........................................................................................ 4–4Example 1: Determining Which Users Can Force Other Users Off System......... 4–4Example 2: Determining Which Users Have Been Forced Off System................. 4–4Example 3: Determining Who Is Currently Using the MONITOR ....................... 4–4

Controlling Access Log Entries ..................................................................................... 4–5Overview of Logging ................................................................................................... 4–5General Rules for Using DDL Statements................................................................. 4–5Security Macro Privilege Checking............................................................................ 4–6System Default .............................................................................................................. 4–6

BEGIN/END LOGGING Statements ........................................................................... 4–7Introduction................................................................................................................... 4–7Function ......................................................................................................................... 4–7DBC.AccLogRuleTbl Entries....................................................................................... 4–7DBC.AccLogTbl Entries ............................................................................................... 4–8Logging at Database Level .......................................................................................... 4–8Logging at Table Level................................................................................................. 4–9Using BEGIN LOGGING With GRANT ................................................................... 4–9Viewing Log Entries..................................................................................................... 4–9Using END LOGGING .............................................................................................. 4–10Purging Aged Log Entries......................................................................................... 4–10DBC.AccLogRule Macro............................................................................................ 4–10Access Logging and Errors ....................................................................................... 4–11Changing Options With MODIFY USER ................................................................ 4–11

Using Account String Expansion ................................................................................ 4–12

Chapter 5: Physical System SecurityControlling Machine Room Access............................................................................... 5–2

Introduction................................................................................................................... 5–2Setting Security Policy ................................................................................................. 5–2Enforcing Security Policy ............................................................................................ 5–2

Controlling Access to Outside Devices ........................................................................ 5–3Controlling Access to Dump Files ................................................................................ 5–4Controlling Access to the Operating System............................................................... 5–5

Appendix A: Running a Secure Teradata DatabaseSecuring System at C2 Level or Equivalent ................................................................A–2

Introduction..................................................................................................................A–2

Security Administrationx

Contents

C2 Security Level Procedure...................................................................................... A–2Potential Hazards ........................................................................................................... A–4

Index ......................................................................................................................... Index–1

Security Administration xi

Contents

Security Administrationxii

List of Tables

Table 1-1 Advantages and Disadvantages of Data Security Levels.................. 1–6Table 1-2 User Groups ............................................................................................. 1–8Table 2-1 SysSecDefaults Column Descriptions .................................................. 2–8Table 2-2 OldPasswords Column Descriptions ................................................. 2–20Table 3-1 Creator Privileges .................................................................................... 3–8

Security Administration xiii

List of Tables

Security Administrationxiv

Chapter 1:

Introduction to Teradata Database Security

The goals of Teradata Database system security features, as presented in this book, are:

• To prevent unauthorized users from gaining access to stored data• To permit legitimate Teradata Database users access to only those resources

(databases, tables, views, stored procedures, and macros) they are authorized to use

The suggestions and procedures in this book are intended to help the system administrator or security administrator to achieve these goals.

Security Administration 1 – 1

Chapter 1: Introduction to Teradata Database SecuritySecurity Controls

Security Controls

Introduction

The controls available to maintain Teradata Database security include:

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

You must define and implement these controls effectively to maintain optimal security. This introductory chapter briefly outlines the first three controls that are described more fully in subsequent chapters. This chapter, in particular, describes security policy in full.

Access Control

As security administrator, you can control access to Teradata Database. Access control takes one of two forms:

• Resource access control• Physical system access control

Resource Access Control

Resource access control involves controlling access to the data and to the relational computing power of Teradata Database. Access to Teradata Database means the user is capable of carrying on a dialog with the system beyond the logon process.

Teradata Database controls access by identifying users with a username and password. Teradata Database acknowledges only users that it recognizes as currently authorized to access the system. If the system identifies the username as an authorized user and the password is correct for that user, Teradata Database assumes the user is valid and establishes a session with the user.

A user cannot run a session on Teradata Database without an associated username. An individual or a process logs on by supplying a username known to Teradata Database and, if required, an associated password. The system then validates the username (with or without a password), against the definition stored in a table maintained by the system.

Optionally, Teradata Database can verify that the logon request originating from a client system connection (LAN, WAN, or mainframe channel) is specifically associated with the username.

If Teradata Database verifies the logon request, it establishes a session for the user and assigns a unique number to the session. The session runs under the

Security Administration1 – 2


combined identifier of session number and username until the user logs off. The user is the basis for ownership of all databases, users, and objects (tables, views, stored procedures, and macros) created during a session. The system can also associate the user with other explicitly granted access rights. For information on how to regulate access, see Chapter 2: “Controlling Access to Teradata Database.”

Physical System Access Control

Physical access control is the control of access to the physical components of the computer system. These components include the processors, disk storage units, and Administration Workstation (AWS).

Controlling access to physical components involves:

• Protecting the system and its components against deliberate damage • Controlling access to devices used to establish sessions on Teradata

Database, such as remote terminals and the local system console

Auditing and Accountability

The security administrator can periodically audit events on Teradata Database to detect the following security hazards:

• Potential break-ins• Attempts to gain unauthorized access to database resources• Attempts to alter the behavior of Teradata Database auditing facilities

Teradata Database automatically audits all logon and logoff activity. However, the security administrator can specify additional audits of attempts to access data by configuring the system to log one, or any combination, of the following parameters:

• All access requests made (for all or specific users)• All access requests denied (for all or specific users)• Specific types of access request made (for all or specific users)

The security administrator can examine or print the audit data during normal system operations, or archive the data to review offline and generate reports. To select data from the audit log during normal operations, the security administrator composes statements with Teradata Structured Query Language (SQL).

If security administrators identify unauthorized or undesirable activity, they take one of the following remedial actions to address the problem:

• Change the security policy• Change compromised passwords• Audit intensively all actions of particular users



• Change access rights• Deny the offending users any access to Teradata Database (in extreme

cases)


Chapter 1: Introduction to Teradata Database SecurityEstablishing a Security Policy

Establishing a Security Policy

Introduction

A security policy consists of those procedures and regulations used to maintain a desired level of system security.

The two major steps for establishing a security policy are:

Identifying Security Requirements

Identifying security needs may involve one or a combination of the following procedures:

• Identifying the business importance of the data and the associated processing system

• Assigning a security priority to the data, based on the business case evaluation

• Identifying the classes of users requiring access to Teradata Database and the data that it controls

• Identifying the system resources that require protection to ensure continued availability data to all valid Teradata Database users

You should base security requirements 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 stores and processes less sensitive data.

Identifying Security Levels

The three levels of data security include minimal, moderate, and high. Table 1-1 summarizes the advantages and disadvantages of each security level, and the following sections briefly discuss each level.

You should ask some key questions to identify the level of security appropriate to your Teradata Database including:

• Is the data on Teradata Database sensitive? How damaging would it be if: – An unauthorized person gained access to the data? – An unauthorized person altered, corrupted, or destroyed the data?

• How important are the processing resources to your company business?• What would be the loss if someone maliciously brought down the system?

Step Action

1 Identify security needs.

2 Identify procedures and regulations to fulfill those needs.



Table 1-1 Advantages and Disadvantages of Data Security Levels

Minimal Security

Minimal security may also include no security. Under minimal security, anyone who has successfully logged on to the system has unrestricted access to all data and Teradata Database resources. No one performs security-related auditing and no formal security policy exists.

The only security-related access restriction is that a user must first gain access to a client system (mainframe, minicomputer, PC, or Application Processor) that is capable of communicating with Teradata Database via a channel, LAN, WAN, or BYNET connection.

Minimal security... Moderate security... High security...

Advantages

• makes sharing information extremely simple.

• allows an environment of trusted users with unrestricted access to all database resources to realize a high level of productivity.

• requires few security enforcement activities enhancing system performance.

• protects the system from casual attempts to circumvent security.

• requires little or no additional effort for users to perform their work.

• involves security-related events that have little or no effect on system performance.

• affords a high level of protection to data and processing resources.

• gives users confidence that their data is safe from unauthorized corruption or disclosure and unwarranted deletions.

• uses an auditing policy designed both to detect unauthorized access attempts and permit the implementation of corrective measures.

Disadvantages

• allows anyone accessing Teradata Database to destroy or corrupt data.

• gives anyone accessing Teradata Database access to all information stored under its control.

• allows no private or secret data.

• lets unauthorized users gain access to Teradata Database.

• might degrade system performance by allowing unauthorized use or misuse of the system.

• can leave serious violation attempts undetected for extended periods.

• provides no guidelines for passwords possibly letting users choose passwords that others can easily guess.

• requires that owners of shared data make additional effort define those authorized to access the data.

• may degrade system performance depending on the frequency and scope of auditing and the demands of security-related events.



A client might have its own security procedures. Teradata Database security procedures neither coordinate nor communicate with any such client security procedures.

Moderate Security

This class groups users according to their needs and trustworthiness. Under moderate security, a small, privileged subgroup has unlimited access. The security administrator performs only occasional auditing of security-related events, and no formal security policy exists for the users.

High Security

This level identifies and charges a security administrator with establishing and maintaining Teradata Database security. The security administrator is the only user that Teradata Database permits to perform the following security-related actions:

• Define which username/client system combinations Teradata Database allows to establish a session

• Define and control the auditing of security-related events• Review the results of security-related audits

The administrator carefully controls physical access to processors, disk storage units, and system consoles. In addition, the administrator regularly audits security-related events and randomly audits individual users.

Each user should receive a document that states the security policy, explains the importance of security, outlines the role of the user in supporting that policy, and defines the guidelines for protecting passwords and data.

Each operator should receive a document that explains their role in supporting the security policy. Operator awareness is important to early detection of potential security violations.


Chapter 1: Introduction to Teradata Database SecurityIdentifying Users and Their Needs

Identifying Users and Their Needs

Introduction

The required level of enforced protection on a system is directly influenced by the level of trust placed in its users. With carefully screened users who are highly trusted, and with strict controls on physical access to Teradata Database, you might be able to establish a high degree of security without denying users needed access rights and without resorting to frequent and detailed audits.

However, the time required to screen all users and the cost of physical access controls make this an undesirable security policy. Also, because you cannot automatically audit and verify the trustworthiness of a user, this type of policy may not easily accommodate additions to the user community in a timely fashion. For these reasons, you can only achieve a high degree of security by making full use of Teradata Database security features and conducting careful administration.

Common User Groups

When formulating a security policy, you must balance the access needs of users with the need to provide system security. In a large computer installation, most Teradata Database users fall into one or more of the groups listed in Table 1-2. Usually the various groups have different needs, with the systems programmers requiring the broadest range of access.

Table 1-2 User Groups

User Group Description

End Users Make Teradata SQL requests to Teradata Database as a means of accomplishing their tasks .

Application Programmers

Develop databases, tables, views, stored procedures, and macros on behalf of the end users.

Systems Programmers

Responsible for the installation, maintenance, and availability of Teradata Database to all system users.


Chapter 1: Introduction to Teradata Database SecurityFormulating the Security Policy

Formulating the Security Policy

Introduction

After you define the security needs of the system and balance those with the needs of system users, you can formulate the security policy.

System-Enforced Security Features

System-enforced security features are relatively easy to implement. Issue a guide defining how to use Teradata Database security features and offer some suggestions. It is up to the security administrator to implement those suggestions.

It is recommended that a document describing the security policy be supplied to each user and operator defined on Teradata Database. The document should outline the advantages of a secure database, minimize any restrictions imposed by the security policy, and include explanations of the following topics:

• Why security is needed • Benefits of security to the users and the company • Suggested security actions for users • Required security actions for users

Key Elements of a Security Policy

The key elements for a system security policy might include knowledge and guidelines on the following:

• Extent of the need for security • Benefits to be derived from 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

Reevaluating the Security Policy

A system security policy should not remain static. You should conduct periodic reviews to continually reevaluate how the current policy meets current needs of the system, the users, and the company.


Chapter 1: Introduction to Teradata Database SecurityFormulating the Security Policy

The following factors make a review of the security policy necessary:

• Changes in the profiles of users who access the system• Changes in business needs that raise or lower the opportunity value of the

data being protected • New releases of Teradata Database software that might introduce new

security features• Discovery of security violations, potential violations, or attempted

violations


Chapter 1: Introduction to Teradata Database SecuritySecurity Administrator Role

Security Administrator Role

Introduction

If system security is critical, then one or more individuals should assume responsibility for the duties of the security administrator. Teradata Database security features allow privileges associated with security to be assigned solely to the security administrator.

Duties of the Security Administrator

The designated security administrator performs the following duties:

• Establishes and modifies logon rules• Defines users, if any, to be audited • Defines objects, if any, to be audited • Defines Teradata SQL functions, if any, to be audited• Coordinates Teradata Database security duties with the NCR server

security administrator, if applicable

Assigning Security Administrator Attributes to a User

To assign the attributes of a security administrator to a user, perform the following steps:

Step Action

1 Log on to Teradata Database under username DBC.

2 Enter a CREATE USER statement to create user space for the security administrator in Teradata Database. If you need more information about the CREATE USER statement, see SQL Reference: Data Definition Statements.

Any name except “sysadmin” can be assigned (this book uses the name “SECADMIN”).

Be sure to assign a password to user SECADMIN.

3 When user SECADMIN has been created, enter the following Teradata SQL statements to grant user SECADMIN the privilege of executing the GRANT/REVOKE LOGON and BEGIN/END LOGGING statements:

GRANT EXECUTE ON DBC.LogonRule TO SECADMIN ;

GRANT EXECUTE ON DBC.AccLogRule TO SECADMIN ;

4 Log off Teradata Database as user.


Chapter 1: Introduction to Teradata Database SecuritySecurity Administrator Role

5 Immediately log back onto Teradata Database as username SECADMIN.

6 Enter the following Teradata SQL statement to initiate an audit trail on the execution of any BEGIN/END LOGGING or GRANT/REVOKE LOGON statement:

BEGIN LOGGING ON EACH ALL ON MACRO DBC.LogonRule,

MACRO DBC.AccLogRule ;

After this statement is executed, audit entries are generated for all future execution of Teradata SQL statements that control auditing of actions on and the source of logons to Teradata Database.

7 Log off Teradata Database.

Step Action


Chapter 2:

Controlling Access to Teradata Database

This chapter describes the following:

• Logon control and Teradata SQL statements used to grant or revoke logons• The controls on initial access to Teradata Database• Logon policy• Suggested ways to protect password confidentiality

A user gains access to Teradata Database when the logon process completes and a session initiates.

This chapter discusses the elements of each of the following major phases of system access control:

Phase Process

1 Identifying and verifying each parameter of the logon request.

Teradata Database logon process accomplishes the first phase by performing a variety of identification checks based on system requirements and, optionally, on requirements imposed by the security administrator.

2 Assigning each session to the conducting user.

Teradata Database accomplishes the second phase by identifying the session with a unique number that is irrevocably linked with the user identification.

3 Controlling user access to stored data during that session.

Teradata Database accomplishes the third phase by checking an arrangement of access rights any time a user submits a Teradata SQL statement that attempts to access (or to execute a function that accesses) a database or object (table, view, stored procedure, or macro) owned by another user.


Chapter 2: Controlling Access to Teradata DatabaseIdentifiers

Identifiers

Introduction

Teradata Database access control is based on the following:

• A user identifier• Optionally, an identifier associated with a channel- or LAN-connected

client system

The security administrator can use these identifiers in GRANT LOGON and REVOKE LOGON statements to designate which users can log on from which client system connections.

The following paragraphs explain each type of identifier.

Username Identifiers

A user identifier or “username” is the name defined in a CREATE USER statement. The Teradata Database security administrator must execute a separate CREATE USER statement for each authorized user to establish the username, define an associated password, and allocate user disk space.

A system table named DBase stores usernames and database names and resides in the space allocated to a system user. You can retrieve information on usernames from DBC.DBase by querying the system view DBC.Users.

Client System Identifiers

Many different types of client systems exist, and they can connect to Teradata Database in many different ways. Each connection must have its own unique client system identifier.

To Teradata Database, a client system can be a mainframe, a minicomputer, a PC, an applications node, a node of a server, or the server itself. Teradata Database communicates with:

• A mainframe client system through a channel connection• A minicomputer or PC client system through a LAN or WAN connection • An application node through a BYNET connection

In turn, the server can have multiple connections to mainframe channels and a single LAN or WAN connection.

You assign each connection a unique value and define that value to Teradata Database using the Configuration utility. The system uses each defined value as a client system identifier or “hostid.” For more information on the Configuration utility, see Utilities.


Chapter 2: Controlling Access to Teradata DatabaseLogon Policy

Logon Policy

Introduction

Teradata Database requires that a LOGON request be issued to identify the user and establish a session. The logon string must include a username already established in the system via a CREATE USER statement. In addition to the username, the logon string may include any combination of the following operands, each involving special considerations as described in this section:

• Tdpid • Account string• Password

Teradata Database validates the account identification (account string) and password associated with the supplied username against system data.

Another method to log on to Teradata Database is Single Sign On (SSO). SSO is further described at the end of this section.

Tdpid

The Teradata Director Program (TDP) is a Teradata-supplied program that manages communication between the client and Teradata Database. On a system connected to more than one server, each copy of the TDP receives a unique identifier, called a tdpid. The tdpid is a client system-based operand and is not transmitted to Teradata Database.

For channel-attached clients connected to several Teradata servers, the tdpid is the identifier of the TDP that handles Teradata Database traffic. The tdpid on a network-attached client specifies the network ID of the Teradata Database.

Use the optional tdpid identifier to specify a particular Teradata Database. Users should see their system or site administrator for the identifier associated with the Teradata Database to be used.

In a Teradata Database logon string, the tdpid indicates which copy of the TDP the system should invoke for the requested session.

For more information on tdpid and default tdpid values, see Teradata Director Program Reference.

Account String

Each username may have one or more associated account strings. Resource accounting requires use of the account string. If the logon string does not supply the account string, the system assigns a default value.

Optionally, the account string may include a priority-level Performance Group prefix code, which establishes the session priority. Priorities are useful when



interactive users are competing for system resources with long-running batch applications.

For additional information, see Database Administration.

Password

The password authenticates a user request to initiate a Teradata Database session under the supplied username. You must define a password in the applicable CREATE USER statement, and the system default requires that the password appear in the user logon string.

For a user to log on to Teradata Database without a password, set up the following conditions:

• A GRANT LOGON statement containing the WITH NULL PASSWORD option must be current for this username. The GRANT LOGON statement is explained later in this chapter.

• For mainframe channel-connected systems, a security exit in the TDP must acknowledge that the logon string for this username is valid without a password. For further details, see Teradata Director Program Reference.

The null password applies only to logging onto the Teradata Database itself; other system security measures still apply. Under any circumstance, a null password limits the ability of the Teradata Database to authenticate the identity of a user.

Although the username is the basis for identification, it is not usually protected information. Unlike a password, a username is openly displayed during interactive logon, on printer listings, and when session information is queried. The password, however, is stored in an encrypted form on Teradata Database.

A password is extremely valuable to system security, because it enables authentication of a username. Never write down or compromise your password. Encourage users to do the same.

Single Sign On

SSO provides Teradata Database users with the ability to be authenticated through network security rather than providing an account and password to logon. Using this feature, Teradata Database users log on to their computer once and run Teradata Database client applications accessing Teradata Database without having to provide username, password, and optional account.

This feature is currently only available on Windows NT and Windows 2000 platforms and must be explicitly turned on by the DBA through DBW or DBS Control. For more information on DBW, see Database Window. For more information on DBS Control, see Utilities.



SSO provides the following benefits:

• Enhances site security because authentication mechanisms do not send passwords across the network

• Saves time


Chapter 2: Controlling Access to Teradata DatabasePassword Control

Password Control

Introduction

Several password control features enhance Teradata Database security:

SysSecDefaults Table

The security administrator sets up the password features for a Teradata Database by updating columns of a single row in user DBC table DBC.SysSecDefaults. Teradata Database reads the single row in the table at system startup. The software uses the values in the columns to determine whether the option has been selected.

Note: You must restart the system to allow it to read the DBC.SysSecDefaults table and to make changed values take effect.

The rules you select apply to all users attempting to log on to Teradata Database, regardless of the logical client system from which the logon is received. The only override to the rules is the null password option, which allows a user to log on without a password and bypass all rules pertaining to user authentication.

Feature Description

Password Expiration Allows the security administrator to define a time span during which a password is valid. After the time elapses, the user must change the password.

Password Reuse Complements the password expiration feature and allows the security administrator to define the time span that must elapse before a previously used password can be reassigned to a user.

Maximum Logon Attempt

Defines the number of erroneous sequential logon attempts a user is allowed before the user is locked out from further logon attempts.

Password Lockout Time

Sets the user lockout time duration after the user has exceeded the maximum number of logon attempts.

Before V2R5.0, the maximum lockout duration was 32000 minutes, about 23 days. In V2R5.0, an additional option of indefinite lockout can be specified.

Miscellaneous Password Features

Allow the security administrator to restrict the number of characters in the password, and to control the use of digits and special characters.

Encryption Enhances security between the Teradata Database and network-attached clients.



The following is a Teradata SQL description of the DBC.SysSecDefaults table:

CREATE SET TABLE DBC.SysSecDefaults ,FALLBACK , NO BEFORE JOURNAL, NO AFTER JOURNAL ( PrimeIndex BYTEINT FORMAT '--9' NOT NULL, ExpirePassword SMALLINT FORMAT '---,--9' NOT NULL, PasswordMinChar BYTEINT FORMAT '--9' NOT NULL, PasswordMaxChar BYTEINT FORMAT '--9' NOT NULL, PasswordDigits CHAR(1) CHARACTER SET LATIN UPPERCASE NOT CASESPECIFIC NOT NULL, PasswordSpecChar CHAR(1) CHARACTER SET LATIN UPPERCASE NOT CASESPECIFIC NOT NULL, MaxLogonAttempts BYTEINT FORMAT '---9' NOT NULL, LockedUserExpire SMALLINT FORMAT '---,--9' NOT NULL, PasswordReuse SMALLINT FORMAT '---,--9' NOT NULL)UNIQUE PRIMARY INDEX ( PrimeIndex );

User DBC has update and select access rights on the table.

The following are the default values in the row (which are initialized by the dictionary initialization and conversion utilities) :

INSERT INTO DBC.SysSecDefaults(1, /* Primary Index for single row */0, /* Do not expire passwords */1, /* Minimum characters in password */30, /* Maximum characters in password */’Y’, /* Allow digits in password */’Y’, /* Allow special characters in password */0, /* Allow unlimited logon attempts */0, /* Do not lock user on erroneous password */0 /* Allow immediate password reuse */

);

User DBC can use a simple update statement to change a default value. The option then becomes effective after the system is restarted.

The following example shows the UPDATE statement to set the minimum number of password characters to eight:

UPDATE DBC.SysSecDefaults SET PasswordMinChar = 8 ;



Table 2-1 provides a quick reference to the password control features and their descriptions.

Table 2-1 SysSecDefaults Column Descriptions

This column… Indicates…

ExpirePassword number of days to elapse before the password expires.

To set a temporary password, you must assign a non-zero value to ExpirePassword.

PasswordMinChar minimum number of characters in a valid password string.

Valid character values include 1 through 30. If the user enters a 0 value, the system replaces that 0 value with the system default value, which is 1.

PasswordMaxChar maximum number of characters in a valid password string.

The maximum number of characters is 30. PasswordMaxChar must be equal to or greater than PasswordMinChar.

Valid character values include 1 through 30. If the user enters a 0 value, the system replaces that 0 value with the system default value, which is 30.

PasswordDigits whether digits are to be allowed in the password as follows:

Setting Result

Y allow digits in a password (except as first character).

N do not allow digits.

PasswordSpecChar whether special characters are to be allowed in the password as follows:

Setting Result

Y allow special characters in a password.

N do not allow special characters.

MaxLogonAttempts number of erroneous logons allowed before locking user.

0 indicates a user is never locked.



LockedUserExpire number of minutes to elapse before a locked user is unlocked. Before V2R5.0, the maximum lockout duration was 32000 minutes, about 23 days. In V2R5.0, an additional option of indefinite lockout can be specified.

Note: If MaxLogonAttempts is set to a value other than zero, and if the time interval for locking users after erroneous attempts is left at zero, then the user is never locked.

0 indicates immediate unlock.

-1 indicates indefinite lockout.

PasswordReuse number of days to elapse before a password can be reused.

0 indicates immediate reuse.

This column… Indicates…



The following values cause errors if placed in the SysSecDefaults row:

• A negative value in ExpirePassword, MaxLogonAttempts, or PasswordReuse.

• A PasswordMaxChar with a value less than PasswordMinChar. • A character other than Y or N in the PasswordDigits or PasswordSpecChar

columns.

If any of these errors occur, Teradata Database generates an error message for the event log during startup and replaces the value with the system default value for the corresponding column.

Password Expiration

The password expiration option allows the security administrator to specify the number of days a password is valid. Teradata Database adds this value to the password change date value maintained in the database row for the user. The system compares the result to the current date to determine if the password is still valid.

Resetting an Expired Password

When a user attempts to log on with an expired password, a session is established if the following conditions are met:

• The logon string contains the correct expired password.• Another session is not currently established under the user identifier

contained in the logon string.

The session is limited to the use of MODIFY USER statement to establish a new password. After the password is modified, normal Teradata SQL activity is permitted over the session.

If the user already has a session logged on and the password expires, the current session may be used to submit the MODIFY USER statement to establish a new password. If the current session is for a utility such as Archive or MultiLoad, which does not offer the MODIFY USER statement, the user must end the current session. The user must log off and log on again through a utility such as BTEQ, which allows use of the MODIFY USER statement. For example, use the following statement to establish a new password:

MODIFY USER username AS PASSWORD = passwordname;

The password is immediately valid for the number of days indicated in the field, ExpirePassword, in the DBC.SysSecDefaults table. For details, see the MODIFY USER syntax in SQL Reference: Data Definition Statements.

The following example shows the UPDATE statement to set the duration of password acceptance to 30 days:

UPDATE DBC.SysSecDefaults SET ExpirePassword = 30 ;



A zero value means passwords do not expire. A negative value is not accepted and causes an error message.

The Department of Defense recommends the maximum lifetime of a password be no more than one year. The value of data or chance of a security breach indicates whether a shorter lifetime is needed.

Setting Password for New User

When you create a new user, the PasswordChgDate is set to zero. This value indicates that the password initially assigned to the user is a temporary password and has already expired at the first logon attempt by the user.

Note: Temporary passwords expire immediately only if you set a non-zero value in the ExpirePassword column in the user DBC table DBC.SysSecDefaults.

Setting a Temporary Password

Use the MODIFY USER statement with the FOR USER option to provide a temporary password (for example, when a user has forgotten their password).



The following procedure expires the existing password and creates a temporary password to replace it.

For details, see the MODIFY USER syntax in SQL Reference: Data Definition Statements.

Step Action

1 SELECT ExpirePassword from the DBC.SecurityDefaults view by entering the following:

SELECT ExpirePassword FROM DBC.SecurityDefaults;

2 Examine the reported value for ExpirePassword.

IF the value is… THEN…

0 Change it to a value > 0.

UPDATE DBC. SecurityDefaults

SET ExpirePassword=2;

Restart the database.

Go to Step 3.

Note: Temporary passwords expire immediately only if you first set a non-zero value in the ExpirePassword column.

3 Perform MODIFY USER with the FOR USER option.

Note: You must have the appropriate privilege.

MODIFY USER JDoe AS

PASSWORD = mysecret

FOR USER;

The existing password immediately expires and is replaced by ‘mysecret.’

The value for PasswordChgDate is reset to 0 just as is true for a new user.

The temporary password expires immediately when the user logs on for the first time, and they must create a new, permanent password at that time using the MODIFY USER command without the FOR USER option.


Chapter 2: Controlling Access to Teradata DatabasePassword Format

Password Format

Introduction

The password format option allows the site administrator to change the minimum and maximum number of characters allowed in the string and control the use of digits and special characters.

Teradata Database accepts any string for a password as long as it conforms to Teradata Database rules for a word. The rules are:

• Characters from 1 to 30• Letters from A through Z• digits 0 through 9• $ (dollar sign)• _ (underscore)• # (pound sign)

The first character must not be a digit.

Rules for Creating a Password

A password cannot contain any of the following:

• Katakana symbols• Multibyte spaces• Special characters other than $ (dollar sign), # (pound sign), or

_ (underscore) in single-byte or multibyte forms• Digits 0 through 9 in single-byte or multibyte forms when they are the first

character in the name• Greek and Cyrillic characters• User-defined characters

These rules are identical to those for naming objects. Note that many of these rules make sense only in a multibyte character set environment.

When creating passwords, additional restrictions apply under each type of character set, as the following sections discuss. The password formatting feature does not apply to multibyte character sets.

For charts of the supported Kanji character sets, Teradata Database internal JIS encoding, and the valid character ranges for Kanji object names and data, See International Character Set Support.



Examples of Using UPDATE to Set Password Values

The following examples show the UPDATE statements you use to set typical values for the password format.

Specifying Password Length

The Department of Defense recommends that passwords consist of eight or more characters. When specifying a password length, consider a longer password. However, keep in mind that because it is more difficult to remember a longer password, the user is more likely to write it rather than memorize it, and it is strongly recommended that users do not write passwords down.

The password format options do not invalidate existing passwords. The format rules are enforced only when a new password is submitted.

Example Description

Set minimum number of characters in password

The setting must be in the range from 1 to 30, and not less than the minimum number of characters:

UPDATE DBC.SysSecDefaults SET PasswordMinChar = 6 ;

Set maximum number of characters in password

The setting must be in the range from 1 to 30, and less than or equal to the maximum number of characters:

UPDATE DBC.SysSecDefaults SET PasswordMaxChar = 8 ;

Allow digits in password The setting must be either Y or N. Even if digits are allowed in the password, the first password character cannot be a digit in order to comply with the definition of a Teradata SQL word:

UPDATE DBC.SysSecDefaults SET PasswordDigits = Y ;

Allow special characters in password

The setting must be either Y or N to allow special characters in the password:

UPDATE DBC.SysSecDefaults SET PasswordSpecChar = Y ;

Set duration of password This setting allows you to decide the length of time in days before password must be renewed.

To set the duration of password acceptance to 30 days:

UPDATE DBC.SysSecDefaults SET ExpirePassword = 30 ;



Submitting a Password String

Submit the password string in either a CREATE USER statement for a new user or a MODIFY USER statement to change a password for an established user. An error message results if a user submits a password string that violates the format constraints.

Error Messages

The error messages are:

3684 The password submitted contains too few characters.3685 The password submitted contains too many characters.3686 Digits may not be used in passwords.3687 Special characters may not be used in passwords.

The system returns the error message in a group of messages, indicating the statement that attempted to add or change the password was not successfully processed.


Chapter 2: Controlling Access to Teradata DatabaseMaximum Logon Attempts

Maximum Logon Attempts

The maximum logon attempts feature restricts the number of successive logon attempts a user with an incorrect password is allowed.

The security administrator enters the number of allowable failed logon attempts into the DBC.SysSecDefaults table MaxLogonAttempts column. Entering a zero value disables this feature so that users are never locked out due to successive, failed logon attempts.

Note: If user DBC exceeds maximum allowable logon attempts, user DBC could be locked out. In the event that this happens, the only way user DBC can log on is through the TSTSQL console. Contact Teradata Support Center (TSC) for more information on the TSTSQL console.

Setting the Maximum Number of Attempts

The following example shows the UPDATE statement to set the maximum number of failed logon attempts to three:

UPDATE DBC.SysSecDefaults SET MaxLogonAttempts = 3 ;

The system does not accept a null. A zero value prevents locking, and a negative value causes an error message.

If the number of erroneous logon attempts reaches the value specified in DBC.SysSecDefaults.MaxLogonAttempts, the system locks out the User ID from further attempts for the duration of the password lockout time (described below). Further erroneous attempts during the password lockout time cause Event log entries containing “User Locked” as the event type.

To break through the password lockout before the allotted time has elapsed, use the MODIFY USER statement to release the lock on the user. The release lock option format of the MODIFY USER statement is as follows:

MODIFY USER username AS RELEASE PASSWORD LOCK;

You must use the DROP USER privilege to execute the MODIFY USER statement. This privilege is usually made available to security administrators and system administrators as an option of the GRANT statement. For the discussion of the GRANT statement, see Chapter 3: “Managing Data Access.” For syntax and usage information, see to SQL Reference: Data Definition Statements.

When specifying the number of failed logon attempts to allow before locking out the user, consider the following trade-offs:

• Allowing a greater number of failed attempts increases exposure to unauthorized access by means of sophisticated, repetitive logon methods.


Chapter 2: Controlling Access to Teradata DatabaseMaximum Logon Attempts

• People make keyboard mistakes and forget passwords. Allowing too few failed logons may increase the number of legitimate user calls to the security administrator requesting password lock release.

• If shorter passwords are used, fewer erroneous attempts should be allowed. If longer passwords are used, more attempts could be allowed.

• Valuable or sensitive data may justify fewer allowed failures (for example, two or only one in extreme cases). Less sensitive data may allow more attempts (for example, three or four, or no lockout at all).


Chapter 2: Controlling Access to Teradata DatabasePassword Lockout Time

Password Lockout Time

The password lockout time feature sets the time length a user is locked out for exceeding the maximum number of logon attempts. The effect of this feature is similar to the Maximum Logon Attempts feature.

The security administrator enters the number of minutes into the LockedUserExpire column of table DBC.SysSecDefaults. A zero value can be used for immediate lock release, which disables the password lockout time feature.

The following example shows the UPDATE statement to set the duration of user lock to two minutes:

UPDATE DBC.SysSecDefaults SET LockedUserExpire = 2 ;

Before V2R5.0, the maximum lockout duration was 32000 minutes, about 23 days. In V2R5.0, the security administrator can specify an additional option of indefinite lockout by setting the LockedUserExpire value to -1.

When specifying the password lockout time, consider the following:

• Legitimate users sometimes make mistakes entering passwords. They should not be locked out for long periods if they make one or two erroneous attempts.

• Legitimate users could be locked out by a malicious process that initiated erroneous logons. If the lockout time is long, such a process could quickly lock out all users.


Chapter 2: Controlling Access to Teradata DatabasePassword Reuse

Password Reuse

Password reuse defines a time span in which a user cannot reuse a previously used password. The following example shows the UPDATE statement used to set the password reuse lock duration to 60 days:

UPDATE DBC.SysSecDefaults SET PasswordReuse = 60 ;

A zero value sets an immediate reuse. A negative value causes an error message.

The Department of Defense recommends that passwords not be reused for at least six months after expiration. Furthermore, the reuse denial period should be at least as long as the password lifetime.

When a user changes a password, Teradata Database records the old password and the current date. The next time the user attempts to change a password, Teradata Database compares the new password to the current password. If they are equal, the system rejects the new password. If they are not equal, the list of passwords previously assigned to the user is searched for one equal to the one being proposed.

If a match is found and the number of days between the date when the old password was modified (last available for use) and the current date are less than the site-specified reuse time, then Teradata Database does not allow the password change. Teradata Database keeps track of previously used passwords for at least the time over which reuse is denied.

Teradata Database saves all previously used passwords in a dictionary table (DBC.OldPasswords) defined under user DBC. When a user successfully changes their password:

• A row containing the current password is written to DBC.OldPasswords.• Teradata Database automatically deletes all old password rows for that user

with a date earlier than the current date minus the reuse time span.

The Old Password table is defined as follows:

CREATE TABLE DBC.OldPasswords, FALLBACK(UserName CHAR(30) UPPERCASE NOT NULL,

PasswordDate Integer NOT NULL,/*Julian date */PasswordSeed BYTE(2) NOT NULL,/*Seed for password */PasswordString Byte(8) NOT NULL,/*Encrypted password*/

)PRIMARY INDEX( UserName );


Chapter 2: Controlling Access to Teradata DatabasePassword Reuse

Table 2-2 lists the contents for the DBC.OldPasswords table.

Table 2-2 OldPasswords Column Descriptions

Column Description

UserName Identity of the user to which the password was assigned.

PasswordDate Date the password was changed for the user.

PasswordSeed Data Encryption Standard (DES) seed needed to encrypt the password.

PasswordString Encrypted password string.


Chapter 2: Controlling Access to Teradata DatabaseSession Handling

Session Handling

Introduction

A username is required at logon time to establish a session. Upon successful logon, the user name is associated with a unique session number under which the session runs until the user logs off.

Each user name is also associated with a default storage area and with an arrangement of access rights with which Teradata Database supervises user access to stored data.

Handling Space Allocation

A user and a database are similar in that both are allocated space that can store object data. Users and databases are different in that a user is active, whereas a database is passive. A database cannot log on, establish a session, or submit a Teradata SQL statement. Creating a user and a database require different Teradata SQL statements called CREATE DATABASE and CREATE USER.

Both the CREATE DATABASE and CREATE USER statements allocate permanent disk space and define the name which identifies that space. However, the CREATE USER statement associates the assigned user name with a password, optionally with one or more account strings, and with a default database.

If you are creating a user and a default database is not defined, the user space is assigned automatically. This user can then log on, establish a session, submit Teradata SQL requests, and provide disk space in which submitted requests can be executed.

If a Teradata SQL statement contains a reference to an object without a database name, Teradata Database searches the default database for the user. The user can override the default for a particular object by qualifying its statement reference with a database name (in the form databasename.objectname).

Also, at any time during the session, the user can override the current default by executing a DATABASE statement. The defined space is used as the default until another DATABASE statement is executed or the user logs off.

Handling Data Access

Predefined privileges, or access rights, control user activities during a session. Access rights are associated with a database, user, table, hash index, join index, view, stored procedure, User-Defined Function (UDF), or macro; and to a role, group of roles, user, or group of users. Access rights or privileges are granted in the following ways:

• Automatically by the system to the creator of an object


Chapter 2: Controlling Access to Teradata DatabaseSession Handling

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

If the user has the right to automatically or explicitly grant rights, the user can also revoke these rights.

Implicit ownership rights cannot be revoked.

Teradata Database verifies access rights when a user attempts to access (or to execute a function that accesses) an object. Information on access rights is stored in the system table DBC.AccessRights and can be retrieved by querying the DBC.UserRights system view.


Chapter 2: Controlling Access to Teradata DatabaseLogon Control

Logon Control

Introduction

If Teradata Database is connected to multiple client systems, the system grants logon permission to all users from all client system connections by default. You can, however, control which users have access from which client system connections. The GRANT LOGON and REVOKE LOGON statements associate specific usernames with specific hostids.

Each username must already be created as a user in Teradata Database. Each hostid must correspond to a value assigned to a LAN or channel connection as defined by Teradata Database.

Teradata Database maintains Data Dictionary (DD) system tables using Data Definition Language (DDL) statements. The GRANT LOGON and REVOKE LOGON statements are DDL statements. Teradata Database uses the DD tables to execute subsequent statements.

Description of GRANT/REVOKE LOGON Statements

A brief description of each LOGON statement follows:

• The GRANT LOGON statement gives specific users permission to log on to Teradata Database from one or more specific client systems. In addition, the statement is used to change the current system defaults for logon permissions.

• The REVOKE LOGON statement retracts permission to log on to Teradata Database from one or more specific client systems. In addition, the statement is used to change the current system defaults. A REVOKE LOGON statement inhibits only future logon attempts; it does not affect users who are currently logged on.

Rules for Submitting GRANT/REVOKE LOGON Statements

GRANT LOGON and REVOKE LOGON statements must be submitted according to the following rules of usage for DDL statements:

• A DDL statement cannot be combined with other statements as part of a multi-statement request.

• A DDL statement can only be included in an explicit transaction (one or more requests bracketed by BEGIN TRANSACTION/ END TRANSACTION statements in Teradata mode, or terminated with a COMMIT statement in ANSI mode) if it is one of the following: – The only statement in the transaction – Structured as a single-statement request that appears as the last request

in the transaction


Chapter 2: Controlling Access to Teradata DatabaseLogon Control

When you submit a GRANT LOGON or REVOKE LOGON statement, the Teradata Database checks whether you have the EXECUTE privilege on the system macro associated with that statement. However, the Teradata Database does not check whether the user name defined in the statement applies to users owned by the requesting user.

If Teradata Database cannot verify the submitted statement (for example, the statement specifies an invalid user name or an invalid hostid), it takes no action on the statement.

Providing Access Control

When Teradata Database is connected to multiple client systems, the initial default grants logon permission to all users from all hostids, and all logons must include a password. The GRANT LOGON and REVOKE LOGON statements control which users have access from which client system connections.

Only the system administrator or a trusted user to whom the system administrator has granted the EXECUTE privilege on the DBC.LogonRule special system macro can submit these statements.

General Rules and Precedence of Clauses

Rules are exercised according to the specific level of the client system and user ID clauses in the GRANT LOGON and REVOKE LOGON statements. The specific clauses take precedence over the general clauses. The clauses are:

• ON ALL AS DEFAULT (most general)• ON hostid AS DEFAULT• ON ALL TO userid• ON hostid TO userid (most specific)

For example:

GRANT LOGON ON ALL TO A

is superseded by:

REVOKE LOGON ON hostid TO userid

For syntax and usage information on the GRANT LOGON and REVOKE LOGON statements, see SQL Reference: Data Definition Statements.


Chapter 2: Controlling Access to Teradata DatabaseEncryption

Encryption

Encryption is implemented to enhance security between the Teradata Database and network-attached clients.

The encryption feature supports the following:

• Network data encryption• Logon Encryption

Network Data Encryption

Teradata Tools and Utililtes 7.1 introduces full payload encryption between CLI-based client applications and the Teradata Gateway.

A client application can enable or disable data encryption for the duration of a request by setting the data_encryption flag in dbcarea. When the flag is set to Y, network traffic is encrypted in both directions between the client application and the Teradata Gateway.

For more information on Network Data Encryption, see Database Administration.

Logon Encryption

Teradata Warehouse 7.1 provides for the encryption of logon strings to ensure the security of passwords when transmitted between client applications and the Teradata Gateway.

The client application does not enable or disable logon encryption. The Teradata Gateway determines the settings.

On the Teradata Gateway, encryption is always enabled. The default is to accept only encrypted logons but rejects unencrypted ones, and the option is set to no in the Gateway Control Utility as follows:

gtwcontrol -b no

To provide compatibility to pre-TTU7.1 version of client software, the Teradata Gateway can be configured to allow deprecated (unencrypted) logons (pre-TTF7.1 client software). If the database administrators choose to allow deprecated logons, they must set the gtwcontrol -b option to yes as follows:

gtwcontrol -b yes

For more information on how to set the options, see the Gateway Control Utility in Utilities.

Teradata recommends using the gtwcontrol -b yes option only until all customers have updated to Teradata Tools and Utilities 7.1.


Chapter 2: Controlling Access to Teradata DatabaseEncryption


Chapter 3:

Managing Data Access

Teradata Database uses a set of rules governing how data access can be controlled. The security administrator should understand these rules to prevent unauthorized access to databases or to objects in databases.

This chapter describes the basics of data ownership and access. However, because relational databases and tables store all data under the control of the database, you need to understand how relational database systems are managed. You may want to first review material in the following documents:

• Introduction to Teradata Warehouse• Database Design

This chapter explains:

• How to create the system administrator user• Terms associated with access rights• Teradata SQL statements used for granting and revoking access rights to

databases, users, and objects • Roles • Profiles


Chapter 3: Managing Data AccessUser DBC

User DBC

Introduction

When first installed, Teradata Database contains space allocated to a special system user named DBC.

User DBC Contents

Initially, user DBC contains:

• System tables of DD• All Teradata Database-managed disk space available for the site

applications including users, databases, objects, and data

User DBC also contains a series of system views that allow the retrieval of data from the underlying system tables.


Chapter 3: Managing Data AccessEstablishing a System Administrator

Establishing a System Administrator

Space under user DBC that is not needed for system information should be allocated to a different user. The following procedure explains how to create this different user:

When logged on as ADMIN, the system administrator can create new users and any administrative databases from the ADMIN space. ADMIN is the parent of

Step Action

1 Log on as DBC.

2 Submit a CREATE USER statement to allocate the space to an administrative user.

The name of the new user can be anything except “sysadmin,” which is the name assigned to a special system database. This book assumes the new username to be ADMIN.

3 Allocate to user ADMIN all the free PERM space that remains under DBC after the requirements of the site system tables and largest transient journal have been calculated and subtracted. For details on the transient journal and creating the administrative user, see Database Design.

When DBC submits the CREATE USER ADMIN statement, the space for ADMIN is allocated from DBC space. DBC thus becomes the immediate owner and parent, as well as the creator, of ADMIN.

4 Explicitly grant ADMIN all the privileges needed to administer the daily activities of the site, including creating users and databases, roles and profiles, and granting privileges, with the following statements:

GRANT ALL ON ADMIN TO ADMIN WITH GRANT OPTION;

GRANT ROLE, PROFILE TO ADMIN WITH GRANT OPTION;

5 Explicitly grant ADMIN the privileges needed to monitor and control system performance, including ABORT SESSION and MONITOR RESOURCE. The following statement grants those rights; however, the statement does not include an ON clause, and cannot work if it has one:

GRANT MONITOR PRIVILEGES TO ADMIN WITH GRANT OPTION ;

6 While still logged on, submit a MODIFY USER statement to change the password for DBC. When the statement is accepted, DBC should log off. From now on, the system administrator should log on under username ADMIN.


Chapter 3: Managing Data AccessEstablishing a System Administrator

all users and databases it has created and automatically receives creator privileges on them.

ADMIN also automatically receives implicit ownership privilege on all databases and users subsequently created, because it is the indirect owner of these objects. In turn, a user created by ADMIN becomes the owner of any databases, other users, and objects he or she creates.

The resulting hierarchical structure gives the owner or creator of an object control over the security of that object.


Chapter 3: Managing Data AccessUser and Database

User and Database

Introduction

Although a user and a database are both allocated space in which object data can be stored, and the keywords USER and DATABASE may sometimes be used synonymously, they are not the same. A dbname, or database name, merely identifies the space in which data is stored.

A Teradata Database is a defined logical repository for tables, views, and macros. A database has perm and spool space. A Teradata Database user is similar to a database except a user:

• Has a password or an account• Can be used to log on • Can be used to establish a session• Can execute Teradata SQL statements

A user may log on to the database either by its own access rights or by a database for which it has access rights.

Space Allocation

The requested space for a new user or database is allocated from the space of the requesting user unless the CREATE USER or CREATE DATABASE statement contains a FROM ownerdb clause.

If the new user then creates another user or a database, the requested space is allocated from the space for that user. The result is a hierarchical structure that is maintained for all users and databases.

For details on user and database space allocation, see Database Design.


Chapter 3: Managing Data AccessAccess Rights

Access Rights

Introduction

Three types of access rights (or privileges) are defined in this section:

Ownership Rights

The ownership rights, also called implicit rights, are implicitly granted to the immediate owner and to all indirect owners (that is, those in the hierarchy above the immediate owner). Ownership rights have two forms:

• Ownership rights allow an owner to execute the GRANT or REVOKE statement for any privilege applied to an owned object. The owner of a table has the implicit right to GRANT to itself the SELECT privilege on an owned table.For example, if a parent revoked the SELECT privilege from a child on tables owned by that child, the child could subsequently GRANT itself the revoked SELECT privilege.

• Ownership rights also implicitly provide CHECKPOINT and DUMP and RESTORE privileges on owned objects. Ownership rights do not include the privilege to execute any form of the CREATE statement.

A user does not own itself; therefore, creating a user does not grant to the newly created user any ownership rights. Ownership rights cannot be revoked. Even though ownership rights are implicit, they are still subject to logging when access logging is specified for the particular right.

Automatic Rights

There are two types of automatically granted rights:

• Rights granted to a newly created user or database on itself • Rights granted on a newly created user, database, or object to the creating

user

Access Right Description

Ownership Granted implicitly by the system to the owner of the space from which a database, user, or object is created.

Automatic Granted automatically by the system to the creator of a database, user, or object, and to a newly created user or database.

Explicit Given to any user having the WITH GRANT OPTION privilege. Explicit rights are given using the Teradata SQL GRANT statement.



Creator privileges are distinct from ownership privileges because the FROM dbname option of the CREATE DATABASE or CREATE USER statement allows the creator to define an owner different from his or her own space.

A new user or database is automatically granted all rights on itself, with the exception of the GRANT (WITH GRANT OPTION) and CREATE DATABASE/USER, CREATE PROCEDURE, and EXECUTE PROCEDURE rights. Thus, a newly created user can create tables, views, and macros within his or her own user space. The automatic right to create objects can be explicitly revoked from a new user by an owner or by the creator of the user.

A user can be explicitly granted the right to create databases and other users in his or her own user space. This right can only be granted by a user who has the GRANT right (WITH GRANT OPTION) and the right to create such users and databases.

In the case of stored procedure-related rights, a newly created user gets only the DROP PROCEDURE privilege. The rights to create or execute stored procedures are not automatic. These can be explicitly granted to any user by DBC or by a user having the rights WITH GRANT OPTION. For details, see “Explicit Rights” on page 3-9.

The initial user (DBC) in the system has all rights, with the exception of CREATE PROCEDURE and EXECUTE PROCEDURE. When creating the ADMIN user, all rights should be explicitly granted by DBC to ADMIN. User ADMIN then has the right to pass these privileges down to any user created by ADMIN.

If a user has been granted either the CREATE DATABASE or the CREATE USER privilege, and subsequently creates a new database or user, Teradata Database automatically grants to that user a series of creator privileges on the created space.

There is a case where the new user or database is the creator but not necessarily the owner. The CREATE DATABASE/USER statement offers a FROM option that creates the new database or user from the space of a specified owner, instead of the space of the user submitting the statement. The owner of the space becomes the owner of the newly created user or database. The creator is the user or database submitting the statement but does not own the space the new object is created in. Therefore, the owner of the new user or database may not be its creator.



Privileges that are automatically granted to the creator of an entity are listed in Table 3-1.

Table 3-1 Creator Privileges

Examples Using GRANT Statement

Examples using the GRANT statement follow.

Example 1: User A Creating Database X

When user A creates database x, the following GRANT statements are executed by Teradata Database:

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

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

CREATE Statement Automatic Rights

CREATE DATABASE

CREATE USER

All privileges on databases, users, macros, tables, and views created in the new space, and DROP PROCEDURE privilege on the database or user space.

CREATE TABLE DROP TABLE, INDEX, INSERT, TRIGGER, UPDATE, DELETE, REFERENCE, SELECT, and DUMP and RESTORE privileges on the newly created table, as well as the CREATE TRIGGER privilege WITH GRANT OPTION.

If the JOURNAL option is specified, the user also must have INSERT privilege on the journal table.

CREATE MACRO DROP MACRO, EXECUTE, and GRANT on the created macro. Performing an EXECUTE or GRANT on a macro depends also on the privileges the owner of the macro has on the objects referenced by that macro.

CREATE VIEW DELETE, DROP VIEW, GRANT, INSERT, SELECT, and UPDATE on the new view. Using the view or performing a GRANT on a view depends also on whether the owner of the view has GRANT privileges on the objects referenced by that view.

CREATE PROCEDURE

DROP PROCEDURE and EXECUTE PROCEDURE on the new stored procedure.

Performing an EXECUTE PROCEDURE or GRANT on a stored procedure depends also on the privileges the owner of the stored procedure has on the objects referenced by that procedure.



The owner gets implicit rights.

Example 2: User A Creating User B

When user A creates user B, the following GRANT statements are executed by Teradata Database:

GRANT TABLE, VIEW, MACRO, SELECT, INSERT, UPDATE, DELETE, DUMP, RESTORE, CHECKPOINT, EXECUTE,

DROP PROCEDURE ON b TO b;GRANT USER, DATABASE, TABLE, VIEW, MACRO, SELECT,

INSERT, UPDATE, DELETE, WITH GRANT OPTION, DUMP,RESTORE, CHECKPOINT, EXECUTE, DROP PROCEDURE ON b TO a;

The owner gets implicit rights.

Example 3: User C Creating Table Z.Y

When user C creates table z.y, the following GRANT statement is executed by Teradata Database:

GRANT DROP TABLE, INSERT, UPDATE, DELETE, SELECT, WITH GRANT OPTION, DUMP, RESTORE ON z.y TO c ;

Example 4: User D Creating Stored Procedure Z.SpSample

When user D creates a stored procedure z.SpSample, the following GRANT statement is executed by Teradata Database:

GRANT PROCEDURE WITH GRANT OPTION ON z.SpSample TO D;

where PROCEDURE includes DROP PROCEDURE and EXECUTE PROCEDURE rights.

Explicit Rights

The GRANT and REVOKE statements give to or retract from a user or group of users one or more privileges on a database, user, table, view, stored procedure or macro.

The user submitting the GRANT or REVOKE statement must be an owner of the object, or must have the GRANT privilege (WITH GRANT OPTION), plus all of the privileges that are to be given or revoked on the object.

If the object is a view, stored procedure, or macro, the owner of the view or macro must also have the GRANT privilege (WITH GRANT OPTION), plus all other applicable privileges, on the objects referenced by the view, stored procedure, or macro.

DBC is the initial user in the system; it has all privileges except CREATE PROCEDURE and EXECUTE PROCEDURE. When creating other users, DBC has the right to grant any or all these privileges to any or all users so created. It



is recommended that DBC first create and grant all privileges to an administrative user, and the administrator then create all other users.

DBC can explicitly grant CREATE PROCEDURE and EXECUTE PROCEDURE privileges to itself, or to any other user.


Chapter 3: Managing Data AccessForms of GRANT Statement

Forms of GRANT Statement

The GRANT statement has four forms:

For syntax and usage information on the GRANT (SQL Form), GRANT (Monitor Form), GRANT LOGON, and GRANT (Role Form) statements, see SQL Reference: Data Definition Statements.

Note: If it is necessary to maintain a security log of access attempts, see the “BEGIN/END LOGGING Statements” section in Chapter 4: “Monitoring Access to Teradata Database” of this book.

Statement Description

GRANT (SQL Form)

In Teradata SQL, this statement pertains to access privilege control on Teradata Database and is used to assign one or more privileges on a database, user, table, view, stored procedure, or macro to a user or a group of users.

GRANT (Monitor Form)

Used to grant system-wide performance monitoring privileges.

GRANT LOGON

Described in Chapter 2: “Controlling Access to Teradata Database,” in this book.

GRANT (Role Form)

Used to grant role membership to users or other roles.


Chapter 3: Managing Data AccessForms of REVOKE Statement

Forms of REVOKE Statement

The REVOKE statement has four forms:

For syntax and usage information on REVOKE (SQL Form), REVOKE (Monitor Form), REVOKE LOGON, and REVOKE (Role Form) statements, see SQL Reference: Data Definition Statements.

Note: Implicit ownership privileges cannot be revoked.

Statement Description

REVOKE (SQL Form)

Cancels privileges to a database, user, table, view, stored procedure, or macro from a user or group of users. The privileges may have been given automatically or by a previous GRANT statement.

REVOKE (Monitor Form)

Cancels system-wide performance monitoring privileges.

REVOKE LOGON

Does either of the following:

• Revokes permission to log on to the Teradata Database from one or more specific client systems.

• Changes the current system logon defaults.

REVOKE (Role Form)

Used to revoke role membership from users or other roles.


Chapter 3: Managing Data AccessOwners and Parents

Owners and Parents

Introduction

A user who creates a database or another user becomes the owner and creator of the new space. As the creator of the new space, the user is automatically granted access rights to and anything created in that space. As the owner of the new space, the user is implicitly granted ownership rights on that space.

If the new space is a user, the owning user is considered the parent and the newly created user is considered its child. In turn, a child becomes the parent of any new users it creates.

A parent may grant itself privileges on any objects owned by its child user. For example, assume that user ADMIN creates a database named Finance and a user named Smith. ADMIN grants Smith the privilege to create new databases and users.

Smith then logs on and creates another user, Jones. Jones receives automatic and implicit privileges on the items he creates in his own space. However, as parent user for Jones, Smith, and those above him in the hierarchy, may also grant themselves privileges on any items owned by Jones, because they have implicit ownership rights on user Jones. This parent-child relationship is maintained for all users defined to Teradata Database.

Object Ownership

The immediate owner of an object is the containing user or database. However, the parents in the hierarchy above the containing user or database are also indirect owners of the object.

For example, assume a user named USER1 creates in its own space a database named TEST. Assume also that USER1 then creates a table defined as TEST.TABLEA. The occurrence of TABLEA is stored in TEST, which is the immediate owner of TABLEA. However, TABLEA is also indirectly owned by USER1 and all the parents of USER1.

Giving Ownership

Use the Teradata SQL GIVE statement to transfer actual ownership of a database or user to a non-owner. The GIVE statement transfers to the recipient not only the specified database or user space, but also all of the databases, users, and objects owned by that database or user. Therefore, transferring ownership affects space allocation and should be used with caution.


Chapter 3: Managing Data AccessOwners and Parents

Rights Verification

Teradata Database verifies access rights upon receipt of a request to access, or to execute a function that accesses, a target database, user, or object. Teradata Database must verify the requestor as having the appropriate privileges on that target.

If a user does not have the appropriate privileges, an access violation is generated, the request is denied, and the requesting user is informed of the violation.


Chapter 3: Managing Data AccessRoles

Roles

Introduction

Roles define access privileges on database objects. A user who is a member of a role can access all the objects on which the role has privileges. Creating roles is a new feature for V2R5.0.

Advantages of Using Roles

Use roles to:

• Simplify access rights administration.A database administrator can grant rights on database objects to a role and have the rights automatically applied to all users assigned to that role.When the function of a user within an organization changes, changing the role of the user is far easier than deleting old rights and granting new rights to go along with the new function.

• Reduce dictionary disk space.Maintaining rights on a role level rather than on an individual level makes the size of the DBC.AccessRights table much smaller. Instead of inserting one row per user per right on a database object, the Teradata Database inserts one row per role per right in DBC.AccessRights, and one row per role member in DBC.RoleGrants.

Related Topics

The following lists the topics related to roles:

For more Information on . . . See . . .

Creating a Role "Create Role" in the "SQL Data Definition Language Statement Syntax" chapter of SQL Reference: Data Definition Statements.

Dropping a Role "Drop Role" in the "SQL Data Definition Language Statement Syntax" chapter of SQL Reference: Data Definition Statements.

Setting a Role "Set Role" in the "SQL Data Definition Language Statement Syntax" chapter of SQL Reference: Data Definition Statements.

Granting Rights to a Role "Grant (SQL Form)" in the "SQL Data Definition Language Statement Syntax" chapter of SQL Reference: Data Definition Statements.


Chapter 3: Managing Data AccessRoles

Revoking Rights from a Role

"REVOKE (SQL Form)" in the "SQL Data Definition Language Statement Syntax" chapter of SQL Reference: Data Definition Statements.

Granting a Role to a User or Role

"GRANT (Role Form)" in the "SQL Data Definition Language Statement Syntax" chapter of SQL Reference: Data Definition Statements.

Revoking a Role from a User or Role

"REVOKE (Role Form)" in the "SQL Data Definition Language Statement Syntax" chapter of SQL Reference: Data Definition Statements.

Assigning a default role to a user

"Using Roles to Manage User Access Privileges" in the "SQL Data Definition Language Statement Syntax" chapter of SQL Reference: Data Definition Statements.



Chapter 3: Managing Data AccessProfiles

Profiles

Definition

Profiles define values for the following system parameters:

• Default database• Spool space• Temporary space• Account• Password security attributes

An administrator can define a profile and assign it to a group of users who share the same settings.

Advantages of Using Profiles

Use profiles to:

• Simplify system administration. Administrators can create a profile that contains system parameters such as account, default database, spool space, temporary space, and password attributes, and assign the profile to a group of users. To change a parameter, the administrator updates the profile instead of each individual user.

• Control user-level password security.Administrators can assign the profile to an individual user or to a group of users.

Related Topics

The following lists the topics related to profiles:


Creating a Profile "CREATE PROFILE" in the "SQL Data Definition Language Statement Syntax" chapter of SQL Reference: Data Definition Statements.

Dropping a Profile "DROP PROFILE" in the "SQL Data Definition Language Statement Syntax" chapter of SQL Reference: Data Definition Statements.


Chapter 3: Managing Data AccessProfiles

System-Wide Password Security

Teradata Database stores the system-wide password security options in a single row in the DBC.SysSecDefault table. During system startup, Session Control validates against password expiration and lockout attributes stored in this row.

Controlling User-Level Password Security

An administrator can create profiles that define values for the following user-level password security attributes:

• Minimum and maximum number of characters in a password string• Whether or not to allow digits and special characters in a password string• Number of incorrect logon attempts to allow before locking a user• Number of minutes before unlocking a locked user• Whether a user is locked out indefinitely• Number of days before a password can be used again• Whether a password may be reused• Ability to change password expiration

The password attribute settings in a user profile override the corresponding system-level password settings. The system uses the system-level password settings for password attributes that are not defined in the profile for a user. Changes to password attribute settings in a profile do not require a system restart to take effect. The new settings take effect the next time users who are assigned the profile log on.

Modifying a Profile "MODIFY PROFILE" in the "SQL Data Definition Language Statement Syntax" chapter of SQL Reference: Data Definition Statements.

Assigning Profiles to Users

"Using Profiles to Manage System Parameters for Groups" in the "SQL Data Definition Language Statement Syntax" chapter of SQL Reference: Data Definition Statements.



Chapter 4:

Monitoring Access to Teradata Database

This chapter:

• Introduces the Data Dictionary• Discusses the system views from which useful audit reports can be

extracted• Provides general rules for controlling access log entries• Describes the BEGIN LOGGING and END LOGGING statements for

invoking and suspending audit trails• Explains the use of Account String Expansion (ASE) for detailed security

audit information

Teradata Database manages a DD in which information is accumulated about users, databases, data demographics, resource usage and access rights. This information is stored in tables reserved for system use and can be accessed by views. These tables and views reside in the system database called DBC.

With respect to security, the Data Dictionary is especially important for recording access activity and for checking access rights to verify user and creator access privileges.

For more information on the DD, see Data Dictionary.


Chapter 4: Monitoring Access to Teradata DatabaseSystem Views

System Views

Each site is provided with a series of system views loaded into user DBC during installation. System views allow users to retrieve information from selected columns of the underlying system tables.

The following table describes views that provide retrieval of information on users and access rights and on grant, logon, and access activities:

View Name Description

DBC.AccessLog The underlying table for this view is DBC.AccLogTbl. Each entry in AccLogTbl indicates the results of a privilege check performed against a Teradata SQL request, based on the criterion defined in a BEGIN LOGGING statement.

DBC.AccLogRules Entries are maintained in the underlying tables for this view as the result of executing BEGIN LOGGING and END LOGGING statements. These entries are used by the system to determine which privilege checks should result in entries being generated in the DBC.AccLogTbl table.

DBC.AllRights Entries provide information about all users automatically or explicitly granted privileges, and the objects on which those privileges were granted.

DBC.AllRoleRights Entries list all rights granted to each role.

DBC.DeleteAccessLog Use this view to remove entries more than 30 days old from the table, which logs access information.

For example, to remove all entries over 30 days old, type the statement:

DELETE FROM DBC.DELETEACCESSLOG ALL ;

Note: The view contains logic to retain a 30-day minimum of the most recent logging entries.

DBC.LogOnOff Use this view to record logon and logoff activity, the associated session number, and attempted logon events. Event data indicates why a logon attempt was unsuccessful.


Chapter 4: Monitoring Access to Teradata DatabaseSystem Views

For information on system views, see Data Dictionary.

DBC.LogonRules Entries are stored in the underlying table of this view as a result of the GRANT LOGON and REVOKE LOGON statements. These entries are used by the system when determining whether to allow or prevent system access.

DBC.RoleMembers Entries list each role and all of its members. The RoleMembersX view lists all roles, if any, directly granted to the user.

DBC.Users Use this view to extract information about the user submitting the request and all users owned by that user. The information is derived from system table DBC.DBase.

View Name Description


Chapter 4: Monitoring Access to Teradata DatabaseSystem View Queries

System View Queries

Introduction

Query the following system views to review information concerning user access privileges and activities:

• DBC.LogonRules• DBC.AccLogRules• DBC.AccessLog

You can use all parameters of the SELECT statement to query system views. For example:

SELECT * FROM DBC.AccLogRules ;SELECT * FROM DBC.AccessLog WHERE AccessType = ’CP’ ;

MONITOR-Related Queries

Make queries regarding the use of system monitoring or production control features much like you make other SELECT queries. Examples follow.

Example 1: Determining Which Users Can Force Other Users Off System

To determine which users have the privilege to force other users off the system (where AS is an abbreviation for the ABORT SESSION privilege), type:

SELECT DISTINCT UserName FROM DBC.AllRights WHERE AccessRight = ’AS’ ;

Example 2: Determining Which Users Have Been Forced Off System

To determine which users have been forced off the system in the past two days, type:

SELECT DISTINCT UserName FROM DBC.LogOnOff WHERE Event = ’Forced Off’ AND LogDate > DATE - 3 ;

Example 3: Determining Who Is Currently Using the MONITOR

To learn who is currently using the MONITOR, type:

SELECT UserName, IFPNo FROM DBC.SessionInfo WHERE Partition = ’MONITOR’ ;


Chapter 4: Monitoring Access to Teradata DatabaseControlling Access Log Entries

Controlling Access Log Entries

Overview of Logging

Use the DDL statements BEGIN LOGGING and END LOGGING to control the monitoring of access rights checks performed by Teradata Database.

Each time you execute a BEGIN LOGGING statement, the system table DBC.AccLogRuleTbl receives applicable rule entries. (The system view DBC.AccessLogRules offers access to the contents of this table.)

When a user named in a BEGIN LOGGING statement attempts to execute a specified action against a specified object, Teradata Database checks the access rights necessary to execute the statement according to the rules in AccLogRuleTbl. The privilege checks made and the access results are logged in the system table DBC.AccLogTbl. (The system view DBC.AccessLog offers access to the contents of this table.)

A logging entry does not indicate that a statement was executed; rather, it indicates that the system checked the privileges necessary to execute the statement.

You can terminate logging by submitting an END LOGGING statement for any action, user, or object for which logging is currently active. Note that you cannot end logging begun for a specific username by omitting the BY username option.

General Rules for Using DDL Statements

The BEGIN LOGGING and END LOGGING statements are DDL statements in that they affect Data Dictionary entries, which the Teradata Database uses when executing subsequent statements. As such, you must submit these statements according to the following rules for DDL statement usage:

• You cannot combine a DDL statement with other statements as part of a multi-statement request.

• You can only include a DDL statement in an explicit transaction (one or more requests bracketed by BEGIN TRANSACTION and END TRANSACTION statements) if it is: – The only statement in the transaction,

OR

– Structured as a single-statement request that appears as the last request in the transaction


Chapter 4: Monitoring Access to Teradata DatabaseControlling Access Log Entries

Security Macro Privilege Checking

When a user submits a BEGIN LOGGING or END LOGGING statement, the system checks whether the executing user has the EXECUTE privilege on the special system macro associated with that statement.

Teradata Database makes no checks for privileges on the user or objects identified in the LOGGING statement.

If the system cannot execute a statement, it returns an error message to the user. Possible errors could be an invalid:

• Action name• Username• Object name

System Default

If the user does not submit a BEGIN LOGGING statement, then by default the system does not generate any entries on any user action.


Chapter 4: Monitoring Access to Teradata DatabaseBEGIN/END LOGGING Statements

BEGIN/END LOGGING Statements

Introduction

A user can execute the BEGIN LOGGING and END LOGGING statements only if the following conditions are present:

• The DIPACC DBCSQL script, which the software release tape provides, has been run to create the special security macro DBC.AccLogRule.

• The system has been reset to initialize the logging software. • The user has been granted the privilege to EXECUTE the macro

DBC.AccLogRule.

Otherwise, access logging is not allowed on Teradata Database.

For syntax and additional usage information on the BEGIN LOGGING and END LOGGING statements, see SQL Reference: Data Definition Statements.

Function

The BEGIN LOGGING and END LOGGING statements start and stop the auditing of data access requests.

Each time a user named in a BEGIN LOGGING statement attempts to execute a specified action against a specified object, Teradata Database performs one or more access-rights checks as defined by the rules residing in DBC.AccLogRuleTbl. The completed checks generate one or more log entries in DBC.AccLogTbl.

The BEGIN LOGGING statement can request checks on one, all, or any combination of the following items:

• Type of access• Text of the request• Frequency of access• Action requested• Name of the requesting user• Objects referenced

A user can terminate logging for an action, user, or object for which log entries are currently active by submitting an END LOGGING statement.

DBC.AccLogRuleTbl Entries

The rules resulting from the execution of BEGIN LOGGING statements are entered in the system table DBC.AccLogRuleTbl.



When access logging is active, Teradata Database looks in AccLogRuleTbl to determine which privilege checks to make against a specified user, action, or object.

Use the END LOGGING statement to terminate access logging on any user, action, or object for which one or more logging rules are currently active. If this action turns off all logging rules for a particular user, database, or table, the system deletes the row from AccLogRuleTbl.

DBC.AccLogTbl Entries

The system generates a log entry only if a logging rule is present and active for the object, action, or user whose privilege is being checked.

When Teradata Database finds one or more active rules, it performs the specified privilege checks. These checks generate one or more log entries in the system table DBC.AccLogTbl.

A logging entry does not necessarily indicate that a statement was executed; rather, it indicates that the system checked on the privileges necessary to execute the statement. The row will be either a “denied” or a “granted” entry.

Log entries may contain one or two names. The logon name is always present in a log entry. If the access right being checked is for other than the logon name, the second name is also present in the log entry as the owner name.

For example, if a user submits an EXECUTE statement for a macro, the system checks the access right of the logon username of that EXECUTE statement. However, the system also checks the access rights for the individual statements within the macro for the owner of the macro itself.

Logging at Database Level

A user should consider the object level used in the grant of an access right when specifying the object level of a logging statement.

When a logging statement specifies logging at the database level, the actions requested against all the tables in that database are candidates for log entries.

To illustrate this, assume that DatabaseA contains several tables, and that the INSERT privilege has been granted to PUBLIC on Table1 only.

Note: PUBLIC (meaning everyone) is a keyword that allows you to retrieve information using the SELECT statement.

Assume also that a current statement specifies:

BEGIN LOGGING ON FIRST INSERT ON DatabaseA

Subsequently, if users other than the owner submit INSERT statements against tables in DatabaseA, the log entries are:

• A “granted” entry for the first insert into Table1



• A “denied” entry for the first attempt at an insert into any other table in the DatabaseA

The same type of action against separate tables in that database might not be logged as separate actions.

For example, assume that DatabaseA contains Table1 and Table2, and a current BEGIN LOGGING statement specifies logging on FIRST INSERT for DatabaseA. Next, assume that rows were inserted into both Table1 and Table2 in the same session. The logging result would be a single entry identifying the table that was the object of the first insert.

Logging at Table Level

If the access right is at the database level but the logging specification is at the table level, only actions against the table are considered for logging entries. (The absence of an access right at the table level may not always result in a log entry.)

The system generates a single log entry for the table according to the results of privilege checks at both the table level and the database level as follows:

• If either check succeeds, the system generates a “granted” entry.• If both checks fail, the system generates a “denied” entry.

Using BEGIN LOGGING With GRANT

The following statement begins logging and saves the statement text for each occurrence throughout the entire system of CREATE or DROP USER, or CREATE or DROP DATABASE statements that also use GRANT:

BEGIN LOGGING WITH TEXT ON EACH USER, DATABASE, GRANT ;

Viewing Log Entries

You can monitor the contents of:

• The DBC.AccLogRuleTbl via the DBC.AccLogRules system view• The DBC.AccLogTbl via the DBC.AccessLog system view

If access logging is specified for a data object (for example, a table), the system will generate log entries only when a user accesses that object by name. For example, a logging statement specifying “FIRST SELECT ON DatabaseA.Table1” causes a log entry to be generated if an access statement is the following:

SELECT . . . FROM Table1

Logging will not occur on the following access statements unless a logging rule specifies the view, macro, or stored procedure used:

• SELECT . . . FROM View1_of_Table1• EXECUTE MACRO1



where Macro1 contains the following statement:SELECT . . . FROM Table1

• CALL SpSample1where SpSample1 contains the following statement:

SELECT . . . FROM Table1

Using END LOGGING

Use the END LOGGING statement to terminate access logging on any user, action, or object for which one or more logging rules are currently active.

Using the END LOGGING statement results in an error if BEGIN LOGGING is not currently in effect for the community (dbname) for which you want to end logging:

• Logging begun for specific usernames cannot be ended by omitting the BY username option.

• The END LOGGING statement erases text flags for the specified actions and user or object. However, the frequency syntax cannot be included in END LOGGING statements because it is restricted.

Purging Aged Log Entries

Include a WHERE condition clause in the DELETE statement to purge aged log entries. Use the viewname DBC.DeleteAccessLog in the DELETE statement. For example, to delete entries older than 90 days, type the statement:

DELETE FROM DBC.DELETEACCESSLOG WHERE LogDate < (Date - 90) ;

If you do not specify a WHERE LogDate, by default the view always deletes entries older than 30 days. The view contains logic to retain a 30-day minimum of logging entries. For more information on the DELETE statement, see SQL Reference: Data Manipulation Statements.

DBC.AccLogRule Macro

You must install the DBC.AccLogRule macro feature on any site that formerly used the SecurityLog and wishes to continue doing so. After you create the DBC.AccLogRule macro and initialize logging, any subsequent command causes the statements that were previously logged in the SecurityLog to be logged in DBC.AccLogTbl.

Caution: Only those sites that require access logging should create the DBC.AccLogRule macro. The feature extracts a performance penalty even if little or no logging is performed.

The user executing a BEGIN LOGGING or END LOGGING statement must have the EXECUTE privilege on the DBC.AccLogRule macro.



Access Logging and Errors

If the SQL parser identifies and reports any syntactic or semantic error, then it returns an error message to the user with no logging of the statement.

Changing Options With MODIFY USER

A user with no access rights can enter a self-referent MODIFY USER statement to change the following options:

• BEFORE JOURNAL• AFTER JOURNAL• DEFAULT JOURNAL TABLE• PASSWORD• STARTUP• COLLATION• DEFAULT DATABASE

Logging is triggered by using access rights. Therefore, no logging occurs if you enter a self-referent MODIFY USER statement.

Note: Privilege checks generate log entries. MODIFY is not a privilege that can be granted, so MODIFY is not a privilege that is checked. MODIFY operations are not logged.

To log MODIFY operations, select logging for the type of access that the MODIFY requires. Specifying such actions as DROP, INSERT, DELETE, and UPDATE can cause logging on actions used by a MODIFY.

For example, to log MODIFY DATABASE operations, specify logging on the DROP DATABASE privilege. DROP DATABASE is the documented access right requirement for MODIFY DATABASE.


Chapter 4: Monitoring Access to Teradata DatabaseUsing Account String Expansion

Using Account String Expansion

Use the optional Account String Expansion (ASE) feature if you need detailed security audit information. ASE provides precise statistics, enabling more accurate capacity planning and information for chargeback and accounting software.

You must modify user logon strings in order to use the ASE feature. ASE does not modify the AMP usage statistics gathering process; those functions and features operate in the usual way prior to ASE.

To enable ASE, the system administrator establishes one or more account identifiers for a new user when the user is created (or modified). When the user logs on, they must supply an account identifier as a part of the logon string. The user may enter the identifier explicitly, or the system will supply an identifier by default. Establish a list of allowable account ID strings with the CREATE USER or MODIFY USER statements.

The system collects a new set of statistics (AMP usage, number of I/Os, etc.) each time it determines that a new account string is in effect. The system stores the accumulated statistics for a user/account string pair as a row in DBC.AMPUsage. Each user/account string pair results in a new set of statistics and an additional row.

For detailed ASE information, string expansion examples, and usage examples, see the Account String Expansion (ASE) section in Database Administration.


Chapter 5:

Physical System Security

Physical system security involves controlling access to the physical components of the computer system. For example, physical system security protects:

• The system and its component against deliberate damage• The Administration Workstation (AWS) or system console from

unauthorized access

It is outside the scope of this book to describe fire protection and disaster planning, security screening of personnel, plant security, and the structural requirements of a secure (TEMPEST) building. These subjects are not specific to NCR systems; information on them can be obtained in books and government publications.


Chapter 5: Physical System SecurityControlling Machine Room Access

Controlling Machine Room Access

Introduction

The computer system requires a controlled environment, such as a machine or computer room. A computer room houses processors, disks, consoles, printers, and tape drives.

Setting Security Policy

At sites where security is a concern, even a minimal security policy should include the following procedure:

Enforcing Security Policy

To effectively enforce the security policy, operators must be knowledgeable about the current security policy.

Step Action

1 Restrict access to the computer room to authorized personnel only. Either escort or deny unauthorized personnel access.

2 Maintain a log of all escorted visitors to the computer room.

3 When it is not possible to escort unauthorized personnel to the computer room, take the following precautions:

• Log off any administrator users in the computer room. • Physically power down the entire computer system.

4 When long-term access is required for non-operations personnel, screen them as if they were joining your operations staff.

5 Review the computer room access list and keep it current. Delete names of personnel who no longer require access.

6 Instruct the operations staff to challenge any strangers encountered in the computer room.

7 Store any media that contains sensitive data in a controlled area such as the computer room.

8 Remove all sensitive data from all media before removing it from the controlled area or releasing it to unsecured personnel.


Chapter 5: Physical System SecurityControlling Access to Outside Devices

Controlling Access to Outside Devices

Access control to devices outside the computer room is generally less stringent than for devices located inside the computer room. However, some exceptions apply.

The security policy is mainly concerned with controlling access to the data because it is intellectual capital and the corporate resource. Therefore, removing remote devices from the computer room can pose a problem.

The caretakers or custodians of the remote devices must always be aware of security and report any unauthorized uses of the equipment they suspect. Such caretakers or custodians should invoke the related audit procedures to help detect and prevent attempted security violations.


Chapter 5: Physical System SecurityControlling Access to Dump Files

Controlling Access to Dump Files

When the system restarts, it produces a dump file. A database named CRASHDUMPS stores the dump file. The system user DBC owns the CRASHDUMPS database.

The system initialization scripts explicitly grant user SYSTEMFE SELECT access to dump data. It is important that you carefully guard the password to user SYSTEMFE, because a dump is the image of physical memory at the time the dump occurred and is therefore highly sensitive data.


Chapter 5: Physical System SecurityControlling Access to the Operating System

Controlling Access to the Operating System

Restrict access to the operating system to only system administrators with special privileges. Establish operating system and network security controls to secure Teradata Database running on the NCR server platform. Restrict users without special privileges from accessing the LAN through the operating system to prevent inadvertent corruption of Teradata Database data files.


Chapter 5: Physical System SecurityControlling Access to the Operating System


Appendix A:

Running a Secure Teradata Database

This appendix details the requirements for running a secure Teradata Database, as suggested by the National Computer Security Center (NCSC).

NCR has implemented enhancements to the Teradata Database using the guidelines provided by the NCSC to create a product that complies with the Trusted Database Interpretation (TDI) at the C2 level.

NCR makes no claim that Teradata Database has been evaluated by NCSC at the C2 level nor that Teradata Database will comply with the TDI.

Security Administration A – 1

Appendix A: Running a Secure Teradata DatabaseSecuring System at C2 Level or Equivalent

Securing System at C2 Level or Equivalent

Introduction

This section describes how to secure your system at a C2 or C2-equivalent level.

C2 Security Level Procedure

You must implement the following critical steps to operate the system at a C2 or C2-equivalent level of security:

Step Action

1 Establish a system security policy.

2 Establish the physical security controls for the system.

3 Establish operating system and network security controls for the NCR server.

4 Install the system (hardware and software) following the NCR-supplied installation guide. Use the guide that corresponds to your current hardware/software release.

5 Make sure the DIPACC script, which is provided on Teradata Database software release tape, has been run. This script creates the AccLogRules macro in system user DBC. If this macro is not created, access logging is not allowed in the system. After this macro has been created, logging still is not allowed until after the system has been reset. The software that controls logging only looks for the presence of this macro during its initialization.

6 Change the PASSWORD parameter for usernames DBC, SYSTEMFE, and SYSADMIN (via MODIFY USER), and protect the new passwords in accordance with your security policy.

7 Define and establish (via CREATE USER) Teradata Database username for the security administrator. Assign a password to this username.

8 Assign the newly created security administrator the rights (privileges) to define and control logon rules and security audit rules. Type the following statements while logged on as user DBC:

GRANT EXECUTE ON DBC.LogonRule

TO security_administrator_name ;

GRANT EXECUTE ON DBC.AccLogRule

TO security_administrator_name ;

Security AdministrationA – 2

Appendix A: Running a Secure Teradata DatabaseSecuring System at C2 Level or Equivalent

9 Initiate auditing of all attempts to access the security administrator macros; this includes the security administrator. Type the following statement:

BEGIN LOGGING WITH TEXT ON EACH ALL

ON MACRO DBC.LogonRule, MACRO DBC.AccLogRule ;

10 Initiate auditing on attempts to change the status of a Teradata Database object. Type the following statement:

BEGIN LOGGING WITH TEXT ON EACH USER,

DATABASE, TABLE, VIEW, STORED PROCEDURE MACRO;

11 Establish any additional security auditing as required by your security policy.

12 Establish a list of users permitted to log on to Teradata Database via the Administration Workstation (hostid = 0). Use the GRANT LOGON statement on the list of valid usernames.

13 Define and implement a reporting structure based on the security audit information.

Step Action

Security Administration A – 3

Appendix A: Running a Secure Teradata DatabasePotential Hazards

Potential Hazards

Take notice of the following warnings to eliminate possible confusion on the part of the security administrator:

Step Action

1 Use caution when considering whether to include the WITH NULL PASSWORD option in a GRANT LOGON statement.

This option splits the function of the Trusted Computing Base (TCB). Although the Teradata Director Program security exit must validate a null password parameter in a particular logon string, Teradata Database itself cannot adhere to the logon policy of username/password verification.

2 Never use the “GRANT ... WITH GRANT OPTION” construct for databases or users. This will help prevent ambiguous structuring of the security network.

This construct should be omitted when granting privileges on objects. Although this will require more work for the system or security administrator, it will force the administrative staff to be involved in all GRANT requests by non-owners.

3 Never define “SESSION POOLING” to the Teradata Director Program. Session pooling offers faster logons, but prevents Teradata Database from identifying and authenticating users without ambiguity.

Security AdministrationA – 4

Index

A

Access control 3–1BEGIN LOGGING statement 4–5denying 1–4END LOGGING statement 4–5monitoring access rights 4–5password 2–4physical 1–2, 1–3resource 1–2restrictions 5–2types of 1–2

Access log entriescontrolling 4–5errors 4–11overview 4–5purging 4–10viewing 4–9

Access rights 2–21changing 1–4security classes 1–5types of 3–6see also Privileges

Account identifier, logon string 2–3Account string 2–3Account String Expansion. See ASEAccountability 1–3ADMIN space 3–3ASE

accurate capacity planning 4–12precise statistics 4–12security audit information 4–12

Audit data. See Audit trailsAudit trails

archiving 1–3examining 1–3invoking 4–1logon/logoff activity 1–3printing 1–3report generation 1–3statements, using 1–3suspending 4–1Teradata RDBMS events 1–3

Auditing 1–3Automatic privileges 3–6Automatic rights

CREATE DATABASE 3–8CREATE MACRO 3–8


CREATE TABLE 3–8CREATE USER 3–8CREATE VIEW 3–8

B

BEGIN LOGGING statementDDL 4–5, 4–7used with GRANT 4–9

BEGIN TRANSACTION statementBEGIN LOGGING Security Administration

usage 4–5END LOGGING Security Administration

usage 4–5

C

C2 security A–1, A–2CHECKPOINT privilege 3–6Child, defined 3–13Clauses, FROM ownerdb 3–5Client system identifier

assigning using Configuration utility 2–2hostid 2–2

CommandsABORT SESSION 3–3CREATE USER 3–3MONITOR RESOURCE 3–3

ConnectionLAN 1–2mainframe channel 1–2WAN 1–2

Crash. See RestartCRASHDUMPS, database security 5–4CREATE DATABASE statement 3–7, 3–8CREATE PROCEDURE statement 3–8CREATE PROFILE statement 3–17CREATE ROLE statement 3–15CREATE statement 3–6CREATE statements

CREATE DATABASE 3–8CREATE MACRO 3–8CREATE PROCEDURE 3–8CREATE TABLE 3–8CREATE TRIGGER 3–8

Index –1

Index

Index –2

CREATE USER 3–8CREATE USER ADMIN 3–3CREATE VIEW 3–8

CREATE TABLE statement 3–8CREATE TRIGGER statement 3–8CREATE TRIGGER WITH GRANT OPTION 3–8CREATE USER 3–3CREATE USER ADMIN statement 3–3CREATE USER statement 2–2, 3–7, 3–8Creator

definition 3–13privileges 3–8

D

Data access control. See Access controlData access requests

start auditing 4–7stop auditing 4–7

Data Dictionary, contents 4–1Database 3–5

creating 3–8security 5–4transfer ownership 3–13

DBClog on 3–3space 3–3user DBC 3–2user DBC locked out 2–16

DBC.AccessLog view 4–2, 4–4, 4–9DBC.AccLogRule macro 4–10DBC.AccLogRules view 4–2, 4–4, 4–9DBC.AccLogRuleTbl entries 4–7, 4–9DBC.AccLogTbl entries 4–8, 4–9DBC.AllRights view 4–2DBC.AMPUsage

storing statistics 4–12user/account string pair 4–12

DBC.DBase system tabledatabase names 2–2DBC.Users entries 4–3usernames 2–2

DBC.DeleteAccessLog view 4–2, 4–10DBC.LogOnOff view

logon/logoff activity 4–2unsuccessful logon attempts 4–2

DBC.LogonRules view 4–3, 4–4DBC.OldPasswords table 2–19DBC.SysSecDefaults Table

column description 2–8

Security Adm

invalid values for 2–10DBC.SysSecDefaults table 2–6, 2–7DBC.Users view 2–2, 4–3DDL statements

BEGIN LOGGING 4–5, 4–7END LOGGING 4–5, 4–7general rules 4–5usage rules 4–5

DELETE privilege 3–8DIPACC DBCSQL script 4–7DROP PROCEDURE privilege 3–8DROP PROFILE statement 3–17DROP ROLE statement 3–15DROP TABLE privilege 3–8Dump file, security 5–4DUMP privilege 3–6, 3–8

E

Encryptionlogon 2–25network data 2–25

END LOGGING statementDDL 4–5, 4–7usage 4–8, 4–10

END TRANSACTION statementBEGIN LOGGING Security Administration

usage 4–5END LOGGING Security Administration

usage 4–5EXECUTE privilege 4–6EXECUTE PROCEDURE privilege 3–8Expired password, resetting 2–10Explicit rights, privileges 2–22

F

FROM ownerdb, clause 3–5

G

GIVE statement 3–13Giving Ownership 3–13GRANT (Role Form) statement 3–16GRANT (SQL Form) statement 3–15GRANT LOGON statement 2–2GRANT privilege 3–8

inistration

Index

GRANT statementaccess privilege control, forms of 3–11examples using 3–8, 3–9

GRANT statement, forms ofGRANT 3–11GRANT LOGON 3–11GRANT MONITOR 3–11

GRANT/REVOKE LOGON statementsgeneral rules 2–24precedence of clauses 2–24

H

High securityadvantages 1–6disadvantages 1–6

Hostidassociated with usernames 2–23channel connection 2–23client system identifier 2–2LAN connection 2–23see Client system identifiersee also GRANT LOGON or REVOKE LOGON

statementHosts, multiple, logon permission 2–23

I

Identifier type, client system 2–2Implicit rights

privileges 2–22see also Ownership 3–6

INSERT privilege 3–8

K

KeywordsDATABASE 3–5USER 3–5

L

Loggingdatabase level 4–8table level 4–9

Logoff


activity 4–2DBC.LogOnOff view 4–2

Logonaccount string 2–3activity 4–2controlling user 2–23DBC.LogOnOff view 4–2DBC.SysSecDefaults.MaxLogonAttempts 2–16how to release lock on failed logon 2–16maximum number of attempts 2–16MODIFY USER statement, using 2–16password string 2–3permission, multiple hosts 2–23policy 2–3string 2–3UPDATE statement, using 2–16why unsuccessful 4–2

Logon string operandsaccount string 2–3password 2–3tdpid 2–3

M

Macros, DBC.AccLogRule 4–10Minimal security

advantages 1–6disadvantages 1–6

Moderate securityadvantages 1–6, 1–7disadvantages 1–6

MODIFY privilege, logged indirectly in audit 4–11MODIFY PROFILE statement 3–18MODIFY USER statement 2–11, 2–16, 4–11

N

National Computer Security Center. See NCSCNCSC A–1Network controls, security 5–5Network security 5–5

O

Objectcreating 3–7ownership of 3–13

Index –3

Index

Index –4

Object Ownership 3–13ON clause 3–3Operating system

restrictions 5–5security controls 5–5special privileges 5–5

Owner, definition 3–13Ownership

rights, forms of 3–6transfer database 3–13

P

Parent, defined 3–13Password

changing 1–3control 2–6control features 2–8DBC.SysSecDefaults option 2–6expiration 2–6, 2–10format 2–13length 2–15lockout time 2–18logon string 2–4null option 2–6old 2–19release lock, MODIFY USER statement 2–16resetting expired 2–10reuse 2–19setting for new user 2–11temporary 2–11

PERM space 3–3Physical access control 1–3Privileges

access types 3–6automatic 3–6checking, DBC.AccessLog view 4–2CHECKPOINT 3–6data access 2–21DELETE 3–8DROP PROCEDURE 3–8DROP TABLE 3–8DUMP 3–6, 3–8EXECUTE 2–24, 4–6EXECUTE checking 2–24EXECUTE PROCEDURE 3–8GRANT 3–8granted to creator 3–8INDEX 3–8INSERT 3–8REFERENCE 3–8

Security Adm

RESTORE 3–6, 3–8SELECT 3–6, 3–8TRIGGER 3–8UPDATE 3–8verifying 3–14

Profiles 3–17CREATE PROFILE statement 3–17defined 3–17DROP PROFILE statement 3–17MODIFY PROFILE statement 3–18using 3–17

Q

Queriesmonitor-related 4–4via system views 4–4

R

REFERENCE privilege 3–8Release password lock 2–16Remote devices, security 5–3Resource access control 1–2Restart, security, dump files 5–4RESTORE privilege 3–6, 3–8REVOKE (Role Form) statement 3–16REVOKE (SQL Form) statement 3–16REVOKE LOGON statement 2–2, 2–23REVOKE statement

rescinding privileges 3–12Rights

automatic 3–8explicit 3–9implicit 3–6ownership 3–6verification 3–14

Roles 3–15CREATE ROLE statement 3–15defined 3–15DROP ROLE statement 3–15GRANT (Role Form) statement 3–16GRANT (SQL Form) statement 3–15REVOKE (Role Form) statement 3–16REVOKE (SQL Form) statement 3–16SET ROLE statement 3–15using 3–15

inistration

Index

S

Scripts, DIPACC DBCSQL 4–7Security

administrator, establishing 3–3audit, DBC.AccLogTbl 4–2computer room 5–2CRASHDUMPS 5–4dump files 5–4hazards 1–3LAN server 5–5levels of 1–5need for 1–5network controls 5–5operating system 5–5policy, establishing 1–5, 5–2remote devices 5–3requirements, identifying 1–5SYSTEMFE 5–4Teradata RDBMS files 5–5user-level password attributes 3–17

Security Administration statementsSee Security Administration, or individual

statementsSecurity administrator

assigning attributes of 1–11duties 1–11establishing 3–3privileges 1–11role of 1–11tasks 1–7

Security controlsphysical components access 1–3Teradata access 1–2

Security features, system-enforced 1–9Security levels

C2 A–1, A–2high 1–6, 1–7minimal 1–6moderate 1–6, 1–7

Security policychanging 1–3enforcing 5–2key elements 1–9procedures 1–5reevaluating 1–9regulations 1–5setting up procedure 5–2

SELECT privilege 3–6, 3–8Session

establishing 1–2handling 2–21

SET ROLE statement 3–15


Single Sign Onbenefits 2–4definition 2–4pre-requisites 2–4

Space allocation 2–21, 3–5SQL statements

BEGIN TRANSACTION 4–5CREATE 3–6CREATE DATABASE 3–7, 3–8CREATE MACRO 3–8CREATE PROCEDURE 3–8CREATE TABLE 3–8CREATE TRIGGER 3–8CREATE USER 2–2, 3–7, 3–8CREATE VIEW 3–8END TRANSACTION 4–5GIVE 3–13GRANT 3–9GRANT LOGON 2–2MODIFY USER 3–3, 4–11REVOKE 3–6, 3–9REVOKE LOGON 2–2UPDATE 2–7

Stored procedurescreating 3–9privileges 3–8revoking 3–12

SysSecDefaults. See DBC.SysSecDefaults tableSystem administrator, establishing 3–3System tables

DBC.AccLogRuleTbl 4–7, 4–9DBC.AccLogTbl 4–9

System views. See ViewsSYSTEMFE, security 5–4

T

TDI A–1Tdpid

TDP unique identifier 2–3Teradata RDBMS

C2 security, system setup A–2identifiers 2–2physical system access 1–2resource access 1–2

TRIGGER privilege 3–8Trusted Database Interpretation. See TDI

Index –5

Index

Index –6

U

UPDATE privilege 3–8UPDATE statement 2–7User 3–5

access needs, identifying 1–8creating 2–2, 3–9groups, identifying 1–8

User DBCgetting locked out 2–16initial contents 3–2special user name 3–2

User groups, common 1–8Username

DBase system table 2–2identifier 2–2

V

ViewsDBC.AccessLog 4–2, 4–4, 4–9DBC.AccLogRules 4–2, 4–4, 4–9DBC.AllRights 4–2DBC.DeleteAccessLog 4–2, 4–10DBC.LogOnOff 4–2DBC.LogonRules 4–3, 4–4DBC.Users 2–2, 4–3

W

WITH GRANT OPTIONand GRAND privilege 3–9warning A–4

WITH NULL PASSWORD option 2–4

Security Adm
inistration

Security Administration

Documents

Transcript of Security Administration