Dave BeulkeDB2 10 Security SECADM Considerations
DB2 10 SECADM helps DB2 audits
In addition to the introduction of ROLES, encryption and masking of data, DB2 10 takes a giant step forward with security and DB2 audits with the new SECADM authority. This new SECADM authority is finally acknowledging the huge amount of work the SYSADM and DBAs do every day defining access and keeping their huge DB2 environments secure. With this SECADM authority IBM is finally providing a way for the SYSADMs to separate themselves from the application data access hassles and focus on performance and overall health of the DB2 environment.
So now is the opportunity to request additional security help within the DB2 support group. Given the DB2 audits, new SECADM authority and the huge push on security and governance, it is easy to document and justify the additional staffing for the DBA group to handle all this type of governance, data access, masking and encryption security. Given that we are all trying to do the best to secure the DB2 environment, guard its data through the new ROLES, masking and encryption, it is time that the DB2 DBA team had someone dedicated to analyze these project and application requirements. We know the application development team is never going to do this type of analysis with their tight schedules and deadlines. So get in front of these security, masking and encryption issues now to get them in the budget, if possible, application schedule, and management staffing conversations.
So leverage and understand that the new security features in DB2 provide a way to make your life better by now being able to separate the time consuming data access analysis from overall system administration. The new SECADM and the new DB2 DSNZPARM SEPARATE_SECURITY provide a clear separation from data access control, oversight, tighter monitoring and security control within DB2 10 systems.
DB2 10 Separate Security for Your Duties
Setting the new zParm SEPARATE_SECURITY to YES does exactly what the parameter implies, it separates security authority from SYSADMs and SYSCTRLs and requires the SECADM authority to take over all data access and security related activities. This immediately removes the SYSADM and SYSCTRL authorities from the ability to GRANT and REVOKE authorities or privileges along with managing any of the ROLES, trusted contexts, masking or encryption activities I mentioned in the previous weeks’ blogs. In addition the SYSADM authorities can no longer SET CURRENT SQLID to any id, only ids that the SYSADM has as a secondary authority id.
In addition to removing the GRANT and REVOKE authorities from SYSADM and SYSCTRL authorization levels, setting the zParm SEPARATE_SECURITY to YES also restricts the SYSADM, SYSCTRL and DBADM authorities to being only able to set their BIND OWNER ids to their primary or the secondary ids. This further secures the system and limits their authority to bind programs that might have data access against sensitive objects. In addition the SECADM now has all responsibility for setting up DB2 audit monitoring, all data access controls, ROLES, masking and encryption.
Trust and Verify Your DB2 Row and Column Access
The SECADM and other security improvements in DB2 10 are all there to better secure your data access and system. Everyone probably will still use existing security procedures by just saying SEPARATE_SECURITY NO but it is a good idea to get your DB2 system security organized and understand all the DATAACCESS, or ACCESSCTRL privileges within your environment. To help set up the tighter environment, DB2 10 has also provided some additional security functions that can help verify security profile settings.
VERIFY_GROUP_FOR_USER, VERIFY_TRUSTED_CONTEXT_ROLE_FOR_USER, VERIFY_ROLE_FOR_USER are all functions that can be used for setting up tighter masking and encryption over your most sensitive data. These are commonly used in verifying these definitions but can also be used when setting up tighter controls.
Given most systems are already administered securely by the SYSADMs, separating security will probably be a SEPARATE_SECURITY NO setting until more resources are allocated or the security people get trained for the robust DB2 environment requirements. What is good about all this new security is that it is exactly the same within the DB2 LUW platform. The new SECADM opportunity only comes around once and now is the time to get help with your security definitions within your environment and start getting rid of that PUBLIC access as soon as possible. So start thinking about all your data access security, ROLES, masking and encryption and use the new SECADM opportunity to get more help with your all DBA duties.