DB2 internal security to RACF Access control

Mohamed Esmael

DB2 internal security to RACF Access control

Hello,
We are at z/OS V 2.2 and DB2 v.10  and I've been given the task to do some research for answering the following question:
is the conversion of DB2 internal security to RACF indeed an enhancement of the overall security?
Can anyone, who already converted their DB2 security to RACF, tell me
what their major considerations were to decide to this conversion and what are the major advantages and disadvantages?


kevin arnold

RE: DB2 internal security to RACF Access control
(in response to Mohamed Esmael)

We did this several years ago - I wouldn't go back.

It it an enhancement?  Absolutely.  If you delete/revoke a RACF user-ID, if the DB2 authorities are within RACF all of the authorities go with it.  If the authorities are in DB2, these authorities become orphaned (and often left forever) unless someone manually removes them.  Removing authorities runs the risks associated with the "cascade effect" - so a RACF conversion gets rid of that too.  Plus, with RACF you can establish the security for objects BEFORE they exist in DB2 - not true if using native DB2 security controls.  

Major advantages:

  • Eliminate cascade effect
  • Pre-stage security rules before objects exist
  • Minimal knowledge of DB2 needed by your RACF admins - although, some is needed, but not to a DBA-level
  • If using automated tools to maintain RACF security like most shops do, it saves a decent amount of manpower as it is simply easier to maintain

Disadvantages:

  • Just one I can think of - the conversion effort can be significant.  You will need DBA's/RACF admins.  And if your RACF admins don't have DB2 basics they will need some training (but not a lot).  IBM does have a "conversion tool" but it takes a good amount of desk-checking.  We have 7 (or so) non-production regions and 1 production - it took perhaps 12 months for the better part of 2 people, plus a part-time DBA.  

In my opinion, the benefits outweigh the risks significantly.

 

Kevin

CISO

OPERS

Mohamed Esmael

RE: DB2 internal security to RACF Access control
(in response to kevin arnold)

Thanks Kevin for your reply and i want to ask you about two things 

1- for now we test DB2 internal security and no problem with us tell now except when we try to create trusted context and role to enable RACF group to be SECADM as parameter in Zparam , the error code is  (DB2 SQL Error: SQLCODE=-601, SQLSTATE=42710, SQLERRMC=SEC_TEAM1;CONTEXT, DRIVER=4.17.30)

2- when i try to read on migrate from DB2 internal security to RACF security i found that i must change on 

[login to unmask email] default exit routine for connections,

[login to unmask email]  default exit routine for sign-ons

which found on DSNXRXAC member on SDSNAMP library 

My Question if i do that on Develop environment , the people that already working can still working or not also i don't have experience knowledge on Exit routines  as i read that from RACF Access Control Module Guide

kevin arnold

RE: DB2 internal security to RACF Access control
(in response to Mohamed Esmael)

Mohamed - it's been about 10 years, so I am going through some of my doc.

1. As far as the -601, I just did a GOOGLE - seems to indicate something about a duplicate object.  I'm not sure what command gave you this result.  I want to choose my words carefully - when I hear "Trusted Context" in a DB2 sense, I am thinking of something completely different than RACF security - I am thinking about source of dynamic SQL statements.  We have not implemented Trusted Context in DB2 yet.  You should be able to define SECADM with the appropriate DSNPARM changes.  Note that while we defined RACF rules, we put them in WARN mode (after the RACF classes were made ACTIVE) until we were ready for RACF to take full control - but this was later in the effort, after rules were created based upon the IBM conversion utility.

2.  Yes, you use the default DSN3 exit routines.  It is not necessary to change these to use RACF, as I recall.

Pay close attention to the [login to unmask email] exit however - see chapter 1 of the RACF ACCESS CONTROL MODULE GUIDE FOR DB2 - dsnran02.pdf.

Kevin

Peter Vanroose

Re: DB2 internal security to RACF Access control
(in response to Mohamed Esmael)

Actually the most recent version of the "RACF with DB2 11" Guide is now the 05 instead of the 02: http://publibfp.dhe.ibm.com/epubs/pdf/dsnran05.pdf
(Minimal changes, I suppose.)

--      Peter Vanroose
        ABIS Training & Consulting,
        Leuven, Belgium.
        http://www.abis.be/

Mohamed Esmael

RE: DB2 internal security to RACF Access control
(in response to kevin arnold)

Kevin , Also thanks for your reply i want to told you that we test the both ways (internal and external security)  as i say before  

1- for trusted context , i apply the appropriate changes DSNZPARM changes and also not working 

2- how i can i use default DSN3 exit routines to be able to use RACF External security

