3. Security

Security is a key concern of the Funder Data Platform. Our system has been developed in a way that allows us to be open about how everything is connected, without the risk of exposing data to the outside world. But it is also a system that builds on trust - meaning we also want to be open about the limitations to security that will always exist in a system like this. In the two sections below, you can read more about our thoughts on this.

3.1. Security measures

The Funder Data Platform implements the following security measures:

• Encrypted connections - All connections to the Funder Data Platform and the JupyterHub workspace happen over SSL (Secure Socket Layer), meaning that the data you enter into forms are encrypted during the transfer from your browser to our server.
• Encrypted personal data - All passwords are hashed using a strong, industry-standard algorithm (bcrypt), and email addresses are encrypted using secure key protocols. This means that in the case of a malicious attack on our system, a potential leak of a user list would expose nothing except for the names and usernames of our members.
• Layered backend security - Our system is maintained and hosted by Aarhus University, and access to the backend requires several layers of authentication.
• Organisational member control - It is not possible to sign up for the Funder Data Platform. Only organisations that have signed appropriate agreements with us are included, and only those organisations are able to invite new users to the system. This means that all users of the system are trusted parties.
• Organisational data control - Organisations maintain a high degree of control over their own data. They choose what data to share, if they want to create specific subsets (either of variables or observations) available to different projects, and whether they want to stop sharing their data.
• Isolated data storage - Data shared by funders is siloed away from the web platform and only accessible as "views" (read-restricted data access) to designated projects.
• Data access keys - Access to data views (see above) is restricted through the use of project-specific access keys. Without a key, views can not be accessed.
• SQL injection prevention - All database queries are sanitized and use "prepared statements" to prevent malicious attacks through SQL injection.
• Audit logging of sensitive operations - Access to critical system components is logged, including file downloads from the platform workspace, ensuring that key actions can be reviewed in the event of a security concern..
• Daily workspace backup - Should anything critical break or become deleted, we have options for restoring files that have become deleted or modified. Should this happen, please get in touch with us as soon as possible, as backups are only retained for a limited time.

3.1. Security considerations

• User access equals data access - Trusted users can export data they have been granted access to, in accordance with the project-specific agreements. Role-based access control is used to limit this access as much as possible, but the system necessarily permits users to work with their data.
• Governance through agreements - All projects on the platform are governed by collaboration agreements that define who may access which data and how that data may be used. These agreements are central to our trust-based model.
• Limitations of technical enforcement - While we cannot fully prevent the risk of a trusted user acting outside of agreed-upon boundaries, we have implemented multiple safeguards to deter misuse, and we retain audit trails for key interactions to support accountability where needed.
• Privacy in user environments - While access to data is logged, we do not monitor user activity within JupyterHub notebooks, in order to preserve a reasonable level of privacy and autonomy for researchers working in their environments.

Have you become aware of a security limitation not listed here? Please let us know right away at funderdataplatform@au.dk.