Sicherheitsverfahren

Unser Team

Wir wissen, dass die meisten Unternehmen dies sagen, aber wir sind außerordentlich stolz auf unser Sicherheitsteam. Wir glauben, dass wir ein Team zusammengestellt und aufgebaut haben, das aus den besten und klügsten Talenten der Branche besteht. Unser Sicherheitsteam wird von unserem CISO in San Francisco geleitet und umfasst über 100 Mitarbeiter in unseren Büros in Sydney, Amsterdam, Bengaluru, Austin, Mountain View, San Francisco und New York sowie einige Remote-Teammitglieder. Wir vergrößern das Team kontinuierlich, um dem Sicherheitsanspruch von Atlassian gerecht zu werden. Das Team besteht aus mehrere Abteilungen, darunter:

• Produktsicherheit – verantwortlich für die Sicherheit unserer Produkte und Plattformen
• Ökosystemsicherheit – verantwortlich für die Sicherheit des Marketplace und der Apps
• Detection and Response – responsible for detecting and responding to security incidents
• Red team - responsible for adversary emulation and exercising Detection and Response
• Sicherheitsarchitektur – verantwortlich für die Definition der Sicherheitsanforderungen unserer Produkte und Plattformen
• Unternehmenssicherheit – verantwortlich für die interne Sicherheit unseres Unternehmensnetzwerks und unserer Anwendungen
• Trust – verantwortlich für die Verfolgung von Kundenerwartungen, entsprechende Maßnahmen und Transparenz hinsichtlich unserer Prozesse und Verfahren
• Entwicklung und SRE – verantwortlich für die Entwicklung und Ausführung von Tools für das Sicherheitsteam
• Sensibilisierung und Schulung – verantwortlich für sichere Arbeit unserer Mitarbeiter und Partner

Wir weiten unser Sicherheitsteam weiterhin aus, aber jeder bei Atlassian ist Teil unserer Mission, die Sicherheit zu verbessern. Dies vermitteln wir all unseren Mitarbeitern während ihrer gesamten Zeit, die sie in unserem Unternehmen beschäftigt sind. Unser angestrebtes Ziel ist es, unsere Mitarbeiter in der Cloudsicherheit anzuleiten, alle Kundenanforderungen an die Cloudsicherheit zu erfüllen, die Branchenanforderungen an Sicherheitsstandards und Zertifizierungen einzuhalten und unsere Maßnahmen zum Schutz der Kundendaten zu veröffentlichen. Unsere Ziele und Visionen vermitteln wir allen unseren Mitarbeitern während ihrer gesamten Zeit bei Atlassian.

Zusätzliche Sicherheitsprogramme

Während wir uns auf die Grundlagen der Sicherheit konzentrieren, bieten wir auch eine Reihe weiterer Programme, die einen umfassenden und proaktiven Sicherheitsansatz verfolgen. Dazu zählen unter anderem:

Kontinuierliche Verbesserung unseres Sicherheitsprogramms

Wir möchten unser Sicherheitsprogramm auf dem neuesten Stand halten und führender Partner in diesem Bereich sein. Wir wissen, dass wir hierzu unseren aktuellen Sicherheitsansatz immer wieder, auch im Vergleich zu unseren Mitbewerbern, überprüfen und Verbesserungsmöglichkeiten ermitteln müssen.

Zu diesem Zweck haben wir zusammen mit unabhängigen Beraterunternehmen zahlreiche Reifegradbewertungen unseres Sicherheitsprogramms durchgeführt und werden dies auch in Zukunft tun. So haben wir 2020 unser gesamtes Trust and Security Program einer Beurteilung unterzogen. Anhand der Beurteilungsergebnisse, einschließlich der wichtigsten Empfehlungen, schließen wir ermittelte Lücken und setzen Verbesserungsvorschläge um.

We have also defined a series of programs across our various security – such as Product Security and Detection and Response – to guide our internal improvement. We have defined metrics to support each of these programs which we review through our Security Management Team. We use these metrics to identify and target areas for improvement across each of our core capabilities.

Weiterführende Informationen