3- what the impact of using DSN3 exit routines and is there any rollback scenario   

Jorge Martelanz

RE: DB2 internal security to RACF Access control
(in response to Mohamed Esmael)

Mohammed

One important thing to consider when migrating from DB2 internal security to RACF is: DB2 security is discrete to the DB2 object, and in RACF the permissions can be generic. Let me explain.

If you have tables

PROD.A001

PROD.A002

PROD.A003

If you need to grant SELECT access to these tables to user XYZ, you need to

GRANT SELECT ON PROD.A001 TO XYZ;

GRANT SELECT ON PROD,A002 TO XYZ;

GRANT SELECT ON PROD.A003 TO XYZ;

If the security is controlled by RACF you can define a profile in the proper table class in RACF for PROD.A00* and then permit user XYZ to that class.

Using generic or discrete profiles depends on how data is structured in your installation.

RACF also gives you the possibility of having group profiles (think of a container of several DB2 objects that can be managed as a group for assigning authorities)

The problem is all of these things can coexistst, and can become an administration nightmare for RACF if not well planned from the begining.

The tool IBM provides is a REXX exec that generates RACF commands from the DB2 catalog auth tables. All the commands generated are discrete, and perhaps that is not the best solution for you.

Hope this helps

Jorge Martelanz

Mohamed Esmael

RE: DB2 internal security to RACF Access control
(in response to Jorge Martelanz)

Thanks Jorge for your kindly help 

i know that it's one from advantages of using RACF Access control but also there is some consideration of using RACF Access control 

kevin arnold

RE: DB2 internal security to RACF Access control
(in response to Mohamed Esmael)

Mohamed,

As I recall, you continue to use the default DSN3 exits.  You need to put in the [login to unmask email] exit and set up that mcro accordingly.

You also need to activate the RACF classes - you may want to use WARN mode initially or something else until you are sure of your rules.

The rollback is to undo the above.

And what Jorge said is accurate - the conversion utility will read the DB2 database and create DISCRETE RACF profiles - you more than likely don't really want that.  A lot of desk-checking would be a good first step trying to determine exactly how specific you want your ruleset to be.

Kevin


In Reply to Mohamed Esmael:

Kevin , Also thanks for your reply i want to told you that we test the both ways (internal and external security)  as i say before  

1- for trusted context , i apply the appropriate changes DSNZPARM changes and also not working 

2- how i can i use default DSN3 exit routines to be able to use RACF External security

3- what the impact of using DSN3 exit routines and is there any rollback scenario   

Meir Zohar

DB2 internal security to RACF Access control
(in response to kevin arnold)
One more thing to consider is that the actual security check is done by DB2 and cached, so that if you remove an authorization under RACF, it will take some time to propogate to DB2.
You can work around this by running GRANT/REVOKE on the resource. This issue resolves under v11.
Meir Zohar
On 28 Jun 2017 15:20, kevin arnold <[login to unmask email]> wrote:

Mohamed,
As I recall, you continue to use the default DSN3 exits.  You need to put in the [login to unmask email] exit and set up that mcro accordingly.
You also need to activate the RACF classes - you may want to use WARN mode initially or something else until you are sure of your rules.
The rollback is to undo the above.
And what Jorge said is accurate - the conversion utility will read the DB2 database and create DISCRETE RACF profiles - you more than likely don't really want that.  A lot of desk-checking would be a good first step trying to determine exactly how specific you want your ruleset to be.
Kevin

In Reply to Mohamed Esmael:
Kevin , Also thanks for your reply i want to told you that we test the both ways (internal and external security)  as i say before  
1- for trusted context , i apply the appropriate changes DSNZPARM changes and also not working 
2- how i can i use default DSN3 exit routines to be able to use RACF External security
3- what the impact of using DSN3 exit routines and is there any rollback scenario   
Site Links: View post online   View mailing list online   Start new thread via email   Unsubscribe from this mailing list   Manage your subscription  

This email has been sent to: [login to unmask email]
Setup a data refresh task in less time than it takes to make a cup of coffee + save up to 90% in CPU
ESAi's BCV5 & XDM fast data refresh & Test Data Mgmt products will make you a hero to users. See
ttp://www.ESAIGroup.com/idug


Use of this email content is governed by the terms of service at:
http://www.idug.org/p/cm/ld/fid=2

Mohamed Esmael

RE: DB2 internal security to RACF Access control
(in response to kevin arnold)

hello kevin 

Sorry for bothering you again , i want to ask when i move to RACF Access control

1- is the catalog tables will be migrated to RACF classes and how ?

