Friday, December 21, 2007
« Video webcast of a CSLA .NET interview | Main | January's Magenic webinars (including on... »

I recently received this email:

Thank you very much for your insightful articles concerning 2 vs. 3 tier models.  It’s very refreshing to hear a view point that I’m aligned with.  Here at work I’m dealing with network Nazi’s who believe there is no cost of a middle tier and that there is only huge security rewards to reap.  I use your articles to support my point but I’m still not getting tremendously far.  I have yet to have anyone explain to me exactly how that middle tier is going to really add a significant enough amount of security that will warrant the high price to pay for employing a performance blasting middle-man.

There are two scenarios, though they are similar.

In the web, adding a middle tier has a very high cost, because the web server is already an app server. It already does database connection pooling across all users on that server. Adding an app server just adds overhead.

The only exception here is where the web server is serving up a lot of static content and only some dynamic content. In that case, moving the data access to another machine may be beneficial because it can allow the web server to focus more on delivering the static content. It is important to realize that the dynamic content will still be delivered more slowly due to overhead, but the overall web site may work better.

In Windows, adding a middle tier has a cost because the data needs to make two network hops to get to the user. Each network hop has a tangible cost. It would be foolish to ignore the cost of moving data over the wire, and the cost of serializing/deserializing the data on each end of the wire. These are very real, measurable costs.

In both cases the middle tier means an extra machine to license, administer, maintain, power and cool. It is an extra point of failure, extra potential for network/CPU/memory/IO contention, etc. These costs come with every server you add into the mix. Anyone who’s ever been a manager or higher in an IT organization has a very good understanding of these costs, because they impact the budget at the end of every year.

However, the security benefits of a middle tier are real.

In a 2-tier web model the database credentials are on the web server. Even if they are encrypted they are there on that machine. A would-be hacker could get them by cracking into that one machine.

Switching to a 3-tier model moves the database credentials onto the middle tier and off the web server. Now the web server has credentials to the app server, but not the database. A would-be hacker must crack first the web server, then the app server to get those credentials.

In a 2-tier Windows model the database credentials are on each client workstation. Even if they are encrypted they are there on those machines. A would-be hacker could get them by sitting at that machine - all it takes is a little social engineering and they're in. More likely, an employee may get the credentials and use Excel or some other common tool to directly access the database, bypassing your application. Oh the havoc they could wreak!

Switching to a 3-tier model moves the database credentials onto the middle tier and off the client workstations. Now the workstations have credentials to the app server, but not the database. A would-be hacker must crack into the app server to get those credentials. And end users are almost automatically shut out, because they would have to be a hacker to get to the app server to get the database credentials.


Saturday, December 22, 2007 1:01:18 PM (Central Standard Time, UTC-06:00)
Why not make it *really* secure and have 15 more /physical/ tiers just in case?

That way the performance would be bad enough to deter anyone entering any useful/dangerous data, plus have the additional benefit of being FIFTEEN TIMES MORE SECURE!?! than your rationale in for going from 2 to 3... ;-)

Fifteen tiers, from orbit - it's the only way to be sure...
David
Wednesday, December 26, 2007 9:45:20 AM (Central Standard Time, UTC-06:00)
15 tiers probably would be more secure, but also more costly. I think the whole point of his argument here is that you have to balance the practical needs with the security needs of your applications.
Thursday, January 03, 2008 10:55:56 AM (Central Standard Time, UTC-06:00)
I'm reading book C# business objects now, and there seems one problem with csla.net commandbase execution. If there is implemented DataPortal_Execute method, then it's implementation would exists on server and on the client. But in n'tier architecture client must know nothing about real method implementation. It means security breach.
Anybody could me elucidate on the subject, how to hide implementation from the client.

Thanks in advance.
maxim
Thursday, January 03, 2008 11:07:37 AM (Central Standard Time, UTC-06:00)
You'll get better support for CSLA specific questions if you post them in the forum at http://forums.lhotka.net.

The data portal is specifically designed to allow object graphs to flow back and forth between client and server, and to provide location transparency as this happens. If you have server-specific code you may implement that in a DataPortal_XYZ method, or you may implement it in a separate assembly that is invoked from a DataPortal_XYZ method. If you follow this second approach, the separate assembly would only be deployed on the app server, thus avoiding security issues (the client wouldn't have that code).
Thursday, January 03, 2008 1:51:10 PM (Central Standard Time, UTC-06:00)
Thanks very much!

I try forum. But asking good question to the author, proves more effective:)
(Its a joke, i dont want to pollute your blog, but the issue with removing server data access code from the client is the key issue in SOA architecture. And in the post the issue about that architecture)

But the second issue, generally can not be solved by this approach. It,s population of business object with data in DataPortal_Fetch method. It accesses private fields, that can be populated only inside the same object.

But, thinking, i came across a solution to the problem (maybe or maybe not, i didnt tryed yet) - Partial compilation. Using #define directive wrapper around DataPortal_XYZ methods, so on client was version without those compiled methods. On server they must be compiled. So there would be two versions of libraries (client and server)
maxim
Thursday, January 03, 2008 2:10:02 PM (Central Standard Time, UTC-06:00)
Off the previous question.
I know one other argument on support of 3 tier architecture, and theres no need in the 4th tier, because middle application server layer hides from client all data access code that in 2 tier model inside the client program that can be decompiled, and easily can be found names of all stored procedures and the underlying storage technology.
Aplication server hides inside dataccess code, that means more security.
CSLA good framework in that there little access methods - DataPortal_XYZ. It's good.
So good is theres easily can be switched transport technologies to access application server. And theres one drawback - in framework (nor in the book) not stressed hiding server data access code from the client. I think it's a big ommition.

P.S.- pardon my english.

maxim
Comments are closed.