Do you hear that silence? It’s how your data sounds as it slips out the door. More companies are facing the unpleasant task of reporting the loss of their data to the government and their customers. Although many recent instances of data loss were attributed to hackers—with carelessness a close second—insider theft accounts for a good percentage of data losses. Though embarrassing, loss of customer information isn’t as devastating as the loss of the data that drives your company—data that makes your company successful and identifies who you are, including trade secrets, sales and profit forecasts, financial statements, and employee information.
A place to start in preventing internal corporate data loss is examining the data custodians. Are the people responsible for securing corporate information also responsible for the integrity and maintenance of that same data? Does your database management system make you feel secure? Can you separate the privileges necessary for a DBA to do his or her job from those privileges necessary to protect a company’s data?
DB2 9 started addressing some of these issues when it introduced the ROLE and TRUSTED CONTEXT. However, DB2 10 really completes the practical solution to the separation of data security from data maintenance with the addition of new system privileges, such as the SECADM administrative authority, that draw a distinct line between who can manage DB2’s security and who can manage its data maintenance and data access.
SECADM System Authority
SECADM is an enhancement that’s increasingly being used as companies move to DB2 10. For the first time, DB2 will natively allow the complete and total separation of the privileges needed to manage and access data from the privileges necessary to perform security tasks.
The SECADM authorization is designed to separate security functions from database maintenance functions. SECADM manages the security functions while having no access to any data in a DB2 object. When the SEPARATE_SECURITY system parameter is also set to YES, the authorization ID (authid) or role defined as SECADM is the only system authority that can:
- Issue SQL GRANT and REVOKE statements implicitly
- Manage ROLEs, TRUSTED CONTEXTs, row permissions, and column masks
- Audit policies.
SECADM also has access to the DB2 catalog tables and can issue the DB2 –START, -STOP, and –DISPLAY TRACE commands. Object owners still have implicit authority to issue GRANT and REVOKE against objects they own.
Enabling SECADM authority requires several steps. First, decide if you want to use SECADM as a standalone, or separate, administrative authority. SECADM may not be for everybody. In previous versions of DB2, the privileges delivered as part of SECADM have traditionally been part of the SYSADM administrative authority. If using SECADM separately from SYSADM, the DSNZPARM, or subsystem parameter, SEPARATE_SECURITY, new in DB2 10, will need to be set to YES. This keyword is on the DSN6SPRM macro and can be set only to YES or NO, with the default being NO. NO allows DB2 to behave similarly to previous versions of DB2.
Next, a ROLE can be optionally defined and associated with the SECADM administrative authority. However, if using a ROLE, make sure it’s created before establishing SECADM’s use of that role. We’ll explain more on SECADM and ROLEs later. Authids can, of course, be either primary or secondary.
Although SECADM can be associated with a role or an authid, we suggest you set authid SECADM1 to a ROLE and SECADM2 to an authid or vice versa. Either way, the intent is to specify one SECADM as a ROLE and the other as an authid. You may wish to define the two SECADMs differently while you’re getting used to this new feature. Authids, even secondary IDs, are associated with a person while a ROLE is a standalone object not dependent on any one authid. A ROLE can easily be moved to wherever it’s needed.