News for hackers. Stuff that matters.
Re:How GDPR Will Change The Way You Develop by boredatwork on Tuesday February 27, 2018 @04:20PM (#16478029)
Sure I delete files that I don't like, but I don't typically rewrite all my old backups to purge them from there too.
Re:How GDPR Will Change The Way You Develop by ncallaway on Tuesday February 27, 2018 @09:30PM (#16480199)
This is my biggest question about HIPAA and GDPR about deleting specific user records and data.

How are others planning on deleting data from all backups. It seems like any automatic process that modifies all existing backups has the potential to accidentally corrupt all backups in the process.

Is there any safe way to safely delete a record out of my prior database snapshots, or is there a reason I don't actually need to do this?

Re:How GDPR Will Change The Way You Develop by com on Wednesday February 28, 2018 @01:08AM (#16481045)
Encrypt the data element using a nonce, encrypt the nonce using a public key whose private key will be purged from your HSM/SCD/key management system on a scheduled basis. You will need to retain metadata about the key ID too.

Don’t leak private keys, so you should generally use a decryption service if you need access to the data record. Handy to prove access too!

That works and survives fairly intense audits at least in my experience.

Re:How GDPR Will Change The Way You Develop by lawik on Wednesday February 28, 2018 @07:17AM (#16482452)
Do you maintain your database backups indefinitely? If they rotate out after a month or so you will likely be inside the realm of what GDPR considers reasonable compliance. The live data is removed ASAP and the data will rotate out from the backups in a reasonable time frame. At least from the legal advice we've had.

We have no plans to retroactively fix our backups. But we will have to make damn sure that if we need to use a database backup we do not reintroduce user data that we've purged. For that purpose we will have to maintain a list of which users have been purged until the backups rotate out. According to the advice we've had, this is acceptable.

Re:How GDPR Will Change The Way You Develop by ncallaway on Wednesday February 28, 2018 @11:02AM (#16483828)
> But we will have to make damn sure that if we need to use a database backup we do not reintroduce user data that we've purged. For that purpose we will have to maintain a list of which users have been purged until the backups rotate out.

This is the approach we've generally taken as well.

Re:How GDPR Will Change The Way You Develop by leesalminen on Tuesday February 27, 2018 @10:22PM (#16480444)
This has been the insurmountable issue for us, thus far.
Re:How GDPR Will Change The Way You Develop by fleetingmoments on Wednesday February 28, 2018 @07:49AM (#16482609)
What if you're using an append-only log, like Kafka as your data backbone?
Re:How GDPR Will Change The Way You Develop by wsy on Wednesday February 28, 2018 @03:58PM (#16486836)
Two options: a) use a reasonably short retention period, e.g. 6 weeks b) if you key your entries in Kafka, a new entry with the same key will overwrite the old one. That way you could overwrite PII content with an empty message.
Re:How GDPR Will Change The Way You Develop by boredatwork on Wednesday February 28, 2018 @09:41AM (#16483270)
You got a big problem.
Re:How GDPR Will Change The Way You Develop by _o_ on Wednesday February 28, 2018 @02:30AM (#16481354)
Once you have a way to backup data per user, just encrypt them with random key and once the account is deleted, delete the random key. We have done it this way, with having multiple live copies of backup key table on multiple locations and beeing backed up daily purging previous backup. The hard thing was to group the data in a way where we can encrypt them with users random key.

I hope I was helpful :)

Re:How GDPR Will Change The Way You Develop by rimliu on Wednesday February 28, 2018 @03:18AM (#16481522)
How do you manage/keep the keys?
Re:How GDPR Will Change The Way You Develop by SahAssar on Tuesday February 27, 2018 @05:15PM (#16478521)
A file does not really exist unless it is backuped, and it's not really deleted unless it is not backuped.