Secured history

If the option Secure History is set in a database, all changes that users have made and released are hashed and stored in a separate area of the database.

This ensures that data written to the history by Aeneis cannot be subsequently changed.

In Secured History mode, the following functions are disabled:

• Compress history

• Switching inverse category attributes from persisted to virtual and vice versa

• Deleting old entries from the classic audit trail

Hash:

This hash is formed from the following contents:

• The changed data

• The timestamp at which the changes are made

• The ID of the user(s) who made the changes

A check function allows the content to be hashed again at any later time and it can be checked whether the content has been changed.

In addition, all changes in the database are mapped sequentially and the individual changes are additionally encrypted using a second hash, which is derived from the hash of the previous action. This also ensures that a user's entire actions cannot be deleted afterwards: the check of the subsequent action would fail.

Even in the event that third parties are able to replicate the mechanism by which the hash values are formed and rebuild all the hashes after tampering, it is possible to determine whether such tampering has taken place by comparing them with backup copies of the hashes.

A short form of the check is executed each time the server is restarted. If irregularities are found here, a detailed check is automatically performed and an email is sent to the administrator or addressee named in the escalation email template.