Teradata Database. Security Administration

Teradata Database

Security Administration

The product or products described in this book are licensed products of Teradata Corporation or its affiliates.

Teradata, BYNET, DBC/1012, DecisionCast, DecisionFlow, DecisionPoint, Eye logo design, InfoWise, Meta Warehouse, MyCommerce, SeeChain, SeeCommerce, SeeRisk, Teradata Decision Experts, Teradata Source Experts, WebAnalyst, and You’ve Never Seen Your Business Like This Before are trademarks or registered trademarks of Teradata Corporation or its affiliates.

Adaptec and SCSISelect are trademarks or registered trademarks of Adaptec, Inc. AMD Opteron and Opteron are trademarks of Advanced Micro Devices, Inc.

BakBone and NetVault are trademarks or registered trademarks of BakBone Software, Inc. EMC, PowerPath, SRDF, and Symmetrix are registered trademarks of EMC Corporation. GoldenGate is a trademark of GoldenGate Software, Inc.

Hewlett-Packard and HP are registered trademarks of Hewlett-Packard Company. Intel, Pentium, and XEON are registered trademarks of Intel Corporation.

IBM, CICS, RACF, Tivoli, and z/OS are registered trademarks of International Business Machines Corporation. Linux is a registered trademark of Linus Torvalds.

LSI and Engenio are registered trademarks of LSI Corporation.

Microsoft, Active Directory, Windows, Windows NT, and Windows Server are registered trademarks of Microsoft Corporation in the United States and other countries.

Novell and SUSE are registered trademarks of Novell, Inc., in the United States and other countries. QLogic and SANbox are trademarks or registered trademarks of QLogic Corporation.

SAS and SAS/C are trademarks or registered trademarks of SAS Institute Inc. SPARC is a registered trademark of SPARC International, Inc.

Sun Microsystems, Solaris, Sun, and Sun Java are trademarks or registered trademarks of Sun Microsystems, Inc., in the United States and other countries.

Symantec, NetBackup, and VERITAS are trademarks or registered trademarks of Symantec Corporation or its affiliates in the United States and other countries.

Unicode is a collective membership mark and a service mark of Unicode, Inc.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Other product and company names mentioned herein may be the trademarks of their respective owners.

THEINFORMATIONCONTAINEDINTHISDOCUMENTISPROVIDEDONAN “AS-IS” BASIS, WITHOUTWARRANTYOFANYKIND, EITHER EXPRESSORIMPLIED, INCLUDINGTHEIMPLIEDWARRANTIESOFMERCHANTABILITY, FITNESSFORAPARTICULARPURPOSE, OR NON-INFRINGEMENT. SOMEJURISDICTIONSDONOTALLOWTHEEXCLUSIONOFIMPLIEDWARRANTIES, SOTHEABOVEEXCLUSION MAYNOTAPPLYTOYOU. INNOEVENTWILL TERADATA CORPORATIONBELIABLEFORANYINDIRECT, DIRECT, SPECIAL, INCIDENTAL, ORCONSEQUENTIALDAMAGES, INCLUDINGLOSTPROFITSORLOSTSAVINGS, EVENIFEXPRESSLYADVISEDOFTHEPOSSIBILITYOF SUCHDAMAGES.

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 Teradata Corporation intends to announce such features, functions, products, or services in your country. Please consult your local Teradata Corporation 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. Teradata Corporation 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]

Any comments or materials (collectively referred to as “Feedback”) sent to Teradata Corporation will be deemed non-confidential. Teradata Corporation 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, Teradata Corporation 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.

Preface

Purpose

The purpose of this book is to assist administrators in formulating, implementing, and auditing security policy for a Teradata Database system. Use it to:

• Understand the basic components of Teradata Database system security.

• Determine a security policy appropriate for your system and the business environment in which it operates.

• Prevent unauthorized users from gaining access to the system.

• Limit the access of legitimate Teradata Database users to only those resources (databases, tables, views, stored procedures, and macros) they are authorized to use.

• Monitor security events and take corrective action.

• Understand the structure and content of the Teradata Database security mechanisms that create session security context, and how to modify them.

• Enable linking of the directory users with Teradata Database users, external roles, and profiles.

Audience

This book is intended for those who plan and implement system security measures including:

• Security administrators

• Database administrators

• System administrators

• Others involved in data management and operations

Supported Software Release

Preface

Changes to This Book

Changes to This Book

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

Release Description

Teradata Database 13.0 November 2009

• Revised the following topics in Chapter 5.

• Tdpid

• LDAP Authcid Logons

• LDAP UPN Logons for Mapped Directory Users

• UPN Credential Format

• Restricting Logons by Host Group

• Revised Chapters 5 and 8 to describe the differences in configuration requirements for the SPNEGO mechanism for Teradata Database running on various operating systems. Teradata Database 13.0

April 2009

• Added information on trusted sessions and proxy users to Chapters 2 and 3.

• Added information on SSL/TLS protection options to Chapters 4, 7, 8, 9, and Appendix F.

• Extensively revised the content of Chapter 7 to include more comprehensive coverage of access logging.

• Added information to Chapters 8 and 9 in support of new binding options.

• Added new entries to the list of certified directories to Chapter 9.

• Added new information on changing the TDGSS configuration for Windows .Net clients to Appendix C.

• Added new Appendix G: “Setting up Kerberos Authentication on Unix Nodes.”

• Added a new limit on use of IP-based access restrictions to Appendix I.

Teradata Database 12.00.00.12 March 2008

• Added information about the new SPNEGO mechanism, which supports logons through Windows .Net clients, to Chapters 5 and 8.

• Revised requirements for external authentication logons in Chapter 5 and added the GenerateCredentialsFromLogon property to Chapter 8.

Preface Additional Information

Additional Information

Teradata Database 12.0 September 2007

• Added information on support for kerberos authentication on Teradata Database systems running MP-RAS and SUSE Linux Enterprise Server to Chapter 2 and new Appendix F.

• Added information on password control enhancements to Chapter 2 and new Appendix E.

• Added information on internationalization to Chapter 2.

• Revised the section on automatically inherited rights in Chapter 3.

• Added set up instructions for specification of backup directory servers in Chapter 5.

• Extensively revised the material on IP logon restrictions in Chapter 6 and Appendix D.

• Added a warning about continued use of Append Domain Name in Chapter 2.

Release Description

URL Description

http://www.info.teradata.com/ Use the Teradata Information Products Publishing Library site to:

• View or download a manual:

1 Under Online Publications, select General Search.

2 Enter your search criteria and click Search.

