Migrating Access Control from DB2 to RACF - IDUG

May 21, 2008 • 01:30 p.m. – 02:30 p.m.Platform: DB2 z/OS

Peter SuhnerAXA Tech Switzerland AG

Session: H10

Migrating Access Control from DB2 to RACF

At AXA Tech Switzerland (former Winterthur Insurance), z/OS security had always been implemented with RACF security system - with the sole exception of the DB2 subsystem. To reduce the overhead and complexity of maintaining two interacting security systems, we decided to migrate our DB2 security definitions to RACF.

The major benefits we gained from that one-year project are: - Transparency: for the administration - Performance: Resource validation only takes place once in RACF - Simplicity: Reduction from some hundred thousands of different DB2 access rights (Grants) to a few thousand generic RACF

profiles - Auditability: Logging of all access by SMF - Governance: Centralized administration of all user access rights- Data quality: Avoidance of outdated and inoperative User-IDs by daily comparison between RACF UserIDs and HR data

The presentation will also mention obstacles and exceptions we experienced.

2

2

Agenda• Introduction• Basic Concepts• Mapping DB2 to RACF• Migration Planning• Migration Implementation• Security Check with RACF• Project information and result• Open issues and recommendations

Listed on this slide are the major topics of this presentation.

Note: A few slides are not shown during the presentation, but are available in your proceedings. These slides supply additional information where we think this might be useful. These slides are not necessary to follow the sequence of information provided here.

3

3

AXA Tech Switzerland Systems overview• Main components of mainframe systems

• Hardware• z9 system running z/OS 1.8• Parallel Sysplex in Production and Acceptance Testing

• Subsystems• Transaction Monitors: IMS-TM v9 and CICS-TS v2.2• Databases: DB2 v8 and IMS v9• Middleware: MQ v6 and CORBA (IONA v6)• RACF v1.8, used for RRSF

• Provider for Mainframe operations -> IBM• Systems, Subsystems, Applications; including Dispatching

A quick overview of the mainframe environment at AXA Tech Switzerland

Note: RRSF stands for RACF Remote Sharing Facility, a tool that synchronizes the RACF databases across system boundaries

4

4

Systems architectureProduction / P Acceptance / A Development - Education / D

P1 P2 A1 A2

P1DB2 P2DB2 P1DB2 P2DB2 E1DB2 D1DB2 M1DB2

25 x P1IMSx 25 x P2IMSx 18 x P1IMSx 18 x P2IMSx 9 x E1IMSx /2 x CICSSx

11 x D1IMSx /9 x CICSTx

CF CF

IMS/DB IMS/DB IMS/DB IMS/DB IMS/DB IMS/DB

10 x CICSPx 8 x CICSPx

P1QM P2QM P1QM P2QM E1QM D1QM

D1

900 MIPS 175 MIPS600 MIPS

175 MIPS900 MIPS

Version 1.1 /Feb 2007

1 x CICSTX

3 Main Systems: Production P / Acceptance A / Development D

Production X10: Sysplex – total 1800 MIPS• 2 DB2 Subsystems (P1DB2, P2DB2) with +/- 110 DB2 DBs• 50 IMS TM (Transaction Monitor) Regions• 10 CICS Instances• 2 IMS-DB Systems with +/- 70 IMS DBs• 2 Queue-Managers for Websphere MQ (P1QM, P2QM)• No SAP on the MainframeProduction and Acceptance Systems are identical

Developers: ~300

Development - Education: monoplex since 2006• 3 DB2 Subsystems (E1DB2, D1DB2, M1DB2) with +/- 800 DB2 DBs• 20 IMS TM (Transaction Monitor) Regions• 12 CICS Instances• 2 IMS-DB Systems with ~75 IMS DBs• 2 Queue-Managers for Websphere MQ (E1QM, D1QM)

5

5

Environment # DB # Tables SpaceDev/Edu 1,341 100,976 8.0 TBAcceptance 174 11,221 4.0 TBProduction 204 11,569 4.1 TBTotal 1,719 123,696 16.1 TB

Number of Mainframe Software-Developers: ~300

Major Products: DB2, QMF, DB/IQ, Erwin, CMF, Spufi, DB2 Utilities & -Routines, Strobe & APC, PM, …

DB2 z/OS Quantity Structure

Major products in DB2 environment:- QMF- Strobe & APC: Performance Analysis and Measurement Tools by Compuware and Trilog- DBIQ: Quality Assurance for DB2 SQL by InSoft Software GmbH, Germany- Erwin: Data Modelling Tool by CA- CMF: Change Management Facility by UBS KeyTools, Switzerland- SPUFI- DB2 IBM Utilities- DBMAN: Cross-platform SQL-Interpreter and Export/Import tool by Marco Gessner; Switzerland- IBM Performance Monitor- Explain and Visual Explain: access path analysis

6

6

Reasons for migration• Who should manage your Security?

• Your security staff?• Your DBAs?

• 2 security systems = waste of resources• Differences between DB2 and RACF impact

implementation of application security• Provider task vs. DIY• to put it short: Standardization and Cost Savings

• The major question is one of responsibilities: Should security administration really be a DBA task? We clearly deny!• Other subsystems like CICS and IMS already used RACF-Access-Control for years. DB2 was the exception. => Different

handling of different subsystems• 2 security systems: DB2-internal and external

• responsibility and support for security at 2 locations• No centralized access management possible

• IBM, as our provider, was responsible for DB2 security administration: Formal request to our provider for any definition/redefinition in DB2 security plus the need to coordinate such requests with our internal RACF security administration led to complex, long-running and error-prone processes.

• Plus several more reasons:• No SMF protocol about access w/o DB2 auditing switched on => Audit • Obsolete/invalid UserIds in subsystem DB2 as there is no comparison with HR data• To assert our internal security concepts and naming standards, we use certain company-written Assembler

programs to restrict data modification authority to certain Secondary-UserIds and tools. This is not under control of our provider and needs to be checked/maintained with each new DB2 version

• The External Security Manager (ESM) - product RACF at our site - was used for:- checking primary auth-ID (TSO-LOGON-Id; IMS-Terminal-ID; Remote User-Name)- checking secondary auth-ID (RACF-Group)

• Everything else was done within DB2 (GRANTs)

7

7

Basic technical concepts

8

8

Basic security concepts DB2• Ownership of object => implicit privileges• Administrative Authority (SYSADM, DBCTRL, ...)• GRANT privileges for functions or procedures

• Use of SQL-Statement; DB2-Commands & -Utilities• Define SP, functions, triggers• Execute Programs (execute Plan privilege)

• GRANT privileges for Data• GRANT Select / Update / ... ON tab TO auth-name

• Explicit, single definitions (lots of...)

Ownership of Objects Privileges:• At object creation time; the owner of an object (DB, TS, Table) gets a set of implicit privileges:

• Administrative Authority like DBADM, DBCTRL• Privileges for functions and/or data like: alter/drop the object; select/update the data; use of LOAD utility; define

constraints/triggers; etc• The owner of an object can GRANT most privileges and even administrative authority explicitly to others

Administrative Authority for object types (hierarchical):• System authorities like SYSADM (all DB2 privileges);

SYSCTRL (all DB2 privileges except read/write user data)SYSOPR (most DB2 commands & utilities);

• Database authorities like DBADM (DB2 privileges to control a data base including manipulation of any table within the DB); DBCTRL (control a data base and run utilities);DBMAINT (work with certain objects and run certain utilities)hierarchical: DBADM authority includes all DBCTRL privileges

• Administrative authorities can not be used to deny access to explicitly GRANTable privileges

GRANTed PrivilegesA privilege allows a specific function to be performed, often on a specific object or on a group.Not all DB2 privileges are explicitly GRANTable. Some are controlled by ownership defined when the object was created. Some

are even DB2 Operator commands.

9

9

Basic concepts RACF• RACF = Resource Access Control Facility

• RACF Classes and profiles

• RACF classes (for DB2)• Control access -> DSNR• Administrative authority class -> DSNADM• Grouping classes (GDSNBP, GDSNPK)• Member classes (MDSNDB, MDSNTB, MDSNUF, ...)

• RACF profiles are unique

• RACF provides generic approach

RACF: Resource Access Control FacilityRACF is a security software which interacts seamlessly with the operating system. RACF retains information about the users, resources, and access authorities in profiles on the RACF database and refers to

