5. IBM IOD 2012 6/22/2016
4
We face numerous security challenges as technology gets better and industry
regulation continues to increase. Auditing is continuing to apply more pressure to
restrict or limit who has DB2 elevated privileges. This means we have to find new
ways to address some of these new challenges.
At Nationwide we used a RACI document to clearly outline and define Roles and
Responsibilities between the DB2 Engineer, DB2 DBA, Data Modeler, and the
Performance Team. This presented Nationwide with some challenges.
2418 Tilkes Pickel.ppt
6. IBM IOD 2012 6/22/2016
5
There are several methods that can be used to allow DBAs to manage DB2 objects
they are not the owner. One is create a RACF group the same as the owner and
add the DBAs IDs to that group. Problem solved right. Here are the issues with
that one someone from another area could request access to that RACF Group.
That never happens right. As all of you are aware the owner of the object has all
DB2 privileges to that object. The second option is with the of a Trusted Context
with an external security profile.
How do we control when the batch scheduling tool has SYSADM access. For this
example we will use a Trusted Context with an assigned Role.
So What is a Trusted Context and Roles?
2418 Tilkes Pickel.ppt
8. IBM IOD 2012 6/22/2016
7
A trusted context establishes a trusted relationship between DB2 and an external
entity, such as a middleware server or another DB2 subsystem. At connection time,
a series of trust attributes are evaluated to determine if a specific context can be
trusted. After a trusted connection is established, it is possible to acquire, through
a role, a special set of privileges for a DB2 authorization ID within the specific
connection that are not available to it outside of the trusted connection.
When defining a Trusted Context the connection attributes must be unique within
the trusted context definition. What I mean is, you are not able to have the an
ADDRESS, JOBNAME, or SERVAUTH the same value in single trusted context
definition.
Minimum DB2 Authority need to define a Trusted Context is INSTALL SYSADM,
SYSADM, or SECADM (Not available until DB2 version 10)
A trusted connection can be established for a local or a remote application. The
attributes used to establish a trusted context are different for remote vs local
applications. The two examples we will be looking at today will both be referencing
local applications using the connection attribute of JOBNAME
2418 Tilkes Pickel.ppt
9. IBM IOD 2012 6/22/2016
8
Any ID that is the owner of an object or has grant authority can grant privileges to a
Role. However to create a Role you must be either INSTALL SYSADM, SYSADM,
SYSCTRL, or SECADM. (Not available until DB2 version 10)
A Role must be associated with a Trusted Context in order to be used.
For more information about Trusted Context and Roles please refer to IBM
Redbook: Securing DB2 and Implementing MLS on z/OS or IBM Redbook: Security
Functions of IBM DB2 10 for z/OS
Now that we know what Trusted Context and Roles are let's explore the two
different opportunities we have to exploit them.
2418 Tilkes Pickel.ppt
11. IBM IOD 2012 6/22/2016
10
Contact your Security Admin and have them create DSNR Class TRUSTEDCTX.DBA.
Then have the Security Admin Grant READ access to users/group that needs to
have access to use DSNR class. Create Protected IDs of the object Owners that you
desire to have the DBAs to be able to manage.
For Views the issue was, how do we allow the DBAs to control access to those
views, and the DBAs needed to have the ability to ALTER the view if needed.
Issues with Aliases was the DBAs could create them, but could not DROP them.
How do you allow the DBA to control access to Packages and Plans.
Now that we have the external security profile in place let's move on and create
the trusted context.
REMEMBER this method allows them to act as the OWNER, and as the owner of an
object they have all privileges to that object.
2418 Tilkes Pickel.ppt
12. IBM IOD 2012 6/22/2016
11
For this example we have a primary user ID of DBAUSR1 with access to an external
security profile of TRUSTEDCTX.DBA through READ access being granted to group
DBAGRP1. We want DBAUSR1 to have access to object owner SAMPID1 in order to
execute the ALTER View regenerate statement on View SAMPID1.EMP_PHONE.
They also only want the DBA to have access only if it is running under specific job
prefixes.
The name of the Trusted Context that is being created is DBA_DBAUSR1
The first job name on the attributes line allow the user to use SPUFI as well as any
batch job prefixed with their ID, and connect using the ASUSER option. The second
job name on the attributes line allow them to use a batch job that begins with a
prefix of DBAT. As long as the batch job is connected with DBAT prefix then the
user can code the ASUSER clause in their connection options.
Now let’s go learn how to use the AS USER clause in SPUFI and Batch to utilize the
Trusted Context we created above.
2418 Tilkes Pickel.ppt
13. IBM IOD 2012 6/22/2016
12
Once I set the AS USER option (OPTION # 10) to SAMPID1. I then hit enter until you
get back to the DB2I PRIMARY OPTION MENU.
Then select SPUFI and enter in the following statement.
ALTER VIEW SAMPID1.EMP_PHONE REGENERATE;
It should execute successfully since the as user option was set to SAMPID1. Where
as if the as user option is not set the above statement will fail provide you have not
been grant SYSADM access.
The reason this works is DBAUSR1 has read access to DSNR Class TRUSTEDCTX.DBA
, SAMPID1 also has read access to DSNR Class, and trusted connection has been
established through Trusted Context DBA.DBAUSR1. This allows DBAUSR1 to use
the as user in their connection string. In doing so DBAUSR1 makes them appear to
DB2 as SAMPID1.
This is similar to what you would do if you executed a SET CURRENT SQLID. The
difference in a SET CURRENT SQLID, you either have to be SYSADM or SAMPID1
would have to be a RACF Group with DBAUSR1 attached. By using the trusted
context concept you limit the opportunity for access to your DB2 objects. Even if
someone would get read access to the DSNR Class TRUSTEDCTX.DBA, the user still
would have to have Trusted Context definition in DB2 related to their Auth ID to
gain access.
2418 Tilkes Pickel.ppt
14. IBM IOD 2012 6/22/2016
13
If the DBA (DBAUSR1) would attempt to execute the ALTER VIEW REGENERATE
without the ASUSER clause a failure would occur stating they do not have the
authority to execute the alter on view.
As a result of the ASUSER clause being coded, provided a trusted connection has
been established, and the owner of the view has been given READ access to DSNR
Class TRUSTEDCTX.DBA
2418 Tilkes Pickel.ppt
17. IBM IOD 2012 6/22/2016
16
SCHID1 is an authorization ID associated to your batch scheduling tool that is the
submitter of all your DB2 system maintenance jobs.
Creating the trusted context allows the scheduling tool to have SYSADM access to
run the DB2 SYSTEM maintenance jobs only for Auth ID SCHID1 and only for job
names that are prefixed in the attributes of the trusted context.
Jobs submitted by the batch scheduling tool under a different Auth ID or other than
a job names listed above will not get assigned the ROLE DB2SYSENG, thus the Auth
ID will not get assigned SYSADM access to DB2.
2418 Tilkes Pickel.ppt
18. IBM IOD 2012 6/22/2016
17172418 Tilkes Pickel.ppt