• Download a documentation CD-ROM:

1 Under Online Publications, select General Search.

2 In the Title or Keyword field, enter CD-ROM, and

click Search.

• Order printed manuals:

Under Print & CD Publications, select How to Order.

http://www.teradata.com The Teradata home page provides links to numerous sources of information about Teradata. Links include:

• Executive reports, case studies of customer experiences with Teradata, and thought leadership

• Technical information, solutions, and expert advice

• Press releases, mentions and media resources

http://www.teradata.com/t/TEN/ Teradata Customer Education designs, develops and delivers education that builds skills and capabilities for our customers, enabling them to maximize their Teradata

Preface

References to Microsoft Windows and Linux

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]

References to Microsoft Windows and Linux

• “Windows” is Microsoft Windows Server 2003 64-bit.

Table of Contents

Preface. . . .3

Purpose . . . .3

Audience . . . .3

Supported Software Release . . . .3

Changes to This Book . . . .4

Additional Information . . . .5

References to Microsoft Windows and Linux . . . .6

Chapter 1: Introduction to Teradata Database System

Security

Teradata Database Security Principles . . . 21

Security Controls. . . 22

Controlling Physical Access . . . 22

Controlling Database Access . . . 23

Transmitting Secure Logons and Data. . . 23

Monitoring Database Activity. . . 23

Determining Security Requirements. . . 24

Business Value of Security. . . 24

Identifying Users and Their Needs . . . 25

Common User Groups . . . 25

Determining the Required Level of Security . . . 26

Minimal Security . . . 26

Moderate Security . . . 27

High Security . . . 27

Advantages and Disadvantages of Security Levels. . . 27

Formulating Security Policy. . . 28

Site-specific Teradata Database Security Policy . . . 28

Re-evaluating Security Policy . . . 29

Security Administration . . . 29

Table of Contents

Chapter 2: Creating Users and Defining Access Privileges

Users and Databases . . . .31

System Generated Users . . . .31

Guidelines for Creating Users. . . .32

Administrative Users . . . .33

Security Administrator Responsibilities. . . .34

Creating the Security Administrator User . . . .35

Database Administrator User . . . .36

Controlling Access to the Operating System . . . .36

Controlling Access to Teradata Dynamic Workload Manager . . . .37

Database Users . . . .37

Directory Managed Users . . . .41

Proxy Users. . . .41 Database Privileges . . . .43 Ownership Privileges . . . .44 Giving Ownership . . . .44 Related Topics . . . .45 Explicit Privileges . . . .45

Granting and Revoking Explicit Privileges . . . .45

Forms of the GRANT and REVOKE Statements . . . .45

Revoking Privileges from PUBLIC or ALL DBC . . . .48

Automatic Privileges . . . .49

User DBC Automatic Privileges . . . .49

Creator/Modifier Automatic Privileges . . . .49

Optional Methods for Limiting Database Access. . . .50

Views . . . .50

Macros. . . .50

Stored Procedures . . . .50

Related Topics . . . .50

Chapter 3: User Identification and Authentication

User Identification . . . .51

Teradata Database Authentication . . . .51

External Authentication . . . .52

System Requirements for External Authentication . . . .53

Other Setup Options for External Authentication . . . .54

External Authentication with Delegated Credentials . . . .55

Table of Contents

Accessing the Database Through a Middle-tier Application . . . 56

Establishing Trusted Sessions . . . 56

Granting Privileges to Establish and Use Trusted Sessions . . . 57

Security Considerations for Trusted Sessions . . . 58

Chapter 4: Protection

Logon Encryption . . . 61

Password Encryption . . . 62

SASL Protection for Systems Using DIGEST-MD5 Binds . . . 62

SSL/TLS Protection for Systems Using Simple Binds . . . 62

Data Encryption . . . 63

Data Integrity . . . 63

Related Topics . . . 63

BAR Encryption . . . 63

Chapter 5: Logon Requirements and Controls

Logon Elements. . . 65

Security Mechanism. . . 65

Database User Names . . . 66

Directory User Names . . . 67

Domain User Names . . . 67

Domain/Realm . . . 67

Appended Domain Name . . . 68

Passwords . . . 69

Tdpid . . . 69

Account String . . . 70

Using UTF-16 Characters in the Logon String . . . 70

Network Logon Formats . . . 72

Logon Requirements Determined by Authentication Type. . . 72

Logon Syntax . . . 72

Command Line Logons . . . 73

Logons Using Teradata Database Authentication. . . 73

Logons Using External Authentication . . . 74

Single Sign-on. . . 74

LDAP Logons . . . 75

Table of Contents

Common Errors with LDAP UPN Logons . . . .80

Sign-on As . . . .81

Explanation of Example 1 . . . .82

Explanation of Example 2 . . . .83

Common Errors with UPN Logons . . . .84

GUI Logons . . . .84

Logons Through Teradata Query Director. . . .85

Logons from Channel-Attached Systems . . . .86

Logons from Teradata Database Nodes . . . .86

Replication Logons . . . .86

Encryption of Replication Sessions . . . .87

Logons from Fully Managed .Net Clients. . . .87

Logon Errors . . . .87

Logon Error Handling Options . . . .88

Logon Controls . . . .88

Granting Logons . . . .88

Revoking Logons . . . .88

Precedence of Clauses . . . .89

Restricting Logons by Host Group. . . .89

Restricting Logons by IP Address . . . .91

Chapter 6: Creating and Managing Passwords . . . .93

Creating Passwords . . . .93

Related Topics . . . .93

Password Format Requirements. . . .93

Forgotten Passwords and Password Lockouts . . . .95

Tracking Changes to Passwords . . . .96

Password Control Options. . . .97

Controlling Passwords With Multibyte Characters . . . .97

Password Controls Located in DBC.SysSecDefaults. . . .97

Viewing Current Password Control Settings. . . .98

Using UPDATE to Manage Global Password Controls in DBC.SysSecDefault . . . .98

Using CREATE or MODIFY PROFILE to Password Controls for Specific Users . . . .99

Comparing Methods of Password Control Management . . . .101

Setting Password Controls . . . .102

ExpirePassword . . . .102

MaxLogonAttempts . . . .103

PasswordReuse . . . .105

Table of Contents PasswordMinChar . . . 107 PasswordMaxChar . . . 107 PasswordDigits . . . 108 PasswordSpecChar . . . 108 PasswordRestrictWords. . . 110 Error Messages . . . 112

Chapter 7: Monitoring Database Activity

Monitoring Options and Objectives . . . 113

Access Logging of Database Users . . . 113

Default Logging . . . 113

