AxonIQ GDPR Module Overview - Feb 2018

Contact me: frans.vanbuul@axoniq.io Follow me: @Frans_vanBuul
Event sourcing,
GDPR Article 17,
and the AxonIQ GDPR Module
Frans van Buul
Evangelist, AxonIQ

Event-driven
architecture
“a software architecture
pattern promoting the
production, detection,
consumption of, and reaction
to events”
https://en.wikipedia.org/wiki/Event-driven_architecture

Event sourced persistence
A mechanism to store and retrieve data from a
program’s working memory into something
more permanent, like a database.

Traditional persistence
• Store the current state
directly to database
• CRUD operations

Traditional persistence Event Sourcing
• Store the current state
directly to database
• CRUD operations
• All state change through
events.
• Events are distributed and
persisted to an event store.
• To access current state,
replay events.
• Events are immutable and
undeletable.

Traditional persistence
Example
Event Sourcing
Order
customer: Frans
1 pizza
1 soda
OrderCreated(customer Frans)
ProductAdded(pizza)
ProductAdded(icecream)
ProductAdded(soda)
ProductRemoved(icecream)
OrderConfirmed

Business reasons Technical reasons
Why use event sourcing?
• Auditing / compliance /
transparency
• Data mining, analytics:
value from data
• Guaranteed completeness of raised
events
• Single source of truth
• Concurrency / conflict resolution
• Facilitates debugging
• Replay into new read models (CQRS)
• Easily capturing intent

Article 17 GDPR
Right to erasure (‘right to be forgotten’)
1. The data subject shall have the right to obtain from the
controller the erasure of personal data concerning him or
her without undue delay and the controller shall have the
obligation to erase personal data without undue delay
where one of the following grounds applies:
……

GDPR vs Event Sourcing
• Generally, very good match because of transparency
• There’s also a challenge
Erasure is
sometimes
mandatory
Events are
immutable and
undeletable
?
GDPR Event Sourcing
Let’s have a look at some ideas!

Idea
Deleting/modifying events
• Delete events anyhow
Reconciling mandatory erasure and the immutable event store

Idea Problems
Deleting/modifying events
• Delete events anyhow
• Modify events anyhow, e.g.
by overwriting field values
• Difficult/expensive to
implement consistently
• Expensive to execute,
especially on a true append-
only event store.
• Diminishes value/reliability
of event store

Idea
Re-interpret the law
• “The law only requires deletion
from operational storage, so that’s
read models in CQRS. An event
store is like a back-up and that’s
excluded from the law.”
• “Data needed for legal claims is
excluded from art 17 (by 17.3.c).
I intend to use my events to
support legal claims. Therefore my
event store is excluded.”

Idea Problems
Re-interpret the law
• No. That violates the
minimization principle.
• No. There’s simply nothing like
that in the law.
• “The law only requires deletion
from operational storage, so that’s
read models in CQRS. An event
store is like a back-up and that’s
excluded from the law. ”
• “Data needed for legal claims is
excluded from art 17 (by 17.3.c).
I intend to use my events to
support legal claims. Therefore my
event store is excluded.”

Idea
Separate contexts
• Store non-personal data in
an event sourced context.
• Store personal data in an
non-event sourced context.
• Bring them together when
needed in read-model
projections.

Idea Problems
Separate contexts
• Store non-personal data in
an event sourced context.
• Store personal data in an
non-event sourced context.
• Bring them together when
needed in read-model
projections.
• Lots of complexity to keep
the mapping in place.
• Huge refactoring in existing
applications.
• Leads to unnatural domain
models in many situations.
• Loses all ES benefits for
personal data.

GDPR vs Event Sourcing
• Generally, very good match because of transparency
• There’s also a challenge
Erasure is
sometimes
mandatory
Events are
immutable and
undeletable
?
GDPR Event Sourcing
Existing ideas have major downsides

AxonIQ GDPR Module

Cryptographic erasure
Core idea:
• Store data in encrypted form
• To delete the data, throw away
the key
A.k.a. “crypto erase”, “crypto-
shredding”, “digital shredding”

Not a novel idea!
By Evan-Amos - Own work, CC BY-SA 3.0,
https://commons.wikimedia.org/w/index.php?curid=27940250
As data sanitization strategy:
• Built into “Self Encrypting Drives”
and enterprise-grade storage
arrays.
• Supported by storage security
standards:
• ISO/IEC 27040
• NIST SP 800-88 Rev 1

