Antwort: [DB2-L] z/OS DB2 Security Configuration

Roy Boxwell

Antwort: [DB2-L] z/OS DB2 Security Configuration
Hi!
Some answers to your questions are:-

Q1) Yes they all are. TRACE is often used, RECOVER INDOUBT is only used
when automatic recover does not work and is rarely used, CANCEL THREAD is
often used when JAVA clients do not clean-up properly. All these commands
are ok with SYSCTRL or SYSOPER
Q2) As always "It Depends" but in your case the job to go to V8 (CATMAINT)
must be run with Installation SYSADM nothing else will work
Q3) SYSADM cannot run the CATMAINT job above

However for "normal" DB2 Database Maintenance (REORG, COPY, RUNSTATS etc)
DBADM or SYSCTRL is more than enough.

Roy Boxwell
SOFTWARE ENGINEERING GMBH
-Product Development-
Robert-Stolz-Strasse 5
40470 Duesseldorf/Germany
Tel. +49 (0)211 96149-0
Fax +49 (0)211 96149-35
E-mail [login to unmask email]
Homepage www.seg.de





"Arnold, Kevin" <[login to unmask email]>
Gesendet von: DB2 Data Base Discussion List <[login to unmask email]>
09.12.2005 14:24
Bitte antworten an DB2 Database Discussion list at IDUG


An: [login to unmask email]
Kopie:
Thema: [DB2-L] z/OS DB2 Security Configuration


We have a single, large production DB2 subsystem on z/OS. We also have
about 16 non-production subsystems. Our environment is perhaps somewhat
different than most in that simply reading unauthorized information has
potential for significant impact to our company.

Our DBA's have been SYSADM for the last 15 years. They are responsible
for the application data portion, of course. They did not have any
problem with losing SYSADM as long as they have DBADM over their databases
and appropriate (for our environment) other authorities such as SYSOPR.
The Tech Manager, whose group is responsible for the DB2 software and
overall system performance, is giving me all kinds of grief. He believes
the DBA's should not have access to TRACE, RECOVER INDOUBT, or CANCEL
THREAD because of the potential impact to the overall system performance,
which is the primary means why they have SYSOPR. I am the security
manager - I can't tell someone what their job is but I do feel responsible
for giving people the authority they need to do their job. From my
perspective, he needs to either convince the DBA's to give up these
functions or develop a means of communication with them when these events
happen.

Question 1 - are TRACE, RECOVER INDOUBT, and CANCEL THREAD authorities
typically found in a DBA group?

The Tech Manager has given me other serious problems as well. We agreed
that his people (responsible for one third-party application database,
along with the DB2 software) did not have to have access to the DBA
databases. So I setup a configuration where they basically have SYSCTRL
and DBADM over their databases (DSNDB* and 3rd party), but not SYSADM nor
INSTALL SYSADM. They could get a firecall ID with INSTALL SYSADM from the
security department when needed which would be audited. Well, he went
ballistic (even though it was his idea). He claims that whenever
"maintenance" is done to one of our 17 DB2 subsystems, he must use INSTALL
SYSADM and he can't wait for a firecall. He gave an example of going to
"new function mode" in version 8, which is coming soon. He also says he
would use SYSADM authority to do his normal Monday through Friday 8-5 job
in maintaining the systems and simply having the subset specified here is
not sufficient. I understand that INSTALL SYSADM is needed to gen a new
system or to do a full recovery, but that doesn't happen very often here.

Question 2 - Is "INSTALL SYSADM" specifically needed to do DB2
"maintenance" from a software support perspective? E.g., going to new
function mode

Question 3 - Ditto a regular SYSADM, compared to DBADM over DB2 databases
and SYSCTRL?

I'll be the first to back down if my requests are not reasonable, but I'd
like to know if I'm getting a snow job or not from the Tech's. Thanks in
advance!

Regards,
Kevin
614-224-8204

CONFIDENTIALITY NOTICE: The Ohio Public Employees Retirement System
intends this e-mail message, and any attachments, to be used only by the
person(s) or entity to which it is addressed. This message may contain
confidential and/or legally privileged information. If the reader is not
the intended recipient of this message or an employee or agent responsible
for delivering the message to the intended recipient, you are hereby
notified that you are prohibited from printing, copying, storing,
disseminating or distributing this communication. If you received this
communication in error, please delete it from your computer and notify the
sender by reply e-mail.


