Sicherheit & Compliance

Geschrieben für alle, die die App freigeben: Sicherheitsprüfung, Datenschutz und Einkauf. Jede Antwort ergibt sich aus der Bauweise der App.

Die Kurzfassung

Frage	Antwort
Wo läuft die App?	Vollständig auf der Plattform Atlassian Forge, innerhalb Ihres Atlassian-Tenants. Keine vom Anbieter betriebene Infrastruktur liegt dazwischen.
Verlassen Daten Atlassian?	Nein. Die App deklariert keine externen Endpunkte, Remotes oder Web-Trigger. Die Plattform selbst würde einen ausgehenden Aufruf blockieren.
Gibt es Unterauftragsverarbeiter?	Keine. Kein Dritter erhält Daten, weil keine Daten irgendwohin gesendet werden.
Hat der Anbieter Zugriff?	Nein. Wir können weder Ihre Site noch Ihre Anfragen noch die gespeicherte Konfiguration der App erreichen.
Werden Feldwerte gespeichert?	Nein. Sie werden beim Aufruf einer Anfrage aus Jira gelesen und nie zwischengespeichert.
Kann ein Kunde eine andere Anfrage lesen?	Nein. Die Anfrage stammt aus dem Seitenkontext von Atlassian, der nur die gerade angezeigte Anfrage enthält.
Runs on Atlassian?	Die App erfüllt die Voraussetzungen für das Atlassian-Programm „Runs on Atlassian“, als Folge der obigen Antworten.

Warum nicht lizenzierte Benutzer überhaupt lesen und schreiben können

Ein Portalkunde hat keine Jira-Lizenz. Er kann deshalb die meisten Felder nicht lesen und keines schreiben. Die App tut beides mit ihren eigenen Berechtigungen auf App-Ebene; anders kann sie nicht funktionieren. Die Sicherheit ergibt sich aus dem Rahmen dieser Aufrufe: Die Anfrage ist immer die, die laut Atlassian gerade angezeigt wird, gelesen werden nur die von einem Administrator konfigurierten Felder, und ein Schreibvorgang durchläuft sechs serverseitige Prüfungen, bevor Jira aufgerufen wird.

Die Folge, die Sie einplanen sollten: Der Vorgangsverlauf in Jira schreibt eine Änderung aus dem Portal der App zu und nicht dem Kunden. Deshalb führt die App ein eigenes Protokoll darüber, welcher Kunde welches Feld in welcher Anfrage geändert hat.

Datenresidenz

Die App hat keine eigenen Server. Sie liest Ihr Jira über die APIs von Atlassian, aus der Infrastruktur von Atlassian heraus, und legt ihre Konfiguration am selben Ort im Forge-Speicher ab. Die Datenresidenz-Einstellung Ihrer Site gilt dafür genauso wie für den Rest von Jira.

Was gespeichert wird

Daten	Personenbezogen?	Aufbewahrung
Konfiguration: Projekte, Feld-IDs, Bezeichnungen, Überschriften, Hinweise, Übersetzungen, Bearbeitungseinstellungen	Nein	Bis Sie sie ändern
Änderungsprotokoll: die Konto-ID des Administrators und ein Zeitstempel je Konfigurationsänderung	Konto-IDs sind pseudonyme Kennungen	Letzte 100 Änderungen
Kundenprotokoll: die Konto-ID des Kunden, ein Zeitstempel, der Anfrageschlüssel und die geänderten Feld-IDs	Konto-IDs sind pseudonyme Kennungen	Letzte 200 Änderungen

Keine Feldwerte, keine Namen, keine E-Mail-Adressen, keine IP-Adressen. Für Personen, die eine Anfrage nur ansehen, wird nichts protokolliert, und bei ausgeschalteter Bearbeitung im Portal wird das Kundenprotokoll nie beschrieben. Mit der Deinstallation der App wird all das gelöscht.

Berechtigungen (Forge-Scopes)

Acht Scopes. Vier davon dienen der Assets-Funktion, alle nur lesend. Es gibt keinen Scope zur Benutzersuche und keine Berechtigung für ausgehende Verbindungen.

