|
|
Administrator > DB 2
Easing the Cost of Compliance
New DB2 for z/OS features simplify regulatory compliance
The Sarbanes-Oxley Act and other regulations require corporate executives to provide and ensure increased levels of financial and operational discipline. To help comply with this law, most enterprises are now implementing measures that cross financial reporting and processes that impact internal business and computing operations. Privacy regulations, such as those imposed by HIPAA, create operational discipline on a company's IT operations that have a similar impact. This article describes how new features in DB2* V9.1 for z/OS* can help ensure compliance by allowing better user accountability, providing end-to-end identity controls and improved auditing capabilities.
The most common view of compliance relates to people: who can access which systems and what data; what can they do with those systems; and what happens when someone owns access to data and then leaves the company. Users perform many tasks when they access information systems. Each of these tasks can be viewed as a role the user plays. A user's ability to access systems and access and manipulate data is typically a function of the role the user plays. By defining roles, creating objects owned by roles instead of users, and assigning privileges to roles and then defining users and which roles can be used by an application, an enterprise can enforce internal business policies, audit user access and provide separation of duties within their database systems which, in fact, owns and controls access to the data. Internal Policy One common internal policy relates to separation of duties. For example, a person who has the right to create a new purchase order shouldn't have the right to create a new vendor. Separating these two duties may prevent a person from diverting business to a friend's company. A solution is to define a role called "purchaser" with the ability to access the Purchase Order System (POS) and the rights to create a new purchase order in DB2. The enterprise would also create a role called "managers" with the ability to access the POS with the rights to add new vendors to DB2. Any attempt by a user using the purchaser role to add a vendor can then be blocked as well as traced for later audit purposes. Another internal policy is adherence to company policies. For example, the POS should only be used to create purchase orders and add new vendors. Allowing a user the right to add a vendor or create a purchase order while not using the POS may bypass any inherent business policies built into the POS. A solution is to create a "trusted context" that defines what users and roles can access DB2 using the POS. The trusted context enforces use by which roles can access DB2 using the POS. If all access is granted only to the role, there is no way any user can access any data outside a trusted context. Any attempt to bypass the POS can then be blocked as well as traced for later audit purposes.
Today, most application servers accessing DB2 are controlled by a single user, and that user's ID is used for all access to DB2. The current approach has many operational benefits. Having all interactions with DB2 under a single user eases access control, but eliminates any user accountability and any way to enforce internal business policies. Such access is potentially a compliace problem, since some regulations require the ability to know who issued access or modified DB2 data.
Roles and trusted contexts are introduced in DB2 V9.1 for z/OS, with roles only available with trusted contexts.
Advertisement
Browse products and services for Administrator.
Advertisement
Maximize your IT investment with monthly information from THE source...IBM Systems Magazine EXTRA & Marketplace eNewsletters. SUBSCRIBE NOW.
View past Mainframe EXTRAs here