Requirements for Using BEGIN/END LOGGING Statements . . . 114

Using BEGIN LOGGING to Enable Logging Functions . . . 114

General Rules for Using DDL Statements in Access Logging . . . 114

DBC.AccLogRuleTbl Entries. . . 115

DBC.AccLogTbl Entries . . . 115

Database Level Logging . . . 116

Table Level Logging . . . 116

Using BEGIN LOGGING With GRANT . . . 117

Logging MODIFY Statements. . . 117

BEGIN/END Logging Errors. . . 117

Disabling Access Logging with the END LOGGING Statement . . . 117

Access Logging of Directory Users . . . 118

Setting up the Gateway to Identify Directory Users in Access Logs . . . 119

Access Logging of Proxy Users. . . 119

Monitoring Security Related Tables and Views . . . 120

Viewing Log Entries . . . 122

Deleting Aged Log Entries. . . 122

Querying Systems Views. . . 123

MONITOR Related Queries . . . 123

Querying Session-Related Views . . . 123

Chapter 8: TDGSS Administration

TDGSS Standards . . . 127

Table of Contents

Locating TDGSS Files . . . .129

TDGSS File Contents. . . .129

TDGSS Site File . . . .130

TDGSS File Maintenance Tools . . . .130

tdgsspkgrm . . . .130

tdgssversion . . . .131

TDGSS Configuration Files . . . .133

C/C++ and Java Application Sharing of TDGSS Configuration Files . . . .134

Setting the Java Application Classpath. . . .134

Using the Jar Update Command . . . .134

TDGSS Security Mechanisms . . . .135 Mechanism Selection . . . .135 Default Mechanism . . . .136 Mechanism Handling . . . .136 Mechanism Configurations . . . .137 TD2 Mechanism. . . .138 KRB5 Mechanism . . . .139 NTLM Mechanism. . . .140 LDAP Mechanism . . . .141 SPNEGO Mechanism . . . .143 Mechanism Properties . . . .144

Special Handling for New Properties . . . .144

Basic Functional Properties . . . .145

AuthenticationSupported . . . .145

AuthorizationSupported . . . .146

GenerateCredentialFromLogon . . . .147

SingleSignOnSupported . . . .148

Mechanism Status Properties. . . .149

DefaultMechanism. . . .149 MechanismEnabled . . . .150 MechanismRank . . . .151 Operational Properties . . . .152 DelegateCredentials . . . .152 MutualAuthentication . . . .153 ReplayDetection . . . .154 OutOfSequenceDetection . . . .155 ConfidentialityDesired . . . .156 IntegrityDesired . . . .157 AnonymousAuthentication. . . .158 DesiredContextTime . . . .159 DesiredCredentialTime . . . .160 CredentialUsage . . . .161

Table of Contents

Directory User Authentication Properties . . . 162

LdapServerName . . . 162

Set up for LDAP Server Failover Protection . . . 163

LdapServerPort. . . 164 LdapServerRealm . . . 165 LdapSystemFQDN . . . 166 LdapBaseFQDN . . . 166 LdapGroupBaseFQDN . . . 167 LdapUserBaseFQDN . . . 168 LdapClientDebug . . . 169 LdapClientDeref. . . 170 LdapClientRebindAuth . . . 171

LDAP Binding Properties. . . 172

LdapClientMechanism . . . 172

LdapServiceBindRequired . . . 173

LdapServiceFQDN . . . 174

LdapServicePassword. . . 175

LDAP Protection Properties . . . 176

SSL/TLS Protection . . . 176

Avoiding Conflicts with OpenLDAP Tunables . . . 176

LdapClientTlsCACert . . . 177 LdapClientTlsCACertDir . . . 178 LdapClientTlsCert . . . 179 LdapClientTlsCipherSuite. . . 180 LdapClientTlsCRLCheck. . . 180 LdapClientTlsKey. . . 182 LdapClientTlsRandFile . . . 183 LdapClientTlsReqCert . . . 184 LdapClientUseTLS . . . 185 SASL Protection . . . 186 LdapClientSASLSecProps . . . 186 Confidentiality Properties . . . 187 VerifyDHKey . . . 187 DHKeyPand DHKeyG . . . 188

Changing the TDGSS Configuration . . . 190

Differences in Function for Client and Server Configuration Files. . . 191

General Rules for Editing . . . 192

Adding New Mechanisms or Properties to the User Configuration File . . . 193

Effects of Upgrade and Migration on TDGSS Configuration Changes . . . 194

Table of Contents

Chapter 9: Directory Management of Database Users

Supported Directories. . . .197

LDAP Binding Options . . . .198

Directory User Binding Options. . . .198

Service Binds. . . .199

Directory User Identification Options . . . .202

Identity Mapping . . . .202

Configuring an Identity Map . . . .203

Identity Searches . . . .205

Using <IdentityMap> and <IdentitySearch> in Combination . . . .206

Using <IdentityMap> and <IdentitySearch> with DIGEST-MD5. . . .209

Directory User Management Options. . . .209

Option 1: Authentication Only--No Directory Schema Changes . . . .210

Option 2: Directory Authorization of Database Users . . . .211

Related Topics . . . .212

Directory User Characteristics. . . .212

Characteristics of Unmapped Directory Users . . . .213

Characteristics of Directory Users Mapped to Permanent Users . . . .213

Ownership of Database Objects Created by Directory Users. . . .214

Roles and Profiles for Directory Users . . . .215

Database Administration of External Roles . . . .215

Directory Administration of External Roles . . . .215

Session Role Hierarchy and Role Switching . . . .216

Effects of ‘Drop External Role’ on Directory User Roles . . . .216

Effects of Changing Directory Role Assignments . . . .216

Profiles for Directory Users. . . .216

Related Topics . . . .216

Access Logging of Directory Users . . . .217

Configuring a Directory to Manage Database Users . . . .217

Directory Schema Overview. . . .217

Teradata Schema Extensions. . . .217

Attribute Usage Requirements . . . .220

Special Objects and Attributes Required for Active Directory and ADAM . . . .223

System Evaluation . . . .224

Optimization of Directory Searches . . . .224

Appendix A: System Level Security . . . .227

Table of Contents

Setting Physical Security Policy . . . 227

Enforcing Security Policy . . . 228

Controlling Access to Dump Files . . . 228

Controlling Access to the Operating System . . . 228

Controlling Access to Outside Devices . . . 228

Appendix B: Running a Secure Teradata Database

Securing a System to the Common Criteria Evaluated Configuration . . . 229

Common Criteria Level Security Procedure . . . 229

Avoiding Potential Security Hazards. . . 232

Appendix C: Changing the TDGSS Configuration

Using dumpcfg to Check the Current TDGSS Configuration . . . 233

Changing the TDGSS Configuration on SUSE Linux Enterprise Server Nodes . . . 235

Changing the TDGSS Configuration on MP-RAS Nodes . . . 236

Changing the TDGSS Configuration on Windows Nodes . . . 237

tdgss Configuration Errors. . . 238

Making TDGSS Configuration Changes on Teradata Clients . . . 238

Changing the TDGSS Configuration on Windows Clients . . . 239

Changing the TDGSS Configuration on Windows .Net Clients . . . 240

Changing the TDGSS Configuration on Linux Clients . . . 242

Changing the TDGSS Configuration on non-Linux UNIX Clients . . . 243

Reversion Procedure . . . 243

Appendix D: System Evaluation Tasks for Directory

Integration

Checking the Network . . . 245

From a Teradata Client . . . 245

From Teradata Database Server Nodes . . . 246

Testing the Directory Server . . . 246

The RootDSE Object . . . 246

Table of Contents

Server Down: As Seen from Windows . . . .250

Server Down: As Seen from MP-RAS . . . .251

Invalid User, Password, or Realm. . . .251

Common Errors with Sun Java Directory Server. . . .252

Server Down . . . .252

Bad Canonicalization. . . .252

Bad User . . . .253

Bad Password . . . .253

Appendix E: Configuring a Directory to Manage Teradata

Database Users

Installing Teradata Schema Extensions in a Supported Directory . . . .255

Schema Installation Options. . . .256

Installation on Active Directory or ADAM from Teradata Database on Windows. . . . .256

Installation on Active Directory or ADAM from Teradata Database on MP-RAS or SUSE Linux Enterprise Server . . . .258

Installation on Sun Java System Directory Server. . . .260

Installation on Novell eDirectory . . . .261

Directory Information Tree . . . .262

Teradata Database Objects in the DIT Hierarchy . . . .262

Populating the Directory Information Tree . . . .265

tdatRootNode Object. . . .265

tdatSystem Object . . . .265

Creating Containers and Inserting Objects . . . .266

Naming Conventions. . . .266

Entering Container and Object Information in the Directory . . . .266

Users . . . .267

Roles . . . .267

Profiles . . . .267

IP Filters . . . .268

Mapping Directory Users to Teradata Database Objects . . . .269

Mapping Directory Users to Database Users. . . .269

Mapping Directory Users to Database External Roles . . . .270

Mapping Directory Users to Database Profiles . . . .270

Mapping IPFilters to Database Users . . . .271

Testing Mapped Directory Users. . . .271

Using BTEQ to Verify Directory User Mapping . . . .272

tdsbind . . . .274

Running tdsbind . . . .274

Table of Contents

Explanation of Example 1 . . . 277

Explanation of Example 2 . . . 279

Diagnosing Logon Failure Due to Incorrect Realm Information . . . 281

tdsbind Error Output. . . 281

ldapsearch . . . 282

Running ldapsearch . . . 282

Usage Notes for ldapsearch . . . 284

Finding User Information with ldapsearch . . . 285

Determining the schemaNamingContext Value . . . 290

Other LDAP Tools . . . 291

Appendix F: Setting Up SSL/TLS Options

Requirements. . . 293

Supported Versions . . . 293

Installation of OpenSSL. . . 294

Basic SSL/TLS Support Required to Support Advanced Options . . . 294

Configuring Basic SSL/TLS Functions . . . 294

SSL Protection . . . 295

TLS Protection . . . 295

Preparing to Configure Advanced Options . . . 295

Directory Server Certificate Requirements . . . 296

Authentication of the Directory Server by Teradata Database . . . 298

Verifying the Directory Server Certificate Chain . . . 298

Step 1: Obtaining the Directory Server Certificate Chain . . . 298

Step 2: Creating the CA Certificate Hashes . . . 302

Step 3: Configuring TDGSS and TeraGSS . . . 303

Step 4: Testing the Connection. . . 304

Mutual Authentication of the Directory Server and Teradata Database . . . 305

Installing Certificates and Private Keys . . . 305

Installing the Private Key. . . 305

Installing the Certificate . . . 306

Repeat the Installations for the Entire Database . . . 307

Updating the TDGSS or TeraGSS Configuration . . . 307

Troubleshooting . . . 308

Hostname Does Not Match CN in Peer Certificate . . . 308

SSL: Certificate Verify Failure . . . 309

Table of Contents

Appendix G: Setting up Kerberos Authentication on Unix

Nodes

Active Directory Setup . . . .313

Task 1: Create a Computer Component for Each Teradata Database Node . . . .314

Task 2: Add Unix Nodes to the Domain Name System (DNS) . . . .314

Task 3: Create an Active Directory User for Each Unix Node . . . .315

Task 4: Determine the Service Principal Name. . . .316

Task 5: Run ktpass to Create the Kerberos Keys . . . .317

Task 6: Move the Kerberos Keys to the Teradata Database System . . . .318

Teradata Database Node Setup . . . .319

Task 7: Install Kerberos on All Teradata Database Nodes . . . .319

Task 8: Setup krb5.conf Kerberos Configuration File . . . .320

Task 9: Verify That a Unix Node Can Find the Name Server . . . .327

Task 10: Install the Kerberos Keys . . . .327

Task 11: Synchronize Time Between the Domain and the Nodes. . . .330

Task 12: Check the Kerberos Synchronization Setup . . . .334

Appendix H: Controlling User Access by IP Address

Principals of IP AccessRestriction . . . .337

Usage Constraints . . . .337

Ensuring Security . . . .338

Creating an XML IP Restriction Document . . . .339

Saving the Completed XML IP Restriction Document . . . .339

Designing IP Restrictions . . . .339

IP Restriction Concepts . . . .340

Element Descriptions. . . .340

IP Filters . . . .342

Effects of Filter Type on allow and deny Elements . . . .344

Addresses and Mask Structure . . . .345

How Masks Affect Filters. . . .345

Important Masking Properties . . . .346

Forms of Interaction Between Primary and Secondary Masked IPs . . . .347

Permissive Filters . . . .350

Restrictive Filters . . . .352

Applying a Filter to a User. . . .355

Application of IP Restrictions. . . .357

Applying a Filter to All Users . . . .358

Table of Contents

Loading Directory Schema Extensions for IP Restriction of Directory Users . . . 359

Creating IP Restriction Schema Objects in the Directory . . . 359

Standard Teradata Database Schema Objects . . . 359

IP Filter Schema Objects . . . 360

Mapping IP Filters to Database Users . . . 362

Data Conversion Utilities . . . 363

ipxml2bin . . . 363

ipdir2bin . . . 364

Appendix I: Password Restricted Words . . . 367

Default Restricted Words . . . 367

Frequently Used Words. . . 367

Frequently Used Names. . . 377

Glossary

CHAPTER 1

Introduction to Teradata Database

System Security

The information in this book is intended help security administrators to understand and perform the following security functions:

• Authenticate users at logon to prevent outsiders from gaining access to the system.

• Manage logon and password controls to ensure secure authentication.

• Authorize users to access only those objects and resources for which they have permission.

• Employ and modify security mechanisms to facilitate the user authentication and authorization strategy.

• Manage Teradata Database users externally using a directory.

• Enable encryption to secure message transmissions between client and server.

• Monitor security events and, where necessary, take corrective action.

• Create a site security policy based on site requirements, Teradata Database capabilities, and the chosen implementation strategy.

Teradata Database Security Principles

Security Principle Description

Database User A database user is an individual defined in the database and identified by a username and password. The user definition also includes provisions to define the space available to the user for creating database objects, the accounts to which the user can charge jobs, and membership in a profile, which can determine a number of system parameters that apply to the user. Database Privileges A user can access and interact with the database only as defined in the

database privileges assigned to the user. These privileges can be granted explicitly to a user, or to a role of which the user is a member. Users acquire some privileges implicitly or automatically as part of other privileges, or as a result of creating database objects.

Logon Users accessing Teradata Database must logon with a username and password. They may choose to logon to the database directly or through a middle-tier application. The logon also defines the security mechanism that will be used to authenticate the user.

Chapter 1: Introduction to Teradata Database System Security Security Controls

Security Controls

You must define and implement effective security controls to establish and maintain optimal database security. You can control database security in the following ways.

• Restrict physical access to database system hardware.

• Use logon controls to limit access to the database.

• Define database privileges for each user to restrict activity within the database.

• Secure data transmissions to and from the database using encryption.

• Monitor user activity to detect security threats and violations.

The following sections provide an overview of how to exercise these controls.

Controlling Physical Access

The most basic level of security is to limit access by unauthorized persons to the physical components of the Teradata Database system. These components include processor nodes, disk storage units, and the Administration Workstation (AWS).

Controlling access to physical components involves the following elements:

• Protect the system against deliberate damage by locating it in a secure room.

Authentication At logon, the username and password are compared with a list valid users to verify that the user is “authentic.” Authentication can be performed by Teradata Database or by an external agent, such as a directory.

Authorization Users are authorized database privileges based on:

• Privileges explicitly or implicitly granted in the database.

• Mapping of directory-based users to database users, roles, and profiles. Security Mechanisms Selectable database objects that define how the user will be authenticated, and in some cases, authorized. Logons use the mechanism specified in the logon string, or if no mechanism is specified, the current default

mechanism.

Access Logging The database can be configured to log all user attempts to access the database, as well as the database objects that are accessed.

Protection Network transmissions between the database and its clients are protected as follows:

• By default, logon strings are encrypted.

• Network traffic between Teradata Database and its clients can be optionally encrypted.

• Additional protection is available for directory user logons, including obfuscation of the logon string and peer authentication of the directory and database.

Chapter 1: Introduction to Teradata Database System Security Security Controls

• Control access to external devices used to connect to the system, such as remote terminals. For detailed suggestions, see Appendix A: “System Level Security.”

Controlling Database Access

Users may access Teradata Database internally, by way of system nodes and administrative work stations (AWS), or externally by way of connected clients. The administrator controls access to the system by assigning a unique username and password to each user.

Each database user must submit a username and password at logon. Once the system verifies that the username and the password are valid, it establishes a session with the user and assigns a unique session number. The session then runs under the combined identifier of the session number and the username until the user logs off.

The user is the basis for ownership of all databases, objects (tables, views, stored procedures, and macros), and other users created during a session. The system provides users certain database privileges. In addition, the administrator can explicitly and selectively grant other privileges to users or groups of users.

For information on how to regulate user access, see Chapter 2: “Creating Users and Defining Access Privileges.”

Transmitting Secure Logons and Data

Data transmitted between the database and clients is secured using encryption. There are two types of encryption:

• Logon strings are automatically encrypted to ensure the security of passwords transmitted from clients to the database.

• SSL and TLS are available to protect the token exchange during the authentication sequence.

• Users can selectively enable or disable encryption of data transmissions between the clients and the database.

For additional information, see Chapter 4: “Protection.”

Monitoring Database Activity

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

• Logon irregularities and attempted break-ins

• Attempts to gain unauthorized access to database resources

• Attempts to alter security monitoring parameters

Teradata Database automatically audits and logs all user logon and logoff activity. The security administrator can also specify auditing of attempts to access data by configuring the system to log one or more of the following additional parameters:

Chapter 1: Introduction to Teradata Database System Security Determining Security Requirements

• 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 can take one of the following remedial actions to address the problem:

• Initiate further monitoring of offending users

• Modify database access privileges

• Change compromised passwords

• Deny the offending users access to Teradata Database (in extreme cases)

• Change the security policy

Related Topics

For detailed information see, Chapter 7: “Monitoring Database Activity.”

Determining Security Requirements

Teradata Database offers a wide array of security features. In order to make the correct choices about which security features to use, you should balance the cost of setting up and

maintaining available security tools and procedures against your actual security needs.

• Evaluate your existing security policy, its effectiveness, and how it may need to change with the introduction of Teradata Database.

• Consider the business value of database security including government requirements, industry standards, and the business disruption that could result from a security breach.

• Identify the types of data in the database and the level of access required by users.

• Identify the ways in which Teradata Database will be accessed and the security concerns associated with each one.

• Define the level of security that is appropriate for your data and users.

• Employ the security options that best fit your implementation of Teradata Database and your existing security policy.

Business Value of Security

Creating and maintaining a security policy costs money. The security policy you decide to use should be based on sound business decisions. How important is security to your business?

Industry Standards

Most businesses retain a large amount of proprietary customer and supplier data. Customers and suppliers expect that data to remain confidential. Industries respond to this need for

Chapter 1: Introduction to Teradata Database System Security Identifying Users and Their Needs

confidentiality by defining and maintaining customer-acceptable levels of data security. Businesses that do not meet industry-standard levels of security may have trouble competing with those businesses that do.

Government Standards

