• Define roles in DB2 and middle-tier applications so they’re aligned with the actual business roles.
• Implement declarative or programmatic role checks in the application to establish role membership; map roles to trusted connections.
• Associate DB2 roles and trusted contexts so DB2 acts as the actual policy enforcement point. Distributed users will be granted data access privileges associated with a specific role once they meet the requirements set by application logic and trusted context (see Figure 5).
The caveat is that, in environments where applications are hosted on distributed platforms and DB2 on z/OS, DB2 can’t verify roles membership for distributed users. While DB2 10 for z/OS supports further restriction of data access by activating row and column access control aligned with DB2 roles, this functionality isn’t much help when using new functions (such as VERIFY_TRUSTED_CONTEXT_ROLE_FOR_USER) in environments where identity propagation isn’t supported.
Consider our example for an application deployed on WAS, which requires access to data in DB2 for z/OS (see Figure 6). When trusted context is configured, DB2-side applications running on WAS will use the same pool of database connections but the authentication method changes to “trusted connection” and the AuthID hard-coded in the JAAS alias is now an account with connect-only privileges.
Implementing a role-based control mechanism for application access consistent with the least privileges principle using DB2 roles and trusted context provides these advantages:
• Increased data protection from human errors and malicious actions. It decreases the impact of defects in SQL queries and SQL injection attacks (error or attack containment).
• Simplified auditing. Using DB2 roles to grant privileges and align DB2 roles with business roles helps document and streamline database access.
• Decreased risks due to compromised middle-tier servers. Even if a DB2 authentication or ID/password associated with pooled connections would fall in the wrong hands, it doesn’t result in a security breach because this account has only connect privileges and no data access privileges. Trusted context will also prevent access from unauthorized servers even if a legitimate connection credential is used.
• Preserves the performance advantages of pooled database connections.
Establishing a role-based access control model using DB2 trusted context and DB2 roles lets you manage an application’s access rights to DB2 resources in a way that’s consistent with the least privileges and separation of responsibilities principles. However, in corporate environments, employees sometimes play several roles. They also may be granted temporary access rights beyond their normal duties. In other words, there may be situations when enterprise data may be accessed using legitimate role privileges, but then temporarily modified and changed back to satisfy the integrity rules in an inappropriate manner.
The principles of accountability and traceability establish that all actions must be traceable to the entity on whose behalf the action is being taken; the history of data manipulations is maintained and available for examination by authorized parties. To implement this principle, several mechanisms must be supported:
• Association of a unique identity with a sequence of actions so that action or sequence of actions can be unquestionably traced back to this identity
• Creation of a record describing the sequence of carried actions, along with a unique identity associated with this sequence, timestamp and other attributes, which may be used to verify the occurrence of the specific action.
Implementing the security principle of accountability and traceability for DB2 for z/OS requires establishing a mechanism to propagate user identities to DB2 to uphold end-to-end traceability. This can be challenging in many corporate environments where middle-tier applications run on distributed platforms. In these environments, transactions are associated with distributed identities while DB2 for z/OS operations run under RACF identities. Additionally, using pooled database connection mechanisms further complicates the problem.
Before DB2 10 for z/OS and z/OS Version 1, Release 11, the primary tool to propagate and map distributed identities to z/OS was the Enterprise Identity Mapping (EIM) mechanism. It provides the mapping of user identities from various user registries using z/OS Lightweight Directory Access Protocol (LDAP) server. The EIM mechanism was replaced by DB2 support for z/OS identity propagation using distributed identity filters and will be retired in the next DB2 release. The distributed identity filter rules define an association between a RACF user ID and one or more distributed identities. The rules don’t revalidate distributed identities; they map them to RACF user IDs. When identity filters are used and a user is audited on the z/OS operating system using SMF, the audit record contains the distributed identity (distinguished name), domain and the mapped RACF user ID. This establishes end-to-end accountability based on associating the transaction with a user on whose behalf this transaction was executed.
DB2 roles and trusted context apply the least privileges and separation of responsibilities principles and also support propagating distributed user identities from middle-tier applications. Assuming a distributed user identity is established, it can be propagated via DB2 trusted context. Specifically, for Java Enterprise Edition (JEE) applications running on WAS, if a distributed user identity is established in JEE security context, it will be automatically propagated to DB2 via DB2 trusted context (see Figure 7).
Advantages of using this approach include:
• Establishes end-to-end individual accountability across platforms using native mechanisms available in DB2 10 for z/OS. The distributed user identity received from middle-tier servers is maintained and logged along with the RACF identity.
• Bridges security silos between distributed applications and DB2 for z/OS, enabling the use of the fine-grained access control RCAC for environments where n-tiered applications use distributed identities
• Creates a more granular accountability structure by facilitating the process of tracing the transactions to a particular user in a specific role
• Simplifies problem analysis and reconstruction of event activities.
The value of establishing a centralized, role-based data access control mechanism goes beyond meeting regulatory and audit requirements. It offers a lower cost of ownership for organizations, reduces security risks and establishes a foundation for comprehensive data protection.
• John Viega and Gary McGraw, Building Secure Software: How to Avoid Security Problems the Right Way. Addison-Wesley, 2002
• Jerome H. Saltzer and Michael D. Schroeder, “The Protection of Information in Computer Systems,” 1278-1308. Proceedings of the IEEE 63, 9, www.cs.virginia.edu/~evans/cs551/saltzer/
• David F. Ferraiolo and D. Richard Kuhn, “Role-Based Access Controls,” National Institute of Standards and Technology, http://csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf
• New DB2 z/OS V10 authorization model for administrative authorities, http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=%2Fcom.ibm.db2z10.doc.seca%2Fsrc%2Ftpc%2Fdb2z_adminauthorities.htm
• “z/OS Identity Propagation,” www.redbooks.ibm.com/redbooks/pdfs/sg247850.pdf.