Posts Tagged ‘database security
DB2 security mechanisms
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
- The authority level that a user is granted
- The commands that a user is allowed to run
- The data that a user is allowed to read and/or alter
- The 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 will 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.
You will need to create a database within the db2inst1 instance. Make sure that the db2instance variable is still set to db2inst1, and then create the sample database using the command db2sampldrive, using the name of the drive where you want to create the sample. For the examples, we’ll create the sample database on our C drive, as follows:
C:\PROGRA~1\SQLLIB\BIN>db2sampl c: