...
...
...
...
...
...
...
...
...
...
...
...
| Info | ||
|---|---|---|
| ||
This part of the documentation relates to Cloud Native Synchronizer. If you use Jira Server and Azure DevOps Server / TFS go to Data Policy for On premises Synchronizer |
We take data security very seriously so we use only trusted service providers with the highest security standards. On this page, you will find details on how we secure our clients' data. If you think something is missing or you have any security related questions please let us know at Spartez Software Appfire Support Portal or support@spartez-software.com.
| Table of Contents |
|---|
Google Cloud Platform
- providers with this label are our data processors as defined by European General Data Protection Regulation (GDPR).Status colour Yellow title PROCESSOR
Service Providers
| Table of Contents | ||
|---|---|---|
|
Storage location.
Cloud SQL, datastore, backups and external backups storage are located in European Union, to be more exact, in Frankfurt, Germany.
Service statistics (operational metrics) are also copied over to the Google Cloud Platform (GCP) US region.
Google Cloud Platform
Status colour Yellow title PROCESSOR
Cloud SQL
Cloud SQL stores data provided during the installation handshake. Stored keys authenticate us to clients' Jira instances. We store
- A key that identifies Jira instance.
- Shared secrets for communication with Jira.
Cloud SQL also stores configuration data for synchronization profiles:
- Urls to Jira and Azure DevOps
- Username and encrypted personal access token for synchronizer user, encrypted using Cloud Key Management
- Value mappings
- Issue type mappings, workflow / status States and Statuses mappings, etc.
Datastore
Datastore stores operational data, that is generated once a synchronization profile is enabled:
- Pairs of Jira ids and Azure DevOps ids for
- Issues / work items
- Comments
- Attachments
- Customer - facing errors that occurred during synchronization
Google Cloud's operations suite
We store application and platform logs to troubleshoot and analyze incidents. Retention period is 30 days.
BigQuery
For a better understanding of our clients, we collect anonymous statistics of the plugin usage. These statistics tell us how we should develop our plugin to make our clients happy.
Cloud storage
Amazon Web Services
Simple Storage Service (S3)
Abbreviations used
- AWS - Amazon Web Services
- GCP - Google Cloud Platform
- JWT - json web token
- PAT - personal access token
- PII - personally identifiable information
- TLS - transport layer security
- UGC - user generated content
- VPC - virtual private cloud
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
| Info | ||
|---|---|---|
| ||
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 |
...
are configured by the user and are stored as a part of the synchronization profile in the 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 and meaningful mappings for fields like Assignee / Assigned To (that contains 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.
PATs 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.
No part of Jira issues and Azure DevOps work items, except for identities is stored. We do not store titles, descriptions, comments or any other part of issue / work item except for id.
This data is stored in Datastore, segregated per customer, 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
...
Datastore
Datastore stores operational data, that is generated once a synchronization profile is enabled:
- Pairs of Jira ids and Azure DevOps ids for
- Issues / work items
- Comments
- Attachments
- Links
- Customer - facing errors that occurred during synchronization
- High-level aggregated data for initial synchronizations, like date started and number of items processed
Google Cloud's operations suite
We store application and platform logs to troubleshoot and analyze incidents.
Logs might contain:
- Jira client key
- Jira issue ids or Azure DevOps work item ids
- user ids
- internal application messages
Retention period is 30 days.
| Info | ||
|---|---|---|
| ||
Synchronizer does not add any UGC to logs during normal operation, however, we reserve the right to log such data when errors occur and to temporarily extend logging with such data when it is necessary to troubleshoot an incident. |
...
Azure can unintentionally return data, containing PII or UGC, as a part of an error message. |
...
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.
Metrics and telemetry data are stored in BigQuery.
...
BigQuery
For a better understanding of our clients, we collect various statistics. These statistics tell us how we should develop our product to make our clients happy.
What is collected
The following table is intended to give you a complete understanding of the policy that we use to collect analytics data.
This table is not intended to list all the possible events collected by the add-on. It is however intended to list all rules and exceptions from those rules so that you are able to assess whether something can be collected or not.
| Data type | Comments |
|---|---|
| Operational metrics | Operational metrics are not anonymized and are correlated with the customer's tenant key in Jira. This is required for operational purposes, so that |
...
we can identify and attribute a portion of cloud hosting and processing costs to a specific customer. These metrics |
...
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.
Backups
Backups contain the following data:
- Synchronization profiles, including value mappings and encrypted connection credentials.
- Identities of synchronized object pairs, specifically
- Issue ids and work item ids
- Comment ids
- Attachment ids
Backups are performed on a daily basis and stored using GCP Cloud Storage, and then transferred via secure copy protocol to an encrypted AWS S3 bucket with a retention period of 30 days.
Data in motion
Cloud-Native Synchronizer is a distributed application built on top of GCP cloud products. Components of the system interoperate securely, mostly via https inside Google cloud.
Data moves across the boundary of GCP in the following scenarios:
- When reading the information from Jira or Azure and writing the data to Jira or Azure, the communication happens over https, using authentication mechanism required by the systems (mostly basic auth with PAT).
- When a customer is using UI in their user agent, the data is transferred via https using JWT authentication via secure http-only cookies.
- When transferring backups from GCP to AWS, AWS s3 cp utility is used, which communicates via TLS
Data sub-processors
...
do not contain any personally identifiable information, nor any user generated content. For example:
| |
User interface and usage | We track the usage of certain features in Jira plugin page, as well as in Synchronizer user interface. For example:
These events do not contain any personally identifiable information, but may contain user-generated content. This data is used to gain insights into user needs and improve application experience. |
Information about synchronizations errors | We store informations about synchronization errors. They may contain user generated content or PII (Jira and Azure can unintentionally return data, containing PII or UGC, as a part of the error message.) |
For further analysis we copy our operational metrics, described in the table above, to our data warehouse in GCP US region. Data we copy does not contain neither personally identifiable information, nor user generated content.
Cloud storage
Cloud storage stores backups of data held in Datastore and Cloud SQL.
Retention period is 7 days.
Amazon Web Services
Status colour Yellow title PROCESSOR
Simple Storage Service (S3)
S3 stores backups of data stored in Google Cloud storage.
Retention period is 30 days.