DB2 10 Security Improvements
DB2 10 for z/OS introduces the ROLES-based security model that was introduced in DB2 9.7 LUW. This security model provides granular data access security providing definitions that can secure data access down to the row and column level. DB2 10 also uses the new SECADM administration role to enhance data access security and provides addition protection safeguards for all the SYSADMs within the DB2 for z/OS environments.
The DB2 10 ROLES-based security and its long history and relationship with other RACF, ACF2 and Top Secret provides many different opportunities to segment and define degrees of data access within your application environments. This is especially important as the new HIPAA, Sarbanes-Oxley, BASEL III and other industry specific security standards are implemented.
So how does DB2 10 security improve performance? While working with a recent security audit client, I learned that the audit division wanted to improve their security profiles, better understand their exposures and improve monitoring of their overall data environment. In collaboration with their security and DB2 support personnel we uncovered several layers of security within their Java applications.
Java Performance Improved with Security Audit
The first layer was the RACF environment that allowed access to their intranet and their Java web applications. This security was a bit loose but still kept out people who were not defined within the organization. This interfaced with additional user security defined within their databases and package security layers for application execution within their DB2 z/OS environment.
Next the UNIX server environment and WebSphere environments had generic users with broad access definitions. These servers balanced the workload but did not really secure the environment as much as pass the generic users along for the database to validate.
Within the Java applications there was a complete section of the application that monitored and logged the user data access. The application had a huge amount of custom code that logged, monitored and stored a massive amount of data every day about what was happening within the application database. Maintaining this huge amount of custom code and security data was an extra burden on the business and the application team.
After reviewing these environments and security situations, the team was able to redefine and tighten up security at every level. These tighter controls led to better thread reuse because of proper Java practices. In addition by setting up the monitoring within the DB2 environment, the custom logging code within the Java application could be removed which improved performance by about 17% right away.
The business success of securing the environment improved performance, improved monitoring and logging of the data activities. Further planned security work such as implementing Trusted Context within WebSphere and improving the Java dynamic SQL to static SQL with pureQuery will potential improve Java performance another 15%-20%. So securing your applications can be a good business practice and improve your overall Java DB2 performance.