DB2CC Security Concerns

Kevin Arnold

DB2CC Security Concerns
First of all, I'm a security guy not a DBA (so don't use
Hello,

First of all, I'm a security guy not a DBA (so don't use any big words, ok? :-) ). We are trying to find alternatives to using a Windows local DB2ADMIN on both workstations and UDB servers (v8.x) for the sake of DB2 Control Center. When DB2CC is installed, it creates a local user and group that has tremendous authorities (local admin, act as part of the operating system, run as service, etc.). Our DBA's tell us that "they HAVE to user this specific user-ID to do their job". OK, let's dig down in that statement a bit.

I would like to give the DBA's the appropriate authorities on both the workstation and UDB servers to do their job - but through their normal user-ID, not DB2ADMIN. It seems this would be easy enough to do via Group Policy. I'm a big believer in giving people the necessary authority to do their job, so I'm trying to define what is appropriate.

As a start to this, does anyone see a reason I could not give the DBA's real domain user-ID the same authorities as the current DB2ADMIN on the UDB servers? And if their domain account is in the local DB2ADMNS group, I also don't see any reason why the local DB2ADMIN account shouldn't be disabled altogether? Those of you who have done the Sarbanes road concerning generic user-ID's have certainly gone through this before me. Exactly what authorities does a DBA need on a v8.x UDB server? Or workstation running Control Center? We have z/OS databases and a handful of server-based databases as well. The majority of DB2CC users use it for remote database access.

Thoughts on how to approach this? Thanks.

Regards,
Kevin Arnold
Manager, IT Security
OPERS
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

Dan Tuck

Re: DB2CC Security Concerns
(in response to Kevin Arnold)
In our shop, our individual userid is a member of a DB2 SYSADMIN group.
This allows us the required privileges while not using the generic ID. This
seems to work on Windows and UNIX.

We do revert to the generic ID for some operations due to specific file
permission issues, like UNIX directory ownership.


On 11/29/06, Arnold, Kevin <[login to unmask email]> wrote:
>
> First of all, I'm a security guy not a DBA (so don't use
> Hello,
>
> First of all, I'm a security guy not a DBA (so don't use any big words,
> ok? :-) ). We are trying to find alternatives to using a Windows local
> DB2ADMIN on both workstations and UDB servers (v8.x) for the sake of DB2
> Control Center. When DB2CC is installed, it creates a local user and group
> that has tremendous authorities (local admin, act as part of the operating
> system, run as service, etc.). Our DBA's tell us that "they HAVE to user
> this specific user-ID to do their job". OK, let's dig down in that
> statement a bit.
>
> I would like to give the DBA's the appropriate authorities on both the
> workstation and UDB servers to do their job - but through their normal
> user-ID, not DB2ADMIN. It seems this would be easy enough to do via Group
> Policy. I'm a big believer in giving people the necessary authority to do
> their job, so I'm trying to define what is appropriate.
>
> As a start to this, does anyone see a reason I could not give the DBA's
> real domain user-ID the same authorities as the current DB2ADMIN on the UDB
> servers? And if their domain account is in the local DB2ADMNS group, I also
> don't see any reason why the local DB2ADMIN account shouldn't be disabled
> altogether? Those of you who have done the Sarbanes road concerning generic
> user-ID's have certainly gone through this before me. Exactly what
> authorities does a DBA need on a v8.x UDB server? Or workstation running
> Control Center? We have z/OS databases and a handful of server-based
> databases as well. The majority of DB2CC users use it for remote database
> access.
>
> Thoughts on how to approach this? Thanks.
>
> Regards,
> Kevin Arnold
> Manager, IT Security
> OPERS
> 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

Paul Gyau

Re: DB2CC Security Concerns
(in response to Dan Tuck)
Arnold:
You can do the following for Windows:
A) Have the DBAs user-ids created in the domain group so that they can
use their own logon credentials to logon on to the UDB Servers to
perform dba functions and this will provide audit trails for SOX. Their
user-ids in the domain group will be part of the administrator group on
the Windows server so definetely they have the sysadam authority.
B) You can also create need an id, example: db2admin, on the server
which should be part of the administrator group and will be used to
perform database installs and upgrades. All the DBAs will be aware of
this id and its password for common usage.

C) You can also create another domain group (note, this group need not
be part of administrator group but can grant dbadm right to the group
name) and add the users who want R/W permission to use the Control
Center to the group. They can then connect remotely with their
individual log on credentials to the database and perform their duties,
this will also satisfy SOX (audit trail). You do not need to create a
generic id for such users because you may end up with id disabling due
to mistyping of passwords. There is a lot of work to be done in (C).

I hope this will help

Paul Gyau
DB2 UDB DBA
Geico

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Arnold, Kevin
Sent: Wednesday, November 29, 2006 9:23 AM
To: [login to unmask email]
Subject: [DB2-L] DB2CC Security Concerns

First of all, I'm a security guy not a DBA (so don't use Hello,

First of all, I'm a security guy not a DBA (so don't use any big words,
ok? :-) ). We are trying to find alternatives to using a Windows local
DB2ADMIN on both workstations and UDB servers (v8.x) for the sake of DB2
Control Center. When DB2CC is installed, it creates a local user and
group that has tremendous authorities (local admin, act as part of the
operating system, run as service, etc.). Our DBA's tell us that "they
HAVE to user this specific user-ID to do their job". OK, let's dig down
in that statement a bit.

I would like to give the DBA's the appropriate authorities on both the
workstation and UDB servers to do their job - but through their normal
user-ID, not DB2ADMIN. It seems this would be easy enough to do via
Group Policy. I'm a big believer in giving people the necessary
authority to do their job, so I'm trying to define what is appropriate.


As a start to this, does anyone see a reason I could not give the DBA's
real domain user-ID the same authorities as the current DB2ADMIN on the
UDB servers? And if their domain account is in the local DB2ADMNS
group, I also don't see any reason why the local DB2ADMIN account
shouldn't be disabled altogether? Those of you who have done the
Sarbanes road concerning generic user-ID's have certainly gone through
this before me. Exactly what authorities does a DBA need on a v8.x UDB
server? Or workstation running Control Center? We have z/OS databases
and a handful of server-based databases as well. The majority of DB2CC
users use it for remote database access.

Thoughts on how to approach this? Thanks.

Regards,
Kevin Arnold
Manager, IT Security
OPERS
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 email/fax message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution of this
email/fax is prohibited. If you are not the intended recipient, please
destroy all paper and electronic copies of the original message.

---------------------------------------------------------------------------------
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