[Db2 z/OS V11][ACF2] Using BINDAGENT to separate the BIND userid from table access

Philip Sevetson

[Db2 z/OS V11][ACF2] Using BINDAGENT to separate the BIND userid from table access
**please note my email address change**
All,

I haven't had to create a production BIND protocol since BINDAGENT was added, which I think is about the same time they added Packages, some time in the 1990's. So, would someone tell me if I have this right? I'm trying to arrange the BIND process so that people who have the power to execute BIND PACKAGE do not thereafter have any ability to execute dynamic SQL, outside of the bound programs, against the tables used in the bound programs or any other schema which I don't deliberately give them.


1) Assume that we wish to use a privilege set defined as the Sel/Ins/Upd/Del privileges which are needed to do your group's work (PRODQUAL.*), and the SQLID which has those privileges is 'BINDMSTR'. 'BINDMSTR' has no TSO UserID associated and therefore cannot be logged on to or associated through ACF2.

2) Assume that a secondary AuthID (RACF Group, for those of you who use that product) is newly created, without privileges except as described here, and named 'BINDAGNT'.

Then:

3) GRANT CREATE IN NEEDED_PROD_COLLECTION TO BINDMSTR;

4) SET CURRENT SQLID = 'BINDMSTR';

5) GRANT BINDAGENT WITHOUT DATA ACCESS TO BINDAGNT;

6) In ACF2, associate members of the team who will BIND, to the secondary AuthID (so that they can specify it as OWNER in the BIND statement and/or specify it as USER= on the z/OS JOB statement).

7) I think we're done. Team members with association to the secondary AuthID now have the ability to submit BIND jobs which reference the tables/privileges in (1) above.

Important Question: ****Have I done this right?****

I want users associated with BINDAGNT to be able to BIND PACKAGE(NEEDED_PROD_COLLECTION) MEMBER(NEWMEMBR) OWNER(BINDMSTR) QUALIFIER(PRODQUAL) and so forth. Can this setup produce that capability?

Philip Sevetson
Computer Systems Manager
5 Manhattan West (33rd St at 10th Ave)
New York, NY 10001-2632
212-857-1688 w
917-991-7052 c
212-857-1659 f
[cid:[login to unmask email]

**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**
Attachments

  • image001.png (3.3k)

James Campbell

[Db2 z/OS V11][ACF2] Using BINDAGENT to separate the BIND userid from table access
(in response to Philip Sevetson)
3) PACKADM might be better. Consider the situation if another id (apart from BINDMSTR)
is the owner of a package NEEDED_PROD_COLLECTION.FOO; do you want BINDMSTR
to be able to create a replacement NEEDED_PROD_COLLECTION.FOO ?

5) BINDAGENT doesn't have a "WITHOUT DATA ACCESS" option. Because it doesn't
allow any data access - the data access is provided by whatever is allowing the agency.

But do remember that BINDAGENT is not considered a security facility - only a separation
of duties facility. A user with Bindagent could bind their own programs to allow access to
the tables.

BIND PACKAGE(NEEDED_PROD_COLLECTION) MEMBER(<package for DSNTEP2>)
OWNER(BINDMSTR) DYNAMICRULES(BIND)

and

RUN PROGRAM(DSNTEP2) PLAN(PRODPLAN)

and off they go

6) z/OS JOB statement USER=BINDMSTR would require BINDMSTR to exist as a (in your
case) ACF/2 Logon ID. You could create BINDMSTR is a LID, but without the ability to be
used as a TSO ID, and use the ACF/2 equivalent of RACF Surrogate to allow people to
submit jobs with USER=BINDMSTR.

I presume that ACF/2 doesn't stop you having a LID that is the same as a Source - if that is
what you are using to create the secondary auth ids.

But apart from that, yes.

James Campbell



On 30 Oct 2017 at 18:46, Sevetson, Phil wrote:

>
> **please note my email address change**
> All,
>  
> I haven´t had to create a production BIND protocol since BINDAGENT was added, which I think is
> about the same time they added Packages, some time in the 1990´s.  So, would someone tell me if
> I have this right?  I´m trying to arrange the BIND process so that people who have the power to
> execute BIND PACKAGE do not thereafter have any ability to execute dynamic SQL, outside of
> the bound programs, against the tables used in the bound programs or any other schema which I
> don´t deliberately give them.
>  
> 1)     Assume that we wish to use a privilege set defined as the Sel/Ins/Upd/Del privileges which
> are needed to do your group´s work (PRODQUAL.*), and the SQLID which has those
> privileges is 'BINDMSTR'. 'BINDMSTR' has no TSO UserID associated and therefore
> cannot be logged on to or associated through ACF2.
> 2)     Assume that a secondary AuthID (RACF Group, for those of you who use that product) is
> newly created, without privileges except as described here, and named 'BINDAGNT'.
>  
> Then:
> 3)     GRANT CREATE IN NEEDED_PROD_COLLECTION TO BINDMSTR;
> 4)     SET CURRENT SQLID = 'BINDMSTR';
> 5)     GRANT BINDAGENT WITHOUT DATA ACCESS TO BINDAGNT;
> 6)     In ACF2, associate members of the team who will BIND, to the secondary AuthID (so that
> they can specify it as OWNER in the BIND statement and/or specify it as USER= on the
> z/OS JOB statement).
> 7)     I think we´re done. Team members with association to the secondary AuthID now have the
> ability to submit BIND jobs which reference the tables/privileges in (1) above.
>  
> Important Question: ****Have I done this right?**** 
>  
> I want users associated with BINDAGNT to be able to BIND
> PACKAGE(NEEDED_PROD_COLLECTION) MEMBER(NEWMEMBR) OWNER(BINDMSTR)
> QUALIFIER(PRODQUAL) and so forth.  Can this setup produce that capability?
>  
> Philip Sevetson

