Architecture de sécurité

Le modèle de sécurité d'Exportelier repose sur une séparation délibérée en deux apps, de sorte que l'app qui manipule les données de vos tickets n'ait aucun moyen de les envoyer où que ce soit.

App principale : pas de fetch, pas de webtriggers

L'app principale ne déclare aucun appel externe ni webtrigger dans son manifest Forge. Les PDF sont rendus entièrement sur Forge, sans navigateur headless et sans serveurs tiers. C'est imposé par la plateforme d'Atlassian — c'est une garantie d'architecture, pas une promesse de politique.

Un schéma : l'app principale (pas d'egress, rend sur Forge) à côté de l'app Automation (tout l'egress, isolé).

App Automation : egress isolé

Tout ce qui doit envoyer des données vers l'extérieur — e-mail, webhooks entrants Slack, Microsoft Teams Workflows et API — vit dans l'app séparée Exportelier Automation. Elle transporte tout le trafic sortant, avec une protection SSRF et des URL secrètes propres aux fournisseurs.

Les rapports lisent Jira en tant que la personne qui exporte

Chaque lecture Jira effectuée par un rapport — lister les filtres enregistrés, les contrôler en pré-vérification et les interroger pendant l'export — s'exécute en tant que la personne qui l'a lancé, via l'identité asUser de Forge. L'application ne se rabat jamais sur sa propre identité applicative pour faire aboutir un export en file d'attente.

Deux propriétés en découlent directement :

• Le statut d'administrateur du site dans Exportelier n'élargit jamais la visibilité Jira. Un administrateur peut construire un rapport à partir de filtres qu'il voit ; cela n'accorde l'accès à personne d'autre. Si une source n'est pas accessible à la personne qui exporte, l'export échoue et la nomme, au lieu d'omettre silencieusement une source de données.
• Aucune requête n'est jamais stockée ni assemblée à partir de votre texte. Exportelier conserve l'identifiant numérique d'un filtre enregistré et construit exactement un prédicat strictement numérique, filter = <id>. Le JQL du filtre n'est jamais lu, stocké, journalisé ni concaténé : il n'y a donc ni surface d'injection JQL, ni copie obsolète de votre requête.

La sortie des rapports est temporaire et supprimée après téléchargement — voir Rétention des données et RGPD.

L'import de tableau de bord n'utilise que des API documentées

L'import de tableau de bord lit Jira exclusivement via l' API REST des tableaux de bord Jira Cloud documentée par Atlassian, en tant que la personne qui importe. Il n'analyse pas les pages web de Jira, ne lit pas les iframes des gadgets, ne prend pas de captures, n'utilise aucun endpoint non documenté de préférences de gadgets et n'envoie rien en dehors de Forge. Il n'a nécessité aucune nouvelle permission.

Ce qui est lu est délibérément restreint. Les valeurs de configuration des gadgets sont validées contre une liste blanche par gadget, plafonnées en taille bien en dessous du maximum de Jira, et jamais journalisées, répercutées dans une erreur ou écrites dans un événement d'audit. Le JQL n'est jamais stocké, même quand une propriété de gadget en contient — un rapport importé conserve le même id numérique de filtre que n'importe quel autre.

L'une des opérations concernées, Get gadgets, est marquée Experimental par Atlassian. Si sa réponse cesse de correspondre à ce qu'Exportelier a vérifié sur un site Jira réel, le chemin d'import échoue proprement et la fonctionnalité se désactive, plutôt que d'agir sur une réponse mal lue. Les rapports et exports existants ne sont pas affectés.

Les événements d'audit consignent qu'un enregistrement d'import a été vérifié ou supprimé. Ils ne contiennent ni configuration de gadget, ni JQL, ni données de tickets.

Pourquoi les séparer

Si votre politique interdit le trafic sortant, vous n'installez que l'app principale et avez une garantie ferme que rien ne quitte Atlassian. Les équipes qui ont besoin de livraison ajoutent l'app Automation en connaissance de cause.

Voir aussi Résidence des données et la page Achats & sécurité fournisseur.