Dieses Whitepaper bietet einen groben Überblick über unseren Sicherheitsansatz. Weitere Informationen zu unserem Sicherheitsprogramm sind im Atlassian Trust Center verfügbar. Zudem stehen mehrere Webseiten und Whitepapers zu unterschiedlichen Bereichen unseres Sicherheitsprogramms zur Verfügung. Zum Beispiel:

• Wie Atlassian Kundendaten verwaltet
• Unser Ansatz für externe Sicherheitstests
• Unser Ansatz für die Handhabung von Sicherheitsvorfällen
• Unser Ansatz für das Schwachstellenmanagement
• Geteilte Verantwortung bei der Cloudsicherheit
• Unser Atlassian Trust Management System
• Unsere Atlassian-Richtlinien für Sicherheit & Technologie

Zero-Trust-Sicherheit in unseren Netzwerken

Atlassian sichert den Zugriff auf sein Unternehmensnetzwerk, interne Anwendungen und Cloudumgebungen mit dem Zero-Trust-Konzept ab. Einfach ausgedrückt lautet der Grundsatz von Zero Trust: "Vertraue niemals, überprüfe immer."

Zero Trust unterscheidet sich von herkömmlichen Netzwerksicherheitsansätzen, die ausschließlich auf die Benutzerauthentifizierung vertrauen, um festzustellen, ob ein Benutzer auf Ressourcen in einem Netzwerk zugreifen kann. Ein solcher Ansatz birgt das Risiko, dass ein nicht vertrauenswürdiges und unsicheres Gerät die Sicherheit gefährdet. Infolgedessen haben viele Unternehmen begonnen, Modelle einzusetzen, bei denen nur vertrauenswürdige Geräte auf ihr Netzwerk zugreifen dürfen, zum Beispiel indem sie Technologien zum Management von Mobilgeräten einsetzen oder den Zugriff auf Netzwerkebene auf eine Liste bekannter Geräte beschränken.

Obwohl sie nützlich sind, fehlt diesen Ansätzen die Granularität. Der Zero-Trust-Ansatz von Atlassian stellt sicher, dass der Nutzerzugriff auf Ressourcen und Services in unseren Netzwerken nicht nur auf den Anmeldedaten zur Authentifizierung basiert. Stattdessen werden dynamischen Entscheidungen anhand von Richtlinien getroffen, bei denen mehrere Faktoren herangezogen werden, um den Zugriff auf einzelne Ressourcen anhand des Sicherheitsniveaus des Nutzergeräts zu genehmigen oder abzulehnen (unabhängig vom Standort).

Einfach ausgedrückt haben wir im Rahmen unseres Zero-Trust-Modells Ressourcen in unserem Netzwerk basierend auf ihrer relativen Wichtigkeit und Vertraulichkeit in drei Stufen unterteilt:

• Offene Stufe – Jeder Unternehmensbenutzer, der sich erfolgreich bei unserem Netzwerk authentifiziert hat, kann auf diese Dienste zugreifen.
• Niedrige Stufe – Der Zugriff auf diese Ressourcen ist einem authentifizierten Unternehmensbenutzer nur dann möglich, wenn er von einem vertrauenswürdigen Unternehmensgerät (Geräte, die Atlassian besitzt und verwaltet) oder einem verwalteten BYOD (einem persönlichen Gerät, das bei Atlassians MDM-Programm angemeldet ist) auf unser Netzwerk zugreift.
• Hohe Stufe – Diese Ressourcen sind nur verfügbar, wenn ein authentifizierter Unternehmensbenutzer von einem von Atlassian bereitgestellten Unternehmensgerät auf sie zugreift. Der Zugriff auf unsere Produktionsservices über unser Unternehmensnetzwerk ist nur über ein Gerät der hohen Stufe und SAML-Authentifizierung möglich.

Sicherer Zugriff auf unsere Systeme und Services

