SchengenDB: A Data Protection Database Proposal

Abstract

GDPR in Europe and similar regulations, such as the California CCPA, require new levels of privacy support for consumers. Most challenging to IT departments is the "right to be forgotten". Hence, an enterprise must ensure that ALL information about a specific consumer be deleted from enterprise storage, when requested. Since enterprises are internally heavily "siloed", sharing of information is usually accomplished by copying data between systems. This makes finding and deleting all copies of data on a particular consumer difficult. GDPR also requires the notion of purposes, which is an access control model orthogonal to the one customarily in SQL. Herein, we sketch an implementation of purposes and show how it fits within a conventional access control framework. We then propose two solutions to supporting GDPR in a DBMS. When a "green field" environment is present, we propose a solution which directly supports the process of ensuring GDPR compliance at enterprise-scale. Specifically, it is designed to store every fact about a consumer exactly once. Therefore, the right to be forgotten is readily supported by deleting that fact. On the other hand, when dealing with legacy systems in the enterprise, we propose a second solution which tracks all copies of personal information, so they can be deleted on request. Of course, this solution entails additional overhead in the DBMS. Once data leaves the DBMS, it is in some application. We propose "sandboxing" applications in a novel way that will prevent them from leaking data to the outside world when inappropriate. Lastly, we discuss the challenges associated with auditing and logging of data. This paper sketches the design of the above GDPR compliant facilities, which we collectively term SchengenDB.

The Impact of Privacy Regulations on DB Systems

“…[ Kraska et al 2019] describe an end-to-end system, from application requirements to the DBMS, as well as a purpose-based data access model, in which purpose filters act between query execution and retrieval to avoid data leaking to unwanted purposes. These filters are added through bit vectors associated with each tuple.…”

“…GDPRBench [Shastri et al 2020] evaluates this impact by adding a time-to-live attribute to data, and using a daemon or adding this functionality to the DBMS to periodically probe the data in search of TTL violations, as well as deleting them when needed. [Kraska et al 2019] point out that when an entry is deleted in their system, the surrogate keys become dangling, rendering data access impossible. Sypse [Deshpande 2021] proposes the deletion of synthetic data as a form of removal, since it would be impossible to decrypt keys.…”

“…Other existing works deal with that by associating purposes to tuples as bit-vectors [Kraska et al 2019] and creating purpose filters to avoid unwanted data leaking. In an application sense, it also describes a "sandbox" mechanism in which the DBMS would only be accessible by applications through specific VMs, each with their own purpose.…”

“…Other cited works also have solutions for this component, be them explicit, such as Sypse [Deshpande 2021] personal information partition, or implicit, like SchengenDB [Kraska et al 2019] and GDPRBench [Shastri et al 2020], which embed the information within data. Although there is not a clear separation of user related data, it is retrievable through its unique identifiers.…”

ConSQL: Consentimentos em SQL para o Processamento de Consultas Orientado a Propósitos

“…O ConSQL representa propósitos como conjuntos de dados visto que esse modelo nos permite lidar com os propósitos de maneira simplificada e, como mostram [Kraska et al 2019], é uma maneira de reduzir o espaço de armazenamento ocupado pelos metadados de propósito. Dessa forma, os propósitos definidos para um banco de dados são armazenados em estruturas de dados associadas ao esquema, de modo a permitir a recuperação quando necessário.…”