1.4 The Fortress as a Trust Boundary

Above all, remember this: The fortress represents a trust boundary. This is the fundamental principle of software fortresses . The fortress represents not only a technical trust boundary, but usually an organizational trust boundary as well. Here I will focus on the technical idea of the trust boundary, formulated as the trust rule :

Definition: Trust Rule

Everybody inside a fortress trusts everybody else inside the fortress, and nobody inside the fortress trusts anybody outside the fortress.

The trust rule tells us that within a fortress there is complete trust, kind of a technical utopia. This concept is perhaps the most radical idea of the software fortress model. Consider, for example, a data strongbox implemented as a database. One implication of the trust rule is that the database applies no security at all to data update requests . No security at all! Can you believe it?

Actually it isn't quite that bad. It isn't that the database will have no security constraints, just that the constraints will serve only to ensure that update requests are coming from within the fortress. After convincing itself that a particular update request originated from within the fortress, the database will accept the request. No more questions asked.

This is not to say that we do not restrict who can update data. It is just that the database is not where we enforce the restrictions. But if not the database, then where?

In the software fortress model, security is the responsibility of four units working together. The wall keeps the hostile world at bay. The drawbridge allows controlled access from those few members of the outside world that this fortress is willing to trust. The guard makes sure that requests coming through the drawbridge are from authorized sources. And the envoy ensures that communications heading to other fortresses meet the security requirements of those fortresses' guards .

If the wall is doing its job, ultimately the guard controls access to the fortress. Once you gain access to the fortress interior, the trust rule says that you can access anything inside the fortress, including the database. With regard to database security, it isn't that we don't control who can access the database; it's just that we don't give the responsibility for controlling that access to the database. We give that responsibility to the guard.

This access control is applicable not only to the data strongbox, but to the different software systems within the fortress. If we have a software system in, say, a banking fortress that can take money out of your savings account, the scary truth is that anybody can withdraw money from your savings account. Anybody, that is, who can get past the guard.

Given that we place no security in either the database or the individual software systems within the fortress (other than ensuring that requests originate from within the fortress), you might expect the software fortress architecture to be inherently insecure . Not so. Security is a major focus of the software fortress model. The removal of security responsibilities from the individual entities doesn't weaken the overall security of the fortress; it actually strengthens security.

Security is strengthened because it is consolidated in a single location. If you think about it, you will realize that very few programmers have the knowledge needed to build a truly secure system. Database administrators think they know a lot about security, but in fact they know very little.

By making one well-defined entity within the software fortress responsible for security, you can consolidate your scarce security resources to the one spot that will benefit everybody in the fortress. The software fortress model tells you to invest your domain expertise in the business application implementations , your database expertise in the back-end data strongboxes, and your security expertise in the implementation of the guard.

Some people mistakenly think that this security model allows anybody from outside the fortress to do anything they want inside the fortress, once they have gotten past the guard. This idea is incorrect on many fronts. First, nobody from outside the fortress "gets inside" the fortress at all. Even the drawbridge request does not enter the fortress.

The only one who ever sees the outside request is the guard. The guard receives the request. The guard determines both the identity of the sender and what the sender wants to do. The guard then decides whether or not to allow that particular sender to make that particular request. If the guard accepts the request, the guard then makes its own request to workers inside the fortress. The request the workers see will be from the guard (or from other workers inside the fortress). Fortress workers never see the original request.

Obviously, getting the guards and walls right is critical to the well-being of the entire fortress. Chapter 7 (Guards and Walls) covers this topic.