Sicherheitsverfahren

Wir glauben, dass in jedem Team das Potenzial für herausragende Leistungen steckt. Wir möchten Teams jeder Größe und aus allen Branchen dabei helfen, dieses Potenzial zu entfalten und die Menschheit durch Software voranzubringen.

Wir wissen, dass deine Mission für dich genauso wichtig ist wie unsere Mission für uns und dass Informationen ein wichtiger Bestandteil unseres Unternehmens und unseres Lebens sind. Im Mittelpunkt unserer Arbeit steht deshalb das Vertrauen unserer Kunden, und Sicherheit hat für uns oberste Priorität. Mit unserem transparenten Sicherheitsprogramm wollen wir erreichen, dass du dich bei der Nutzung unserer Produkte und Services ausreichend informiert und sicher fühlst.

Hier erfährst du mehr über unseren Sicherheitsansatz und darüber, wie Kunden sich einbringen können.

Die Informationen auf dieser Seite gelten für die Atlassian Cloud-Produkte Jira, Confluence und Bitbucket, sofern nicht anders vermerkt.

Unsere Maßnahmen

Unser Atlassian Trust Management System (ATMS) betrachtet die Sicherheitsanforderungen jedes einzelnen Kunden und destilliert daraus eine Reihe von Anforderungen und Initiativen, die für uns und unsere Umgebung einzigartig sind. Ausführliche Informationen zu unseren Initiativen findest du auf der Atlassian Trust-Website. Dort kannst du unsere Prüfprotokolle zu ISO 27001 und SOC 2 anfordern bzw. herunterladen und unseren CSA STAR-Fragebogen einsehen. Natürlich findest du dort auch weitere Details zum Atlassian Trust Management System (ATMS).

Integrierte Sicherheit

Für uns ist Sicherheit kein fixes Ziel, das wir irgendwann erreichen werden, sondern eine Reise, die niemals endet. Wir arbeiten hart daran, unsere Softwareentwicklungsprozesse und innerbetrieblichen Abläufe kontinuierlich zu verbessern, um die Sicherheit unserer Software und Services weiter zu erhöhen. Dabei sollte Sicherheit immer auch einfach sein. Deshalb sind alle diesbezüglichen Funktionen tief mit unseren Produkten und unserer Infrastruktur verwoben. Im Folgenden zeigen wir dir anhand einiger Beispiele, wie wir Sicherheit in unseren Alltag integrieren.

Architektur

Wenn wir unsere Anwendungen, Netzwerke und Geschäftsprozesse planen, steht Sicherheit immer an erster Stelle

Die Sicherheitsarchitektur von Atlassian Cloud deckt verschiedenste Branchenstandards und Frameworks ab und geht Hand in Hand mit unserem internen Prozess zur Bedrohungsmodellierung. Sie vereint Flexibilität mit wirksamen Kontrollmechanismen, die es uns erlauben, die Vertraulichkeit, Integrität und Verfügbarkeit von Kundendaten sicherzustellen.

Anwendungen

Sicherheit der Anwendungsentwicklung, Datensicherheit und Information Lifecycle Management

Sicherheit

Kryptografie und Verschlüsselung, Bedrohungs- und Schwachstellenmanagement, Management von Sicherheitsvorfällen

Infrastruktur

Asset-Management, Zugriffskontrolle, Betriebsabläufe, Kommunikationssicherheit

Rechenzentrum und Büros

Physische und umgebungsbezogene Sicherheit

Corporate

Sicherheits-Governance, Organisation der Sicherheit, Personalsicherheit, Management von Zulieferer- und Drittanbieterdaten, mobile Sicherheit, Geschäftskontinuität, Audit/Compliance, Datenschutz

Die Sicherheitskontrollen, auf denen unsere Architektur fußt, decken verschiedene Standards ab. Weil es zwischen diesen Standards viele Überschneidungen gibt, haben wir unser eigenes Kontroll-Framework entwickelt. Dieses Framework gibt uns klar vor, worauf wir uns konzentrieren müssen, und legt die Standards dar, die für uns gelten, wie in Tabelle 1 zu sehen ist.

Standard Sponsor Kontrollen Domains

ISO 27001

Internationale Organisation für Normung (International Organization for Standardisation, ISO)

26 Anforderungen

6 Klauseln

ISO 27002

Internationale Organisation für Normung (International Organization for Standardisation, ISO)

114 Anforderungen

14 Domains

PCI DSS

Zahlungskartenbranche

247 Anforderungen

6 Domains

CSA CCM

Cloud Security Alliance

133 Kontrollen

16 Domains

SOC2

Service Organisation Control

116 Anforderungen

5 Prinzipien

SOX 404 (IT)

US-Bundesgesetz

22 Anforderungen

5 Domains

GAPP

AICPA

106 Anforderungen

10 Domains

Wenn du Näheres erfahren möchtest, lies die Informationen über unser Common Controls Framework.

Networking

Beim Netzwerkzugang verfolgen wir einen schichtenbasierten Ansatz, wobei es für jede Schicht im Stack eigene Kontrollen gibt

Jede Schicht im Stack ist durch Kontrollen gesichert. Unsere Infrastruktur ist in Zonen, Umgebungen und Services unterteilt.

Zonenbeschränkungen betreffen zum Beispiel den möglichen Netzwerkverkehr in den Büros, im Rechenzentrum und über die Plattform. Umgebungen wie Produktion und Entwicklung sind voneinander getrennt, Verbindungen sind beschränkt. Services müssen über eine Authentifizierungsfreigabeliste explizit für die Kommunikation mit anderen Services autorisiert werden.

Den Zugriff auf unsere sensiblen Netzwerke schützen wir mithilfe von VPC-Routing (Virtual-Private-Cloud), Firewall-Regeln und Software Defined Networking. Alle Verbindungen werden standardmäßig verschlüsselt.

Der Netzwerkzugriff für Mitarbeiter ist durch Gerätezertifikate, Zwei-Faktor-Authentifizierung und Proxys für besonders sensible Netzwerkbereiche beschränkt. Der Zugriff auf Kundendaten ist nur nach Prüfung und Genehmigung möglich.

Zum Schutz vor potenziellen Sicherheitsproblemen haben wir in den Netzwerken der Büro- und Produktionsumgebung Systeme zur Angriffserkennung und -verhinderung implementiert.

Anwendung

Wir nutzen Bedrohungsmodellierung (Threat Modeling), um sicherzustellen, dass wir für jede Bedrohung, der wir ausgesetzt sind, die passenden Kontrollen implementiert haben

In der Produktplanungs- und Produktdesignphase nutzen wir Bedrohungsmodelle zur Bewertung der spezifischen Sicherheitsrisiken, die mit einem Produkt oder einer Funktion einhergehen. Grob gesagt kommen dabei Entwickler, Sicherheitsexperten, Architekturspezialisten und die Produktmanager einer Anwendung oder eines Service zu einem Brainstorming zusammen, bei dem mögliche Bedrohungen benannt und priorisiert werden. Die gewonnenen Erkenntnisse fließen in die Entwicklung von Kontrollmechanismen während des Designprozesses ein und ermöglichen in späteren Entwicklungsphasen zielgerichtete Funktionsprüfungen und Tests.

