My question regards the best practice / industry standards to prevent rogue users/admins from directly logging into the database console and updating sensitive information such as financial info / balances, etc as opposed to using the software which would otherwise validate the user's actions.
I ask this because the software I maintain has a rudimentary anti-tamper mechanism. A set of fields from each table are check-summed prior to insertion or updating and the resulting signature is stored in each record. When the record is next loaded from the database, the signature is recalculated and compared to the signature previously persisted in the database. If the signatures differ, then an alarm is raised.
There are some challenges with this approach, for instance in the event that new fields need to be added to the signature, this renders all existing signatures outdated. Thus, they either need to be migrated or somehow versioned. Migrating millions of records is not an option. I guess for me, its a case that the mechanism needs to be reworked to encode the version identifier in the signature. Additionally this approach won't catch deleted records. The biggest flaw with this approach is that a user with an initial high balance (ideal record state) could transact and replace his/her record back to its ideal initial state after each transaction. No alarm would be raised as the signature does not take into account previous record states.
I have found so many holes with the concept and implementation of this mechanism that its got me wondering, how does the rest of the world handle this? Banks? Insurance Companies? Financial Institutions?
I imagine that keeping ssh and database access on lock-down is entirely sufficient.
Essentially my question is: Am I correct in saying that this solution smacks of over engineering, or is the basis of the idea sound?