Defining and Protecting Resources

Comparing DB2 and CA Top Secret Option for DB2 › Defining and Protecting Resources

Defining and Protecting Resources

Native DB2 Defining and Protecting Resources	CA Top Secret Option for DB2 Defining and Protecting Resources
DB2 protects the following resources through explicit or implicit privileges: Buffer Pools Collections Databases Distinct Types Functions JAR Files Packages Plans Roles Storage Groups Stored Procedures Schemas Sequences System Privileges Table Spaces Tables/Views Trusted Context	CA Top Secret defines the following DB2‑related resources to the RDT: DB2BUFFP DB2COLL DB2DBASE DB2TYPE DB2FUNC DB2JAR DB2PKG DB2PLAN DB2ROLE DB2STOGP DB2PROC DB2SCHMA DB2SEQ DB2SYS DB2TABSP DB2TABLE DB2TRCON
DB2 protects explicitly through the SQL GRANT or REVOKE statement. DB2 protects implicitly when you create an object. Privileges that are explicitly or implicitly granted to an ID are recorded in the DB2 catalog. Each row in the catalog table represents one privilege that has been granted to an authorization ID. When you try to perform a function, DB2 checks the catalog table for each ID until one has the required privilege assigned to it. Obviously, the more secondary IDs assigned to the primary ID, the slower the DB2 process. For some privileges, it is more complicated to determine which users are granted the privilege. With the UPDATE privileges, DB2 must check two tables if UPDATE is restricted to a column level: one for the table privileges and one for the column privileges. Authorization checking for resources when a plan or package is bound can take place at two different times: at bind time and at execution time.	CA Top Secret Option for DB2 performs authorization checking on all of the DB2 resources in question, which allows or prevents access to that particular function. Four different security modes help you tailor and migrate your security. CA Top Secret Option for DB2 does not update the DB2 catalog tables when CA Top Secret administration is performed. CA Top Secret is not involved in protecting or interpreting native DB2 Grant and Revoke administration. Native DB2 rules for Grant and Revoke administration apply even after a subsystem is converted to external security (that is, the issuing user must have appropriate native DB2 authorization to Grant or Revoke). We recommend that sites eliminate all native DB2 administration wherever possible to help eliminate unexpected results. Native DB2 Grant and Revoke have no effect on security processing once CA Top Secret Option for DB2 is implemented in a subsystem.

Native DB2
Defining and Protecting Resources

CA Top Secret Option for DB2
Defining and Protecting Resources

DB2 protects the following resources through explicit or implicit privileges:

Buffer Pools
Collections
Databases
Distinct Types
Functions
JAR Files
Packages
Plans
Roles
Storage Groups
Stored Procedures
Schemas
Sequences
System Privileges
Table Spaces
Tables/Views
Trusted Context

CA Top Secret defines the following DB2‑related resources to the RDT:

DB2BUFFP
DB2COLL
DB2DBASE
DB2TYPE
DB2FUNC
DB2JAR
DB2PKG
DB2PLAN
DB2ROLE
DB2STOGP
DB2PROC
DB2SCHMA
DB2SEQ
DB2SYS
DB2TABSP
DB2TABLE
DB2TRCON

DB2 protects explicitly through the SQL GRANT or REVOKE statement. DB2 protects implicitly when you create an object.

Privileges that are explicitly or implicitly granted to an ID are recorded in the DB2 catalog. Each row in the catalog table represents one privilege that has been granted to an authorization ID. When you try to perform a function, DB2 checks the catalog table for each ID until one has the required privilege assigned to it. Obviously, the more secondary IDs assigned to the primary ID, the slower the DB2 process.

For some privileges, it is more complicated to determine which users are granted the privilege. With the UPDATE privileges, DB2 must check two tables if UPDATE is restricted to a column level: one for the table privileges and one for the column privileges.

Authorization checking for resources when a plan or package is bound can take place at two different times: at bind time and at execution time.

CA Top Secret Option for DB2 performs authorization checking on all of the DB2 resources in question, which allows or prevents access to that particular function.

Four different security modes help you tailor and migrate your security.

CA Top Secret Option for DB2 does not update the DB2 catalog tables when CA Top Secret administration is performed. CA Top Secret is not involved in protecting or interpreting native DB2 Grant and Revoke administration. Native DB2 rules for Grant and Revoke administration apply even after a subsystem is converted to external security (that is, the issuing user must have appropriate native DB2 authorization to Grant or Revoke). We recommend that sites eliminate all native DB2 administration wherever possible to help eliminate unexpected results. Native DB2 Grant and Revoke have no effect on security processing once CA Top Secret Option for DB2 is implemented in a subsystem.