Database security is of utmost importance today. Your database might allow customers to purchase products over the Internet, or it can contain historical data used to predict business trends; either way, your company needs a sound database security plan.
A database security plan should define:
- Who is allowed access to the instance and/or database
- Where and how a user's password will be verified
- Authority level that a user is granted
- Commands that a user is allowed to run
- Data that a user is allowed to read and/or alter
- Database objects a user is allowed to create, alter, and/or drop
There are three main mechanisms within DB2 that allow a DBA to implement a database security plan: authentication, authorization, and privileges.
Authentication is the first security feature you'll encounter when you attempt to access a DB2 instance or database. DB2 authentication works closely with the security features of the underlying operating system to verify user IDs and passwords. DB2 can also work with security protocols like Kerberos to authenticate users.
Authorization involves determining the operations that users and/or groups can perform, and the data objects that they may access. A user's ability to perform high-level database and instance management operations is determined by the authorities that they have been assigned. The five different authority levels within DB2 are SYSADM, SYSCTRL, SYSMAINT, DBADM, and LOAD.
Privileges are a bit more granular than authorities, and can be assigned to users and/or groups. Privileges help define the objects that a user can create or drop. They also define the commands that a user can use to access objects like tables, views, indexes, and packages. New to DB2 9 is the concept of label-based access control (LBAC), which allows more granular control of who can access individual rows and/or columns.
To prepare for the next section of the tutorial, you will need to
create a database within the DB2 instance. Make sure that the
%DB2INSTANCE% variable is still set to DB2,
and then create the sample database using the command
using the name of the drive where you want to create the sample. For
the examples in this tutorial, you'll create the sample database on
your D: drive, as follows:
D:\SQLLIB\BIN> db2sampl d:
It is particularly important that you understand the terms client, server, gateway, and host when considering the security of the entire database environment. A database environment often consists of several different machines; you must safeguard the database at any potential data access point. The concepts of clients, servers, gateways, and hosts are particularly important when dealing with DB2 authentication.
The diagram below illustrates a basic client-server-host configuration.
Figure 1. Basic client-server-host configuration
The database server is the machine (or machines in a partitioned database system) on which the database physically resides. The DB2 database clients are machines that are configured to run queries against the database on the server. These clients can be local (reside on the same physical machine as the database server) or they can be remote (reside on separate machines).
If the database resides on a mainframe machine running an operating system like AS/400® (iSeries®) or OS/390® (zSeries®), it's called a host or host server. A gateway is a machine running the DB2 Connect product. Through the gateway, DB2 client machines can connect to a DB2 database that resides on a host machine. The gateway is also referred to as the DB2 Connect Server. Systems with the Enterprise Server Edition product installed also have the DB2 Connect functionality built in.