Chapter 6 Working with Users, Roles, and Profiles: Operational DBAs. Teradata Release 15.10
Реклама
Реклама
CHAPTER 6
Working with Users, Roles, and
Profiles: Operational DBAs
This chapter describes the strategies that an administrator can use to control user access.
Specific topics include:
•
Assessing user needs to develop a user management strategy
•
Creating users and user accounts
•
Creating user profiles
•
Using roles to manage privileges
•
Granting privileges directly to users
•
Creating Teradata Viewpoint users
Overview of Establishing Users
To establish users for the first time, perform all the tasks in this chapter completely and in the order presented.
1
Group potential database users by functional group and determine database access needs.
See
“Assessing Database User Needs” on page 106
.
2
Set up user accounts to track resource usage and assign workload priorities. See
3
Set up profiles to define resources, account assignments, and password control parameters for groups of users.
“Creating User Profiles” on page 110
.
4
Create database users and assign profiles, space and accounts. See
5
Create roles to define privileges for users groups and grant role membership to users.
“Using Roles to Manage User Privileges” on page 117
.
6
Grant additional privileges that are not suitable for role assignment directly to users. See
“Granting Privileges Directly to Users” on page 125 .
User Access Methods
This book describes permanent database users who are created with the CREATE USER request, have PERM space on disk, and are authenticated by Teradata Database. For more information on granting privileges to users not managed in the database, for example directory users, see Security Administration.
Database Administration 105
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Types of Users
Types of Users
The following list identifies five typical user types and job functions.
Functional Category Description
General users
Update users
Batch users
Database end-users who only need to read the data or to run preexisting queries or macros to generate reports.
Privileged users who perform some general user functions and who also may need to insert, update or delete data, and create new database objects.
High-level users who typically perform batch-level functions, for example:
•
Load, update, and export operations, including creation and deletion of staging tables.
•
Data backup, archive, and restore operations.
Database programmers
Assistant administrators
Users who design and create queries, macros, and stored procedures, as well as database objects, for use by the user community. Programmers may require administrator privileges within a development database, while needing only limited privileges in the main production database.
Administrative users that assist the principal administrator, user
DBADMIN, created in
“Setting Up Teradata Administrator” on page 29
.
Assistant administrative users may have most or all of the same privileges granted to user DBADMIN, but have a much smaller permanent space allocation because they have a limited ownership of objects
Note: You can create additional user types where necessary to identify functional differences, however, the examples provided in this book are based on these user types.
Assessing Database User Needs
Assess database user needs and develop a user management strategy before you begin executing user management setup tasks.
1
2
Create a list of all users that require access to Teradata Database and identify each one according to user type. Minimize the number of user types to simplify user management.
Define user resource requirements for use in creating profiles:
•
Examine user space requirements.
•
Users that create or own databases, tables and other space-consuming objects require permanent storage space (perm space).
•
Users that execute SQL queries, macros, or stored procedures require spool space to contain the required temporary database structures. The spool specification in a
106 Database Administration
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Best Practices for Creating Users
3
4
5
profile limits the amount of available space a profile member can use.
•
Define user accounting requirements for use in specifying one or more account strings.
Each profile can include one or more accounts. Each account can specify:
•
A priority level (low, medium, high, and rush)
•
A four-character account identifier based on department, group, or function.
•
A date and time stamp
•
Define the user default database, that is, the database where the user most often works.
•
Define password control parameters. Refer to the chapters on password controls and managing passwords in Security Administration. Consider your site security policy and decide whether or not all users can share global password parameters, or if you need to set them by user group, in profiles.
Review the database objects (such as views, tables, macros, functions, and procedures) that users or user groups must access to do their job. Always define database privileges at the highest level that is appropriate for a particular user. For example, if a user requires the same privileges on all views in a database, assign privileges at the database level.
Identify groups of users with common database privilege requirements and create roles to define the privileges for each group. Consolidate minor differences in access requirement where possible to minimize the number of roles.
You may need to assign specialized privileges directly to individual users.
Best Practices for Creating Users
While there is no single set of procedures that would best fit all the varieties of system configurations possible and meet all site requirements, consider the following suggestions for best practices in creating users.
•
Create separate users for the security administrator and database administrator.
Establish a security administrator user to perform security-related tasks. The biggest threat to security is usually the misuse of information or privileges by authorized users. No one single user should have all the privileges for everything. Neither should an administrative user have access to something for which he does not need access.
•
Ensure that all users are uniquely identified. This means not allowing several users to log in to Teradata Database using the same username.
Setting up users to be unique enables you to effectively monitor user activities and helps you identify the source of a security breach if there is one. By disallowing users to use a generic or shared user account, each user is held accountable for his specific actions. In addition, unique users can be allowed to view or not view certain information that is protected by row-level security constraints. For more information, see Security
Administration.
•
Consider the function of the user. Create administrative users under separate users/ databases so that privileges can be granted from the owning user/database. For example,
Database Administration 107
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Creating User Accounts the HR database and Marketing database can have separate administrative users to manage privileges for their respective users.
•
For non-administrative users, if possible, assign the user to a role with the required privileges rather than granting privileges to the user directly. It is easier to use roles to manage privileges. Profiles should also be created for non-administrative users (see
“Creating User Profiles” on page 110 ).
•
Limit the permanent and spool space of users and grant additional space if it becomes necessary. Limit spool space using a profile allows you to protect the system from runaway queries.
Creating User Accounts
Each user logon to the database should specify a user account string.
Accounts are used by the database to:
•
Assign priority to individual sessions to manage the workload
•
Monitor resource usage
•
Charge for space or resources used
Teradata recommends that you specify at least one user account for each user. Users with similar responsibilities and resource requirements should be assigned to the same account(s) to reduce the overall number of accounts you must maintain.
You can specify accounts in:
•
A CREATE PROFILE or MODIFY PROFILE statement for the profile specified in the user definition (preferred).
•
A CREATE USER or MODIFY USER statement.
Note: If a user is a member of a profile that specifies one or more accounts, the profile account assignments supersede and invalidate any accounts specified in the user definition.
Reference Information
Information on...
specifying the account string at logon
Is available in...
•
Security Administration
•
The logon section in the User Guide for each Teradata tool or utility.
Creating Account Strings
Teradata recommends that you devise an account system and then identify the accounts required for various groups in the user community before attempting to specify account information in user profiles. An account string is limited to 128 characters.
108 Database Administration
Database Administration
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Creating User Accounts
User account strings should follow this format:
‘$G0+account_ID&S&D&H’
Note: If a CREATE or MODIFY statement specifies more than one account string, the individual strings must be separated by commas and the entire list of strings enclosed by parentheses.
where:
Element
Required Account String Variables
Description
$G0+
account_ID
Optional. The performance group identifier. Priority scheduler uses the identifier to determine the priority of the session.
Recommendation: Specify one of the following instead of $G0+:
•
$R0+ = Rush
•
$H0+ = High
•
$M0+ = Medium (default)
•
$L0+ = Low
Note: Consider the following when specifying the performance group.
•
The 0 specification designates resource partition 0, the default.
•
The + character is a place holder that forces the account_ID to start at the fifth character, which is important for compatibility with certain administrative tools.
The account name. Uniquely identifies the account.
Recommendation: You can use the four characters of the
account_ID to differentiate accounts and to provide an abbreviated description of the account function.
For example:
•
A department, such as finance (FIN) or marketing (MKT)
•
A job function, such as general use (G), update (U), or batch processing (B).
A complete account ID might resemble one of the following:
FINB or MKTU
Note: Although more characters are allowed, using a fourcharacter account_ID maintains application compatibility.
Account String Expansion (ASE) Variables
Teradata Database tags the session with information specified by the ASE variables for later use in management of database sessions. Each ASE variable expands to the number of characters needed to express the related information. The string limit is enforced against the expanded form.
Specification of the ASE variables shown below is optional, but recommended. Other variables are available. For information, see
“Logging Resource Usage Data with Account String Variables” on page 162 .
109
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Creating User Profiles
Element
&S
&D
&H
Description
The ampersand (&) designates an account string expansion
(ASE) variable. Teradata Database automatically replaces these variables with actual values upon opening the session. You can use any or all of the following:
•
&S = the session number
•
&D = the date
•
&H = the time
Determining the Account for a User Session
The system determines the account for a user when the user logs on as follows:
•
If the user is assigned only one account, the logon uses that account by default.
•
If the user is assigned multiple accounts and the default account (the first listed in the operant user or profile definition) is appropriate for the session, the logon need not contain the account string.
•
If the user has multiple accounts and does not want to use the default, the logon string can specify another assigned account.
•
During a session, the user can submit a SET SESSION ACCOUNT statement to change the session to another assigned account.
•
If the user has no account assignment, the session defaults to the first account listed for the owning user or database. Such a use of default owner accounts is not recommended.
Creating User Profiles
About Profiles
You can create profiles to define resource parameters for groups of users with similar needs instead of defining them for each individual user. Then list the profile in a CREATE or
MODIFY USER statement to establish membership in a profile for each user.
Profiles can be based on the primary user types such as those shown in “Types of Users” on page 106
, or other factors that group users according to database resource requirements.
Use profiles to specify parameters such as:
•
Permanent and spool space allocations
•
User account(s)
•
Password control parameters
•
Default database assignment
•
Query band
Note: The value for a profile attribute supersedes and replaces any corresponding values specified in global defaults, or in a CREATE USER request.
110 Database Administration
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Creating User Profiles
Creating Profiles
1
Open your favorite client software to construct your SQL request. For example:
2
CREATE PROFILE profile_name AS
ACCOUNT = (‘account_str1’,’account_str2’)
DEFAULT DATABASE = database_name,
SPOOL = spool_space,
PASSWORD =
(EXPIRE = n_days,
MAXLOGONATTEMPTS = attempts,
LOCKEDUSEREXPIRE = n_minutes),
QUERY_BAND = 'Pair_name=pair_value;' [NOT] DEFAULT';
Include the parameters:
Parameter
Name
Description
The unique name for the profile. Include such things as the user type or user department to identify its function. For example, GenUser_Profile or
Finance_Profile. Consolidate user requirements where possible to avoid the unnecessary proliferation of profiles.
Account The database uses accounts for user job tracking and to prioritize requests.
Recommendation: Enter one or more account strings in accordance with
the format shown in “Creating User Accounts” on page 108
.
If you assign more than one account string to a profile, enclose each string in apostrophes, separate the strings with commas and enclose the complete specification in parentheses, for example:
(‘$M0+accl&S&D&H’,‘$L0+accr&S&D&H’, ‘$R0+acc51’)
Note: The content of an account string is limited to 128 characters.
Default Database Optional. The database the user is most likely to access.
If no name is specified, the system uses the name specified in the user definition (CREATE USER statement).
Recommendation: Specify the default database at the user level, rather than in the profile, to allow for differences in user default database requirements.
Database Administration 111
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Creating User Profiles
Parameter
Spool Space
Description
This value limits the amount of space available for intermediate query results or formatted answer sets to queries and volatile tables. Spool space for a user is shared among the queries that user is executing concurrently.
The system borrows spool space for a user from unused permanent space in the system.
Recommendation: Spool space requirements in a profile depend on the activities of member users. Begin by specifying spool space in bytes according to the following percentages of the total perm space allocation for the Spool_Reserve database.
•
General users: 5%
•
Update users: 10%
•
Batch users: 10%
•
Assistant administrative users: 10%
•
Database programmers: 10%
Periodically monitor usage patterns and modify spool space assignments when required using the MODIFY PROFILE statement.
Spool space can also be specified as part of a CREATE USER statement or modified as part of a MODIFY USER statement.
Note: Profile members that do not require permanent space must still be allocated a small amount of spool space in the profile, for example, 1 MB.
Temporary Space This is required only when using global temporary tables.
Recommendation: Initially omit a temporary space specification unless you have a predetermined temporary space requirement for this group of users. If necessary, you can add a temporary space specification later with a
MODIFY PROFILE statement.
Password Optional. The password control parameters allow you to apply different settings in the profile than are in the global default settings created in
DBC.SysSecDefaults, as part of step 2 in “Setting Up the Database
Administrator User” on page 30
Recommendation: Do not reset any password control parameter values in a profile unless the profile members cannot use the system defaults.
Cost Profile
Constraint
Query Band
Optional. The Optimizer cost profile name to be associated with the profile.
Optional. Name of one or more row-level security constraints, each followed by a list of the hierarchical levels or non-hierarchical categories, valid for the constraint, which are being assigned to the profile_name.
Optional. Creates a query band that is automatically set for the session at
logon. For more details, see “About Defining Name-Value Pairs for Profile
3
Specify profile membership as follows:
•
Assign a profile to each user as part of “Working with Database Users.”
or
•
After creating users, use a MODIFY PROFILE statement to include member users.
112 Database Administration
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Working with Database Users
4
Close the client software or go on to
.
Reference Information
Information on...
syntax and options for the
CREATE PROFILE statement using accounts to enforce session priorities information on monitoring and reallocating space global temporary tables password control options
Is available in...
SQL Data Definition Language Syntax and
Examples
•
“Managing the Database Workload with
Teradata Active System Management” on page 228
“Chapter 9 Managing Space: Operational DBAs” on page 171
Database Design
Security Administration
Dropping Profiles
DROP statements are recorded in the Data Dictionary. However, the result of a DROP
PROFILE, DROP DATABASE, or DROP ROLE statement is not cascaded to the user rows in
DBC.Dbase, so the corresponding default setting for each affected user is not reset to NULL.
When an affected user next logs on, the system does not return an error or warning.
If you drop a default profile, the system uses the following by default:
•
ACCOUNT, SPOOL, TEMP, and DEFAULT DATABASE specifications in the CREATE
USER or latest MODIFY USER statement
•
Password attributes defined at the system level in DBC.SecurityDefaultsV (see Security
Administration)
Note: If you re-create a profile with the same name after it was dropped, users defined for that profilename are assigned the profile parameters at the next logon. The effect of a profile recreation is not immediate.
Working with Database Users
About Users
This task creates individual database users, including lower level administrators, database programmers and other privileged users, and database end-users.
Creating Users
1
Start Teradata Administrator and log on as user DBADMIN.
Note: This procedure creates users individually. To automate the creation of users by using
BTEQ scripts, see “Using BTEQ Scripts to Create Database Objects” on page 88 .
Database Administration 113
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Working with Database Users
2
3
From the main screen, click the Preview Mode button generated SQL.
Do the following to create a user:
a
Click Tools>Create>User.
b
to allow future display of
In the Create User dialog, specify the values for the required fields and controls.
Field or Control
User Name
Owner
Password
Permanent Space
Spool Space
Explanation
Required. The name of an individual Teradata Database user.
Each database user should be uniquely identified for accurate logging. Do not allow users to share a username for accessing the database.
Note: The username must conform to the rules for SQL object names.
Required. The name of the database or user that owns the space in which the user is created.
Recommendation: DBADMIN. All users should be created in space owned by the database administrator.
Required. A temporary password. The user is prompted to change the temporary password to a permanent, private password at first logon.
May be required. Space in bytes that can be used to contain objects the user creates or owns. Permanent space is required for those users that create and store space-consuming objects.
Recommendation: Base the permanent space specification on user needs.
•
General users: Not required.
•
Update users: Required if users create and store objects.
•
Batch users: Required if users create and store objects.
•
Assistant administrators: Required if users create and store objects.
•
Database programmers: Required to create and store objects.
Optional. Specifies the limit to the amount of space in bytes available for temporary process constructs such as intermediate query results or formatted answer sets to queries and volatile tables. Spool space for a user is shared among the queries that user is executing concurrently.
The system borrows user spool space from any unused permanent space found on the system.
The spool space specification in a profile takes precedence over spool space specified in a CREATE USER statement.
Recommendation: Specify spool space as part of a profile unless the user requires special spool considerations.
If you do enter a value for an individual user, specify approximately 20% of the perm space available to the largest database the user will query.
114 Database Administration
Database Administration
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Working with Database Users
Field or Control
Temporary Space
Account
Default Database
Profile Name
Explanation
Not applicable. Required only when using global temporary tables.
Specifying temporary space requires that you develop a strategy for use of the advanced features that need such space. If necessary, you can add a temporary space specification later with a MODIFY USER or MODIFY
PROFILE statement.
Optional. You can set up user account information to form the basis of various user management options.
Recommendation: Do not specify accounts at the user level, unless the user requires unique system priorities. Instead name a profile in the
Profile parameter that contains the needed account(s). For information,
see “Creating User Profiles” on page 110
.
Note:
If a user is a member of a profile that specifies one or more accounts, the profile account assignment supersedes and invalidates all account assignments specified in the user definition.
Optional. Identifies the database that owns the space in which the
Teradata Database stores or searches for new or target objects in an SQL query, unless a different database is specified in the query.
Note: Users can use the DATABASE statement to establish a new default database for the current session.
Recommendation: Specify the database most often accessed by the user.
•
General users: Specify a read-only Views database. If restrictions are necessary, use role privileges to allow access to particular views.
•
Update users: Specify either a read-only Views or an updatable Views database, depending on where the user normally works.
•
Batch users: Specify the Tables_Database, where batch operations take place.
•
Assistant administrators: Specify DBADMIN.
•
Database programmers: Specify the name of the development database.
Optional. Gives the user membership in the named profile.
For syntax elements that appear in both the CREATE USER statement for a user, and in a profile in which the user is a member, the profile values take precedence.
A user can be a member of only one profile.
Recommendation: Specify profile membership for all users. Select from the drop-down list and highlight the needed profile.
115
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Working with Database Users
116
Field or Control
Default Role
Explanation
Identifies the default role used for determining user privileges in the database for the current session. This is usually the role associated with the activities performed most frequently by the user.
Note: The user can employ the SET ROLE statement at the beginning of a session or transaction to change from the default role to another role. The
SET ROLE ALL statement allows access to all roles of which the user is a member.
Recommendation: You may specify a default role later after you have created the user and the roles. See
member of only one role.
Optional.
Recommendation: Do not use for initial database implementation.
Default Journal
Startup String
Before Journal
After Journal
FALLBACK
Collation
Time Zone
Default Date Form
Default Character
Set
Optional. Specification of FALLBACK automatically creates a duplicate of each table stored in the user space, in addition to the duplicates already created by disk mirroring. The system reverts to the FALLBACK tables in the event of a failure.
Recommendation: Specify FALLBACK only for individual missioncritical tables or tables so large that their size prevents timely backup to tape or external disk.
Optional. Database default values that apply to all users are already set as part of system installation and configuration.
Recommendation: Do not change the default values for a user unless the default value is not applicable.
Note: All users must use the same collation value.
c
Click the Create button. The Query Window displays the generated CREATE USER statement, similar to the following:
CREATE USER "GenUser1" FROM "DBADMIN"
AS PERM = 0
PASSWORD = "temp123"
STARTUP = ''
DEFAULT DATABASE = "Personnel_Views"
NO FALLBACK
NO BEFORE JOURNAL
NO AFTER JOURNAL
PROFILE=”GenUser_Profile”
d e
In the Query Window, click the Run Query button . A Query Complete message appears in the bottom left corner of the main window when the query executes.
Close the Query Window and the Create User dialog box.
Database Administration
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Creating Temporary Passwords for First Login
4
Log off Teradata Administrator or go on to “Using Roles to Manage User Privileges” on page 117 .
Reference Information
For Step...
Information on...
3 syntax and options for the CREATE
USER statement the creation and use of accounts
Is available in...
SQL Data Definition Language Syntax and
Examples
“Creating User Accounts” on page 108
Creating Temporary Passwords for First Login
Teradata Database requires you to associate a username with a password when you first create a user. You must specify a password, even if temporary. Otherwise the Parser rejects the statement as incomplete.
The security administrator can prompt users for a new password upon first login if:
•
At the time of installing a new system, the administrator has created generic passwords for all users and wants them to choose their own passwords.
•
New password requirements must be enforced. For example, if the security administrator wants to require mixed case and wants all users to change their passwords.
If you are using Teradata Administrator, simply check the “Temporary” box next to the password. This adds the 'FOR USER' phrase to the generated command.
Note: Teradata password rules do not apply to external authentication. For more information, see Security Administration.
To use SQL, see “Passwords” under “CREATE USER” in SQL Data Definition Language.
Using Roles to Manage User Privileges
Do the following to setup roles to manage user privileges:
1
Create roles, as shown in
2
Grant privileges to each role, as shown in “Granting Privileges to a Role.”
3
Grant role membership to users, as shown in
“Granting User Membership in a Role.”
Note: Some privileges cannot be granted to a role. You must grant those privileges directly to
a user. For information, see “Granting Privileges Directly to Users” on page 125 .
Database Administration 117
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Using Roles to Manage User Privileges
User Types and Minimum Required Privileges
The following table describes the minimal privileges required by the three basic user types.
User Type
General
Update
Privilege Requirements
Database end-users who typically read data and execute macros in a read-only
Views database.
Assign the following privileges on a read-only Views database to all General users:
•
EXECUTE
•
SELECT
The read-only Views database must have privileges on the Tables_Database, as
shown in “Working with Table Access Privileges for Views” on page 129 .
Privileged database users who update data generally require the following privileges:
Privileges required on a read-only Views database:
•
EXECUTE
•
SELECT
•
CREATE VIEW and DROP VIEW
•
CREATE MACRO and DROP MACRO
Privileges required on an updatable Views database:
•
EXECUTE
•
SELECT
•
INSERT, UPDATE, and DELETE
•
EXECUTE PROCEDURE
•
EXECUTE FUNCTION
•
CREATE VIEW and DROP VIEW
•
CREATE MACRO and DROP MACRO
Additional recommended privileges on an updatable Views database for database programmers:
•
SHOW
•
ALTER, CREATE, and DROP PROCEDURE
•
ALTER, CREATE, and DROP FUNCTION
•
ALTER and CREATE EXTERNAL PROCEDURE
•
CREATE TRIGGER and DROP TRIGGER
To provide update capability on views, you must grant the updatable Views database SELECT, INSERT, UPDATE, DELETE WITH GRANT OPTION privileges on the referenced tables in the Tables_Database, as shown in
“Working with Table Access Privileges for Views” on page 129
.
118 Database Administration
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Using Roles to Manage User Privileges
User Type
Batch
Assistant
Administrators
Database
Programmers
Privilege Requirements
Data movers, who typically perform batch-level functions, such as:
•
Batch data load, update, and export operations.
•
Data backup, archive, and restore operations, including creating and deleting staging tables.
Batch users must have the following privileges on the Tables_Database:
•
SELECT
•
INSERT, UPDATE, DELETE
•
DUMP and RESTORE
•
CHECKPOINT
•
CREATE TABLE and DROP TABLE
If you need one or more assistant administrators to help share administrative duties, they may require the same privileges as those granted to DBADMIN, or a subset of those privileges. Use the procedure shown in
Administrator User” on page 30
to create assistant administrators and grant the privileges they need.
Database programmers may require administrator-level privileges within the development database to allow them to create and test database objects.
Administrators can then deploy the objects to the production database.
Types of Privileges
You can explicitly grant database privileges to users, roles, or databases. Users also gain other privileges without a formal grant. Before you decide which privileges to explicitly grant, make sure you understand the privileges users receive by other means.
Privilege
Implicit Privileges
Ownership
Description
Users that own perm space have certain implicit (ownership) privileges on any object contained in the space they own, even if they did not create the object.
Note: You can transfer ownership using the GIVE statement.
Explicit privileges
Automatic
GRANT
When a user creates a database object, Teradata Database automatically grants privileges to:
•
The creator of the object
•
A newly created user or database
You can grant privileges:
•
Directly to a user or database
•
To a role, then GRANT membership in the role to one or more users
•
To an external role, then map the external role to one or more groups of directory users
Database Administration 119
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Using Roles to Manage User Privileges
Privilege
Inherited
Description
Privileges that a user acquires indirectly.
•
All users inherit the privileges of the system-generated user, PUBLIC, a role-like collection of privileges available by default, whether or not they have any other privileges. You can grant additional privileges to PUBLIC.
•
A user inherits all the privileges granted to each role of which the user is a member.
•
Directory users inherit the privileges of the database users and external roles to which they are mapped.
Note: The system logs automatic and explicit privileges in exactly the same way, and are indistinguishable as to how they were acquired. All privileges except implicit privileges are stored in the data dictionary in the DBC.AccessRights table, by each user.
For a detailed discussion of privileges, see “Teradata Database User Privileges” in Chapter 5:
“Creating Users and Granting Privileges” in Security Administration.
Privileges That Must Be Explicitly Granted
Some privileges cannot be acquired by indirect means and must be explicitly granted to a user, database, or role. For information, see “Privileges that Must Be Explicitly Granted” in Security
Administration.
Creating User Roles
1
Start Teradata Administrator and log on as user DBADMIN.
2
3
4
5
On the main screen, click the Preview Mode button generated SQL.
Click Tools>Create>Role.
to allow future display of
In the Roles dialog, use the Role Name field to specify a unique role name. The role name should also provide some indication of the role function or the group of users to which it applies, for instance:
•
FinanceUser_Role
•
Update_Role
Click the Create button. The Query Window displays the generated CREATE ROLE statement:
CREATE ROLE role_name
6
7
8
In the Query Window, click the Run Query button. A Query Complete message appears in the bottom left corner of the main window when the query executes.
Close the Query Window and the Roles dialog box.
Repeat this procedure to create the needed roles.
120 Database Administration
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Using Roles to Manage User Privileges
9
Log off Teradata Administrator or go on to “Granting Privileges to a Role.” .
Granting Privileges to a Role
Use the GRANT statement to grant privileges to the roles necessary to serve the basic user types. A GRANT statement takes the following basic form:
GRANT privilege
ON database_object_name
TO role_name
1
Start Teradata Administrator and log on as user DBADMIN.
2
3
From the main screen, click the Preview Mode button generated SQL.
Grant privileges to each role as follows:
a
Click Tools>Grant/Revoke>Object Rights.
b
to allow future display of
In the Grant/Revoke Objects dialog, specify values for the following:
Fields and Controls Explanation
Database Name Required.
•
To grant privileges on an entire database, specify the name of the database.
•
To grant privileges on an object, specify the parent database that contains the object.
Recommendation: When specifying privileges for:
•
General users, select a read-only Views database.
•
Update users, select a read-only Views database or an updatable Views database.
•
Batch users, select the Tables_Database.
•
Administrative users, select DBADMIN.
•
Database programmers, select a Development database.
Object Type Required.
Specify the type of database object on which privileges are being granted.
For example:
•
To grant privileges on the Tables_Database, specify Database.
•
To grant privileges on the tables located in the Tables_Database, specify Table.
Recommendation: Always grant privileges at the highest level that is appropriate, while observing security concerns and user “need to know.”
Database Administration 121
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Using Roles to Manage User Privileges
122
Fields and Controls Explanation
Objects Required when objects are displayed.
If the Object Type is Database, this field is blank and not required.
Otherwise, the Objects field displays all of the database objects of the object type contained in the named database.
For example, if Database Name is Tables_Database and Object Type is
Table, this field displays all of the tables contained in the
Tables_Database.
Select the specific database object on which privileges are being granted.
To/From User
Role
Not applicable for granting privileges to roles.
Required. The role to which the specified privileges are granted.
Select the name of a previously created role from the displayed list.
Public
Normal
Create
Drop
All
Optional.
Checking the Public box grants the specified privileges to PUBLIC, a group of rights accessible by any user with logon privileges, even if no other privileges have been granted.
Recommendation: Do not grant additional privileges to PUBLIC at this time.
Required. Specify the privileges by checking the boxes, based on the guidelines in
“User Types and Minimum Required Privileges” on page 118 .
Recommendation: Consider the privileges that the user may get without
formal granting, as shown in “Types of Privileges” on page 119
, before deciding on what privileges to grant.
Optional. Do not use for roles.
Grants all privileges that apply on the database object. This box is usually used only for the master administrator, DBADMIN.
Dictionary
Access
All But
Optional. Grants administrative privileges on data dictionary tables.
Optional.
Provides basic SELECT and EXECUTE privileges on the specified object.
Optional.
When the All But box is checked, role members receive all privileges except those checked in the Normal, Create, and Drop sections.
c
Not all privileges need to be granted using roles. It may be more efficient to grant some specialized privileges directly to a user, rather than creating a role with a membership of one.
Note: Any user can grant privileges on any database object it owns to any other user or role, excluding the CREATE and DROP privileges, which are not ownership privileges.
Click the Grant button. The Query Window displays the generated GRANT statement, for example:
Database Administration
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Using Roles to Manage User Privileges
GRANT EXECUTE, SELECT, INSERT, UPDATE, DELETE, DUMP, RESTORE,
CHECKPOINT, CREATE TABLE, DROP TABLE ON "Tables_Database" TO
"Role_BatchUser_2"
4
5 d
In the Query Window, click the Run Query button . A Query Complete message appears in the bottom left corner of the main window when the query executes.
e
Close the Query Window and the Grant/Revoke Objects dialog box.
Repeat this procedure to grant privileges to all roles.
Close Teradata Administrator or go to
“Granting User Membership in a Role.”
Reference Information
For Step...
Information on...
3 syntax and options for the GRANT
(SQL Form) statement using roles to manage user access
Is available in...
SQL Data Control Language
Security Administration
Granting User Membership in a Role
After creating database users, grant them membership in one or more roles to provide the required database access privileges.
1
Start Teradata Administrator and log on as user DBADMIN.
2
5
6
3
4
7
On the main screen, click the Preview Mode button generated SQL.
to allow future display of
Click Tools>Create>Role.
In the Roles dialog, select a role from the Role Name drop-down menu.
Click the Users tab.
Select all users that will be members of the selected role, and click Add.
The Query Window will display a GRANT statement similar to:
Grant "Role_1" To "GenUser1";
8
In the Query Window, click the Run Query button . A Query Complete message appears in the bottom left corner of the main window when the query executes.
9
10
11
Close the Query Window and the Roles dialog box.
Repeat this procedure for each role to which a user requires membership.
Log off Teradata Administrator or go to “Defining the Default Role for a User.”
Database Administration 123
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Using Roles to Manage User Privileges
Reference Information
For Step...
Information on...
1 syntax and options for the
CREATE ROLE statement
2 using roles to manage user access syntax and options for the GRANT
(SQL form) statement
3 database privileges, including those conferred by object ownership syntax and options for GRANT
(Role form)
Is available in...
SQL Data Definition Language Syntax and
Examples
Security Administration
SQL Data Control Language
Defining the Default Role for a User
To ensure that role privileges are available to users at log on, you must define a default role for each user that is a member of one or more roles. If you do not specify a default role, the user must employ the SET ROLE statement to select the operant role. For example:
SET ROLE role_name; or
SET ROLE ALL;
You can also use the SET ROLE statement to change from one role to another role within a session.
To ensure that the user is operating with the appropriate role, specify the default role for a user as follows:
1
Start Teradata Administrator and log on as user DBADMIN.
2
5
6
3
4
7
On the main screen, click the Preview Mode button generated SQL.
Click the + next to DBADMIN to display the list of users.
Select the user you want to modify.
to allow future display of
Click Tools>Modify User.
In the Modify User dialog, click the Default Role drop-down menu and select a default role.
You can optionally select All Roles, which will allow access to all roles of which the user is a member.
Click the Modify button. The Query Window displays the generated MODIFY USER statement, for example:
MODIFY USER "GenUser1" AS
STARTUP = ''
124 Database Administration
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Granting Privileges Directly to Users
DEFAULT DATABASE = "Personnel_Views"
NO FALLBACK
NO BEFORE JOURNAL
NO AFTER JOURNAL
COLLATION = HOST
DEFAULT CHARACTER SET LATIN
DATEFORM=INTEGERDATE
TIME ZONE=NULL
DEFAULT ROLE="Role_GenUser_2"
8
In the Query Window, click the Run Query button . A Query Complete message appears in the bottom left corner of the main window when the query executes.
9
10
11
Close the Query Window and the Modify User dialog box.
Repeat this procedure to specify the default role for each user who is a member of a role.
Log off Teradata Administrator or go on to “Granting Privileges Directly to Users.”
Reference Information
For Step...
Information on...
1 syntax and options for the SET ROLE statement
7 syntax and options for the MODIFY
USER statement, including the default role using roles to manage user access
Is available in...
SQL Data Definition Language Syntax and
Examples
SQL Data Definition Language Syntax and
Examples
Security Administration
Granting Privileges Directly to Users
Some privileges cannot or should not be granted to roles, but should instead be granted directly to users.
•
System-level privileges that cannot be granted to a role, as shown in
Privileges to User DBADMIN” on page 35 .
Note: System-level privileges are normally used by administrators and should not be granted to other users.
•
Object-level privileges that apply to too few users to require creation of a role.
Note: A user automatically has the privilege to grant most privileges on any database object the user owns to any other user or role. This excludes CREATE and DROP privileges, which are not automatic ownership privileges. The CREATE and DROP privileges must be granted directly to a user, and must include the WITH GRANT OPTION clause, before that user can grant these privileges to others. For information on ownership privileges, see Security
Administration.
Database Administration 125
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Granting Privileges Directly to Users
Prerequisites
You can only grant privileges to users that already exist in the database. For information on creating users, see
“Working with Database Users” on page 113 .
The Sys_Calendar database and Calendar view must exist. They are normally created as part of system installation by running the DIPALL script.
Example: Granting Privileges on Sys_Calendar to All Users
Sys_Calendar is a system database used to contain the Sys_Calendar.CalDates table and
Sys_Calendar.Calendar view. The Calendar view is a user-accessible tool for date arithmetic. It permits easy specification of arithmetic expressions and aggregation, and is particularly useful when requesting values aggregated by weeks, months, year-to-date, years, and so on. You can use the Calendar view to get attributes for any date between the years 1900 and 2100, such as which day of the week or which week of the month a date occurs.
1
2
Use the following procedure to grant SELECT privilege on Sys_Calendar to all Teradata
Database users.
Start Teradata SQL Assistant and log on as DBADMIN.
Enter the following statement in the main query window:
GRANT SELECT ON Sys_Calendar TO PUBLIC
3
4
Click the Execute button
Close Teradata SQL Assistant.
to run the query.
Reference Information
For Step...
Information on...
All Sys_Calendar and the Calendar view
Is available in...
Data Dictionary
Granting Privileges to a User
1
Start Teradata Administrator and log on as DBADMIN.
2
3
4
From the main screen, click the Preview Mode button generated SQL.
Click Tools>Grant/Revoke>Object Rights.
In the Grant/Revoke Objects dialog, specify the following:
to allow future display of
•
Use the Database Name, Object Type, and Objects fields to identify the database object which the user will receive privileges on.
•
In the To/From User tab, select the user who will receive the specified privileges.
•
In the Normal, Create, or Drop sections, check the privileges the user will receive.
126 Database Administration
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Granting Privileges Directly to Users
5
For details, see “Granting Database Privileges to User DBADMIN” on page 35
.
Click the Grant button. The Query Window displays the generated GRANT statement similar to:
GRANT privilege
ON database_object_name
TO username; where
•
The ON clause is based on the values of the Database Name, Object Type, and Objects fields.
•
The TO clause is based on the user selected from the To/From User tab.
6
7
8
In the Query Window, click the Run Query button . A Query Complete message appears in the bottom left corner of the main window when the query executes.
Close the Query Window and the Grant/Revoke Objects dialog box.
Log off Teradata Administrator.
Automatic Privileges for Creators
When you create a user or database, the system automatically grants you privileges on the created database or user:
•
ANY
•
CHECKPOINT
•
CREATE AUTHORIZATION
•
CREATE DATABASE
•
CREATE MACRO
•
CREATE TABLE
•
CREATE TRIGGER
•
CREATE USER
•
CREATE VIEW
•
DELETE
•
DROP AUTHORIZATION
•
DROP DATABASE
•
DROP FUNCTION
•
DROP MACRO
•
DROP PROCEDURE
•
DROP TABLE
•
DROP TRIGGER
•
DROP USER
•
DROP VIEW
•
DUMP
Database Administration 127
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Granting Privileges Directly to Users
•
EXECUTE
•
INSERT
•
SELECT
•
STATISTICS (also for creators of tables)
•
RESTORE
•
UPDATE
Automatic Privileges for Created Users and Databases
When you create a user or database, it automatically gets the following privileges on itself:
•
ANY
•
CHECKPOINT
•
CREATE AUTHORIZATION
•
CREATE MACRO
•
CREATE TABLE
•
CREATE TRIGGER
•
CREATE VIEW
•
DELETE
•
DROP AUTHORIZATION
•
DROP FUNCTION
•
DROP MACRO
•
DROP PROCEDURE
•
DROP TABLE
•
DROP TRIGGER
•
DROP VIEW
•
DUMP
•
EXECUTE
•
INSERT
•
SELECT
•
STATISTICS
•
RESTORE
•
UPDATE
Note: These same privileges are automatically given to creators, with the exception of
CREATE USER, CREATE DATABASE, DROP USER, and DROP DATABASE.
128 Database Administration
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Granting Privileges Directly to Users
Reference Information
For Step...
Information on...
5 syntax and options for the GRANT
(SQL form) statement database privileges, including those conferred by object ownership
Is available in...
SQL Data Control Language
Security Administration
Working with Table Access Privileges for Views
You must grant table access privileges to all views databases to allow the views within each database to access tables in the Tables database.
Note: When table access privileges are granted to a Views database, the individual views inherit the right to access tables in the Tables database from the parent Views database.
Granting Table Access to Each Views Database
1
Start Teradata Administrator and log on as user DBADMIN.
2
3
4 f
On the main screen, click the Preview Mode button
SQL.
Click Tools>Grant/Revoke>Object Rights.
In the Grant/Revoke Objects dialog:
a
to allow display of generated
From the Database Name drop-down menu, select the Tables database. This is the object the privileges are granted on.
b
From the Object Type drop-down menu, select Database.
c
Click the To/From User tab and select a Views database. The privileges are granted to this object.
d
In the Normal field, check the following to select the privileges being granted:
•
For read-only views: Check Select.
•
For updatable views: Check Select, Insert, Update, and Delete.
e
Check the Grant box in the lower right-hand corner of the screen to give the database the privilege of extending the defined privileges to other databases. This specifies the
WITH GRANT OPTION clause.
Click the Grant button. The Query Window displays the generated GRANT statement, for example:
•
For read-only Views databases:
GRANT SELECT ON "Tables_Database" TO "database_name" WITH GRANT
OPTION
•
For the updatable Views databases:
Database Administration 129
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
About Viewpoint Monitoring Privileges
GRANT SELECT, INSERT, UPDATE, DELETE ON "Tables_Database" TO
"database_name" WITH GRANT OPTION
5 g
In the Query Window, click the Run Query button . A Query Complete message appears in the bottom left corner of the main window when the query executes.
h
Close the Query Window and the Grant/Revoke Objects dialog box.
Log off Teradata Administrator.
Reference Information
For Step...
Information on...
4 syntax and options for the GRANT
(SQL form) statement database privileges, including those conferred by object ownership
Is available in...
SQL Data Control Language
Security Administration
About Viewpoint Monitoring Privileges
All database users can benefit from using Teradata Viewpoint to monitor the database, but not all users need all Teradata Viewpoint capabilities.
You can use the examples in the following table to help determine the database monitoring functions needed by various user types, and in creating and assigning privileges to Teradata
Viewpoint roles.
Role Privileges
Default Teradata Viewpoint roles
Administrator Assign this role only to the Teradata Viewpoint administrator(s).
Has all privileges (default). This role can access the functions in the Admin tool menu to configure Teradata Viewpoint alerts, users, roles, and systems.
User
TD_SE (Teradata
Solution Engineer)
TD_TSS (Teradata
Technical Support
Specialist)
Includes minimal privileges
This role is intended for the Teradata Solution Engineer when they need access to system health and metrics. You can enable or disable this role, but do not reconfigure it.
This role is intended for Teradata Technical Support Specialists when they need access to your system SQL. You enable or disable this role, but do not reconfigure it.
Example custom roles
Note: Roles are based on the user types/duties shown in
.
130 Database Administration
Database Administration
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
About Viewpoint Monitoring Privileges
Role
Database
Administrator
Database
Programmer/
Power User
Batch User
Update User
Privileges
Database administrators may require all Teradata Viewpoint monitoring functions to perform administrative duties in the database.
Suggested role privileges: Create a Database Administrator role that has privileges to use all portlets and portlet functions, except System
Administration, which should only be accessible to the Teradata Viewpoint administrator(s).
Note: You may find it useful to create an additional role that limits access to some portlets and functions for lower level administrators.
Database programmers perform functions similar to administrators, creating database objects, running ad hoc queries, and monitoring performance.
Suggested role privileges: Similar to Database Administrator, but without analytical functions.
Note: Programmer privileges in the database are often restricted to a development database, but Teradata Viewpoint monitors all databases within the system.
Batch users run load and export utilities, or who perform backup, archive and restore operations.
Suggested role privileges include:
•
For job planning:
•
Capacity Heat Map
•
Space Usage
•
Calendar
•
During job execution and troubleshooting:
•
System Health
•
My Queries or Query Monitor
•
Workload Monitor
•
SQL Scratch Pad
•
Console Utilities
•
Privilege to set preferences and share portlets
Users who perform miscellaneous insert/update/delete operations.
Suggested role privileges:
•
Calendar (no create or edit privileges)
•
System Health (View Summary only)
•
My Queries
•
Workload Monitor
•
SQL Scratchpad
131
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Setting Up Teradata Viewpoint Users
Role
General User
Privileges
Low level users that run macros and stored procedures to access data, which select data and generate reports.
Suggested role privileges:
•
Calendar (no create or edit privileges)
•
System Health (View Summary only)
•
My Queries
Setting Up Teradata Viewpoint Users
For users that are not already set up to access Teradata Viewpoint, as part of initial system installation, you must perform Teradata Viewpoint set up operations.
1
2
3
4
Log on as the Teradata Viewpoint administrator and select Admin, which includes a drop down list of administrative functions.
Use the Roles Manager to create Teradata Viewpoint roles and define sets of user privileges for each role.
When creating roles:
•
Define the portlets available to the role
•
Define whether user members can set their own preferences and share portlets.
•
Give or remove user permissions for portlet tools and functions.
Teradata Viewpoint provides two default roles, but you may find it useful to configure custom roles, based on the suggestions in
“About Viewpoint Monitoring Privileges” on page 130 .
Use the Users Manager to create Teradata Viewpoint users and assign membership in one or more roles according to user job function. Include an email address for each user, so that Teradata Viewpoint can send them alert emails, if necessary.
Instruct users to setup their Teradata Viewpoint profile by specifying their username, password, and account, so the system can verify that each user exists in the specified database system and that the account is valid for the user. Profile information is used by some portlets, for example:
•
My Queries portlet, to track query activity for the user
•
SQL Scratchpad portlet, to determine database access privileges for the user
Reference Information
Information on...
the duties typically performed by the user types for which customer roles are recommended
Is available in...
132 Database Administration
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Setting Up Teradata Viewpoint Users
Information on...
Is available in...
creating Teradata Viewpoint users, roles, and profiles
•
Viewpoint application Help screens
•
Teradata Viewpoint User Guide
Configuring User Dashboards
You can create custom dashboard pages, and then use the Add Content function to populate each page with a set of related portlets from among those available to the user.
The primary dashboard should contain the most important portlets for live monitoring of database activity, for example:
•
System Health (all)
•
My Queries (users) or Query Monitor (administrators and programmers)
•
1 or 2 other optional portlets, depending on the type of user
You can create additional dashboards to contain other portlets.
Note: You may need to limit the number of portlets per dashboard page. Displaying too many
Teradata Viewpoint portlets on one dashboard may make it hard to find needed data, and for some browsers, may slow portlet loading and response times.
For details about configuring dashboards and portlets, see Teradata Viewpoint User Guide.
Creating a Dashboard
From the Teradata Viewpoint portal:
1
2
Use the Add Page option to name the dashboard, for example, MainDashboard.
Use the Add Content function to select portlets to include in the dashboard.
Database Administration 133
Chapter 6: Working with Users, Roles, and Profiles: Operational DBAs
Setting Up Teradata Viewpoint Users
134 Database Administration
Скачать
Общедоступная ссылка обновлена
Общедоступная ссылка на ваш чат была обновлена. Вы можете просматривать и управлять своими ссылками на чат после регистрации здесь.
Общедоступная ссылка на документ
Реклама
