DB2 Security Definitions

With the all the hacking stories getting a lot of news coverage, security of a company’s information will definitely be on everyone’s mind.  There are many DB2 security options and features that can be used within the system, database, and application environments.  As I have written before, DB2 security for row and column access and DB2 security with encryption are two of the most recent DB2 security enhancements.  Check those DB2 security blogs out if you are not currently using these great DB2 security features.  
The following are five DB2 security definitions techniques that can help you improve the security within your production DB2 environment.

1. DB2 security starts in test
   All system, database, and application security plans need to be a comprehensive collaboration of all the components that interact to protect your DB2 data.  DB2 security, along with your other security components, needs to be multi-layered and comprehensive enough to provide a series of access challenges for anyone trying to hack your DB2 data.
   DB2 security starts with your test environments, because several recent hackings have started their hack through test or unrelated systems that have then been leveraged to study, explore and exploit access to other production systems.  If your DB2 security for your test environments is minimal, it is time to upgrade and make it as secure as your production environment.  Having your test environment DB2 security like production can help everyone understand the different layers, procedures, and approvals required for production environment DB2 security and help uncover any lapses or possible improvement areas.
   
   
2. Partitioning and segmenting DB2 security access
   
   With the collaboration of firewalls, operating system security, and other components, accessing the DB2 system should be limited to a very small number of IDs compared to the number accessing the overall system.  Through the use of DB2 security ROLES and/or grouping of user IDs through the RACF/ACF2/Top Secret operating system security software, all the access should be partitioned, segmented, and minimized for the unique requirements of the ROLE or group ID and the specific databases or tables they need to access.
   
   The IDs then can be further segmented via the database, the processes, and then their functional requirements.  Researching the number of IDs with duplicate functionality controlled or allowed through multiple DB2 or RACF definitions needs to be done. This information then needs to be analyzed, so duplicate or unknown access can be eliminated to minimize DB2 security exposure.  When researching the DB2 security, examine the ROLE/ID usage against the DB2 functionality required, the data objects it can access, and the plans, packages, and processes that the ID can execute within the environment.
   
   
3. DB2 security for functionality
   
   Not everyone in the DB2 security definitions needs to have the evaluated functionality of a system administrator or DBA.  All of the groups or IDs with direct SECADM, SYSADM, and DBADM privileges need extra attention because of their elevated authority, but also because of their ability to GRANT privileges authority to other IDs.  The IDs with GRANTing authority are best managed through the operating system RACF/ACF2/Top Secret security groups with any new id GRANTs and production access fully audited and explained in a weekly DB2 security audit log report.
   
   
4. DB2 security for data object type
   
   Just as we have different car types for different purposes, trucks for cargo and high performance race cars for speed, the security implemented should match the data object type it is protecting.  While all cars have engines, fuel, and passenger protections they are all customized for their usage and application.
   
   Within your DB2 environment, data objects need the same type of security usage and application considerations.  The security for the DB2 object needs specialized security to keep it safe, and yet provide the best protection for the application considerations.
   
   
5. DB2 security for execution modules
   
   For customizing the security for the applications, the existing access types need to be catalogued.  For example, referencing data via customer key or order number or another key is common, but scanning all the customer data within a single SQL statement might be uncommon.  Understanding the number/type of accesses, their time window, and patterns of your normal processing access to your most sensitive information is critical for identifying unauthorized scans or other access types that may be probing your data objects.

There is nothing more important than security and DB2 security has all the mechanisms to keep your systems and data safe.  Now is the time to review your DB2 security facilities to guarantee that you won’t have issues.

Here’s a list with links to other posts that may help you improve your DB2 performance, security, and ease-of-use:

5 More DB2 SQL Performance Tips
Another 5 More DB2 SQL Performance Tips
5 Big Data SQL Performance Tips – Fixing Generated SQL
DB2 11 SQL Performance Improvements
5 More SQL Performance Tips for your Big Data
Hadoop SQL: 4 Reasons Why BigInsights Is the Best
Vital Java DB2 SQL Performance Considerations
More DB2 Family Security Best Practices Part 7: Preventing SQL Injection
DB2 SQL Security Audits

Dave Beulke is a system strategist, application architect, and performance expert specializing in Big Data, data warehouses, and high performance internet business solutions.  He is an IBM Gold Consultant, Information Champion, President of DAMA-NCR, former President of International DB2 User Group, and frequent speaker at national and international conferences.  His architectures, designs, and performance tuning techniques help organization better leverage their information assets, saving millions in processing costs.