Help Center

Menu

Privacy and security in Datastore

This document outlines how Datastore helps protect customers, developers, and end-users when storing user data.

This documentation and the content below does not constitute legal advice and is general in nature. This document is intended to help Squiz customers and Datastore developers better understand how Squiz protects their data and how Squiz complies with its obligations. Customers can align their use of Datastore with privacy legislation and regulatory compliance. Squiz has not considered any individuals or entity’s specific requirements or circumstances. Therefore, Squiz recommends that any users, including customers, consult with a privacy or legal expert to obtain guidance on any specific requirements that may be applicable to their organization.

What type of data is suitable for Datastore?

Datastore is designed from the ground up to be a high performing backbone for storing structured data in small-, medium-, and enterprise-level rapidly-responsive web applications (apps).

Developers can:

  • build entire client-side JavaScript apps around a Datastore service that provides great flexibility, and use their client-side apps to store and retrieve a wide variety of app settings, configurations, as well as user profile and behavioural metadata.

  • Datastore is particularly well-designed for storing structured data that relates to a user’s personalized experience with an app. The following types of information may be suitable for storage, depending on the needs of the app:

    • IP address

    • Geographic location

    • Device details

    • App settings and metadata

    • Personalization preferences

    • User events, interaction, and behavioural data

Data encryption in Datastore

Squiz provides multiple layers of security to protect user data, such as encryption in transit (HTTPS) and logical isolation of customer data, and encryption at rest (e.g. data encrypted within a physical storage device).

If you need to capture sensitive data (such as credit card details or unencrypted passwords) for your app to function, then you should take appropriate steps to ensure your compliance with appropriate legislation, which may include:

  1. Confirm your organizational requirements for the storage of sensitive information.

  2. Let relevant stakeholders know what you are storing, why, and catalogue/document that information.

  3. Review the General Data Protection Regulation (GDPR) considerations prior to starting any work.

How Squiz and Datastore protects user data

This section describes the various mechanisms that Datastore implements and adheres to, in order to protect and monitor user data.

API and data storage access

Datastore provides a number of API and data storage access security features to help protect your data:

  • API endpoints can only be accessed from secure and encrypted web-based connections (HTTPS).

  • Client deployments are limited to their own unique microservice containers where Datastore logically isolates customer data from other deployments.

  • Using JSON Web Token (JWT) open standard to pass trusted data between Squiz Matrix (Matrix) and Datastore via a JavaScript application, in conjunction with the JWT extension for Matrix, which provides implementation options for developers to expire tokens frequently to limit replay attacks.

  • Access is denied by default, forcing developers to define strict access control rules (called access control layers, or ACLs in Datastore) to specify who gets access to what data, in conjunction with the JWT extension for Matrix.

  • Industry standard JSON schema validation ensures data is hidden by default and enforces a process whereby developers need to explicitly define what data should be returned at each endpoint.

The application layer

All code is tested for potential security vulnerabilities before a new Datastore version is released. Regular scans and penetration tests across Squiz DXP Console (where Datastore services are deployed) and Squiz DXP Console’s supporting infrastructure are performed to detect and mitigate vulnerabilities, misconfigurations and other anomalies.

  • Squiz DXP Console’s core code and servers are regularly patched to protect Datastore from exploits.

  • Squiz DXP Console is assessed regularly for application and network vulnerabilities, including selected penetration testing.

  • New versions of Datastore are only released after code repository scanning, credential scanning, and completing security check-lists including the full scope of OWASP security risks.

The physical and environmental layer

Datastore services are hosted in high quality data centres, which provide:

  • Biometric or ID card scanning for controlled data centre access.

  • Security camera monitoring at all data centre locations.

  • 24x7 onsite staff for additional protection against unauthorized entry.

  • Redundant power and cooling with all data centres operated to the Uptime Institute’s Tier III Certification, or higher standards.

  • Sensors to detect environmental hazards e.g. smoke / water detection.

  • Fire detection and suppression system.

Network layer

Datastore employs the following network access controls to mitigate network compromise and downtime.

  • Network access to and from the Squiz DXP Console network is protected with layered access controls, and stateful firewalls that validate the authenticity of connections.

  • Distributed Denial of Service (DDoS) attacks of unlimited size are automatically detected and mitigated.

  • Deterministic packet filtering, and priority-based traffic shaping to automatically mitigate network layer attacks.

Security monitoring

Datastore employs the following security monitoring strategies to maintain security and accountability:

  • Security teams monitor internal and external security events and implement corrective actions.

  • Platform access is logged and tracked for auditability.

  • Application access logs are collected and analysed.

Regulatory compliance

Squiz DXP Console complies with the following standards:

  • General Data Protection Regulation (GDPR), along with Datastore.

  • ISO/IEC 27001, along with Squiz Support.

  • SOC 2, and SOC 2 certificates are available for all US locations.

Squiz DXP Console is also registered with the Cloud Security Alliance.

Administrative controls

The following personnel controls are implemented to protect your data in Datastore:

  • Access to customer data and Datastore infrastructure is restricted to authorized dedicated personnel only.

  • All data center employees are trained on information security and privacy procedures.

  • Access to SaaS servers is limited, logged and tracked for auditability.

Service availability controls

Datastore employs the following systems and mechanisms to maintain service uptime and mitigate the possibility of any downtime.

  • Squiz DXP Console uses virtualization-level redundancy combined with fully redundant power, cooling, network, and power infrastructure, to provide 99.9% uptime for all Squiz DXP Console applications, including Datastore. Virtualization-level redundancy means that the virtual machines running Datastore services (on Squiz DXP Console infrastructure) can quickly be recovered from any failure, thereby mitigating downtime.

  • Data is stored on a high-performance and highly-durable distributed storage system, with nightly backups.

  • Traffic is routed between multiple geographically redundant data centres which automatically fail over in the event of a provider outage to mitigate traffic failure.

  • Continuous external reachability monitoring, which detects for internet service provider outages (outside the Squiz DXP Console network).

General Data Protection Regulation considerations

On the 25th of May 2018, one of the biggest changes in the data privacy regulatory landscape came into force: the General Data Protection Regulation (GDPR). The GDPR is a privacy legislation that replaced the 95/46/EC Directive on Data Protection of 24 October 1995.

What happens if you don’t comply? A fine of 4% of an organizations global revenue or £17m - whichever comes in higher.

In short, GDPR strictly enforces 'privacy by design', which means everyone who handles personal data, whether this be from a developer, marketing, human resources, sales or finance, needs to understand how personal data can and cannot be used.

For more information, watch the Squiz webinar which helps to outline a simple, comprehensive guide on GDPR regulation.

Customer responsibilities

In most cases, a developer will work on behalf of a customer who has purchased the right to use a Datastore service from Squiz and in GDPR terms, the developer typically acts as the data controller for any personal data they provide to Squiz via their use of Datastore. In general, the data controller determines the purposes and means of processing personal data.

During the process of designing and developing an app, the data controller (i.e. developer) determines what type of data needs to be collected and for what purposes. Squiz acts as the data processor, who processes data stored on behalf of the data controller (when the controller uses Datastore).

Both data controllers and processors have obligations under the GDPR, but their responsibilities vary. Read more about the differences between data controllers and data processors. Customers should confirm and satisfy themselves as to their responsibilities and obligations under the GDPR.

Data controller’s responsibilities

When a data controller uses Datastore, the controller is responsible for:

  • Implementing any technical or business measures to ensure data processing complies with the GDPR.

  • Fulfilling end-users' rights with respect to their data.

  • Complying with other GDPR obligations relating to lawfulness, fairness and transparency, purpose limitation, data minimization, and accuracy.

To understand more about a data controllers' responsibilities, review the relevant provisions of the GDPR along with your organization’s compliance plans.

Data processor’s responsibilities