---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email]
Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm



---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Raymond Bell

Re: z/OS DB2 Security Configuration
(in response to Roy Boxwell)
Hmmmm... tricky one. I'll try to keep to the facts (Ma'am), as I
understand them.

Question 1 - is trace, etc typically possessed by the DBA group?

You know what's coming, don't you? It depends, only this time it really
does. And what it depends on is what the DBA Group does for a living. If
they're expected to look into performance issues then the ability to start
traces is kinda useful. Likewise if anyone says, 'Hey, look , I fired off
this really stupid MS Query query up to our Prod subsystem and I've
cancelled it, but I think there's probably an ownerless task beavering away
in DB2 that can probably be cancelled too,' then it would be very useful for
the DBA to be able to cancel it. Similar with Recover Indoubt, but I don't
know what specific privilege is required for that (hey, whaddya know,
RECOVER is enough, and they'll definitely want/need that). But to be
honest, bit of a moot point as most of that stuff CICS (or IMS/DC) and DB2
work out for themselves anyway. Basically if they do the function they need
the privilege - no newsflash there. If not then, well, not.

Question 2 - do you need Install Sysadm to do maintenance?

Don't think so - not sure as, like a lot of sites, our 2nd IS ID is an
ACF2/RACF group, with an actual ID as the 1st IS. So the maintenance I've
applied may have needed it, but I doubt it. As long as they've access to
the libraries containing the new maintenance it may be enough. Upgrades
like all the V8 malarkey would quite probably need to be done using an IS ID
but, like you say, that's well-in-advance stuff and they can probably have
the ID for that work at the time. I've worked somewhere that locked down
their Sysadm ID that way - bit of a PITA but you got used to it. Or found
imaginative ways around it, but I didn't say that...

Q3 - I've always (well, 95% of the time) had Sysadm to do my DBA work,
usually because the site isn't mature/anal (strike as appropriate) enough to
be bothered to restrict the access of a person/role they consider key. Not
meant as a dig, incidentally, but usually you either trust your DBAs or you
don't, or have other more pressing security issues to worry about. However,
saying that, I've worked at sites where I've only been responsible for Dev
databases and DBADM (plus a few other odds and sods) has been ample. But
that doesn't stop read (or any other kind of) access to the tables in the DB
- if that's the objective your options are limited i.e. Sysctrl (I think -
never used/had it) or, well, actually I don't know.

Does any of the above help? Or is it just a rant? You decide. Basically
Sysadm is dead handy and is probably the main reason why they want to keep
it.


Raymond Bell
Database Administrator with Wide Ranging Responsibilities (and therefore
Install Sysadm everywhere)

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]On
Behalf Of Arnold, Kevin
Sent: 09 December 2005 13:24
To: [login to unmask email]
Subject: [DB2-L] z/OS DB2 Security Configuration


We have a single, large production DB2 subsystem on z/OS. We also have
about 16 non-production subsystems. Our environment is perhaps somewhat
different than most in that simply reading unauthorized information has
potential for significant impact to our company.

Our DBA's have been SYSADM for the last 15 years. They are responsible for
the application data portion, of course. They did not have any problem with
losing SYSADM as long as they have DBADM over their databases and
appropriate (for our environment) other authorities such as SYSOPR. The
Tech Manager, whose group is responsible for the DB2 software and overall
system performance, is giving me all kinds of grief. He believes the DBA's
should not have access to TRACE, RECOVER INDOUBT, or CANCEL THREAD because
of the potential impact to the overall system performance, which is the
primary means why they have SYSOPR. I am the security manager - I can't
tell someone what their job is but I do feel responsible for giving people
the authority they need to do their job. From my perspective, he needs to
either convince the DBA's to give up these functions or develop a means of
communication with them when these events happen.

Question 1 - are TRACE, RECOVER INDOUBT, and CANCEL THREAD authorities
typically found in a DBA group?