Some businesses work directly on government contracts that contain contract-specific security requirements. Some are part of industries such as defense, financial, or medical that may be subject to a wide variety of local, state, and national government regulations, both foreign and domestic, in which they do business. Administrators should become acquainted with all applicable government security regulations before finalizing security policy.

Possibility of Business Disruption

How likely is it that someone would want to damage system hardware; to steal or corrupt your data? How would it affect your business if this happened? If the risk is moderate to high, your company has probably already initiated a security policy. Even if the risk of a serious security breach appears to be low, the losses your business might suffer if something did happen probably dictate that system security be taken seriously.

Some kind of formal statement of security policy is needed by most businesses. What security policy will adequately protect your system without negatively impacting the users?

Identifying Users and Their Needs

Teradata Database security requirements are directly influenced by the needs of its users and the security risks they represent. 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 significant restrictions on user privileges and without

resorting to frequent and detailed audits. However, for all but the smallest user communities, the time required to adequately screen all users and the cost of physical access controls may make this an undesirable security policy. For these reasons, a comprehensive and cost-effective security policy should be based on use of software-enforced Teradata Database security constraints and monitoring procedures.

Common User Groups

When formulating a security policy, you must balance the access needs of database users with the need to provide database security. Database users have different access needs based on the job functions they perform and the ways they use the data. Most Teradata Database users fall into one or more of the groups listed in Table 1.

Chapter 1: Introduction to Teradata Database System Security Determining the Required Level of Security

For information on regulating database user access, see Chapter 2: “Creating Users and Defining Access Privileges.”

Generally, users should be granted access privileges based on the needs of the work they perform. However, strict adherence to this concept may not result in the most efficient or economical security policy. Before making a final decision on establishing user access privileges, you should consider the threat users may pose, and the effects of their unauthorized access.

Determining the Required Level of Security

Once you understand the security risks for your database, the likelihood of them occurring, and the consequences of their occurrence, you must determine the appropriate level of security to counter the possible threats.

Minimal 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. This approach may be attractive for small Teradata Database systems, including test systems, that have a small number of trusted administrative users who can access the system directly.

Under a minimal security policy, the only security-related access restriction is on the initial logon to a client mainframe or PC that is capable of communicating with Teradata Database. Teradata Database can be configured to use the client directory for user authentication and authorization. For more information on interfacing with directories, see Chapter 9: “Directory Management of Database Users.”

Table 1: User Groups

User Group Duties Suggested Access

Administrators Responsible for the installation, setup, maintenance, performance, and availability of Teradata Database.

Principal administrators usually require full access to the database, including all privileges. Secondary or assistant administrators may be given more restricted access.

Application Programmers

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

Programmers may need wide access to create or restructure databases and objects, but should be restricted from adding or changing data. End Users Make Teradata SQL requests to Teradata

Database to view, add, or change data.

Limit user access to only the data and data manipulation functions users need to perform their assigned duties.

Some high-level end users may require special privileges.

Chapter 1: Introduction to Teradata Database System Security Determining the Required Level of Security

Moderate Security

Under moderate security, the database administrator performs security administration duties, grouping users according to their needs and trustworthiness, and assigning access privileges accordingly. Only a small, privileged subgroup has unlimited access. The security

administrator performs only occasional auditing of security-related events. Security

administration policy is documented for administrators, but no formal security policy exists for the users.

High Security

High security requires that the security administrator formally establish and maintain Teradata Database security. The security administrator is responsible for following security-related actions:

• Careful control of physical access to system processors, disk storage units, and terminals.

• Approval of those username/client system combinations Teradata Database allows to establish a session.

• Definition and control of the auditing of security-related events.

• Review of the results of security-related audits and initiation of corrective action.

• Creation of a detailed security policy document for administrators, application programmers, and end 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 administrator should receive a document that explains their role in supporting the security policy. Administrator awareness is important to early detection of potential security violations.

Advantages and Disadvantages of Security Levels

Each level of security has both advantages and disadvantages. You should consider whether the advantages of a level are worth their cost, or if the disadvantages make it impractical.

Chapter 1: Introduction to Teradata Database System Security Formulating Security Policy

Formulating Security Policy

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

Site-specific Teradata Database Security Policy

System-enforced security features are relatively easy to implement. However, Teradata Database offers many security options, and it is not possible for the administrator and user documentation to identify the specific combination your site will choose to employ. To make sure administrators and users at your site understand and follow site-specific security procedures, the security administrator should create and distribute a security handbook. It should summarize your overall security policy, as well as highlighting Teradata Database security features and how they are to be used for your database.

Table 2: Advantages and Disadvantages of Data Security Levels

Category 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 that might impact system performance.

• protects the system from casual attempts to circumvent security.

• requires little or no

additional effort for users to perform their work.

• employs security practices 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 disclosure, corruption, or deletions.

• uses an auditing policy that detects unauthorized access attempts and permits the implementation of corrective measures.

Disadvantages • allows anyone accessing Teradata Database the opportunity to steal, destroy, or corrupt data.

• provides 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 security violations undetected for extended periods.

• provides no guidelines for user security practices such as setting passwords, possibly allowing users to choose passwords that others can easily guess.

• requires significant additional effort for administrators to precisely define and authorize user data-access privileges.

• may degrade system

performance depending on the frequency and scope of auditing and the demands of other required security practices.

Chapter 1: Introduction to Teradata Database System Security Security Administration

The security policy document should include explanations of the following topics:

• An overview of your company’s security needs and how they are being met

• Benefits that will be derived from a secure system

• Teradata Database security policy, including:

• A brief overview of Teradata Database security functions.

• Required security actions for users, such as logon and password regulations.

• Explanation of security mechanisms, their selection, and how they are to be employed by users and groups.

• Logon options, such as external authentication; especially use of single sign-on and directory sign-on.

• Database access privileges and restrictions.

• Security restrictions and management policy for security violations.

• A list of contacts who can answer security questions.

Re-evaluating Security Policy

Your security policy should not remain static. You should conduct periodic reviews to reevaluate whether the existing policy meets the current needs of the system, the users, and the company.

The following factors may make changes to the security policy necessary:

• Addition of new access points and users.

• Changes in the profiles and needs of existing users.

• Changes in business focus that raise or lower the security requirements.

• Discovery of security violations, potential violations, or attempted violations that require procedural changes.

• New releases of Teradata Database software that introduce new security features.

Security Administration

One or more individuals should assume responsibility for the duties of Teradata Database security administrator. For small systems or those with low-level security needs, security administration duties may be handled by the system or database administrator. Larger, more complex systems, may require a separate security administrator or even a security