Scope	Wozu er benötigt wird
`read:jira-work`	Die konfigurierten Felder der angezeigten Anfrage lesen; die Felder und Serviceprojekte der Site für die Auswahllisten der Einstellungsseiten auflisten; lesen, was ein Feld in dieser Anfrage akzeptiert.
`write:jira-work`	Die erlaubte Änderung eines Kunden anwenden. Nur eine Art von Schreibzugriff: eine Aktualisierung der Anfrage, die der Kunde ansieht. Erstellt, überführt oder löscht nie einen Vorgang.
`read:permission:jira`	Vor jedem Lesen oder Schreiben einer Konfiguration prüfen, ob der Benutzer Jira-Administrator oder Administrator des betreffenden Projekts ist.
`storage:app`	Forge-Speicher für die Konfiguration und die beiden begrenzten Protokolle.
`read:cmdb-object:jira`	Ein Assets-Objekt in seinen Namen auflösen und Objekte für die Auswahl des Kunden innerhalb der erlaubten Typen suchen.
`read:cmdb-schema:jira`	Die Assets-Objektschemas für die Typauswahl auflisten.
`read:cmdb-type:jira`	Die Objekttypen in diesen Schemas auflisten, also das, was ein Administrator erlaubt.
`read:servicedesk-request`	Nur ein einziger Aufruf: die Assets-Workspace-ID ermitteln, die jede Assets-Route benötigt. Darüber werden keine Anfrageinhalte gelesen.

Kontrollen, nach denen Prüfer fragen

Kontrolle	Umsetzung
Autorisierung bei jedem Aufruf	Admin-Aufrufe prüfen erneut die Rolle als Jira-Administrator, Projektaufrufe die als Projektadministrator für das Projekt aus dem Atlassian-Kontext, Portalaufrufe entnehmen die Anfrage diesem Kontext. Nichts aus dem Browser gilt als vertrauenswürdig.
Schreibbeschränkung	Nur als bearbeitbar markierte Felder, in der angezeigten Anfrage, für die gewählte Zielgruppe, mit Werten, die Jira akzeptiert. Eine Übermittlung, die ein anderes Feld nennt, wird vollständig abgelehnt.
Keine Rechteausweitung über die Konfiguration	Die Sicherheitsstufe und Container-Felder werden in der Speicherschicht abgelehnt, sodass weder Import noch manuelle Eingabe sie einschleusen können. Personenfelder lassen sich nie bearbeitbar machen.
Sichere Ausgabe	Ein Wert in einer unbekannten Form wird als leer dargestellt, sodass eine interne Struktur keinen nicht lizenzierten Kunden erreichen kann.
Schutz vor Injection	Jeder Pfadparameter einer REST-Anfrage wird gegen ein striktes Muster geprüft, stammt aus dem Atlassian-Kontext oder ist eine Konstante. Assets-Objekt-IDs dürfen nur aus Ziffern bestehen.
Nebenläufigkeit	Optimistisches Sperren bei jedem Speichern der Konfiguration und ein Abgleich mit dem Ausgangswert bei jeder Änderung durch Kunden.
Gefährliche Konstrukte	Keine dynamische Codeausführung, kein rohes HTML, kein Browserspeicher, keine direkten Netzwerkaufrufe.
Automatisierte Prüfung	Speicherung, Validierung, Darstellung, Bearbeitung, Portalentscheidungen, Wiederholungsversuche und alle 26 Sprachdateien sind durch eine Testsuite abgedeckt, die bei jeder Änderung läuft, dazu statische Codeanalyse in der CI.

Datenschutz

Sie sind Verantwortlicher für Ihre Daten. Wir sind dafür weder Verantwortlicher noch Auftragsverarbeiter: Die App läuft in Ihrem Tenant, und wir erhalten nichts, auch nicht die beiden Protokolle, die nur Ihre eigenen Administratoren lesen oder löschen können. Ihr Auftragsverarbeiter für Daten auf der Plattform ist Atlassian, auf Grundlage Ihres Vertrags mit Atlassian. Ein Auftragsverarbeitungsvertrag mit uns ist daher nicht erforderlich. Das bestätigen wir Ihnen für Ihre Beschaffungsunterlagen gern schriftlich.

Was wir nicht behaupten

Keine eigene Zertifizierung. Die Zertifizierungen von Atlassian gelten für die Plattform, auf der die App läuft. Sie gehören Atlassian, und wir geben sie nicht als unsere aus.
Die Protokolle sind kein Compliance-Archiv. Sie behalten die letzten 100 bzw. 200 Einträge.
Der Vorgangsverlauf in Jira nennt bei einer Änderung aus dem Portal nicht den Kunden. Das ist eine Eigenschaft der Plattform und lässt sich nicht einstellen.

Ein Sicherheitsproblem melden

Schreiben Sie an security@vi2va.de und nicht über den öffentlichen Support-Kanal, mit so vielen Details, dass sich das Problem nachvollziehen lässt. Wir bestätigen den Eingang, halten Sie bis zur Behebung auf dem Laufenden und gehen gegen niemanden vor, der in gutem Glauben meldet. Bitte senden Sie niemals API-Tokens oder Passwörter mit; wir werden nie danach fragen.

Beginnen Sie mit den drei Feldern, nach denen Ihre Kunden am häufigsten fragen

Zeigen Sie diese zuerst nur an. Geben Sie eines zur Bearbeitung frei, wenn Sie so weit sind. Bearbeitbar wird nichts, bevor Sie es einschalten.

Zum Marketplace Dokumentation