The Tech Manager has given me other serious problems as well. We agreed
that his people (responsible for one third-party application database, along
with the DB2 software) did not have to have access to the DBA databases. So
I setup a configuration where they basically have SYSCTRL and DBADM over
their databases (DSNDB* and 3rd party), but not SYSADM nor INSTALL SYSADM.
They could get a firecall ID with INSTALL SYSADM from the security
department when needed which would be audited. Well, he went ballistic
(even though it was his idea). He claims that whenever "maintenance" is
done to one of our 17 DB2 subsystems, he must use INSTALL SYSADM and he
can't wait for a firecall. He gave an example of going to "new function
mode" in version 8, which is coming soon. He also says he would use SYSADM
authority to do his normal Monday through Friday 8-5 job in maintaining the
systems and simply having the subset specified here is not sufficient. I
understand that INSTALL SYSADM is needed to gen a new system or to do a full
recovery, but that doesn't happen very often here.

Question 2 - Is "INSTALL SYSADM" specifically needed to do DB2 "maintenance"
from a software support perspective? E.g., going to new function mode

Question 3 - Ditto a regular SYSADM, compared to DBADM over DB2 databases
and SYSCTRL?

I'll be the first to back down if my requests are not reasonable, but I'd
like to know if I'm getting a snow job or not from the Tech's. Thanks in
advance!

Regards,
Kevin
614-224-8204

CONFIDENTIALITY NOTICE: The Ohio Public Employees Retirement System intends
this e-mail message, and any attachments, to be used only by the person(s)
or entity to which it is addressed. This message may contain confidential
and/or legally privileged information. If the reader is not the intended
recipient of this message or an employee or agent responsible for delivering
the message to the intended recipient, you are hereby notified that you are
prohibited from printing, copying, storing, disseminating or distributing
this communication. If you received this communication in error, please
delete it from your computer and notify the sender by reply e-mail.


----------------------------------------------------------------------------
-----
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org.
The IDUG List Admins can be reached at [login to unmask email] Find
out the latest on IDUG conferences at http://conferences.idug.org/index.cfm


This e-mail (and any attachments) may contain privileged and/or confidential information. If you are not the intended recipient please do not disclose, copy, distribute, disseminate or take any action in reliance on it. If you have received this message in error please reply and tell us and then delete it. Should you wish to communicate with us by e-mail we cannot guarantee the security of any data outside our own computer systems. For the protection of Legal & General's systems and staff, incoming emails will be automatically scanned.

Any information contained in this message may be subject to applicable terms and conditions and must not be construed as giving investment advice within or outside the United Kingdom.

The following companies are subsidiary companies of the Legal & General Group Plc which are authorised and regulated by the Financial Services Authority for advising and arranging the products shown: Legal & General Partnership Services Limited (insurance and mortgages), Legal & General Insurance Limited (insurance), Legal & General Assurance Society Limited
(life assurance, pensions and investments), Legal & General Unit Trust Managers Limited and Legal & General Portfolio Management Services Limited (investments).

They are registered in England under numbers shown.
The registered office is Temple Court, 11 Queen Victoria Street, London EC4N 4TP.

Legal & General Partnership Services Limited: 5045000 Legal & General Assurance Society Limited: 166055 Legal & General (Unit Trust Managers) Limited: 1009418 Legal & General (Portfolio Management Services) Limited: 2457525 Legal & General Insurance Limited: 423930

They are registered with the Financial Services Authority under numbers shown. You can check this at www.fsa.gov.uk/register

Legal & General Partnership Services Limited: 300792 Legal & General Assurance Society Limited: 117659 Legal & General (Unit Trust Managers) Limited: 119273 Legal & General (Portfolio Management Services) Limited: 146786 Legal & General Insurance Limited: 202050

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Roger Miller

Re: z/OS DB2 Security Configuration
(in response to Raymond Bell)
Raymond has the main points. The key question is the tasks that the
individuals do and the authority needed to do those jobs, as the role of a
DBA can be highly varied. There is always a tension between making
security easy by avoiding it and having very tight security that does not
allow people to do their job. I describe the goal as ease of safe use.

A number of companies are examining their security, as they see more
attempts and more need for disclosure. I presented a session on best
practices in DB2 security at the DB2 Technical Conference, but we seem to
have a glitch on the web, so I'll email it, if you'd like. Here is the
abstract:

This discussion will discuss various practices for security and discuss
how you can make improvements. The discussion includes various
security objectives. Most sites have a range of needs and objectives.
For some situations, basic security is adequate. For others better or
standard security techniques are needed. In other cases, best security
practices are demanded. Our tools range from very tight system security
to basic techniques, applicable with public information on the web.
Application security techniques are more flexible, but require much more
work by more people, so they are generally weaker. Choices and
guidelines will be our primary points, discussing how to provide improved
security.

Roger Miller

On Fri, 9 Dec 2005 15:32:32 -0000, Bell, Raymond <[login to unmask email]>
wrote:

>Hmmmm... tricky one. I'll try to keep to the facts (Ma'am), as I
>understand them.
>
>Question 1 - is trace, etc typically possessed by the DBA group?
>
>You know what's coming, don't you? It depends, only this time it really
>does. And what it depends on is what the DBA Group does for a living. If
>they're expected to look into performance issues then the ability to start
>traces is kinda useful. Likewise if anyone says, 'Hey, look , I fired off
>this really stupid MS Query query up to our Prod subsystem and I've
>cancelled it, but I think there's probably an ownerless task beavering
away
>in DB2 that can probably be cancelled too,' then it would be very useful
for
>the DBA to be able to cancel it. Similar with Recover Indoubt, but I
don't
>know what specific privilege is required for that (hey, whaddya know,
>RECOVER is enough, and they'll definitely want/need that). But to be
>honest, bit of a moot point as most of that stuff CICS (or IMS/DC) and DB2
>work out for themselves anyway. Basically if they do the function they
need
>the privilege - no newsflash there. If not then, well, not.
>
>Question 2 - do you need Install Sysadm to do maintenance?
>
>Don't think so - not sure as, like a lot of sites, our 2nd IS ID is an
>ACF2/RACF group, with an actual ID as the 1st IS. So the maintenance I've
>applied may have needed it, but I doubt it. As long as they've access to
>the libraries containing the new maintenance it may be enough. Upgrades
>like all the V8 malarkey would quite probably need to be done using an IS
ID
>but, like you say, that's well-in-advance stuff and they can probably have
>the ID for that work at the time. I've worked somewhere that locked down
>their Sysadm ID that way - bit of a PITA but you got used to it. Or found
>imaginative ways around it, but I didn't say that...
>
>Q3 - I've always (well, 95% of the time) had Sysadm to do my DBA work,
>usually because the site isn't mature/anal (strike as appropriate) enough
to
>be bothered to restrict the access of a person/role they consider key.
Not
>meant as a dig, incidentally, but usually you either trust your DBAs or
you
>don't, or have other more pressing security issues to worry about.
However,
>saying that, I've worked at sites where I've only been responsible for Dev
>databases and DBADM (plus a few other odds and sods) has been ample. But
>that doesn't stop read (or any other kind of) access to the tables in the
DB
>- if that's the objective your options are limited i.e. Sysctrl (I think -
>never used/had it) or, well, actually I don't know.
>
>Does any of the above help? Or is it just a rant? You decide. Basically
>Sysadm is dead handy and is probably the main reason why they want to keep
>it.
>
>
>Raymond Bell
>Database Administrator with Wide Ranging Responsibilities (and therefore
>Install Sysadm everywhere)
>
>-----Original Message-----
>From: DB2 Data Base Discussion List [mailto:[login to unmask email]On
>Behalf Of Arnold, Kevin
>Sent: 09 December 2005 13:24
>To: [login to unmask email]
>Subject: [DB2-L] z/OS DB2 Security Configuration
>
>
>We have a single, large production DB2 subsystem on z/OS. We also have
>about 16 non-production subsystems. Our environment is perhaps somewhat
>different than most in that simply reading unauthorized information has
>potential for significant impact to our company.
>
>Our DBA's have been SYSADM for the last 15 years. They are responsible
for
>the application data portion, of course. They did not have any problem
with
>losing SYSADM as long as they have DBADM over their databases and
>appropriate (for our environment) other authorities such as SYSOPR. The
>Tech Manager, whose group is responsible for the DB2 software and overall
>system performance, is giving me all kinds of grief. He believes the
DBA's
>should not have access to TRACE, RECOVER INDOUBT, or CANCEL THREAD because
>of the potential impact to the overall system performance, which is the
>primary means why they have SYSOPR. I am the security manager - I can't
>tell someone what their job is but I do feel responsible for giving people
>the authority they need to do their job. From my perspective, he needs to
>either convince the DBA's to give up these functions or develop a means of
>communication with them when these events happen.
>
>Question 1 - are TRACE, RECOVER INDOUBT, and CANCEL THREAD authorities
>typically found in a DBA group?
>
>The Tech Manager has given me other serious problems as well. We agreed
>that his people (responsible for one third-party application database,
along
>with the DB2 software) did not have to have access to the DBA databases.
So
>I setup a configuration where they basically have SYSCTRL and DBADM over
>their databases (DSNDB* and 3rd party), but not SYSADM nor INSTALL SYSADM.
>They could get a firecall ID with INSTALL SYSADM from the security
>department when needed which would be audited. Well, he went ballistic
>(even though it was his idea). He claims that whenever "maintenance" is
>done to one of our 17 DB2 subsystems, he must use INSTALL SYSADM and he
>can't wait for a firecall. He gave an example of going to "new function
>mode" in version 8, which is coming soon. He also says he would use
SYSADM
>authority to do his normal Monday through Friday 8-5 job in maintaining
the
>systems and simply having the subset specified here is not sufficient. I
>understand that INSTALL SYSADM is needed to gen a new system or to do a
full
>recovery, but that doesn't happen very often here.
>
>Question 2 - Is "INSTALL SYSADM" specifically needed to do
DB2 "maintenance"
>from a software support perspective? E.g., going to new function mode
>
>Question 3 - Ditto a regular SYSADM, compared to DBADM over DB2 databases
>and SYSCTRL?
>
>I'll be the first to back down if my requests are not reasonable, but I'd
>like to know if I'm getting a snow job or not from the Tech's. Thanks in
>advance!
>
>Regards,
>Kevin
>614-224-8204
>
>CONFIDENTIALITY NOTICE: The Ohio Public Employees Retirement System
intends
>this e-mail message, and any attachments, to be used only by the person(s)
>or entity to which it is addressed. This message may contain confidential
>and/or legally privileged information. If the reader is not the intended
>recipient of this message or an employee or agent responsible for
delivering
>the message to the intended recipient, you are hereby notified that you
are
>prohibited from printing, copying, storing, disseminating or distributing
>this communication. If you received this communication in error, please
>delete it from your computer and notify the sender by reply e-mail.
>
>
>--------------------------------------------------------------------------
--
>
>This e-mail (and any attachments) may contain privileged and/or
confidential information. If you are not the intended recipient please do
not disclose, copy, distribute, disseminate or take any action in reliance
on it. If you have received this message in error please reply and tell us
and then delete it. Should you wish to communicate with us by e-mail we
cannot guarantee the security of any data outside our own computer
systems. For the protection of Legal & General's systems and staff,
incoming emails will be automatically scanned.
>
>Any information contained in this message may be subject to applicable
terms and conditions and must not be construed as giving investment advice
within or outside the United Kingdom.
>
>The following companies are subsidiary companies of the Legal & General
Group Plc which are authorised and regulated by the Financial Services
Authority for advising and arranging the products shown: Legal & General
Partnership Services Limited (insurance and mortgages), Legal & General
Insurance Limited (insurance), Legal & General Assurance Society Limited
>(life assurance, pensions and investments), Legal & General Unit Trust
Managers Limited and Legal & General Portfolio Management Services Limited
(investments).
>
>They are registered in England under numbers shown.
>The registered office is Temple Court, 11 Queen Victoria Street, London
EC4N 4TP.
>
>Legal & General Partnership Services Limited: 5045000 Legal & General
Assurance Society Limited: 166055 Legal & General (Unit Trust Managers)
Limited: 1009418 Legal & General (Portfolio Management Services) Limited:
2457525 Legal & General Insurance Limited: 423930
>
>They are registered with the Financial Services Authority under numbers
shown. You can check this at www.fsa.gov.uk/register
>
>Legal & General Partnership Services Limited: 300792 Legal & General
Assurance Society Limited: 117659 Legal & General (Unit Trust Managers)
Limited: 119273 Legal & General (Portfolio Management Services) Limited:
146786 Legal & General Insurance Limited: 202050
>

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm