ATLASSIAN CLOUD ENTERPRISE · GUARD PREMIUM · REGULIERTE BRANCHEN
Eure Auditoren ziehen mit in die Cloud.
In Data Center habt ihr eure eigene Datensegregation gebaut: ein Dropdown auf jeder Seite, klassifiziert, zurückgemeldet an die Auditoren. In der Cloud müssen dieselben Fragen ab Tag eins beantwortet sein – mit Guard Premium statt Eigenbau.
DIE AUDIT-LÜCKE
Compliance bremst Migrationen – deshalb fangen wir dort an.
Dutzende Instanzen über Konzerngesellschaften hinweg, jede mit eigenen Admins und eigenen Regeln. Die technische Migration ist lösbar; die Auditoren zu überzeugen ist der schwierige Teil.
Eigenbau-Segregation reist nicht mit
Das Data-Center-Dropdown, das jede Seite klassifiziert hat, und die Auswertung dahinter müssen auf Plattform-Fähigkeiten neu entstehen, nicht als Plugin-Code.
Niemand weiß, wo die Daten liegen
Sensible Inhalte liegen selten sauber im dafür vorgesehenen Projekt. Sie sind überall – und genau das fragt der Auditor zuerst.
Viele Admins, ein Standard
Ein Dutzend Jira-Admins, jeder macht es ein bisschen anders. Irgendwer öffnet anonymen Zugriff, um ein Ticket zu teilen – und die Frage wird, wer wirklich die Kontrolle hat.
KLASSIFIZIERUNG & POLICY
Labels allein tun nichts. Verheiratet mit Policies, tun sie alles.
Eine Klassifizierung ist ein Name und eine Farbe. Den Wert liefern Data-Security-Policies, die darauf reagieren – zentral gesteuert und außerhalb der Reichweite lokaler Admins.
Ein Boden, kein Wunsch
Setzt den Organisations-Standard so, dass alles ab Tag eins mindestens intern ist – und klassifiziert dann in dem Tempo nach oben, das das Business trägt.
Policies, die durchsetzen
Kein Anhang-Download oberhalb einer Klassifizierung. Kein anonymer Zugriff. Keine öffentlichen Links. Angewendet pro Space und Projekt, einmal entschieden.
Marketplace-Apps im Geltungsbereich
Eine eigene Policy begrenzt, wohin Drittanbieter-Apps reichen dürfen. Jeder Anbieter ist eine Lieferketten-Frage; das ist die Antwort, die ihr einem Auditor zeigen könnt.
Start bei null Risiko
Premium einschalten, ohne aktive Policies. Logs und Alerts beobachten, das Umfeld verstehen – dann handeln. Niemand verliert dabei den Zugriff.
GOVERNANCE ÜBER KONZERNGESELLSCHAFTEN
Ein Organisations-Admin. Policies, die ein Jira-Admin nicht umgehen kann.
SITE-ADMIN
Data-Security-Policies
Klassifizierungs-Katalog
Projekt- & Space-Workflows
Ausnahme auf Space-Ebene
ORG-ADMIN
Data-Security-Policies
Klassifizierungs-Katalog
Projekt- & Space-Workflows
Ausnahme auf Space-Ebene
DIE MICROSOFT-PURVIEW-LÜCKE
Wenn eure Labels in Purview leben, muss jemand beide Seiten ehrlich halten.
Es gibt heute keinen fertigen Connector.
Die fünf Stufen nachbauen
Dieselben Vertraulichkeitsstufen wie in Purview, einmal in der Atlassian-Organisation angelegt. Schnell gemacht, ohne Integration aber für immer manuell.
Labels lesen, Logs zurückspielen
Eine Marketplace-App, die Vertraulichkeits-Labels aus Purview liest und die Audit-Spur zurückgibt – Auditoren bleiben in ihrem gewohnten Tool statt Jira lernen zu müssen.
Ihr steht nicht auf dem Trockenen
Bringt Atlassian den Connector später selbst, verliert ihr nichts – Klassifizierungen, Policies und Log-Routing stehen schon, die Integration zieht sich still zurück.
VERFÜGBAR, GEPLANT, UNTERWEGS
Für heute bauen. Für das nächste Release planen.
Wir verfolgen die Roadmap, damit Ihre Architektur nicht neu gebaut werden muss.
Klassifizierungen, Policies, Detections, ausführliche Logs
Alles, um die Audit-Fragen zu beantworten, die ihr heute in Data Center beantwortet.
Policies auf Klassifizierungen · Rovo-Chat-Sicherheit · Anhang-Scan
In früher Vorschau und wenige Wochen entfernt – inklusive Detections für das, was Nutzer an die KI senden und von ihr abfragen.
Zugriff auf Basis der Klassifizierung
Zugriff gesteuert über die Klassifizierung statt allein über Berechtigungen – ohne festes Datum. Bis dahin lösen wir es über Berechtigungsgruppen, die den Wechsel überleben.
Policies in Klartext formuliert
Das Policy-Dokument übergeben statt reguläre Ausdrücke zu schreiben, und die Regeln daraus entwerfen lassen.
DETECTION & AUTOMATISIERUNG
Die Daten finden, automatisch klassifizieren, dann handeln.
Rund 70 Detections sind ab Werk dabei: Sozialversicherungsnummern, IBANs, Kreditkarten, Gesundheits- und Finanzentitäten, AWS-Keys – teils regional, alle einsatzbereit. Alles andere wird eine eigene Detection per regulärem Ausdruck. Findet Guard eine Kartennummer irgendwo, wird die Seite automatisch als vertraulich eingestuft – außer sie ist schon höher eingestuft. Genau das beruhigt Auditoren: Ihr wisst, wo sensible Daten liegen, auch außerhalb ihres vorgesehenen Zuhauses.
- ~70 Detections ab Werk, plus eigene Muster per Regex
- Automatische Klassifizierung, sobald ein Treffer irgendwo auftaucht
- Automation am Alert: einschränken, benachrichtigen, verzweigen
- Nutzeraktivität im Blick: verdächtige Suchen, Massen-Exporte, Logins aus Tor-Exit-Nodes
Jeder Content-Scan-Alert kann eine Automation auslösen: Seite einschränken, Owner benachrichtigen, nach Muster verzweigen. Zwei getrennte Streams tragen die Beweiskette – der unveränderliche Organisations-Audit-Log (Webhook oder REST-API) an das Plattform-Team, der Guard-Detect-Alert-Webhook an die Security.
SO SETZEN WIR ES UM
Beobachten, feinjustieren, dann automatisieren – nie umgekehrt.
Erst beobachten, dann eingreifen.
Einschalten, nichts ändern
Premium aktiv, keine Policy scharf. Logs und Alerts beobachten und lernen, wie das Umfeld wirklich aussieht.
Muster feinjustieren
Eine schlampige Detection trifft alles. Wir lassen eigene Detections Stunden laufen, bevor etwas Automatisches daran hängt.
Das Offensichtliche automatisieren
Einschränken und benachrichtigen, wo das Muster eindeutig ist; einen Menschen im Loop lassen, wo es das nicht ist. Niemand liest jeden Alert.
Den Auditoren die Beweise geben
Log-Routing ins SIEM, Policies dokumentiert, Ausnahmen protokolliert – der Migrationsfall ergibt sich von selbst.
HÄUFIGE FRAGEN
Was Auditoren und IT-Leitung als Erstes fragen.
Antworten, die den Migrationsentscheid beschleunigen.
Nicht als Code, aber als Ergebnis: Statt eines selbst gebauten Dropdowns mit eigener Reporting-Logik bekommt ihr fünf bis zehn Stufen, einen Organisations-Standard und Policies, die auf jeder Stufe greifen. Die Migration ist eine Übersetzung der Regeln, kein Rewrite der App.
Der Organisations-Standard setzt einen Boden – alles startet mindestens intern, ab dem Moment, in dem ihr Premium aktiviert. Bestehende Inhalte klassifiziert ihr im Tempo, das euer Team trägt; die automatische Klassifizierung durch Detection greift parallel, unabhängig vom manuellen Fortschritt.
Das hängt vom Umfeld ab, nicht von der Technik: Wir aktivieren Premium ohne Policies, beobachten Logs und Alerts einige Wochen, justieren eigene Detections nach und schalten erst dann automatische Restriktionen scharf. Das verhindert, dass eine zu breite Regel produktive Arbeit blockiert.
Guard Premium deckt die Atlassian-Seite vollständig ab. Ohne Integration bleiben Purview-Labels und Atlassian-Klassifizierung zwei getrennte Systeme, die von Hand synchron gehalten werden müssen – genau die Lücke, die wir mit einer Marketplace-App schließen, sobald sie gebraucht wird.
NÄCHSTER SCHRITT
Bringt die Fragen eurer Auditoren mit. Wir beantworten sie eine nach der anderen.
Ein Compliance-Review eures Data-Center-Setups gegen Guard Premium – was direkt passt, was einen Workaround braucht und worauf es sich zu warten lohnt. Ihr geht mit der Roadmap, nicht mit einem Pitch.