the profiles when deciding which users should be permitted access to protected system resources.

RACF classesRACF classes are like compartments in a big wardrobe. They are specifically designed for certain types of chlothes: specifically

designed bars for shirts (on coathangers), another one for shoes; drawers for socks and underware; boards for pullovers; boxes for whatever else, etc.).

RACF provides classes instead of compartments, but they are similarly specialized to support the different types of resources that are available in a mainframe environment.

RACF classes for DB2DSNR: Controls remote access to a DB2 z/OS subsystems from a particular environment (CICS, TSO, DDF, etc.)DSNADM: DB2 administrative authority class.GDSNxyz: Grouping classes (not used in AXA-Winterthur for lack of transparency)MDSNxyz: Member classes (used in AXA-Winterthur). Within the member classes, RACF profiles are defined. Each profile is

unique!

RACF (generic) profilesRACF makes use of generic names (wildcards). This allows for protection of 1-n objects with only one profile.Thus: 1 profile protects 1-n objects; depending on its syntax.

10

10

RACF Grouping vs Member classMember class MDSNTBGrouping class GDSNTB

RACF profil:eSYSIBMAUTHMember:DB2S.SYSIBM.SYSDBAUTH.SELECTDB2S.SYSIBM.SYSPACKAUTH.SELECTDB2S.SYSIBM.SYSPLANAUTH.SELECTDB2T.SYSIBM.SYSDBAUTH.SELECTDB2T.SYSIBM.SYSPACKAUTH.SELECTDB2T.SYSIBM.SYSPLANAUTH.SELECTAccess list:C123456C987654

RACF profil:eDB2S.SYSIBM.SYSDBAUTH.SELECTAccess list:C123456C987654

RACF profile:DB2S.SYSIBM.SYSPACKAUTH.SELECTAccess list:C123456C987654

RACF profile:DB2S.SYSIBM.SYSPLANAUTH.SELECTAccess list:C123456C987654

RACF profile:DB2T.SYSIBM.SYSDBAUTH.SELECTAccess list:C123456C987654

RACF profile:DB2T.SYSIBM.SYSPACKAUTH.SELECTAccess list:C123456C987654

RACF profile:DB2T.SYSIBM.SYSPLANAUTH.SELECTAccess list:C123456C987654

Two userids with accessto six tables Two userids with access to six tables

Grouping Class: Member DB2S.SYSIBM.SYSDBAUTH.SELECT exists within RACF Profil SYSIBMAUTH.For Grouping Classes, the member name (e.g. DB2S.SYSIBM.SYSDBAUTH.SELECT) equals one RACF profile of a Member

Class (righthand part of picture)

As RACF profile names must be unique, it's easier to find a specific profile in Member-classes. When using the concept of Grouping-Classes; 1 specific profil can exist several times within diferent RACF profiles.

Example / Goal: all +/- 50 Catalog-Tables are allowed to be read (select).Either: 50 RACF-Profiles (1 per Catalog-Table) like 'DB2Subsys.SYSIBM.Tablename.SELECT' or 1 Profile with wildcards like 'DB2Subsys.SYSIBM.*.SELECT

11

11

RACF Class vs DB2 ObjectGDSNTB All SYSIBM-TablesDSNADM DB2 administrative authority classDSNR Access to DB2 subsystemsMDSNBP DB2 buffer pool privilegesMDSNCL DB2 collection privilegesMDSNDB DB2 database privilegesMDSNJR Java archive files (JARs)MDSNPK DB2 package privilegesMDSNPN DB2 plan privilegesMDSNSC DB2 schema privilegesMDSNSG DB2 storage group privilegesMDSNSM DB2 system privilegeMDSNSP DB2 stored procedure privilegesMDSNSQ DB2 sequencesMDSNTB DB2 table, index, or view privilegesMDSNTS DB2 tablespace privilegesMDSNUF DB2 user-defined function privilegesMDSNUT DB2 user-defined distinct type privileges

18 RACF

classesused

Further 15 grouping classes not used

RACF-Class DB2-Object

The above (and more) RACF classes for DB2 objects and administrative authorities are supplied in the class descriptor table (CDT).

See also: Book DB2 RACF Access Control Module Guide, Table 11. Resource classes for DB2 objects and administrative authorities

If you use Grouping Classes in a complex environment, things may easily become intransparent. As it's name implicates, you can define Grouping Class definitions to contain lots of different resource profiles. And one single resource definition can be contained in more than one Grouping Class definition. To make things a bit more complicated, the same resource may be coded as "UACC(NONE)" in our first grouping class definition, while it has UACC(READ) in another one. What happens now if a user (or group of users) is permitted both of these grouping class definitions?

It's obvious for RACF: it will assume the one with the least authority (being UACC(NONE) in this case) and therefore deny access. It is clearly much less obvious for the security administrator to maintain profiles with diverging contents. Unexpected side effects will occur very soon.

12

12

Scope of RACF classes• Single Subsystem Scope

• Class name contains DB2 subsystem name (i.E MDSN1BP#)• Resource/Profile names don't contain DB2 subsystem name• Need to define separate classes for each subsystem• Classes must be defined by the installation

• Multi-Subsystem Scope• 1 set of 18 general resource classes for multiple subsystems• Classes provided in CDT (class descriptor table) within RACF• Subsystem name appears in resource name

• Protection of resource within subsystem boundaries• => fewer classes & profiles overall ☺

Defining RACF classesThere are 2 different concepts for defining RACF classes:

a) Single subsystem scope (= defining classes pro subsystem in CDT)In single-subsystem scope, the class names of the DB2 object classes contain the DB2 subsystem name or DB2 group

attachment name but the profile names of resources in those classes do not. Therefore, in single-subsystem scope, you must define a separate class name for each subsystem that will use the RACF access control module.

b) Multi Subsystem Scope (= subsystem in resource name)In multiple-subsystem scope, profile names of resources in the DB2 object classes are prefixed with the DB2 subsystem name,

or group attachment name, but the class names are not.If you use the multiple-subsystem scope and the default &CLASSNMT value (DSN), you can use the classes provided in the

IBM supplied CDT class descriptor table (ICHRRCDX).Any subsystem sharing the RACF access control module can share the same set of classes. You do not need to define a

separate set of classes for each subsystem.

The primary reason for this choice is to protect multiple subsystems with a single set of resource profiles and to have fewer classes in total.

13

13

Multi Subsystem Scope

taken from "RACF and DB2 – Teamed for Security", by Mark Nelson, IBM

Multi subsytem scopeThis diagram illustrates the names, with the data sharing group name or subsystem name as a prefix to the resource name

(also called "profile").The classes are provided by IBM in the CDT class descriptor table (ICHRRCDX) within RACF.

DSNx prefix for subsystem-IDXxxx DatabaseYyyy table name / function privilegeZzzz what (SELECT, INSERT, UPDATE, DELETE)

Example: Class MDSNTB => DB2S.SYSIBM.SYSDBAUTH.SELECT

14

14

Conceptual differences

• RACF – cross-system• DB2 – per system• Generic profiles for several

objects possible

• Profile & access list can be predefined

• No cascading GRANT / REVOKE possible

• DB2 privileges in RACF database!

• Each object must be granted

• Grant tied to object

• Grant .... WITH GRANT OPTION

• Catalog-Tables show privileges

This is an overview of distinct and important conceptual differences between DB2 an RACF security

15

15

Conceptual differences II• RACF – cross-system implementation

• Profiles from several DB2 subsystems in one single RACF DB• Security tied to a profile

• Drop DB2 object -> RACF privileges remain• Catalog-Tables like SYSxyzAUTH don't show all privileges

• Need for a RACF-Query Tool => RA2• DB2 – per system/environment (Dev, Acc, Prod)

• Security tied to the object• Create object first• Drop object -> all privileges gone

• Catalog-Tables show privileges

• In our systems, we had implemented our own security exit which ensured that only specific DB2 secondary user IDs were allowed to perform data modifications. Data modification from remote systems were generally prohibited.This security exit became ineffective with the security migration to RACF and other concepts had to be implemented.

• In our 2-way sysplex in Production; RACF is started on each plex. The RACF DB is shared.

• Catalog Tables (SYSDBAUTH, SYSPACKAUTH, SYSPLANAUTH, SYSRESAUTH, SYSUSERAUTH, etc) don't show all privileges; as the entries in the SYSIBM.SYSxyzAUTH tables are irrelevant. The privileges are now defined in RACF.