Atlassian hat für alle Systeme und Services einen genau definierten Prozess für die Bereitstellung (Zuweisung oder Aufhebung) des Benutzerzugriffs. Wir haben einen etablierten Workflow (8-Stunden-Synchronisierung), der unser HR-Managementsystem mit unserem Zugriffsbereitstellungssystem verbindet. Wir verwenden dabei eine rollenbasierte Zugriffskontrolle basierend auf vordefinierten Benutzerprofilen, um zu gewährleisten, dass Mitarbeiter nur Zugriffsrechte erhalten, die ihrer Rolle entsprechen. Alle Benutzerkonten müssen vom Management genehmigt werden, bevor sie Zugriff auf Daten, Anwendungen, Infrastruktur oder Netzwerkkomponenten erhalten.

Im Rahmen unserer Zero-Trust-Architektur kontrollieren wir den Zugriff auf unsere Unternehmensanwendungen über eine Single-Sign-On-Plattform. Um auf unsere Anwendungen zugreifen zu können, müssen sich Mitarbeiter über diese Plattform authentifizieren, unter anderem unter Verwendung eines zweiten Authentifizierungsfaktors. Benutzer müssen sich entweder über einen U2F-Schlüssel oder über eine mobile Authentifizierungs-App für Atlassian-Mitarbeiter authentifizieren. Weniger sichere Authentifizierungsmethoden wie Einmalpasswörter per SMS oder Telefon setzen wir nicht mehr ein. Atlassian verfolgt diesen Ansatz, um seinen Authentifizierungsprozess verlässlich gegen Phishing- und Man-in-the-Middle-Angriffe zu schützen – denn jedes System, bei dem vertrauliche Daten per Textnachricht versendet werden, kann von einem erfahrenen Angreifer kompromittiert werden.

Absicherung unserer Endgeräte

Atlassian verwendet mehrere Lösungen für das Endgerätemanagement, um Updates und Patches für Betriebssysteme und wichtige Anwendungen auf unseren Endgeräten bereitzustellen. Wir setzen zudem mehrere Lösungen für den Endgeräteschutz ein, um Bedrohungen wie Malware abzuwehren.

Im Rahmen unseres Zero-Trust-Ansatzes müssen sich Mitarbeiter von Atlassian, die über ihre persönlichen Mobilgeräte auf unsere Services zugreifen möchten, in der Regel für unser MDM-Programm (Mobile Device Management) anmelden. Dadurch stellen wir sicher, dass alle Mobilgeräte, die mit unserem Netzwerk verbunden sind, unsere Mindestsicherheitsanforderungen an Verschlüsselung, Gerätesperre, Anti-Malware-Software und Betriebssystemversionen erfüllen.

Alle berechtigten Mitarbeiter, die sich für unser MDM-Programm anmelden und dessen Regeln einhalten, erhalten von Atlassian eine monatliche Vergütung für ihre Teilnahme.

Falls ein Mitarbeiter ein Gerät nutzt, das als nicht konform eingestuft wurde, erhält er eine E-Mail, die ihn darüber informiert. Er hat dann 24 Stunden Zeit, die fehlende Compliance zu beheben, bevor der Zugriff für das jeweilige Gerät gesperrt wird.

Konfigurationsmanagement in unseren Systemen

Nur eine begrenzte Anzahl von Technikern und Architekten dürfen Software in unserer Produktionsumgebung installieren. In den meisten Fällen ist eine Softwareinstallation nicht möglich. Wir verwenden Konfigurationsmanagementtools in unseren Produktionsumgebungen, um Konfigurationen und Änderungen an Servern zu verwalten. Für eine bessere Einheitlichkeit werden direkte Änderungen an diesen Systemen durch die genehmigte Konfiguration überschrieben, die in den Konfigurationsmanagementtools festgelegt wurde. Wir nutzen Standard-AMIs (Amazon Machine Images) und alle Änderungen an unseren AMIs oder Betriebssystemen müssen über unseren standardmäßigen Änderungsmanagementprozess vorgenommen werden. Ausnahmekonfigurationen werden gemeldet und verfolgt und wir isolieren Serviceprobleme, damit sie sich nicht auf andere Services auswirken. Außerdem verfolgen wir einen PRGB-Prozess (Peer Review/Green Build), um sicherzustellen, dass in den Konfigurationstools vorgenommene Änderungen von mehreren Prüfern genehmigt werden. Alle Builds sind kryptografisch signiert und nur signierte Builds dürfen in unserer Produktionsumgebung ausgeführt werden.

Verwendung von Protokollen

Wir verwenden eine SIEM-Plattform, um Protokolle aus verschiedenen Quellen zu aggregieren, Überwachungsregeln auf diese aggregierten Protokolle anzuwenden und dann verdächtige Aktivitäten zu kennzeichnen. Wie diese Meldungen selektiert, weiter untersucht und eskaliert werden, ist in unseren internen Prozessen geregelt. Wichtige Systemprotokolle werden von jedem System weitergeleitet, in dem die Protokolle schreibgeschützt sind. Das Atlassian-Sicherheitsteam erstellt Warnmeldungen auf unserer Plattform für Sicherheitsanalysen und überprüft Anzeichen für Kompromittierungen. Unsere SRE-Teams nutzen die Plattform, um Verfügbarkeits- oder Leistungsprobleme zu überwachen. Protokolle werden 30 Tage lang als Hot Backup und 365 Tage als Cold Backup aufbewahrt.

Wichtige Systemprotokolle werden sowohl in einem internen Protokollanalysesystem als auch in einem Intrusion-Detection-System zusammengefasst.

Protokolle sind eine wichtige Komponente unserer gesamten Strategie zur Identifizierung und Behebung von Vorfällen, die im Abschnitt "Wie wir Sicherheitsbedrohungen identifizieren, abwehren und beheben" ausführlich behandelt wird.

Business Continuity und Disaster Recovery Management

Die Ausfallsicherheit unserer Produkte ist für uns ein wichtiges Anliegen, nicht zuletzt weil wir – intern bei Atlassian – auf dieselben Produkte angewiesen sind. Wir wissen, dass es zu Störungen kommen kann. Daher entwickeln wir Prozesse, um auf Störungen zu reagieren und dafür zu sorgen, dass sie sich nur minimal auf unsere Kunden auswirken. Unsere BC- und DR-Programme (Business Continuity und Disaster Recovery) umfassen die verschiedenen Maßnahmen, die wir verfolgen, um unsere Ziele zu erreichen.

Die Beteiligung der Führungskräfte an BC- und DR-Planungsaktivitäten sorgt für die erforderliche Aufsicht, damit sich alle Teams für die Ausfallsicherheit verantwortlich fühlen. Das Ziel unserer BC- und DR-Planungsaktivitäten ist es, durch eine Analyse der "Recovery Time Objectives" (RTO) und "Recovery Point Objectives" (RPO) von Services das richtige Gleichgewicht zwischen Kosten, Nutzen und Risiko zu erzielen. Diese Analyse hat zur Entwicklung eines einfachen, vierstufigen Systems geführt, um Gruppenservices basierend auf ihren jeweiligen Recovery-Anforderungen zu unterstützen. Details zu diesem Ansatz erläutern wir auf unserer Seite Wie Atlassian Kundendaten verwaltet.

Unsere BC- und DR-Programme umfassen folgende Aktivitäten:

1. Integrierte Redundanzmaßnahmen zur Erfüllung der Anforderungen an die Ausfallsicherheit

2. Test und Verifizierung der Redundanzmaßnahmen

3. Lernen auf Grundlage der Tests, um BC- und DR-Maßnahmen kontinuierlich zu verbessern

Wir entwickeln unsere Produkte so, dass sie Redundanzfunktionen wie Availability Zones und Regionen, die von unseren Cloud-Serviceanbietern angeboten werden, bestmöglich nutzen.

Wir überwachen kontinuierlich eine Vielzahl von Metriken mit dem Ziel, potenzielle Probleme frühzeitig zu erkennen. Basierend auf diesen Metriken werden Warnungen so konfiguriert, dass Site Reliability Engineers (SREs) oder die entsprechenden Produktentwicklungsteams benachrichtigt werden, wenn Schwellenwerte überschritten werden. So können automatisch Maßnahmen im Rahmen unseres Incident-Response-Prozesses ergriffen werden. SREs spielen auch eine Schlüsselrolle bei der Identifizierung von Lücken im DR-Programm und arbeiten mit unserem Risiko- und Compliance-Team zusammen, um diese Lücken zu schließen. Zu jedem unserer Teams gehört auch ein DR-Champion, der die mit diesem Team verbundenen Disaster-Recovery-Aspekte überwacht und verwaltet.

Unsere DR-Tests umfassen Prozess- und Technologieaspekte, einschließlich der relevanten Prozessdokumentation. Die Häufigkeit der DR-Tests richtet sich nach der Bedeutung des jeweiligen Services – beispielsweise werden Backup- und Recovery-Prozesse für wichtige kundenorientierte Systeme vierteljährlich getestet. Wir führen manuelle und Ad-hoc-Failover-Tests unserer Systeme durch. Diese Tests reichen von weniger komplizierten Tabletop-Simulationsübungen bis hin zu komplizierteren Availability-Zone- oder regionalen Failover-Tests. Unabhängig von der Komplexität des Tests legen wir großen Wert auf Sorgfalt beim Erfassen und Dokumentieren von Testergebnissen, bei der Identifizierung und Analyse von möglichen Verbesserungen und Lücken sowie bei deren abschließender Bearbeitung mithilfe von Jira-Tickets. So können wir den Gesamtprozess kontinuierlich verbessern.

Wir führen jährliche Business Impact Assessments (BIAs) durch, um die mit wichtigen Services verbundenen Risiken zu bewerten. Die Ergebnisse dieser BIAs unterstützen unsere Maßnahmenstrategie im Bereich DR und BC. So können effektive DR- und BC-Pläne für wichtige Services entwickelt werden.

Serviceverfügbarkeit

Zusätzlich zu den oben genannten Maßnahmen veröffentlichen wir in Echtzeit den Verfügbarkeitsstatus unserer Services für unsere Kunden. Hierfür verwenden wir unser Produkt Statuspage. Wenn es Probleme bei einem unserer Produkte gibt, informieren wir unsere Kunden umgehend.

Backups

Atlassian verfolgt ein umfassendes Backup-Programm. Dies schließt unsere internen Systeme ein, bei denen unsere Backup-Maßnahmen in Einklang mit den Anforderungen zur Systemwiederherstellung erstellt wurden. Wir bieten ebenso umfangreiche Backup-Maßnahmen für unsere Atlassian Cloud-Angebote, insbesondere für Kunden- und Anwendungsdaten. Atlassian nutzt die Snapshot-Funktion von Amazon RDS (Relational Database Service), um automatische tägliche Backups jeder RDS-Instanz anzulegen.

Amazon RDS-Snapshots werden 30 Tage lang aufbewahrt. Sie unterstützen die zeitpunktspezifische Wiederherstellung (Point-in-Time Recovery) und sind mit dem AES-256-Standard verschlüsselt. Die Backup-Daten werden nicht extern gespeichert, sondern in mehreren Rechenzentren innerhalb einer bestimmten AWS-Region repliziert. Zudem werden unsere Backups alle drei Monate getestet.

Für Bitbucket werden Daten in eine andere AWS-Region repliziert. In jeder Region werden täglich unabhängige Backups erstellt.

Wir verwenden diese Backups nicht, um destruktive Änderungen von Kunden rückgängig zu machen, wie zum Beispiel von Skripts überschriebene Felder oder gelöschte Vorgänge, Projekte oder Sites. Um Datenverlust zu vermeiden, empfehlen wir regelmäßige Backups. Mehr über die Erstellung von Backups erfährst du in der Supportdokumentation zu deinem Produkt.

Physische Sicherheit

Die physischen Sicherheitskontrollen in unseren Büros orientieren sich an unserer Richtlinie für physische und umgebungsbezogene Sicherheit, die sicherstellt, dass in unseren Umgebungen vor Ort und in der Cloud robuste physische Sicherheitsmaßnahmen implementiert werden. Die Richtlinie umfasst unter anderem Themen wie sichere Arbeitsbereiche, die Absicherung unserer IT-Ausrüstung an jedem Standort, die Beschränkung des Zutritts zu unseren Gebäuden und Büros auf geeignetes Personal und die Überwachung von physischen Ein- und Ausgangspunkten. Unsere Verfahren für die Sicherheit vor Ort umfassen die Besetzung des Empfangs während der Arbeitszeit, die Registrierung der Besucher und der Zugang zu nicht öffentlichen Bereichen unter Vorlage eines Ausweises. Wir arbeiten mit dem Bürogebäudemanagement zusammen, um den Zutritt nach den Geschäftszeiten zu regeln und Ein- und Ausgangspunkte sowohl an den Haupteingängen als auch Ladeflächen per Video zu überwachen.

