Architettura di sicurezza

Il modello di sicurezza di Exportelier si basa su una divisione deliberata in due app, così che l'app che gestisce i dati delle tue issue non abbia modo di inviarli da nessuna parte.

App principale: nessun fetch, nessun webtrigger

L'app principale non dichiara alcuna chiamata esterna né webtrigger nel suo manifest di Forge. I PDF vengono renderizzati interamente su Forge, senza browser headless e senza server di terze parti. È imposto dalla piattaforma di Atlassian — è una garanzia di architettura, non una promessa di policy.

Un diagramma: l'app principale (nessun egress, renderizza su Forge) accanto all'app Automation (tutto l'egress, isolato).

App Automation: egress isolato

Tutto ciò che deve inviare dati all'esterno — email, webhook in ingresso Slack, Microsoft Teams Workflows e API — vive nell'app separata Exportelier Automation. Trasporta tutto il traffico in uscita, con protezione SSRF e URL segreti specifici del provider.

I report leggono Jira come la persona che esporta

Ogni lettura di Jira eseguita da un report — elencare i filtri salvati, verificarli nel controllo preliminare e interrogarli durante l'esportazione — viene eseguita come la persona che l'ha avviata, tramite l'identità asUser di Forge. L'app non ripiega mai sulla propria identità applicativa per far riuscire un'esportazione in coda.

Ne derivano direttamente due proprietà:

• Essere amministratore del sito in Exportelier non amplia mai la visibilità in Jira. Un amministratore può costruire un report da filtri che vede; questo non concede accesso a nessun altro. Se una sorgente non è disponibile per chi esporta, l'esportazione fallisce e la nomina, invece di omettere in silenzio una sorgente dati.
• Nessuna query viene mai memorizzata o composta a partire dal tuo testo. Exportelier conserva l'ID numerico di un filtro salvato e costruisce esattamente un predicato rigorosamente numerico, filter = <id>. Il JQL del filtro non viene mai letto, memorizzato, registrato né concatenato: non c'è quindi superficie di JQL injection né copia obsoleta della tua query.

L'output dei report è temporaneo e viene eliminato dopo il download — vedi Conservazione dei dati e GDPR.

L'importazione di dashboard usa solo API documentate

L'importazione di dashboard legge Jira esclusivamente tramite l' API REST delle dashboard di Jira Cloud documentata da Atlassian, come la persona che importa. Non analizza pagine web di Jira, non legge iframe dei gadget, non cattura screenshot, non usa endpoint non documentati per le preferenze dei gadget e non invia nulla fuori da Forge. Non ha richiesto alcun nuovo permesso.

Ciò che viene letto è deliberatamente ristretto. I valori di configurazione dei gadget vengono validati contro una allowlist per gadget, limitati in dimensione molto al di sotto del massimo di Jira e mai registrati nei log, riportati negli errori o scritti negli eventi di audit. Il JQL non viene mai memorizzato, nemmeno quando una proprietà di gadget lo contiene: un report importato conserva lo stesso id numerico di filtro di qualsiasi altro report.

Una delle operazioni coinvolte, Get gadgets, è contrassegnata come Experimental da Atlassian. Se la sua risposta smette di corrispondere a quanto Exportelier ha verificato su un sito Jira reale, il percorso di importazione fallisce in modo controllato e la funzione si disattiva, invece di agire su una risposta letta male. Report ed esportazioni esistenti non ne risentono.

Gli eventi di audit registrano che un record di importazione è stato verificato o eliminato. Non contengono configurazione dei gadget, JQL o dati dei ticket.

Perché separarle

Se la tua policy vieta il traffico in uscita, installi solo l'app principale e hai una garanzia solida che nulla lascia Atlassian. I team che hanno bisogno della consegna aggiungono l'app Automation consapevolmente.

Consulta anche Residenza dei dati e la pagina Acquisti e sicurezza dei fornitori.