2- shall i use default classes or use DB2 to RACF Migration utility ?

Note:- i know when i use DB2 to RACF Migration utility , the catalog tables will be migrated 

Peter Vanroose

Re: DB2 internal security to RACF Access control
(in response to Mohamed Esmael)

IMHO, there are two use cases:

1) You are satisfied with the current authorizations in DB2
      => in that case, definitely use the migration utility!

2) You want to start from scratch with a clean set of authorizations, fully taking advantage of RACF's wildcarding possibilities
      => in that case, just create RACF profiles manually, and then perform thorough testing (first while keeping the DB2 catalog entries, next after removing them)

 

--      Peter Vanroose
        ABIS Training & Consulting,
        Leuven, Belgium.
        http://www.abis.be/


In Reply to Mohamed Esmael:

1- is the catalog tables will be migrated to RACF classes and how ?

2- shall i use default classes or use DB2 to RACF Migration utility ?

Note:- i know when i use DB2 to RACF Migration utility , the catalog tables will be migrated

Mohamed Esmael

Re: DB2 internal security to RACF Access control
(in response to Peter Vanroose)

Thanks for your reply 

Also i want to know the steps to rollback to DB2 internal security 

kevin arnold

Re: DB2 internal security to RACF Access control
(in response to Mohamed Esmael)

Look at https://www.ibm.com/support/knowledgecenter/en/SSEPEK_11.0.0/seca/src/tpc/db2z_accesscontrolexitroutine.html

It's been a while since I've been into the details of the [login to unmask email] macro but I believe this is where you tell DB2 to use either the internal catalog security for security, or to use RACF.

Kevin

Mohamed Esmael

Re: DB2 internal security to RACF Access control
(in response to kevin arnold)

Kevin

thanks again for your usual support

Another , if i worked for while on RACF Access control and then turn back to DB2 internal security .. is actions done by RACF still affected or i will do it again  

Peter Vanroose

Re: DB2 internal security to RACF Access control
(in response to Mohamed Esmael)

Your RACF profiles remain intact (and can even be further modified) while DB2 is not contacting RACF for authorization checking.

In Reply to Mohamed Esmael:

if i worked for while on RACF Access control and then turn back to DB2 internal security .. is actions done by RACF still affected or i will do it again 

--      Peter Vanroose
        ABIS Training & Consulting,
        Leuven, Belgium.
        http://www.abis.be/

Mohamed Esmael

Re: DB2 internal security to RACF Access control
(in response to Peter Vanroose)

i know the authorization will be done from DB2 ..

i mean by actions for example    permit user 1 to Access resources or gain privileges  

so that will remain after i turned back to DB2 internal security ? 

Peter Vanroose

Re: DB2 internal security to RACF Access control
(in response to Mohamed Esmael)

In that case -- no.  If you modify RACF profiles, and next switch back to DB2 internal security, you'll just have you "old" catalog-based authorisations.

RACF's way of granting and revoking is broader than DB2's internal one (e.g.: wildcards, and combinations of grants and revokes), so there is no automatic way to convert a set of RACF rules to DB2 internal grants.

In Reply to Mohamed Esmael:

i know the authorization will be done from DB2 ..
i mean by actions for example    permit user 1 to Access resources or gain privileges  so that will remain after i turned back to DB2 internal security ?

--      Peter Vanroose
        ABIS Training & Consulting,
        Leuven, Belgium.
        http://www.abis.be/

Mohamed Esmael

Re: DB2 internal security to RACF Access control
(in response to Peter Vanroose)

Dear Peter 

I have another question about Defining Classes for objects on RACF Access Control that why we if we ant to define only class , that class must begin with M Not G 

Pete Suhner

Re: DB2 internal security to RACF Access control
(in response to Mohamed Esmael)

Hi Mohamed,

the G (Grouping Classes) and M (Member Classes) support different concepts for the implementation of access profiles. You will find a presentation on the topic on IDUG.org (http://www.idug.org/p/do/sd/topic=91&sid=3004), with Slide 10 showing the difference of these approaches. I just realize that it is also available in video format (http://www.idug.org/p/do/sd/topic=79&sid=898). However, this one misses the nice comparison slide between grouping and member classes.

The presentations are not very recent, but still valid in terms of these concepts.

 

Hope this helps,


Best regards,

Pete Suhner
IDUG Board of Directors
IBM Champion for Analytics

Mohamed Esmael

Re: DB2 internal security to RACF Access control
(in response to Pete Suhner)

Thanks for your reply 

Also I want to ask how to install RACF DB2 tool for migration Catalog tables