An Architecture for Regulatory Compliant Database Management

Abstract

Abstract-Spurred by financial scandals and privacy concerns, governments worldwide have moved to ensure confidence in digital records by regulating their retention and deletion. These requirements have led to a huge market for compliance storage servers, which ensure that data are not shredded or altered before the end of their mandatory retention period. These servers preserve unstructured and semi-structured data at a file-level granularity: email, spreadsheets, reports, instant messages. In this paper, we extend this level of protection to structured data residing in relational databases. We propose a compliant DBMS architecture and two refinements that illustrate the additional security that one can gain with only a slight performance penalty, with almost no modifications to the DBMS kernel. We evaluate our proposed architecture through experiments with TPC-C on a high-performance DBMS, and show that the runtime overhead for transaction processing is approximately 10% in typical configurations.

Efficient audit-based compliance for relational data retention

“…Intuitively, the audit succeeds if the hash from the old DB snapshot D o , plus the hash of all the new tuples introduced in the transaction log L, is equal to the hash of the current instance D c . Slightly abusing notation, we can write this as the following tuple completeness condition: [16] H…”

“…In current legal interpretations of email compliance, the regret interval is zero, meaning that email must be archived on WORM before it is delivered to its recipient. The architects of LDA argued that to ensure good DBMS performance, we need a non-zero regret interval [16]. Current practice in industry is to dump a snapshot of the database contents and current log files to WORM periodically, making the regret interval at least a day long.…”

“…Researchers have noted that it is impractical to provide term-immutability by making every tuple a separate file, making a new copy of the database file on every update, or moving the DBMS functionality into the WORM storage server [16]. A DBMS that supports term-immutability must consist of untrusted code that communicates with the (trusted) WORM storage server over as narrow an interface as possible.…”

“…Recently, researchers have proposed a scheme for supporting term-immutability in databases [16]. Their approach, called the log-consistent DBMS architecture (LDA), turns every tuple insert, delete, and update request into the creation of a new version of the tuple.…”

“…Primary threat: forgery of history. We use the regret-based threat model for databases, as introduced in [16]. This threat model captures the way that falsification of historical records typically happens in the situations targeted by Sarbanes-Oxley and SEC Rule 17a-4.…”