GDPR’s right to be forgotten means we have to be able to erase a person’s data from our systems. Event sourced systems work from an immutable log of events which makes erasure difficult. You probably want to think hard about storing data you need to delete in an immutable event log but sometimes that choice is already made and you need to make it work, so let’s dig in.
Erasing user data from current state projections
This is relatively straightforward. A RightToBeForgottenInvoked event is added to the event store for the person. All projectors that depend on personal data listen for this event and prune or scrub the appropriate data for the person from their projections.
Erasing data from the event stream itself
This case is trickier. We need to rewrite history in a way that doesn’t break things. Let’s look at an option for erasing data without rebuilding the event stream. This approach is also applicable for projections that are immutable change logs.
We can store personal data outside of events themselves in a separate storage layer. Each event instead stores a key for retrieving the data from this layer and any event consumers request the data when they need it. Given this data is personal the storage layer should probably encrypt the data at rest.
Once a RightToBeForgottenInvoked event is added to the event store all data for that person can be erased from the storage layer. All subsequent requests for data from the secure storage layer for that person’s data will return null objects rather than the actual data. This should make life easier for all consumers and avoid you null checking yourself to death all over the place.
Let’s see what this secure storage layer might look like.
Sketch of a secure storage layer
Our secure storage layer stores data that is scoped to a person and has a type (so we can return null objects). The store allows all data for a specific person to be erased.
Let’s start with two main models: a Person and a Data model.
Data Person
┌──────────┐ ┌───────────────┐
│ id │ ┌───>│ id │
├──────────┤ │ ├───────────────┤
│person_id │───┘ │encryption_key │
├──────────┤ ├───────────────┤
│ type │ │ is_erased │
├──────────┤ └───────────────┘
│ciphertext│
└──────────┘
The interface to the secure storage layer is outlined below.
class SecureStorage
def add(person_id, data_id, type, data)
# Find the Person model for person_id (lazily create one if needed).
#
# Encrypt the data using the person's encryption_key and store the
# ciphertext in the data table using the client supplied data_id and type.
#
# Clients will store this data_id in an event body and use it to retrieve
# the data later.
end
def erase_data_for_person(person_id)
# Mark the corresponding record in the person table as erased
# and delete the encryption key.
end
def get(data_id)
person = Person.find_non_erased(person_id)
if person
# Look up the row from the data table, decrypt ciphertext using the
# key on the person model, and return the data.
else
# Look up the row from the data table and return a null object for
# that data type.
end
end
end
Where does that leave us?
After a person has invoked their right to be forgotten all current state projections will be updated to erase that person’s data. The event store will return null objects for any events that contain data for the person which means that any event processors won’t see that data as they build their projections. It will also contain the RightToBeForgottenInvoked event for the person so consumers can handle that explicitly if required.
🔗
∙ Tagged in Software Design.
]]>
