The following can be protected in a DB2 environment:
Each of these bulleted items is discussed in the subsequent headings and gives a description of how these particular objects and resources can be protected.
Access to specific DB2 subsystems is controlled outside of DB2. You do not signon to DB2; instead, you connect to DB2 from other environments such as TSO, batch, IMS, CICS, or distributed platforms. When you connect to DB2, DB2 calls the System Authorization Facility (SAF) to verify that you are permitted access to the DB2 subsystem from your environment.
To fully protect the data in DB2, you must take steps to ensure that no other process has access to the data sets in which DB2 data resides.
To protect archive log tape data sets, specify YES on the installation CLIST panel entry for ARCHIVE LOG RACF.
DB2 controls access to its objects by a set of privileges. A privilege allows an action on some object. In its most basic sense, a privilege is an action given to a user by the execution of a GRANT statement.
There are several ways within DB2 to give an ID access to data:
The concept of different types of privileges is discussed in detail later in this chapter in “What Are DB2 Authorities and Privileges?”
An authorization ID is an identifier that represents a set of privileges. This short identifier can also represent a user or group of users, but DB2 does not determine this representation.
Authorization IDs are used by DB2 to provide:
Every process has one primary authorization ID. It can also have one or more additional authorization IDs called secondary authorization IDs.
Ownership of an object carries with it a set of related privileges over the object. An ID can own an object it creates, or it can create an object owned by another ID. The use of IDs is controlled by CA Top Secret and by the choices you make for DB2 connections.
A primary authorization ID is used to identify the user of a process in DB2.
Although you do not actually sign on to DB2, this primary ID identifies you. It is determined by the type of system from which you are connecting to a DB2 subsystem. For example, if you connect through TSO, your primary authorization ID is the user ID that you signed on to TSO; namely, your logon ID.
A secondary authorization ID is an optional ID that can hold additional privileges available to a process. A process can have up to 245 secondary IDs. The required privileges for some actions can be held by any one of these secondary IDs. Secondary authorization IDs can reduce some of the administrative burdens caused by the cascade affect when privileges are revoked. The cascade effect is discussed later in this chapter when addressing explicit privileges and the REVOKE statement.
Note: Secondary authorization IDs for DB2 users provide the same capabilities as CA Top Secret profiles. Although profiles and secondary authorization IDs are conceptually the same, it is the CA Top Secret profile that is more functionally adept to handle your privileges and access authorizations. Further discussion of how CA Top Secret can be used to secure secondary authorization ids can be found in the “Protecting Resources” and “Comparing DB2 and CA Top Secret Option for DB2” chapters.
The current SQL ID is the current authorization ID of the user for those commands or statements where composite privileges are not used. By composite privileges we mean that the execution of an SQL statement can be based on the privileges of more than one authorization ID of the process.
The only authorization ID that can be changed during a connection (without using an exit routine) is the current SQL ID. This can be changed using the following SQL statement:
SET CURRENT SQLID = idname
The value of idname can be a literal, a host variable, or the special keyword USER.
The current SQL ID can be set to:
|
Copyright © 2011 CA Technologies.
All rights reserved.
|
|