• Therefore, to see privileges; the user needs a tool to query RACF (such as RA2).

16

Mapping DB2 to RACF

17

17

Mapping DB2 to RACF• DB2 ownership of object

RACF general resource classes

• DB2 Administrative Authority (SYSADM, DBCTRL) profiles within RACF general resource class

DSNADM

• Granted privileges part of RACF profile name (Access Control List)

The DB2 authorization checking uses RACF general resource classes that correspond to the DB2 objects.

The DB2 administrative authorities like SYSADM, DBCTRL also have profiles within other RACF resource classes.- P0DB.SYSADM- P0DB.Ixxx.DBADMThe RACF-class name for administrative authorities is DSNADM

The DB2 (granted) privileges are more specialized than the RACF ones, so they are included as part of the profile name.Example: PERMIT M0DB.IXXX.ITTEST1.SELECT CLASS(MDSNTB) ACC(READ) ID(xxxxx)

18

18

Mapping DB2 to RACF

RDEFINE: Protection profile for a given object, also defining a general access rule (UACC = Universal ACCess = default access if no further profile is specified)

PERMIT: Access List (ACL) => who is allowed to do what? (kind of connection between the profile/resource and the User-/Group-ID)

Any PERMIT is an exception to the general access as defined with RDEFINE

DSNADM: DBADM, DBMAINT, DBCTRL

MDSNTB: SELECT, DELETE, INSERT, UPDATE, INDEX

MDSNDB: LOAD, IMAGCOPY, REORG, DROP, DISPLAYDB, RECOVERDB, REPAIR, CREATETAB, STATS, STARTDB, STOPDB

MDSNSM: BINDADD, BINDAGENT, CREATEDBA, DISPLAY, RECOVER, TRACE, STOPALL, etc.

MDSNPN: EXECUTE, BIND

Example: The names use multi-subsystem scope, so they are prefixed by the subsystem (M0DB) and suffixed by the privilege (SELECT)

19

19

Mapping DB2 to RACF RACF

RDEFINE MDSNDBM0DB.IXXX.LOAD UACC(NONE)

PERMIT M0DB.IXXX.LOADCLASS(MDSNDB) ACC(READ)ID(xxxxxxx)

RDEFINE MDSNSMM0DB.BINDADD UACC(NONE)

PERMIT M0DB.BINDADDCLASS(MDSNSM) ACC(READ)ID(xxxxxxx)

RDEFINE MDSNPNM0DB.ABCD.EXECUTEUACC(NONE)

PERMIT M0DB.ABCD.EXECUTECLASS(MDSNPN) ACC(READ)ID(xxxxxxx)

GRANT LOAD ONDATABASE IXXXTO xxxxxxx

GRANT BINDADDTO xxxxxxx

GRANT EXECUTEON PLAN ABCDTO xxxxxxx

Example applies to IMAGCOPY, REORG, DROP,DISPLAYDB, RECOVERDB, REPAIR, CREATETAB, STATS,STARTDB, STOPDB, etc. as well

Example applies to BINDAGENT, CREATEDBA, DISPLAY,RECOVER, TRACE, STOPALL, etc. as well

Example applies to BIND as well

DB2

RACF class MDSNDB

RACF class MDSNSM

RACF class MDSNPN

RDEFINE Protection profile for a given objectPERMIT Access List (ACL) => who is allowed to do what? (kind of connection between the profile/resource and

the User-/Group-ID)

DSNADM: DBADM, DBMAINT, DBCTRL

MDSNTB: SELECT, DELETE, INSERT, UPDATE, INDEX

MDSNDB: LOAD, IMAGCOPY, REORG, DROP, DISPLAYDB, RECOVERDB, REPAIR, CREATETAB, STATS, STARTDB, STOPDB

MDSNSM: BINDADD, BINDAGENT, CREATEDBA, DISPLAY, RECOVER, TRACE, STOPALL, etc.

MDSNPN: EXECUTE, BIND

Example: The names use multi-subsystem scope, so they are prefixed by the subsystem (M0DB) and suffixed by the privilege (SELECT)

20

20

Fully qualified vs. generic mapping

RDEFINE DSNADMM0DB.IXXX.DBADM UACC(NONE)

PERMIT M0DB.IXXX.DBADMCLASS(DSNADM) ACC(READ) ID(xxxxxxx)

RDEFINE MDSNTBM0DB.IXXX.ITTEST1.SELECT UACC(NONE)

PERMIT M0DB.IXXX.ITTEST1.SELECTCLASS(MDSNTB) ACC(READ) ID(xxxxxxx)

RDEFINE DSNADMM0DB.IXXX.DB** UACC(NONE)

PERMIT M0DB.IXXX.DB*CLASS(DSNADM) ACC(READ) ID(xxxxxxx)

RDEFINE MDSNTBM0DB.IXXX.IT*.SELECT UACC(NONE)

PERMIT M0DB.IXXX.IT*.SELECTCLASS(MDSNTB) ACC(READ) ID(xxxxxxx)

1:1 mapping from DB2= millions of profiles

Generic mapping= few thousand profiles

This is a comparison of fully qualified mapping and generic mapping. While DB2 does not allow generic security definitions, RACF does. This allows you to define one single profile for a whole bunch of similar resources.

To achieve a good result (meaning: saving lots and lots of single security definitions), standardization of object names is a vital precondition.

Basic steps for RACF profiles are• Define the profile for a specific resource (or a group of resources – generic approach) with UACC NONE as default• Define access for users (or groups of users – generic approach) as the exception to UACC NONE

1. RDEFINE Class-name:1st step in the definition process for a (protection) profile. There is no need that the object exists! Complete protection is

achieved with UACC(None).

2. PERMIT:Administrate the Access List (ACL) for the profile. => Who is allowed to do what?

MDSNTB -> RACF class for DB2 Tables/Index/ViewsM0DB -> DB2 subsystemIXXX -> DatabaseDBADM -> Function privilegeXxxxxxx -> User- or Group-ID (Ixxxxxx, $xyz)

ITTEST1 -> DB2 object; depending on RACF-ClassSELECT -> access-function (also DELETE, INSERT, UPDATE)ACC(...) -> NONE or READThe term "read" is misleading for DB2 people: "read" means "is allowed to"

With generic mapping, we may use wildcards on any level of the definition:PERMIT M0DB.IXXX.IT*.SELECT -> Select on any table starting with 'IT' in database 'IXXX' of subsys M0DBPERMIT M0DB.IXXX.IT*.* -> Select/Update/Insert/Delete on any table starting with 'IT' in DB 'IXXX' of subsys M0DBPERMIT M0DB.*.*.SELECT -> Select on any table in any database of subsystem M0DBetc.

21

21

Fully qualified profile mapping

• DSNADM= class name• M0DB = DB2 subsystem• IXXX = Database• DBADM = function privilege• xxxxxx = who (User- / Group-ID)

• ITTEST1 = DB2 object (Table)• SELECT = Access• ACC(…) = Access to profile Y/N

RDEFINE DSNADMM0DB.IXXX.DBADM UACC(NONE)

PERMIT M0DB.IXXX.DBADMCLASS(DSNADM) ACC(READ)ID(xxxxxxx)

RACF

RDEFINE MDSNTBM0DB.IXXX.ITTEST1.SELECTUACC(NONE)

PERMITM0DB.IXXX.ITTEST1.SELECTCLASS(MDSNTB)ACC(READ) ID(xxxxxxx)

ACC(READ) = is allowed to...

1. RDEFINE Class-name:1st step in the define process for a (protection) profile. Can be done without the object existing. Complete protection with

UACC(None).

2. PERMIT:Administrate the Access List (ACL) of the profile. => Who is allowed to do what?

M0DB -> DB2 subsystemIXXX -> DatabaseDBADM -> Function privilegeXxxxxxx -> User- or Group-ID (Ixxxxxx, $xyz)

ITTEST1 -> DB2 object; depending on RACF-ClassSELECT -> access-function (also DELETE, INSERT, UPDATE)ACC(...) -> NONE or READThe term "read" is misleading for DB2 people: "read" means "is allowed to"

22

22

Generic profile mapping

• DSNADM= class name• M0DB = DB2 subsystem• IXXX = Database• DB* = function privilege• Xxxxxx = who (User-ID)

• IT* = all Tables named IT%• DB* = all functions like DB%