GDPR Module design goals
Implement crypto-erasure
on the application level, for Java
• Easily usable. No changes to business logic. Integration with Axon.
• Generally usable:
• With Axon 3, Axon 2 or without Axon at all.
• Independent of serialization and event store choices.
• Fine grained control. Decide what you want encrypted/erased.
• Highest possible, long-term security.

uses as
delegate
API Overview
<<class>>
FieldEncrypter
void encrypt(Object obj)
void decrypt(Object obj)
<<interface>>
CryptoEngine
SecretKey getOrCreateKey(String id)
SecretKey getKey(String id)
Cipher getCipher(SecretKey key)
void deleteKey(String id)
uses
Implementations:
• In memory
• JPA-backed
• JKS
• PKCS#11
<<class>>
FieldEncryptingSerializer
<<interface>>
Serializer
implements
uses
Driven by
annotations on the
object’s fields
Enables seamless Axon
Framework integration.
Three versions: axon3,
axon2, core.

Common questions
• Today's encryption may be hacked in the future – how can you
guarantee security?
• Is this allowed under GDPR?
• How about key management? Are keys secured?
• Is this open source?

Long-term security
• There are big difference in crypto algorithms here: we use the
symmetric AES algorithm, which is very different from e.g. RSA
• We recommend and default to using 256-bit keysize
• Best known cryptanalysis attack (Biclique) reduces this to 254.4 bits
• This will withstand any classic brute-force attack (given size of keyspace).
• This will also withstand the best known quantum attack (Grover's
algorithm)
This provides the long-term security that is the
basis for current use for disk sanitization and
its inclusion in NIST and ISO standards.

Is this allowed under GDPR?
• GDPR is explicitly "technology neutral"
• Is doesn't define "erasure"
This gives room to different technical
implementations of erasure.
• The strengths and weaknesses of crypto erasure should be compared
against other practices.
• Regular SQL DELETE doesn't event delete data from disk
Crypto erasure is at least as strong as
traditional DELETE and therefore a reasonable
technical implementation of "erasure".

Are keys secured?
• The module offers various options to store your keys, including
in a database (with regular database security) or a HSM. You
can also define your own by implementing an interface.
• But, from a risk analysis point of view, these crypto-erasure
keys are much like regular data!

Without cryptoerasure With cryptoerasure
Are keys secured?
Cleartext event
data record
Encrypted
event data
record
Key
Get access to this, and you
have the event data
Get access to this, and you
have the event data

Is the GDPR Module open source?
• No, it's a commercial, closed source offering.
• Flexible pricing scheme with both enterprise-wide
licenses as well as single project licenses on offer.
Contact us to discuss.
• We are 100% transparent about what the module does.
• The cryptographic scheme that we use is fully
described in the documentation and may e.g. be
provided to your security auditors.
• The scheme is not patented and may be implemented
by others.
Free as
in beer:
No
Open and
transparent:
Yes

Example scheme documentation
SecureRandom
pre_iv (int)
big-endian enc.
pre_iv (byte[])
MD5
AES/CBC/PKCS#5
cleartext byte[]
encrypted byte[]
MD5
digest byte[]
AES key
first 8 big-end dec
AES/ECB/NoPad first 8
iv
data
key
data
key
1
2
big-end dec
EncryptedFieldData
int32
version = 11
fixed32
pre_iv= 2
bytes
encrypted_value=3
fixed64
digest= 4
fixed64
enc_digest=5
bytes
partial_value=6
ReplacementValueProvider
#partialValueForStorage
Protobuf 3
encoding
encrypted byte[]

Where does this fit?
Part of a strategy to deal
with mandatory erasure
(driven by GDPR or
otherwise)
Easy to implement solution
for the erasure vs.
immutability problem
Request for
deletion Valid?
Yes
Raise specific
deletion event
Delete from
event store
Delete from
read models
Inform 3rd
parties
Keystore
Readmodel
database
AxonIQ
GDPR
Module
Request for
deletion
Inform data
subject
Deletion
acknowledge-
ment

Finally
Please contact me directly in case you have any questions after
this webinar
frans.vanbuul@axoniq.io
Want to learn about more about Axon Framework?
• We offer training:
https://axoniq.io/services/axon-training.html
On September 21th, we'll have our annual conference:
https://www.eventbrite.com/o/axoniq-15996042943
• Visit https://axoniq.io and subscribe to newsletter.

AxonIQ GDPR Module Overview - Feb 2018

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a AxonIQ GDPR Module Overview - Feb 2018

Semelhante a AxonIQ GDPR Module Overview - Feb 2018 (20)

Último

Último (20)

AxonIQ GDPR Module Overview - Feb 2018