The following is a reprint of an article that first appeared in IDG’s TECH(Talk) online community forum.

A Modern Mainframe Architecture to the Rescue!

Chapter 5

We’ve covered a lot of ground. I’m glad you’re still with us!

In the previous chapters we discussed how a middle-tier heavy architecture is poorly suited to answer today’s cybersecurity and information technology challenges. We also laid the conceptual foundation for a data-layer oriented approach that removes user files and business logic resources from the middle-tier.

But, if we move all of our resources to the data-layer, do we still need a middle-tier? If we do, what does it look like?

The New Middle-Tier – An Elastic Security Isolation Layer

In our new data centric model, the middle-tier plays a vital role and can be viewed as an elastic security isolation layer. ‘Elastic Security Isolation Layer?’ What does that mean you may ask. Well, if the middle-tier has no user or business logic resources, it’s only purpose is to effect a protocol transformation between the data-layer and the client-layer.

The protocol transformation that is taking place is between HTTP, which is used to communicate with the client, and SQL which is used by the database. The middle-tier is elastic in its ability to adapt to user requirements. Finally, it acts a security isolation layer because any intruder would have to subsequently gain access to the data-layer in order to compromise information.

It is important to remember in this scenario that the middle-tier, acting as a protocol transformer, does not have to, in most cases, interpret or act upon the client requests or the responses from the data-layer. The middle-tier can merely pass the requests and responses back and forth implementing the HTTP/SQL transformation in the process.

Middle-Tier API Design Considerations

This whole ‘Isolation Layer’ thing sounds interesting, doesn’t it? Since the middle-tier is often exploited by hackers, having it act as a security isolation layer gives us an added layer of protection. But, there’s a catch, as always. What happens if an attacker is able to pierce the data-layer? After all, in order for the middle-tier to call the data layer, an API of some sort must be exposed. Can we take a new approach in how we implement the API to the data-layer?

It may not be apparent at first, but something very significant happens when we push all of our logic down to the data-layer; all of our logic routing and mapping in the middle-tier goes away. Once again, the middle-tier has no resources, it’s only supposed to forward requests and responses back and forth. This means that the data-layer is responsible for looking at the client request and routing it to the appropriate logic.

So, what does this mean for our API to the data-layer? It means that we can implement a generic API with a single entry point – an API that has a function called ‘CALL_API’ for example! Recall that the middle-tier is not going to act upon the client request but merely forward it to the data layer. That request, because we are using a RESTFUL interface, has all the information we need. Therefore, the routing takes place inside of the database and does not have to be exposed in any way through the API.

With our generic API, we now have a means of restricting the information that an attacker can glean about a compromised system. If the attacker were able to gain access to the data-layer and look at the objects exposed, they will only see a package with a function inside that says ‘CALL_API’. Lot’s of help that is to them!

JSON – The Lingua Franca of the Internet

You may recall that in chapter 3 we examined how JSON provides a uniform data representation, a langua franca if you will, for data communications. Our new middle-tier API design takes full advantage of this in it’s implementation.

Your browser is designed to talk and understand JSON data. Realizing that JSON is not going away, relational databases are now becoming JSON aware. This allows the database to directly ingest JSON data and act upon it. As you can see, the browser sends its request in JSON and the middle-tier merely forwards it on to the database. The database examines the data contained in the JSON packet and performs the actions necessary to fulfill the client’s request.

The response formulated by the database is also expressed as JSON data. With JSON data coming into and going out of the API, the generic interface that we just spoke of, ‘CALL_API’, takes a JSON string as a parameter and returns a JSON string as its result.

Minimally Provisioned Users

You may recall from chapter 3 that pushing the SELECT statements down to the data-layer has some significant security implications; here’s where that becomes relevant.

Traditional database interface techniques entail binding variables to each column in a SELECT statement. This imposes a lot of complexity if one were to try to incorporate SELECT statements into a database procedure or a function. The API signatures become cumbersome and changing just one SELECT statement will require close coordination between the calling programs and the API.

As a result, programmers find it easier to place SELECT statements directly into middle-tier logic. This subsequently requires the exposure of schema information to allow for the parsing of the SELECT statement. This is a security risk. Connections from the middle-tier are able to examine your schema structures and discover information about your system.

With our single-point API and SELECT statements embedded within our API, we can implement a minimally provisioned schema/user architecture within the database. It’s really rather simple. The user that owns all of the tables and business logic is not allowed to connect to the database. Instead, we have a proxy user that can connect to the database but that user only gets to see our API. Since our API does all of the work, that’s all the user needs to see.

Our database is now setup such that the only user of relevance is the DBA user. The database user that owns the application can not connect to the database under normal production use. This means that being connected as the DBA is the only way to examine or change the application’s data structures or logic. Our proxy user, as mentioned previously, can only see our API with its single entry point.

The net result is the near complete elimination of discovery from the middle-tier. If an intruder gains access to a middle-tier resource and subsequently connects to the database, using the proxy user’s credentials, all they will see is our generic API.

A Security Breakthrough – No Network Discovery

This is very significant. We have eliminated all network discovery from the middle-tier. An attacker can no longer move laterally within this architecture and map out your system.

Is this the holy-grail of cybersecurity? It could be. Stay tuned for chapter 6 where we will look at all of this in summary and examine the full security implications.