Managing Complexity and Privacy Debt with Drupal
0 likes190 views
The document discusses managing complexity and privacy debt in modern software, particularly through the use of Drupal. It highlights the challenges associated with intricate software systems and the implications of GDPR on data management, advocating for uniformity and centralization in handling private data. Additionally, it outlines how Drupal can effectively serve as a tool to manage privacy issues and data rights, offering various features and modules to facilitate compliance.
Managing Complexity and Privacy Debt with Drupal
- 1. Janne Kalliola Exove Managing Complexity and Privacy Debt with Drupal Tallinn, November 2, 2018
- 2. Agenda § About Exove and myself § Complexity in modern software § Privacy debt § Drupal to rescue
- 3. About Exove § Digital design and development company in Finland, Estonia, the UK, and Singapore § Full service portfolio from business consulting and service design to development and care § We serve both multinational giants and new start-ups alike We deliver digital growth More about us: § www.exove.com § www.exove.com/gdpr § @exove
- 4. About Janne Kalliola § Founder and CEO of Exove § Continuent, First Hop, SSH, Helsinki University of Technology § Been coding since 1983, first web stuff in 1994 § Worked with web publishing and content managements systems since 1999 § I’ve written three CMS in the past § Worked with open source since 1998, with Drupal from 2007 More about me: § www.kallio.la § linkedin.com/in/jannekalliola § @plastic
- 6. Complexity and Modern Software § Modern software development practices, the fast pace of the industry, and changing demands cause software platforms to be layered, multifaceted and complicated systems § A systems consists of numerous interconnected subsystems created with various technologies, deployed with different tools, and hosted in several places § The complexity of the system is easily hidden under number of layers and facades
- 7. Privacy Aspect § GDPR requires companies to specify how they manage private data § If the system is complicated – as they typically are – understanding the management is hard § Besides, there are number of places were private data is stored temporarily of permanently during processing § Log files, etc. § This is not the focus of today’s discussion, but it is good to know
- 8. Documentation Can Mislead § A typical IT system documentation is non-existent § If it does exist, the documentation is typically somewhat simplified view of the architecture § Sometimes very simplified § Finally, it is most probably also outdated § If the system’s documentation is from era before GDPR, it does not focus on data privacy much or at all
- 10. The Same System, Zoomed in
- 11. § Varnish or CDN in the front § Web server logs § Platform logs § Local caches § Uploaded binary files § Maillog of all the sent emails § Backups of the servers
- 12. § SQL logs § Binary logs on all servers § Backups of binary logs § Database dumps made by developers § Production dumps to staging environment
- 13. § Integration platform logs and local caches § Integration platform document DB oplogs § SaaS messaging platform logs and internal database
- 14. § Finally the actual data master, its logs, backups and development environment
- 15. And That Was Just Data Flows and Storages § The previous example was just about data flows and storages § It was the physical architecture of a modern platform § The logical architecture should reflect the desired functionality of the system § To save time, we do not go through it right now for that system § The logical architecture can be easily even messier – as the requirements of the system change during years, new features are added, and old ones are deprecated
- 16. Debt § Every change that is not done “perfectly” creates debt § Bad architecture, wrong components, and features hacked in create technical debt § Non-uniform ways to manage private data and distributing / spreading out private data create privacy debt § Payment is due – sooner or later § Debt is paid in refactoring § Interest is paid when new features take longer to implement or cannot be done in an optimal fashion
- 17. Privacy Debt A concept in software architectures that reflects the implied cost of additional work caused by choosing a non-uniform solution to handle private data instead of using a commonly used or more centralised approach.
- 18. Privacy Debt in Practice § Every time a new way to deal with private data is added to the system, the complexity – and privacy debt – increases § And vice versa, if something is centralised or made more uniform, the debt decreases § The debt is paid every time an individual uses one of her rights § The right honouring process is more complex than it could be due to various different ways how handling of private data is implemented
- 19. Reducing the Privacy Debt § Uniformity: Define and apply uniform ways to handle private data. The data itself is typically mostly the same in most of the systems, and it can be handled using the same procedures. If possible, define the data uniformly and use that definition in all systems applicable § Reduction: Move data outside of the systems, such as using SSO solution, and minimise the personal data stored in a business system § Encapsulation: Require all new systems to expose APIs to ensure the users’ rights on that system § Centralisation: Create a centralised system that handles all – or the bulk of – users’ rights. Connect all your systems, one by one, to this centralised private data management platform
- 20. Drupal and Privacy Debt
- 21. Drupal to Rescue § Drupal has numerous built-in tools to manage arbitrary content, structured and unstructured § And more can be installed as modules § Private data is at the end just data, and it can be managed with the same tools § Besides, Drupal has also a good user rights management subsystem § GPDR requires restricting access to private data to only those that need it § This can be achieved easily with Drupal’s user rights
- 22. API and Headlessness § Drupal has extensive REST API § It can thus be used also as a headless private data repository § The centralised solution to manage privacy debt § Authentication, authorisation, and user rights allow controlling external access of private data § Thus every system does not get to see the full amount of data, but only the relevant subset – this, of course, requires careful planning of the data structures § It can also be integrated with other systems to work as a consumer of private data
- 23. Rules § Besides storage and connectivity, Drupal can be used also as a private data automatic management platform § Private data can be altered and removed using Rules functionality § Of course, creating own modules to manipulate the data is also an option § Especially, if the business logic is hard to implement with Rules
- 24. Views § As Drupal is also a publishing platform, various end-user views can be constructed easily § These can be either for viewing only or also CRUD operations for the data § Again, restricted and controlled by the user rights § Drupal admin ui provides quick and easy way to implement these § But implementing real end-user templates might make the system more approachable to a common user § And the functionality can be different for people having access to the front-end and those having access to the Drupal admin ui in its entirety
- 25. GDPR User Rights and Drupal § GDPR rights (right of rectification, right of removal, etc.) can be implemented using Drupal’s admin UI § An user wanting to exercise rights contacts an operator with admin rights and the operator makes the changes within admin UI § Another option is to provide users a self-service view to see their information as a normal Drupal provided webpage § Depending on the business/use case, there might be also possibility to remove and change the information as self-service § Or then a simple contact form or email address to send the requests to an operator
- 26. GDPR Module § There is a specific GDPR module for Drupal § https://www.drupal.org/project/gdpr § The focus of the module is to provide support for handling GDPR requirements and user rights in websites powered by Drupal § The module is not straightforwardly useful in this scenario § However, GDPR fields and GDPR tasks submodules could have benefits in organising the information § As usual, your mileage may vary when using modules to something else than their precise intended purpose § The future features look interesting – thus consider contributing
- 27. Caveat Emptor § Remember, that Drupal has a nasty habit of creating users automatically when using external authentication service § Each external user ever logged in has a Drupal account § And this feature cannot be turned off § Thus, you will end up spreading your user information to a new platform – whether you like it or not
- 28. Recap
- 29. Recap § Complexity combined with privacy requirements can make systems very hard to manage § Concept of privacy debt allows you to think the future consequences of bad choices made today § Drupal is an excellent tool to manage private data due to its versality, readymade tools, and adaptivity in various scenarios