Child pages
  • Data Policy for Cloud Native Synchronizer

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Contents        

Data at rest

Synchronization profiles

Every customer has his own, separate database that stores synchronization profiles in  Cloud SQL.

These databases do not have a public IP and are not accessible to the outside world.

They interoperate with other components of Cloud-Native Synchronizer architecture over a VPC.

Value mappings

One of the strategies to synchronize fields between Jira and Azure is to create a value mapping.

A value mapping, is, essentially a dictionary that maps specific field values in one system to specific field values in another system.

Value mappings need to be configured by the user, and are stored as a part of synchronization profile in Cloud SQL database, separately for each customer.

Synchronizer will not prevent the user from putting PII and UGC into value mappings.

This is essential to achieve useful mappings for fields like users, components, area path, etc.

Connection credentials

In order to synchronize data between Jira and Azure, Synchronizer requires read / write access to one or both systems depending on synchronization direction.

Such access is granted by providing access tokens (PAT) during synchronization profile configuration. 

PAT are encrypted using Cloud Key Management using a private symmetric key, fully managed by GCP.

After encryption PATs are stored together with the synchronization profile in Cloud SQL database.

Data from external systems

During synchronization, Synchronizer needs to store identities of synchronized object pairs. 

We only store object identities, and not the whole objects themselves. 

This data is stored in Datastore and is guaranteed to be retained as long as the customer has a paying subscription to the product. 

Identities of the following objects are stored, both for Jira and Azure DevOps Services:

  • Work item Ids / issue Ids
  • Comment Ids
  • Attachment Ids

Customer-facing logs

These logs have been specifically designed to report problems that a customer can fix, and refer to.

These logs are stored in Datastore, and are guaranteed to be retained as long as the customer has a paying subscription to the product. 

Platform logs

Platform logs include application, infrastructure, and audit logs are stored using Google Cloud's operations suite with a maximum retention period of 30 days. 

These logs are not visible to any customer, and are needed for audit, maintenance and troubleshooting. 

PII and UGC in logs

Synchronizer does not add any PII to logs.

Synchronizer does not any UGC to logs, however we reserve the right to temporarily extend logging with such data when it is necessary to troubleshoot an incident.

Please note that external systems, including Jira and Azure can unintentionally return data, containing PII or UGC, as a part of an error message. 

In such cases, Synchronizer will log this data "as is", without making any attempt to discover or remove sensitive data.

Metrics and Telemetry

Spartez reserves the right to collect, store, process and analyze operational and business metrics and telemetry, without notifying the customer which specific metric is collected.

Operational metrics will not be anonymized, and will be correlated with customer's tenant key in Jira.

This is required for operational purposes, so that Spartez can identify and attribute a portion of cloud hosting and processing costs to a specific customer.

These metrics will not contain PII and UGC.

Not all business metrics will be anonymized, for example Spartez might measure how actively a certain feature is used or upvoted.

This data will be used to adjust our roadmap and to reach out to customers for feedback.

Data in motion


Data sub processors


  • No labels

This page has no comments.