RDEFINE DSNADMM0DB.IXXX.DB* UACC(NONE)

PERMIT M0DB.IXXX.DB*CLASS(DSNADM) ACC(READ)ID(xxxxxxx)

RACF

RDEFINE MDSNTBM0DB.IXXX.IT*.SELECTUACC(NONE)

PERMIT M0DB.IXXX.IT*.SELECTCLASS(MDSNTB) ACC(READ)ID(xxxxxxx)

1. RDEFINE Class-name:1st step in the define process for a (protection) profile. Can be done without the object existing. Complete protection with

UACC(None).

2. PERMIT:Administrate the Access List (ACL) of the profile. => Who is allowed to do what?

M0DB = DB2 subsystemIXXX = DatabaseDB* = Function privilegeXxxxxxx = UserID

IT* = DB2 objects; depending on RACF-class => all Tables named like IT%DB* = all functions named like DB% =>

DBADM, DBCTRL, ...

23

23

Base profile for each DBFor each DB2 database, these are the basic RACF definitions

• RDEFINE DSNADM for administrative authorities with UACC(NONE)

• PERMIT for SecUID $xyz in DSNADM Class with ACC(READ)

• Example:RDEFINE DSNADM M0DB.IDBE.DB* UACC(NONE)

PERMIT M0DB.IDBE.DB* CLASS(DSNADM) ID($xyz) ACC(READ)

1. RDEFINE Class-name:1st step in the definition process for a (protection) profile. Can be done without the object existing. Complete protection with

UACC(None).

2. PERMIT:Administrate the Access List (ACL) of the profile. => Who is allowed to do what?

For each new DB2 Database; the following will be defined in advance:a) RDEFINE DSNADM for administrative authorities with UACC(NONE)

-> RDEF DSNADM M0DB.IDBE.DB* UACC(NONE) b) PERMIT for SecUID $xyz in DSNADM-Class with ACC(READ)

-> PERMIT M0DB.IDBE.DB* CLASS(DSNADM) ID($D2Txyz) ACC(READ)-> DB* allows for any admin right starting with DB (e.g. DBADM, DBCTL, DBMAINT, ...)

As a result, the resource (= database) is generally protected (nobody is granted access due to UACC(NONE) except members of Racf-SecUID $xyz in Class DSNADM)

BTW: DB2 Secondary Auth IDs are defined as RACF groups

24

24

Migration Planning

25

25

Migration Phases• Pilot study

• Dependencies on DB2 tools• Cascade effects, etc.

• Core concept• Standards and requirements for RACF profiles• Project planning

• Implementation "step by step"• define, activate, refine

refine

activatedefine

The pilot study phase answers basic feasiblity questions:• What dependencies do exist• How do changes affect the environment• What side effects might occur• etc.

RACF differs from DB2 security in several ways. To overcome issues arising from these differences, a core migration concept is inevitable:

The core concept will define how to achieve the goals:• Definition of underlying standards• Requirements analysis and solution definition• Core project plan (workpackages, milestones, dependencies, schedule, resource planning, etc.)

Based on the results from pilot study and core concept, the project steering committee decided: Go ahead!

Next step was to implement the migration according to the results of the previous project phases. Implementation is possible step-by-step, as DB2 security and RACF security may be run in parallel. You may choose to leave only migrate part of the security to RACF while leaving the remainder with DB2.

26

26

Example: Standard RACF profile for developer

DSNADMx0DB.userid.DB* UACC(NONE)ID(userid) ACC(READ)MDSNTBx0DB.userid.** UACC(NONE)ID(userid) ACC(READ)

DBADM/DBMAINT/DBCTRL Access(for own userid)

Access to all tables(for own userid)

Access to all"standard" projects(Standard for SW-Developer)

MDSNBPx0DB.ALL.USE UACC(READ)x0DB.BP*.USE UACC(READ)

Userid-Environment

Project-Environment

GeneralAccess

MDSNCLx0DB.C*.CREATEIN UACC(READ)x0DB.NULLID.CREATEIN UACC(READ)DSNADMx0DB.C*.PACKADM UACC(READ)(Only MAINT & DEV)

MDSNTBx0DB.proj.*.SELECT UACC(NONE)x0DB.proj.*.INSERT UACC(NONE)x0DB.proj.*.UPDATE UACC(NONE)x0DB.proj.*.DELETE UACC(NONE)ID($D2x0012) ACC(READ) (for all 4 profiles)

Access per project forproject employees(additional to standard)

MDSNPNx0DB.*.BIND UACC(READ)x0DB.*.EXECUTE UACC(READ)(Only MAINT & DEV)

MDSNDBx0DB.DSQDBDE%.CREATETAB UACC(READ)x0DB.DSQTSDE%.CREATETAB UACC(READ)P0DB.P1DBTEMP.* UACC(READ)P0DB.P2DBTEMP.* UACC(READ)

