Security Administration
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Security Administration

on

  • 2,509 views

 

Statistics

Views

Total Views
2,509
Views on SlideShare
2,509
Embed Views
0

Actions

Likes
1
Downloads
65
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Security Administration Document Transcript

  • 1. Teradata Database Security Administration Release V2R5.1 B035-1100-083A November 2003
  • 2. 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: teradata-books@lists.ncr.com or write: Information Engineering NCR Corporation 100 North Sepulveda Boulevard El Segundo, CA 90245-4361 U.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 Corporation All Rights Reserved
  • 3. 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
  • 4. Preface About 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 ii Security Administration
  • 5. Preface About This Book 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
  • 6. Preface About This Book 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). iv Security Administration
  • 7. Preface List 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
  • 8. Preface Technical 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 vi Security Administration
  • 9. Contents Preface Supported Software Release ............................................................................................ i Changes to This Book ....................................................................................................... i About This Book ..................................................................................................................ii List of Acronyms ................................................................................................................. v Technical Information on the Web...................................................................................vi Chapter 1: Introduction to Teradata Database Security Security Controls ............................................................................................................. 1–2 Introduction................................................................................................................... 1–2 Access Control .............................................................................................................. 1–2 Resource Access Control ............................................................................................ 1–2 Physical System Access Control................................................................................. 1–3 Auditing and Accountability ...................................................................................... 1–3 Establishing a Security Policy........................................................................................ 1–5 Introduction................................................................................................................... 1–5 Identifying Security Requirements ............................................................................ 1–5 Identifying Security Levels ......................................................................................... 1–5 Minimal Security .......................................................................................................... 1–6 Moderate Security ........................................................................................................ 1–7 High Security ................................................................................................................ 1–7 Identifying Users and Their Needs............................................................................... 1–8 Introduction................................................................................................................... 1–8 Common User Groups................................................................................................. 1–8 Formulating the Security Policy.................................................................................... 1–9 Introduction................................................................................................................... 1–9 System-Enforced Security Features ........................................................................... 1–9 Key Elements of a Security Policy.............................................................................. 1–9 Reevaluating the Security Policy................................................................................ 1–9 Security Administrator Role ........................................................................................ 1–11 Introduction................................................................................................................. 1–11 Duties of the Security Administrator ...................................................................... 1–11 Assigning Security Administrator Attributes to a User ....................................... 1–11 Security Administration vii
  • 10. Contents Chapter 2: Controlling Access to Teradata Database Identifiers.......................................................................................................................... 2–2 Introduction................................................................................................................... 2–2 Username Identifiers.................................................................................................... 2–2 Client System Identifiers ............................................................................................. 2–2 Logon Policy..................................................................................................................... 2–3 Introduction................................................................................................................... 2–3 Tdpid .............................................................................................................................. 2–3 Account String .............................................................................................................. 2–3 Password........................................................................................................................ 2–4 Single Sign On............................................................................................................... 2–4 Password Control ............................................................................................................ 2–6 Introduction................................................................................................................... 2–6 SysSecDefaults Table.................................................................................................... 2–6 Password Expiration .................................................................................................. 2–10 Resetting an Expired Password................................................................................ 2–10 Setting Password for New User ............................................................................... 2–11 Setting a Temporary Password................................................................................. 2–11 Password Format........................................................................................................... 2–13 Introduction................................................................................................................. 2–13 Rules for Creating a Password ................................................................................. 2–13 Examples of Using UPDATE to Set Password Values .......................................... 2–14 Specifying Password Length..................................................................................... 2–14 Submitting a Password String .................................................................................. 2–15 Error Messages............................................................................................................ 2–15 Maximum Logon Attempts.......................................................................................... 2–16 Password Lockout Time ............................................................................................... 2–18 Password Reuse ............................................................................................................. 2–19 Session Handling ........................................................................................................... 2–21 Introduction................................................................................................................. 2–21 Handling Space Allocation........................................................................................ 2–21 Handling Data Access................................................................................................ 2–21 Logon Control ................................................................................................................ 2–23 Introduction................................................................................................................. 2–23 Description of GRANT/REVOKE LOGON Statements ....................................... 2–23 Rules for Submitting GRANT/REVOKE LOGON Statements ........................... 2–23 Providing Access Control.......................................................................................... 2–24 General Rules and Precedence of Clauses .............................................................. 2–24 Encryption ...................................................................................................................... 2–25 Network Data Encryption ......................................................................................... 2–25 viii Security Administration
  • 11. Contents Logon Encryption....................................................................................................... 2–25 Chapter 3: Managing Data Access User DBC .......................................................................................................................... 3–2 Introduction................................................................................................................... 3–2 User DBC Contents ...................................................................................................... 3–2 Establishing a System Administrator ........................................................................... 3–3 User and Database........................................................................................................... 3–5 Introduction................................................................................................................... 3–5 Space Allocation ........................................................................................................... 3–5 Access Rights.................................................................................................................... 3–6 Introduction................................................................................................................... 3–6 Ownership Rights......................................................................................................... 3–6 Automatic Rights.......................................................................................................... 3–6 Examples Using GRANT Statement .......................................................................... 3–8 Example 1: User A Creating Database X................................................................... 3–8 Example 2: User A Creating User B ........................................................................... 3–9 Example 3: User C Creating Table Z.Y...................................................................... 3–9 Example 4: User D Creating Stored Procedure Z.SpSample.................................. 3–9 Explicit Rights ............................................................................................................... 3–9 Forms of GRANT Statement........................................................................................ 3–11 Forms of REVOKE Statement ...................................................................................... 3–12 Owners and Parents...................................................................................................... 3–13 Introduction................................................................................................................. 3–13 Object Ownership....................................................................................................... 3–13 Giving Ownership ...................................................................................................... 3–13 Rights Verification...................................................................................................... 3–14 Roles ................................................................................................................................ 3–15 Advantages of Using Roles ....................................................................................... 3–15 Related Topics ............................................................................................................. 3–15 Profiles ............................................................................................................................ 3–17 Definition ..................................................................................................................... 3–17 Advantages of Using Profiles ................................................................................... 3–17 Related Topics ............................................................................................................. 3–17 System-Wide Password Security.............................................................................. 3–18 Controlling User-Level Password Security ............................................................ 3–18 Chapter 4: Monitoring Access to Teradata Database System Views ................................................................................................................... 4–2 Security Administration ix
  • 12. Contents System View Queries ...................................................................................................... 4–4 Introduction................................................................................................................... 4–4 MONITOR-Related Queries........................................................................................ 4–4 Example 1: Determining Which Users Can Force Other Users Off System......... 4–4 Example 2: Determining Which Users Have Been Forced Off System................. 4–4 Example 3: Determining Who Is Currently Using the MONITOR ....................... 4–4 Controlling Access Log Entries ..................................................................................... 4–5 Overview of Logging ................................................................................................... 4–5 General Rules for Using DDL Statements................................................................. 4–5 Security Macro Privilege Checking............................................................................ 4–6 System Default .............................................................................................................. 4–6 BEGIN/END LOGGING Statements ........................................................................... 4–7 Introduction................................................................................................................... 4–7 Function ......................................................................................................................... 4–7 DBC.AccLogRuleTbl Entries....................................................................................... 4–7 DBC.AccLogTbl Entries ............................................................................................... 4–8 Logging at Database Level .......................................................................................... 4–8 Logging at Table Level................................................................................................. 4–9 Using BEGIN LOGGING With GRANT ................................................................... 4–9 Viewing Log Entries..................................................................................................... 4–9 Using END LOGGING .............................................................................................. 4–10 Purging Aged Log Entries......................................................................................... 4–10 DBC.AccLogRule Macro............................................................................................ 4–10 Access Logging and Errors ....................................................................................... 4–11 Changing Options With MODIFY USER ................................................................ 4–11 Using Account String Expansion ................................................................................ 4–12 Chapter 5: Physical System Security Controlling Machine Room Access............................................................................... 5–2 Introduction................................................................................................................... 5–2 Setting Security Policy ................................................................................................. 5–2 Enforcing Security Policy ............................................................................................ 5–2 Controlling Access to Outside Devices ........................................................................ 5–3 Controlling Access to Dump Files ................................................................................ 5–4 Controlling Access to the Operating System............................................................... 5–5 Appendix A: Running a Secure Teradata Database Securing System at C2 Level or Equivalent ................................................................ A–2 Introduction.................................................................................................................. A–2 x Security Administration
  • 13. Contents C2 Security Level Procedure...................................................................................... A–2 Potential Hazards ........................................................................................................... A–4 Index ......................................................................................................................... Index–1 Security Administration xi
  • 14. Contents xii Security Administration
  • 15. List of Tables Table 1-1 Advantages and Disadvantages of Data Security Levels.................. 1–6 Table 1-2 User Groups ............................................................................................. 1–8 Table 2-1 SysSecDefaults Column Descriptions .................................................. 2–8 Table 2-2 OldPasswords Column Descriptions ................................................. 2–20 Table 3-1 Creator Privileges .................................................................................... 3–8 Security Administration xiii
  • 16. List of Tables xiv Security Administration
  • 17. 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
  • 18. Chapter 1: Introduction to Teradata Database Security Security 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 1–2 Security Administration
  • 19. Chapter 1: Introduction to Teradata Database Security Security Controls 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 Security Administration 1–3
  • 20. Chapter 1: Introduction to Teradata Database Security Security Controls • Change access rights • Deny the offending users any access to Teradata Database (in extreme cases) 1–4 Security Administration
  • 21. Chapter 1: Introduction to Teradata Database Security Establishing 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: Step Action 1 Identify security needs. 2 Identify procedures and regulations to fulfill those needs. 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? Security Administration 1–5
  • 22. Chapter 1: Introduction to Teradata Database Security Establishing a Security Policy Table 1-1 Advantages and Disadvantages of Data Security Levels Minimal security... Moderate security... High security... • makes sharing • protects the system • affords a high level of information extremely from casual attempts protection to data and simple. to circumvent processing resources. • allows an environment security. • gives users confidence of trusted users with • requires little or no that their data is safe from unrestricted access to additional effort for unauthorized corruption all database resources users to perform their or disclosure and Advantages to realize a high level of work. unwarranted deletions. productivity. • involves • uses an auditing policy • requires few security security-related designed both to detect enforcement activities events that have little unauthorized access enhancing system or no effect on system attempts and permit the performance. performance. implementation of corrective measures. • allows anyone • can leave serious • requires that owners of accessing Teradata violation attempts shared data make Database to destroy or undetected for additional effort define corrupt data. extended periods. those authorized to access • gives anyone accessing • provides no the data. Teradata Database guidelines for • may degrade system access to all passwords possibly performance depending information stored letting users choose on the frequency and under its control. passwords that others scope of auditing and the Disadvantages • allows no private or can easily guess. demands of secret data. security-related events. • lets unauthorized users gain access to Teradata Database. • might degrade system performance by allowing unauthorized use or misuse of the system. 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. 1–6 Security Administration
  • 23. Chapter 1: Introduction to Teradata Database Security Establishing a Security Policy 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. Security Administration 1–7
  • 24. Chapter 1: Introduction to Teradata Database Security Identifying 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 Develop databases, tables, views, stored procedures, Programmers and macros on behalf of the end users. Systems Responsible for the installation, maintenance, and Programmers availability of Teradata Database to all system users. 1–8 Security Administration
  • 25. Chapter 1: Introduction to Teradata Database Security Formulating 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. Security Administration 1–9
  • 26. Chapter 1: Introduction to Teradata Database Security Formulating 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 1 – 10 Security Administration
  • 27. Chapter 1: Introduction to Teradata Database Security Security 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. Security Administration 1 – 11
  • 28. Chapter 1: Introduction to Teradata Database Security Security Administrator Role Step Action 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. 1 – 12 Security Administration
  • 29. 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. Security Administration 2–1
  • 30. Chapter 2: Controlling Access to Teradata Database Identifiers 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. 2–2 Security Administration
  • 31. Chapter 2: Controlling Access to Teradata Database Logon 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 Security Administration 2–3
  • 32. Chapter 2: Controlling Access to Teradata Database Logon Policy 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. 2–4 Security Administration
  • 33. Chapter 2: Controlling Access to Teradata Database Logon Policy SSO provides the following benefits: • Enhances site security because authentication mechanisms do not send passwords across the network • Saves time Security Administration 2–5
  • 34. Chapter 2: Controlling Access to Teradata Database Password Control Password Control Introduction Several password control features enhance Teradata Database security: 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 Defines the number of erroneous sequential logon attempts a Attempt user is allowed before the user is locked out from further logon attempts. Password Lockout Sets the user lockout time duration after the user has Time 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 Allow the security administrator to restrict the number of Password Features 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. 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. 2–6 Security Administration
  • 35. Chapter 2: Controlling Access to Teradata Database Password Control 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 ; Security Administration 2–7
  • 36. Chapter 2: Controlling Access to Teradata Database Password Control 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. 2–8 Security Administration
  • 37. Chapter 2: Controlling Access to Teradata Database Password Control This column… Indicates… 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. Security Administration 2–9
  • 38. Chapter 2: Controlling Access to Teradata Database Password Control 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 ; 2 – 10 Security Administration
  • 39. Chapter 2: Controlling Access to Teradata Database Password Control 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). Security Administration 2 – 11
  • 40. Chapter 2: Controlling Access to Teradata Database Password Control The following procedure expires the existing password and creates a temporary password to replace it. 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. For details, see the MODIFY USER syntax in SQL Reference: Data Definition Statements. 2 – 12 Security Administration
  • 41. Chapter 2: Controlling Access to Teradata Database Password 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. Security Administration 2 – 13
  • 42. Chapter 2: Controlling Access to Teradata Database Password Format 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. Example Description Set minimum number of The setting must be in the range from 1 to 30, and characters in password not less than the minimum number of characters: UPDATE DBC.SysSecDefaults SET PasswordMinChar = 6 ; Set maximum number of The setting must be in the range from 1 to 30, and characters in password 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 The setting must be either Y or N to allow special password 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 ; 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. 2 – 14 Security Administration
  • 43. Chapter 2: Controlling Access to Teradata Database Password Format 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. Security Administration 2 – 15
  • 44. Chapter 2: Controlling Access to Teradata Database Maximum 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. 2 – 16 Security Administration
  • 45. Chapter 2: Controlling Access to Teradata Database Maximum 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). Security Administration 2 – 17
  • 46. Chapter 2: Controlling Access to Teradata Database Password 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. 2 – 18 Security Administration
  • 47. Chapter 2: Controlling Access to Teradata Database Password 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 ); Security Administration 2 – 19
  • 48. Chapter 2: Controlling Access to Teradata Database Password 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. 2 – 20 Security Administration
  • 49. Chapter 2: Controlling Access to Teradata Database Session 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 Security Administration 2 – 21
  • 50. Chapter 2: Controlling Access to Teradata Database Session 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. 2 – 22 Security Administration
  • 51. Chapter 2: Controlling Access to Teradata Database Logon 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 Security Administration 2 – 23
  • 52. Chapter 2: Controlling Access to Teradata Database Logon 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. 2 – 24 Security Administration
  • 53. Chapter 2: Controlling Access to Teradata Database Encryption 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. Security Administration 2 – 25
  • 54. Chapter 2: Controlling Access to Teradata Database Encryption 2 – 26 Security Administration
  • 55. 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 Security Administration 3–1
  • 56. Chapter 3: Managing Data Access User 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. 3–2 Security Administration
  • 57. Chapter 3: Managing Data Access Establishing 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: 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. 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 Security Administration 3–3
  • 58. Chapter 3: Managing Data Access Establishing 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. 3–4 Security Administration
  • 59. Chapter 3: Managing Data Access User 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. Security Administration 3–5
  • 60. Chapter 3: Managing Data Access Access Rights Access Rights Introduction Three types of access rights (or privileges) are defined in this section: 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. 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 3–6 Security Administration
  • 61. Chapter 3: Managing Data Access Access Rights 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. Security Administration 3–7
  • 62. Chapter 3: Managing Data Access Access Rights Privileges that are automatically granted to the creator of an entity are listed in Table 3-1. Table 3-1 Creator Privileges CREATE Statement Automatic Rights CREATE DATABASE All privileges on databases, users, macros, tables, and views created in the new space, and DROP PROCEDURE privilege CREATE USER 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 DROP PROCEDURE and EXECUTE PROCEDURE on the PROCEDURE 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. 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 x TO a; 3–8 Security Administration
  • 63. Chapter 3: Managing Data Access Access Rights 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 Security Administration 3–9
  • 64. Chapter 3: Managing Data Access Access Rights 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. 3 – 10 Security Administration
  • 65. Chapter 3: Managing Data Access Forms of GRANT Statement Forms of GRANT Statement The GRANT statement has four forms: Statement Description GRANT (SQL In Teradata SQL, this statement pertains to access Form) 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 Used to grant system-wide performance monitoring (Monitor Form) privileges. GRANT Described in Chapter 2: “Controlling Access to LOGON Teradata Database,” in this book. GRANT (Role Used to grant role membership to users or other roles. Form) 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. Security Administration 3 – 11
  • 66. Chapter 3: Managing Data Access Forms of REVOKE Statement Forms of REVOKE Statement The REVOKE statement has four forms: Statement Description REVOKE (SQL Cancels privileges to a database, user, table, view, Form) 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 Cancels system-wide performance monitoring (Monitor Form) privileges. REVOKE Does either of the following: LOGON • Revokes permission to log on to the Teradata Database from one or more specific client systems. • Changes the current system logon defaults. REVOKE (Role Used to revoke role membership from users or other Form) roles. 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. 3 – 12 Security Administration
  • 67. Chapter 3: Managing Data Access Owners 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. Security Administration 3 – 13
  • 68. Chapter 3: Managing Data Access Owners 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. 3 – 14 Security Administration
  • 69. Chapter 3: Managing Data Access Roles 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. Security Administration 3 – 15
  • 70. Chapter 3: Managing Data Access Roles For more Information on . . . See . . . Revoking Rights from a "REVOKE (SQL Form)" in the "SQL Data Definition Role Language Statement Syntax" chapter of SQL Reference: Data Definition Statements. Granting a Role to a User "GRANT (Role Form)" in the "SQL Data Definition or Role Language Statement Syntax" chapter of SQL Reference: Data Definition Statements. Revoking a Role from a "REVOKE (Role Form)" in the "SQL Data Definition User or Role Language Statement Syntax" chapter of SQL Reference: Data Definition Statements. Assigning a default role "Using Roles to Manage User Access Privileges" in the to a user "SQL Data Definition Language Statement Syntax" chapter of SQL Reference: Data Definition Statements. 3 – 16 Security Administration
  • 71. Chapter 3: Managing Data Access Profiles 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: For more Information on . . . See . . . 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. Security Administration 3 – 17
  • 72. Chapter 3: Managing Data Access Profiles For more Information on . . . See . . . Modifying a Profile "MODIFY PROFILE" in the "SQL Data Definition Language Statement Syntax" chapter of SQL Reference: Data Definition Statements. Assigning Profiles to "Using Profiles to Manage System Parameters for Users Groups" in the "SQL Data Definition Language Statement Syntax" chapter of SQL Reference: Data Definition Statements. 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. 3 – 18 Security Administration
  • 73. 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. Security Administration 4–1
  • 74. Chapter 4: Monitoring Access to Teradata Database System 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. 4–2 Security Administration
  • 75. Chapter 4: Monitoring Access to Teradata Database System Views View Name Description 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. For information on system views, see Data Dictionary. Security Administration 4–3
  • 76. Chapter 4: Monitoring Access to Teradata Database System 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’ ; 4–4 Security Administration
  • 77. Chapter 4: Monitoring Access to Teradata Database Controlling 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 Security Administration 4–5
  • 78. Chapter 4: Monitoring Access to Teradata Database Controlling 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. 4–6 Security Administration
  • 79. Chapter 4: Monitoring Access to Teradata Database BEGIN/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. Security Administration 4–7
  • 80. Chapter 4: Monitoring Access to Teradata Database BEGIN/END LOGGING Statements 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 4–8 Security Administration
  • 81. Chapter 4: Monitoring Access to Teradata Database BEGIN/END LOGGING Statements • 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 Security Administration 4–9
  • 82. Chapter 4: Monitoring Access to Teradata Database BEGIN/END LOGGING Statements where Macro1 contains the following statement: SELECT . . . FROM Table1 • CALL SpSample1 where 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. 4 – 10 Security Administration
  • 83. Chapter 4: Monitoring Access to Teradata Database BEGIN/END LOGGING Statements 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. Security Administration 4 – 11
  • 84. Chapter 4: Monitoring Access to Teradata Database Using 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. 4 – 12 Security Administration
  • 85. 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. Security Administration 5–1
  • 86. Chapter 5: Physical System Security Controlling 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: 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. Enforcing Security Policy To effectively enforce the security policy, operators must be knowledgeable about the current security policy. 5–2 Security Administration
  • 87. Chapter 5: Physical System Security Controlling 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. Security Administration 5–3
  • 88. Chapter 5: Physical System Security Controlling 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. 5–4 Security Administration
  • 89. Chapter 5: Physical System Security Controlling 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. Security Administration 5–5
  • 90. Chapter 5: Physical System Security Controlling Access to the Operating System 5–6 Security Administration
  • 91. 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
  • 92. Appendix A: Running a Secure Teradata Database Securing 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 ; A–2 Security Administration
  • 93. Appendix A: Running a Secure Teradata Database Securing System at C2 Level or Equivalent Step Action 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. Security Administration A–3
  • 94. Appendix A: Running a Secure Teradata Database Potential 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. A–4 Security Administration
  • 95. Index CREATE TABLE 3–8 A CREATE USER 3–8 Access control 3–1 CREATE VIEW 3–8 BEGIN LOGGING statement 4–5 denying 1–4 END LOGGING statement 4–5 monitoring access rights 4–5 B password 2–4 physical 1–2, 1–3 BEGIN LOGGING statement resource 1–2 DDL 4–5, 4–7 restrictions 5–2 used with GRANT 4–9 types of 1–2 BEGIN TRANSACTION statement Access log entries BEGIN LOGGING Security Administration controlling 4–5 usage 4–5 errors 4–11 END LOGGING Security Administration usage 4–5 overview 4–5 purging 4–10 viewing 4–9 Access rights 2–21 changing 1–4 C security classes 1–5 C2 security A–1, A–2 types of 3–6 CHECKPOINT privilege 3–6 see also Privileges Child, defined 3–13 Account identifier, logon string 2–3 Clauses, FROM ownerdb 3–5 Account string 2–3 Client system identifier Account String Expansion. See ASE assigning using Configuration utility 2–2 Accountability 1–3 hostid 2–2 ADMIN space 3–3 Commands ASE ABORT SESSION 3–3 accurate capacity planning 4–12 CREATE USER 3–3 precise statistics 4–12 MONITOR RESOURCE 3–3 security audit information 4–12 Connection Audit data. See Audit trails LAN 1–2 Audit trails mainframe channel 1–2 archiving 1–3 WAN 1–2 examining 1–3 Crash. See Restart invoking 4–1 CRASHDUMPS, database security 5–4 logon/logoff activity 1–3 CREATE DATABASE statement 3–7, 3–8 printing 1–3 CREATE PROCEDURE statement 3–8 report generation 1–3 CREATE PROFILE statement 3–17 statements, using 1–3 CREATE ROLE statement 3–15 suspending 4–1 CREATE statement 3–6 Teradata RDBMS events 1–3 CREATE statements Auditing 1–3 CREATE DATABASE 3–8 Automatic privileges 3–6 CREATE MACRO 3–8 Automatic rights CREATE PROCEDURE 3–8 CREATE DATABASE 3–8 CREATE TABLE 3–8 CREATE MACRO 3–8 CREATE TRIGGER 3–8 Security Administration Index –1
  • 96. Index CREATE USER 3–8 invalid values for 2–10 CREATE USER ADMIN 3–3 DBC.SysSecDefaults table 2–6, 2–7 CREATE VIEW 3–8 DBC.Users view 2–2, 4–3 CREATE TABLE statement 3–8 DDL statements CREATE TRIGGER statement 3–8 BEGIN LOGGING 4–5, 4–7 CREATE TRIGGER WITH GRANT OPTION 3–8 END LOGGING 4–5, 4–7 CREATE USER 3–3 general rules 4–5 CREATE USER ADMIN statement 3–3 usage rules 4–5 CREATE USER statement 2–2, 3–7, 3–8 DELETE privilege 3–8 Creator DIPACC DBCSQL script 4–7 definition 3–13 DROP PROCEDURE privilege 3–8 privileges 3–8 DROP PROFILE statement 3–17 DROP ROLE statement 3–15 DROP TABLE privilege 3–8 Dump file, security 5–4 D DUMP privilege 3–6, 3–8 Data access control. See Access control Data access requests start auditing 4–7 stop auditing 4–7 E Data Dictionary, contents 4–1 Encryption Database 3–5 logon 2–25 creating 3–8 network data 2–25 security 5–4 END LOGGING statement transfer ownership 3–13 DDL 4–5, 4–7 DBC usage 4–8, 4–10 log on 3–3 END TRANSACTION statement space 3–3 BEGIN LOGGING Security Administration user DBC 3–2 usage 4–5 user DBC locked out 2–16 END LOGGING Security Administration DBC.AccessLog view 4–2, 4–4, 4–9 usage 4–5 DBC.AccLogRule macro 4–10 EXECUTE privilege 4–6 DBC.AccLogRules view 4–2, 4–4, 4–9 EXECUTE PROCEDURE privilege 3–8 DBC.AccLogRuleTbl entries 4–7, 4–9 Expired password, resetting 2–10 DBC.AccLogTbl entries 4–8, 4–9 Explicit rights, privileges 2–22 DBC.AllRights view 4–2 DBC.AMPUsage storing statistics 4–12 user/account string pair 4–12 F DBC.DBase system table FROM ownerdb, clause 3–5 database names 2–2 DBC.Users entries 4–3 usernames 2–2 DBC.DeleteAccessLog view 4–2, 4–10 G DBC.LogOnOff view logon/logoff activity 4–2 GIVE statement 3–13 unsuccessful logon attempts 4–2 Giving Ownership 3–13 DBC.LogonRules view 4–3, 4–4 GRANT (Role Form) statement 3–16 DBC.OldPasswords table 2–19 GRANT (SQL Form) statement 3–15 DBC.SysSecDefaults Table GRANT LOGON statement 2–2 column description 2–8 GRANT privilege 3–8 Index –2 Security Administration
  • 97. Index GRANT statement activity 4–2 access privilege control, forms of 3–11 DBC.LogOnOff view 4–2 examples using 3–8, 3–9 Logon GRANT statement, forms of account string 2–3 GRANT 3–11 activity 4–2 GRANT LOGON 3–11 controlling user 2–23 GRANT MONITOR 3–11 DBC.LogOnOff view 4–2 GRANT/REVOKE LOGON statements DBC.SysSecDefaults.MaxLogonAttempts 2–16 general rules 2–24 how to release lock on failed logon 2–16 precedence of clauses 2–24 maximum number of attempts 2–16 MODIFY USER statement, using 2–16 password string 2–3 permission, multiple hosts 2–23 H policy 2–3 string 2–3 High security UPDATE statement, using 2–16 advantages 1–6 why unsuccessful 4–2 disadvantages 1–6 Logon string operands Hostid account string 2–3 associated with usernames 2–23 password 2–3 channel connection 2–23 tdpid 2–3 client system identifier 2–2 LAN connection 2–23 see Client system identifier see also GRANT LOGON or REVOKE LOGON M statement Hosts, multiple, logon permission 2–23 Macros, DBC.AccLogRule 4–10 Minimal security advantages 1–6 disadvantages 1–6 I Moderate security advantages 1–6, 1–7 Identifier type, client system 2–2 disadvantages 1–6 Implicit rights MODIFY privilege, logged indirectly in audit 4–11 privileges 2–22 MODIFY PROFILE statement 3–18 see also Ownership 3–6 MODIFY USER statement 2–11, 2–16, 4–11 INSERT privilege 3–8 N K National Computer Security Center. See NCSC Keywords NCSC A–1 DATABASE 3–5 Network controls, security 5–5 USER 3–5 Network security 5–5 L O Logging Object database level 4–8 creating 3–7 table level 4–9 ownership of 3–13 Logoff Security Administration Index –3
  • 98. Index Object Ownership 3–13 RESTORE 3–6, 3–8 ON clause 3–3 SELECT 3–6, 3–8 Operating system TRIGGER 3–8 restrictions 5–5 UPDATE 3–8 security controls 5–5 verifying 3–14 special privileges 5–5 Profiles 3–17 Owner, definition 3–13 CREATE PROFILE statement 3–17 Ownership defined 3–17 rights, forms of 3–6 DROP PROFILE statement 3–17 transfer database 3–13 MODIFY PROFILE statement 3–18 using 3–17 P Q Parent, defined 3–13 Password Queries changing 1–3 monitor-related 4–4 control 2–6 via system views 4–4 control features 2–8 DBC.SysSecDefaults option 2–6 expiration 2–6, 2–10 format 2–13 R length 2–15 REFERENCE privilege 3–8 lockout time 2–18 Release password lock 2–16 logon string 2–4 Remote devices, security 5–3 null option 2–6 old 2–19 Resource access control 1–2 release lock, MODIFY USER statement 2–16 Restart, security, dump files 5–4 resetting expired 2–10 RESTORE privilege 3–6, 3–8 reuse 2–19 REVOKE (Role Form) statement 3–16 setting for new user 2–11 REVOKE (SQL Form) statement 3–16 temporary 2–11 REVOKE LOGON statement 2–2, 2–23 PERM space 3–3 REVOKE statement Physical access control 1–3 rescinding privileges 3–12 Privileges Rights access types 3–6 automatic 3–8 automatic 3–6 explicit 3–9 checking, DBC.AccessLog view 4–2 implicit 3–6 CHECKPOINT 3–6 ownership 3–6 data access 2–21 verification 3–14 DELETE 3–8 Roles 3–15 DROP PROCEDURE 3–8 CREATE ROLE statement 3–15 DROP TABLE 3–8 defined 3–15 DUMP 3–6, 3–8 DROP ROLE statement 3–15 EXECUTE 2–24, 4–6 GRANT (Role Form) statement 3–16 EXECUTE checking 2–24 GRANT (SQL Form) statement 3–15 EXECUTE PROCEDURE 3–8 REVOKE (Role Form) statement 3–16 GRANT 3–8 REVOKE (SQL Form) statement 3–16 granted to creator 3–8 SET ROLE statement 3–15 INDEX 3–8 using 3–15 INSERT 3–8 REFERENCE 3–8 Index –4 Security Administration
  • 99. Index Single Sign On S benefits 2–4 Scripts, DIPACC DBCSQL 4–7 definition 2–4 Security pre-requisites 2–4 administrator, establishing 3–3 Space allocation 2–21, 3–5 audit, DBC.AccLogTbl 4–2 SQL statements computer room 5–2 BEGIN TRANSACTION 4–5 CRASHDUMPS 5–4 CREATE 3–6 dump files 5–4 CREATE DATABASE 3–7, 3–8 hazards 1–3 CREATE MACRO 3–8 LAN server 5–5 CREATE PROCEDURE 3–8 levels of 1–5 CREATE TABLE 3–8 need for 1–5 CREATE TRIGGER 3–8 network controls 5–5 CREATE USER 2–2, 3–7, 3–8 operating system 5–5 CREATE VIEW 3–8 policy, establishing 1–5, 5–2 END TRANSACTION 4–5 remote devices 5–3 GIVE 3–13 requirements, identifying 1–5 GRANT 3–9 SYSTEMFE 5–4 GRANT LOGON 2–2 Teradata RDBMS files 5–5 MODIFY USER 3–3, 4–11 user-level password attributes 3–17 REVOKE 3–6, 3–9 Security Administration statements REVOKE LOGON 2–2 See Security Administration, or individual UPDATE 2–7 statements Stored procedures Security administrator creating 3–9 assigning attributes of 1–11 privileges 3–8 duties 1–11 revoking 3–12 establishing 3–3 SysSecDefaults. See DBC.SysSecDefaults table privileges 1–11 System administrator, establishing 3–3 role of 1–11 System tables tasks 1–7 DBC.AccLogRuleTbl 4–7, 4–9 Security controls DBC.AccLogTbl 4–9 physical components access 1–3 System views. See Views Teradata access 1–2 SYSTEMFE, security 5–4 Security features, system-enforced 1–9 Security levels C2 A–1, A–2 high 1–6, 1–7 T minimal 1–6 moderate 1–6, 1–7 TDI A–1 Security policy Tdpid changing 1–3 TDP unique identifier 2–3 enforcing 5–2 Teradata RDBMS key elements 1–9 C2 security, system setup A–2 procedures 1–5 identifiers 2–2 reevaluating 1–9 physical system access 1–2 regulations 1–5 resource access 1–2 setting up procedure 5–2 TRIGGER privilege 3–8 SELECT privilege 3–6, 3–8 Trusted Database Interpretation. See TDI Session establishing 1–2 handling 2–21 SET ROLE statement 3–15 Security Administration Index –5
  • 100. Index U UPDATE privilege 3–8 UPDATE statement 2–7 User 3–5 access needs, identifying 1–8 creating 2–2, 3–9 groups, identifying 1–8 User DBC getting locked out 2–16 initial contents 3–2 special user name 3–2 User groups, common 1–8 Username DBase system table 2–2 identifier 2–2 V Views DBC.AccessLog 4–2, 4–4, 4–9 DBC.AccLogRules 4–2, 4–4, 4–9 DBC.AllRights 4–2 DBC.DeleteAccessLog 4–2, 4–10 DBC.LogOnOff 4–2 DBC.LogonRules 4–3, 4–4 DBC.Users 2–2, 4–3 W WITH GRANT OPTION and GRAND privilege 3–9 warning A–4 WITH NULL PASSWORD option 2–4 Index –6 Security Administration