Datastore:

  • Is governed by the Squiz DXP Console Terms of Service and when customers (who are the data controllers) use Datastore, Squiz is generally the data processor and processes personal data on their behalf.

  • Does not store personal data or use personal data for any other purposes other than for what a data controller needs for their app to function.

  • Does, however, store a small amount of information about data controllers, outlined in the following table:

    Type Purpose State

    Developer email addresses

    Email addresses are:

    • Not being captured for marketing purposes.

    • Used as a username for logging into the deployment environment in order to deploy and manage Datastore services.

    • Also used to notify developers of outages or scheduled maintenance.

    Permanent unless deletion is requested. Note that if developers request their email addresses to be deleted, then developers no longer have access to deploy a new Datastore service or manage their existing ones. Developers should treat this like a username, it is permanent until they no longer require access, or until they nominate an alternative email address.

Organizational tips

GDPR should be a part of your organization’s data protection compliance strategy. Here are a few tips to get started:

  • Review the relevant provisions of the GDPR.

  • Create an up-to-date inventory of user data that you may handle.

  • Review any policies or procedures you may have for managing and protecting user data within the scope of the GDPR’s requirements. If gaps are found, then come up with a plan to fix them.

  • Incorporate how Datastore security features are being used into any of your organization’s own compliance documentation.

Developer tips

When developers (otherwise known as GDPR data controllers) decide to use Datastore to build an app, they should first consider the following questions:

  • How will the organization or app ensure transparency and control around the use of data?

  • Will the organization or app have the right consents in place where these are needed under the GDPR?

  • Does the organization or app have the right systems to record user preferences and consents?

  • How will I show others that the organization or app meets the principles of the GDPR?

  • Have I consulted and received advice regarding the organization’s legislative and compliance obligations?

The following are a number of general tips to help developers get up to speed with best practices for building apps with Datastore.

Tip 1 - Reduce the amount of personal user data that your app needs to store

The first step to managing privacy is to:

  • gain a clear idea of the data that the app needs,

  • which features are using that data, and

  • how long the app needs to store the data for.

For example, where a web app can only function if an end-user confirms their country of birth and whether or not they are over 18, do not store the user’s full birthday and country of birth; only store whether or not they meet the two criteria (e.g. a boolean value).

Tip 2 - Provide an opt-in for the collection and processing of user data

Make it easy to gather and track user preferences around the collection and processing of data by setting up app features to manage, update, and track privacy settings. This typically assumes a UI to prompt users to opt in to your app (with a privacy agreement) and a UI to prompt users for their privacy settings and a way to store these settings. Prior to building these UIs, developers should:

  • Understand the data being collected and take time to catalog the user data being stored or processed.

  • Design UIs to help users understand what data is being collected, in friendly terms with clear descriptions, including descriptions about how data may be used.

  • Think about their app’s onboarding and user flow. If an app needs user data to function, then to avoid issues, disable any UI elements that allow the user to continue until the user agrees to a privacy policy.

  • Decide on how best to store privacy settings, which is entirely up to the developer, including what sort of unique identifier to use.

  • Provide a feature that allows a user to visit their profile or settings page, where the user can update their privacy settings.

Tip 3 - Configure access controls correctly

Access control rules (ACLs) are a developers first line of defence in creating secure apps with Datastore. Correctly configuring security rules is an important step in preventing unauthorized data access. Before developers deploy rules, ensure that successful API endpoint calls are tested using the Datastore local simulator along with a tool like Postman, that helps make test API calls repeatable or even scriptable via cURL.

Tip 4 - Remove user data that an app no longer needs

Developers should delete user data when an end-user removes their account and when developers no longer need a specific set of data for their apps to function. For example: when building a “high score listing” for a student assessment app, developers only need to keep a record of the highest scores for the app to function, they do not need to store all assessment details and the complete score history.

Tip 5 - Consider app storage retention versus Datastore storage retention

It is important to understand the way an app is using data, especially if an app needs to inform an end-user about app privacy details. Deleting data from the Datastore service in Squiz DXP Console does not immediately delete all copies of this data from the Datastore service. Some of this data is kept temporarily in backups.

Tip 6 - Keep a record of user preferences and consents

Records of user preferences and consents can be kept through an audit log of privacy changes, structured by the ID of a user, and can include details such as updated settings and the date/time of changes. Typically, this may require two write requests: one to update the privacy settings and another to update the log. It is important to make this a separate section in your API specification document or an entirely different service so that developers can create more restrictive access controls.