administration team.

Duties of the Security Administrator

The designated security administrator is responsible for defining and documenting security policy. A security administrator typically performs the following duties:

Chapter 1: Introduction to Teradata Database System Security Security Administration

• Sets and manages password controls.

• Identifies the users, objects, and SQL functions to be audited.

• Monitors security incidents and initiates corrective action.

• Coordinates Teradata Database security concerns with other administrators. For example, working with the database administrator in the creation and maintenance of users, roles, and profiles.

• Develops, documents, and distributes site security policy to administrators and users. For detailed information on best practice for setting up the security administrator user, see

CHAPTER 2

Creating Users and Defining

Access Privileges

This chapter provides an overview of critical tasks required to create database users and define the privileges they have to access, add, change, or delete data.

For detailed information on how to create users and databases, and grant database privileges, see Database Administration.

Users and Databases

Teradata Database users and databases are permanent storage spaces that can contain and own objects such as tables, indexes, procedures, triggers, functions, and other databases and users. However, whereas a database is a passive container, a user with the required privileges can logon to Teradata Database, establish a session, and perform actions in a database.

To establish and maintain database security, it is important that users and databases be properly created and administered. The following sections explain the user and database security concerns.

System Generated Users

Most database users must be actively created using the CREATE USER statement. However, a few “system generated” users are created by the DIP scripts, which execute by default as part of the Teradata Database software installation process.

System generated users automatically perform a number of basic system-level tasks in the database with no setup. Some options exist for employing these users to accomplish specialized tasks.

For further information, see Database Administration.

User DBC

The top level system user, DBC, is the owner or parent of all other databases, objects, and users. By default, user DBC has all possible privileges for interacting with the database, and can grant privileges to lower level users.

Initially, user DBC contains:

• All Teradata Database-managed disk space available to the database.

Chapter 2: Creating Users and Defining Access Privileges Users and Databases

Because user DBC owns all of the disk space managed by Teradata Database it is the parent of all other users, including the administrative users. Once created, the administrative users own most of the disk space and are responsible for creating and managing all other users,

databases, and objects.

User DBC Security Warnings!

Warning: Because of the wide range of database privileges available to user DBC, only the most trusted administrative personnel should have access to the user DBC password.

Warning: Never alter the database privileges for user DBC. Changing DBC privileges may cause installation, upgrade, maintenance, archive, or other procedures to end abnormally and consequently require Teradata Support Center assistance to correct the problem. Other System Generated Users

User DBC owns all databases and users including those created by the DIP script during installation. The following additional system generated users are automatically created by the DIP scripts. • SysAdmin • SystemFE • ALL • CRASHDUMPS • DEFAULT • PUBLIC • TDPUSER

Note: System generated users may have access to sensitive data and functions within the

database, therefore, Teradata recommends assigning new passwords in place of the default passwords for all system generated users.

Warning: System generated users perform important system-level functions. Do not alter the database privileges for a these users unless specifically directed to do so in Teradata Database

documentation. Access to system generated users should be limited to trusted administrators.

For further information on the function and use of system generated users, see Database

Administration.

Guidelines for Creating Users

Users not generated by the system, i.e. administrative users and database end users, must be actively created using the CREATE USER statement. Teradata suggests that you adhere to the following security guidelines when you create users and grant them privileges in the database.

• Create separate users for the security administrator and database administrator functions, even on small systems where both sets of tasks will be done by the same person. This separation of functions helps to clarify and emphasize security concerns.

• Ensure that all users are uniquely identified, so that monitoring of database access

accurately reflects the activity of individuals. Avoid allowing multiple users to log on using the same username whenever possible, to maintain access log specificity.

Chapter 2: Creating Users and Defining Access Privileges Users and Databases

• Grant only the minimum number of privileges to users required for the jobs they perform. Even administrative users should not necessarily have every privilege available to user DBC. Granting users more access than they need causes unnecessary privilege checks, puts users at risk of unintentionally modifying or deleting unfamiliar objects and data, and could allow unwarranted user access to proprietary data.

• Grant CREATE and GRANT privileges only to administrators and other high level users who understand the security implications of these actions.

• Wherever possible, use roles to control and manage privileges of groups of users according to their job description or responsibility rather than granting privileges to individuals. This approach helps to simplify user management and provides a consistent level of privileges to users with similar jobs.

Make sure that site-specific rules for creating users and granting user privileges are clearly spelled out in your site security policy.

For information about creating users and granting privileges, see Database Administration. For a description of other methods of limiting database access, see “Optional Methods for Limiting Database Access” on page 50.

Administrative Users

Administration of a particular Teradata Database site should always be done according to site-specific administrative needs. However, all sites should have at least one administrator with clearly defined administrative duties who manages the database and the user community. Administrative users should have sufficient database privileges to perform their function, while taking care to restrict the privileges of the general user community to prevent them from accessing administrative databases and functions.

Teradata recommends that you divide administrative duties into two functional groups, the security administrator and the database administrator, regardless of the number of persons acting as administrators. Where necessary, create lower level administrative users in the space owned by the administrative group to which they belong.

User DBC should create both the database and security administrator users. Disk space owned by user DBC that is not needed for system tables should be allocated to administrative users--the database administrator, security administrator, and if necessary, ousers--ther assistant

Chapter 2: Creating Users and Defining Access Privileges Users and Databases

As administrators create users and databases, a hierarchical relationship evolves, as follows:

• DBC directly creates the database administrator (A) and security administrator (B) users. DBC is the immediate owner (parent) of A and B, and owns everything in the hierarchy.

• The database administrator (A) owns database (C) and assistant administrator (D), and then creates user (F) in database (C).

• A is the immediate owner, or parent, of C and D.

• C is the immediate owner, or parent, of F.

• The security administrator (B) creates assistant security administrator (E).

• B is the immediate owner, or parent, of E.

Owners of objects have implicit privileges on those objects. For more detailed information on the effects of object ownership, see “Ownership Privileges” on page 44.

Security Administrator Responsibilities

Teradata recommends that security administrators assume the following responsibilities:

• Work with the database administrator to evaluate site security requirements, determine the level of protection needed for adequate security, and define the security features that will both support security requirements and allow users to efficiently do their job.

• Develop a security policy based on how the site will use Teradata Database capabilities to meet security needs. Distribute the policy to administrators.

• Create a set of user-level security rules and distribute them to users.

• Set up and manage the TDGSS configuration to support site security policy.

• Coordinate with the database administrator in creation and maintenance of users, roles, and profiles.

• Coordinate with the database administrator and directory administrator to set up optional directory management of database users.

