Entente de traitement des données
En vigueur le [date de publication]
En bref
- Cette entente s’applique aux données personnelles que TuneCraft traite pour un client, et fait partie des conditions d’utilisation.
- Le client est le responsable du traitement. Plugincraft est la sous-traitante, et ne traite les données que pour fournir l’application.
- TuneCraft fonctionne entièrement sur la plateforme Forge d’Atlassian. Plugincraft n’exploite aucun serveur qui reçoit les données du client et n’a aucun accès aux données stockées sur le site du client.
- Atlassian est le seul sous-traitant ultérieur. Plugincraft avise le client au moins 30 jours avant d’en ajouter un.
1. Parties et portée
Cette entente est conclue entre le client qui installe TuneCraft : automatisation et nettoyage du site sur son site Atlassian (le « client ») et Logiciels Plugincraft inc. (en anglais, Plugincraft Software Inc.), société par actions constituée en vertu de la Loi sur les sociétés par actions (Québec), numéro d’entreprise du Québec (NEQ) 1182711235 (« Plugincraft »). Elle s’applique aux données personnelles que TuneCraft traite pour le client, et fait partie des conditions d’utilisation selon lesquelles le client utilise TuneCraft.
2. Rôles
Le client est le responsable du traitement des données personnelles. Plugincraft est la sous-traitante et ne les traite que pour fournir TuneCraft, selon les instructions documentées du client, qui sont les conditions d’utilisation, la présente entente et l’utilisation que le client fait des paramètres de l’application.
3. Ce qui est traité
| Élément | Détails |
|---|---|
| Personnes concernées | Les utilisateurs du client qui possèdent, exécutent ou analysent des flux d’automatisation sur son site, ou dont un expéditeur que le client exécute envoie les flux; les personnes que les étapes d’un flux nomment (par exemple un responsable, un observateur ou un destinataire, clients de Jira Service Management compris); les personnes qu’un avis avise (le propriétaire ou l’acteur d’un flux, ou toute personne active sur le site que choisit une personne que le client a autorisée à gérer TuneCraft) et les personnes qui envoient des avis; les personnes qu’un administrateur Jira choisit pour que les alertes d’utilisation les mentionnent; les administrateurs Jira qui configurent les alertes, saisissent les compteurs d’utilisation, envoient des alertes d’essai, modifient les paramètres, fixent l’état d’une action de la page À faire ou lisent le rapport de Jira sur les tickets près de ses plafonds; les personnes du niveau Gérer qui enregistrent le modèle de coût; les propriétaires de filtres et de tableaux de bord, les administrateurs Jira qui les modifient et les nouveaux propriétaires qu’ils choisissent; les personnes à qui un schéma de permissions accorde quelque chose nommément, actives ou non; les administrateurs Jira qui excluent une proposition, mettent un objet sous surveillance ou fixent une cible pour une vérification, et les personnes qu’ils excluent; les administrateurs Jira qui lancent une lecture de pièces jointes ou un archivage; les personnes retirées d’un groupe et les administrateurs Jira qui les retirent; et les personnes qui détiennent un siège payant dans l’export d’utilisateurs qu’un administrateur Jira téléverse. |
| Données personnelles | Des identifiants de comptes Atlassian, y compris ceux que les étapes d’un flux nomment (conservés à côté de la structure caviardée du flux, pour les analyses lancées par un administrateur Jira). Pour chaque identifiant de compte conservé, si Jira a dit que le compte était actif la dernière fois que TuneCraft a demandé, et quand. Pour chaque siège payant d’un export d’utilisateurs téléversé : l’identifiant de compte, le dernier jour où la personne a utilisé le produit et l’indication d’administrateur du produit. Pour une action À faire : l’identifiant de compte de la personne qui a fixé son état et la clé du ticket Jira qui y est lié. L’identifiant de compte du propriétaire de chaque filtre et tableau de bord (avec l’indication que le compte est actif ou non), du responsable d’un espace tant que Jira dit qu’il est inactif, de chaque personne à qui un schéma de permissions accorde une permission nommément (avec la clé de la permission), de l’administrateur Jira qui a exclu une proposition, mis un objet sous surveillance ou fixé une cible pour une vérification, d’une personne exclue et, pour une lecture de pièces jointes d’espaces choisis, de l’administrateur Jira qui l’a lancée, et de la personne qui a enregistré en dernier chaque paramètre (un administrateur Jira ou, pour le modèle de coût, une personne du niveau Gérer). Le registre de chaque changement qu’un outil de nettoyage a fait (qui l’a fait, le nouveau propriétaire, le propriétaire antérieur de chaque objet, et l’identifiant de compte de chaque personne retirée d’un groupe, avec l’identifiant Jira du groupe). Tant qu’ils attendent d’être enregistrés, les flux qu’un expéditeur que le client exécute a envoyés à l’analyse automatique : leurs noms, les identifiants de compte des propriétaires, des acteurs et des personnes que les étapes nomment, et les étapes caviardées. Les noms des flux d’automatisation, le texte qu’un administrateur Jira saisit comme réglage (conventions de nommage, les deux nombres de jours de Laissés de côté, cibles, consignes d’une vérification) et, pour un changement d’étiquette, l’ancienne et la nouvelle étiquette pendant 30 jours (du texte que les utilisateurs du client ont écrit, qui peut contenir des données personnelles). |
| Non stocké | Les adresses courriel (TuneCraft écarte celles que Jira renvoie avec le nom d’une personne). Les textes des réglages des flux d’automatisation (JQL, adresses Web, en-têtes, valeurs intelligentes, noms de champs personnalisés, valeurs comparées, commentaires, secrets), qui n’atteignent jamais l’application : chacun est remplacé dans le navigateur de la personne qui analyse, ou dans l’expéditeur du client, par un hachage à clé, sauf un identifiant de compte, conservé à côté du flux. Le JQL d’un flux va de ce navigateur uniquement vers le Jira du site d’où vient le flux, en tant que cette personne, pour y être vérifié et compté; l’application ne garde que les nombres. Les tickets que le rapport de Jira sur sa limite par ticket et la recherche qui écarte les tickets terminés renvoient (leurs identifiants, leurs clés et leurs espaces) sont montrés à l’administrateur Jira qui les a lus et jamais conservés. Il en va de même de l’échantillon que montre une recherche d’Archivage et des noms de fichiers des pièces jointes, qu’une lecture de Pièces jointes compare en mémoire. Les noms et les adresses courriel d’un export d’utilisateurs téléversé restent dans le navigateur de l’administrateur Jira. |
| Finalité | Faire rapport sur les flux d’automatisation du client, les étapes d’automatisation qu’ils dépensent, les correctifs proposés et les économies; prévoir l’utilisation de l’automatisation du mois; vérifier et nettoyer la configuration Jira du client, les administrateurs Jira du client confirmant chaque changement; aviser les personnes qu’un flux concerne, par des tickets Jira créés en tant que la personne qui les envoie; et alerter les personnes qu’un administrateur Jira choisit lorsque la prévision approche l’allocation, par des tickets Jira que TuneCraft crée en tant qu’application (Jira montre l’application comme rapporteuse), dans le projet et le type de ticket que cet administrateur a choisis et dans lesquels il peut créer; et, si le client l’active, recevoir l’analyse caviardée qu’un expéditeur que le client exécute envoie à l’application (l’analyse automatique). |
| Durée | Tant que TuneCraft est installée. Les analyses au-delà des 24 dernières sont retirées, sauf que, tant qu’aucune des 24 dernières n’a gardé ce que ses flux nomment, la dernière analyse qui l’a gardé l’est aussi. Le registre d’un avis (qui il a avisé, qui l’a envoyé) est retiré après un an. Les compteurs d’utilisation de l’automatisation (et l’heure unique de la dernière exécution d’un journal, qui reste jusqu’à ce que l’analyse suivante d’un journal qui liste toutes les exécutions et finit le même jour ou plus tard la remplace), les historiques des lectures, le registre de chaque changement et de chaque alerte envoyée sont retirés après 400 jours; chaque objet modifié après 30 jours, et l’ancienne et la nouvelle étiquette d’un changement d’étiquette après 30 jours; la fusion d’un champ dans un autre (les identifiants des deux champs et des nombres) après 400 jours, avec les identifiants de ses tickets après 30 jours; l’exécution d’un changement d’étiquette (les hachages à clé de ses étiquettes et ses nombres) après 400 jours, et l’identifiant du dernier ticket traité à l’arrêt de l’exécution ou, au plus, après 30 jours. Un changement resté ouvert, que personne n’a terminé ni arrêté, est fermé par la maintenance quotidienne 30 jours après son début (une semaine pour une fusion de schémas ou pour un changement que la page Modifications de son outil ferme, une heure pour la suppression d’une copie de schéma de permissions ou le retrait d’un octroi ouvert), et ses objets disparaissent comme ci-dessus; les critères d’une exécution d’archivage laissée ouverte restent jusqu’à 400 jours après leur dernière écriture. Les personnes que les alertes mentionnent sont retirées lorsqu’elles ne sont plus choisies. Les listes d’exclusion et de surveillance sont gardées jusqu’à ce qu’un administrateur Jira les arrête, que les jours d’une exclusion soient écoulés, ou que Jira n’ait plus l’objet (pour un flux, dès que la dernière analyse ne l’a plus et que l’exclusion a plus de 30 jours); une surveillance disparaît aussi dans la journée lorsque les vérifications de son outil sont désactivées. Une cible fixée pour une vérification est gardée jusqu’à ce qu’un administrateur Jira la retire, et 400 jours après qu’elle a été atteinte. Une lecture de pièces jointes d’espaces choisis est gardée 90 jours. Les sièges d’un export d’utilisateurs téléversé sont gardés jusqu’à ce que l’administrateur Jira téléverse un nouveau fichier ou les retire, et dans tous les cas 90 jours après le téléversement. L’état d’une action À faire et l’identifiant de compte de la personne qui l’a fixé sont retirés 400 jours après qu’une lecture l’a confirmée terminée, ou dès qu’aucune lecture n’a vu son problème depuis 400 jours. Les parties d’un envoi de l’analyse automatique sont supprimées quand l’envoi se termine ou, pour un envoi qui ne se termine jamais, par la maintenance quotidienne dès qu’il a une heure (trois heures si l’application avait commencé à l’enregistrer, 26 heures si l’expéditeur a demandé à le garder ouvert); tant que l’analyse n’est pas enregistrée, les identifiants de compte de ces parties ne sont pas encore sur la liste que l’application signale à Atlassian. |
| Emplacement | Le stockage hébergé Forge d’Atlassian pour le site du client, à l’emplacement de résidence des données du site. |
4. Comment TuneCraft fonctionne
TuneCraft fonctionne entièrement sur la plateforme Forge d’Atlassian. Son traitement et son stockage se font sur l’infrastructure d’Atlassian, selon les conditions propres d’Atlassian avec le client et avec Plugincraft. Plugincraft n’exploite aucun serveur qui reçoit les données du client et n’a aucun accès aux données stockées sur le site du client.
Si le client active l’analyse automatique, une chose s’ajoute : un déclencheur Web Forge qui reçoit les flux caviardés qu’un expéditeur que le client exécute lui envoie (section 6). L’expéditeur s’exécute sur les systèmes du client ou comme tâche planifiée dans ScriptRunner Cloud, une application de scripts d’un autre éditeur que le client a installée sur son site. C’est l’expéditeur du client, et non un sous-traitant ultérieur de Plugincraft : il lit les règles avec le jeton d’API Atlassian du client, qui n’atteint jamais TuneCraft ni Plugincraft.
5. Obligations de Plugincraft
Plugincraft :
- ne traite les données personnelles que comme le décrit la section 3;
- veille à ce que les personnes qui travaillent sur TuneCraft soient tenues à la confidentialité;
- conçoit et maintient TuneCraft avec les mesures de la section 6;
- n’utilise aucun sous-traitant ultérieur autre que la plateforme d’Atlassian sur laquelle le client installe l’application, et informe le client au moins 30 jours avant d’en ajouter un, pour que le client puisse s’y opposer;
- aide le client à répondre aux demandes des personnes concernées, principalement en fournissant les moyens propres à l’application de consulter et de retirer les données;
- informe le client sans délai injustifié, et dans les 72 heures si possible, après avoir pris connaissance d’une atteinte aux données personnelles touchant TuneCraft, et la signale à Atlassian comme l’exigent les règles du Marketplace d’Atlassian;
- aide le client dans ses évaluations des facteurs relatifs à la vie privée lorsque TuneCraft est concernée;
- met à disposition les renseignements nécessaires pour démontrer le respect de la présente entente, et répond par écrit aux questions d’audit raisonnables.
6. Mesures de sécurité
- Chaque texte des réglages d’un flux d’automatisation est remplacé dans le navigateur de la personne qui analyse, ou dans l’expéditeur du client, par un hachage à clé avant que quoi que ce soit soit envoyé; aucun de ces textes n’est jamais stocké. Un hachage à clé est un pseudonyme, et non un secret pour qui détient la base de données : la clé est conservée dans le même stockage, si bien qu’on peut retrouver un nom court en essayant des candidats. Une valeur qui ressemble à une personne (un identifiant de compte ou une adresse courriel) n’est jamais hachée dans l’enregistrement de ce que chaque flux utilise. L’application ne stocke la structure d’un flux que si elle est ainsi caviardée, la revérifie et refuse celle qui ne l’est pas, et aucune page ne reçoit ses hachages, seulement des pastilles numérotées.
- L’accès à l’application est vérifié sur le serveur pour chaque requête : administrateurs Jira, groupes que le client autorise, et administrateurs de projet pour leurs propres projets seulement. Une vérification qui ne peut pas se terminer fait refuser la requête.
- L’application demande le moins de permissions Jira possible, ne déclare aucune sortie de données et ne reçoit ni ne stocke aucun mot de passe ni jeton d’API Atlassian. Pour l’analyse automatique, elle a un seul déclencheur Web, qui n’accepte que POST avec la clé fabriquée par un administrateur Jira, répond par des réponses fixes et refuse tout flux non caviardé. Elle n’en garde qu’une empreinte à sens unique du secret de la clé, faite avec un secret propre à l’application conservé dans une variable Forge chiffrée. La clé porte aussi la clé d’analyse du site, la clé derrière les hachages à clé, parce que l’expéditeur en a besoin pour faire les mêmes hachages : quiconque détient la clé entière peut envoyer des analyses à l’application et tester des hypothèses contre un hachage à clé; le client la garde donc secrète. Remplacer la clé ou désactiver l’analyse automatique arrête aussitôt son secret; la clé d’analyse ne change pas.
- Les journaux ne contiennent que des identifiants des enregistrements propres à l’application, des nombres et des codes d’erreur.
- Les changements de code sont révisés, testés et vérifiés pour y repérer les secrets avant la livraison; les vulnérabilités sont corrigées dans les délais de la politique de correction des bogues de sécurité du Marketplace d’Atlassian. Voir l’Aperçu de la sécurité.
7. Fin du traitement
Lorsque le client désinstalle TuneCraft, Atlassian supprime les données stockées de l’application selon ses règles de conservation des données. Plugincraft ne détient aucune copie à rendre ou à supprimer.
8. Transferts
Plugincraft ne transfère pas les données personnelles : elles restent dans le stockage hébergé d’Atlassian, à l’emplacement de résidence des données du site.
9. Personne-ressource
Questions sur la vie privée : écrivez au président de Logiciels Plugincraft inc., la personne responsable de la protection des renseignements personnels, à info@plugincraft.ca.