Admin Ops für JiraSicherheit & Compliance
Für die Menschen, die die App freigeben, statt sie zu benutzen: Sicherheitsprüfung, Datenschutz und Einkauf. Jede Antwort hier folgt aus der Bauweise der App.
Die Kurzfassung
| Frage | Antwort |
|---|---|
| Wo läuft die App? | Vollständig auf der Plattform Atlassian Forge, in Ihrem Atlassian-Tenant. Es gibt keine Infrastruktur des Anbieters dazwischen. |
| Verlassen Daten Atlassian? | Nein. Die App deklariert keine externen Endpunkte und macht keine externen Netzwerkaufrufe. Es gibt nichts freizuschalten. |
| Gibt es Unterauftragsverarbeiter? | Keine. Kein Dritter erhält Daten, weil keine Daten gesendet werden. |
| Hat die App eigene Rechte? | Nein. Jeder Aufruf läuft als der Administrator, der sie benutzt. Es gibt kein Dienstkonto und keinen Modus mit erweiterten Rechten. |
| Erreicht sie Daten, die der Bediener nicht erreicht? | Nein. Jira wendet bei jedem Aufruf seine normale Projektberechtigung an. |
| Gibt es einen Hintergrundprozess? | Einen: den wöchentlichen Bericht über personenbezogene Daten, den Atlassian von Apps verlangt, die solche speichern. Er liest nur den eigenen Speicher der App. |
| Runs on Atlassian? | Die App erfüllt die Voraussetzungen für das Programm „Runs on Atlassian“, als Folge der Antworten oben. |
Datenresidenz
Fragen zur Datenresidenz drehen sich meist darum, wo die Server eines Anbieters stehen. Admin Ops hat keine. Die App liest und schreibt Ihr Jira über die APIs von Atlassian, aus der Infrastruktur von Atlassian heraus, und legt ihren kleinen Datenbestand im Forge-Speicher am selben Ort ab. Die Daten bewegen sich nicht, es gibt also keine Übermittlung zu bewerten und keine Region zu wählen: Es gilt die Datenresidenz-Einstellung Ihrer Atlassian-Site, genau wie für den Rest von Jira.
Was gespeichert wird
Die App speichert Konto-IDs statt Personen. Die Ausnahmen sind offengelegt, nicht versteckt.
| Daten | Personenbezogen? | Aufbewahrung |
|---|---|---|
| Protokoll: Jobtyp, Konto-IDs von Auslöser und Ziel, Objekt-IDs, Anzahlen, Zeitstempel, Ergebnisse | Konto-IDs sind pseudonyme Kennungen | Letzte 50 Läufe |
| Objektnamen im Protokoll (Filter, Dashboards, Schemes, Felder, Gruppen, Projekte, Screens) | Möglich. Die Namen vergeben Ihre Nutzer; ein Filter „Krankmeldung – A. Meier“ wird so gespeichert | Letzte 50 Läufe |
| E-Mail-Adressen eines Kundenimports, im Eintrag dieses Laufs | Ja, bewusst: Eine abgelehnte Zeile hat kein Konto, auf das sie verweisen könnte | Letzte 50 Läufe |
| Zugriffsrichtlinie: Konto-ID und Rolle jedes benannten Administrators | Ja. Solange der Zugriff uneingeschränkt ist (Standard), wird nichts gespeichert | Bis zur Änderung |
| Festgehaltene Vorschau: eine JQL-Abfrage und die ermittelten Vorgangs-IDs | Nein | Einmalig, 10 Minuten |
Zu keinem Zeitpunkt werden Vorgangsinhalte, Geheimnisse oder Tokens gespeichert, und keine personenbezogenen Daten gelangen in Diagnoseprotokolle. Beim Deinstallieren wird alles gelöscht.
Berechtigungen (Forge-Scopes)
Die App fordert fünfzehn Scopes an. Zwölf sind granular; drei sind breit, weil Jira für diese Endpunkte nichts Engeres anbietet. Jeder ist mit Begründung aufgeführt.
| Scope | Wofür er gebraucht wird |
|---|---|
read:jira-work | Filter, Dashboards und Vorgänge per JQL suchen; Filterfreigaben und Feldnutzung lesen. |
write:jira-work | Eigentum an Filtern und Dashboards übertragen; bestätigte Massenoperationen ausführen; Filter löschen oder Freigaben entfernen. |
read:jira-user | Benutzer in den Auswahlfeldern auflösen und prüfen. |
read:group:jira | Gruppenmitgliedschaften und Gruppengrößen lesen und verhindern, dass der letzte Administrator entfernt wird. |
write:group:jira | Eine ausscheidende Person aus Gruppen entfernen. Bewusst granular: Für diesen Schreibvorgang wird kein manage-Scope angefordert. |
read:permission:jira | Bei jedem Backend-Aufruf prüfen, dass der Aufrufer „Jira verwalten“ besitzt. |
read:permission-scheme:jira | Berechtigungsschemata für das Audit und die Vorschau der Konsolidierung lesen. |
read:board-scope:jira-software | Die Boards finden, die auf einem Filter aufbauen, damit der Filter eines Boards nie zum Löschen empfohlen wird. |
read:project:jira | Von diesem Board-Endpunkt verlangt, außerdem um Projekte in Nutzungsberichten zu benennen. |
manage:jira-projectbreit | Jeder Screens-Endpunkt verlangt ihn, auch zum Lesen; außerdem die Zuweisung eines Berechtigungsschemas beim Konsolidieren. |
manage:jira-configurationbreit | Kontexte eines Feldes lesen, Screen-Schemata für Vorgangstypen, Benachrichtigungsschemata und das Verschieben eines Feldes in den Papierkorb. |
manage:servicedesk-customerbreit | Jira Service Management stellt Organisationen und Kunden nur hinter diesem Scope bereit. |
read:servicedesk-request | Die Service Desks für die Kunden- und Organisationsberichte auflisten. |
storage:app | Forge-Speicher für Protokoll, Zugriffsrichtlinie und die kurzlebige Vorschaumenge. |
report:personal-data | Der wöchentliche Bericht gespeicherter Konto-IDs, den Atlassian verlangt, damit geschlossene Konten gelöscht werden können. |
Die breiten Scopes erlauben mehr, als die App nutzt. Die Absicherung ist strukturell: Jeder Aufruf läuft als der aufrufende Administrator, jede Anfrage prüft „Jira verwalten“ neu, und jede Änderung wird vorab gezeigt, bestätigt und protokolliert.
Kontrollen, nach denen Prüfer fragen
| Kontrolle | Umsetzung |
|---|---|
| Autorisierung bei jeder Anfrage | Jeder Backend-Aufruf prüft „Jira verwalten“ neu. Die Platzierung auf einer Admin-Seite gilt nicht als Autorisierung. |
| Rechteausweitung | Nicht möglich: Schreibzugriffe laufen als der aufrufende Benutzer, nie als die App. |
| Funktionstrennung | Eine Richtlinie in der App weist benannten Administratoren Auditor, Operator oder Owner zu, auf dem Server durchgesetzt. Sie kann nur einschränken, was Jira ohnehin erlaubt. |
| Gefälschte Anfragen | Änderungen ermitteln ihre Ziele bei der Ausführung neu aus Jira, statt dem Browser zu vertrauen. |
| Zerstörerische Fehler | Vorschau, Bestätigung, Ausführung, bei Unumkehrbarem mit Eingabewort und namentlicher Objektliste. |
| Veraltete Daten | Massenoperationen handeln auf einer festgehaltenen, einmaligen Vorgangsmenge der Vorschau, gültig zehn Minuten. |
| Unvollständige Informationen | Wo eine unvollständige Antwort gefährlich wäre, wird die Operation blockiert statt versucht. |
| Lizenzdurchsetzung | Auf dem Server bei jeder schreibenden Operation geprüft. Ein Build-Test schlägt fehl, wenn ein schreibender Resolver sie auslässt. |
| Selbstaussperrung | Sie können sich nicht selbst aus der Jira-Administratorengruppe entfernen und keine Richtlinie speichern, die Ihnen die Owner-Rolle nimmt. |
Was wir nicht behaupten
- Hier wird keine Zertifizierung behauptet. Verlangt Ihr Prozess einen bestimmten Nachweis, fragen Sie uns; Sie bekommen eine klare Antwort, was es gibt und was nicht.
- Die App ist kein Compliance-Archiv. Ihr Protokoll hält die letzten 50 Läufe. Für langfristige Nachweise dient das Audit-Log von Jira, in dem jede Änderung der App ebenfalls erscheint.
- Die App ist kein Freigabe-Workflow. Eine Freigabe durch eine zweite Person gibt es in ihr nicht.
Sicherheitsbedenken melden
Stellen Sie eine Anfrage in unserem Support-Portal und kennzeichnen Sie sie im Betreff als Sicherheitsmeldung, oder schreiben Sie an support@vi2va.de. Bitte senden Sie niemals API-Tokens, Passwörter oder andere Geheimnisse; wir fragen nie danach.
Sehen Sie zuerst nach, was Ihre Instanz mit sich herumträgt
Die nur lesenden Audits funktionieren auch ohne Lizenz. Nichts ändert sich, bevor Sie es entscheiden.