• Manage user logon permissions and password controls.

• Set up optional access restrictions by IP address.

• Set up database access logging and monitor the output for security violations.

• Take action to repel security threats, including revising user privileges, revoking logons, and dropping users. Enforcement actions should only be taken with the knowledge and participation of the database administrator.

DBC

F

C D E

A B

Chapter 2: Creating Users and Defining Access Privileges Users and Databases

Creating the Security Administrator User

Provide the security administrator with the privileges required to carry out administrative duties. For sites that require more than one security administrator, especially where duties vary among administrators, use roles to define administrator database privileges.

Perform the following steps to create the security administrator user and grant the minimum privileges necessary to carry out security administration duties:

1 Log on to Teradata Database as user DBC.

2 Update the value for ExpirePassword in DBC.SysSecDefaults to a non-zero value so the temporary password assigned to the security administrator user will expire at first logon, and require creation of a private password.

UPDATE DBC.SysSecDefaults SET ExpirePassword = 30 ;

3 Create the security administrator user with a CREATE USER statement. The example that follows employs the user name “SECADMIN.”

The CREATE USER statement should assign a temporary security administrator password and set the size of the PERMANENT, SPOOL, and TEMPORARY space. For details on how to determine space requirements, see Database Administration.

CREATE USER SECADMIN AS PASSWORD = xxx,

PERMANENT = xxx, SPOOL = xxx,TEMPORARY = XXX FALLBACK ;

You can specify other user attributes in the initial CREATE USER statement or later with a MODIFY USER statement. For further information, see Database Administration

4 After creating user SECADMIN, enter the following SQL statements to grant user SECADMIN the basic privileges recommended by Teradata for security administrators.

GRANT USER ON SECADMIN TO SECADMIN /* maintain users */ ;

GRANT ROLE TO SECADMIN /* maintain roles */ ; GRANT PROFILE TO SECADMIN /* maintain profiles */ ;

GRANT SELECT ON DBC TO SECADMIN /* select on dictionary tables */ ;

GRANT UPDATE ON DBC.SysSecDefaults TO SECADMIN /* password characteristics */ ;

GRANT EXECUTE ON DBC.LogonRule TO SECADMIN /* logon rules */ ; GRANT EXECUTE ON DBC.AccLogRule TO SECADMIN /* access logging */ ;

GRANT DELETE ON DBC.AccLogTbl TO SECADMIN /* delete audit entries */ ;

GRANT DELETE ON DBC.DeleteAccessLog TO SECADMIN /* delete audit entries */ ;

GRANT DELETE ON DBC.EventLog TO SECADMIN /* delete event log */ ;

5 Next, provide the security administrator the authority to control and monitor user logons, using the GRANT/REVOKE LOGON and BEGIN/END LOGGING statements, as follows:

GRANT EXECUTE ON DBC.LogonRule TO SECADMIN ; GRANT EXECUTE ON DBC.AccLogRule TO SECADMIN ;

Chapter 2: Creating Users and Defining Access Privileges Users and Databases

7 Immediately log back onto Teradata Database as username SECADMIN. Create a personal password at the prompt.

8 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 WITH TEXT ON EACH ALL ON MACRO DBC.LogonRule, MACRO DBC.AccLogRule ;

Executing this statement generates audit entries for all subsequent Teradata SQL statements that control auditing of actions on, and the source of logons to, the database. 9 Log off Teradata Database.

You can assign other privileges to the security administrator depending on system needs.

Database Administrator User

Employ user DBC to create the database administrator user. Teradata recommends that database administrators be granted privileges sufficient to carry out the following responsibilities:

• Create and manage users, profiles (except password controls), databases, tables, views, query logs, stored procedures, and journals.

• Grant database privileges to users and roles.

• The database administrator should work closely with the security administrator to develop guidelines for granting user privileges based on an evaluation of site security requirements and user needs.

• Manage space and allocate it to users and databases.

• Create and manage accounts, and assign them to users.

• Manage data checking and protection.

• Monitor and tune system performance.

• Troubleshoot user problems.

• Manage periodic maintenance tasks.

• Manage extract and load utilities, such as FastLoad, MultiLoad, and Teradata Parallel Transporter.

For information on creating the database administrator user and performing the various administration tasks, see Database Administration.

Controlling Access to the Operating System

It is important to restrict access to the operating system to only administrators with special privileges. Establish operating system and network security controls to secure Teradata Database. Restrict users without special privileges from accessing the LAN through the operating system to prevent inadvertent corruption of Teradata Database data files.

In addition, all Teradata systems can be set up with operating system-level security hardening. Hardening for systems running on SUSE Linux Enterprise Server Enterprise Server is enabled at the factory. Security hardening prevents users with access to Teradata Database from using this access to perform unauthorized activities at the operating system level.

Chapter 2: Creating Users and Defining Access Privileges Users and Databases

Controlling Access to Teradata Dynamic Workload Manager

Teradata Dynamic Workload Manager (Teradata DWM) is a Teradata Database tool for managing database resources. Access to Teradata DWM requires submitting a special username and password. Because of the powerful effects of this tool, allow as few users as is practical to access the Teradata DWM username and password.

For information on Teradata DWM, see Teradata Dynamic Workload Manager User Guide.

Database Users

Each database user is defined by the database administrator with a CREATE USER statement:

CREATE USER USERXYZ AS PASSWORD = xxx

Database administrators should observe the following security guidelines when creating users:

• Create database users in the space owned by the principal database they will use.

• Grant privileges directly to users, or to roles that will in turn be granted to the users, in accordance with guidelines set out in the site security policy, as developed by the security administrator.

The following sections present an overview of the elements of the CREATE USER statement from a security perspective. For details on creating users and granting privileges, see Database

Administration. User Name

Specification of the username in a CREATE USER statement must take into account the following security concerns.

• Must be unique within the database.

• Should represents a single person. Teradata recommends not allowing more than one person to logon with the same username. Such an approach eliminates the ability to monitor the database activities of individuals.

User Password

A CREATE USER statement submitted without a password specification will be rejected by the system. The password specified in the CREATE USER statement is only temporary, and therefore it need not be unique. By default the PasswordChgDate parameter for each newly created user is set to 0 in DBC.Users. This value requires that the user create a personal password at first logon. Thereafter, the user will be periodically prompted by the system to create a new password at intervals defined by password expiration settings.

For information on password controls, see Chapter 5: “Logon Requirements and Controls.”

Space Allocation

From a security perspective, user space allocation should be based on the user privileges and responsibilities in the database. Ownership of permanent space automatically provides