Arquitectura de seguridad
El modelo de seguridad de Exportelier se basa en una división deliberada en dos apps, de modo que la app que maneja los datos de tus incidencias no tenga forma de enviarlos a ningún sitio.
App principal: sin fetch, sin webtriggers
La app principal no declara ninguna petición externa ni webtriggers en su manifest de Forge. Los PDF se renderizan íntegramente en Forge, sin navegador headless y sin servidores de terceros. Lo impone la plataforma de Atlassian — es una garantía de arquitectura, no una promesa de política.
Un diagrama: la app principal (sin egress, renderiza en Forge) junto a la app Automation (todo el egress, aislado).
App Automation: egress aislado
Todo lo que necesita enviar datos al exterior — correo, webhooks entrantes de Slack, Microsoft Teams Workflows y API — vive en la app separada Exportelier Automation. Transporta todo el tráfico saliente, con protección SSRF y URL secretas específicas del proveedor.
Los informes leen Jira como la persona que exporta
Toda lectura de Jira que realiza un informe —listar
filtros guardados, comprobarlos en la comprobación previa y buscarlos durante la
exportación— se ejecuta como la persona que la inició, con la identidad
asUser de Forge. La aplicación nunca recurre a su propia identidad de
aplicación para que una exportación en cola salga adelante.
De ahí se siguen directamente dos propiedades:
- Ser administrador del sitio en Exportelier nunca amplía la visibilidad en Jira. Un administrador puede construir un informe con filtros que él ve; eso no concede acceso a nadie más. Si una fuente no está disponible para quien exporta, la exportación falla y la nombra en lugar de omitir en silencio una fuente de datos.
- Nunca se almacena ni se compone una consulta a partir de tu texto.
Exportelier conserva el ID numérico de un filtro guardado y construye
exactamente un predicado estrictamente numérico,
filter = <id>. El JQL del filtro nunca se lee, guarda, registra ni concatena, así que no hay superficie de inyección de JQL ni copia obsoleta de tu consulta.
La salida de los informes es temporal y se elimina tras la descarga — consulta Retención de datos y GDPR.
La importación de paneles usa solo APIs documentadas
La importación de paneles lee Jira exclusivamente a través de la API REST de paneles de Jira Cloud documentada por Atlassian, como la persona que importa. No analiza páginas web de Jira, no lee iframes de gadgets, no hace capturas, no usa endpoints no documentados de preferencias de gadgets ni envía nada fuera de Forge. No requirió ningún permiso nuevo.
Lo que se lee es deliberadamente estrecho. Los valores de configuración de los gadgets se validan contra una lista de permitidos por gadget, se limitan en tamaño muy por debajo del máximo de Jira y nunca se registran, se reflejan en errores ni se escriben en eventos de auditoría. El JQL nunca se almacena, ni siquiera cuando una propiedad de gadget lo contiene: un informe importado conserva el mismo id numérico de filtro que cualquier otro.
Una de las operaciones implicadas, Get gadgets, está marcada como Experimental por Atlassian. Si su respuesta deja de coincidir con lo que Exportelier verificó contra un sitio Jira real, la ruta de importación falla de forma controlada y la función se desactiva, en lugar de actuar sobre una respuesta mal leída. Los informes y exportaciones existentes no se ven afectados.
Los eventos de auditoría registran que se comprobó o eliminó un registro de importación. No contienen configuración de gadgets, ni JQL, ni datos de incidencias.
Por qué dividirlas
Si tu política prohíbe el tráfico saliente, instalas solo la app principal y tienes una garantía firme de que nada sale de Atlassian. Los equipos que necesitan entrega añaden la app Automation de forma consciente.
Consulta también Residencia de datos y la página Compras & seguridad de proveedores.