Web-Exposed Databases

2 Pages

Increasing scrutiny of database activity, fueled by regulatory requirements, is exposing a rarely discussed hole in database activity auditing: invisible users. This blind spot is especially troublesome for organizations that must comply with regulations that mandate database access auditing, including section 404 of the Sarbanes-Oxley Legislation, section 10 of the PCI (Payment Card Industry) standard, and Title II, Security Rule, and Administrative Safeguards of HIPAA. Native DB2 for z/OS audit logs have no awareness of specific user identities  accessing sensitive database information via Web applications. This includes Web-enabled commercial packages such as SAP, Oracle EBusiness Suite, PeopleSoft, etc. Therefore, when audit logs reveal fraudulent database transactions, there’s no link to the responsible user. The problem isn’t unique to DB2; the issue applies to all database platforms. That’s because the problem isn’t with the database technology itself, but with the design of most Web applications.

The Problem With Web Applications

Web application users don’t directly access the database server. Rather, a browser request invokes Web application server code that performs the required database transaction on the user’s behalf. To accomplish this, the Web application doesn’t access a unique database account for each user; instead, a process known as connection pooling is applied as follows:

  1. The Web application server creates a relatively small set of database connections (called “the pool”) using a single database account commonly referred to as the “application account.”
  2. When a Web server thread that processes a user request needs database access, it picks an arbitrary connection from the pool, sends the request over this connection, receives the response, and releases the connection back to the pool.

Connection pooling lets a database service thousands of concurrent user sessions with only a handful of database connections. Moreover, with a pool of available connections, the Web application can quickly recover from a single connection failure without any noticeable effect on response time. This approach is exercised by Internet-facing applications and internal enterprise Web applications such as SAP, Oracle E-Business Suite, PeopleSoft, etc. Unfortunately, pooled connections have two negative characteristics for the database auditor:

  1. All user transactions are aggregated in a single database account identified only by the Web application account name (see Figure 1). The database receives no information regarding the actual user’s identity.
  2. Multiple user sessions are multiplexed into a single database connection while simultaneously dispersing requests from a single user session across multiple database connections.

Consequently, the database server’s native audit mechanism can’t correlate any single request to a specific user. The resulting audit trail associates all database activity with the generic “application account.” This is problematic because when logs reveal questionable database transactions, there’s no link to the responsible user. Regulatory compliance, security best practices, and common sense all dictate that audit data must establish accountability by linking actions to users. Without such accountability, there’s little value in the audit process.

What can be done to eliminate this blind spot? There are four options to consider: rewriting the applications, using proprietary database mechanisms, relying upon Web application audit information, and using external database audit devices.

Rewriting the Applications

The most obvious approach to identifying each user to the database is to rewrite Web applications so they access a unique database account for each user. Doing so enables native database auditing tools to record each transaction with the appropriate user name. Unfortunately, it’s an unrealistic solution for several reasons:

  • Scalability and performance: Web applications, especially Internet-connected applications, are required to support thousands (or tens of thousands) of concurrent users while maintaining short response times. In such an environment, if the Web server were to open a new database connection for each request, a tremendous increase in response time would result. Alternatively, if the Web server maintains an open connection for each user session to mitigate the response time increase, the database must maintain thousands (or tens of thousands) of active sessions, greatly increasing the cost of server hardware.
  • User management responsibilities: Creation of unique database user accounts shifts user management, authentication, and application-level authorization responsibilities from the application administrator to the database administrator. This requires significant change to organizational responsibilities, but most database administrators don’t have the information, time, or tools to tackle such a task. In addition, the database server isn’t a suitable user management platform. Some of these issues may be reasonably addressed through deployment of an integrated user management environment that’s interoperable with the database server and the Web application. Kerberos, for example, can be used with DB2 for this purpose. Regardless, user management is challenging.
  • Third-party software: Organizations can’t modify proprietary third-party software such as SAP, Oracle EBusiness Suite, PeopleSoft, etc. Usually, the best that can be done is to request that the software vendor add database user audit capabilities in a future release.
  • Cost: Rewriting applications is costly. Code changes, user account migration, testing, and administrator training all consume significant resources. A significant budget should be allocated to these tasks for each application.
  • Implementation schedule: Extensive application and user management changes such as those described above take months to accomplish for a single application. For an organization with hundreds of applications, the transition takes years.
  • Risk: Extensive code changes, particularly in the area of user login, introduce significant risk to application availability. Strategic application changes should be tested extensively before production deployment and monitored closely after deployment.

A Better Approach to Rewriting

Rather than accessing a unique database account for each user, the Web applications may continue to use pooled connections, but be rewritten to embed a reference to user identity in each database request. The database may then be programmed to incorporate the embedded reference information into the audit trail.

2 Pages