Beveiligingsarchitectuur

Het beveiligingsmodel van Exportelier berust op een opzettelijke splitsing in twee apps, zodat de app die de gegevens van je issues verwerkt geen manier heeft om ze ergens naartoe te sturen.

Hoofd-app: geen fetch, geen webtriggers

De hoofd-app declareert geen externe fetch en geen webtriggers in zijn Forge-manifest. PDF's worden volledig op Forge gerenderd, zonder headless browser en zonder externe servers. Dit wordt afgedwongen door het platform van Atlassian — het is een architectuurgarantie, geen beleidsbelofte.

Een diagram: de hoofd-app (geen egress, rendert op Forge) naast de Automation-app (alle egress, geïsoleerd).

Automation-app: geïsoleerde egress

Alles wat gegevens naar buiten moet sturen — e-mail, Slack incoming webhooks, Microsoft Teams Workflows en API — leeft in de aparte Exportelier Automation-app. Die draagt al het uitgaande verkeer, met SSRF-bescherming en providerspecifieke geheime URL's.

Rapporten lezen Jira als de exporterende gebruiker

Elke Jira-leesactie die een rapport uitvoert — opgeslagen filters opsommen, ze in de preflight controleren en ze tijdens de export doorzoeken — draait als de persoon die hem startte, via de asUser-identiteit van Forge. De app valt nooit terug op haar eigen app-identiteit om een in de wachtrij staande export te laten slagen.

Daaruit volgen direct twee eigenschappen:

• Sitebeheerder zijn in Exportelier verbreedt de Jira-zichtbaarheid nooit. Een beheerder kan een rapport bouwen uit filters die hij ziet; dat geeft niemand anders toegang. Is een bron niet beschikbaar voor de exporterende gebruiker, dan mislukt de export en wordt de bron genoemd, in plaats van er stilletjes een weg te laten.
• Er wordt nooit een query bewaard of uit jouw tekst samengesteld. Exportelier houdt het numerieke ID van een opgeslagen filter vast en bouwt precies één strikt numeriek predicaat, filter = <id>. De JQL van het filter wordt nooit gelezen, opgeslagen, gelogd of samengevoegd, dus er is geen JQL-injectieoppervlak en geen verouderde kopie van je query.

Rapportuitvoer is tijdelijk en wordt na het downloaden verwijderd — zie Gegevensbewaring en GDPR.

Dashboard-import gebruikt uitsluitend gedocumenteerde API's

Dashboard-import leest Jira uitsluitend via de door Atlassian gedocumenteerde Jira Cloud dashboard-REST-API, als de importerende persoon. Het ontleedt geen Jira-webpagina's, leest geen gadget-iframes, maakt geen schermafbeeldingen, gebruikt geen ongedocumenteerde endpoints voor gadgetvoorkeuren en stuurt niets buiten Forge. Er was geen nieuwe permissie voor nodig.

Wat er gelezen wordt, is bewust smal. Configuratiewaarden van gadgets worden gevalideerd tegen een allowlist per gadget, ruim onder het maximum van Jira in omvang begrensd, en nooit gelogd, in foutmeldingen herhaald of in auditgebeurtenissen geschreven. JQL wordt nooit opgeslagen, ook niet wanneer een gadgeteigenschap het toevallig bevat — een geïmporteerd rapport houdt hetzelfde numerieke filter-id als elk ander rapport.

Eén van de betrokken bewerkingen, Get gadgets, is door Atlassian als Experimental aangemerkt. Komt het antwoord niet langer overeen met wat Exportelier tegen een echte Jira-site heeft geverifieerd, dan faalt het importpad gecontroleerd en schakelt de functie zichzelf uit, in plaats van te handelen op een verkeerd gelezen antwoord. Bestaande rapporten en exports blijven ongemoeid.

Auditgebeurtenissen leggen vast dat een importrecord is gecontroleerd of verwijderd. Ze bevatten geen gadgetconfiguratie, geen JQL en geen issuegegevens.

Waarom ze splitsen

Verbiedt je beleid uitgaand verkeer, dan installeer je alleen de hoofd-app en heb je een harde garantie dat niets Atlassian verlaat. Teams die bezorging nodig hebben, voegen de Automation-app bewust toe.

Zie ook Gegevensresidentie en de pagina Inkoop en leveranciersbeveiliging.