Philip Sevetson

[Db2 z/OS V11][ACF2] Using BINDAGENT to separate the BIND userid from table access
(in response to James Campbell)
**please note my email address change**
James,

3) In re the PACKADM versus CREATE IN privileges; the situation which concerns you is actually not one of the likely occurrences because of our limited permissions in Production. Our SYSADMs do not normally BIND PACKAGE except by resubmitting a job which will use the BINDAGNT UserID, and no one else has the ability to BIND in the Production packages. Nonetheless, we'll be kicking it around when the DBA who owns this project gets back into the office tomorrow. Thanks.

5) Good point about WITHOUT DATAACCESS - sorry, looks like I read through the syntax diagram more than a bit too fast...
BINDAGENT can, I know (and as you've said) BIND anything, including programs which the employee/user writes, so it's not an ideal situation. However, it eliminates the submitter's ability to run dynamic SQL outside of a static plan, which we think is a useful restriction. I'll note the possible use of the DSNTEP2 (and DSNTIAUL) programs in prod packages. We'll add it to the audit reporting. I believe there's a proposal to make sure that our code repository checkin timestamps are close to our BIND timestamps. Not sure what more we can do.

6) USER=BINDMSTR (Or more precisely, OWNER=BINDMSTR) is my mistake (ANOTHER of my mistakes...). I should have said, and meant to say, USER=(UserID associated with BINDAGNT), which I _think_ solves the problem.

Philip Sevetson
Computer Systems Manager
5 Manhattan West (33rd St at 10th Ave)
New York, NY 10001-2632
212-857-1688 w
917-991-7052 c
212-857-1659 f
[cid:[login to unmask email]

From: James Campbell [mailto:[login to unmask email]
Sent: Monday, October 30, 2017 10:41 PM
To: [login to unmask email]
Subject: [DB2-L] - RE: [Db2 z/OS V11][ACF2] Using BINDAGENT to separate the BIND userid from table access

3) PACKADM might be better. Consider the situation if another id (apart from BINDMSTR) is the owner of a package NEEDED_PROD_COLLECTION.FOO; do you want BINDMSTR to be able to create a replacement NEEDED_PROD_COLLECTION.FOO ?

5) BINDAGENT doesn't have a "WITHOUT DATA ACCESS" option. Because it doesn't allow any data access - the data access is provided by whatever is allowing the agency.

But do remember that BINDAGENT is not considered a security facility - only a separation of duties facility. A user with Bindagent could bind their own programs to allow access to the tables.

BIND PACKAGE( NEEDED_PROD_COLLECTION) MEMBER(<package for DSNTEP2>) OWNER(BINDMSTR) DYNAMICRULES(BIND)

and

RUN PROGRAM(DSNTEP2) PLAN(PRODPLAN)

and off they go

6) z/OS JOB statement USER=BINDMSTR would require BINDMSTR to exist as a (in your case) ACF/2 Logon ID. You could create BINDMSTR is a LID, but without the ability to be used as a TSO ID, and use the ACF/2 equivalent of RACF Surrogate to allow people to submit jobs with USER=BINDMSTR.

I presume that ACF/2 doesn't stop you having a LID that is the same as a Source - if that is what you are using to create the secondary auth ids.

But apart from that, yes.

James Campbell



On 30 Oct 2017 at 18:46, Sevetson, Phil wrote:

>
> **please note my email address change**
> All,
>
> I haven't had to create a production BIND protocol since BINDAGENT was added, which I think is
> about the same time they added Packages, some time in the 1990's. So, would someone tell me if
> I have this right? I'm trying to arrange the BIND process so that people who have the power to
> execute BIND PACKAGE do not thereafter have any ability to execute dynamic SQL, outside of
> the bound programs, against the tables used in the bound programs or any other schema which I
> don't deliberately give them.
>
> 1) Assume that we wish to use a privilege set defined as the Sel/Ins/Upd/Del privileges which
> are needed to do your group's work (PRODQUAL.*), and the SQLID which has those
> privileges is 'BINDMSTR'. 'BINDMSTR' has no TSO UserID associated and therefore
> cannot be logged on to or associated through ACF2.
> 2) Assume that a secondary AuthID (RACF Group, for those of you who use that product) is
> newly created, without privileges except as described here, and named 'BINDAGNT'.
>
> Then:
> 3) GRANT CREATE IN NEEDED_PROD_COLLECTION TO BINDMSTR;
> 4) SET CURRENT SQLID = 'BINDMSTR';
> 5) GRANT BINDAGENT WITHOUT DATA ACCESS TO BINDAGNT;
> 6) In ACF2, associate members of the team who will BIND, to the secondary AuthID (so that
> they can specify it as OWNER in the BIND statement and/or specify it as USER= on the
> z/OS JOB statement).
> 7) I think we're done. Team members with association to the secondary AuthID now have the
> ability to submit BIND jobs which reference the tables/privileges in (1) above.
>
> Important Question: ****Have I done this right?****
>
> I want users associated with BINDAGNT to be able to BIND
> PACKAGE(NEEDED_PROD_COLLECTION) MEMBER(NEWMEMBR) OWNER(BINDMSTR)
> QUALIFIER(PRODQUAL) and so forth. Can this setup produce that capability?
>
> Philip Sevetson

-----End Original Message-----
**This e-mail, including any attachments, may be confidential, privileged, or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy, or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.**
Attachments

  • image001.png (3.3k)