MDSNPKx0DB.*.*.BIND UACC(READx0DB.*.*.EXECUTE UACC(READ(Only MAINT & DEV)

MDSNTBx0DB.SYSIBM.*.SELECT UACC(READ)

x0DB.DBXREL30.*.SELECTx0DB.DBXREL30.DBX_WKSN_XREF.INSERTx0DB.DBXREL30.DBX_WKSN_XREF.UPDATE(Only MAINT, DEV, EDUC)

MDSNTBx0DB.proj.*.* UACC(NONE)ID($D2xxxx1) ACC(READ)DSNADMx0DB.proj.DB* UACC(NONE)ID($D2xxxx1) ACC(READ)MDSNDBx0DB.proj.* UACC(NONE)ID($D2xxxx1) ACC(READ)

MDSNTBx0DB.spez-proj.*.* UACC(NONE)ID($D2xxxx1) ACC(READ)DSNADMx0DB.spez-proj.DB* UACC(NONE)ID($D2xxxx1) ACC(READ)MDSNDBx0DB.spez-proj.* UACC(NONE)ID($D2xxxx1) ACC(READ)

access per specialproject for projectemployees(additional to standard)

MDSNSMx0DB.BINDADD UACC(READ)(Only MAINT & DEV) (PROD,ACC,EDUC=support)x0DB.DISPLAY UACC(READ)x0DB.MONITOR% UACC(READ)x0DB.TRACE UACC(READ)

MDSNTSx0DB.DSN*.USEx0DB.DSQDBDE%.DSQTSDE%.USEx0DB.DSQTSDE%.USEUACC(READ) for all 3 profiles

MDSNSPx0DB.*.*.DISPLAY UACC(READ)x0DB.*.*.EXECUTE UACC(READ)

MDSNSGx0DB.x1REL.USE UACC(READ)

SecondaryUserids

Sys = PROD$D2Pxxxx$DBPxxxx

Sys = ACC$D2Pxxxx$DBPxxxx

Sys = DEV$D2Txxxx$DBTxxxx

Sys = EDUC$D2Sxxxx$DBSxxxx

Sys = MAINT$D2Mxxxx$DBMxxxx

This is an exemplary part of our core concept: Profile definition basis that will allow for generic profiles

Standards are defined on three layers:1. Userid-Environment

- Two classes are required for the Userid-DB- These two profiles are only implemented on specific request of the employee

2. Project-Environment- Three classes are required for the project (or workareas) DB- With MDSNTB, all projects are related to the software developers (via $xyz)- Remaining table access per project/workarea are mapped to respective secondary user-ids- Non-standard projects (HR, Security, etc.) are mapped via the project's secondary user-id only- Within DSNADM and MDSNDB, every project is mapped to a profile with access to the project's secondary user-id

This is not visible in the slide as it only arose as an additional requirement during implementation – core concepts are important, but rarely immaculate...)

3. General Access (PUBLIC access within DB2)- Contains all profiles, which had to be created with UACC(READ) according to the conversion utility and subsequent analysis by DB2 concept specialists. The meaning of these profiles is partly somewhat ambiguous (no one really knows why they are there), so they had to be made accessible for all employees.

27

27

Migration Implementation

RACF

DB2

28

28

Migration Preparation• RACF structures (are the most important part!)

• Definition of RACF structures and profiles• Activation of all required DB2-RACF classes (DSNADM,

MDSNBP, etc.)

• Tool decision• 3 available flavors of the RACF DB2 migration tool

• RACFDB2/RXSQLrequires the RXSQL (product 5764-074)

• RACFDB2/BatchPipesrequires the BatchPipes or MVS PipesRACFDB2requires only DB2 v6 (or above)

Selecting ONE (out of 3 possible) RACF DB2 migration toolhttp://www-03.ibm.com/servers/eserver/zseries/zos/racf/racfdb2.html

Reasons for our choice of RACFDB2:- commonly used tool/product (our RACF-specialist Max Meier asked at the RACF-Guide)- Straightforward tool which does not require further products or special features- Free of charge

29

29

RACFDB2 Migration Tool• RACFDB2 utility converts contents of

SYSIBM.SYSxxxAUTH tables to equivalent RACF profiles

• For large DB2 systems, utility will generate a lot of RACF commands (RDEFINE, PERMIT)

• Manually merge of profiles required to create fewer generic profiles

The RACF DB2 Conversion Utility generated:- Development Environment: 3,110,836 RACF Commands !! - By (partly manually!) merging / mapping these commands according to our earlier definied standards to generic profiles; we

ended up with 1,454 RACF profiles.

- PROD: from 729,021 generated commands to 987 generic profiles ☺

30

30

Install RACF Control Module (DB2 V8)• Source Code (member DSNXRXAC) provided in Library

SYS1.SDSNSAMP• Installation steps:

• copy member to a private library• Optionally, customize the copy

(exit options & classes if not using the defaults)• Define profiles and activate desired classes (with

Migration Tool)• Run the DB2 installation job DSNTIJEX (Step 3)

• Next time DB2 subsystem starts, the RACF / DB2 External Security Module will be active ☺

Excerpt from: V8 RACF Control Module Guide; Chapter 3 – Installing RACF Access Control Module

• Locate the DSNXRXAC member (containing the RACF access control module) in the prefix.SDSNSAMP library and copy it to a private library.

- Optionally, customize your private copy of the RACF access control module by modifying the assembler SET options from their default values. The options you use in this step will affect DB2 authorization processing (Defaults = use classes provided in CDT; otherwise classes must be predefined).

- Use the DB2 installation job DSNTIJEX to assemble and link-edit the RACF access control module into the APF-authorized DB2 exit load library (prefix.SDSNEXIT).

- Define profiles and activate desired classes (subset of all the provided ones)- Modify Step 3 (JEX0003) of DSNTIJEX to point to the library containing your (customized) version of DSNXRXAC and then

run it.- After you complete these steps, the RACF access control module will be initialized the next time the DB2 subsystem is

started. The initialization function will succeed and the RACF access control module will become active only if DB2 resource classes are active at the time of the restart. If the RACF access control module is active, DB2 will invoke RACF for authority checking.

During DB2 subsystem startup, all profiles are cached in memory which heavily reduces access time (this mechanism is also known for other subsystems like CICS)

31

31

DB2 DBM facility startup

IEF695I START DB2ADBM1 WITH JOBNAME DB2ADBM1 IS ASSIGNED TO USER #aaaa,GROUP #SYSnnnn

$HASP373 DB2ADBM1 STARTED IEF403I DB2ADBM1 - STARTED - TIME=03.23.41IRR908I RACF/DB2 EXTERNAL SECURITY MODULE FOR DB2 SUBSYSTEM DB2A HAS

A MODULE VERSION OF HDRE810 AND A MODULE LENGTH OF 00005BD0. IRR909I RACF/DB2 EXTERNAL SECURITY MODULE FOR DB2 SUBSYSTEM DB2A

IS USING OPTIONS: &CLASSOPT=2 &CLASSNMT=DSN &CHAROPT=1 &ERROROPT=1 &PCELLCT=50 &SCELLCT=50

IRR910I RACF/DB2 EXTERNAL SECURITY MODULE FOR DB2 SUBSYSTEM DB2AINITIATED RACLIST FOR CLASSES:MDSNDB MDSNPK MDSNPN MDSNBP MDSNCL MDSNTS MDSNSG MDSNTB MDSNSM MDSNSC MDSNUT MDSNUF MDSNSP MDSNJR MDSNSQ DSNADM

IRR911I RACF/DB2 EXTERNAL SECURITY MODULE FOR DB2 SUBSYSTEM DB2ASUCCESSFULLY RACLISTED CLASSES: MDSNDB MDSNPK MDSNPN MDSNBP MDSNCL MDSNTS MDSNSG MDSNTB MDSNSM MDSNSC MDSNUT MDSNUF MDSNSP MDSNJR MDSNSQ DSNADM

DB2 startup with the external security module activated

When starting DB2 with the External Security Module activated, the DBM1 started task prints respective messages in the JESMSGLG output.

Only MEMBER-Classes become "raclisted", meaning: loaded in special address space (for higher performance).

DB2 initializes the RACF Control Module during startup of DBM1:- IRR910I message shows all member classes that DB2 expects to be covered by RACF (as defined in the DB2 RACF Control

Module).- IRR911I message shows whether all of these requested classes are prodivded by RACF.- Identical lists in both of these messages show us, that RACF provides what DB2 expected- If any of these classes are not provided by RACF, DB2 will instead use internal security for the respective security checks

32

32

RACF Activation steps• When RACF object-class is not active

=> DB2 internal authority check occurs

• After defining & activating additional RACF classes, restart DB2

• Interceptors for each RACF class prevent DB2 authority checks (Interceptor = generic subsystem profile; e.g. DB2S.** with UACC(NONE) )

• Remove generation of DB2 Grants in tools / utilities / jobs

• Timely educate administrators, supporters, developers

Migration can be done step by step; DB2 Database by database; application after application

If the RACF / DB2 External Security Module detects that an object class is not active or an object profile is not yet defined; DB2 internal security checking will occur for these object types. So there is no need for a "big bang" migration. Also, there is no change in error handling: DB2 always returns the usual SQLCODEs when querying a table he is not allowed to. The RACF-Error is issued additionally and visible in the Log.

When defining and activating additional RACF classes & profiles (for another application-area or additional databases), the DB2 system must be restarted. DB2 starts the external security module which "raclists" the new/additional classes.

As DB2 internal security is not maintained, you must ensure that each and every check will be fulfilled by RACF. This requires to have all respective RACF classes activated. In addition, a generic subsystem profile ("interceptor", called "Abfangjäger" in German) must be defined and activated.

Example for an interceptor:- DB2Subsys.** with UACC(NONE)- Permissions are the exception to this complete denial of access

33

33

Impact of Interceptors (Catch-all)Assumption: No explicit RACF profile exists for specified resource

WITHCatch-all

User Request S

AF

RACF RACFDatabase

ResourceManager

DB2RequestResponse

NO!

NOCatch-all

ResourceManager

DB2

DB2SYSIBMTables

SAF

RACF RACFDatabase

User Request

RequestResponse

Dont' know...

Upper part: During Migration Phase; WITHOUT interceptor/generic subsystem profiles- User request (table access) is routed from Resource Manager DB2 via SAF(RACF) to RACF Database- RACF checks: is there a matching profile for this very user/table?

The best matching profile will be used for authorization checking; e.g. DB2S.DB.Table.SELECT- Next check: does the requesting user have access via profile DB2S.DB.Table.SELECT -- Y/N?- Next check: if NO, search for other matching security profiles (e.g. DB2S.DB.*.SELECT) and

other types of access authority that would implicate the requested type (e.g. DB2S.DB.DBADM of class DSNADM)

- Without interceptors (catch-all profiles), RACF will not necessarily contain a matching profile- The answer (Yes, No or "No information in RACF") is routed back to DB2 Resource Manager- Resource Manager issues

- in case of Y: Query execution and result table- in case of No: SQLCODE -551- in case of "No information in RACF": Query DB2-internal authorization tables and act accordingly

Lower part: After Migration Phase; WITH interceptor/generic subsystem profiles- User Request (Table access) comes to Resource Manager DB2 via SAF(RACF) to RACF Database- RACF checks: is there a matching profile for this very user/table?

The best matching profile will be used for authorization checking; i.E DB2S.DB.Table.SELECT- Next check: has user C123456 access via profile DB2S.DB.Table.SELECT -- Y/N ?- If no exactly matching profile is found, the catch-all will match as a last instance, ensuring that RACF will eventually return

"N".- A catch-all profile for this case would look like "RDEFINE MDSNTB DB2S.** UACC(NONE)" with no existing PERMITs

- With catch-all profiles, RACF will always return a valid answer- Answer from RACF to DB2 Resource Manager: N or Y- Resource Manager issues

- in case of N: SQLCODE – 551 and RACF Error Message- in case of Y: Query execution and result table

34

34

Security Check with RACF activated

35

35

Is this User authorized to…?ALTER TABLE PETER.CTTEST ADD COLUMN i1 INTEGER

. . .SQLCODE –551: PETER.CTTEST does not exist, or you lack

the necessary authority

SYSLOG Entry:ICH408I USER(xyz) GROUP(blabla) NAME(STEINER, SUSI)

DB2T.PETER.CTTEST.ALTER CL(MDSNTB ) INSUFFICIENT ACCESS AUTHORITY FROM DB2T.PETER.** (G) ACCESS INTENT(READ ) ACCESS ALLOWED(NONE ) ***

Statement ALTER TABLE PETER.CTTEST ADD COLUMN i1 INTEGER (run in QMF)

Feedback from QMF is as shown below:

Message No: DSQ17551 SQL Code: -551 PETER.CTTEST does not exist, or you lack the necessary authority.

Explanation: PETER.CTTEST does not exist, or it is a read-only view, or you (the SUSI id) lack the ALTER TABLE authority. The possible causes of the authorization failure are:

1. SELECT authority to SELECT from another user's table or view. 2. INSERT, UPDATE, DELETE, or ALTER authority for another user's table or view. INDEX authority is needed to CREATE an index.

3. GRANT authority (via the WITH GRANT OPTION) to GRANT authority to another user's table or view. 4. Specific authority needed to CREATE a table, SAVE DATA, or reserve space in the database. 5. ALTER authority to perform a FOREIGN KEY, DROP FOREIGN KEY, DROP PRIMARY KEY operation or DROP UNIQUE operation. If this is the case, note that PETER.CTTEST is the name of the table being created or altered, not the name of the table for which C153362 lacks the ALTER authority.

Suggested Action: If you misnamed an existing object, use the correct name. If the C153362 id lacks needed authority, contact your QMF administrator.

With RACF activated, we can find the additional entry in the SYSLOG as shown on the slide.

36

36

… ask RACF!• User "SUSI" wants to alter my TABLE named "CTTEST"

• Security checks:• DB2 Resource Mgr: Does user "SUSI" own the table?• If not, DB2 passes control to RACF• RACF now checks the user's access profile to

one of these resources in RACF class• DB2-subsystem.table-owner.CTTEST.ALTER MDSNTB• DB2-subsystem.database-name.DBADM DSNADM• DB2-subsystem.SYSCTRL DSNADM• DB2-subsystem.SYSADM DSNADM

• RACF answers: NO and issues ICH408I in SYSLOG (including class and profile)

• DB2 issues a SQLCODE -551

This outlines the series of authorization checks that occur in the RACF access control module to determine if the requesting user is authorized to use a particular DB2 privilege against a particular DB2 object type. If any authorization check in the series is successful, the privilege is granted.

The ownership of an object is known to the DB2 Resource Manager. No further questions/checks necessary.If all further authorization checks fail (answer "no" for all of the above questions); the returned RACF class is MDSNTB (the

lowest level).

For details refer to Appendix D in the "RACF Access Control Module Guide" http://www.ibm.com/software/data/db2/zos/library.html

(Despite its name, this is a DB2 manual, not a RACF manual!)

37

37

RACF Query Tool RA/2• Who has access to table AFPRESTAB1 in class MDSNTB?

RACF Query Tool RA/2

Developed by Eugene Vogt. For Manual, see Bibliography It's one of many such tools from other vendors (Beta Systems, Vanguard, etc.)

Call Query-Tool from ISPF primary Option Menu => tso RA2SYPGM

Upper Part: Question- Which RACF Class? MDSNTB- Which user (optional)? xyz- Which table and access method (= Resource Name)?

Lower Part: Answers- protected by profile: DB2X.DATABASE.AFPRES*.SELECT- With UACC: NONE- Which grp/usr has access to the profile? $ABCD001

38

38

Further Considerations• Ownership check is always done by DB2 Resource Manager

• If OWNER of a DB2 object is a valid Secondary ID:SET CURRENT SQLID will keep security check DB2-internal

• No automatic cleanup for RACF profiles if DB2 objects are dropped or renamed => establish new cleanup process in RACF

• The content of the SYSxxxAUTH tables is confusing; better deny access• Provide information about authorities and access rights by

other means (RACF Query Tool)

Now, there is a mix of DB2 & RACF authorization. Old habits must be changed to use RACF techniques instead of DB2 ones.

SET CURRENT SQLID can set a qualifier; but not change authorization. Therefore, OWNER of an object should be a valid group ($D2Txyz).

Ownership is still checked by the DB2 Resource Manager and if you set your current SqlID to the owner of the object, RACF won't be called for security check.

There is no plan or package invalidation if authorization is revoked. Therefore, the information in SYSIBM.SYSxxxAUTH-tables is no longer up-to-date.

Furthermore, if a DB2 object or DB is dropped; the RACF profiles remain intact as they are not attached to the object. A new RACF-cleanup process is needed.

Developers are used to checking authorities in SYSAUTH-Tables. As the information in there is no longer valid, it's confusing for them; deny access to these tables.

But provide the authorization-infos otherwise => Query Tool RA/2

39

39

Cross-platform compatibility (Oracle, DB2 LUW, etc.)

Third party suppliers do not support security externalization to RACF

Revoke of GRANTs has cascade effect on views

Comprehensive security environment

Generic approach

Easy implementation• Step by step• RACF and DB2 in

parallel• Fallback no problem

General Pros and Cons

Apart from the already mentioned advantages like one single, comprehensive, LPAR-spanning security environment that may be implemented with very few generic profiles, there are some more considerations worth mentioning. The migration from DB2 internal security to RACF can be implemented very simple from a technical point of view:

• At ANY time of the process, you may deactivate specific RACF classes or the DB2 security exit as a whole and return to DB2 internal security within minutes

• Therefore you can implement RACF security step by step• Define profile(s) in RACF• Activate and check results• As long as no RACF interceptors are defined, any security check that can't be handled by RACF is returned to DB2's

internal security• Activate RACF interceptors when the profiles are complete and check behavior again• Do NOT remove DB2 internal security profiles unless you are sure that the RACF profiles work as designed

• RACF and DB2 security in parallel• There is no need to decide between RACF or DB2• You can easily migrate a part of the security checks (= certain RACF classes) to RACF and leave the remainder within

DB2• As already mentioned: as long as your DB2 security definitions are not eliminated, you can easily return to DB2 security by

simply deactivating a part or all of the RACF classes

On the other hand, there are certain general disadvantages when you use RACF security:• Compatibility with other platforms is clearly lost. If you intend to migrate databases to other platforms, the security

implementation must be migrated back from RACF to the target database platform/product• If you use third party solutions with DB2 databases, these products usually only support DB2 internal security. Next to none

of such products incorporate RACF security• Don't forget that if a user has created a view on a table and this user's access to the table is REVOKEd, DB2 will DROP the

respective view (as described in the manuals).

40

Result – The Project View

41

41

Security yesterday

*PLAN/Package authority still DB2

*

RACFDB2

82,753

1,555,418

2.5

0.4

0.02

1.75

3

4

0%

20%

40%

60%

80%

100%

# Profiles Maint EffortFTE

Error Rate % Lead TimeDays

The major goals for this project were to:- Reduce lead times for changes in security profiles- Reduce overall cost of security maintenance- Reduce number of erroneous definitions, which were mainly caused by

- Unclear requests- Missing cleanup processes (= outdated definitions)- Handling errors during definition

42

42

Security today

*PLAN/Package authority still DB2

*

RACFDB2

Benefit

84,207

228,278

1,325,686

2.6

0.050.25

0.020.02

1.73

3

4

0%

20%

40%

60%

80%

100%

# Profiles Maint EffortFTE

Error Rate % Lead TimeDays

With DB2 Security in RACF we achieved:- Heavily reduced number of access profiles

- Reduced complexity- Smaller DB2 catalog- Better overview

- Certain reduction of maintenance efforts- Significantly reduced error rate

- Mainly due to clear standards and predefinition of profiles- Much faster response time to security profile requests

43

43

Customer satisfaction• Reduced error rate

• Standardized Access profiles• Next to no incompatibilities or side effects

• Faster delivery• Access profiles pre-definable• Definition is part of standard delivery processes

• Transparency• Complete view for security and support staff• Allows for documented standards

With RACF security, profile changes are now implemented much faster and at a clearly reduced error rate:- Access profiles are not created individually, but based on specified standards- Definition of the access profiles is integrated into our standard delivery processes

- e.g. when a new project or workarea is requested, access profile creation is one clearly defined step of the definition process

-one can't achieve this with DB2 security, because access to an object can not be defined before the object exists

-The security definition for any DB2 object is at no point in time incorrect or incomplete

- No more requests to our provider for DB2 security definitions. This is clearly specific to our site, but basically true for every site:

- Reduced lead time- Less error prone- Maintenance is less resource intensive

44

44

Smoother daily operations• Comprehensive security environment

• One single tool, one single concept• Complete view• Across system boundaries

• Identical view and behavior• For Security admin and support staff

• Reduced support effort• Faster problem solution

• Security profile spans whole DB2 object lifecycle

No matter what front end tool you use for RACF security administration, you can handle all of it within one single tool: No need to check access to the basic system, file systems, transactions, etc. in a tool different from the one managing DB2 security. It's all the same interface and – even much better – it's all built on identical concepts! It's so much easier to understand this unified view and identical behavior. Which ends up in less errors and reduced maintenance efforts.

All security definitions in one single tool means:- Coordination – obsolete- Multiple definitions – obsolete- Complete view – easy- Specialist know-how for DB2 – obsolete- Maintenance effort – reduced and optimized

The lifecycle of the security profile for an object is independent from the existence of the object itself. It is due to this fact that at no point in time any of your DB2 objects will be unsecured – at least with the interceptor profile. During day-to-day operations, a DBA has so many things to keep in mind – it's very common that certain GRANT tasks slips one's mind (much worse if it was a REVOKE...). These times are by and large gone.

45

45

Ever heard about SOX?SOX?• DB2 internal auditing has certain limitations…

• But:• You can't dodge RACF• RACF writes SMF logs• No need for DB2 auditing?

SOX compliance made easy…

For anybody who has to adhere to SOX (Sarbanes-Oxley Act), Basle II, any many more of these regulations...

Activating the DB2 internal audit feature is a labor intensive task. It also adds considerable CPU usage and maintenance overhead. Plus: Efficient log analysis requires add-on tools.

But worst of all: DB2 audit facility is not beyond all doubt (e.g. only first statement within a UOW is logged, etc.).

Thus we are somewhat sceptical about relying on the DB2 audit feature.

RACF is – fortunately – more sophisticated at auditing. The built-in logging functionality writes to SMF. Data/events/traps to be logged may be configured easily. You would typically implement logging behavior on the level of a RACF profiles. And here, the generic approach again supports you and further reduces the effort. SMF record analysis is straightforward with respective tools.

And RACF logging/auditing behavior is SOX approved. If you use this facility, SOX compliance is much easier to achieve from an infrastructure and tools point of view. This allows you to concentrate on the respective processes and not waste time for technical infrastructure reviews.

46

46

What about runtime?• Runtime considerations

• All checks within one system (exception: PLANs)• No double checking

• DB2 always calls RACF first• probably some overhead

• Number of profiles heavily reduced (by about 80%)• All profiles cached – no physical I/O

• Runtime savings not analyzed• 'Gut feeling' goes towards slight performance benefit• No clear statement

To what concerns performance of the externalized security checks, one might mention pros and cons.

After all, our performance monitoring team clearly did not find evidence for any negative impact on our environment. On the contrary, we think there might be a slight performance benefit (but far from calling it a boost).

As we haven't done in-depth analysis of the effects on the performance side, there is no clear statement. From our point of view, the pros and cons are in balance.

47

47

Project – the efforts…• about 12 months project duration

• 170 days total• AXA Tech: ~125 days (RACF, Org)• Provider: ~45 days (DB2)

• 40% (!) Analysis, 30% Organization, 30% Implementation

• Cash out: $0.00• internal workforce (AXA Tech and provider)• free migration software (RACFDB2)

Initial plans for the project were at 6 months.

But during the analysis phase we recognized several uncertainties which led to in-depth tests and additional efforts. That was the point where it became obvious that the individual infrastructure, tools usage, processes (like change management, deployment, etc.) need to be analyzed seriously to avoid side effects during implementation.

In addition, the migration was slowed down as we started the major upgrade to DB2 v8 in parallel. Today, we would strongly recommend you to separate such large tasks.

Also don't forget to cleanup your SYSIBM.%AUTH catalog tables after the implementation. This relieves the catalog as well as memory buffers and reduces possible uncertainties for people who don't exactly know your environment. (like e.g. the new developers not knowing about your RACF implementation and checking the DB2 catalog tables for their access rights. Their wrong conclusions would certainly generate unnecessary support requests...)

48

48

Project – Challenges…• Organizational: Cooperation

• Internal staff and external provider• Systems people and Application developers• RACF people and DB2 people

• Mentality: Deal with different mindsets• steep learning curve for DB2 and RACF people

• Technical: DB2 behavior with external security• DB2 security <> RACF security• In-depth analysis required

The most pressing problems arose from different backgrounds:• People do not have unlimited capacity

• People in such projects have a different focus and different goals• Developers usually have strict deadlines, etc.• Allow them the time it takes to cope with the situation and learn from each other

• People tend to think and act in certain ways they are used to• Our project allowed (and required) them to work together tightly, which proved to be a challenge of it's own

On the technical side, an in-depth analysis of the DB2 environment is unavoidable. Not only applications are affected, but as well

• Infrastructure (find an alternative for automatic REBIND in DB2, etc.)• SW development (processes, DB2 BIND, GRANT, etc.)• Deployment tools• etc.

49

49

Trapped! – Autorebind• AUTOREBIND mechanism inactive

• -904: the "-551 in disguise"• no automatic REBIND if PLAN/PACKAGE was

invalid due to different behavior• Workaround

• Nightly reBIND of all invalid PLANs/PACKAGEs• Analysis of inoperative PLANs/PACKAGEs

AUTO REBIND MECHANISMDB2 internal security:• If a plan becomes invalidated (DDL changes or other), DB2 performs an auto-REBIND with Owner of Plan or Package

DB2 with RACF security:• The auto-REBIND mechanism is still in place, but the current user's credentials will be used instead of the Plan/Package

owner's • As the current user typically doesn't have the required access right to perform a REBIND, the action fails• The PLAN/PACKAGE stays invalid and will become inoperative due to the failed REBIND request• The job or transaction fails with SQLCODE –904 (unavailable resource) which actually is a "–551 in disguise"

No idea, whether or not IBM will fix this difference in behavior

At our site, we implemented the following workaround:• Nightly REBIND of all invalid PLANs/PACKAGEs• Persisting problems (inoperative PLANs/PACKAGEs) are analyzed regularly

• These usually may occur on outdated objects which no more are aligned with current table definitions (-204 and such)

50

50

Trapped! – IMS• PLAN/PACKAGE security still in DB2

• IMS to DB2 ACEE structure problems• IBM has no plans for enhancement yet

• Workaround• None• Not a big issue

• Transaction security active• Therefore most PLANs are PUBLIC

PLAN/PACKAGE security still in DB2 or "When DB2 cannot provide an ACEE"Sometimes DB2® cannot provide an ACEE. For example, if you do not use external security in CICS® (that is, SEC=NO is

specified in the DFHSIT), CICS does not pass an ACEE to the CICS attachment facility. The ACEE address is passed for CICS transactions, if available.

When DB2 does not have an ACEE, it passes zeros in the XAPLACEE field. If this happens, your routine can return a 4 in the EXPLRC1 field, and let DB2 handle the authorization check.

DB2 does not pass the ACEE address for IMS™ transactions. The ACEE address is passed for CICS transactions, if available.DB2 does pass the ACEE address when it is available for DB2 commands that are issued from a logged on z/OS® console.

DB2 does not pass the ACEE address for DB2 commands that are issued from a console that is not logged on, or for the START DB2 command, or commands issued automatically during DB2 startup.

Parent topic: Considerations for the access control authorization routine (seehttp://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db29.doc.admin/db2z_accesscontrolconsideration.htm)

This topic can be found in: DB2 for z/OS Administration Guide (see http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/topic/com.ibm.db29.doc.pdf/dsnagk10.pdf)

Result for our IMS environment: Plan Security with RACF is not possible. PLAN and PACKAGE security remains within DB2

51

51

Trapped! – StoredProcs• Stored Procedures (WLM) security

• a) DB2 passes wrong UID to RACF• Several DCR and PMR open with IBM

• b) Trouble with Content Manager Admin• CM Admin issues GRANTs from StoProcs

