GDPR for developers
Download as PPTX, PDF7 likes8,858 views
GDPR for developers is a document about the General Data Protection Regulation (GDPR) and what software developers need to do to comply. It discusses key GDPR concepts like the rights of data subjects, lawful processing of personal data, and security measures. It provides practical advice for implementing GDPR principles in software like obtaining consent, handling data subject requests, and responding to data breaches. The overall message is that GDPR compliance requires changes to protect personal data but many can be done incrementally without a full rewrite.
GDPR for developers
- 1. GDPR for developers Bozhidar Bozhanov
- 2. About me • Founder and CEO of LogSentinel • Former IT advisor to the deputy prime minister of Bulgaria • Software engineer • Privacy advocate • Top 50 stackoverflow contributor • https://techblog.bozho.net • @bozhobg
- 3. What is GDPR? Regulation Panic! Opportunity • a.k.a. direct common EU law • overrides / supercedes national data protection laws • extends the existing directive • Huge fines for non-compliance (4% of turnover or 20 million euro) • Insufficient understanding on what has to be done (consultants, regulators, companies) • To really protect your customers’ data • To get your systems secure
- 4. Pros and cons of GDPR • Cons: • Bureaucratic • Not always clear • Requires most systems to be upgraded (burden) • Doesn’t solve all data protection issues • Leaves issues at the discretion of local regulators • Pros: • Unifies data protection in Europe • Mandates best practices • Requires consciousness about personal data processing
- 5. Why do YOU care? • You may be: • implementing GDPR-related upgrades • be designated as a DPO (data protection officer) • implementing anything that handles data • conscious about personal data in your organization
- 6. Terminology Data subject Personal data Data processing • a.k.a. User (person whose personal data is processed) • Any data about an identifiable or identified person • Any operation (manual or automated) on personal data Controller • The entity (company) that requests and uses the data Processor • Any entity that processes data on behalf of a controller (e.g. cloud service providers)
- 7. GDPR principles Lawfulness Purpose limitation Data minimisation Accuracy Storage limitation Integrity and confidentiality …magic
- 8. What about cookies? • ePrivacy directive -> ePrivacy regulation • Somehow different than GDPR • Answers some questions unanswered by GDPR: • Tracking cookies • Traffic data • Direct marketing • Opinion – should have been a unified regulation • With the upcoming ePrivacy regulation – no more useless cookie warnings • Also: directive for processing personal data by law enforcement
- 9. When to process personal data • User’s consent • Performance of a contract • If required by law • Legitimate interest of the controller (including direct marketing) • Combination of the above
- 10. GDPR functionalities • Functionalities are only part of it – processes/procedures/rules must also exist • “Forget me” (the right to erasure) • Mark profile as restricted (right to restriction of processing) • Export data (right to portability) • Allow profile editing (right to rectification) • “See all my data” (right to access) • Consent checkboxes • Age checks • Data destruction (data minimization principle)
- 11. “Forget me” • Delete all data relating to a user • void forgetUser(UUID userId); • Useful for integration tests • What about foreign keys? • Allow nullable foreign keys • Anonymize user (leave only ID) • Cascade delete • Option: mark for deletion (+user cleanup job)
- 12. “Forget me” • Event-sourcing? • Crypto-shredding • Blockchain? • Notify 3rd parties / call 3rd parties APIs: • CRMs, Payment gateways, etc. • Return 404 for indexable pages • Backups – store anonymized IDs separately • “My data model doesn’t allow for it” is no excuse
- 13. Restrict processing • Mark user as “restricted” • Boolean database column • Button on profile page “restrict processing of personal data” • Button on admin page • Don’t show in searches, don’t send emails, don’t include in automated processing • Mark as restricted in 3rd party systems (e.g. with a custom field) • Don’t show on public pages / 404 • Why? • Edge cases: user objects to erasure;
- 14. Export data • Right to data portability (no vendor lock-in; in theory) • Formats: JSON, XML, CSV or other standards • Schema: prefer schema.org • Could be a background process that sends email when done • Could be a manual process (easier to get compliant) • All personal data + all data, associated with the user (orders, messages, etc.) • Logs? No • Data from 3rd party systems? Yes • they should have that functionality as well
- 15. Editable user profile • Right to rectification • All personal data fields should be editable • Could be a manual support process: “please fix my name” • Data obtained from 3rd parties • If email/phone is included, user should be able to identify with that email/phone (“shadow accounts”) • If not – manual process
- 16. Ask for consent • No more “I accept the Terms and conditions and the privacy policy” • Unchecked checkbox for each processing purpose on registration • Data processing business processes to be listed in a register • User should be able to withdraw consent from the user profile page • If data is used for machine learning, get explicit consent for that • Store consent in a secure way • Boolean column may or may not be enough, depending on the regulator • Consents table? • Timestamping? • Re-request consent for existing users via email • Oral consent • Workarounds: consent vs contract with electronic signature?
- 17. “See my data” • Overlaps with “export data” • Allow non-registered users to check if you have data about them • Confirm email • Show the processing records from the register
- 18. Age check • On registration ask for age / date of birth / (checked) checkbox “I’m older than 16” • Ask parent for consent • How? • Nobody has a clue • “The controller shall make reasonable efforts to verify in such cases that consent is given or authorised by the holder of parental responsibility over the child, taking into consideration available technology.” • Proposal: ask for parent’s email, send a link and get the registration confirmed • Proposal: upload “parent selfie” • Proposal: eID
- 19. Limit data retention • Don’t store data for longer than “necessary” • Database column for “data retention deadline” • Scheduled job to delete/anonymize/pseudonymize data that past its deadline • Deadline vs confirmation event, e.g. “goods delivered” • Applicable to “purchase without registration” • Theoretically applicable to registered users • In practice: “I agree to having my address stored for the purpose of not entering it again on subsequent purchases”
- 20. Do’s (encryption) • Encrypt data in transit • between application and database • between application and 3rd parties • between application and database nodes (gossip) • between multiple applications / microservices • obviously: between user and application • between load balancer and application? • Encrypt data at rest • LUKS or database-specific encryption • Encryption key: ideally on HSM / AWS KMS / … • Encrypt backups
- 21. Do’s • Implement pseudonymization • replace personal data with bcrypt/PBKDF? • don’t use real production data for staging/test • pseudonymize for machine learning purposes • Protect data integrity • Simple solution: do nothing Procedures should indicate integrity is guaranteed by the database via checksums • Other options: checksum column per record, enforced in the application layer, audit trail, 3rd party solutions like LogSentinel
- 22. Do’s • Have your GDPR register of processing activities in something other than Excel • Internal web app / microservice or a 3rd party service • Integrate with consent checkboxes and “right to access” • Correlate audit logs with processing activities • Audit log for the register itself • Backups, high availability • Log access to personal data • Implied from the accountability principles • Correlate with processing activity • Search results / lists? Log “User X did query Y” • Register all API consumers (no anonymous access)
- 23. Data breaches • Notify data protection regulator • Notify controllers (if you are a processor) • Notify users • Option: Configure your security incident system to report to the data protection regulator • Have proof of when the breach was discovered (timestamp emails/issues?) • Will it help? Questionable • (Dilbert)
- 24. Don’t’s • Don’t use data for purposes other than what he user has agreed with • Request consent via email for new purposes • Legitimate interests can be dynamically added • Don’t log personal data – just ID • Cleanup old log files • Don’t put unnecessary registration fields • Don’t assume 3rd parties are compliant • Don’t assume having ISO XXX makes you compliant • Don’t dump personal data on public servers/buckets • …and other obvious stuff
- 25. Conclusion • GDPR would require changes, mostly • Best practices • Useful to customers • The majority of changes can be implemented within 2-3 sprints • GDPR forces better understanding of data flows • Compliance likely to be checklist-based • Beware of consultants claiming GDPR will require rewriting everything and asking for a lot of money • Regulators will need some teaching • The spirit of the regulation: be conscious about personal data
- 26. Thank you Bozhidar Bozhanov: bozhidar.bozhanov@logsentinel.com