One argument for having three tiers is basically a least privilege /
containment argument.
The idea is that if the web tier and/or credential gets compromised, it
can only execute (hopefully) narrowly defined business logic requests
against the middle tier, it cannot directly update tables. It is
basically the difference between being able to execute raw SQL and
stored procedures. The middle tier needs to be suspicious of the web
tier for this to work, i.e. it depends what the business logic enforces.
But if you didn't make that split, then a compromised web tier would
have immediate access to the whole database backend and update/query
tables directly, without being constrained by business logic at all. So
there is a good reason to get the business logic physically off the web
tier, and create a logical middle tier, at least.
There is a similar argument for physically splitting the middle tier
from the DB, for example if the same DB is accessed by multiple apps,
then each middle tier gets the access it needs and no more. But
depending on what you are doing you may or may not care about that.
Also depends whether you need segregation of duties between those who
admin the various tiers.
So at least if you're facing a hostile network then it's reasonable to
have 3 logical tiers, but that doesn't necessarily mean that the middle
& DB tiers couldn't be physically co-located.
Cheers,
Frank
Richard Burgett wrote:
One of our new colleagues is leading the charge to
require *all* business logic (i.e. database calls) to
be physically located on a middle tier server (which
is separate from the Web and DB Server). The
motivation for this change is "to be more secure".
We're a Microsoft shop, and are finally moving from
ASP to ASP.Net for public facing web apps (ones that
provide web registrations and similar with a
database).
I can understand using Three Physical Tiers for the
reasons of performance, scalability, and design
purposes. But, I've yet to find a compelling reason
why to do this for security reasons (after some
googling).
Could anyone point to some sort of authoritative
document on this or give a response?
Chapter 7 in the "Building Secure ASP.NET
Applications" book has very useful information, I'm
just basically trying to see how security mesures up
between the 2 physical tier scenario of "ASP.NET to
SQL Server" and 3 physical tier scenarios of "ASP.NET
to Remote Enterprise Services to SQL Server" (or even
"Using .NET Remoting").
Do 2 Physical tiers only cut it for small web sites
that don't store things like Credit Card info (i.e.
"Grandma's Cookie Shop")? Where would you draw the
line for moving to 3 tiers (being a bank)? Upto what
level of sensitive info can you store in 2 physical
tiers?
In trying to look at it from a bad guy's perspective,
how much more protection does the extra physical tier
give you? (especially in terms of trying to escalating
database privilege or trying to penetrate backend
systems) I'm not too familiar with these newer
technologies in terms of pen-testing, but I imagine it
wouldn't be that much harder to "island hop" across
the middle tier with netcat (or similar) after gaining
access and elevating privileges. (these newer
technologies must use open ports that pass through the
firewall between servers that could somehow be
compromised).
We have a fairly low volume of transactions, and were
hoping to smoothe out the learning curve for our
existing developers that are learning .Net and web
stuff and take a more gradual approach. (although
some of our apps are small and they all probably don't
warrant the extra complexity of this approach).
Personally, I don't like the rigid rule of having to
create a class on a middle tier for all database calls
to populate a web page, but maybe it will grow on me
;)
Some of our developers are thinking 3 tiers is
actually 3 tears from the eyes, lol
Thanks for any feedback,
Richard
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