• Workarounds• a) ensure StoredProc Package owner = table owner

• no security check done at all• b) GRANT SYSADM to CM Admin user

There are several issues with Stored Procedures. As we use them scarcely, the problem only arose with the usage of Content Manager which intensely relies on Stored Procedures.

Attention: The parameter 'External Security' which can be defined on stored procedures does not influence it's cooperation with an external security product. It only defines how access to DB2-external resources from within the stored procedure is handled!

DB2 passes wrong UID to RACFFirst problem is, that DB2 passes only the primary user id to RACF – which usually is the wrong one. While with internal

security, DB2 would check the WLM started task owner id, it passes the personal userID of the caller to RACF. RACF checks this user's access rights to the table – which obviously fails and DB2 returns a respective SQLCODE –551. But to ensure maximum confusion, the DB2 error message does not refer to the id of the user that was checked by RACF, but the WLM started task user. Just great! An example:

WLM Started Task Userid = #M1CMWL2 (was granted DBADM on ICMMLSD2, and SYSADM, and has SYSADM rights from RACF). CM Logon Userid is X000001 (which has no explicit or implicit rights on table). For this system, the security exit DSNXRXAC is active and RACF profiles have been defined to protect all DB2 resources. Results:

1. User X000001 cannot access table ICMUT01031001 via Content Manager.2. In the Workload Manager Started Task we see SQLCODE -551, stating userid #M1CMWL2:

