Sicherheitsarchitektur

Das Sicherheitsmodell von Exportelier beruht auf einer bewussten Aufteilung in zwei Apps, sodass die App, die Ihre Vorgangsdaten verarbeitet, keine Möglichkeit hat, sie irgendwohin zu senden.

Haupt-App: kein Fetch, keine Webtrigger

Die Haupt-App deklariert in ihrem Forge-Manifest keinen externen Fetch und keine Webtrigger. PDFs werden vollständig auf Forge gerendert, ohne Headless-Browser und ohne Drittanbieter-Server. Das wird von der Plattform von Atlassian erzwungen — es ist eine Architektur-Garantie, kein Richtlinien-Versprechen.

Ein Diagramm: die Haupt-App (kein Egress, rendert auf Forge) neben der Automation-App (gesamter Egress, isoliert).

Automation-App: isolierter Egress

Alles, was Daten nach außen senden muss — E-Mail, Slack Incoming Webhooks, Microsoft Teams Workflows und API — lebt in der separaten Exportelier Automation-App. Sie trägt den gesamten ausgehenden Verkehr, mit SSRF-Schutz und anbieterspezifischen geheimen URLs.

Reports lesen Jira als die exportierende Person

Jeder Jira-Lesevorgang eines Reports — Saved Filters auflisten, sie im Preflight prüfen und sie beim Export durchsuchen — läuft als die Person, die ihn gestartet hat, über die asUser-Identität von Forge. Die App weicht nie auf ihre eigene App-Identität aus, um einen eingereihten Export gelingen zu lassen.

Daraus folgen direkt zwei Eigenschaften:

• Site-Admin-Status in Exportelier erweitert die Jira-Sichtbarkeit nie. Ein Admin kann einen Report aus Filtern bauen, die er sieht; das gewährt niemandem sonst Zugriff darauf. Ist eine Quelle für die exportierende Person nicht verfügbar, scheitert der Export und benennt sie, statt eine Datenquelle stillschweigend wegzulassen.
• Es wird nie eine Abfrage gespeichert oder aus Ihrem Text zusammengesetzt. Exportelier hält die numerische ID eines Saved Filters und bildet genau ein streng numerisches Prädikat, filter = <id>. Filter-JQL wird nie gelesen, gespeichert, protokolliert oder konkateniert — es gibt also keine JQL-Injection-Fläche und keine veraltete Kopie Ihrer Abfrage.

Report-Ausgaben sind temporär und werden nach dem Download gelöscht — siehe Datenaufbewahrung & GDPR.

Der Dashboard-Import nutzt ausschließlich dokumentierte APIs

Der Dashboard-Import liest Jira ausschließlich über Atlassians dokumentierte Jira-Cloud-Dashboard-REST-API, und zwar als die importierende Person. Er parst keine Jira-Webseiten, liest keine Gadget-Iframes, erstellt keine Screenshots, nutzt keine undokumentierten Gadget-Preference-Endpunkte und sendet nichts außerhalb von Forge. Ein neuer Berechtigungs-Scope war dafür nicht nötig.

Was gelesen wird, ist bewusst eng gefasst. Gadget-Konfigurationswerte werden gegen eine Allowlist pro Gadget validiert, deutlich unterhalb von Jiras eigenem Maximum größenbegrenzt und niemals geloggt, in Fehlermeldungen wiedergegeben oder in Audit-Events geschrieben. JQL wird nie gespeichert, auch dann nicht, wenn eine Gadget-Property zufällig welches enthält — ein importierter Report behält dieselbe numerische Filter-ID wie jeder andere Report.

Eine der beteiligten Operationen, Get gadgets, ist von Atlassian als Experimental gekennzeichnet. Entspricht ihre Antwort nicht mehr dem, was Exportelier gegen eine echte Jira-Site geprüft hat, schlägt der Importpfad kontrolliert fehl und die Funktion schaltet sich ab, statt auf einer fehlgelesenen Antwort zu handeln. Bestehende Reports und Exporte sind davon nicht betroffen.

Audit-Events halten fest, dass ein Importdatensatz geprüft oder gelöscht wurde. Sie enthalten keine Gadget-Konfiguration, kein JQL und keine Vorgangsdaten.

Warum die Aufteilung

Verbietet Ihre Richtlinie ausgehenden Verkehr, installieren Sie nur die Haupt-App und haben eine harte Garantie, dass nichts Atlassian verlässt. Teams, die Zustellung brauchen, fügen die Automation-App bewusst hinzu.

Siehe auch Datenresidenz und die Seite Beschaffung & Anbietersicherheit.