7.3 Auditing

Auditing refers to the ability to track all changes to the internal state of a fortress. Because the state of the fortress is effectively the content of the data strongbox, we can say that auditing is the ability to track all changes to the data strongbox.

There are four things we want tracked in an auditing system:

1. The fortress that made the request resulting in the change.

2. The exact request the fortress made.

3. The data that was sent with the request.

4. The time the request was made.

Other bits of information may be included in the audit trail, but these are the main points.

Hypothetically, auditing could be done in several places. It could be done at the worker level, with each worker in the fortress, when asked to do something, logging that request. It could be done within the database itself, which is where the database vendors , with their egocentric view of the world, recommend it be done. It could be done by Gwen. Where should it be done?

In my view, auditing at either the worker or the database level makes no sense. The workers have no way of knowing which fortress originated the request, what the original request looked like, what data was sent in, or even when the request was made. The database is even further removed from this information. So neither the worker nor the database is in a good position to take on serious audit responsibility.

The only one who has access to the exact information we want audited is good old reliable Gwen. Gwen is not only the obvious candidate for auditing; she is, in my view, the only candidate. Not every fortress may need to have requests audited. For those that do, Gwen is our girl.

Auditing is not only useful for security purposes; it can also be useful for debugging. At the enterprise level, debugging often requires careful workflow tracking, as one tries to determine when an error first occurred. The ability to dynamically turn on auditing at the fortress level can be a big help in these unpleasant situations.