DSNT408I SQLCODE = -551, ERROR: #M1CMWL2 DOES NOT HAVE THE PRIVILEGE TO PERFORM OPERATION SELECT ON OBJECT ICMADM2.ICMUT01031001

3. In the System Log we see message ICH408I several times, stating userid X000001: 2006136 10:49:31.55 00000211 ICH408I USER(X000001 ) GROUP(#EXT0001) NAME(MYSELF,ME )00000211 DB2M.ICMADM2.ICMUT01031001.SELECT CL(MDSNTB ) 00000211 INSUFFICIENT ACCESS AUTHORITY 00000211 FROM DB2M.ICMADM*.** (G) 00000211 ACCESS INTENT(READ ) ACCESS ALLOWED(NONE )

Workaround to this problem: set the stored procedure bind owner to the same value as the table owner. With this constellation, DB2 has no reason to perform any more security checks at all as the owner of a table implicitly holds any access rights to the table.

Trouble with Content Manager AdminThe CM Administration tool is used to define new objects and the underlying data structures. When you define such

new objects, CM Admin tools tries to execute a GRANT on them. With externalized security, such requests obviously will fail and as a result, the process within the CM Admin tool stops in error state. Even though GRANTs are not required when external security is in place, the CM Admin tool requires SYSADM authority to perform them. Just because the CM Admin internal processes are designed to work that way. This workaround is far from being a good solution as it exposes the highest level of DB2 system administration authority to a specific applications user. Depending on the environment and/or application, this could produce a serious security flaw. For more information on Stored Procedures, refer to the redbook SG24-7083-00: "DB2 for z/OS Stored Procedures: Through the call and beyond" (http://www.redbooks.ibm.com/redbooks/pdfs/sg247083.pdf), for Security see chapter 7.

52

52

Project Considerations…• Expect differences in DB2 security behavior

• almost identical – but only almost…• Site specific side effects

• Cooperation is a challenge• Be aware of different mindsets• RACF is not easily understood by DB2 people

• and vice versa…• Educate and inform the users ahead of time

• Impact on software development (no GRANT…)

This is just a summary of the previous slides.

For our environment, almost all of the security within RACF worked still the same as with DB2 – but only almost. Few and slight differences led to side effects that were time consuming to deal with. Certain differences in behavior exist and can be overcome. But you need to be aware of them ahead of time. Don't let yourself be surprised and caught by side effects. In the end, it's a security issue – which is always to be taken seriously.

Your project will be a success if:• end users don't even recognize that something has changed• any other user (like your developers, etc.) is informed and educated at the right time to be able to cope with the different

situation

53

53

Conclusion• Major goals achieved

• SecAdmin more transparent, better quality, faster delivery• No 100% solution

• PLAN/Package security still in DB2• More complex than initially expected

• Different behavior of DB2 with external security• Profound knowledge of RACF and DB2 required

• Definitely no walk in the park...• Surprisingly well accepted by SW developers

Even though things became a bit more complicated than we initially had expected, our major goals were successfully achieved.

Nontheless, there is no 100% solution. Of course we would favor PLAN security to be handled by RACF as well. This is currently impossible due to restrictions from IMS-TM. As long as IBM won't provide a solution, we will have to live with this situation.

What also complicated things was the fact that RACF and DB2 security principles are slightly different. At the same time, IBM's DB2 interface to RACF could clearly have been implemented more sophisticatedly; for certain requirements, the functionality is just a bit too basic. On the other hand, it is at least stable and correctly documented. But it advisable to read the documentation instead of just expecting a specific way of how things should behave. Make sure you have the required knowledge.

The change also impacts software developers; in terms of access profile definitions for their end users as well as during the development and deployment processes. Make sure you have them well informed. At our site, the effects were accepted astonishingly well by the developers thanks to well planned information.

54

54

Recommendations• RTFM☺ – carefully!

• Understand differences• Analyze effects on your environment

• The better planned, the faster implemented• Don't try to "just quickly do it" – you'll mess up!

• Avoid "mix and match" approach• Be sure you can assign side effects to source of

change

Know and understand the differences between DB2 internal and RACF security• The conceptual differences may lead to the need of changes in the security profile implementation• The less standardized your access profiles are, the less you will gain in terms of "reduction by generalization"• Side effects are not only possible, but likely to arise• Be sure you "read these friendly manuals" and understand the meaning of their contents!

Thorough planning is vital for this type of project• This is a typical infrastructure project

• The real gains come from standardization• Extensive planning phase is unavoidable

• You won't have a flashing new screen just one day after the project has started• Thus it's not too easy to impress – and convince – nowaday's average managers

• Set your project up accordingly• Don't start it from a DB2 point of view• Involve RACF and infrastructure people – they are used to the topics

Separate this task from other changes to your DB2 environment• Don't plan other major changes in the area of DB2 during the project phase

55

55

The final question…

• Was it worthwhile? • -> Now that it's achieved – YES!

• Would we do it again?

This project has definitely been more challenging than initially expected – full stop.

But: the yields were also clearly higher than initially expected – another full stop.

56

56

Bibliography• DB2 RACF Access Control Module Guide (SC18-7433-00)

http://publib.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/DSNRAJ10/CCONTENTS?DT=20040209111627

• RACF and DB2: Teamed for Securityby Mark Nelson, IBM, ftp://ftp.software.ibm.com/eserver/zseries/zos/racf/pdf/r07_racf_db2_overview.pdf

• ABCs of OS/390 System Programming, Vol. 4 (SG24-5654-00)http://www.redbooks.ibm.com/redbooks/pdfs/sg245654.pdf

• Protect Your Assets Using RACF for Securityby Roger Miller, IBM, ftp://ftp.software.ibm.com/software/db2storedprocedure/db2zos390/techdocs/db2sec1001p.pdf

• RACF DB2 migration toolhttp://www-03.ibm.com/servers/eserver/zseries/zos/racf/racfdb2.html

• Using RACF to Control Access to DB2 Objectsz/Journal, Dec 2003/Jan 2004, by M.Nelson, R.Love, A.Lobo, http://www.zjournal.com/pdfIssue/pdfArticle/nelson%20love%20lobo.pdf

• RACF Query Tool RA/2http://www.racf.ch/ or http://www.racf.ch/Products/RA_2/ra_2.html

The listed books and articles are a good starting point to achieving the goal. The weblinks were accessible in September 2007.

A few more links may be found in the notes of the previous slides.

57

Peter SuhnerAXA Tech Switzerland AG

[email protected]

Thanks for lots of support and help:Max Meier, Security Engineering, eMail: [email protected] Steiner, DB Engineering, eMail: [email protected]

Session H10

Migrating Access Control from DB2 to RACF

Whenever questions arise, don't hesitate to contact me.