Wir verwenden das Microsoft Threat Modeling Tool und das STRIDE Threat Model Framework. Das Kürzel STRIDE setzt sich aus den Anfangsbuchstaben typischer Sicherheitsgefahren zusammen: Spoofing, Tampering, Reputation, Information Disclosure, Denial of Service und Elevation of Privilege (Spoofing, Manipulation, Rufschädigung, Informationspreisgabe, Denial of Service und Erhöhung von Berechtigungen).

Die Bedrohungsmodellierung kommt bei uns frühzeitig und häufig zum Einsatz. So sorgen wir dafür, dass es für alle Bedrohungen, die unsere Produkte oder Funktionen betreffen, relevante Sicherheitskonfigurationen und -kontrollen gibt.

Zuverlässigkeit

Unsere Kunden nutzen unsere Anwendungen sehr unterschiedlich. Aus Gesprächen mit ihnen wissen wir, dass Produkte wie Jira und Confluence oft Teil ihrer wichtigsten Geschäftsprozesse sind. Natürlich verlassen wir uns auch selbst auf unsere eigene Produktsuite, weswegen wir genau wissen, welch hohen Stellenwert Zuverlässigkeit und Wiederherstellbarkeit haben.

Plattformweite Verfügbarkeit und Redundanz

Wir betreiben mehrere Rechenzentren an verschiedenen Orten weltweit

Unsere Cloud-Anwendungen werden alle bei den Cloud-Hosting-Partnern AWS und NTT gehostet. Deren Rechenzentren sind speziell für das Anwendungshosting optimiert und mehrfach redundant ausgelegt. Sie werden auf einem getrennten Front-End-Hardwareknoten ausgeführt, auf dem die Anwendungsdaten gespeichert werden.

Besonderen Wert legen wir auf die hohe Verfügbarkeit unserer Daten und Services. Wir erreichen Ausfallsicherheit, indem wir uns an Standards und Verfahren orientieren, die uns eine Minimierung der Ausfallzeiten ermöglichen. Unsere Mechanismen für Ausfallsicherheit basieren auf SOC 2, ISO 27002 und ISO 22301.

Jira, Confluence, Statuspage, Trello, Opsgenie und Jira Align werden beim branchenführenden Cloud-Hosting-Anbieter Amazon Web Services (AWS) gehostet, wodurch wir weltweit optimale Performance mit Redundanz und Failover-Optionen sicherstellen können. Unsere Lösungen sind auf mehrere Verfügbarkeitszonen in den Regionen USA (Ost) und USA (West), in der Europäischen Union und in APAC verteilt.

Unser Rechenzentrum-Hosting-Partner für Bitbucket ist NTT, die mit SOC 2- und ISO27001-Zertifizierungen Sicherheit und Verfügbarkeit gewährleisten und uns zudem in ausreichendem Maße nachweisen, bei Aspekten wie physischer Sicherheit, Netzwerk- und IP-Backbone-Zugriff, Kunden-Provisioning und Problemmanagement die von uns geforderten Standards zu erfüllen.

Weitere Informationen dazu, wie wir mithilfe mehrerer Rechenzentren und Availability Zones für Hochverfügbarkeit sorgen, findest du auf unseren Seiten zur Verwaltung von Kundendaten und zu unserer Cloud-Hosting-Infrastruktur.

Backups

Wir haben ein umfangreiches Backup-Programm implementiert

Die Anwendungsdaten werden in einem ausfallsicheren Speicher abgelegt und übergreifend in unseren Rechenzentren repliziert. Zusätzlich zur plattformweiten Ausfallsicherheit haben wir ein umfangreiches Backup-Programm für unsere Atlassian Cloud-Angebote eingerichtet. Die Wiederherstellung dieser Backups ist jedoch ausschließlich über unsere eigene Atlassian Cloud-Plattform möglich.

Die Anwendungsdatenbanken von Atlassian Cloud werden in den folgenden Intervallen gesichert: Tägliche automatisierte Backups werden erstellt und 30 Tage lang aufbewahrt und können zeitpunktspezifisch wiederhergestellt werden. Snapshot- und Backup-Daten werden grundsätzlich verschlüsselt. Die Backup-Daten werden nicht extern gespeichert, sondern in mehreren Rechenzentren innerhalb einer bestimmten AWS-Region repliziert. Die Backups werden alle drei Monate getestet. Weitere Informationen findest du auf unserer Seite zur Cloud-Hosting-Infrastruktur. Wenn du wissen möchtest, wie wir unser Backup-Programm implementiert haben, sieh dir unsere Seite zur Verwaltung von Kundendaten an.

Business Continuity und Disaster Recovery

Wir verfügen über umfassende, getestete Pläne für Geschäftskontinuität und Disaster Recovery

Erstklassiger Kundenservice ist einer der Grundwerte unseres Unternehmens. Dazu gehören auch leistungsfähige Funktionen für Geschäftskontinuität (Business-Continuity, BC) und Disaster Recovery (DR), mit denen wir die Auswirkungen etwaiger Unterbrechungen und Störungen unserer Services auf unsere Kunden minimieren.

Unser Disaster-Recovery-Programm umfasst einige wichtige Praktiken, mit denen wir das richtige Maß an Governance, Überwachung und Tests sicherstellen:

  1. Governance: Die Geschäftsleitung ist in die Umsetzung unseres DR-Programms involviert. Durch Einbeziehung der Führungsebene sind bei unserer Ausfallsicherheitsstrategie die technischen und die geschäftlichen Bereiche gleichermaßen abgedeckt.
  2. Überwachung und Wartung: Wir gehen bei der Überwachung und Verwaltung unseres DR-Programms nach einem strikten Ansatz für Governance, Risikomanagement und Compliance vor. So können wir bei der Überwachung, Messung, Berichterstattung und Problembehebung für wichtige Aktivitäten im Rahmen des DR-Programms effizienter und effektiver handeln. Für die Zuverlässigkeit der Site zuständige Techniker (Site Reliability Engineers, SREs) kommen regelmäßig zu Disaster-Recovery-Meetings zusammen und vertreten dabei ihre kritischen Services. Sie besprechen erkannte DR-Lücken mit dem für Risiko und Compliance zuständigen Team und verfolgen die angemessene Problembehebung.
  3. Tests: Wir führen regelmäßig Tests durch und bemühen uns im Zuge des DR-Lebenszyklus um kontinuierliche Verbesserung, damit deine Daten hoch verfügbar sind und mit hoher Leistung genutzt werden können.
    1. Wir testen die Ausfallsicherheit über mehrere AWS-Verfügbarkeitszonen hinweg, damit die Ausfallzeit bei Ausfällen einzelner Verfügbarkeitszonen minimiert wird.
    2. Wir erstellen Daten-Backups über mehrere regionale AWS-Rechenzentren hinweg. Falls eine Region ausfällt, sind deine Daten für den Katastrophenfall in einer zweiten Region gesichert.
    3. Wir führen Tests für den Fall von AWS-Regionsausfällen durch. Uns ist bewusst, dass der komplette Ausfall einer Region sehr unwahrscheinlich ist. Dennoch testen wir immer wieder unsere Möglichkeiten zum Service-Failover, um unsere regionale Ausfallsicherheit weiter zu stärken.
    4. Wir haben Backup- und Wiederherstellungsverfahren implementiert, die wir regelmäßig testen. Wenn Daten wiederhergestellt werden müssen, verfügen wir also über gut geschulte Supportmitarbeiter und umfassend getestete Verfahren, damit du deinen Betrieb schnell wieder aufnehmen kannst.

