Middle-Tier Passwords – Who Needs Them?
Oracle recently announced a feature in the upcoming Oracle Database that addresses the operational burden associated with changing passwords in the middle tier. This technology white paper compares Oracle’s Gradual Password Rollover feature and the AsterionDB architecture.
Modern applications are like a stack of three pancakes – the user on top, the application in the middle and the database at the bottom. When you log on, you are logging in to the application. The application then logs on to the database at the bottom on behalf of everybody.
If somebody steals your username and password they get your information; that’s bad. If somebody steals the application’s username and password, they get everybody’s information; that’s worse!!!
With AsterionDB, if somebody steals the application’s username and password that’s not enough, they still need more information. That’s Good…!!!
Many organizations have policies that require the regular changing of passwords used by applications that connect from the middle-tier to the data-layer. Oracle answered this operational requirement by adding a specific feature to the database to assist in the management of password rollover activities.
In contrast, AsterionDB’s architectural innovations render middle-tier passwords irrelevant. This is accomplished by isolating application logic, limiting schema visibility and utilizing a generic middle-tier transformation layer that greatly limits the information that can be discovered by the intruder.
The Oracle database allows AsterionDB to create a single, generic access point to business logic at the data-layer. With a single API access point for client interactions, we are able to limit the information an intruder can discover to such a degree that no useful knowledge can be gleaned.
The AsterionDB architecture employs a minimally provisioned philosophy and a middle-tier translation and security layer that isolates business and presentation logic between client and data layers.
AsterionDB’s minimal provisioning philosophy extends to the point that architectural security is guaranteed by the Database Administrator (DBA) password. Middle-tier access is granted by an operational proxy user and a password that has no security relevance.
Market and Technical Forces Driving This Innovation
Many organizations have an operational requirement to regularly change passwords that are used by middle-tier applications that access database resources. This introduces a significant operational burden surrounding the coordinated changing of passwords. Each middle-tier computer that is hosting an application that accesses the database must be reconfigured to utilize the new password. This operation is frequently done manually or by a specialized maintenance script. In addition, the safe recording of the new and the disposal of the old password must be factored into this operation.
Today’s dominant architecture and paradigm places a significant percentage of an application’s resources (i.e. unstructured data, logic) in the middle-tier. Applications utilize database credentials in order to make calls to retrieve and update structured data.
Oracle based applications frequently utilize functions and procedures to update information. Utilizing functions and procedures to return data, especially large sets of data, is very difficult however. In order to work around this limitation, middle-tier logic is built with the knowledge of the database’s structure. This knowledge, also called ‘schema visibility’, allows the middle-tier application to specify the information to be retrieved.
Schema visibility is a critical intrusion vector. The ensuing operational requirement to rollover passwords is a direct result of the effort incurred to minimize the schema visibility intrusion vector.
The Layer Cake Example
To give an example, today’s applications place a call to the database in order to retrieve a set of data. Each row of data could be thought of as a layer in a cake. The data that comprises each row, or layer in the cake, is specified by the middle tier application. This is akin to telling a baker to make a layer cake and to use these specific ingredients. The baker knows how to make a layer cake but must be instructed what to include as far as ingredients.
The Fundamental Difference – Limited Schema Visibility
In contrast, AsterionDB moves all data, both structured and unstructured, to the data layer. We also move all business logic to the data layer. This allows the middle-tier to become a transformation and security layer between users and the application’s logic and data.
AsterionDB also utilizes advanced features in the database that allows the full encapsulation of requests for data within a function. This is a key innovation that facilitates pushing all business logic, including requests for data, down to the data layer. The result is that AsterionDB is able to significantly limit schema visibility in the middle-tier. The only thing the middle-tier can see is a procedural interface into exposed PL/SQL packages – a data layer API.
A Smarter Cook Bakes a Better Cake
Returning to our layer cake example, by removing schema visibility and pushing all of the logic down to the data layer we have in essence given the cook knowledge of what ingredients to use when making the layer cake. All we have to do is ask for a certain type of cake and allow the cook to do the work.
AsterionDB’s Generic Middle-Tier Interface
Building upon limited schema visibility in the AsterionDB architecture, we have implemented a generalized interface to data-layer logic. The middle-tier transforms requests from the client layer and makes a call to a generic API interface. This mechanism relies upon the fact that the client knows what it wants from the application, thus allowing the middle-tier to merely decorate and pass on the request to the data-layer for validation and processing. The middle-tier does not know exactly what the data-layer can do, it only knows that it can call a generic interface and let the API do the rest based on the request from the client-layer.
Middle-Tier = Waiter / Data-Layer = Kitchen
Returning once again to our gastronomical example, the AsterionDB architecture looks very much like a restaurant with diners (the clients) making requests to the waiter (the middle-tier) that get passed directly on to the kitchen with the cooks (the data-layer). AsterionDB’s generic middle-tier is like a waiter that doesn’t know what is on the menu – they just pass the request on to the kitchen.
The kitchen validates each request ensuring that the diner is a known patron and is placing a proper order from the menu. Remember, the waiter is only responsible for passing requests from the diner to the kitchen and returning the prepared food. The kitchen keeps track of everything else.
Isolated Application Intelligence
With the AsterionDB architecture utilizing the middle-tier as a transformation and security layer, we have isolated application logic in the client and data layers. The client-layer, knowing what it wants from the data-layer, implements all of the presentation logic. The data-layer, as previously discussed, contains all of the business logic. The middle-tier, which relies upon a generic API interface, does not know what the underlying application is capable of doing; that knowledge is already present in the client-layer.
What this in essence means is that the middle-tier is unable to do anything on it’s own – it has no knowledge and must be instructed by the client-layer. Furthermore, each client request is self containing and encapsulates all required information for session validation.
If a cybersecurity intrusion occurs and the intruder is able to connect as the middle-tier user they must have intimate knowledge of how to formulate a valid request. Issuing an invalid request will reveal the intrusion – or the existence of a bug. All the intruder can discover is a generic API interface that tells them no other information.
An intrusion at the middle-tier is similar to breaking into a dark room with trip wires all over the place. The intruder must know exactly what to call and can not submit a malformed request. Doing so will immediately set off an alarm and reveal the intrusion. This is limited schema visibility in action!!!
Minimal Provisioning Philosophy
The convergence of logic and data in the database makes it easy to adhere to a best practice: minimally provisioning an application’s schema. This makes it easy to segregate application responsibilities and object ownership in a manner that enforces security at the source. The AsterionDB architecture takes advantage of this by creating an application schema that owns all of the data and logic and proxy user that is used to process middle-tier API requests.
Critical to the design, the user that owns all of the data and logic is never granted the ability to connect to the database and thus create a session.
To enable application connections the proxy user is granted execute access to exposed PL/SQL logic – an API entry point for example. This provisioning mechanism allows us to control, in a precise fashion, exactly what the proxy user can see and works hand in hand with AsterionDB’s overall approach that emphasizes limited schema visibility.
During normal operation, the only account that can connect to the AsterionDB system is the middle-tier proxy user. Enforcing this policy ensures that in the case of an intrusion leveraging the proxy user, the intruder is limited in the information that they can discover.
During maintenance operations DBA access is enabled to install any schema and logic updates as required.
The AsterionDB Converged Computing Platform is secured by the DBA password. All other system passwords have no security relevance.
Isolated Operational Intelligence
Minimal provisioning as well as isolated application intelligence reveal a concrete benefit through the isolation of operational intelligence. In essence, this means that the people that know how the system is built don’t get to run the system and those that run the system don’t know how it is built. With all of the data and logic stored securely in the database this separation of operational roles stands in opposition to insider intrusion.
Middle-Tier Passwords Are Now Irrelevant
The net result of isolated application and operational intelligence, limited schema visibility, minimal provisioning and AsterionDB’s generic middle-tier interface renders passwords in the middle-tier irrelevant. This irrelevance is driven by the fact that an intruder has limited schema visibility within the data-layer.
Applications built in conformance to the AsterionDB Converged Computing Platform are secured by the DBA password. All other database passwords used for application access (i.e. from the middle-tier) have no security relevance. The need to rollover middle-tier database passwords can thus be minimized or negated.