An Audit Trail is typically a chronological set of records to provide conclusive set of evidence on how a system ended in its current state. Very often the trail contains also information on what kind of data has been extracted from the system during the monitoring interval.
Collecting Audit Information is important in several kinds of systems that contain financially or otherwise sensitive information and have any risk of being subject to misuse or fraud.
For database systems, auditing all access to database can be set up on multiple levels. This section describes solidDB’s audit features that will collect information on user and login information changes, data model changes, actual SQL operations modifying and accessing the data and certain operational events.
▪The AuditTrailEnabled mechanism is based on collecting information to a system table about changes in user definitions and database model. The information is available in system table to be accessed for auditing purposes. Due to data model changes and user definitions being relatively rare events the size of this table can be expected to be low or moderate at most.
▪The AuditInfoLogEnabled mechanism is based on creating external files to file system that can contain all the information provided by AuditTrailEnabled and optionally all SQL being executed at the server plus some operational events. In systems with high workload this files can be very large. Processing and archiving the files should be designed separately.
In addition to collecting records on auditable level using database mechanisms, there are other possible ways to build up auditing policies in a system such as building auditing tables in the database on application level or tracking operations on client side.