Im DR-Programm von Atlassian geht es nicht nur um Ausfallsicherheit durch Governance, Kontrolle und Tests. Vielmehr ist darin auch die kontinuierliche Verbesserung des Programms selbst festgeschrieben. Weitere Informationen zu unseren Disaster-Recovery-Testverfahren und unserem Programm für Geschäftskontinuität findest du auf unserer Seite zur Verwaltung von Kundendaten.

Wir aktualisieren den Verfügbarkeitsstatus unserer Services in Echtzeit, damit du jederzeit auf deine Daten zugreifen kannst.

Produktsicherheit

In unserer Branche herrscht ein hoher Innovationsdruck. Das heißt, wir müssen Produkte schnell auf den Markt bringen, um erfolgreich zu sein. Dabei dürfen wir aber niemals die Sicherheit aus den Augen verlieren. Unser Ziel ist es, das richtige Verhältnis zwischen Geschwindigkeit und Sicherheit zu finden — schließlich arbeiten wir bei Atlassian fast ausschließlich mit unserer eigenen Software. Um die Sicherheit unserer Produkte und Daten zu gewährleisten, haben wir einige Sicherheitsmaßnahmen implementiert.

Verschlüsselung und Schlüsselmanagement

Verschlüsselung während der Übertragung

Alle Kundendaten, die in Atlassian Cloud-Produkten gespeichert sind, werden bei der Übertragung über öffentliche Netzwerke mithilfe von Transport Layer Security (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.

Verschlüsselung ruhender Daten

Datenlaufwerke auf Servern, auf denen Kundendaten und Anhänge in Jira Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Confluence Cloud, Statuspage, Opsgenie und Trello gespeichert sind, verwenden im Ruhezustand die AES-256-Verschlüsselung nach Branchenstandard. Für Bitbucket wird die Verschlüsselung ruhender Daten für Repositorys derzeit nicht unterstützt.

Im Falle von ruhenden Daten werden vor allem Kundendaten auf Festplatte verschlüsselt, zum Beispiel Jira-Vorgangsdaten (Details, Kommentare, Anhänge) oder Confluence-Seitendaten (Seiteninhalt, Kommentare, Anhänge). Die Verschlüsselung ruhender Daten dient als Schutz vor unberechtigtem Zugriff und sorgt dafür, dass nur autorisierte Rollen und Services mit geprüftem Zugang zu den Verschlüsselungsschlüsseln auf die Daten zugreifen können.

Verwaltung der Verschlüsselungsschlüssel

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 bei AWS regelmäßig untersucht und verifiziert. Jedem Schlüssel wird ein Eigentümer zugewiesen, der dafür zuständig ist, dass angemessene Sicherheitsmaßnahmen für die Schlüssel in Kraft sind.

Mandantenisolierung

Durch die Isolierung von Mandanten können unsere Kunden eine gemeinsame IT-Infrastruktur nutzen, sind aber gleichzeitig logisch voneinander getrennt, sodass die Aktionen eines Mandanten keine Auswirkungen auf die Daten oder den Service der anderen haben.

Je nach Anwendung ist die Mandantenisolierung bei Atlassian unterschiedlich gelöst, wobei wir versuchen, die Ansätze mit der Zeit zu vereinheitlichen. Für Jira und Confluence Cloud, die sich über die Jahre zu ausgewachsenen mandantenfähigen SaaS-Anwendungen entwickelt haben, setzt Atlassian auf ein Konzept, das wir als Tenant Context (Mandantenkontext) bezeichnen. Umgesetzt ist es sowohl im Anwendungscode als auch in Form des "Tenant Context Service" (TCS). Diese Herangehensweise sorgt in der gemeinsamen Umgebung für Folgendes:

  • 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.

Der TCS ist unabhängig von Jira und Confluence, jedoch unverzichtbar für deren Funktionsweise. Vereinfacht gesagt speichert der TCS für die einzelnen Mandanten der Kunden einen "Kontext". Dieser besteht aus einer Reihe von mandantenspezifischen Metadaten (z. B. welche Datenbanken der Mandant nutzt, welche Lizenzen der Mandant besitzt, auf welche Funktionen er Zugriff hat sowie verschiedene andere Konfigurationsinformationen) und eindeutigen verschlüsselten Anmeldeinformationen. Dem Kontext eines Mandanten ist eine eindeutige ID zugeordnet, die vom TCS zentral gespeichert wird.

Wenn ein Kunde auf Jira 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 zur Atlassian Cloud-Architektur.

Produktsicherheitstests

Wir loben Bug Bountys sowohl in internen als auch in externen Sicherheitstestprogrammen aus

Das Schwachstellenmanagement für unsere Produkte umfasst interne und externe Sicherheitstests. Bekannte Probleme werden in unserem öffentlichen Bug-Tracker bekannt gegeben.

Interne Tests

Dieser Prozess betrifft die Planungs-, Entwicklungs- und Testphase. Die Tests bauen aufeinander auf und werden immer anspruchsvoller. Sowohl in der Entwicklungs- als auch in der Testphase führen wir statische und dynamische Codeanalysen durch. In der Entwicklungsphase beschränken wir uns auf die Integration von Codescans, um alle funktionalen und sofort erkennbaren, nicht funktionalen Sicherheitsprobleme auszuräumen.

In der Testphase schalten unsere Entwicklungs- und Sicherheitstechnikteams auf einen antagonistischen Ansatz um und versuchen, mithilfe automatisierter und manueller Testmethoden Fehler in Funktionen hervorzurufen.

Unser Sicherheitstechnikteam hat eine ganze Reihe von Sicherheitstesttools zur Automatisierung häufiger Aufgaben entwickelt und versorgt unsere Produktteams mit spezialisierten Testtools. Diese Tools unterstützen das Sicherheitsteam und ermöglichen es den Entwicklern, auf eigene Faust Sicherheitsprüfungen durchzuführen und die Zuständigkeit für die Ergebnisse zu übernehmen. Die Mitglieder unseres Sicherheitstechnikteams sind allesamt Experten auf ihrem Gebiet, aber letztlich ist jeder Entwickler in unserem Unternehmen für seinen Code selbst verantwortlich.

Externe Tests

Externe Tests erfolgen erst dann, wenn ein Release in die Produktionsphase eintritt. Diese Vorgehensweise beruht auf dem Konzept der "kontinuierlichen Sicherheit". Statt punktueller Penetrationstests nutzen wir ein durchgehend aktives Modell für Tests, das in Form eines öffentlichen Bug-Bounty-Programms mit Crowdsourcing umgesetzt wird.

Wenn ein Benutzer im Rahmen der normalen Verwendung eines unserer Produkte eine Schwachstelle erkennt, begrüßen wir jede Benachrichtigung und reagieren zeitnah auf alle gemeldeten Schwachstellen (wie in unserem Schwachstelleninformationsbericht dargelegt). Wir halten den Einsender auf dem Laufenden, während wir das Problem untersuchen und bearbeiten.

Bei Produkten und Infrastrukturen mit hohem Risiko beauftragen wir Sicherheitsberatungsunternehmen mit Penetrationstests. Dies kann beispielsweise bei einer neuen Infrastrukturarchitektur (z. B. unserer Cloud-Umgebung), einem neuen Produkt oder einer grundlegenden Umgestaltung der Architektur (z. B. zur verstärkten Nutzung von Microservices) der Fall sein.

Unser Ansatz für Penetrationstests ist sehr zielgerichtet und fokussiert. Im Allgemeinen werden Tests folgender Art durchgeführt:

White-Box-Tests: Die Tester erhalten zur Unterstützung ihrer Tests Designdokumente und Briefings von unseren Produktentwicklern.
Tests mit Code-Unterstützung: Die Tester erhalten umfassenden Zugriff auf die relevante Codebasis, damit sie unerwartetes Systemverhalten bei den Tests besser diagnostizieren und potenzielle Ziele leichter ermitteln können.
Bedrohungsbasierte Tests: Bei den Tests liegt der Fokus auf einem bestimmten Bedrohungsszenario, beispielsweise einer infizierten Instanz, bei der dann die laterale Verbreitung von diesem Ausgangspunkt aus getestet wird.

Die Berichte zu diesen Tests veröffentlichen wir weder ganz noch auszugsweise, weil wir den Testern für ihre Beurteilungen umfassende Informationen zur Verfügung stellen. Die meisten dieser Systeme und Produkte werden später in unser öffentliches Bug-Bounty-Programm aufgenommen. So erhalten Kunden die gewünschte externe Bestätigung der Sicherheit. Weitere Informationen zu unserer Vorgehensweise beim Validieren von Produktsicherheitstests findest du auf der Seite zu unserem Ansatz für externe Sicherheitstests.

Produktschwachstellenmanagement

Wir gehen bei der Entwicklung hochwertiger Software neue Wege

Um neue Funktionen möglichst schnell und sicher bereitzustellen, gehen wir über die herkömmliche Qualitätssicherung (Quality Assurance, QA) hinaus und verfolgen einen Ansatz, den wir Quality Assistance* nennen. Dieser ist ganzheitlich und bindet das gesamte Team ein. Bei uns hat die QA eine moderierende Funktion, statt für die eigentliche QA-Umsetzung zuständig zu sein. Gleichzeitig schulen wir unsere Entwickler darin, ihre eigenen Funktionen auf die Einhaltung unserer Qualitätsstandards zu testen.

Wir tun viel dafür, die Anzahl der Schwachstellen in unseren Produkten zu reduzieren. Gleichzeitig wissen wir, dass Schwachstellen bis zu einem gewissen Grad ein unvermeidlicher Bestandteil des Entwicklungsprozesses sind. Durch unsere Bug-Bounty-Partnerschaft versuchen wir, den Zeit- und Ressourcenaufwand für das Aufspüren und Ausnutzen von Schwachstellen für Hacker nach oben zu treiben und Angriffe damit unattraktiv zu machen. Weitere Informationen zu unserer Vorgehensweise beim Produktschwachstellenmanagement findest du auf der Seite zu unserem Ansatz für externe Sicherheitstests.

* Hinweis: Der Begriff "Quality Assistance" wurde von Cem Kaner geprägt. In unserer Blogpost-Reihe zum Thema QA erfährst du mehr darüber und über unseren allgemeinen Qualitätsprozess.

Betriebliche Verfahren

Sicherheit hat viele Facetten. Sie betrifft nicht nur unsere Produkte, sondern auch sicherheitsbewusste Verhaltensweisen in unserer täglichen Arbeit. Das Konzept der "integrierten Sicherheit" basiert auf derselben Philosophie, die wir bei unseren internen Prozessen verfolgen und die unser geschäftliches Handeln bestimmt.

Zugriff auf Kundendaten

Der Zugriff auf Kundendaten, die in den Anwendungen gespeichert sind, ist auf die Personen beschränkt, die ihn wirklich benötigen

Innerhalb unserer SaaS-Plattform gilt für alle Kundendaten dieselbe Vertraulichkeitsstufe. Der Zugriff auf diese Daten wird streng kontrolliert. Unsere Mitarbeiter und Auftragnehmer nehmen im Rahmen des Onboardings bzw. der Einarbeitung an einer Sensibilisierungsmaßnahme teil und erlernen den sicherheitsbewussten Umgang mit Kundendaten.

Innerhalb unseres Unternehmens haben ausschließlich autorisierte Mitarbeiter von Atlassian Zugriff auf die Kundendaten, die in unseren Anwendungen gespeichert sind. Die Authentifizierung erfolgt über individuelle passwortgeschützte öffentliche Schlüssel. Die Server akzeptieren nur eingehende SSH-Verbindungen von Atlassian und internen Data-Center-Standorten.

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.

Zu den Rechenzentren, in denen die Daten unserer Kunden gehostet werden, hat nur autorisiertes Personal Zutritt. Dies wird durch biometrische Sicherheitsvorkehrungen gewährleistet. Vor Ort sorgen außerdem Wachpersonal, Videoüberwachungsanlagen, Zugangsschleusen und weitere Einbruchsschutzmaßnahmen für Sicherheit.

Eine allgemeiner gefasste Richtlinie bezüglich des Zugriffs auf Kundendaten und Metadaten ist Teil unserer Datenschutzrichtlinie.

Supportzugang

Unsere Supportteams greifen nur dann auf Kundendaten zu, wenn es zur Lösung eines offenen Tickets erforderlich ist

Zur Unterstützung von Wartungs- und Supportprozessen hat unser weltweites Supportteam Zugriff auf unsere Cloud-basierten Systeme und Anwendungen. Der Zugriff auf die gehosteten Anwendungen und Daten ist nur zur Überwachung der Anwendungsfunktionen und zur Durchführung der System- und Anwendungswartung zulässig sowie nach Kundenanfrage über unser Supportsystem.

Schulung und Sensibilisierung

Unser Sicherheitsschulungs- und Sensibilisierungsprogramm besteht nicht nur aus einer Liste mit Compliance-Anforderungen, die wir abhaken, sondern hat Auswirkungen auf das gesamte Unternehmen

Unser Sensibilisierungsprogramm basiert auf der Prämisse, dass Sicherheit in der Verantwortung jedes Einzelnen liegt. Welche Verantwortlichkeiten das sind, ist in unserem internen Sicherheitsrichtlinienprogramm festgelegt. Das Schulungs- und Sensibilisierungsprogramm ist das Instrument, mit dem wir die Verantwortlichkeiten unserem Personal vermitteln.

Bewerber und Auftragnehmer müssen eine Vertraulichkeitserklärung unterzeichnen, bevor sie bei oder mit uns arbeiten können. Während des darauffolgenden Onboarding-Prozesses nehmen die neuen Mitarbeiter an einer Sicherheitssensibilisierungsmaßnahme teil.

Im Einklang mit unserem Motto der "kontinuierlichen Verbesserung" verbreiten wir regelmäßig Sicherheitshinweise in unternehmensweiten E-Mails und in Blogposts. Diese Hinweise nehmen in der Regel auf aktuelle Geschehnisse oder Erkenntnisse Bezug, z. B. auf eine bislang unbekannte öffentlich gemachte Bedrohung. Die Hinweise sollen das Sicherheitsbewusstsein unserer Mitarbeiter weiter schärfen.

Security Champions

Auch außerhalb des Sicherheitsteams gibt es sicherheitsbewusste Mitarbeiter, deren Begeisterung und Fachkenntnis wir uns zunutze machen

Zusätzlich zum Sensibilisierungsprogramm haben wir ein internes "Security Champions"-Programm aufgelegt. Für uns ist es wichtig, Sicherheitsbewusstsein in jedem Team bei Atlassian zu verankern. Außerdem möchten wir Sicherheitsthemen für alle greifbarer und verständlicher machen. Deshalb haben wir uns entschieden, einige unserer Mitarbeiter, sowohl aus dem operativen Geschäft als auch Entwickler, in essenziellen Sicherheitsthemen zu schulen. Diese Experten tragen ihre Begeisterung für das Thema Sicherheit in die Teams, denen sie für einen bestimmten Zeitraum zugeteilt werden, und sind für das restliche Unternehmen unsere Fürsprecher.

Änderungsmanagement

Beim Änderungsmanagement verfolgen wir einen Open-Source-ähnlichen Ansatz

Herkömmliche Änderungsmanagementprozesse basieren auf einer pyramidenähnlichen Änderungskontrollhierarchie. Wenn jemand eine Änderung vornehmen möchte, muss er diese einem Gremium vorlegen, das über die Umsetzung entscheidet. Wir verfolgen einen anderen Ansatz, den wir als "Peer Review, Green Build" bezeichnen. Jede Änderung, ob am Code oder an der Infrastruktur, muss durch mindestens einen Kollegen auf mögliche Probleme untersucht werden. Je wichtiger die Änderung oder das Produkt ist, desto mehr dieser "Peer Reviews" sind erforderlich. Wir vertrauen darauf, dass unsere Entwicklungsteams und Techniker Sicherheits- und Performanceprobleme erkennen und die Änderung vor der Genehmigung und Implementierung melden. Wir verwenden unser selbst entwickeltes Continuous-Integration-Tool Bamboo, um festzustellen, ob die Änderungen Probleme in unseren Integrations-, Komponenten-, Funktions- oder Sicherheitstests verursachen, sobald sie in den Haupt-Branch gemergt werden. Wurden in den Build- und Testphasen keine Probleme identifiziert, signalisiert Bamboo einen grünen Punkt und kennzeichnet den Build-Prozess als erfolgreich. Wenn es Probleme gab, signalisiert Bamboo einen roten Punkt, und der Merge wird abermals überprüft, um herauszufinden, welche Änderungen die Probleme verursacht haben. Unser "Peer Review, Green Build"-Prozess ist eine wichtige Stütze, um die Tausenden Änderungen zu identifizieren, die wir jede Woche vornehmen.

Einstellung neuer Mitarbeiter

Wir möchten die besten Talente für uns gewinnen

Wie jedes andere Unternehmen auch sind wir daran interessiert, die besten und klügsten Köpfe einzustellen. Neue Mitarbeiter werden in unseren wöchentlichen Global Town Hall-Meetings begrüßt und dazu motiviert, "die beste Arbeit ihres Lebens abzuliefern" und "alles daran zu setzen, Atlassian noch besser zu machen". Unser Unternehmen soll an den einzigartigen Fähigkeiten unserer Mitarbeiter wachsen und jeden Tag und jede Woche davon profitieren. Unser Recruiting-Prozess umfasst Beschäftigungs-, Visa-, Hintergrund- und Finanzchecks. Jeder neu eingestellte Mitarbeiter durchläuft einen 90-tägigen Onboarding-Prozess und erhält Zugang zu fortlaufenden funktionsspezifischen Schulungen.

Customer Exit Procedure

Endet ein Vertrag über unsere Cloud-Produkte zwischen Atlassian und einem Kunden, werden die Kundendaten gemäß den nachfolgend genannten Fristen aus unserer Cloud-Umgebung gelöscht.

Ein Kundenvertrag kann aus folgenden Gründen enden:

  • Zahlungsverzug: Ein Kunde gerät mit seinem Produktabonnement in Zahlungsverzug (monatliche oder jährliche Zahlungsweise).
  • Kündigung des Abonnements: Ein Kunde kündigt sein Abonnement.
  • Ende des Testzeitraums: Der Testzeitraum für eines unserer Produkte endet, und der Kunde entscheidet sich gegen ein bezahltes Abonnement.

Zahlungsverzug

Gerät ein Kunde mit seinen Zahlungen für ein Abonnement in Verzug oder ist eine Zahlung nicht möglich, endet sein Abonnement für alle betroffenen Produkte 15 Tage nach Zahlungsfälligkeit. Alle Kundendaten verbleiben danach für die Dauer von 60 Tagen in einer "kalten" Sicherung (Cold Backup). Danach werden die Daten gelöscht. Kunden können verhindern, dass ihre Daten gelöscht werden, indem sie den offenen Betrag innerhalb der 15-Tage-Frist begleichen. Nach Ablauf des genannten Zeitraums können die Kundendaten nicht wiederhergestellt werden, selbst wenn eine Zahlung erfolgt ist.

Kündigung des Abonnements

Kündigt ein Kunde sein Abonnement absichtlich, werden die Kundendaten 60 Tage nach Ablauf des aktuellen Abonnementzeitraums gelöscht (gebührenpflichtige Sites).

Für Jira gilt: Wenn ein Kunde ein Jira-Produkt kündigt (z. B. Jira Software) und ein anderes (z. B. Jira Service Desk) beibehält, werden die Jira-Daten nicht gelöscht. Das betrifft auch Testversionen. Wenn der Testzeitraum eines Jira-Produkts endet und der Kunde noch andere Jira-Produkte abonniert hat, bleiben die Jira-Daten erhalten. Die Jira-Daten werden jedoch sofort gelöscht, wenn alle Jira-Produkte gekündigt werden.

Dasselbe gilt, wenn ein Kunde Confluence aus seinem Atlassian-Produktabonnement entfernt. Alle Confluence-Daten werden sofort gelöscht, und der Zugang zu Confluence wird für alle Benutzer gesperrt.

Ende des Testzeitraums

Entscheidet sich ein Kunde nach Ablauf des Testzeitraums gegen ein bezahltes Abonnement, werden alle Kundendaten 15 Tage danach gelöscht (bei Testversionen).

Einmal gelöschte Daten können in keinem der genannten Fälle wiederhergestellt werden.

Datenlöschung

Deine Daten werden 15 Tage (bei Evaluierungssites) bzw. 60 Tage (bei bezahlten Abonnementsites) nach Ablauf des Abonnements aufgrund eines Zahlungsverzugs für ein Atlassian-Produkt bzw. nach Kündigung deines Abonnements gelöscht.

Was geschieht, wenn ich in Zahlungsverzug gerate oder ein einzelnes Produktabonnement kündige?

Wenn du für ein Atlassian-Produktabonnement in Zahlungsverzug gerätst, werden alle abonnierten Produkte 15 Tage nach Zahlungsfälligkeit gekündigt. Ab diesem Zeitpunkt hat keiner deiner Benutzer mehr Zugriff auf das Produkt.

Durch die Kündigung deines Atlassian-Produktabonnements werden keine weiteren Site-Verlängerungen verarbeitet. Deine Site bleibt bis 15 Tage nach Ende des laufenden Abonnementzeitraums erreichbar und wird danach deaktiviert.

Datenaufbewahrung

Deine Site wird 15 Tage nach Ende des laufenden Abonnementzeitraums deaktiviert. Atlassian bewahrt die Daten deaktivierter Sites für die Dauer von 15 Tagen (bei Testversionen) bzw. 60 Tagen (bei gebührenpflichtigen Abonnementsites) nach Ende des laufenden Abonnementzeitraums auf.

Der Testzeitraum für Einzelprodukte im Rahmen eines Jahresabonnements für ein Atlassian-Produkt beträgt 30 Tage. Wenn wir keine Zahlung erhalten, wird dein Abonnement von Jira- und Confluence-Produkten 17 Tage nach dem Zahlungstermin beendet. Danach haben Benutzer keinen Zugriff mehr auf Jira und Confluence.

Confluence-Daten werden 15 Tage nach Ende des Produktabonnements gelöscht. Wenn dein Testzeitraum für ein Jira-Produkt (z. B. Jira Service Desk) endet, dein Jahresabonnement aber noch andere Jira-Produkte (z. B. Jira Software) umfasst, werden deine Jira-Daten nicht gelöscht. Die Jira-Daten werden nur gelöscht, wenn du alle Jira-Produkte kündigst.

Deine Daten können nach der Löschung nicht wiederhergestellt werden. Du solltest daher wie unten beschrieben ein Backup deiner Confluence- bzw. Jira-Site anlegen.

Wie kann ich meine Daten für den Umzug auf eine andere Site vorbereiten?

Sicherheitsprozesse

Wir sind uns bewusst, dass es immer einen Fehlerspielraum gibt. Wir möchten Sicherheitsprobleme frühzeitig aufspüren und erkannte Defizite so schnell wie möglich ausräumen, um den Schaden zu begrenzen.

Management von Sicherheitsvorfällen

Vorfälle sind unausweichlich, aber wenn wir schnell und effizient reagieren, halten wir die Auswirkungen so gering wie möglich

Das Sicherheitsteam bei Atlassian sammelt Protokolle aus verschiedenen Quellen innerhalb der Hosting-Infrastruktur und nutzt eine SIEM-Plattform zur Überwachung und Meldung verdächtiger Aktivitäten. Wie diese Meldungen selektiert, weiter untersucht und eskaliert werden, ist in unseren internen Prozessen geregelt. Unsere Kunden und die Community im Allgemeinen sind dazu angehalten, vermutete Sicherheitsvorfälle dem Atlassian-Support zu melden.

Sollte es zu einem schwerwiegenden Sicherheitsvorfall kommen, kann Atlassian intern auf Experten zurückgreifen und externe Sicherheitsspezialisten hinzuholen, um die Vorfälle zu untersuchen und bis zur endgültigen Lösung zu verfolgen. Die Datenbank unserer Sicherheitsvorfälle ist gemäß dem VERIS Framework katalogisiert.

Wenn Interesse besteht, kannst du dich gerne über unseren Prozess für das Management von Sicherheitsvorfällen und unsere gemeinsame Verantwortung während eines Sicherheitsvorfalls informieren.

Schwachstellenmanagement

In unserem umfangreichen Schwachstellenmanagement-Programm ist geregelt, dass wir aktiv nach Schwachstellen in unserer Umgebung suchen

Zusätzlich zu unseren produktspezifischen Schwachstellenmanagementverfahren (wie bereits vorgestellt) nutzt unser Sicherheitsteam einen branchenführenden Schwachstellenscanner, um unsere interne und externe Infrastruktur laufend auf Netzwerkschwachstellen zu überprüfen. Weitere Informationen dazu findest du in unseren FAQ zum Vertrauen.

Bei Produkten und Infrastrukturen mit hohem Risiko beauftragen wir durchaus Sicherheitsberatungsunternehmen mit Penetrationstests.Dies kann beispielsweise bei einer für uns eingerichteten neuen Infrastruktur (z. B. unserer Cloud-Umgebung), einem neuen Produkt (z. B. Stride) oder einer grundlegenden Umgestaltung der Architektur (z. B. zur verstärkten Nutzung von Microservices) der Fall sein.

Wir haben interne Prozesse zur Überprüfung und Bearbeitung gemeldeter Schwachstellen implementiert. Diese beinhalten vordefinierte SLAs für das Patchen von Schwachstellen abhängig vom CVSS-Schweregrad. Mehr dazu findest du in unserer Richtlinie zur Behebung von Sicherheits-Bugs.

Weitere Informationen zu unseren Sicherheitstestverfahren findest du hier: Unser Ansatz für externe Sicherheitstests.

Weitere Informationen zu unserem Schwachstellenmanagement-Programm findest du unter Schwachstellenmanagement von Atlassian.

Bug-Bounty-Programm

Mit unserem Bug-Bounty-Programm stellen wir sicher, dass unsere Systeme laufend getestet werden

Das Herz unseres Sicherheits-Bug-Managements ist unser Bug-Bounty-Programm, das gewährleistet, dass unsere Produkte kontinuierlich auf Sicherheitsschwachstellen getestet werden. In einer äußerst agilen Entwicklungsumgebung mit häufigen Releases sind kontinuierliche Tests unverzichtbar. Wir sind davon überzeugt, dass die Beteiligung unabhängiger Sicherheitsforscher an unserem Bug-Bounty-Programm den effektivsten Prozess für externe Sicherheitstests darstellt.

Unser Bug-Bounty-Programm, für das sich über 500 Tester registriert haben, deckt mehr als 25 unserer Produkte und Umgebungen ab – von unseren Server-Produkten über mobile Apps bis hin zu Cloud-Produkten. Details zur Anzahl der gemeldeten Sicherheitslücken, unserer durchschnittlichen Reaktionszeit und der durchschnittlichen Prämienhöhe sind in unserem Bug-Bounty-Programm zu finden.

Weitere Informationen zu unseren Sicherheitstestverfahren findest du hier: Unser Ansatz für externe Sicherheitstests.

Download der aktuellen Testberichte

Alle Sicherheitslücken in den unten aufgeführten Berichten werden von uns intern über Jira verfolgt, so wie sie über das Bug-Bounty-Programm hereinkommen, und gemäß dem in unserer Richtlinie für die Behebung von Sicherheits-Bugs angegebenen SLA-Zeitplan wieder geschlossen.

Compliance

Unser Sicherheitsprogramm orientiert sich an einigen weit verbreiteten Industriestandards. Wir halten diese Zertifizierungen für unerlässlich, da sie unseren Kunden einen unabhängigen Nachweis liefern, dass wir das Thema Sicherheit ernst nehmen. Hier erfährst du mehr über unser Sicherheitsmanagementprogramm.

Derzeit sind wir nach SOC 2, ISO 27001, PCI DSS und CSA STAR zertifiziert. Nähere Informationen zu diesen Programmen findest du auf unserer Seite zur Compliance.

Standard

Sponsor

Status

ISO 27001

Internationale Organisation für Normung (International Organization for Standardisation, ISO)

Atlassian ist gemäß ISO 27001 akkreditiert. Der Umfang der Betriebsabläufe wird in unserem Akkreditierungszertifikat benannt. Die Kurzversion: Unser Sicherheitsteam ist derzeit für die Bereiche Sicherheitstechnik, Security Intelligence und Sicherheitsprojekte zertifiziert. Der Umfang der Akkreditierung wird momentan im gesamten Unternehmen ausgeweitet.

ISO/IEC 27001 nutzt zudem die in ISO/IEC 27002 beschriebenen umfassenden Sicherheitskontrollen. Grundlage dieser Zertifizierung ist die Entwicklung und Implementierung eines rigorosen Sicherheitsmanagementprogramms einschließlich der Entwicklung und Implementierung eines Managementsystems für Informationssicherheit (Information Security Management System, ISMS). Diese weithin anerkannte internationale Sicherheitsnorm erwartet von Unternehmen, die eine Zertifizierung anstreben, u. a. die Umsetzung der folgenden Punkte:

  • Systematische Bewertung unserer IT-Sicherheitsrisiken unter Berücksichtigung der Auswirkungen von Bedrohungen und Schwachstellen
  • Entwurf und Umsetzung einer umfassenden Palette an Informationssicherheitskontrollen zur Bewältigung von Sicherheitsrisiken
  • Einführung eines allumfassenden Audit- und Compliance-Managementprozesses zur Gewährleistung der durchgängigen Erfüllung der Vorgaben unserer Sicherheitskontrollen

Sieh dir das ISO/IEC 27001-Zertifikat von Atlassian an.

ISO 27018

Internationale Organisation für Normung (International Organization for Standardisation, ISO)

Atlassian erweitert derzeit seine Kontrollen für Sicherheit und Datenschutz im gesamten Unternehmen, um im Rahmen seines DSGVO-Compliance-Programms die Anforderungen aus ISO 27018 zu erfüllen.

Die Norm ISO/IEC 27018 ist ein Verhaltenskodex für den Schutz persönlicher Daten in der Cloud. Sie basiert auf dem Informationssicherheitsstandard ISO 27002 und dient als Leitfaden für die Implementierung von ISO 27002-Kontrollen, die für personenbezogene Daten, anhand derer eine Person eindeutig identifiziert werden kann (PII), in der öffentlichen Cloud gelten. Die Norm bietet zusätzliche Kontrollen und Richtlinien für die Schutzanforderungen von personenbezogenen Daten, die von den aktuellen Kontrollen der ISO 27002 nicht berücksichtigt werden.

Sieh dir das ISO/IEC 27018-Zertifikat von Atlassian an.

PCI DSS

Zahlungskartenbranche

Atlassian ist als Händler in Bezug auf Käufe im Zusammenhang mit unseren Produkten PCI DSS-konform. Atlassian-Produkte sind jedoch nicht zur Verarbeitung oder Speicherung von Kreditkartendaten unserer Kunden vorgesehen.

Wenn du Atlassian-Produkte oder -Services mit deiner Kreditkarte bezahlst, kannst du dich darauf verlassen, dass wir der Sicherheit dieser Transaktionen gebührende Aufmerksamkeit schenken. Wir sind ein Level-2-Händler und lassen unsere Compliance mit PCI DSS von einem Qualified Security Assessor (QSA) überprüfen. Derzeit erfüllen wir die Anforderungen von PCI DSS v3.2, SAQ A.

Du kannst unsere PCI Attestation of Compliance (AoC) anzeigen oder herunterladen:

CSA CCM/STAR

Cloud Security Alliance

Ein CSA STAR Level 1 Questionnaire für Atlassian kann auf der Cloud Security Alliance STAR Registry-Website heruntergeladen werden.

CSA Security, Trust & Assurance Registry (STAR) ist ein kostenloses öffentliches Verzeichnis, in dem die Sicherheitskontrollen verschiedener Cloud-Angebote dokumentiert werden, sodass Kunden die Sicherheit von Cloud-Anbietern beurteilen können.Atlassian ist bei CSA STAR registriert, Corporate Member der Cloud Security Alliance (CSA) und hat den Cloud Security Alliance (CSA) Consensus Assessments Initiative Questionnaire (CAIQ) ausgefüllt. Die neueste Version des CAIQ gemäß CSA Cloud Controls Matrix (CCM) v.3.0.1 beantwortet über 300 Fragen, die ein Cloud-Kunde oder Cloud-Sicherheits-Auditor an einen Cloud-Anbieter haben könnte.

Sieh dir die CIAQ-Einträge von Atlassian in der CSA Star Registry an.

SOC 2/SOC 3

Service Organisation Control

Die durch eine Drittpartei zertifizierten SOC-Berichte (Service Organization Control) von Atlassian legen dar, wie Atlassian wichtige Compliance-Kontrollen und -Ziele erreicht. Diese Berichte sollen dir und deinen Auditoren dabei helfen, die zur Unterstützung der Betriebsabläufe und Compliance bei Atlassian eingerichteten Kontrollen zu verstehen.

Atlassian verfügt über SOC 2-Zertifizierungen für viele seiner Produkte. Hier kannst du die SOC 2- und SOC 3-Zertifizierungen von Atlassian herunterladen.

Mindestens einmal jährlich lassen wir zudem von einem renommierten Prüfungsunternehmen umfassende Sicherheitsaudits durchführen.

Die Ergebnisse der Audit- und Zertifizierungsprogramme fließen zusammen mit Erkenntnissen aus unseren internen Prozessen, z. B. aus dem Schwachstellenmanagement, in die kontinuierliche Verbesserung unseres Sicherheitsprogramms ein.

Konformität mit der DSGVO

Wir setzen uns intensiv für den Erfolg unserer Kunden und den Schutz von Kundendaten ein. Wir tun dies einerseits, indem wir Atlassian-Kunden und Benutzern dabei helfen zu verstehen, wie sie die Datenschutz-Grundverordnung (DSGVO), sofern erforderlich, einhalten. Die DSGVO gilt als die bedeutendste Änderung der europäischen Datenschutzgesetze in den letzten 20 Jahren. Sie ist seit dem 25. Mai 2018 in Kraft.

Uns ist bewusst, dass unsere Kunden Anforderungen der DSGVO erfüllen müssen, die durch ihre Nutzung von Atlassian-Produkten und -Services direkt beeinflusst werden. Deshalb betreiben wir erheblichen Aufwand, Kunden bei der Erfüllung DSGVO-relevanter Anforderungen und lokaler Gesetze zu unterstützen.

Nachfolgend werden einige unserer DSGVO-Initiativen für unsere Cloud-Produkte beschrieben:

  • Wir haben umfassend in unsere Sicherheitsinfrastruktur und unsere Zertifizierungen investiert (siehe Abschnitt zu Sicherheit und Zertifizierungen).
  • Wir unterstützen angemessene Mechanismen für länderübergreifende Datenübertragungen, indem wir unsere Privacy Shield-Zertifizierungen aufrechterhalten und Standardvertragsklauseln im Rahmen unseres aktualisierten Zusatzes zur Datenverarbeitung festlegen.
  • Wir bieten Tools für Datenportabilität und Datenmanagement. Hierzu zählen:
  • Wir sorgen dafür, dass Atlassian-Mitarbeiter, die auf personenbezogene Daten von Atlassian-Kunden zugreifen und diese verarbeiten, im Umgang mit Daten und im Aufrechterhalten der Sicherheit und Vertraulichkeit von Daten geschult sind.
  • Unsere Anbieter, die personenbezogene Daten verarbeiten, müssen dieselben Praktiken und Standards für Datenmanagement, Sicherheit und Datenschutz nutzen wie wir.
  • Wir haben uns selbst zu Datenfolgenabschätzungen verpflichtet und halten im Bedarfsfall Rücksprache mit den zuständigen EU-Aufsichtsbehörden.

Auf der Seite DSGVO-Compliance bei Atlassian erfährst du mehr über unseren DSGVO-Ansatz und unsere Bemühungen zur Umsetzung der Verordnung.

Datenschutz

Wir nehmen die Datenschutzbedenken unserer Kunden ernst und können sie gut nachvollziehen, weil wir dieselben Bedenken haben, wenn es um die Nutzung SaaS-basierter Anwendungen geht. Deshalb behandeln wir personenbezogene und andere vertrauliche Daten genau so wie wir es von unseren eigenen Serviceanbietern erwarten.

Atlassian und seine Tochtergesellschaften halten sich an das EU-U.S. Privacy Shield Framework (EU-US-Datenschutzschild) und die zugehörigen Prinzipien zur Erfassung, Nutzung und Aufbewahrung von aus der Europäischen Union in die USA übertragenen personenbezogenen Daten.

Eine ausführliche Beschreibung unserer Datenschutzpraktiken kannst du unserer Datenschutzrichtlinie entnehmen.

Anfragen von Strafverfolgungsbehörden

Atlassian veröffentlicht einen jährlichen Transparenzbericht, in dem Behördenanfragen bezüglich des Zugriffs auf Benutzerdaten, der Löschung von Inhalten oder der Sperrung von Benutzerkonten festgehalten sind.

Gemeinsame Verantwortung

In der Cloud lässt sich die Sicherheit deiner Daten auf unseren Systemen nur gemeinsam bewerkstelligen. Auf dieses Modell der gemeinsamen Verantwortung gehen wir in unserem erst kürzlich veröffentlichten Whitepaper "The Atlassian Cloud Security Team (You’re part of it)" (Das Atlassian Cloud-Sicherheitsteam (du gehörst dazu)) näher ein.

Im Allgemeinen ist Atlassian dafür verantwortlich, dass die Anwendungen, die Systeme, auf denen diese ausgeführt werden, und die Umgebungen, in denen die Systeme gehostet werden, sicher sind. Wir sorgen dafür, dass diese Systeme und Umgebungen die relevanten Standards einhalten, zum Beispiel PCI DSS und SOC 2.

Unsere Kunden wiederum sind für die Informationen in ihren Konten zuständig. Du verwaltest deine Konten, die Benutzer, die darauf Zugriff haben, und die dafür verwendeten Anmeldeinformationen. Du entscheidest auch, welche Apps du als vertrauenswürdig erachtest und installierst. Du bist dafür zuständig sicherzustellen, dass dein Unternehmen seinen Compliance-Pflichten im Rahmen der Verwendung unserer Systeme nachkommt.

Verantwortungsstruktur

Hier einige Dinge, die unsere Kunden bedenken sollten:

Wichtige Entscheidungen

Die Entscheidungen, die du beim Einrichten unserer Produkte triffst, haben maßgeblichen Einfluss auf die Implementierung von Sicherheitsmaßnahmen. Am wichtigsten sind folgende Entscheidungen:

  • Alle Produkte – Domain-Bestätigung und zentrale Verwaltung: Du kannst eine oder mehrere Domains verifizieren, um nachzuweisen, dass du bzw. dein Unternehmen diese Domains besitzt. Über die Domain-Bestätigung kann dein Unternehmen die Atlassian-Konten aller Mitarbeiter zentral verwalten und Authentifizierungsrichtlinien (u. a. Passwortanforderungen und SAML) anwenden. Sobald deine Domain bestätigt wurde, erhalten alle Benutzer mit bestehenden Atlassian-Konten in dieser Domain eine E-Mail, in der erklärt wird, dass eine Umstellung auf ein verwaltetes Konto erfolgt. Benutzer, die in dieser Domain ein neues Atlassian-Konto erstellen, werden ebenfalls darüber informiert, dass sie ein verwaltetes Konto erhalten.
  • Bitbucket – öffentliche und private Repositorys: Du kannst festlegen, ob deine Repositorys öffentlich (d. h. für alle Internetbenutzer einsehbar) oder privat (d. h. nur für Benutzer mit entsprechenden Berechtigungen zugänglich) sein sollen.
  • Trello – öffentliche und private Teams und Boards: In Trello kannst du Sichtbarkeitseinstellungen für Boards festlegen. Du hast auch die Möglichkeit, Boards öffentlich zu machen (allerdings gelten einige Einschränkungen, wenn dein Trello-Konto ein verwaltetes Konto ist). Wenn ein Board öffentlich ist, kann es von jedem Internetbenutzer angezeigt werden, und es erscheint möglicherweise in den Ergebnissen von Suchmaschinen wie Google. Weitere Informationen über die Sichtbarkeitseinstellungen für Trello-Boards findest du hier. Du kannst auch dein Team öffentlich machen, sodass jeder Internetbenutzer das Teamprofil anzeigen kann. Weitere Informationen über die Sichtbarkeitseinstellungen für Trello-Teams findest du hier.
  • Alle Produkte – Zugriffsberechtigungen: Unsere Produkte sind auf Zusammenarbeit ausgelegt. Dafür sind Zugriffsberechtigungen erforderlich. Du solltest jedoch mit Bedacht vorgehen, wenn du anderen Benutzern und Apps Berechtigungen zum Zugriff auf deine Daten gewährst. Wenn die Berechtigungen einmal erteilt wurden, können wir nicht verhindern, dass die entsprechenden Benutzer die im Rahmen dieser Berechtigungen möglichen Aktionen durchführen – auch wenn du nicht damit einverstanden bist.

Benutzerzugriff

Wie es bei SaaS-Lösungen üblich ist, sind unsere Kunden für den angemessenen Zugriff der Benutzer auf ihre Daten verantwortlich. In diesem Kontext ist es besonders wichtig, die Klassifizierung der in das System gelangenden Daten zu verstehen und sicherzustellen, dass die Benutzer mit Zugriff auf das System dazu autorisiert sind, auf diese Daten zuzugreifen.

Wo erforderlich, vereinfacht eine rollenbasierte Authentifizierung die Durchsetzung von Zugriffsbeschränkungen, die möglicherweise nötig sind, um die Anforderungen hinsichtlich der Datenklassifizierung und Datenverarbeitung zu erfüllen.

Benutzer sollten dazu angehalten werden, sorgfältig mit Passwörtern umzugehen, damit Risiken wie erratene Passwörter und die Verwendung geleakter Anmeldedaten durch Angreifer verringert werden.

Ökosystem

Das Atlassian-Ökosystem besteht aus dem Serviceanbieter Atlassian, den Kunden, ihren Benutzern und dem Marketplace. Unsere Kunden haben die vollständige Kontrolle darüber, welche Apps sie installieren. Bei der Installation kann der Installierende (normalerweise ein Benutzeradministrator) die erteilten Berechtigungen der Apps überprüfen. Die Kundenadministratoren müssen bei der Erteilung dieser Berechtigungen mit Bedacht vorgehen. Wurde eine Berechtigung erst einmal erteilt, haben wir nur wenig Einblick in die Verwendung der Kundendaten durch diese App.

Es wird von Kunden erwartet, dass sie vor einer Installation den Herausgeber der App überprüfen und sich vergewissern, dass die von der App geforderten Berechtigungen angemessen und sinnvoll sind. Nachdem das Add-on installiert wurde, können wir das Ökosystem durch Überwachung der App-Aktivität und die Meldung verdächtiger Aktivitäten schützen.

Möchtest du noch mehr wissen?

Wir haben auf dieser Seite auf einige andere Dokumente und Ressourcen verwiesen, mit denen du dich näher befassen solltest, wenn du mehr über unseren Ansatz für Sicherheit und Vertrauen erfahren möchtest.