Die Rechenzentren unserer Partner sind mindestens SOC2-konform. Diese Zertifizierungen beziehen sich auf eine Reihe von Sicherheitskontrollen, einschließlich physischer und umgebungsbezogener Sicherheit. Der Zugang zu den Rechenzentren ist auf autorisiertes Personal beschränkt und wird durch biometrische Maßnahmen zur Identitätsprüfung überprüft. Vor Ort sorgen außerdem Wachpersonal, Videoüberwachungsanlagen, Zugangsschleusen und weitere Einbruchsschutzmaßnahmen für Sicherheit.

Datenverschlüsselung

Alle Kundendaten in Atlassian Cloud-Produkten werden bei der Übertragung über öffentliche Netzwerke mithilfe von TLS 1.2+ mit Perfect Forward Secrecy (PFS) verschlüsselt, um sie vor einer unautorisierten Veröffentlichung oder Modifikation zu schützen. Unsere Implementierung von TLS setzt die Verwendung starker Chiffren und Schlüssellängen voraus, sofern diese vom Browser unterstützt werden.

Datenlaufwerke auf Servern, auf denen Kundendaten und Anhänge in Jira Software Cloud, Jira Service Management Cloud, Jira, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie und Trello gespeichert sind, verwenden im Ruhezustand die AES-256-Verschlüsselung nach Branchenstandard. Weitere Informationen zu künftigen Plattform-Updates erhältst du in der Atlassian Trust Roadmap.

Schlüsselmanagement

Atlassian nutzt den AWS Key Management Service (KMS) für das Schlüsselmanagement. Der Verschlüsselungs-, Entschlüsselungs- und Schlüsselmanagementprozess wird im Rahmen interner Prüfprozesse regelmäßig von AWS untersucht und verifiziert. Jedem Schlüssel wird ein Besitzer zugewiesen, der dafür zuständig ist, dass angemessene Sicherheitsmaßnahmen für die Schlüssel in Kraft sind.

Mandantentrennung

Unsere Kunden greifen auf eine gemeinsame cloudbasierte IT-Infrastruktur zu, wenn sie die Produkte von Atlassian nutzen. Wir haben daher Maßnahmen für eine logische Trennung ergriffen, damit die Aktionen eines Kunden die Daten oder Services anderer Kunden nicht gefährden.

Je nach Anwendung verfolgt Atlassian hier unterschiedliche Ansätze. Im Fall von Jira und Confluence Cloud setzen wir auf das Konzept "Tenant Context" (Mandantenkontext), um Kunden logisch zu isolieren. Umgesetzt wird es im Anwendungscode und verwaltet über den von uns entwickelten "Tenant Context Service" (TCS). Das Konzept stellt Folgendes sicher:

• Die ruhenden Daten jedes Kunden werden logisch getrennt von denen der anderen Mandanten aufbewahrt.
• Alle Anfragen, die über Jira oder Confluence verarbeitet werden, verfügen über eine "mandantenspezifische" Ansicht, sodass andere Mandanten davon nicht betroffen sind.

Vereinfacht gesagt speichert der TCS für die einzelnen Mandanten der Kunden einen "Kontext". Der Kontext für jeden Mandanten ist mit einer eindeutigen ID verknüpft, die zentral vom TCS gespeichert wird, und enthält eine Reihe von Metadaten, die mit diesem Mandanten verknüpft sind (z. B. in welchen Datenbanken sich der Mandant befindet, welche Lizenzen der Mandant hat, auf welche Funktionen er zugreifen kann und eine Reihe anderer Konfigurationsinformationen). Wenn ein Kunde auf Jira Cloud oder Confluence Cloud zugreift, stellt der TCS die Metadaten anhand der Mandanten-ID zusammen und verknüpft diese dann mit allen Aktionen, die der Mandant im Sitzungsverlauf in der Anwendung vornimmt.

