Out of Office & Absence PlannerSicherheit & Datenschutz
Geschrieben für alle, die die App freigeben, statt sie zu benutzen: Sicherheitsprüfung, Datenschutz und Betriebsrat. Jede Antwort hier folgt daraus, wie die App gebaut ist.
Die Kurzfassung
| Frage | Antwort |
|---|---|
| Wo läuft die App? | Vollständig auf der Plattform Atlassian Forge, in Ihrem Atlassian-Tenant. Es gibt keine vom Anbieter betriebene Infrastruktur dazwischen. |
| Verlassen Daten Atlassian? | Nein. Die App deklariert keine externen Endpunkte und ruft nichts außerhalb auf. Es gibt nichts freizugeben. Sie nutzt nur Atlassians eigene Schnittstellen. |
| Gibt es Unterauftragnehmer? | Keine. Kein Dritter erhält Daten, weil keine Daten irgendwohin gesendet werden. Es ist keine Analyse- oder Telemetrie-Bibliothek eingebunden. |
| Wer kann einen Abwesenheitsgrund sehen? | Standardmäßig nur der Antragsteller und ein berechtigter Genehmiger. Ein Administrator kann Gründe in der Teamansicht freigeben, aber nie für einen als sensibel markierten Typ. Gründe erscheinen nie am Vorgang und nie in Logs. |
| Sehen Kollegen „krank“? | Nein. Bei einem als sensibel markierten Typ zeigt die Teamansicht anderen nur „Abwesend“. Das setzt der Server durch. |
| Wer sieht wessen Abwesenheiten? | Ein Administrator entscheidet: alle Jira-Nutzer, Mitglieder desselben Teams oder nur Genehmiger und Admins. Die Person selbst, ihre zuständigen Genehmiger und Jira-Administratoren sehen sie immer. Vom Server durchgesetzt. |
| Lassen sich personenbezogene Daten löschen? | Ja. Ein Administrator kann alle Daten einer Person in einem Schritt löschen, auch ohne aktives Abonnement. Eine optionale Aufbewahrungsfrist löscht beendete Abwesenheiten, und die Daten von Konten, die Atlassian als geschlossen meldet, werden wöchentlich gelöscht. |
| Gibt es einen Hintergrundprozess? | Ja, vier: einen stündlichen Vertretungs-Job, der Abwesenheiten startet und beendet und Vorgänge nur in den Projekten umverteilt, die ein Administrator ausgewählt hat, einen Auslöser bei Änderungen der zuständigen Person für den Warnkommentar, einen täglichen Aufbewahrungs-Job und eine wöchentliche Meldung personenbezogener Daten an Atlassian. |
| Runs on Atlassian? | Die App erfüllt die Voraussetzungen für Atlassians Programm „Runs on Atlassian“, als Folge der Antworten oben. |
Datenresidenz
Fragen zur Datenresidenz zielen meist darauf, wo die Server eines Anbieters stehen. Diese App hat keine. Sie liest und schreibt Ihr Jira über Atlassians eigene Schnittstellen, aus Atlassians Infrastruktur heraus, und hält Abwesenheitseinträge und Konfiguration im Forge-Speicher am selben Ort. Die Daten bewegen sich nicht, es gibt also keine Übermittlung zu bewerten: Die Datenresidenz-Einstellung Ihrer Atlassian-Site gilt dafür genauso wie für das übrige Jira. Verknüpfte Atlassian Teams sind keine Ausnahme: Ihre Mitglieder werden aus Atlassian gelesen, innerhalb von Atlassian, und höchstens 15 Minuten vorgehalten.
Was gespeichert wird
Personen erscheinen als Atlassian-Konto-IDs. Das einzige Freitextfeld, das sensible Angaben enthalten kann, ist optional.
| Daten | Personenbezogen? | Aufbewahrung |
|---|---|---|
| Abwesenheitseinträge: Konto-IDs von Antragsteller, Genehmiger, Vertretung und entscheidender Person, Zeitraum, Abwesenheitstyp, Status, Notiz zur Entscheidung, die Projekte, in denen die Vertretung laufen darf, das Team, über das der Antrag geleitet wurde | Ja | Bis zur Löschung: durch einen Administrator, durch die optionale Aufbewahrungsfrist oder wenn Atlassian das Konto als geschlossen meldet |
| Optionaler Grund als Freitext zu einer Abwesenheit | Ja, möglicherweise sensibel (etwa bei Krankheit). Längenbegrenzt, nie indiziert | Mit dem zugehörigen Abwesenheitseintrag |
| Konfiguration: Abwesenheitstypen, Genehmiger-Pool, Teams oder ihre Verknüpfung mit einem Atlassian Team, abgedeckte Projekte, Regel, Zeitzone, Sichtbarkeit, Sprache des Kommentars, Aufbewahrungsfrist, Schalter | Konto- und Gruppen-IDs von Genehmigern und von Mitgliedern manuell gepflegter Teams | Bis Sie sie ändern; eine Person wird entfernt, wenn ihre Daten gelöscht werden |
| Mitglieder eines verknüpften Atlassian Teams, aus Atlassian gelesen | Konto-IDs | Verfallen nach 15 Minuten; außerdem bei jedem Speichern der Einstellungen und jeder Löschung der Daten einer Person verworfen |
| Änderungsverlauf der Konfiguration: wer die Einstellungen wann geändert hat und welche; außerdem, dass Daten einer Person gelöscht wurden, nie wessen | Die Konto-ID des Administrators. Nie die geänderten Werte | Mit der Aufbewahrungsfrist bereinigt; als „Gelöschter Benutzer“ angezeigt, sobald die Daten dieses Administrators gelöscht sind |
| Buchführung der Vertretung: numerische IDs der Vorgänge, die an die Vertretung gingen | Nein: nur Vorgangs-IDs | Gelöscht, wenn die Vertretung endet; nur IDs von Vorgängen, die nicht zurückgegeben werden konnten, bleiben, damit der Antragsteller davon erfährt |
| Eine Markierung am Vorgang, damit die Warnung nur einmal erscheint | Nein: eine interne Abwesenheits-ID | Bleibt am Vorgang in Jira |
Logs enthalten nur Ereignisnamen, Abwesenheits-IDs, numerische Vorgangs-IDs, Zahlen und Statuscodes; nie Konto-IDs, Namen, Gründe oder Vorgangsschlüssel. Nach der Deinstallation löscht Atlassian den Speicher der App: Er wird 28 Tage aufbewahrt und dann endgültig gelöscht. Warnkommentare und die Markierung liegen in Jira, nicht in der App, und bleiben als Teil der Vorgangshistorie bestehen.
Berechtigungen (Forge-Scopes)
Die App fordert zehn Scopes an. Keiner ist spezifisch für Jira Service Management, und es gibt keinen Scope für Projektadministration, Boards oder Dashboards. Jeder steht hier mit seiner Begründung. Die beiden allgemeinen Jira-Vorgangs-Scopes, als weit markiert, erlauben mehr, als die App nutzt; Änderungen im Hintergrund bleiben auf die Projekte beschränkt, die ein Administrator ausgewählt hat und in denen der Antragsteller Vorgänge zuweisen darf.
| Scope | Wofür er nötig ist |
|---|---|
storage:app | Die eigenen Daten der App im Forge-Speicher ablegen: Konfiguration, Abwesenheitseinträge, Änderungsverlauf und den kurzlebigen Zwischenspeicher der Mitglieder von Atlassian Teams. |
read:jira-workweit | Die offenen Vorgänge einer Person finden und zuständige Person und Projekt eines Vorgangs lesen; die Jira-Administratorberechtigung und die Berechtigung „Vorgänge zuweisen“ des Antragstellers in den abgedeckten Projekten prüfen; die Projektauswahl in den Einstellungen. |
write:jira-workweit | Vorgänge der Vertretung zuweisen, sie nach der Rückkehr zurückgeben, den Warnkommentar schreiben (bei Anfragen in Jira Service Management intern) und dessen Markierung speichern. |
read:jira-user | Nutzer und Jira-Gruppen für die Auswahl von Genehmigern, Teams und Vertretung nachschlagen, prüfen, ob eine Vertretung zuweisbar ist, und die eigenen Gruppenmitgliedschaften des Aufrufers für gruppenbasierte Genehmiger ermitteln. |
report:personal-data | Die wöchentliche Meldung senden, die Atlassian von Apps verlangt, die Konto-IDs speichern, damit die Daten geschlossener Konten gelöscht werden können. |
view:team:teams | Atlassian Teams suchen und lesen, damit ein Administrator ein Team der App mit einem davon verknüpfen kann und die Verknüpfung beim Speichern geprüft wird. |
view:membership:teams | Die Mitglieder eines verknüpften Atlassian Teams lesen, für die Weiterleitung von Genehmigungen und die Sichtbarkeit im Team. |
read:account | Konto-ID und Kontostatus eines Teammitglieds lesen, damit nur aktive Konten zählen. Sonst wird nichts aus dem Profil gelesen. |
read:app-data:jira | Die zwischengespeicherten Antworten der App für die Abwesenheitssuche lesen, um sie aktualisieren zu können. Kundendaten werden damit nicht erreicht. |
write:app-data:jira | Diese zwischengespeicherten Antworten stündlich neu schreiben, damit ein gespeicherter Filter nicht weiter Personen findet, die längst zurück sind. |
Eine weitere Berechtigung im Manifest ist kein Scope: Inline-Styles für die Oberfläche der App, weil sich die Komponenten aus Atlassians Designsystem zur Laufzeit selbst gestalten. Sie gewährt keinen Datenzugriff und keinen Datenabfluss.
Kontrollen, nach denen Prüfer fragen
| Kontrolle | Umsetzung |
|---|---|
| Identität | Wird auf dem Server immer aus dem Forge-Kontext abgeleitet, nie aus der Anfrage übernommen. |
| Administrator-Aktionen | Lesen und Speichern der Einstellungen, die Suche nach Atlassian Teams, der Änderungsverlauf, der Vertretungs-Job auf Knopfdruck und das Löschen der Daten einer Person prüfen die Jira-Administratorberechtigung auf dem Server erneut. Die Platzierung auf einer Admin-Seite gilt nicht als Autorisierung. |
| Genehmigungen | Nur der Genehmiger-Pool, die Genehmiger des eigenen Teams oder ein Jira-Administrator dürfen entscheiden, nie der Antragsteller. Bei jeder Entscheidung gegen den gespeicherten Eintrag geprüft. |
| Gruppenbasierte Genehmiger | Die Mitgliedschaft wird im Moment der Entscheidung live aus dem eigenen Konto des Aufrufers ermittelt; wer aus der Gruppe entfernt wird, verliert das Recht sofort. |
| Ausforschen fremder Einträge | Stornieren darf nur der Eigentümer, und „nicht gefunden“ und „nicht Ihrer“ sind nicht zu unterscheiden. |
| Umverteilung im Hintergrund | Läuft als App, nur in den vom Administrator ausgewählten Projekten, in denen der Antragsteller beim Stellen des Antrags „Vorgänge zuweisen“ durfte, geprüft mit seinen eigenen Berechtigungen. Überspringt Vorgänge, deren Zuweisung Jira ablehnt. |
| Atlassian Teams | Als App gelesen, weil Apps Atlassian Teams nicht im Namen eines Nutzers lesen können. Die Team-Suche ist nur für Jira-Administratoren und liefert Namen und Mitgliederzahlen, nie Mitgliederlisten. Mitglieder dienen nur Entscheidungen auf dem Server über Weiterleitung und Sichtbarkeit. Ein Team, das sich nicht lesen lässt, gilt als leer; Teams, denen jeder beitreten kann, zählen nicht für die Sichtbarkeit. |
| Sensible Abwesenheitstypen | In der Teamansicht ersetzt der Server einen sensiblen Typ durch „Abwesend“ für alle außer dem Antragsteller, einem zuständigen Genehmiger und Jira-Administratoren und gibt seinen Grund nie heraus. |
| Löschung und Aufbewahrung | „Alle Daten einer Person löschen“ für Administratoren, auch ohne aktives Abonnement; wöchentliche Löschung der Daten von Konten, die Atlassian als geschlossen meldet; eine optionale Aufbewahrungsfrist von bis zu 3.650 Tagen. |
| Abfluss zum Kunden | Bei Anfragen in Jira Service Management ist der Warnkommentar immer intern, damit ein Kunde die Abwesenheit eines Agenten nie im Portal sieht. |
| Eingabeprüfung | Jede Anfrage wird auf Typ, Länge, erlaubte Werte, gültige Daten und ID-Formate geprüft. Nutzereingaben gelangen nie unmaskiert in JQL. |
| Änderungen der Konfiguration | Jedes Speichern wird mit Person und Zeitpunkt protokolliert, dazu welche Einstellungen sich geändert haben, nie deren Werte. |
Was wir nicht behaupten
- Hier wird keine Zertifizierung behauptet. Wenn Ihr Prozess einen bestimmten Nachweis verlangt, fragen Sie uns, und Sie bekommen eine klare Antwort, was es gibt und was nicht.
- Die App kann eine Zuweisung nicht verhindern. Forge bietet keinen blockierenden Haken; die Warnung kommt kurz nach der Änderung.
- Die Deinstallation entfernt nicht, was die App in Jira geschrieben hat. Warnkommentare und die Markierung bleiben an den Vorgängen, unter Ihrer Kontrolle.
- Die App ist kein führendes HR-System. Sie erfasst Abwesenheiten, um die Arbeit in Jira abzustimmen; Ansprüche, Urlaubskonten oder Lohndaten berechnet sie nicht.
Ein Sicherheitsproblem melden
Stellen Sie eine Anfrage in unserem Support-Portal und schreiben Sie in den Betreff, dass es sich um eine Sicherheitsmeldung handelt, oder schreiben Sie an support@vi2va.de. Bitte senden Sie nie private Abwesenheitsgründe, API-Tokens, Passwörter oder andere Geheimnisse; wir fragen nie danach.
Planen Sie die nächste Urlaubszeit, bevor sie beginnt
Abwesenheitstypen, Genehmiger und ein abgedecktes Projekt sind in etwa 10 bis 15 Minuten eingerichtet. Jira arbeitet währenddessen ganz normal weiter.