Der vom TCS bereitgestellte Kontext funktioniert dabei wie eine "Linse", durch die alle Interaktionen mit den Kundendaten getunnelt werden – und diese Linse ist immer auf einen einzigen Mandanten ausgerichtet. So ist sichergestellt, dass der Mandant nicht auf die Daten anderer Mandanten zugreifen kann oder ein Mandant durch seine Aktionen den Service eines anderen Mandanten beeinflusst.

Weitere Informationen zu unserer Cloud-Architektur sind als Teil unserer Cloud-Supportressourcen verfügbar.

Geteilte Verantwortung bei der Verwaltung von Kundendaten

Atlassian übernimmt die Verantwortung für die Sicherheit, Verfügbarkeit und Leistung der von uns bereitgestellten Anwendungen, der Systeme, auf denen sie ausgeführt werden, und der Umgebungen, in denen die Systeme gehostet werden. In den folgenden vier Bereichen teilen sich Atlassian und seine Kunden jedoch die Verantwortung für die Sicherheit:

Kontrolle des Zugriffs auf Kundendaten

Für alle Kundendaten gilt dieselbe Vertraulichkeitsstufe und der Zugriff auf diese Daten wird streng kontrolliert. Unsere Mitarbeiter und Auftragnehmer nehmen im Rahmen des Onboardings an einer Sensibilisierungsmaßnahme teil und erlernen den sicherheitsbewussten Umgang mit Kundendaten.

Innerhalb unseres Unternehmens haben ausschließlich autorisierte Atlassian-Mitarbeiter Zugriff auf die Kundendaten, die in unseren Anwendungen gespeichert sind. Die Authentifizierung erfolgt über individuelle passwortgeschützte öffentliche Schlüssel und Server akzeptieren nur eingehende SSH-Verbindungen von Atlassian und internen Rechenzentrumsstandorten. Der Zugriff ist grundsätzlich auf berechtigte Gruppen beschränkt, es sei denn, er wurde speziell angefragt und geprüft. Zudem ist eine Zwei-Faktor-Authentifizierung (2FA) erforderlich.

Unser für Wartungs- und Supportprozesse zuständiges Supportteam befolgt strenge Regeln zur Authentifizierung und Autorisierung. Der Zugriff auf die gehosteten Anwendungen und Daten erfolgt zur Überwachung der Anwendungsfunktionen und zur Durchführung der System- und Anwendungswartung oder nach Kundenanfrage über unser Supportsystem. Über unseren Consent Control Checker können Kunden zudem prüfen, welche Supporttechniker im Rahmen einer ausdrücklichen Zustimmung auf ihre Daten zugreifen dürfen.

Der unautorisierte oder missbräuchliche Zugriff auf Kundendaten wird als Sicherheitsvorfall eingestuft und über unseren Vorfallmanagementprozess verfolgt. Der Prozess umfasst Anweisungen zur Benachrichtigung betroffener Kunden, sofern es zu einem Richtlinienverstoß kam.

Aufbewahrung und Löschung von Daten

Wir verfügen über Bestimmungen für die Reaktion auf Benutzeranfragen zur Löschung personenbezogener Daten und helfen Endbenutzern mit Atlassian-Konten dabei, ihre personenbezogenen Daten zu löschen. Wir bieten zudem Import- und Export-Tools, damit unsere Kunden mit Atlassian-Tools auf ihre Daten zugreifen, sie importieren und exportieren können.

Kunden-Sites werden 15 Tage nach Ende des laufenden Abonnementzeitraums deaktiviert. Atlassian bewahrt die Daten deaktivierter Sites für die Dauer von 15 Tagen (bei Testversionen) oder 60 Tagen (bei kostenpflichtig abonnierten Sites) nach Ende des laufenden Abonnementzeitraums auf. Bitte beachte, dass Jira-Daten nur gelöscht werden, wenn du alle Jira-Produkte kündigst, die du bisher abonniert hattest.

Weitere Informationen findest du auf unserer Seite zu Sicherheitsverfahren und in den FAQ zur Datenspeicherung.