ENISA: Europäische Agentur für Netz- und Informationssicherheit

Die Europäische Agentur für Netz- und Informationssicherheit (ENISA) ist ein Zentrum für Netzwerk- und Informationsexpertise. Sie arbeitet eng mit den EU-Mitgliedstaaten und dem privaten Sektor zusammen, um Leitlinien und Empfehlungen zu effektiven Cybersicherheitsmaßnahmen zu erarbeiten. Die ENISA unterstützt auch die Entwicklung und Umsetzung von EU-Richtlinien und -Gesetzen im Zusammenhang mit der nationalen Informationssicherheit.

Das ENISA Cloud Computing Information Assurance Framework (IAF) umfasst eine Reihe von Kriterien für Zusicherungen, anhand derer Unternehmen feststellen können, ob Cloud Service Provider (CSPs) ausreichende Sicherheitsmaßnahmen für Kundendaten bereitstellen. Das IAF soll das Risiko der Cloud-Einführung bewerten und den mit Zusicherungen verbundenen Aufwand für CSPs verringern.

Atlassian erzielt Compliance mit dem IAF durch die Zertifizierung nach ISO 27001 und durch die Nutzung der Cloud Control Matrix (CCM) der Cloud Security Alliance (CSA). Dabei werden CCM-Domains und -Kontrollen mit den IAF-Prüfkriterien abgeglichen.

Atlassian bietet die folgenden auf der CCM basierenden Zusicherungen:

• CSA Star 1 Selbstbeurteilung

Im Folgenden werden die Zusicherungskriterien beschrieben, um Unternehmen bei der Auswahl eines Cloud Service Providers zu unterstützen. Wenn du Fragen zu bestimmten Details hast, kontaktiere bitte unser Enterprise Sales Team unter https://www.atlassian.com/enterprise/contact?formType=product-features.

6.01

Die meisten Fragen zum Personal gleichen Fragen, die du deinen eigenen IT-Mitarbeitern oder anderen mit deiner IT betrauten Mitarbeitern stellen würdest. Wie bei den meisten Bewertungen müssen Risiken und Kosten abgewägt werden.

6.01. (a)

Welche Richtlinien und Verfahren kommen zum Einsatz, wenn dein Unternehmen IT-Administratoren oder andere Personen mit Systemzugriff einstellt? Empfehlenswert sind zum Beispiel:

• Prüfungen vor der Einstellung (Identität, Nationalität oder Status, beruflicher Werdegang und Referenzen, strafrechtliche Verurteilungen und genaue Hintergrundüberprüfungen (für leitende Mitarbeiter)).

Neue Atlassian-Mitarbeiter werden einer Hintergrundüberprüfung unterzogen (je nach Gesetzeslage an ihrem Standort). Infolge einer Übernahme neu eingestellten Mitarbeiter werden nach dem Datum der Übernahme einer Hintergrundüberprüfung unterzogen (je nach Gesetzeslage an ihrem Standort). Bei allen neuen Mitarbeitern und unabhängigen Auftragnehmern wird eine Prüfung auf Vorstrafen durchgeführt. Eine Überprüfung der Ausbildung, der bisherigen Beschäftigung oder Bonitätsprüfungen erfolgt zusätzlich, wenn die Position oder das Niveau der Position dies erfordern. Wir führen vollständige Hintergrundüberprüfungen für Führungspositionen und Buchhaltungspositionen durch.

6.01. (b)

Sind unterschiedliche Richtlinien vorhanden, je nachdem, wo die Daten gespeichert oder wo Anwendungen ausgeführt werden?

• Zum Beispiel könnten sich Einstellungsrichtlinien je nach Region unterscheiden.
• Die Verfahren sollten in allen Regionen einheitlich sein.
• Es kann sein, dass vertrauliche Daten in einer bestimmten Region von befugtem Personal gespeichert werden.

Atlassian vergibt nur die geringstmöglichen Berechtigungen, die Mitarbeiter benötigen, um zur Ausübung ihrer Tätigkeiten Zugriff auf unsere Systeme, Anwendungen und Infrastruktur zu erhalten. Dieses Prinzip wird durch unser Authentifizierungsverfahren durchgesetzt. Jeglicher Zugriff erfolgt über authentifizierte Sitzungen und basiert auf festgelegten Berechtigungen.

Alle Tier-1-Systeme werden über die zentrale Single-Sign-On (SSO)- und Verzeichnislösung von Atlassian verwaltet. Benutzer erhalten auf der Grundlage dieser Profile angemessene Zugriffsrechte, die über Workflow aus unserem Personalverwaltungssystem gesteuert werden. Atlassian nutzt MFA für den Zugriff auf alle Tier-1-Systeme. Wir haben die Zwei-Faktor-Authentifizierung für die Hypervisor-Managementkonsole und die AWS-API sowie einen täglichen Auditbericht über den gesamten Zugriff auf die Hypervisor-Verwaltungsfunktionen aktiviert. Die Zugriffslisten für die Hypervisor-Managementkonsole und die AWS-API werden vierteljährlich überprüft. Wir führen außerdem eine 8-stündige Synchronisation zwischen unserem HR-System und unserem Identitätsspeicher durch.

Im Allgemeinen werden Kontrollen in Zusammenhang mit der Zugriffskontrolle in der Richtlinie zum Zugriffsmanagement behandelt, die du hier in Auszügen abrufen kannst: https://www.atlassian.com/trust

6.01. (c)

Welche Sicherheitsschulungen müssen alle Mitarbeiter absolvieren?

Atlassian bietet Schulungen zur Informationssicherheit als Bestandteil des Onboarding-Trainings ("Tag 1") für neue Mitarbeiter und fortlaufend für alle Mitarbeiter an.

Zusätzlich zu diesen allgemeinen Schulungen zur Informationssicherheit werden für unsere Entwickler gezieltere Schulungen zum Thema sicheres Programmieren angeboten, die durch unser Programm für dedizierte Sicherheitstechniker unterstützt werden.

Wir bieten auch fortlaufende themenbezogene Schulungen zu Malware, Phishing und anderen sicherheitsrelevanten Aspekten an. Weitere Informationen findest du unter: https://www.atlassian.com/trust/security/security-practices#security-awareness-training

Wir führen offizielle Aufzeichnungen über den Abschluss der internen Mitarbeiterschulung. Die Mitarbeiter sind verpflichtet, den Verhaltenskodex anzuerkennen und ihm jährlich erneut zuzustimmen. Diese Richtlinie gilt für alle Mitarbeiter. Die Anforderungen an Sicherheitsbewusstsein, Vertraulichkeit und Datenschutz werden Mitarbeitern von Anfang an vermittelt und stehen allen Mitarbeitern in Confluence zur Verfügung.

6.01. (d)

Ist ein Prozess für kontinuierliche Bewertungen vorhanden?

• Wie oft wird geprüft?
• Weiterführende Gespräche.
• Zugriffs- und Berechtigungsüberprüfungen.
• Richtlinien- und Verfahrensüberprüfungen.

Atlassian hat die SOC2-, ISO27001- und ISO27018-Zertifizierungen für unsere Cloud-Services erhalten. Wir führen mindestens jährlich interne und externe Audits sowie Bereitschaftsüberprüfungen durch. Zahlreiche Produkte von Atlassian sind ISO-zertifiziert, was regelmäßige Risikobewertungen und Überprüfungen des Umgangs mit Daten erfordert.

Weitere Informationen findest du unter: https://www.atlassian.com/trust/compliance. Wir empfehlen unseren Kunden, regelmäßig die Aktualisierungen unserer Compliance-Zertifizierungen und -Berichte von dieser Website herunterladen und überprüfen.

Atlassian hat ein dokumentiertes Richtlinien-Framework mit unserer Sicherheitsrichtlinie als primärer Richtlinie. Unser Policy Management Program (PMP) umfasst Pflichten in Bezug auf Eigentum, Verfügbarkeit und Überprüfungszyklus und beschreibt unsere allgemeinen Ziele. Unsere Richtlinien werden mindestens einmal jährlich überprüft und von der Geschäftsleitung genehmigt. Weitere Informationen über unser PMP findest du unter: https://www.atlassian.com/trust/security/security-management-program

Einen schnellen Überblick über unsere übergeordneten Richtlinien findest du unter: https://www.atlassian.com/trust/security/ismp-policies

Alle Systeme und Projekte werden einer Bewertung der Auswirkungen hinsichtlich personenbezogener Daten unterzogen.

Unsere Drittanbietervereinbarungen beinhalten entsprechende Sicherheits- und Datenschutzbestimmungen. Neue Anbieter von Atlassian müssen unseren Datenschutz- und Sicherheitsrichtlinien in unseren Verträgen zustimmen. Unsere Rechts- und Beschaffungsteams überprüfen Verträge, SLAs und interne Anbieterrichtlinien, um die Risiken im Zusammenhang mit Sicherheit, Verfügbarkeit und Vertraulichkeit zu managen. Im Rahmen des Enterprise Risk Management (ERM)-Programms von Atlassian wird eine jährliche Risikobewertung durchgeführt, die die Wahrscheinlichkeit und die Auswirkungen für alle Risikokategorien berücksichtigt und auf das COSO-Risikomodell abgestimmt ist. Bei Bedarf führen wir auch funktionale Risikobewertungen auf der Grundlage des Risikoprofils durch. Die Risikobewertungen werden im Rahmen der Richtlinienverlängerungen und immer dann überprüft, wenn sich die Beziehung zum Lieferanten erheblich ändert.

6.02.

Die folgenden Fragen gelten, wenn der Cloud-Anbieter einige Operationen, die für die Sicherheit des Betriebs von entscheidender Bedeutung sind, an Dritte vergibt (z. B. ein SaaS-Anbieter, der die zugrunde liegende Plattform an einen Drittanbieter auslagert, ein Cloud-Anbieter, der die Sicherheitsservices an einen Anbieter verwalteter Sicherheitsservices auslagert, Verwendung eines externen Anbieters für das Identitätsmanagement von Betriebssystemen usw.). Dazu gehören auch Dritte mit physischem Zugriff oder Remote-Zugriff auf die Infrastruktur des Cloud-Anbieters. Es wird davon ausgegangen, dass dieser gesamte Fragebogen rekursiv auf Cloud-Services von Dritten (oder n-ten) angewendet werden kann.

6.02. (a)

Definiere die Services, die in deiner Lieferkette für die Erbringung von Services ausgelagert oder an Subunternehmer vergeben werden und die für die Sicherheit (einschließlich Verfügbarkeit) deines Betriebs von entscheidender Bedeutung sind.

Atlassian arbeitet mit externen Serviceanbietern zusammen, die Services im Zusammenhang mit Websites, Anwendungsentwicklung, Hosting, Wartung, Backup, Speicherung, virtueller Infrastruktur, Zahlungsverarbeitung, Analyse und anderen Zwecken bereitstellen. Eine Liste der Unterauftragnehmer, die derzeit von Atlassian beauftragt und vom Kunden autorisiert sind, ist unter https://www.atlassian.com/legal/sub-processors zu finden.

6.02. (b)

Beschreibe die Verfahren, mit denen der Zugriff durch Dritte auf deine Infrastruktur sichergestellt wird (physisch und/oder logisch).

• Prüfst du deine Outsourcer und Subunternehmer und wie oft?

Unsere Rechts- und Beschaffungsteams überprüfen Verträge, SLAs und interne Anbieterrichtlinien, um die Risiken im Zusammenhang mit Sicherheit, Verfügbarkeit und Vertraulichkeit zu managen. Bei Bedarf führen wir auch funktionale Risikobewertungen auf der Grundlage des Risikoprofils durch. Die Risikobewertungen werden im Rahmen der Richtlinienverlängerungen und immer dann überprüft, wenn sich die Beziehung zum Lieferanten erheblich ändert. Unsere Richtlinie zum Management von Zulieferer- und Drittanbieterdaten deckt diesen Prozess ab. Einen Auszug daraus findest du hier: https://www.atlassian.com/trust/security/ismp-policies

6.02. (c)

Garantieren deine Outsourcer niedrigere SLA-Bestimmungen als die, die du deinen Kunden anbietest? Wenn nicht, ist bei deinen Lieferanten Redundanz vorhanden?

Je nach Lizenzvereinbarung sollten die Kundenbedingungen für Atlassian Cloud entweder bei der Verlängerung des monatlichen Abonnements oder bei der Verlängerung des Jahresabonnements überprüft werden. Unsere Rechts- und Beschaffungsteams überprüfen Verträge, SLAs und interne Anbieterrichtlinien, um die Risiken im Zusammenhang mit Sicherheit, Verfügbarkeit und Vertraulichkeit zu managen. Im Rahmen des Enterprise Risk Management (ERM)-Programms von Atlassian wird eine jährliche Risikobewertung durchgeführt, die die Wahrscheinlichkeit und die Auswirkungen für alle Risikokategorien berücksichtigt und auf das COSO-Risikomodell abgestimmt ist. Bei Bedarf führen wir auch funktionale Risikobewertungen auf der Grundlage des Risikoprofils durch. Die Risikobewertungen werden im Rahmen der Richtlinienverlängerungen und immer dann überprüft, wenn sich die Beziehung zum Lieferanten erheblich ändert.

6.02. (d)

Welche Maßnahmen werden ergriffen, um sicherzustellen, dass die Serviceniveaus von Drittanbietern eingehalten und aufrechterhalten werden?

Unsere Rechts- und Beschaffungsteams überprüfen Verträge, SLAs und interne Anbieterrichtlinien, um die Risiken im Zusammenhang mit Sicherheit, Verfügbarkeit und Vertraulichkeit zu managen. Bei Bedarf führen wir auch funktionale Risikobewertungen auf der Grundlage des Risikoprofils durch. Die Risikobewertungen werden im Rahmen der Richtlinienverlängerungen und immer dann überprüft, wenn sich die Beziehung zum Lieferanten erheblich ändert. Unsere Richtlinie zum Management von Zulieferer- und Drittanbieterdaten deckt diesen Prozess ab. Einen Auszug daraus findest du hier: https://www.atlassian.com/trust/security/ismp-policies

6.02. (e)

Kann der Cloud-Anbieter bestätigen, dass die Sicherheitsrichtlinien und -kontrollen (vertraglich) auf seine Drittanbieter angewendet werden?

Alle Systeme und Projekte werden einer Bewertung der Auswirkungen hinsichtlich personenbezogener Daten unterzogen. Unsere Drittanbietervereinbarungen von Atlassian beinhalten entsprechende Sicherheits- und Datenschutzbestimmungen. Neue Anbieter von Atlassian müssen unseren Datenschutz- und Sicherheitsrichtlinien in unseren Verträgen zustimmen.

Unsere Rechts- und Beschaffungsteams überprüfen Verträge, SLAs und interne Anbieterrichtlinien, um die Risiken im Zusammenhang mit Sicherheit, Verfügbarkeit und Vertraulichkeit zu managen. Im Rahmen des Enterprise Risk Management (ERM)-Programms von Atlassian wird eine jährliche Risikobewertung durchgeführt, die die Wahrscheinlichkeit und die Auswirkungen für alle Risikokategorien berücksichtigt und auf das COSO-Risikomodell abgestimmt ist. Bei Bedarf führen wir auch funktionale Risikobewertungen auf der Grundlage des Risikoprofils durch. Die Risikobewertungen werden im Rahmen der Richtlinienverlängerungen und immer dann überprüft, wenn sich die Beziehung zum Lieferanten erheblich ändert.

6.03.

Es wird erwartet, dass jede kommerzielle Vereinbarung mit externen Anbietern Service-Levels für alle Netzwerkservices beinhaltet. Zusätzlich zu der definierten Vereinbarung sollte der Endkunde jedoch weiterhin sicherstellen, dass der Anbieter angemessene Kontrollen anwendet, um eine unbefugte Offenlegung zu verhindern.

6.03. (a)

Beschreibe dein Verfahren und deine Richtlinien zur Änderungskontrolle. Dies sollte auch den Prozess beinhalten, der verwendet wird, um Risiken aufgrund von Änderungen neu zu bewerten, und klären, ob die Ergebnisse für Endkunden verfügbar sind.

Atlassian hat ein Enterprise Risk Management (ERM)-Programm, das auf das COSO-Risikomodell und ISO 31000 abgestimmt ist. Das ERM-Programm implementiert ein Risikomanagement-Framework und eine Methodik für Atlassian und führt jährliche Risikobewertungen, regelmäßige spezifische Risikobewertungen einer Produktumgebung und nach Bedarf funktionale Risikobewertungen auf der Grundlage des Risikoprofils durch.

Insbesondere umfasst das Risikomanagement-Framework von Atlassian Standards, Prozesse, Rollen und Verantwortlichkeiten, akzeptable Risikotoleranzen und Richtlinien für die Durchführung von Risikobewertungsaktivitäten. Unsere Risikomanagementprozesse und -praktiken unterstützen die Durchführung unserer Risikobewertungen. Diese können wiederholt werden und sie stellen valide, konsistente und vergleichbare Ergebnisse bereit. Die Risikobewertungen von Atlassian umfassen sowohl die Wahrscheinlichkeit als auch die Auswirkungen für alle Risikokategorien, sowie Angaben zum Umgang mit sämtlichen Risiken im Einklang mit unseren intern festgelegten Richtlinien. Das Risiko- und Compliance-Team kommuniziert in allen Phasen des ERM-Programms mit den relevanten Interessenvertretern und berät sich mit den entsprechenden Fachexperten.

Mitarbeiter mit einer Rolle in den Risikomanagementprozessen von Atlassian sind sich ihrer Verantwortlichkeiten und der Erfüllung ihrer Aufgaben angemessen bewusst und darin geschult. Alle Risiken werden mit unserem eigenen Jira-Tool verfolgt und verwaltet, wobei die Verantwortung für die zugehörigen Lösungspläne und Projekte auf Managementebene liegt. Weitere Informationen findest du unter: https://www.atlassian.com/trust/security/security-management-program oder https://www.atlassian.com/trust/compliance/risk-management-program

Der Prozess für das Änderungsmanagement bei Atlassian unterscheidet sich geringfügig von herkömmlichen Änderungsprozessen. Wir verlassen uns bei allen Änderungen, ob es sich um Code-, Anwendungs- oder Infrastrukturänderungen handelt, auf eine PRGB-Kontrolle (Peer Review and Green Build). Peer Review (Prüfung durch Kollegen) ist in unserem CD-Tool konfiguriert, in dem wichtige Branches so eingerichtet werden müssen, dass sie für jede Pull-Anfrage mehrere Gutachter haben. In der Regel sind das zwei Entwickler und der Teamleiter. Green Build (erfolgreicher Build) bedeutet hier, dass die Integration während der CI-Phase alle Integrations-, Funktions-, Sicherheits- und anderen Tests bestehen muss, die entwickelt wurden. Wenn diese Tests fehlschlagen (Red Build), wird für den Code kein Merge durchgeführt, und er muss erneut überprüft werden, um die Fehler zu beheben. Sobald ein Green Build erfolgreich ist, ist die Binärdatei kryptografisch signiert, und unsere Produktionsumgebung führt nur Binärdateien aus, die mit unserem Schlüssel signiert sind. Unser Testprozess umfasst sowohl automatische als auch manuelle Bewertungskomponenten. Wir schreiben gerne in Blogs über Dinge, die wir besonders gut können. Wir sind überzeugt von unserem Ansatz, "Quality Assistance" (anstelle der traditionellen "Qualitätssicherung") zu nutzen: https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance

6.03. (b)

Definiere die Richtlinie für den Remote-Zugriff.

Die Anforderungen für den Remote-Zugriff sind in der Richtlinie zum Zugriffsmanagement und den zugehörigen Standards definiert. Kundendaten können zu Support- oder Migrationszwecken und mit einem aktiven Kundensupport-Ticket auf die Workstations der Mitarbeiter repliziert werden. Es gibt strenge Firewall-Regeln, die den Zugriff auf die Produktionsumgebung auf unser VPN-Netzwerk und autorisierte Systeme einschränken. Unser VPN-Zugang erfordert eine Multi-Faktor-Authentifizierung.

Alle Geräte (im Besitz von Atlassian oder BYOD), mit denen Atlassian-Mitarbeiter auf Atlassian-Tools zugreifen können, werden mithilfe von MDM-Softwaresicherheitsprofilen und einer Überprüfung des Sicherheitsstatus beim Gerätemanagement registriert. Atlassian verwendet ein Zero-Trust-Sicherheitsmodell für alle Atlassian-Geräte. Weitere Informationen findest du hier: https://www.atlassian.com/trust/compliance/resources/eba/eba-guidance

6.03. (c)

Unterhält der Anbieter dokumentierte Betriebsverfahren für Informationssysteme?

Zu den Grundprinzipien der Betriebssicherheit von Atlassian gehört die Entwicklung von Dokumenten für Standardarbeitsanweisungen. Einen schnellen Überblick über unsere übergeordneten Richtlinien und grundlegenden Prinzipien findest du unter: https://www.atlassian.com/trust/security/ismp-policies

6.03. (d)

Gibt es eine Staging-Umgebung zur Risikominderung, z. B. eine Entwicklungs-, Test- und Betriebsumgebung, und ist diese eigenständig?

Atlassian verfügt über Richtlinien zur Informationssicherheit, die die Verwendung von Produktionsdaten in Umgebungen außerhalb der Produktion verbieten. Jeder Versuch einer Datenmigration zwischen den Umgebungen wird durch den Änderungsmanagementprozess identifiziert. Der Code wird vom zentralisierten Build-System zunächst zu den Komponententests weitergereicht. Anschließend steht die Feature-Branch-Validierung mit zusätzlichen Testautomatisierungen und Gate-Reviews durch PM, Entw. und QS an. Darauf folgen Validierungen von Benutzerakzeptanztests (UAT), Sicherheit und Leistung. Entwickler können den Code nicht direkt in die Produktion befördern. Weitere Informationen sind verfügbar unter https://www.atlassian.com/trust/security/security-practices#managing-changes-in-our-environment

Produktionsumgebungen sind logisch und physisch von Nichtproduktionsumgebungen (Entwicklungsumgebungen) getrennt und wir verwenden Methoden zur Isolierung dieser Umgebungen.

Unsere Staging-Umgebung ist logisch, nicht jedoch physisch, getrennt und wird unter Änderungskontroll- und Zugriffsverfahren der Produktionsklasse verwaltet. Weitere Informationen über unsere Codesicherheitspraktiken findest du unter: https://www.atlassian.com/trust/security/security-in-development.

6.03. (e)

Definiere die Host- und Netzwerkkontrollen, die zum Schutz der Systeme eingesetzt werden, auf denen die Anwendungen und Informationen für den Endkunden gehostet werden. Diese sollten Einzelheiten der Zertifizierung nach externen Standards (z. B. ISO 27001/2) enthalten.

Atlassian Network Engineering verwendet IPS-Technologien, die in unsere Cloud- und Office-Firewalls integriert sind, und Atlassian hat IDS-Technologien in unseren Büroumgebungen implementiert. Der Schutz vor Netzwerkbedrohungen wird von AWS durchgeführt, einschließlich DDoS-Schutz und einiger Firewall-Funktionen für Webanwendungen. Alle Daten für unsere Services werden bei der Übertragung mit TLS verschlüsselt, um sie vor unbefugter Offenlegung oder Änderung zu schützen, sei es über HTTPS oder SMTPS.

Atlassian hat die SOC2-, ISO27001- und ISO27018-Zertifizierungen für unsere Cloud-Services erhalten. Wir führen mindestens jährlich interne und externe Audits sowie Bereitschaftsüberprüfungen durch.

Weitere Informationen findest du unter: https://www.atlassian.com/trust/compliance. Wir empfehlen unseren Kunden, regelmäßig die Aktualisierungen unserer Compliance-Zertifizierungen und -Berichte von dieser Website herunterzuladen und zu überprüfen.

6.03. (f)

Spezifiziere die Kontrollen, die zum Schutz vor bösartigem Code verwendet werden.

Atlassian hat Crowdstrike Falcon (https://www.crowdstrike.com/falcon-platform/) für alle unsere Windows- und Mac-Geräte implementiert. Wir verwenden keine Anti-Malware auf unseren Linux-Computern. Anti-Malware ist in unserer Richtlinie zum Management von Sicherheitsrisiken enthalten.

Wir pflegen eine Richtlinie zum Bedrohungs- und Sicherheitsrisikomanagement. Unser Policy Management Program (PMP) umfasst Pflichten in Bezug auf Eigentum, Verfügbarkeit und Überprüfungszyklus und beschreibt unsere allgemeinen Ziele. Unsere Richtlinien werden mindestens einmal jährlich überprüft und von der Geschäftsleitung genehmigt. Weitere Informationen über unser PMP findest du unter: https://www.atlassian.com/trust/security/security-management-program

Einen schnellen Überblick über unsere übergeordneten Richtlinien und grundlegenden Prinzipien findest du unter: https://www.atlassian.com/trust/security/ismp-policies

6.03. (g)

Werden sichere Konfigurationen eingesetzt, um nur die Ausführung von autorisiertem Mobilfunkcode und autorisierten Funktionen zu ermöglichen (z. B. nur bestimmte Befehle ausführen)?

Alle Server werden mithilfe unseres zentralen Puppet-Konfigurationssystems für unsere Standardbetriebsumgebung konfiguriert, einschließlich der Entfernung ausgewählter Pakete aus dem Standard-Image und wichtiger Paket-Updates. Alle Serverrollen lehnen alle eingehenden Netzwerkanfragen standardmäßig ab. Ausgewählte Ports sind nur für solche Serverrollen geöffnet, die aus Funktionsgründen auf den Port zugreifen müssen.

Unser Unternehmensnetzwerk ist von unserem Produktionsnetzwerk getrennt und unsere Machine Images sind so gesichert, dass nur die erforderlichen Ports und Protokolle zugelassen werden. Alle Produktionssysteme werden derzeit in den US-Regionen unseres Cloud-Anbieters gehostet. Alle Daten, die außerhalb von gesicherten VPC-Netzwerken (Virtual Private Cloud) übertragen werden, werden über branchenübliche Kanäle verschlüsselt.

Auf allen Produktionsservern ist zudem ein IDS-System mit Funktionen für Echtzeit-Überwachung vorhanden, das bei Änderungen an den Dateien oder der Konfiguration des Produktionssystems sowie bei anomalen Sicherheitsereignissen Warnungen ausgibt.

Außerdem haben wir eine zentralisierte Systemverwaltungslösung (https://www.jamf.com/lp/apple-mobile-device-management-mdm-jamf/) für alle unsere Mac-Laptops implementiert. Wir verwenden vollständige Festplattenverschlüsselung auf unseren Laptops. Außerdem haben wir eine Lösung zur Verwaltung mobiler Geräte für unsere Smartphones implementiert (https://www.vmware.com/products/workspace-one.html). Alle Geräte müssen für den Zugriff auf interne Systeme und Anwendungen registriert sein. Wenn ein Mobilgerät nicht registriert ist, kann es nicht auf interne Ressourcen zugreifen und befindet sich in einem Gastnetzwerk, das nur auf das Internet zugreifen kann. Der Zugriff wird über rollenbasierte Zugriffskontrollen verwaltet, um sicherzustellen, dass nur die Benutzer, die Zugriff auf Kunden-/Mandantendaten benötigen, diesen erhalten.

6.03. (h)

Beschreibe die Richtlinien und Verfahren für Backups. Dazu zählen auch Verfahren für die Verwaltung von Wechselmedien und Methoden zur sicheren Zerstörung von Medien, die nicht mehr benötigt werden. (Je nach seinen Geschäftsanforderungen möchte der Kunde möglicherweise eine unabhängige Backup-Strategie einrichten. Das ist besonders relevant, wenn zeitkritischer Zugriff auf Backups erforderlich ist.)

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. Für unsere Cloud-Produkte und insbesondere für dich und deine Anwendungsdaten verfügen wir über umfangreiche Backup-Maßnahmen. Wir verwenden 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. Kunden sollten auch regelmäßig eigene Backups durchführen, um vom Kunden initiierte Änderungen rückgängig machen zu können. Weitere Informationen findest du unter https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/#Can-Atlassian%E2%80%99s-RDS-backups-be-used-to-roll-back-changes.

Atlassian unterhält einen Standard zur Aufbewahrung und Vernichtung von Daten, der festlegt, wie lange wir Daten verschiedener Arten aufbewahren müssen. Daten werden gemäß unserer Atlassian-Richtlinie für Datensicherheit und Information Lifecycle Management und den darauf aufbauenden Kontrollen klassifiziert. Was Kundendaten betrifft, so werden bei Kündigung eines Atlassian-Vertrags die Daten eines Kundenteams aus der Live-Produktionsdatenbank entfernt. Alle direkt auf Atlassian hochgeladenen Dateianhänge werden innerhalb von 14 Tagen entfernt. Die Daten des Teams verbleiben in verschlüsselten Backups, bis das 90-tägige Aufbewahrungsfenster für diese Backups überschritten ist und sie gemäß unserer Atlassian-Datenspeicherungsrichtlinie vernichtet werden. Für den Fall, dass innerhalb von 90 Tagen nach einer angeforderten Datenlöschung eine Datenbankwiederherstellung erforderlich ist, wird das Operations-Team die Daten so schnell wie möglich erneut löschen, wenn das Live-Produktionssystem vollständig wiederhergestellt ist. Weitere Informationen findest du unter https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

Audit-Protokolle werden für den Fall verwendet, dass ein Vorfall untersucht werden muss, sowie zur Problembehebung. Für diese Zwecke benötigt der Endkunde die Gewissheit, dass solche Informationen verfügbar sind.

6.03. (i)

Kann der Anbieter detailliert angeben, welche Informationen in den Audit-Protokollen aufgezeichnet werden?

• Für welchen Zeitraum werden diese Daten aufbewahrt?
• Ist es möglich, Daten in Audit-Protokollen zu segmentieren, sodass sie dem Endkunden und/oder den Strafverfolgungsbehörden zur Verfügung gestellt werden können, ohne andere Kunden zu gefährden, und trotzdem vor Gericht zulässig sind?
• Welche Kontrollen werden eingesetzt, um Protokolle vor unbefugtem Zugriff oder Manipulation zu schützen?
• Welche Methode wird verwendet, um die Integrität der Audit-Protokolle zu überprüfen und zu schützen?

Wichtige Systemprotokolle werden von jedem System an eine zentrale Protokollplattform weitergeleitet, auf der Protokolle schreibgeschützt sind. Das Atlassian-Sicherheitsteam erstellt auf unserer Plattform für Sicherheitsanalysen (Splunk) Warnmeldungen 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.

Bei Atlassian dürfen Audit-Protokolle nur von autorisiertem Personal auf unserer zentralen Protokollierungsplattform eingesehen und gelesen werden.

Atlassian unterhält einen Standard zur Aufbewahrung und Vernichtung von Daten, der festlegt, wie lange wir Daten verschiedener Arten aufbewahren müssen. Daten werden gemäß unserer Atlassian-Richtlinie für Datensicherheit und Information Lifecycle Management und den darauf aufbauenden Kontrollen klassifiziert. Was Kundendaten betrifft, so werden bei Kündigung eines Atlassian-Vertrags die Daten eines Kundenteams aus der Live-Produktionsdatenbank entfernt. Alle direkt auf Atlassian hochgeladenen Dateianhänge werden innerhalb von 14 Tagen entfernt. Die Daten des Teams verbleiben in verschlüsselten Backups, bis das 90-tägige Aufbewahrungsfenster für diese Backups überschritten ist und sie gemäß unserer Atlassian-Datenspeicherungsrichtlinie vernichtet werden. Für den Fall, dass innerhalb von 90 Tagen nach einer angeforderten Datenlöschung eine Datenbankwiederherstellung erforderlich ist, wird das Operations-Team die Daten so schnell wie möglich erneut löschen, wenn das Live-Produktionssystem vollständig wiederhergestellt ist. Weitere Informationen findest du unter https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

6.03. (j)

Wie werden Audit-Protokolle geprüft? Welche aufgezeichneten Ereignisse führen dazu, dass Maßnahmen ergriffen werden?

Wichtige Systemprotokolle werden von jedem System an eine zentrale Protokollplattform weitergeleitet, auf der Protokolle schreibgeschützt sind. Das Atlassian-Sicherheitsteam erstellt auf unserer Plattform für Sicherheitsanalysen (Splunk) Warnmeldungen 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.

Bei Atlassian dürfen Audit-Protokolle nur von autorisiertem Personal auf unserer zentralen Protokollierungsplattform eingesehen und gelesen werden.

6.03. (k)

Welche Zeitquelle wird verwendet, um Systeme zu synchronisieren und einen genauen Zeitstempel für das Audit-Protokoll bereitzustellen?

Atlassian Cloud verwendet AWS Time Sync für alle bereitgestellten Instanzen.

6.03.01. (a)

Definiere Kontrollen, die verwendet werden, um die Integrität des Betriebssystems und der verwendeten Anwendungssoftware zu schützen. Füge alle Standards hinzu, die befolgt werden, z. B. OWASP, SANS-Checkliste, SafeCode.

Unser Team von Sicherheitstechnikern führt im Rahmen unseres Entwicklungszyklus kontinuierlich eine turnusmäßige Überprüfung des gesamten Quellcodes unserer Produkte durch. Es werden sowohl automatisierte als auch manuelle Techniken eingesetzt. Wir verwenden auch ein obligatorisches duales Peer-Review-Verfahren, bei dem mehrere erfahrene oder leitende Entwickler alle Master Commits überprüfen. Agile Workflows ermöglichen es uns, alle Schwachstellen schnell zu identifizieren und zu beheben, insbesondere für unsere Cloud-Services.

Der Prüfprozess von Atlassian für sicheren Code umfasst automatisches Scannen (d. h. Softwarekompositionsanalyse) auf bekannte Schwachstellen, einschließlich solcher, die bei echten Angriffen ausgenutzt wurden. Zusätzlich scannt unser Programm zur Verwaltung von Schwachstellen mithilfe von Snyk Hosts und Container-Images auf bekannte Schwachstellen. Weitere Informationen findest du unter https://www.atlassian.com/trust/security/vulnerability-management.

Wir arbeiten mit BugCrowd an einem Bug-Bounty-Programm zusammen, um fortlaufende Schwachstellenbewertungen unserer öffentlich zugänglichen Anwendungen und Services durchzuführen. Das Programm ist verfügbar unter https://bugcrowd.com/atlassian. Wir teilen die Ergebnisse der laufenden Penetrationstests aus unserem Bug-Bounty-Programm unter https://www.atlassian.com/trust/security/security-testing.

6.03.01. (b)

Wie wird verifiziert, dass neue Releases für ihren Zweck geeignet sind oder keine Risiken beinhalten (Hintertüren, Trojaner usw.)? Werden diese vor der Verwendung überprüft?

Der Prozess für das Änderungsmanagement bei Atlassian unterscheidet sich geringfügig von herkömmlichen Änderungsprozessen. Wir verlassen uns bei allen Änderungen, ob es sich um Code-, Anwendungs- oder Infrastrukturänderungen handelt, auf eine PRGB-Kontrolle (Peer Review und Green Build). Peer Review (Prüfung durch Kollegen) ist in unserem CD-Tool konfiguriert, in dem wichtige Branches so eingerichtet werden müssen, dass sie für jede Pull-Anfrage mehrere Gutachter haben. In der Regel sind das zwei Entwickler und der Teamleiter. Green Build (erfolgreicher Build) bedeutet hier, dass die Integration während der CI-Phase alle Integrations-, Funktions-, Sicherheits- und anderen Tests bestehen muss, die entwickelt wurden. Wenn diese Tests nicht bestanden werden (Red Build), wird für den Code kein Merge durchgeführt und er muss erneut überprüft und die Fehler behoben werden. Sobald ein Green Build erfolgreich ist, wird die Binärdatei kryptografisch signiert und unsere Produktionsumgebung führt nur Binärdateien aus, die mit unserem Schlüssel signiert sind. Unser Testprozess umfasst sowohl automatische als auch manuelle Bewertungskomponenten. Wir schreiben in Blogs gerne über Dinge, die wir besonders gut können. Wir sind überzeugt von unserem "Quality Assistance"-Ansatz (anstelle der traditionellen "Qualitätssicherung"): https://www.atlassian.com/inside-atlassian/quality-assurance-vs-quality-assistance.

Nach dem Deployment setzen wir regelmäßige automatische Schwachstellenscans und ein branchenführendes Bug-Bounty-Programm (https://bugcrowd.com/atlassian) ein, um die kontinuierliche Sicherheit unserer Anwendungen zu gewährleisten. Änderungen der Systemkonfiguration werden durch einen automatisierten Prozess verwaltet, der auch eine Überprüfung beinhaltet.

Der Prüfprozess von Atlassian für sicheren Code umfasst automatisches Scannen (d. h. Softwarekompositionsanalyse) auf bekannte Schwachstellen, einschließlich solcher, die bei echten Angriffen ausgenutzt wurden. Zusätzlich scannt unser Programm zur Verwaltung von Schwachstellen mithilfe von Snyk Hosts und Container-Images auf bekannte Schwachstellen. Weitere Informationen findest du unter https://www.atlassian.com/trust/security/vulnerability-management.

6.03.01. (c)

Welche Praktiken werden befolgt, um die Sicherheit der Anwendungen aufrechtzuerhalten?

Unsere Anwendungen erfordern Peer Review und Green Build (PRGB). Danach werden die Anwendungsartefakte kryptografisch signiert und automatisch von unserer CI/CD-Pipeline bereitgestellt. Nur von Atlassian signierte Anwendungen können in unserer Produktionsumgebung ausgeführt werden.

Atlassian verwendet in allen Phasen des Entwicklungslebenszyklus sichere Entwicklungspraktiken. Weitere Informationen findest du unter https://www.atlassian.com/trust/security/security-in-development.

Zu den Praktiken in der Designphase gehören Bedrohungsmodellierung, Designprüfungen und eine regelmäßig aktualisierte Bibliothek mit Sicherheitsstandards, die gewährleistet, dass Sicherheitsanforderungen berücksichtigt werden. Während der Entwicklung verlassen wir uns auf ein obligatorisches Peer-Review-Verfahren als erste Stufe der Sicherheitsüberprüfung. Dies wird durch automatisierte statische Analyseprüfungen (SAST) und manuelle Sicherheitstests unterstützt (sowohl durch interne Teams als auch durch externe Experten, wie es unser Risikobewertungsprozess vorschreibt). Die Entwicklung wird zudem durch Schulungsprogramme zur Anwendungssicherheit und eine vom Sicherheitsteam verwaltete Sicherheitswissensdatenbank unterstützt. Formale Betriebsbereitschafts- und Änderungskontrollprozesse stellen dann sicher, dass nur genehmigte Änderungen in die Produktion übernommen werden. Nach dem Deployment setzen wir regelmäßige automatische Schwachstellenscans und ein branchenführendes Bug-Bounty-Programm (https://bugcrowd.com/atlassian) ein, um die kontinuierliche Sicherheit unserer Anwendungen zu gewährleisten. Änderungen der Systemkonfiguration werden durch einen automatisierten Prozess verwaltet, der die Überprüfung aller Änderungen vor dem Deployment in der Produktion umfasst. Atlassian Service Operations kann Patches bereitstellen, sobald ein erhebliches Risiko erkannt wird. Wir können anhand interner Kriterien bestimmen, wie schnell Patches implementiert werden müssen, und diese innerhalb von 12 Stunden auf alle Rechner anwenden. Es gibt auch ein IDS-System, das die Überwachung der Systemkonfigurationsdateien umfasst.

6.03.01. (d)

Wird eine Softwareversion auf Penetration getestet, um sicherzustellen, dass sie keine Schwachstellen enthält? Welches Verfahren wird zur Behebung entdeckter Schwachstellen angewendet?

Atlassian verwendet in allen Phasen des Entwicklungslebenszyklus sichere Entwicklungspraktiken. Weitere Informationen findest du unter https://www.atlassian.com/trust/security/security-in-development.

Während der Entwicklung verlassen wir uns auf ein obligatorisches Peer-Review-Verfahren als erste Stufe der Sicherheitsüberprüfung. Dies wird durch automatisierte statische Analyseprüfungen (SAST) und manuelle Sicherheitstests unterstützt (sowohl durch interne Teams als auch durch externe Experten, wie es unser Risikobewertungsprozess vorschreibt). Die Entwicklung wird zudem durch Schulungsprogramme zur Anwendungssicherheit und eine vom Sicherheitsteam verwaltete Sicherheitswissensdatenbank unterstützt.

Formale Betriebsbereitschafts- und Änderungskontrollprozesse stellen dann sicher, dass nur genehmigte Änderungen in die Produktion übernommen werden. Nach dem Deployment setzen wir regelmäßige automatische Schwachstellenscans und ein branchenführendes Bug-Bounty-Programm (https://bugcrowd.com/atlassian) ein, um die kontinuierliche Sicherheit unserer Anwendungen zu gewährleisten.

6.03.02. (a)

Erläutere das Verfahren für das Patch-Management.

Wir pflegen eine Richtlinie zum Bedrohungs- und Schwachstellenmanagement. Unser Policy Management Program (PMP) umfasst Pflichten in Bezug auf Eigentum, Verfügbarkeit und Überprüfungszyklus und beschreibt unsere allgemeinen Ziele. Unsere Richtlinien werden mindestens einmal jährlich überprüft und von der Geschäftsleitung genehmigt. Weitere Informationen über unser PMP findest du unter https://www.atlassian.com/trust/security/security-management-program

Einen schnellen Überblick über unsere übergeordneten Richtlinien und grundlegenden Prinzipien findest du unter https://www.atlassian.com/trust/security/ismp-policies

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. Weitere Informationen findest du unter https://www.atlassian.com/trust/security/security-practices#keeping-track-of-information-assets

6.03.02. (b)

Kannst du sicherstellen, dass der Patch-Management-Prozess alle Ebenen der Cloud-Bereitstellungstechnologien abdeckt, d. h. Netzwerk (Infrastrukturkomponenten, Router und Switches usw.), Serverbetriebssysteme, Virtualisierungssoftware, Anwendungen und Sicherheitssubsysteme (Firewalls, Antiviren-Gateways, Angriffserkennungssysteme usw.)?

Änderungen der Systemkonfiguration werden durch einen automatisierten Prozess verwaltet, der die Überprüfung aller Änderungen vor dem Deployment in der Produktion umfasst. Atlassian Service Operations kann Patches bereitstellen, sobald ein erhebliches Risiko erkannt wird. Wir können anhand interner Kriterien bestimmen, wie schnell Patches implementiert werden müssen, und diese innerhalb von 12 Stunden auf alle Rechner anwenden. Es gibt ein IDS-System, das die Überwachung der Systemkonfigurationsdateien umfasst.

Atlassian Cloud-Produkte können so schnell wie nötig auf das neueste AMI aktualisiert werden. Unsere SaaS-Anwendungen werden mehrmals pro Woche aktualisiert. Wir haben schnelle und kontrollierte Deployment-Mechanismen für Updates unseres Codes und unserer Systemkonfigurationen. Atlassian verwendet aktiv eine Änderungskontrolle für ungeplante und dringende Änderungen.

6.03.03. (a)

Definiere die Kontrollen, die zur Abwehr von DDoS-Angriffen (Distributed Denial-of-Service) verwendet werden.

• Gestaffelte Sicherheitsebenen (tiefgehende Paketanalyse, Bandbreiteneinschränkung, Paket-Blackholing usw.).
• Verfügt dein Unternehmen über Abwehrmechanismen gegen "interne" (aus den Netzwerken der Cloud-Anbieter stammende) Angriffe sowie gegen externe (aus dem Internet oder Kundennetzwerken stammende) Angriffe?
<

Netzwerksicherheitsanforderungen werden in unserer Richtlinie zur Kommunikationssicherheit beschrieben, die jährlich im Einklang mit unserem Policy Management Program (PMP) überprüft wird. Weitere Informationen zum PMP findest du unter https://www.atlassian.com/trust/security/security-management-program

Unsere Atlassian Cloud-Plattform bietet nur sehr wenig Angriffsfläche. Wir überprüfen unsere Firewall-Regeln regelmäßig. Wir haben IDS an unseren Bürostandorten und in unserer Cloud-Hosting-Umgebung bereitgestellt. Für die Atlassian Cloud-Plattform ist die Protokollweiterleitung in eine Plattform für Sicherheitsanalysen integriert. Die Dateiintegrität auf Container-Ebene der Cloud-Plattform wird dadurch gewahrt, dass die Instanzen nicht modifizierbar sind. Atlassian Network Engineering verwendet IPS-Technologien, die in unsere Firewalls integriert sind, und wir haben IDS-Technologien in unseren Büro- und Cloud-Umgebungen implementiert. DDoS-Funktionen werden von unserem Internetdienstanbieter/Netzbetreiber bereitgestellt.

Die Leistung unserer Firewalls wird zudem regelmäßig durch eine Schwachstellenanalyse (https://www.atlassian.com/trust/security/vulnerability-management) und Penetrationstests (https://www.atlassian.com/trust/security/security-testing) bewertet.

6.03.03. (b)

Welche Isolationsstufen werden verwendet?

• Für virtuelle Computer, physische Computer, Netzwerke, Speicher (z. B. Storage Area Networks), Verwaltungsnetzwerke und Management-Support-Systeme usw.
<

Atlassian ist eine mehrmandantenfähige SaaS-Anwendung. Mehrmandantenfähigkeit ist eine wichtige Funktion von Atlassian Cloud, die es mehreren Kunden ermöglicht, eine Instanz der Jira- oder Confluence-Anwendungsebene gemeinsam zu nutzen, wobei die Anwendungsdaten ihres jeweiligen Mandanten isoliert werden. Atlassian Cloud erreicht dies durch den Tenant Context Service (TCS). Jede Benutzer-ID ist mit genau einem Mandanten verknüpft, der dann für den Zugriff auf die Atlassian Cloud-Anwendungen verwendet wird. Weitere Informationen findest du unter: https://www.atlassian.com/trust/security/security-practices#tenant-isolation

Produktionsumgebungen sind logisch und physisch von Nichtproduktionsumgebungen (Entwicklungsumgebungen) getrennt und wir verwenden Methoden zur Isolierung dieser Umgebungen.

Unsere Staging-Umgebung ist logisch, nicht jedoch physisch, getrennt und wird unter Änderungskontroll- und Zugriffsverfahren der Produktionsklasse verwaltet.

6.03.03. (c)

Unterstützt die Architektur den unterbrechungsfreien Betrieb über die Cloud, wenn das Unternehmen vom Serviceanbieter getrennt ist und umgekehrt (besteht beispielsweise eine kritische Abhängigkeit vom LDAP-System des Kunden)?

Eine Richtlinie für Business Continuity und Disaster Recovery sowie ein Plan für Business Continuity und Disaster Recovery sind vorhanden und werden jährlich vom Lenkungsausschuss für Business Continuity/Disaster Recovery überprüft. Weitere Informationen findest du unter: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e und https://www.atlassian.com/trust/security/data-management.

Atlassian nutzt die hochverfügbaren AWS-Rechenzentren, die in verschiedenen Regionen weltweit angesiedelt sind, um einen unterbrechungsfreien Betrieb sicherzustellen. Weitere Informationen findest du unter: https://www.atlassian.com/trust/security/data-management.

6.03.03. (d)

Ist die virtuelle Netzwerkinfrastruktur, die von Cloud-Anbietern verwendet wird (in PVLANs und VLAN-Tagging-802.1q-Architektur) nach herstellerspezifischen und/oder Best-Practice-spezifischen Standards gesichert (z. B. werden MAC-Spoofing, ARP-Poising-Attacken usw. durch eine bestimmte Sicherheitskonfiguration verhindert)?

Netzwerksicherheitsanforderungen werden in unserer Richtlinie zur Kommunikationssicherheit beschrieben, die jährlich im Einklang mit unserem Policy Management Program (PMP) überprüft wird. Weitere Informationen zum PMP findest du unter: https://www.atlassian.com/trust/security/security-management-program

Unsere Atlassian Cloud-Plattform bietet nur sehr wenig Angriffsfläche. Wir überprüfen unsere Firewall-Regeln regelmäßig. Wir haben IDS an unseren Bürostandorten und in unserer Cloud-Hosting-Umgebung bereitgestellt. Für die Atlassian Cloud-Plattform ist die Protokollweiterleitung in eine Plattform für Sicherheitsanalysen integriert. Die Dateiintegrität auf Container-Ebene der Cloud-Plattform wird dadurch gewahrt, dass die Instanzen nicht modifizierbar sind. Atlassian Network Engineering verwendet IPS-Technologien, die in unsere Firewalls integriert sind, und wir haben IDS-Technologien in unseren Büro- und Cloud-Umgebungen implementiert. DDoS-Funktionen werden von unserem Internetanbieter/-betreiber bereitgestellt.

Die Leistung unserer Firewalls wird zudem regelmäßig durch eine Schwachstellenanalyse (https://www.atlassian.com/trust/security/vulnerability-management) und Penetrationstests (https://www.atlassian.com/trust/security/security-testing) bewertet .

Zudem überwacht Atlassian die Konfiguration seiner AWS-Umgebungen anhand etablierter Konfigurationsgrundlagen.

6.03.04. (a)

Stellt der Anbieter sicher, dass virtuelle Images standardmäßig gesichert sind?

Alle Server werden mithilfe unseres zentralen Puppet-Konfigurationssystems für unsere Standardbetriebsumgebung konfiguriert, einschließlich der Entfernung ausgewählter Pakete aus dem Standard-Image und wichtiger Paket-Updates. Alle Serverrollen lehnen alle eingehenden Netzwerkanfragen standardmäßig ab. Ausgewählte Ports sind nur für solche Serverrollen geöffnet, die aus Funktionsgründen auf den Port zugreifen müssen.

Unser Unternehmensnetzwerk ist von unserem Produktionsnetzwerk getrennt, und unsere Machine Images sind so gesichert, dass nur die erforderlichen Ports und Protokolle zugelassen werden. Alle Produktionssysteme werden derzeit in den US-Regionen unseres Cloud-Anbieters gehostet. Alle Daten, die außerhalb von gesicherten VPC-Netzwerken (Virtual Private Cloud) übertragen werden, werden über branchenübliche Kanäle verschlüsselt.

Auf allen Produktionsservern ist zudem ein IDS-System mit Funktionen für Echtzeit-Überwachung vorhanden, das bei Änderungen an den Dateien oder der Konfiguration des Produktionssystems sowie bei anomalen Sicherheitsereignissen Warnungen ausgibt.

In der Atlassian Cloud-Plattform haben einzelne Container kein Image. Wenn der Container initiiert wird, wird ein Bild aus einem Standard-Repository ausgewählt. Wir führen fortlaufende Prüfungen für jedes der Images durch und sorgen bei Bedarf für eine erneute Anwendung der Images durch unsere Konfigurationstools. Infolgedessen werden keine Änderungen an den Images des virtuellen Computers vorgenommen.

Die Image-Builds des Basisbetriebssystems von AWS Linux AMI verfügen über begrenzte Ports, Protokolle und Services. Wir vergleichen unsere Builds mit der aktuellen AMI-Version, um die richtigen Einstellungen festzulegen.

Unsere Docker-Images werden in einer streng kontrollierten Änderungsumgebung verwaltet, um eine angemessene Überprüfung und Genehmigung aller Änderungen sicherzustellen.

6.03.04. (b)

Ist das gesicherte virtuelle Image vor unbefugtem Zugriff geschützt?

Alle Server werden mithilfe unseres zentralen Puppet-Konfigurationssystems für unsere Standardbetriebsumgebung konfiguriert, einschließlich der Entfernung ausgewählter Pakete aus dem Standard-Image und wichtiger Paket-Updates. Alle Serverrollen lehnen alle eingehenden Netzwerkanfragen standardmäßig ab. Ausgewählte Ports sind nur für solche Serverrollen geöffnet, die aus Funktionsgründen auf den Port zugreifen müssen.

Unser Unternehmensnetzwerk ist von unserem Produktionsnetzwerk getrennt, und unsere Machine Images sind so gesichert, dass nur die erforderlichen Ports und Protokolle zugelassen werden. Alle Produktionssysteme werden derzeit in den US-Regionen unseres Cloud-Anbieters gehostet. Alle Daten, die außerhalb von gesicherten VPC-Netzwerken (Virtual Private Cloud) übertragen werden, werden über branchenübliche Kanäle verschlüsselt.

Auf allen Produktionsservern ist zudem ein IDS-System mit Funktionen für Echtzeit-Überwachung vorhanden, das bei Änderungen an den Dateien oder der Konfiguration des Produktionssystems sowie bei anomalen Sicherheitsereignissen Warnungen ausgibt.

In der Atlassian Cloud-Plattform haben einzelne Container kein Image. Wenn der Container initiiert wird, wird ein Bild aus einem Standard-Repository ausgewählt. Wir führen fortlaufende Prüfungen für jedes der Images durch und sorgen bei Bedarf für eine erneute Anwendung der Images durch unsere Konfigurationstools. Infolgedessen werden keine Änderungen an den Images des virtuellen Computers vorgenommen.

Die Image-Builds des Basisbetriebssystems von AWS Linux AMI verfügen über begrenzte Ports, Protokolle und Services. Wir vergleichen unsere Builds mit der aktuellen AMI-Version, um die richtigen Einstellungen festzulegen.

Unsere Docker-Images werden in einer streng kontrollierten Änderungsumgebung verwaltet, um eine angemessene Überprüfung und Genehmigung aller Änderungen sicherzustellen.

Unser globales Support-Team unterhält für Wartungs- und Support-Zwecke ein Konto auf allen gehosteten Systemen und Anwendungen. Der Zugriff auf die gehosteten Anwendungen und Daten durch das Support-Team erfolgt zur Überwachung der Anwendungsfunktionen und zur System- und Anwendungswartung oder nach Kundenanfrage über unser Support-System.

6.03.04. (c)

Kann der Anbieter bestätigen, dass das virtualisierte Image die Authentifizierungsdaten nicht enthält?

Alle Server werden mithilfe unseres zentralen Puppet-Konfigurationssystems für unsere Standardbetriebsumgebung konfiguriert, einschließlich der Entfernung ausgewählter Pakete aus dem Standard-Image und wichtiger Paket-Updates. Alle Serverrollen lehnen alle eingehenden Netzwerkanfragen standardmäßig ab. Ausgewählte Ports sind nur für solche Serverrollen geöffnet, die aus Funktionsgründen auf den Port zugreifen müssen.

Unser Unternehmensnetzwerk ist von unserem Produktionsnetzwerk getrennt, und unsere Machine Images sind so gesichert, dass nur die erforderlichen Ports und Protokolle zugelassen werden. Alle Produktionssysteme werden derzeit in den US-Regionen unseres Cloud-Anbieters gehostet. Alle Daten, die außerhalb von gesicherten VPC-Netzwerken (Virtual Private Cloud) übertragen werden, werden über branchenübliche Kanäle verschlüsselt.

Auf allen Produktionsservern ist zudem ein IDS-System mit Funktionen für Echtzeit-Überwachung vorhanden, das bei Änderungen an den Dateien oder der Konfiguration des Produktionssystems sowie bei anomalen Sicherheitsereignissen Warnungen ausgibt.

In der Atlassian Cloud-Plattform haben einzelne Container kein Image. Wenn der Container initiiert wird, wird ein Bild aus einem Standard-Repository ausgewählt. Wir führen fortlaufende Prüfungen für jedes der Images durch und sorgen bei Bedarf für eine erneute Anwendung der Images durch unsere Konfigurationstools. Infolgedessen werden keine Änderungen an den Images des virtuellen Computers vorgenommen.

Die Image-Builds des Basisbetriebssystems von AWS Linux AMI verfügen über begrenzte Ports, Protokolle und Services. Wir vergleichen unsere Builds mit der aktuellen AMI-Version, um die richtigen Einstellungen festzulegen.

Unsere Docker-Images werden in einer streng kontrollierten Änderungsumgebung verwaltet, um eine angemessene Überprüfung und Genehmigung aller Änderungen sicherzustellen.

Unser globales Support-Team unterhält für Wartungs- und Support-Zwecke ein Konto auf allen gehosteten Systemen und Anwendungen. Der Zugriff auf die gehosteten Anwendungen und Daten durch das Support-Team erfolgt zur Überwachung der Anwendungsfunktionen und zur System- und Anwendungswartung oder nach Kundenanfrage über unser Support-System.

6.03.04. (d)

Wird die Host-Firewall nur mit den minimalen Ports betrieben, die notwendig sind, um die Dienste innerhalb der virtuellen Instanz zu unterstützen?

Alle Server werden mithilfe unseres zentralen Puppet-Konfigurationssystems für unsere Standardbetriebsumgebung konfiguriert, einschließlich der Entfernung ausgewählter Pakete aus dem Standard-Image und wichtiger Paket-Updates. Alle Serverrollen lehnen alle eingehenden Netzwerkanfragen standardmäßig ab. Ausgewählte Ports sind nur für solche Serverrollen geöffnet, die aus Funktionsgründen auf den Port zugreifen müssen.

Unser Unternehmensnetzwerk ist von unserem Produktionsnetzwerk getrennt, und unsere Machine Images sind so gesichert, dass nur die erforderlichen Ports und Protokolle zugelassen werden. Alle Produktionssysteme werden derzeit in den US-Regionen unseres Cloud-Anbieters gehostet. Alle Daten, die außerhalb von gesicherten VPC-Netzwerken (Virtual Private Cloud) übertragen werden, werden über branchenübliche Kanäle verschlüsselt.

Unsere Atlassian Cloud-Plattform bietet nur sehr wenig Angriffsfläche. Wir überprüfen unsere Firewall-Regeln regelmäßig. Wir haben IDS an unseren Bürostandorten und in unserer Cloud-Hosting-Umgebung bereitgestellt. Für die Atlassian Cloud-Plattform ist die Protokollweiterleitung in eine Plattform für Sicherheitsanalysen integriert. Die Dateiintegrität auf Container-Ebene der Cloud-Plattform wird dadurch gewahrt, dass die Instanzen nicht modifizierbar sind. Atlassian Network Engineering verwendet IPS-Technologien, die in unsere Firewalls integriert sind, und wir haben IDS-Technologien in unseren Büro- und Cloud-Umgebungen implementiert. DDoS-Funktionen werden von unserem Internetanbieter/-betreiber bereitgestellt.

Die Leistung unserer Firewalls wird zudem regelmäßig durch eine Schwachstellenanalyse (https://www.atlassian.com/trust/security/vulnerability-management) und Penetrationstests (https://www.atlassian.com/trust/security/security-testing) bewertet .

6.03.04. (e)

Kann ein hostbasierter Intrusion Prevention Service (IPS) in der virtuellen Instanz ausgeführt werden?

Nicht zutreffend, da Atlassian ein SaaS-Modell (Software as a Service) betreibt.

6.03.05.

Im Allgemeinen sind PaaS-Serviceanbieter für die Sicherheit des Plattform-Software-Stacks verantwortlich. Die Empfehlungen in diesem Dokument sind eine gute Grundlage, um sicherzustellen, dass ein PaaS-Anbieter bei der Entwicklung und Verwaltung seiner PaaS-Plattform die Sicherheitsprinzipien berücksichtigt hat. Es ist oft schwierig, von PaaS-Anbietern detaillierte Informationen darüber zu erhalten, wie sie ihre Plattformen sichern. Die folgenden Fragen sowie andere Abschnitte in diesem Dokument sollten jedoch bei der Bewertung ihrer Angebote hilfreich sein.

6.03.05. (a)

Fordere Informationen darüber an, wie mehrmandantenfähige Anwendungen voneinander isoliert werden – eine ausführliche Beschreibung der Eindämmungs- und Isolationsmaßnahmen ist erforderlich.

Nicht zutreffend, da Atlassian ein SaaS-Modell (Software as a Service) betreibt.

6.03.05. (b)

Welche Zusicherung kann der PaaS-Anbieter geben, dass der Zugriff auf deine Daten auf deine Unternehmensanwender und deine Anwendungen beschränkt ist?

Nicht zutreffend, da Atlassian ein SaaS-Modell (Software as a Service) betreibt.

6.03.05. (c)

Die Plattformarchitektur sollte eine klassische "Sandbox" sein. Stellt der Anbieter sicher, dass die PaaS-Plattform-Sandbox auf neue Bugs und Sicherheitslücken überwacht wird?

Nicht zutreffend, da Atlassian ein SaaS-Modell (Software as a Service) betreibt.

6.03.05. (d)

PaaS-Anbieter sollten eine Reihe von Sicherheitsfunktionen anbieten (die von ihren Kunden wiederverwendet werden können) – umfassen diese Benutzerauthentifizierung, Single-Sign-On, Autorisierung (Rechteverwaltung) und SSL/TLS (bereitgestellt durch eine API)?

Nicht zutreffend, da Atlassian ein SaaS-Modell (Software as a Service) betreibt.

6.03.06.

Das SaaS-Modell schreibt vor, dass der Anbieter die gesamte Suite von Anwendungen verwaltet, die den Endbenutzern zur Verfügung gestellt werden. Daher sind SaaS-Anbieter hauptsächlich für die Sicherung dieser Anwendungen verantwortlich. Kunden sind normalerweise für betriebliche Sicherheitsprozesse (Benutzer- und Zugriffsmanagement) verantwortlich. Bei der Bewertung von Angeboten können dir jedoch die folgenden Fragen sowie andere Abschnitte in diesem Dokument helfen:

6.03.06. (a)

Welche Verwaltungskontrollen gibt es und können diese verwendet werden, um anderen Benutzern Lese- und Schreibrechte zuzuweisen?

Kunden unserer Enterprise- und Premium-Cloud-Angebote haben Zugriff auf einen zentralen Administrationsbereich. Die Admins deiner Organisation können den Benutzerzugriff und die Berechtigungen für all deine Produktinstanzen verwalten. Siehe hierzu unseren Blogpost: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Atlassian-Kunden können einen externen Identitätsanbieter ihrer Wahl verwenden, sofern dieser von Atlassian unterstützt wird. Näheres zu diesen Funktionen sowie eine Anleitung zur Einbindung deines Identitätsanbieters findest du auf der folgenden Atlassian Support-Seite: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.03.06. (b)

Ist die SaaS-Zugriffskontrolle feinkörnig und kann sie an die Richtlinien deiner Organisation angepasst werden?

Kunden unserer Enterprise- und Premium-Cloud-Angebote haben Zugriff auf einen zentralen Administrationsbereich. Die Admins deiner Organisation können den Benutzerzugriff und die Berechtigungen für all deine Produktinstanzen verwalten. Siehe hierzu unseren Blogpost: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Atlassian-Kunden können einen externen Identitätsanbieter ihrer Wahl verwenden, sofern dieser von Atlassian unterstützt wird. Näheres zu diesen Funktionen sowie eine Anleitung zur Einbindung deines Identitätsanbieters findest du auf der folgenden Atlassian Support-Seite: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.03.07. (a)

Im Fall einer Überlastung von Ressourcen (Prozessor, RAM, Speicher, Netzwerk):

• Welche Informationen gibt es über die relative Priorität, die meiner Anfrage im Fall eines Bereitstellungsfehlers zugewiesen wird?
• Gibt es eine Vorlaufzeit in Bezug auf Service-Levels und Änderungen der Anforderungen?
<

Atlassian plant die Kapazität 6–12 Monate im Voraus, wobei die grobe perspektivische Planung auf 36 Monate ausgelegt ist.

Atlassian analysiert die Scaling-in- und Scaling-out-Architekturen von AWS und Azure für Cloud und nutzt diese Daten als Grundlage für das weitere Produktwachstum. Diese Daten werden Kunden derzeit jedoch nicht zur Verfügung gestellt.

6.03.07. (b)

Wie viel Skalierungsspielraum gibt es nach oben? Bietet der Anbieter Garantien für maximal verfügbare Ressourcen innerhalb eines Mindestzeitraums?

Atlassian plant die Kapazität 6–12 Monate im Voraus, wobei die grobe perspektivische Planung auf 36 Monate ausgelegt ist.

Atlassian analysiert die Scaling-in- und Scaling-out-Architekturen von AWS und Azure für Cloud und nutzt diese Daten als Grundlage für das weitere Produktwachstum. Diese Daten werden Kunden derzeit jedoch nicht zur Verfügung gestellt.

6.03.07. (c)

Wie schnell kann nach oben skaliert werden? Bietet der Anbieter Garantien für die Verfügbarkeit zusätzlicher Ressourcen innerhalb eines Mindestzeitraums?

Atlassian plant die Kapazität 6–12 Monate im Voraus, wobei die grobe perspektivische Planung auf 36 Monate ausgelegt ist.

Atlassian analysiert die Scaling-in- und Scaling-out-Architekturen von AWS und Azure für Cloud und nutzt diese Daten als Grundlage für das weitere Produktwachstum. Diese Daten werden Kunden derzeit jedoch nicht zur Verfügung gestellt.

6.03.07. (d)

Wie werden starke Fluktuationen bei der Ressourcennutzung gehandhabt (z. B. saisonal bedingt)?

Atlassian plant die Kapazität 6–12 Monate im Voraus, wobei die grobe perspektivische Planung auf 36 Monate ausgelegt ist.

Atlassian analysiert die Scaling-in- und Scaling-out-Architekturen von AWS und Azure für Cloud und nutzt diese Daten als Grundlage für das weitere Produktwachstum. Diese Daten werden Kunden derzeit jedoch nicht zur Verfügung gestellt.

6.04.01.

Die folgenden Kontrollen gelten für die Identitäts- und Zugriffsverwaltungssysteme des Cloud-Anbieters (die unter seiner Kontrolle stehen).

6.04.01. (a)

Gibt es Konten mit systemweiten Berechtigungen für das gesamte Cloud-System und wenn ja, für welche Operationen (Lesen/Schreiben/Löschen)?

Unser globales Support-Team unterhält für Wartungs- und Support-Zwecke ein Konto auf allen gehosteten Systemen und Anwendungen. Der Zugriff auf die gehosteten Anwendungen und Daten erfolgt zur Überwachung der Anwendungsfunktionen und zur System- und Anwendungswartung oder nach Kundenanfrage über unser Supportsystem.

6.04.01. (b)

Wie werden die Konten mit den höchsten Berechtigungen authentifiziert und verwaltet?

Atlassian beschränkt weiterhin die Mitarbeiter, die diesen Zugriff für ihre berufliche Rolle und ihre Aufgaben benötigen. Alle Tier-1-Systeme werden über die zentrale Single-Sign-On (SSO)- und Verzeichnislösung von Atlassian verwaltet. Benutzer erhalten auf der Grundlage dieser Profile angemessene Zugriffsrechte, die über Workflow aus unserem Personalverwaltungssystem gesteuert werden. Atlassian nutzt MFA für den Zugriff auf alle Tier-1-Systeme. Wir haben die Zwei-Faktor-Authentifizierung für die Hypervisor-Managementkonsole und die AWS-API sowie einen täglichen Auditbericht über den gesamten Zugriff auf die Hypervisor-Verwaltungsfunktionen aktiviert. Die Zugriffslisten für die Hypervisor-Managementkonsole und die AWS-API werden vierteljährlich überprüft. Wir führen außerdem eine 8-stündige Synchronisation zwischen unserem HR-System und unserem Identitätsspeicher durch.

6.04.01. (c)

Wie werden die wichtigsten Entscheidungen (z. B. das gleichzeitige Aufheben der Bereitstellung großer Ressourcenblöcke) autorisiert (einzeln oder doppelt, und von welchen Rollen innerhalb der Organisation)?

Atlassian beschränkt weiterhin die Mitarbeiter, die diesen Zugriff für ihre berufliche Rolle und ihre Aufgaben benötigen. Alle Tier-1-Systeme werden über die zentrale Single-Sign-On (SSO)- und Verzeichnislösung von Atlassian verwaltet. Benutzer erhalten auf der Grundlage dieser Profile angemessene Zugriffsrechte, die über Workflow aus unserem Personalverwaltungssystem gesteuert werden. Atlassian nutzt MFA für den Zugriff auf alle Tier-1-Systeme. Wir haben die Zwei-Faktor-Authentifizierung für die Hypervisor-Managementkonsole und die AWS-API sowie einen täglichen Auditbericht über den gesamten Zugriff auf die Hypervisor-Verwaltungsfunktionen aktiviert. Die Zugriffslisten für die Hypervisor-Managementkonsole und die AWS-API werden vierteljährlich überprüft. Wir führen außerdem eine 8-stündige Synchronisation zwischen unserem HR-System und unserem Identitätsspeicher durch.

Für unsere Kernprodukte gibt es Kontrollen zur Funktionstrennung, die unter anderem Folgendes beinhalten:

• Überprüfungen von Zugriffskontrollen
• Von HR-Anwendungen verwaltete Sicherheitsgruppen
• Genehmigung/Peer-Review/Implementierung von Änderungen (PRGB)
• Workflow-Kontrollen

6.04.01. (d)

Gibt es Rollen mit hochrangigen Berechtigungen, die alle einer Person zugewiesen sind? Verstößt diese Zuweisung gegen die Regeln der Funktionstrennung oder des geringstprivilegierten Zugriffs?

Atlassian beschränkt weiterhin die Mitarbeiter, die diesen Zugriff für ihre berufliche Rolle und ihre Aufgaben benötigen. Alle Tier-1-Systeme werden über die zentrale Single-Sign-On (SSO)- und Verzeichnislösung von Atlassian verwaltet. Benutzer erhalten auf der Grundlage dieser Profile angemessene Zugriffsrechte, die über Workflow aus unserem Personalverwaltungssystem gesteuert werden. Atlassian nutzt MFA für den Zugriff auf alle Tier-1-Systeme. Wir haben die Zwei-Faktor-Authentifizierung für die Hypervisor-Managementkonsole und die AWS-API sowie einen täglichen Auditbericht über den gesamten Zugriff auf die Hypervisor-Verwaltungsfunktionen aktiviert. Die Zugriffslisten für die Hypervisor-Managementkonsole und die AWS-API werden vierteljährlich überprüft. Wir führen außerdem eine 8-stündige Synchronisation zwischen unserem HR-System und unserem Identitätsspeicher durch.

Für unsere Kernprodukte gibt es Kontrollen zur Funktionstrennung, die unter anderem Folgendes beinhalten:

• Überprüfungen von Zugriffskontrollen
• Von HR-Anwendungen verwaltete Sicherheitsgruppen
• Genehmigung/Peer-Review/Implementierung von Änderungen (PRGB)
• Workflow-Kontrollen

6.04.01. (e)

Verwendest du die rollenbasierte Zugriffskontrolle (RBAC)? Wird das Prinzip der geringsten Berechtigungen befolgt?

Atlassian hat einen etablierten Workflow, der unser HR-Managementsystem mit unserem Zugriffsbereitstellungssystem verbindet. Wir verwenden eine rollenbasierte Zugriffskontrolle, die auf vordefinierten Benutzerprofilen basiert. Alle Benutzerkonten müssen vom Management genehmigt werden, bevor sie Zugriff auf Daten, Anwendungen, Infrastruktur oder Netzwerkkomponenten erhalten.

Atlassian vergibt nur die geringstmöglichen Berechtigungen, die Mitarbeiter benötigen, um zur Ausübung ihrer Tätigkeiten Zugriff auf unsere Systeme, Anwendungen und Infrastruktur zu erhalten. Dieses Prinzip wird durch unser Authentifizierungsverfahren durchgesetzt.

6.04.01. (f)

Welche Änderungen werden ggf. an Administratorberechtigungen und -rollen vorgenommen, um in Notfällen außerordentlichen Zugriff zu gewähren?

Unser globales Support-Team unterhält für Wartungs- und Support-Zwecke ein Konto auf allen gehosteten Systemen und Anwendungen. Der Zugriff auf die gehosteten Anwendungen und Daten erfolgt zur Überwachung der Anwendungsfunktionen und zur System- und Anwendungswartung oder nach Kundenanfrage über unser Supportsystem.

6.04.01. (g)

Gibt es eine "Administrator"-Rolle für den Kunden? Ist der Kundenadministrator zum Beispiel am Hinzufügen neuer Benutzer beteiligt (ohne jedoch den zugrundeliegenden Speicher ändern zu können)?

Atlassian stellt Kunden die Rolle „Organisationsadministrator“ bereit, mit der Benutzer und Gruppen für die Produkte des Kunden verwaltet werden. Weitere Informationen findest du unter: https://support.atlassian.com/user-management/docs/give-users-admin-permissions/

6.04.02. (a)

Wie wird die Identität von Benutzerkonten bei der Registrierung überprüft? Welche Standards werden eingehalten? Zum Beispiel das E-Government-Interoperabilitäts-Framework?

• Gibt es je nach den benötigten Ressourcen unterschiedliche Stufen der Identitätsprüfung?

Weltweit werden neue Atlassian-Mitarbeiter einer Hintergrundüberprüfung unterzogen. Bei neu eingestellten Mitarbeitern infolge einer Übernahme wird nach dem Datum der Übernahme eine Hintergrundüberprüfung durchgeführt. Bei allen neuen Mitarbeitern und unabhängigen Auftragnehmern wird eine Prüfung auf Vorstrafen durchgeführt. Eine Überprüfung der Ausbildung, der bisherigen Beschäftigung oder Bonitätsprüfungen erfolgt zusätzlich, wenn die Position oder das Niveau der Position dies erfordern. Wir führen vollständige Hintergrundüberprüfungen für Führungspositionen und Buchhaltungspositionen durch.

Atlassian hat einen etablierten Workflow, der unser HR-Managementsystem mit unserem Zugriffsbereitstellungssystem verbindet. Wir verwenden eine rollenbasierte Zugriffskontrolle, die auf vordefinierten Benutzerprofilen basiert. Alle Benutzerkonten müssen vom Management genehmigt werden, bevor sie Zugriff auf Daten, Anwendungen, Infrastruktur oder Netzwerkkomponenten erhalten.

6.04.02. (b)

Wie werden Zugangsdaten wieder entzogen?

Derzeit entziehen wir Zugangsdaten bei der Kündigung des Arbeitsverhältnisses, des Vertrags oder der Vereinbarung. Bei einem internen Stellenwechsel behalten Benutzer in der Regel ihre Zugriffsrechte, um laufende Arbeiten und Support nicht zu beeinträchtigen. Um reaktionsschnell, flexibel und kundenorientiert arbeiten zu können, liegt unser Fokus im Einklang mit unseren Unternehmenswerten darauf, unbefugte Zugriffe zu erkennen, anstatt den Zugriff einzuschränken, was unsere Reaktionsfähigkeit beeinträchtigen könnte.

6.04.02. (c)

Werden Zugangsdaten im gesamten Cloud-System gleichzeitig bereitgestellt und entzogen, oder besteht ein Risiko, wenn sie an mehreren geografisch verteilten Standorten entzogen werden?

Atlassian hat einen etablierten Workflow, der unser HR-Managementsystem mit unserem Zugriffsbereitstellungssystem verbindet. Wir verwenden eine rollenbasierte Zugriffskontrolle, die auf vordefinierten Benutzerprofilen basiert. Alle Benutzerkonten müssen vom Management genehmigt werden, bevor sie Zugriff auf Daten, Anwendungen, Infrastruktur oder Netzwerkkomponenten erhalten.

Unsere HR-Anwendung wird alle 8 Stunden mit unserem internen Identitätsspeicher synchronisiert, wodurch alle Konten von Mitarbeitern oder Auftragnehmern entfernt werden, die nicht mehr angestellt sind.

6.04.03. (a)

Welche Datenspeicher- und Schutzkontrollen gelten für das Benutzerverzeichnis (z. B. AD, LDAP) und den Zugriff darauf?

Daten werden gemäß unserer Richtlinie für Information Lifecycle Management und Datensicherheit und den darauf aufbauenden Kontrollen klassifiziert und behandelt.

Weitere Informationen findest du unter: https://www.atlassian.com/trust/security/security-practices

Alle Systeme und Projekte werden einer Bewertung der Auswirkungen hinsichtlich personenbezogener Daten unterzogen. Unsere Drittanbietervereinbarungen beinhalten entsprechende Sicherheits- und Datenschutzbestimmungen. Neue Anbieter von Atlassian müssen unseren Datenschutz- und Sicherheitsrichtlinien in unseren Verträgen zustimmen.

Zahlreiche Produkte von Atlassian sind ISO-zertifiziert, was regelmäßige Risikobewertungen und Überprüfungen des Umgangs mit Daten erfordert.

Unsere Folgenabschätzung für die Datenübertragung findest du unter: https://www.atlassian.com/legal/data-transfer-impact-assessment

Atlassian unterhält einen Standard zur Aufbewahrung und Vernichtung von Daten, der festlegt, wie lange wir Daten verschiedener Arten aufbewahren müssen. Daten werden gemäß unserer Atlassian-Richtlinie für Datensicherheit und Information Lifecycle Management und den darauf aufbauenden Kontrollen klassifiziert.

Was Kundendaten betrifft, so werden bei Kündigung eines Atlassian-Vertrags die Daten eines Kundenteams aus der Live-Produktionsdatenbank entfernt. Alle direkt auf Atlassian hochgeladenen Dateianhänge werden innerhalb von 14 Tagen entfernt. Die Daten des Teams verbleiben in verschlüsselten Backups, bis das 90-tägige Aufbewahrungsfenster für diese Backups überschritten ist und sie gemäß unserer Atlassian-Datenspeicherungsrichtlinie vernichtet werden. Für den Fall, dass innerhalb von 90 Tagen nach einer angeforderten Datenlöschung eine Datenbankwiederherstellung erforderlich ist, wird das Betriebsteam die Daten so schnell wie möglich erneut löschen, nachdem das Live-Produktionssystem vollständig wiederhergestellt ist. Weitere Informationen findest du unter: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/

6.04.03. (b)

Sind Benutzerverzeichnisdaten in einem interoperablen Format exportierbar?

Admins können das Benutzerverzeichnis im Admin-Bereich exportieren. Anleitungen sind auf der folgenden Atlassian Support-Website verfügbar: https://support.atlassian.com/organization-administration/docs/export-users-from-a-site/

6.04.03. (c)

Gewährt der Cloud-Anbieter Zugriff auf Kundendaten nach dem Need-to-know-Prinzip?

Atlassian beschränkt weiterhin die Mitarbeiter, die diesen Zugriff für ihre berufliche Rolle und ihre Aufgaben benötigen. Alle Tier-1-Systeme werden über die zentrale Single-Sign-On (SSO)- und Verzeichnislösung von Atlassian verwaltet. Benutzer erhalten auf der Grundlage dieser Profile angemessene Zugriffsrechte, die über Workflow aus unserem Personalverwaltungssystem gesteuert werden. Atlassian nutzt MFA für den Zugriff auf alle Tier-1-Systeme. Wir haben die Zwei-Faktor-Authentifizierung für die Hypervisor-Managementkonsole und die AWS-API sowie einen täglichen Auditbericht über den gesamten Zugriff auf die Hypervisor-Verwaltungsfunktionen aktiviert. Die Zugriffslisten für die Hypervisor-Managementkonsole und die AWS-API werden vierteljährlich überprüft. Wir führen außerdem eine 8-stündige Synchronisation zwischen unserem HR-System und unserem Identitätsspeicher durch.

Für unsere Kernprodukte gibt es Kontrollen zur Funktionstrennung, die unter anderem Folgendes beinhalten:

• Überprüfungen von Zugriffskontrollen
• Von HR-Anwendungen verwaltete Sicherheitsgruppen
• Genehmigung/Peer-Review/Implementierung von Änderungen (PRGB)
• Workflow-Kontrollen

6.04.04.

Für Schlüssel, die vom Cloud-Anbieter kontrolliert werden:

6.04.04. (a)

Gibt es Sicherheitskontrollen zum Lesen und Schreiben dieser Schlüssel? Zum Beispiel strenge Passwortrichtlinien, Schlüssel, die in einem separaten System gespeichert sind, Hardware-Sicherheitsmodule (HSM) für Stammzertifikatsschlüssel, Smartcard-basierte Authentifizierung, direkter abgeschirmter Speicherzugriff, kurze Schlüssellebensdauer usw.

Atlassian verfügt über Richtlinien zu Verschlüsselung und Kryptografie sowie zur Implementierung. Diese Richtlinien werden jährlich im Einklang mit unserem Policy Management Program (PMP) überprüft und aktualisiert. Weitere Informationen findest du unter: https://www.atlassian.com/trust/security/security-management-program.

Atlassian nutzt dokumentierte Schlüsselmanagementverfahren für die Cloud-Infrastruktur. Verschlüsselungsschlüssel für Amazon-Anhänge, die in S3 gespeichert sind, werden von Amazon KMS verwaltet. Der Verschlüsselungs-, Entschlüsselungs- und Schlüsselmanagementprozess wird im Rahmen des bestehenden Audit-Prozesses bei AWS regelmäßig untersucht und verifiziert. Die von Atlassian verwalteten Schlüssel werden bei maßgeblichen Änderungen der Rolle oder des Beschäftigungsstatus von Mitarbeitern geändert. Der AWS KMS-Service ist konform mit SOC 1, SOC 2, SOC 3. Weitere Informationen findest du unter: https://aws.amazon.com/kms/

6.04.04. (b)

Gibt es Sicherheitskontrollen für die Verwendung dieser Schlüssel zum Signieren und Verschlüsseln von Daten?

Atlassian nutzt dokumentierte Schlüsselmanagementverfahren für die Cloud-Infrastruktur. Verschlüsselungsschlüssel für Amazon-Anhänge, die in S3 gespeichert sind, werden von Amazon KMS verwaltet. Der Verschlüsselungs-, Entschlüsselungs- und Schlüsselmanagementprozess wird im Rahmen des bestehenden Audit-Prozesses bei AWS regelmäßig untersucht und verifiziert. Hauptschlüssel innerhalb von KMS aktivieren bei der Erstellung eine automatische Rotation, um Hauptschlüsselmaterial alle 365 Tage (jährlich) zu generieren.

6.04.04. (c)

Welche Verfahren greifen bei kompromittierten Schlüsseln? Zum Beispiel Schlüsselsperrlisten.

Atlassian nutzt dokumentierte Schlüsselmanagementverfahren für die Cloud-Infrastruktur. Verschlüsselungsschlüssel für Amazon-Anhänge, die in S3 gespeichert sind, werden von Amazon KMS verwaltet. Der Verschlüsselungs-, Entschlüsselungs- und Schlüsselmanagementprozess wird im Rahmen des bestehenden Audit-Prozesses bei AWS regelmäßig untersucht und verifiziert. Die von Atlassian verwalteten Schlüssel werden bei maßgeblichen Änderungen der Rolle oder des Beschäftigungsstatus von Mitarbeitern geändert. Der AWS-KMS-Service ist konform mit SOC 1, SOC 2, SOC 3. Weitere Informationen findest du unter: https://aws.amazon.com/kms/

6.04.04. (c)

Welche Verfahren greifen bei kompromittierten Schlüsseln? Zum Beispiel Schlüsselsperrlisten.

Atlassian nutzt dokumentierte Schlüsselmanagementverfahren für die Cloud-Infrastruktur. Verschlüsselungsschlüssel für Amazon-Anhänge, die in S3 gespeichert sind, werden von Amazon KMS verwaltet. Der Verschlüsselungs-, Entschlüsselungs- und Schlüsselmanagementprozess wird im Rahmen des bestehenden Audit-Prozesses bei AWS regelmäßig untersucht und verifiziert. Die von Atlassian verwalteten Schlüssel werden bei maßgeblichen Änderungen der Rolle oder des Beschäftigungsstatus von Mitarbeitern geändert. Der AWS-KMS-Service ist konform mit SOC 1, SOC 2, SOC 3. Weitere Informationen findest du unter: https://aws.amazon.com/kms/

6.04.04. (d)

Kann die Schlüsselsperre Probleme mit der Gleichzeitigkeit bei mehreren Sites lösen?

Atlassian nutzt dokumentierte Schlüsselmanagementverfahren für die Cloud-Infrastruktur. Verschlüsselungsschlüssel für Amazon-Anhänge, die in S3 gespeichert sind, werden von Amazon KMS verwaltet. Der Verschlüsselungs-, Entschlüsselungs- und Schlüsselmanagementprozess wird im Rahmen des bestehenden Audit-Prozesses bei AWS regelmäßig untersucht und verifiziert. Die von Atlassian verwalteten Schlüssel werden bei maßgeblichen Änderungen der Rolle oder des Beschäftigungsstatus von Mitarbeitern geändert. Der AWS-KMS-Service ist konform mit SOC 1, SOC 2, SOC 3. Weitere Informationen findest du unter: https://aws.amazon.com/kms/

6.04.04. (e)

Werden System-Images der Kunden geschützt oder verschlüsselt?

Atlassian verwendet den Industriestandard Transport Layer Security ("TLS") Version 1.2, um eine sichere Verbindung mithilfe der 256-Bit-Verschlüsselung Advanced Encryption Standard ("AES") herzustellen. Server mit Benutzerdaten verwenden die AES-Verschlüsselung nach Branchenstandard. Mandantendaten werden in den AWS-RDS- oder RDS-Backups verschlüsselt und sind auch im Langzeitspeicher (S3) sowie in allen Anhängen verschlüsselt. Weitere Informationen findest du unter: https://www.atlassian.com/trust/security/security-practices#encryption-and-key-management

Alle Kundendaten, die in Atlassian Cloud-Produkten und -Services 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.

Datenlaufwerke auf Servern, auf denen Kundendaten und Anhänge in Jira Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie und Trello gespeichert sind, verwenden im Ruhezustand die AES-256-Verschlüsselung nach Branchenstandard.

Im Falle von ruhenden Daten werden vor allem Kundendaten auf Festplatte verschlüsselt, z. B. 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.

6.04.05. (a)

Verschlüsselung kann an mehreren Orten verwendet werden – wo wird sie verwendet?

• Daten bei der Übertragung?
• Daten im Ruhezustand?
• Daten im Prozessor oder Speicher?

Atlassian verfügt über Richtlinien zu Verschlüsselung und Kryptografie sowie zur Implementierung. Diese Richtlinien werden jährlich im Einklang mit unserem Policy Management Program (PMP) überprüft und aktualisiert. Weitere Informationen findest du unter: https://www.atlassian.com/trust/security/security-management-program .

Atlassian nutzt dokumentierte Schlüsselmanagementverfahren für die Cloud-Infrastruktur. Verschlüsselungsschlüssel für Amazon-Anhänge, die in S3 gespeichert sind, werden von Amazon KMS verwaltet. Der Verschlüsselungs-, Entschlüsselungs- und Schlüsselmanagementprozess wird im Rahmen des bestehenden Audit-Prozesses bei AWS regelmäßig untersucht und verifiziert. Die von Atlassian verwalteten Schlüssel werden bei maßgeblichen Änderungen der Rolle oder des Beschäftigungsstatus von Mitarbeitern geändert.

Alle Kundendaten, die in Atlassian Cloud-Produkten und -Services 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.

Datenlaufwerke auf Servern, auf denen Kundendaten und Anhänge in Jira Software Cloud, Jira Service Desk Cloud, Jira Core Cloud, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie und Trello gespeichert sind, verwenden im Ruhezustand die AES-256-Verschlüsselung nach Branchenstandard.

Im Falle von ruhenden Daten werden vor allem Kundendaten auf Festplatte verschlüsselt, z. B. 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.

6.04.05. (b)

Gibt es eine klar definierte Richtlinie dafür, was verschlüsselt werden sollte und was nicht?

Atlassian verfügt über Richtlinien zu Verschlüsselung und Kryptografie sowie zur Implementierung. Diese Richtlinien werden jährlich im Einklang mit unserem Policy Management Program (PMP) überprüft und aktualisiert. Weitere Informationen findest du unter: https://www.atlassian.com/trust/security/security-management-program.

Atlassian nutzt dokumentierte Schlüsselmanagementverfahren für die Cloud-Infrastruktur. Verschlüsselungsschlüssel für Amazon-Anhänge, die in S3 gespeichert sind, werden von Amazon KMS verwaltet. Der Verschlüsselungs-, Entschlüsselungs- und Schlüsselmanagementprozess wird im Rahmen des bestehenden Audit-Prozesses bei AWS regelmäßig untersucht und verifiziert. Die von Atlassian verwalteten Schlüssel werden bei maßgeblichen Änderungen der Rolle oder des Beschäftigungsstatus von Mitarbeitern geändert.

6.04.05. (d)

Wer besitzt die Zugriffsschlü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 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.

6.04.05. (e)

Wie werden die Schlüssel geschützt?

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.

6.04.06. (a)

Welche Formen der Authentifizierung werden für Vorgänge verwendet, die eine hohe Sicherheit erfordern? Dazu können die Anmeldung bei Verwaltungsschnittstellen, die Erstellung von Schlüsseln, der Zugriff auf mehrere Benutzerkonten, Firewall-Konfiguration, Fernzugriff usw. gehören.

• Wird die Zwei-Faktor-Authentifizierung verwendet, um kritische Komponenten innerhalb der Infrastruktur wie Firewalls usw. zu verwalten?

Wir folgen den Richtlinien, die in der NIST Special Publication 800-63B beschrieben sind. Siehe https://pages.nist.gov/800-63-3/sp800-63b.html

Das Verfahren zur Zuweisung von Passwörtern ist in der Atlassian-Passwortrichtlinie geregelt. Neue Passwörter werden nicht elektronisch übermittelt, außer in Fällen, in denen ein erstes Einmalpasswort gesendet wird. In diesen Fällen wird der Benutzer gezwungen, das Einmalpasswort bei der ersten Verwendung zu ändern.

Im Allgemeinen werden Kontrollen in Zusammenhang mit der Zugriffskontrolle in der Richtlinie zum Zugriffsmanagement behandelt, die hier verfügbar ist: https://www.atlassian.com/trust/security/ismp-policies

Atlassian vergibt nur die geringstmöglichen Berechtigungen, die Mitarbeiter benötigen, um zur Ausübung ihrer Tätigkeiten Zugriff auf unsere Systeme, Anwendungen und Infrastruktur zu erhalten. Dieses Prinzip wird durch unser Authentifizierungsverfahren durchgesetzt. Jeglicher Zugriff erfolgt über authentifizierte Sitzungen und basiert auf festgelegten Berechtigungen.

Atlassian beschränkt weiterhin die Mitarbeiter, die diesen Zugriff für ihre berufliche Rolle und ihre Aufgaben benötigen. Alle Tier-1-Systeme werden über die zentrale Single-Sign-On (SSO)- und Verzeichnislösung von Atlassian verwaltet. Benutzer erhalten auf der Grundlage dieser Profile angemessene Zugriffsrechte, die über Workflow aus unserem Personalverwaltungssystem gesteuert werden. Atlassian nutzt MFA für den Zugriff auf alle Tier-1-Systeme. Wir haben die Zwei-Faktor-Authentifizierung für die Hypervisor-Managementkonsole und die AWS-API sowie einen täglichen Auditbericht über den gesamten Zugriff auf die Hypervisor-Verwaltungsfunktionen aktiviert. Die Zugriffslisten für die Hypervisor-Managementkonsole und die AWS-API werden vierteljährlich überprüft. Wir führen außerdem eine 8-stündige Synchronisation zwischen unserem HR-System und unserem Identitätsspeicher durch.

6.04.07. (a)

Bietest du eine Anomalieerkennung an (die Fähigkeit zum Erkennen von ungewöhnlichem und potenziell bösartigem IP-Datenverkehr und Benutzer- oder Support-Team-Verhalten)? Beispielweise eine Analyse fehlgeschlagener und erfolgreicher Anmeldungen, ungewöhnlicher Tageszeiten, mehrerer Anmeldungen usw.

Unsere Atlassian Cloud-Plattform bietet nur sehr wenig Angriffsfläche. Wir überprüfen unsere Firewall-Regeln regelmäßig. Wir haben IDS an unseren Bürostandorten und in unserer Cloud-Hosting-Umgebung bereitgestellt. Für die Atlassian Cloud-Plattform ist die Protokollweiterleitung in eine Plattform für Sicherheitsanalysen integriert. Die Dateiintegrität auf Container-Ebene der Cloud-Plattform wird dadurch gewahrt, dass die Instanzen nicht modifizierbar sind. Atlassian Network Engineering verwendet IPS-Technologien, die in unsere Firewalls integriert sind, und wir haben IDS-Technologien in unseren Büro- und Cloud-Umgebungen implementiert. DDoS-Funktionen werden von unserem Internetanbieter/-betreiber bereitgestellt.

Wichtige Systemprotokolle werden von jedem System an eine zentrale Protokollplattform weitergeleitet, auf der Protokolle schreibgeschützt sind. Das Atlassian-Sicherheitsteam erstellt Warnmeldungen auf unserer Plattform für Sicherheitsanalysen (Splunk) 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.

6.04.07. (b)

Welche Bestimmungen gelten für den Fall eines Diebstahls der Anmeldedaten eines Kunden (Erkennung, Sperre, Nachweis für Handlungen)?

Bei den Atlassian Cloud-Services sind unsere Kunden möglicherweise für einige oder alle Aspekte der Zugriffsverwaltung für ihre Servicebenutzer verantwortlich, die unter ihrer Kontrolle stehen.

Dementsprechend ermöglicht Atlassian unseren Kunden, den Zugriff von Servicebenutzern unter der Kontrolle des Servicekunden zu verwalten, z. B. indem Administratorrechte zur Verwaltung oder Beendigung des Zugriffs gewährt werden. Atlassian überprüft auch die Anmeldedaten der Kunden anhand von Datenbanken mit durchgesickerten Anmeldedaten und zwingt die Benutzer, ihr Passwort zu aktualisieren.

Atlassian bietet Data Loss Prevention (DLP) nicht direkt im Rahmen von Cloud-Deployments an. Es gibt jedoch Anbieter im Atlassian Marketplace wie Nightfall, die Atlassian Kunden empfiehlt, die diese DLP-Funktion wünschen. Sieh dir die Marketplace-Produktseite für Nightfall hier an: https://marketplace.atlassian.com/vendors/1217783/nightfall. Nightfall beinhaltet das automatische Scannen vertraulicher Informationen, einschließlich Anmeldedaten, geheimer Werte und API-Schlüsseln.

Atlassian hat Beacon veröffentlicht, das sich in der Betaphase befindet und DLP-Funktionen hinzufügt. Bis zur Veröffentlichung der finalen Version von Beacon empfiehlt Atlassian weiterhin Nightfall. Weitere Informationen zu Atlassian Beacon findest du unter: https://www.atlassian.com/software/beacon.

Wir haben eine dokumentierte Richtlinie und einen Plan zur Security Incident Response, zu deren wichtigsten Prinzipien folgende gehören:

• Antizipieren von Sicherheitsvorfällen und Vorbereitung auf die Incident Response
• Eindämmung und Beseitigung von Vorfällen und anschließende Wiederherstellung
• Investition in Mitarbeiter, Prozesse und Technologien, um sicherzustellen, dass auftretende Sicherheitsvorfälle erkannt und analysiert werden können
• Der Schutz personenbezogener Daten und Kundendaten hat bei Sicherheitsvorfällen oberste Priorität.
• Regelmäßige Testläufe des Prozesses zur Incident Response
• Erlernen und Verbesserung der Funktion für das Management von Sicherheitsvorfällen
• Wir melden kritische Sicherheitsvorfälle dem Führungsteam von Atlassian.

6.04.08.

Die folgenden Fragen beziehen sich auf die Identitäts- und Zugriffsmanagementsysteme, die vom Cloud-Anbieter zur Nutzung und Kontrolle durch den Cloud-Kunden angeboten werden.

6.04.08.01. (a)

Unterstützt das System eine föderierte IDM-Infrastruktur, die sowohl für hohe Sicherheit (OTP-Systeme, falls erforderlich) als auch für niedrige Sicherheit (z. B. Benutzername und Passwort) verwendet werden kann?

Atlassian Access unterstützt Identitätsverbundstandards für sämtliche Atlassian-Produkte (Confluence, Jira, Jira Align, Bitbucket usw.). Atlassian Access kann dein Active Directory mit Okta, Azure AD oder OneLogin automatisch mit Atlassian synchronisieren. Weitere Informationen findest du unter https://www.atlassian.com/enterprise/cloud/access. SSO-Einrichtung für spezifische Produkte (Generic SAML v2.0, Google, Okta, OneLogin, PingIdentity, ADFS):

• Opsgenie unterstützt mehrere SSO-Anbieter. Weitere Informationen findest du unter: https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/
• Trello unterstützt mehrere SSO-Anbieter. Weitere Informationen findest du unter: https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization
• Statuspage unterstützt mehrere SSO-Anbieter. Weitere Informationen findest du unter: https://help.statuspage.io/knowledge_base/categories/single-sign-on-2

6.04.08.01. (b)

Ist der Cloud-Anbieter mit externen Identitätsanbietern kompatibel?

Atlassian-Kunden können einen externen Identitätsanbieter ihrer Wahl verwenden, sofern dieser von Atlassian unterstützt wird. Näheres zu diesen Funktionen sowie eine Anleitung zur Einbindung deines Identitätsanbieters findest du auf der folgenden Atlassian Support-Seite: https://support.atlassian.com/provisioning-users/docs/supported-identity-providers/

6.04.08.01. (c)

Gibt es die Möglichkeit, Single-Sign-On zu integrieren?

Atlassian unterstützt die Verwendung von Google-, Microsoft- und Apple-Identitäten zur Authentifizierung der meisten Produkte. Wir unterstützen auch SAML für unsere Atlassian Cloud-Services über Atlassian Access. Siehe: https://www.atlassian.com/enterprise/cloud/access.

6.04.08.02. (a)

Erlaubt das Client-Anmeldedatensystem die Trennung von Rollen und Verantwortlichkeiten sowie mehrere Domains (oder wird für mehrere Domains, Rollen und Verantwortlichkeiten ein einziger Schlüssel verwendet)?

Atlassian ist eine mehrmandantenfähige SaaS-Anwendung. Mehrmandantenfähigkeit ist eine wichtige Funktion von Atlassian Cloud, die es mehreren Kunden ermöglicht, eine Instanz der Jira- oder Confluence-Anwendungsebene gemeinsam zu nutzen, wobei die Anwendungsdaten ihres jeweiligen Mandanten isoliert werden. Atlassian Cloud erreicht dies durch den Tenant Context Service (TCS). Jede Benutzer-ID ist mit genau einem Mandanten verknüpft, der dann für den Zugriff auf die Atlassian Cloud-Anwendungen verwendet wird. Weitere Informationen findest du hier: https://www.atlassian.com/trust/security/security-practices#tenant-isolation

Kunden unserer Enterprise- und Premium-Cloud-Angebote haben Zugriff auf einen zentralen Administrationsbereich. Die Admins deiner Organisation können den Benutzerzugriff und die Berechtigungen für all deine Produktinstanzen verwalten. Siehe hierzu unseren Blogpost: https://www.atlassian.com/blog/platform/cloud-enterprise-centralized-admin-controls.

Atlassian stellt Kunden die Rolle "Organisationsadministrator" bereit, mit der Benutzer und Gruppen für die Produkte des Kunden verwaltet werden. Weitere Informationen findest du unter: https://support.atlassian.com/user-management/docs/give-users-admin-permissions/

6.04.08.02. (b)

Wie wird der Zugriff auf System-Images der Kunden verwaltet – und sichergestellt, dass die Authentifizierungs- und kryptografischen Schlüssel nicht darin enthalten sind?

Unser globales Support-Team unterhält für Wartungs- und Support-Zwecke ein Konto auf allen gehosteten Systemen und Anwendungen. Der Zugriff auf die gehosteten Anwendungen und Daten erfolgt zur Überwachung der Anwendungsfunktionen und zur System- und Anwendungswartung oder nach Kundenanfrage über unser Supportsystem.

6.04.08.03. (a)

Wie identifiziert sich der Cloud-Anbieter gegenüber dem Kunden (d. h. gibt es eine gegenseitige Authentifizierung)?

• Wann sendet der Kunde API-Befehle?
• Wann meldet sich der Kunde bei der Verwaltungsschnittstelle an?

Atlassian nutzt die gegenseitige Authentifizierung, um sich gegenüber dem Kunden zu identifizieren. Eine Atlassian-API-Dokumentation findest du hier: https://developer.atlassian.com/cloud/. Das ASAP (Atlassian Service Authentication Protocol) ist ein Service-to-Service-Authentifizierungsprotokoll, das Zugriffstoken verwendet, die mit JSON-Web-Token (JWT) implementiert und mit einem RSA-Schlüssel von einer vertrauenswürdigen Atlassian-Instanz signiert wurden. Weitere Informationen findest du unter im Atlassian Service Authentication Protocol. Wir verwenden keine traditionellen Begriffe wie "Servicekonten". Wir verlassen uns auf die Service-to-Service-Authentifizierung und -Autorisierung.

6.04.08.03. (b)

Wird ein Verbundmechanismus für die Authentifizierung unterstützt?

Atlassian Access unterstützt Identitätsverbundstandards für sämtliche Atlassian-Produkte (Confluence, Jira, Jira Align, Bitbucket usw.). Atlassian Access kann dein Active Directory mit Okta, Azure AD oder OneLogin automatisch mit Atlassian synchronisieren. Weitere Informationen findest du unter https://www.atlassian.com/enterprise/cloud/access. SSO-Einrichtung für spezifische Produkte (Generic SAML v2.0, Google, Okta, OneLogin, PingIdentity, ADFS):

• Opsgenie unterstützt mehrere SSO-Anbieter. Weitere Informationen findest du unter: https://support.atlassian.com/opsgenie/docs/configure-sso-for-opsgenie/
• Trello unterstützt mehrere SSO-Anbieter. Weitere Informationen findest du unter: https://help.trello.com/article/1224-linking-a-trello-enterprise-to-an-atlassian-organization
• Statuspage unterstützt mehrere SSO-Anbieter. Weitere Informationen findest du unter: https://help.statuspage.io/knowledge_base/categories/single-sign-on-2

6.05.

Es ist wichtig sicherzustellen, dass der Anbieter eine aktuelle Liste von Hardware- und Software-Assets (Anwendungen) unterhält, die der Kontrolle des Cloud-Anbieters unterliegen. Dadurch kann überprüft werden, ob auf allen Systemen angemessene Kontrollen eingesetzt werden, und sichergestellt werden, dass Systeme nicht als Hintertür in die Infrastruktur verwendet werden können.

6.05. (a)

Verfügt der Anbieter über ein automatisiertes Mittel zur Inventarisierung aller Assets, um deren angemessene Verwaltung zu ermöglichen?

Unsere Produktionssysteme befinden sich in einer von Cloud-Serviceanbietern bereitgestellten Infrastruktur. Aufgrund ihrer Beschaffenheit ist keine Nachverfolgung der Services auf Hardwareebene möglich. Stattdessen werden die unseren Produkten zugrunde liegenden Microservices in einer benutzerdefinierten "Service"-Datenbank nachverfolgt. Diese Datenbank wird automatisch aktualisiert, wenn ein Service bereitgestellt wird.

Unser Workplace-Technologieteam führt einen Asset-Bestand aller Endpunkte. Dabei wird unsere eigene Jira Software für die Nachverfolgung eingesetzt.

6.05. (b)

Gibt es eine Liste von Assets, die der Kunde über einen bestimmten Zeitraum genutzt hat?

Atlassian ist eine mehrmandantenfähige SaaS-Anwendung. Mehrmandantenfähigkeit ist eine wichtige Funktion von Atlassian Cloud, die es mehreren Kunden ermöglicht, eine Instanz der Jira- oder Confluence-Anwendungsebene gemeinsam zu nutzen, wobei die Anwendungsdaten ihres jeweiligen Mandanten isoliert werden. Atlassian Cloud erreicht dies durch den Tenant Context Service (TCS). Jede Benutzer-ID ist mit genau einem Mandanten verknüpft, der dann für den Zugriff auf die Atlassian Cloud-Anwendungen verwendet wird. Weitere Informationen findest du unter: https://www.atlassian.com/trust/security/security-practices#tenant-isolation

Die folgenden Fragen sind zu verwenden, wenn Endkunden Daten bereitstellen, die zusätzlichen Schutz benötigen würden (z. B. wenn sie als vertraulich betrachtet werden).

6.05. (c)

Werden Assets nach Vertraulichkeit und Wichtigkeit klassifiziert?

• Nutzt der Anbieter in diesem Fall eine angemessene Trennung zwischen Systemen mit unterschiedlichen Klassifizierungen sowie für einen einzelnen Kunden, der Systeme mit unterschiedlichen Sicherheitsklassifizierungen hat?

Atlassian nutzt ein vierstufiges Rating für unsere Assets und Services, wobei die Anforderungen an Verfügbarkeit, Servicelevel und Kontinuität nach Stufe festgelegt sind. Weitere Informationen findest du unter: https://www.atlassian.com/trust/security/data-management.

6.06.

Anhand dieser Fragen lassen sich die Risiken ermitteln, die mit der Bindung an einen bestimmten Anbieter verbunden sind.

6.06. (a)

Gibt es dokumentierte Verfahren und APIs für den Export von Daten aus der Cloud?

Kundendaten sind über Web-App und API verfügbar. Im Folgenden findest du Einzelheiten zu bestimmten Produkten.

• Confluence und Jira sowie Jira Align: Details zu unserer Atlassian-API findest du unter: https://developer.atlassian.com/cloud/jira/platform/rest/v3/
• Trello: Board-Daten können von Board-Mitgliedern über die REST-API von Trello im JSON-Format exportiert werden. Dateianhänge können einzeln direkt von Amazon S3 über den eindeutigen Hyperlink der Datei abgerufen werden. Die Trello Business Class- und Enterprise-Editionen bieten für alle Organisationsdaten und -anhänge einen vereinfachten Datenexport. Jede Business Class- und Enterprise-Organisation ermöglicht es, Boards innerhalb der Organisation mit einem Klick zu exportieren. Optional können direkt auf Trello hochgeladene Dateianhänge in die Exportdatei aufgenommen werden. Im Export sind die Daten jedes Boards sowohl im JSON-Format als auch im CSV-Format (Comma-Separated Values) enthalten.
• Opsgenie: Die API findest du unter: https://docs.opsgenie.com/docs/api-overview
• Statuspage: Die API findest du unter: https://doers.statuspage.io/api/v1/
• Bitbucket: Jeder Quellcode bzw. jedes Repository kann für Zwecke der Interoperabilität von Bitbucket heruntergeladen oder exportiert werden. Siehe: https://confluence.atlassian.com/bitbucket/does-bitbucket-backup-my-repositories-288658413.html
• Halp: hat eine CSV-Exportfunktion. Weitere Informationen findest du in unserer Dokumentation: https://plz.halp.com/article/5790zlyrun-export-to-csv

6.06. (b)

Stellt der Anbieter interoperable Exportformate für alle in der Cloud gespeicherten Daten bereit?

Atlassian unterstützt Kundenanfragen zum Export ihrer Daten, falls diese auf Atlassian-Produkten gehostet werden. Es stehen robuste Datenportabilitäts- und Datenmanagementtools für den Export von Produkt- und Benutzerdaten zur Verfügung. Weitere Informationen zum Atlassian Cloud-Datenexport findest du in unserer Dokumentation zum Import und Export: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Details zum Exportieren von Daten in gängige Formate wie CSV, HTML und XML findest du hier: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/.

6.06. (c)

Sind die verwendeten API-Schnittstellen im Fall von SaaS standardisiert?

Einzelheiten zu unseren Atlassian Cloud-APIs findest du unter: https://developer.atlassian.com/explore-the-apis/

Details zu den APIs spezifischer Produkte:

• Trello: Die API-Dokumentation ist verfügbar unter: https://developer.atlassian.com/cloud/trello
• Jira Align: Die API findest du unter: https://help.jiraalign.com/hc/en-us/articles/360045371954-Getting-started-with-the-REST-API-2-0
• Statuspage: Die API findest du unter: https://doers.statuspage.io/api/v1
• Opsgenie: Die API findest du unter: https://docs.opsgenie.com/docs/api-overview
• Halp: derzeit keine öffentliche API verfügbar.

6.06. (d)

Besteht die Möglichkeit, von Benutzern erstellte Anwendungen in einem Standardformat zu exportieren?

Nicht zutreffend, da Atlassian ein SaaS-Modell (Software as a Service) betreibt.

6.06. (e)

Gibt es Verfahren, um zu testen, ob Daten zu einem anderen Cloud-Anbieter exportiert werden können, z. B. für den Fall, dass Kunden den Anbieter wechseln möchten?

Atlassian unterstützt Kundenanfragen zum Export ihrer Daten, falls diese auf Atlassian-Produkten gehostet werden. Es stehen robuste Datenportabilitäts- und Datenmanagementtools für den Export von Produkt- und Benutzerdaten zur Verfügung. Weitere Informationen zum Atlassian Cloud-Datenexport findest du in unserer Dokumentation zum Import und Export: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Details zum Exportieren von Daten in gängige Formate wie CSV, HTML und XML findest du hier: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/.

6.06. (f)

Können Kunden ihre eigene Datenextraktion durchführen, um zu überprüfen, ob das Format universell ist und zu einem anderen Cloud-Anbieter migriert werden kann?

Atlassian unterstützt Kundenanfragen zum Export ihrer Daten, falls diese auf Atlassian-Produkten gehostet werden. Es stehen robuste Datenportabilitäts- und Datenmanagementtools für den Export von Produkt- und Benutzerdaten zur Verfügung. Weitere Informationen zum Atlassian Cloud-Datenexport findest du in unserer Dokumentation zum Import und Export: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/.

Details zum Exportieren von Daten in gängige Formate wie CSV, HTML und XML findest du hier: https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/.

6.07.

Die Gewährleistung von Kontinuität spielt für Unternehmen eine wichtige Rolle. Die Mindestverfügbarkeit der Systeme kann in einem Service Level Agreement detailliert festgelegt werden. Es gibt jedoch noch ein paar weitere Überlegungen.

6.07. (a)

Verfügt der Anbieter über eine dokumentierte Methode, die die Auswirkungen einer Unterbrechung beschreibt?

• Welches RPO (Recovery Point Objective) und RTO (Recovery Time Objective) wurden für die Services entsprechend ihrer jeweiligen Wichtigkeit festgelegt?
• Werden im Rahmen des Wiederherstellungsprozesses Maßnahmen zur Informationssicherheit auf angemessene Weise berücksichtigt?
• Welche Kommunikationswege zu Endkunden sind im Falle einer Unterbrechung verfügbar?
• Sind die Rollen und Verantwortlichkeiten der Teams im Falle einer Unterbrechung klar definiert?

Eine Richtlinie für Business Continuity und Disaster Recovery sowie ein Plan für Business Continuity und Disaster Recovery sind vorhanden und werden jährlich vom Lenkungsausschuss für Business Continuity/Disaster Recovery überprüft. Weitere Informationen (auch in Bezug auf RPOs, RTOs und Resilienz durch die Nutzung von Verfügbarkeitszonen) findest du unter: https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management und https://www.atlassian.com/trust/security/data-management.

Unsere Partnerrechenzentren verfügen über mehrere Compliance-Zertifizierungen. Diese Zertifizierungen beziehen sich auf die physische Sicherheit, die Systemverfügbarkeit, den Netzwerk- und IP-Backbone-Zugriff, die Kundenbereitstellung und das Problemmanagement. Der Zugang zu den Rechenzentren ist ausschließlich auf autorisiertes Personal beschränkt und wird durch biometrische Identitätsprüfungen kontrolliert. Vor Ort sorgen außerdem Wachpersonal, Videoüberwachungsanlagen, Zugangsschleusen und weitere Einbruchsschutzmaßnahmen für Sicherheit. Informationen zur Gewährleistung des physischen Schutzes durch AWS findest du unter: http://aws.amazon.com/compliance/

6.07. (b)

Hat der Anbieter die Priorität in Bezug auf die Wiederherstellung kategorisiert? Was wäre in diesem Fall unsere relative Priorität (Endkunden)? Hinweis: Dies kann eine Kategorie sein (HOCH/MITTEL/NIEDRIG).

Besitzer von erfolgskritischen Systemen, Prozessen oder Services müssen im Falle einer Katastrophe und im Rahmen festgelegter Störungstoleranzen eine ordnungsgemäße Business Continuity und/oder Disaster Recovery sicherstellen. Entsprechende Pläne werden vierteljährlich geprüft, um Probleme zu identifizieren und zu beheben. Weitere Informationen findest du unter: https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management und https://www.atlassian.com/trust/security/data-management.

6.07. (c)

Welche Abhängigkeiten sind für den Wiederherstellungsprozess relevant? Dies schließt Lieferanten und externe Partner ein.

Atlassian verfügt über ein Verfahren zur Datenwiederherstellung und hält entsprechende Maßnahmen in einem Protokoll fest. Auf übergeordneter Ebene spiegelt sich dies in unserem internen Standard für Backups und in unseren Richtlinien für Business Continuity und Disaster Recovery wider. Für die einzelnen Services von Atlassian gibt es jedoch verschiedene interne Dokumente, darunter Runbooks, Zeitpläne und Verfahren für vom Kunden initiierte Wiederherstellungen und von Atlassian initiierte Wiederherstellungen.

6.07. (d)

Welche Trennung für den sekundären Standort besteht mindestens, falls der primäre Standort nicht verfügbar ist?

Unsere Partnerrechenzentren verfügen über mehrere Compliance-Zertifizierungen. Diese Zertifizierungen beziehen sich auf die physische Sicherheit, die Systemverfügbarkeit, den Netzwerk- und IP-Backbone-Zugriff, die Kundenbereitstellung und das Problemmanagement. Der Zugang zu den Rechenzentren ist ausschließlich auf autorisiertes Personal beschränkt und wird durch biometrische Identitätsprüfungen kontrolliert. Vor Ort sorgen außerdem Wachpersonal, Videoüberwachungsanlagen, Zugangsschleusen und weitere Einbruchsschutzmaßnahmen für Sicherheit. Informationen zur Gewährleistung des physischen Schutzes durch AWS findest du unter: http://aws.amazon.com/compliance/

6.07.01.

Vorfallmanagement und Incident Response sind Teil des Business Continuity Management. Das Ziel dieses Prozesses besteht darin, die Auswirkungen unerwarteter und potenziell störender Ereignisse auf ein Maß zu begrenzen, das für ein Unternehmen akzeptabel ist. Um zu beurteilen, wie gut ein Unternehmen in der Lage ist, die Wahrscheinlichkeit eines Informationssicherheitsvorfalls zu minimieren bzw. entsprechende negativen Auswirkungen zu reduzieren, sollten einem Cloud-Anbieter die folgenden Fragen gestellt werden:

6.07.01. (a)

Verfügt der Anbieter über ein formelles Verfahren zur Erkennung, Identifizierung, Analyse und Reaktion auf Vorfälle?

Wir haben eine dokumentierte Security Incident Response-Richtlinie und einen entsprechenden Plan mit den folgenden Grundprinzipien:

• Antizipieren von Sicherheitsvorfällen und Vorbereitung auf die Incident Response
• Eindämmung und Beseitigung von Vorfällen und anschließende Wiederherstellung
• Investition in Mitarbeiter, Prozesse und Technologien, um sicherzustellen, dass auftretende Sicherheitsvorfälle erkannt und analysiert werden können
• Der Schutz personenbezogener Daten und Kundendaten hat bei Sicherheitsvorfällen oberste Priorität.
• Regelmäßige Testläufe des Prozesses zur Incident Response
• Erlernen und Verbesserung der Funktion für das Management von Sicherheitsvorfällen
• Wir melden kritische Sicherheitsvorfälle dem Führungsteam von Atlassian.


Gemäß dieser Richtlinie unterhält Atlassian einen Security Incident Response-Plan. Weitere Informationen zu unserem Prozess der Security Incident Response findest du unter: https://www.atlassian.com/trust/security/security-incident-management

Wichtige Systemprotokolle werden von jedem System an eine zentrale Protokollplattform weitergeleitet, auf der Protokolle schreibgeschützt sind. Das Atlassian-Sicherheitsteam erstellt Warnmeldungen auf unserer Plattform für Sicherheitsanalysen (Splunk) 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.

Weitere Informationen zu unserem Detections-Programm findest du unter: https://www.atlassian.com/trust/security/detections-program

6.07.01. (b)

Wurde dieser Prozess geprobt, um die Wirksamkeit der Handhabung von Vorfällen zu testen? Stellt der Cloud-Anbieter während der Probe sicher, dass alle Beteiligten in der Support-Organisation über den Prozess und ihre Rollen bei der Handhabung von Vorfällen informiert sind (sowohl während des Vorfalls als auch nach der Analyse)?

Die Business Continuity- und Disaster Recovery-Pläne für unsere Atlassian Cloud-Services werden mindestens vierteljährlich getestet. Die Verfügbarkeit in mehreren Regionen wird in Echtzeit überwacht. Jede Woche werden in der Vorproduktionsumgebung automatische regionale Failover-Tests durchgeführt. In der Produktionsumgebung werden täglich automatisierte Tests zur Wiederherstellung der Konfigurationsdaten durchgeführt. Alle Atlassian-Services führen für die Verfügbarkeitszonen in der Vorproduktionsumgebung vierteljährlich einen Resilienztest durch. Weitere Informationen zu unserem Business Continuity-Programm findest du unter: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

Unsere Disaster Recovery-Pläne werden von unseren externen Prüfern im Rahmen unseres Compliance-Programms getestet und validiert. Weitere Informationen findest du unter: https://www.atlassian.com/trust/compliance/resources

Wir haben unseren Security Incident Response-Plan durch Live-Vorfallaktivitäten umgesetzt. Wir verfolgen einen Ansatz der kontinuierlichen Verbesserung, um unsere Reaktionsfähigkeit zu optimieren.

Nachdem ein Vorfall mit hohem Schweregrad 1 oder 2 gelöst wurde, wird das ursprüngliche Ticket geschlossen und ein Prozess zur Überprüfung nach dem Vorfall (PIR) eingeleitet. Bei Vorfällen mit hohem Schweregrad führt das Sicherheitsteam eine Ursachenanalyse durch und schlägt mögliche Verbesserungen des Systems und/oder der Behebung des Problems vor.

6.07.01. (c)

Wie sind die Funktionen zur Erkennung strukturiert?

• Wie können Cloud-Kunden dem Anbieter Anomalien und Sicherheitsereignisse melden?
• Auf welche Weise können die vom Kunden ausgewählten RTSM-Services von Drittanbietern, in die Systeme des Anbieters eingreifen (sofern angemessen) oder die Incident Response-Funktionen mit dem Cloud-Anbieter koordinieren?
• Gibt es einen Service für die Echtzeit-Sicherheitsüberwachung (Real Time Security Monitoring RTSM)? Ist dieser Service ausgelagert? Welche Parameter und Services werden überwacht?
• Erstellt der Anbieter (auf Anfrage) regelmäßig einen Bericht über Sicherheitsvorfälle (z. B. gemäß der ITIL-Definition)?
• Wie lange werden die Sicherheitsprotokolle aufbewahrt? Sind diese Protokolle sicher gespeichert? Wer hat Zugriff auf die Protokolle?
• Können Kunden ein HIPS/HIDS im Image des virtuellen Computers erstellen? Ist es möglich, die von ihren Systemen zur Angriffserkennung und -verhinderung gesammelten Informationen in den RTSM-Service des Cloud-Anbieters oder den eines Drittanbieters zu integrieren?

Unsere Atlassian Cloud-Plattform bietet nur sehr wenig Angriffsfläche. Wir überprüfen unsere Firewall-Regeln regelmäßig. Wir haben IDS an unseren Bürostandorten und in unserer Cloud-Hosting-Umgebung bereitgestellt. Für die Atlassian Cloud-Plattform ist die Protokollweiterleitung in eine Plattform für Sicherheitsanalysen integriert. Die Dateiintegrität auf Container-Ebene der Cloud-Plattform wird dadurch gewahrt, dass die Instanzen nicht modifizierbar sind. Atlassian Network Engineering verwendet IPS-Technologien, die in unsere Firewalls integriert sind, und wir haben IDS-Technologien in unseren Büro- und Cloud-Umgebungen implementiert. DDoS-Funktionen werden von unserem Internetanbieter/-betreiber bereitgestellt. Weitere Informationen zu unserem Detections-Programm findest du unter: https://www.atlassian.com/trust/security/detections-program Wichtige Systemprotokolle werden von jedem System an eine zentrale Protokollplattform weitergeleitet, auf der Protokolle schreibgeschützt sind. Das Atlassian-Sicherheitsteam erstellt Warnmeldungen auf unserer Plattform für Sicherheitsanalysen (Splunk) 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. Bei Atlassian dürfen Audit-Protokolle nur von autorisiertem Personal auf unserer zentralen Protokollierungsplattform eingesehen und gelesen werden. Atlassian hält sich außerdem externe Berichtswege offen, über die wir auf Sicherheitsrisiken oder Vorfälle aufmerksam gemacht werden können, zum Beispiel durch unser Bug-Bounty-Programm, unser Kundensupport-Portal und bestimmte E-Mail-Adressen und Telefonnummern für Sicherheitsmeldungen. Atlassian ermutigt Kunden, jeden unautorisierten Zugriff oder böswilliges Verhalten zu melden. Weitere Informationen findest du unter: https://www.atlassian.com/trust/security/security-incident-management und https://www.atlassian.com/trust/security/security-incident-responsibilities.

6.07.01. (d)

Wie werden Schweregrade definiert?

Atlassian nutzt das Common Vulnerability Scoring System (CVSS), um Sicherheitsrisiken auszuwerten und entdeckte Sicherheitslücken zu priorisieren. Die verwendeten Sicherheitsstufen basieren auf dem selbst berechneten CVSS-Score von Atlassian und umfassen folgende Einstufungen:

• Kritisch
• Hoch
• Mittel
• Niedrig


Weitere Informationen, einschließlich der Bewertungsbereiche, die den Schweregrad bestimmen, findest du unter: https://www.atlassian.com/trust/security/security-severity-levels.

6.07.01. (e)

Wie sind Eskalationsverfahren definiert? Wann (wenn überhaupt) ist der Cloud-Kunde beteiligt?

Wir haben eine dokumentierte Security Incident Response-Richtlinie und einen entsprechenden Plan mit den folgenden Grundprinzipien:

• Antizipieren von Sicherheitsvorfällen und Vorbereitung auf die Incident Response
• Eindämmung und Beseitigung von Vorfällen und anschließende Wiederherstellung
• Investition in Mitarbeiter, Prozesse und Technologien, um sicherzustellen, dass auftretende Sicherheitsvorfälle erkannt und analysiert werden können
• Der Schutz personenbezogener Daten und Kundendaten hat bei Sicherheitsvorfällen oberste Priorität.
• Regelmäßige Testläufe des Prozesses zur Incident Response
• Erlernen und Verbesserung der Funktion für das Management von Sicherheitsvorfällen
• Wir melden kritische Sicherheitsvorfälle dem Führungsteam von Atlassian.


Gemäß dieser Richtlinie unterhält Atlassian einen Security Incident Response-Plan. Weitere Informationen zu unserem Prozess der Security Incident Response findest du unter: https://www.atlassian.com/trust/security/security-incident-management

Atlassian weiß, wie wichtig es ist, dass du umgehend über jeden Datenschutzverstoß informiert wirst. Aus diesem Grund hat Atlassian ein umfangreiches funktionsübergreifendes Team und einen Prozess zum Umgang mit Sicherheitsvorfällen eingerichtet. Mehr dazu erfährst du hier: https://www.atlassian.com/trust/security/security-incident-management

Atlassian kann eine lange Erfolgsbilanz vorweisen, wenn es darum geht, Vorfälle rechtzeitig und proaktiv zu melden und in Zusammenarbeit mit unseren Kunden alle notwendigen Abhilfemaßnahmen zu ergreifen.

Da sich die Security Incident Response-Teams von Atlassian sofort im Entstehen eines Vorfalls auf dessen Bewertung und Eindämmung konzentrieren, ist die 72-Stunden-Vorgabe für uns nicht praktikabel. Stattdessen benachrichtigen wir unsere Kunden "unverzüglich", was den rechtlichen Anforderungen für Datenverarbeiter im Rahmen der DSGVO entspricht. Auch die rechtlichen Anforderungen der meisten unserer Kunden werden so erfüllt.

Vorfälle können einfach, aber auch sehr komplex sein. Wir halten uns zwar an die gesetzlichen Anforderungen, können aber keine für alle Vorfälle passenden Zeitangaben machen.

6.07.01. (f)

Wie werden Vorfälle dokumentiert und Nachweise erfasst?

Jira-Tickets werden zu Nachverfolgung und Fehlerbehebung erstellt. Die Fälligkeitsdaten werden gemäß unserem SLO vergeben, basierend sowohl auf dem Schweregrad als auch auf der Quelle der Schwachstelle. Ein fortlaufender Prozess erstellt Tickets für identifizierte Schwachstellen für Systembesitzer. Unser Sicherheitsmanagementteam überprüft alle gemeldeten Schwachstellen und stellt sicher, dass geeignete Maßnahmen zur Behebung ergriffen werden.

Nachdem ein Vorfall mit hohem Schweregrad 1 oder 2 gelöst wurde, wird das ursprüngliche Ticket geschlossen und ein Prozess zur Überprüfung nach dem Vorfall (PIR) eingeleitet. Bei Vorfällen mit hohem Schweregrad führt das Sicherheitsteam eine Ursachenanalyse durch und schlägt mögliche Verbesserungen des Systems und/oder der Behebung des Problems vor.

6.07.01. (g)

Welche weiteren Kontrollen gibt es außer Authentifizierung, Buchhaltung und Audits, um böswillige Aktivitäten von Mitarbeitern zu verhindern (oder deren Auswirkungen zu minimieren)?

Atlassian hat IDS an unseren Bürostandorten und in unserer Cloud-Hosting-Umgebung bereitgestellt. Die Protokollweiterleitung ist in eine Sicherheitsanalysen-Plattform für die Atlassian Cloud-Plattform integriert. Wichtige Systemprotokolle werden von jedem System an eine zentrale Protokollplattform weitergeleitet, auf der Protokolle schreibgeschützt sind. Das Atlassian-Sicherheitsteam erstellt Warnmeldungen auf unserer Plattform für Sicherheitsanalysen (Splunk) und überprüft Anzeichen für Kompromittierungen. Weitere Informationen zu unserem Detections-Programm findest du unter: https://www.atlassian.com/trust/security/detections-program

6.07.01. (h)

Erfasst der Anbieter Kennzahlen und Anzeichen für Vorfälle (d. h. die Anzahl der erkannten und gemeldeten Vorfälle pro Monat, die Anzahl der Vorfälle, die von den Subunternehmern des Cloud-Anbieters verursacht wurden, die Gesamtzahl der Vorfälle, die durchschnittliche Zeit bis zur Reaktion und Behebung usw.)?

• Welche davon macht der Anbieter öffentlich zugänglich?(Hinweis: Nicht alle Daten zur Meldung von Vorfällen können veröffentlicht werden, da dies die Kundenvertraulichkeit gefährden und sicherheitskritische Informationen offenlegen könnte.)

Unsere internen Kennzahlen werden derzeit nicht veröffentlicht. Wir informieren allerdings auf unserer Statuspage über unsere Maßnahmen nach betrieblichen Vorfällen des Schweregrads 0 oder 1: https://status.atlassian.com/.

6.07.01. (j)

Wie oft testet der Anbieter Disaster-Recovery- und Business-Continuity-Pläne?

Die Business Continuity- und Disaster Recovery-Pläne für unsere Atlassian Cloud-Services werden mindestens vierteljährlich getestet. Die Verfügbarkeit in mehreren Regionen wird in Echtzeit überwacht. Jede Woche werden in der Vorproduktionsumgebung automatische regionale Failover-Tests durchgeführt. In der Produktionsumgebung werden täglich automatisierte Tests zur Wiederherstellung der Konfigurationsdaten durchgeführt. Alle Atlassian-Services führen für die Verfügbarkeitszonen in der Vorproduktionsumgebung vierteljährlich einen Resilienztest durch. Weitere Informationen zu unserem Business Continuity-Programm findest du unter: https://www.atlassian.com/trust/security/security-practices#faq-d323ae61-59b8-4ddb-96d4-30716b603e3e

Unsere Disaster Recovery-Pläne werden von unseren externen Prüfern im Rahmen unseres Compliance-Programms getestet und validiert. Weitere Informationen findest du unter: https://www.atlassian.com/trust/compliance/resources

6.07.01. (k)

Erfasst der Anbieter Daten zur Einhaltung von SLAs?

Wir überwachen alle Cloud-Instanzen auf Leistung und Verfügbarkeit, aber bieten derzeit kein formelles SLA für die Anwendungsverfügbarkeit an. Unser Support-Team verfügt über ein SLA zur Erstreaktionszeit. Für die Behebung durch unseren Support gibt es zwar kein offizielles SLA, wir versuchen aber, alle zugewiesenen Fälle innerhalb von 48 Stunden zu beheben. Auf der folgenden Seite informiert Atlassian über Statistiken zu unserem aktuellen Cloud-Systemstatus: https://status.atlassian.com.

Für unsere Premium- und Enterprise-Lösungen bieten wir SLA-Garantien.

6.07.01. (l)

Führt der Anbieter Helpdesk-Tests durch? Zum Beispiel:

• Identitätsbetrugstests (ist die Person am Telefon, die ein Zurücksetzen des Kennworts beantragt, wirklich, wer sie vorgibt zu sein?) oder sogenannte "Social Engineering"-Angriffe.

Atlassian bietet Schulungen zur Informationssicherheit als Bestandteil des Onboarding-Trainings ("Tag 1") für neue Mitarbeiter und fortlaufend für alle Mitarbeiter an.

Zusätzlich zu diesen allgemeinen Schulungen zur Informationssicherheit werden für unsere Entwickler gezieltere Schulungen zum Thema sicheres Programmieren angeboten, die durch unser Programm für dedizierte Sicherheitstechniker unterstützt werden.

Wir bieten auch fortlaufende themenbezogene Schulungen zu Malware, Phishing und anderen sicherheitsrelevanten Aspekten an. https://www.atlassian.com/trust/security/security-practices#security-awareness-training

Wir führen offizielle Aufzeichnungen über den Abschluss der internen Mitarbeiterschulung. Die Mitarbeiter sind verpflichtet, den Verhaltenskodex anzuerkennen und ihm jährlich erneut zuzustimmen. Diese Richtlinie gilt für alle Mitarbeiter. Die Anforderungen an Sicherheitsbewusstsein, Vertraulichkeit und Datenschutz werden Mitarbeitern von Anfang an vermittelt und stehen allen Mitarbeitern in Confluence zur Verfügung.

6.07.01. (m)

Führt der Anbieter Penetrationstests durch? Wenn ja, wie oft? Was wird beim Penetrationstest wirklich getestet? Wird zum Beispiel die Sicherheitsisolation jedes Images getestet, um sicherzustellen, dass es nicht möglich ist, aus einem Image in ein anderes "auszubrechen" und Zugriff zur Host-Infrastruktur zu erhalten? Bei den Tests sollte auch überprüft werden, ob es möglich ist, über das virtuelle Image Zugriff auf die Management- und Supportsysteme der Cloud-Anbieter zu erhalten (z. B. Bereitstellungs- und Administratorzugriffskontrollsysteme).

Unser internes Red Team führt fortlaufend Penetrationstests unserer gesamten Infrastruktur, Cloud-Dienste und Mitarbeiter durch.

Wir beauftragen externe Beratungsunternehmen mit der Durchführung jährlicher Penetrationstests für nach außen gerichtete Anwendungen. Wir ergänzen diese Tests auch durch kleinere, fortlaufende Sicherheitstests, die von unserem internen Sicherheitstestteam durchgeführt werden. Die Beurteilungsschreiben für diese Penetrationstests und weitere Informationen zu unserem Testprozess und unserem Ansatz für externe Sicherheitstests findest du hier: https://www.atlassian.com/trust/security/security-testing.

6.07.01. (n)

Führt der Anbieter Schwachstellentests durch? Wenn ja, wie oft?

Unser Atlassian-Sicherheitsteam nutzt einen branchenweit anerkannten Schwachstellenscanner, um unsere interne und externe Infrastruktur laufend auf Netzwerkschwachstellen zu überprüfen. Weitere Informationen zu unserem Schwachstellenmanagement-Programm findest du unter: https://www.atlassian.com/trust/security/vulnerability-management.

6.07.01. (o)

Wie werden Schwachstellen behoben (Hotfixes, Neukonfiguration, Umstellung auf neuere Softwareversionen usw.)?

Jira-Tickets werden zu Nachverfolgung und Fehlerbehebung erstellt. Die Fälligkeitsdaten werden gemäß unserem SLO vergeben, basierend sowohl auf dem Schweregrad als auch auf der Quelle der Schwachstelle. Ein fortlaufender Prozess erstellt Tickets für identifizierte Schwachstellen für Systembesitzer. Unser Sicherheitsmanagementteam überprüft alle gemeldeten Schwachstellen und stellt sicher, dass geeignete Maßnahmen zur Behebung ergriffen werden.

Einzelheiten zu unserem Schwachstellenmanagement-Programm findest du unter: https://www.atlassian.com/trust/security/vulnerability-management.

6.08.

Wie bei der Personalsicherheit entstehen viele potenzielle Probleme, wenn Drittanbieter für die IT-Infrastruktur verantwortlich sind. Wie bei herkömmlichen Auslagerungen können sich die Auswirkungen einer physischen Sicherheitsverletzung auf mehrere Kunden (Organisationen) auswirken.

6.08. (a)

Welche Zusicherungen erhalten Kunden in Bezug auf die physische Sicherheit des Standorts? Führe Beispiele an, welche Normen eingehalten werden, wie etwa: ISO 27001/2, Abschnitt 9.

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

6.08. (a) (i)

Wer, außer autorisiertem IT-Personal, hat unbegleiteten (physischen) Zugang zur IT-Infrastruktur?

• Zum Beispiel Reinigungskräfte, Führungskräfte, Personal im Bereich physische Sicherheit, Auftragnehmer, Berater, Verkäufer usw.

Für die Büros von Atlassian gilt unsere interne Richtlinie für physische und umgebungsbezogene Sicherheit. Unter anderem werden alle Ein- und Ausgangstüren überwacht. Auszüge aus unseren internen Richtlinien für Technologiebetrieb und Sicherheit findest du hier: https://www.atlassian.com/trust/security/ismp-policies

Die Büros von Atlassian sind mit Zugangskontrollen (u. a. Lesegeräte für Zugangsausweise) und Kameraüberwachung gesichert. Zusätzlich besteht die Möglichkeit, den Zugang je nach Bedarf auf bestimmte Uhrzeiten oder Wochentage zu beschränken. Das Building Management-Team führt Protokoll über den Zugang zu den Bürogebäuden. Diese Protokolle stehen auch dem Workplace Experience-Team zu Überprüfungszwecken zur Verfügung.

Unsere Partnerrechenzentren verfügen über mehrere Compliance-Zertifizierungen. Diese Zertifizierungen beziehen sich auf die physische Sicherheit, die Systemverfügbarkeit, den Netzwerk- und IP-Backbone-Zugriff, die Kundenbereitstellung und das Problemmanagement. Der Zugang zu den Rechenzentren ist auf autorisiertes Personal beschränkt und wird durch biometrische Identitätsprüfungen kontrolliert. Vor Ort sorgen außerdem Wachpersonal, Videoüberwachungsanlagen, Zugangsschleusen und weitere Einbruchsschutzmaßnahmen für Sicherheit. Informationen zur Gewährleistung des physischen Schutzes durch AWS findest du hier: http://aws.amazon.com/compliance

6.08. (a) (ii)

Wie oft werden Zugriffsrechte überprüft?

• Wie schnell können Zugriffsrechte entzogen werden?

Atlassian bewertet die Leistung und Effektivität seines ISMS anhand geeigneter Kennzahlen. Wir überwachen die Leistung des Atlassian Trust Management System (ATMS) und der relevanten Kontrollen durch interne und externe Prüfungen. Unser Atlassian Compliance Team verwaltet den Zeitplan für unsere internen Bereitschaftsprüfungen und unsere externen Prüfungen. (Diese werden intern auf unserer Seite "Audit Roadmaps" dokumentiert.) Interne Audits konzentrieren sich auf Bereiche mit hohem Risiko bei Atlassian und finden regelmäßig nach festgelegten Zeitplänen und gemäß dem Enterprise-Audit-Zeitplan statt, der zwischen dem Risiko- und Compliance-Team und dem Team für interne Audits vereinbart wurde. Wir veröffentlichen unsere internen Kennzahlen derzeit nicht. Das ATMS wird jährlich und nach wesentlichen Änderungen von unabhängigen Drittparteien geprüft. Atlassian hat die SOC 2-, ISO27001- und ISO7018-Zertifizierungen für jeden unseren zentralen Cloud-Services erhalten. Atlassian überwacht die grundlegenden Funktionen des ATMS mit regelmäßigen Meetings und spezifischen Kennzahlen. Dazu gehören wöchentliche Compliance-Bewertungen des ATMS und weitere Meetings, die intern auf unseren Seiten "ATMS: Compliance Health Review" und "ATMS Meeting Notes" dokumentiert werden. Weitere Informationen findest du unter: https://www.atlassian.com/trust/compliance.

Wir haben ein formelles Sicherheitsmanagementprogramm und wir überprüfen unser Information Security Management Program (ISMP) jährlich. Weitere Informationen zum Security Management Program, findest du unter: https://www.atlassian.com/trust/security/security-management-program

6.08. (a) (iii)

Werden regelmäßig Bewertungen der Sicherheitsrisiken und -perimeter durchgeführt?

• Wie häufig?

Atlassian bewertet die Leistung und Effektivität seines ISMS anhand geeigneter Kennzahlen. Wir überwachen die Leistung des Atlassian Trust Management System (ATMS) und der relevanten Kontrollen durch interne und externe Prüfungen. Unser Atlassian Compliance Team verwaltet den Zeitplan für unsere internen Bereitschaftsprüfungen und unsere externen Prüfungen. (Diese werden intern auf unserer Seite "Audit Roadmaps" dokumentiert.) Interne Audits konzentrieren sich auf Bereiche mit hohem Risiko bei Atlassian und finden regelmäßig nach festgelegten Zeitplänen und gemäß dem Enterprise-Audit-Zeitplan statt, der zwischen dem Risiko- und Compliance-Team und dem Team für interne Audits vereinbart wurde. Wir veröffentlichen unsere internen Kennzahlen derzeit nicht. Das ATMS wird jährlich und nach wesentlichen Änderungen von unabhängigen Drittparteien geprüft. Atlassian hat die SOC 2-, ISO27001- und ISO7018-Zertifizierungen für jeden unseren zentralen Cloud-Services erhalten. Atlassian überwacht die grundlegenden Funktionen des ATMS mit regelmäßigen Meetings und spezifischen Kennzahlen. Dazu gehören wöchentliche Compliance-Bewertungen des ATMS und weitere Meetings, die intern auf unseren Seiten "ATMS: Compliance Health Review" und "ATMS Meeting Notes" dokumentiert werden. Weitere Informationen findest du unter: https://www.atlassian.com/trust/compliance.

Wir haben ein formelles Sicherheitsmanagementprogramm und wir überprüfen unser Information Security Management Program (ISMP) jährlich. Weitere Informationen zum Security Management Program, findest du unter: https://www.atlassian.com/trust/security/security-management-program

6.08. (a) (iv)

Werden regelmäßig Risikobeurteilungen durchgeführt, bei denen auch Faktoren wie benachbarte Gebäude berücksichtigt werden?

Atlassian bewertet die Leistung und Effektivität seines ISMS anhand geeigneter Kennzahlen. Wir überwachen die Leistung des Atlassian Trust Management System (ATMS) und der relevanten Kontrollen durch interne und externe Prüfungen. Unser Atlassian Compliance Team verwaltet den Zeitplan für unsere internen Bereitschaftsprüfungen und unsere externen Prüfungen. (Diese werden intern auf unserer Seite "Audit Roadmaps" dokumentiert.) Interne Audits konzentrieren sich auf Bereiche mit hohem Risiko bei Atlassian und finden regelmäßig nach festgelegten Zeitplänen und gemäß dem Enterprise-Audit-Zeitplan statt, der zwischen dem Risiko- und Compliance-Team und dem Team für interne Audits vereinbart wurde. Wir veröffentlichen unsere internen Kennzahlen derzeit nicht. Das ATMS wird jährlich und nach wesentlichen Änderungen von unabhängigen Drittparteien geprüft. Atlassian hat die SOC 2-, ISO27001- und ISO7018-Zertifizierungen für jeden unseren zentralen Cloud-Services erhalten. Atlassian überwacht die grundlegenden Funktionen des ATMS mit regelmäßigen Meetings und spezifischen Kennzahlen. Dazu gehören wöchentliche Compliance-Bewertungen des ATMS und weitere Meetings, die intern auf unseren Seiten "ATMS: Compliance Health Review" und "ATMS Meeting Notes" dokumentiert werden. Weitere Informationen findest du unter: https://www.atlassian.com/trust/compliance.

Wir haben ein formelles Sicherheitsmanagementprogramm und wir überprüfen unser Information Security Management Program (ISMP) jährlich. Weitere Informationen zum Security Management Program, findest du unter: https://www.atlassian.com/trust/security/security-management-program

6.08. (a) (v)

Wird Personal (einschließlich externer Personen), das Zugang zu Sicherheitsbereichen hat, kontrolliert oder überwacht?

Für die Büros von Atlassian gilt unsere interne Richtlinie für physische und umgebungsbezogene Sicherheit. Unter anderem werden alle Ein- und Ausgangstüren überwacht. Auszüge aus unseren internen Richtlinien für Technologiebetrieb und Sicherheit findest du hier: https://www.atlassian.com/trust/security/ismp-policies

Die Büros von Atlassian sind mit Zugangskontrollen (u. a. Lesegeräte für Zugangsausweise) und Kameraüberwachung gesichert. Zusätzlich besteht die Möglichkeit, den Zugang je nach Bedarf auf bestimmte Uhrzeiten oder Wochentage zu beschränken. Das Building Management-Team führt Protokoll über den Zugang zu den Bürogebäuden. Diese Protokolle stehen auch dem Workplace Experience-Team zu Überprüfungszwecken zur Verfügung.

Unsere Partnerrechenzentren verfügen über mehrere Compliance-Zertifizierungen. Diese Zertifizierungen beziehen sich auf die physische Sicherheit, die Systemverfügbarkeit, den Netzwerk- und IP-Backbone-Zugriff, die Kundenbereitstellung und das Problemmanagement. Der Zugang zu den Rechenzentren ist auf autorisiertes Personal beschränkt und wird durch biometrische Identitätsprüfungen kontrolliert. Vor Ort sorgen außerdem Wachpersonal, Videoüberwachungsanlagen, Zugangsschleusen und weitere Einbruchsschutzmaßnahmen für Sicherheit. Informationen zur Gewährleistung des physischen Schutzes durch AWS findest du hier: http://aws.amazon.com/compliance

6.08. (a) (vi)

Welche Richtlinien oder Verfahren gelten für das Laden, Entladen und Installieren von Geräten und Medien?

In den Büroeinrichtungen von Atlassian sind die Laderampen von den Arbeitsbereichen isoliert und werden ständig von Überwachungskameras und Gebäudepersonal überwacht. Unsere Rechenzentrums-Hosting-Partner sind für die physische Sicherheit zuständig. Wir verlassen uns auf ihre Compliance-Zertifizierungen als Nachweis dafür, dass die Kontrollen wirksam sind.

6.08. (a) (vii)

Werden Lieferungen vor der Installation auf Risiken überprüft?

In den Büroeinrichtungen von Atlassian sind die Laderampen von den Arbeitsbereichen isoliert und werden ständig von Überwachungskameras und Gebäudepersonal überwacht. Unsere Rechenzentrums-Hosting-Partner sind für die physische Sicherheit zuständig. Wir verlassen uns auf ihre Compliance-Zertifizierungen als Nachweis dafür, dass die Kontrollen wirksam sind.

6.08. (a) (viii)

Wird ein aktuelles Inventar der Komponenten im Rechenzentrum geführt?

Einen Auszug aus unserer Asset-Management-Richtlinie findest du unter https://www.atlassian.com/trust/security/ismp-policies. Atlassian führt ein Inventar aller Produktions-Assets mit Angaben zu den jeweiligen Besitzern. Alle unsere Systeme befinden sich in AWS-basierten Rechenzentren. Aufgrund der Beschaffenheit des Service ist keine Nachverfolgung unserer AWS-Systeme auf Hardwareebene möglich.

Alle Microservices werden in einer speziell für diesen Zweck erstellten Service-Datenbank nachverfolgt, die immer bei Bereitstellung eines Service aktualisiert wird. Das Workplace Technology-Team von Atlassian führt ein Inventar aller Endgeräte. Dabei wird unser eigenes Produkt Jira Software für die Nachverfolgung eingesetzt.

Alle Microservices werden bestimmten Stufen mit konkreten Verfügbarkeits-, RTO- und RPO-Erwartungen zugeordnet. Beispiele findest du hier: https://www.atlassian.com/trust/security/data-management

6.08. (a) (ix)

Verlaufen Netzwerkkabel durch öffentlich zugängliche Bereiche?

• Werden Panzerkabel oder speziell geschützte Leitungen verwendet?

Für die Büros von Atlassian gilt unsere interne Richtlinie für physische und umgebungsbezogene Sicherheit. Unter anderem werden alle Ein- und Ausgangstüren überwacht. Auszüge aus unseren internen Richtlinien für Technologiebetrieb und Sicherheit findest du hier: https://www.atlassian.com/trust/security/ismp-policies

Die Büros von Atlassian sind mit Zugangskontrollen (u. a. Lesegeräte für Zugangsausweise) und Kameraüberwachung gesichert. Zusätzlich besteht die Möglichkeit, den Zugang je nach Bedarf auf bestimmte Uhrzeiten oder Wochentage zu beschränken. Das Building Management-Team führt Protokoll über den Zugang zu den Bürogebäuden. Diese Protokolle stehen auch dem Workplace Experience-Team zu Überprüfungszwecken zur Verfügung.

6.08. (a) (x)

Werden Gebäude regelmäßig nach nicht autorisierten Geräten und Medien durchsucht?

Einen Auszug aus unserer Asset-Management-Richtlinie findest du unter https://www.atlassian.com/trust/security/ismp-policies. Atlassian führt ein Inventar aller Produktions-Assets mit Angaben zu den jeweiligen Besitzern. Alle unsere Systeme befinden sich in AWS-basierten Rechenzentren. Aufgrund der Beschaffenheit des Service ist keine Nachverfolgung unserer AWS-Systeme auf Hardwareebene möglich.

Alle Microservices werden in einer speziell für diesen Zweck erstellten Service-Datenbank nachverfolgt, die immer bei Bereitstellung eines Service aktualisiert wird. Das Workplace Technology-Team von Atlassian führt ein Inventar aller Endgeräte. Dabei wird unser eigenes Produkt Jira Software für die Nachverfolgung eingesetzt.

6.08. (a) (xi)

Werden Geräte und Medien genutzt, die sich an externen Standorten befinden?

• Wie werden diese geschützt?

Einen Auszug aus unserer Asset-Management-Richtlinie findest du unter https://www.atlassian.com/trust/security/ismp-policies. Atlassian führt ein Inventar aller Produktions-Assets mit Angaben zu den jeweiligen Besitzern. Alle unsere Systeme befinden sich in AWS-basierten Rechenzentren. Aufgrund der Beschaffenheit des Service ist keine Nachverfolgung unserer AWS-Systeme auf Hardwareebene möglich.

Alle Microservices werden in einer speziell für diesen Zweck erstellten Service-Datenbank nachverfolgt, die immer bei Bereitstellung eines Service aktualisiert wird. Das Workplace Technology-Team von Atlassian führt ein Inventar aller Endgeräte. Dabei wird unser eigenes Produkt Jira Software für die Nachverfolgung eingesetzt.

6.08. (a) (xii)

Nutzt das Personal tragbare Geräte (z. B. Laptops oder Smartphones), die Zugang zum oder Zugriff auf das Rechenzentrum ermöglichen?

• Wie werden diese geschützt?

Unsere Partnerrechenzentren verfügen über mehrere Compliance-Zertifizierungen. Diese Zertifizierungen beziehen sich auf die physische Sicherheit, die Systemverfügbarkeit, den Netzwerk- und IP-Backbone-Zugriff, die Kundenbereitstellung und das Problemmanagement. Der Zugang zu den Rechenzentren ist auf autorisiertes Personal beschränkt und wird durch biometrische Identitätsprüfungen kontrolliert. Vor Ort sorgen außerdem Wachpersonal, Videoüberwachungsanlagen, Zugangsschleusen und weitere Einbruchsschutzmaßnahmen für Sicherheit. Informationen zur Gewährleistung des physischen Schutzes durch AWS findest du hier: http://aws.amazon.com/compliance/

Autorisierte und geschulte Mitglieder der Atlassian Engineering-Teams, die einer Hintergrundüberprüfung unterzogen wurden, authentifizieren sich beim VPN mit eindeutigen sicheren Passwörtern und TOTP-basierter 2FA und greifen dann nur über SSH-Terminalverbindungen mit passphrasengeschützten persönlichen RSA-Zertifikaten auf die Produktionsumgebung zu. Auf allen Produktionsservern ist ein IDS-System mit Funktionen für Echtzeit-Überwachung vorhanden, das bei Änderungen an den Dateien oder der Konfiguration des Produktionssystems sowie bei anomalen Sicherheitsereignissen Warnungen ausgibt. Für die autorisierten und geschulten Mitglieder des Operations-Teams mit Zugriff auf das Produktionssystem muss auf allen Workstations unter Windows oder OS X, die für den SSH-Terminalzugriff auf die Produktionsumgebung verwendet werden, aktuelle und aktive Antivirensoftware ausgeführt werden. Kundendaten werden nicht auf die Workstations oder Mobilgeräte von Mitarbeitern repliziert.

6.08. (a) (xiii)

Mit welchen Maßnahmen werden Zugangskarten kontrolliert?

Für die Büros von Atlassian gilt unsere interne Richtlinie für physische und umgebungsbezogene Sicherheit. Unter anderem werden alle Ein- und Ausgangstüren überwacht. Auszüge aus unseren internen Richtlinien für Technologiebetrieb und Sicherheit findest du hier: https://www.atlassian.com/trust/security/ismp-policies

Die Büros von Atlassian sind mit Zugangskontrollen (u. a. Lesegeräte für Zugangsausweise) und Kameraüberwachung gesichert. Zusätzlich besteht die Möglichkeit, den Zugang je nach Bedarf auf bestimmte Uhrzeiten oder Wochentage zu beschränken. Das Building Management-Team führt Protokoll über den Zugang zu den Bürogebäuden. Diese Protokolle stehen auch dem Workplace Experience-Team zu Überprüfungszwecken zur Verfügung.

6.08. (a) (xiv)

Welche Prozesse oder Verfahren regeln die ggf. erforderliche Vernichtung alter Medien oder Systeme?

• Werden die Daten überschrieben?
• Erfolgt eine physische Vernichtung?

Das Workplace Technology-Team ist für diesen Prozess zuständig. Die Geräte und Medien werden bereinigt und ggf. entmagnetisiert. Atlassian hat keine Kontrolle über physische Medien, die ggf. unsere Cloud-Produkte und -Services unterstützen.

6.08. (a) (xv)

Welche Genehmigungsverfahren gibt es für den Transport von Geräten von einem Standort zum anderen?

• Wie werden die dazu befugten Mitarbeiter (oder Auftragnehmer) identifiziert?

Die Rechenzentrums-Hosting-Partner von Atlassian (AWS) sind für die physische Sicherheit zuständig. Wir verlassen uns auf ihre SOC2-Compliance als Nachweis dafür, dass die Kontrollen wirksam sind.

Bei Atlassian Cloud-Produkten werden Kundendaten nicht physisch übertragen. Festplatten mit Kundendaten werden vernichtet oder bereinigt, bevor sie unsere gesicherten AWS-Rechenzentren verlassen. Bei Systemen, die in AWS gehostet werden, können Daten in einem Redundanzszenario zwischen Regionen verschoben werden, bleiben aber innerhalb von AWS. Weitere Informationen zu unseren AWS-Regionen findest du hier: https://www.atlassian.com/trust/reliability/infrastructure

6.08. (a) (xvi)

Wie oft werden Audits durchgeführt, um zu überprüfen, ob Geräte oder Medien unerlaubt entfernt wurden?

Die Rechenzentrums-Hosting-Partner von Atlassian (AWS) sind für die physische Sicherheit zuständig. Wir verlassen uns auf ihre SOC2-Compliance als Nachweis dafür, dass die Kontrollen wirksam sind.

Bei Atlassian Cloud-Produkten werden Kundendaten nicht physisch übertragen. Festplatten mit Kundendaten werden vernichtet oder bereinigt, bevor sie unsere gesicherten AWS-Rechenzentren verlassen. Bei Systemen, die in AWS gehostet werden, können Daten in einem Redundanzszenario zwischen Regionen verschoben werden, bleiben aber innerhalb von AWS. Weitere Informationen zu unseren AWS-Regionen findest du hier: https://www.atlassian.com/trust/reliability/infrastructure

6.08. (a) (xvii)

Wie oft werden Prüfungen durchgeführt, um sicherzustellen, dass die Umgebung den geltenden gesetzlichen und behördlichen Anforderungen entspricht?

Das Legal-Team und die Compliance-Teams von Atlassian überwachen die Einhaltung der für uns geltenden Auflagen. Unsere rechtlichen Hinweise findest du unter https://www.atlassian.com/legal/. Weitere Informationen zu unserem Compliance-Programm sind hier zu finden: https://www.atlassian.com/trust/compliance.

6.09. (a)

Welche Verfahren oder Richtlinien stellen sicher, dass Probleme in der Umgebung nicht zu Betriebsunterbrechungen führen?

Für die Büros von Atlassian gilt unsere interne Richtlinie für physische und umgebungsbezogene Sicherheit. Unter anderem werden alle Ein- und Ausgangstüren überwacht.

Unsere Partnerrechenzentren verfügen über mehrere Compliance-Zertifizierungen. Diese Zertifizierungen beziehen sich auf die physische Sicherheit, die Systemverfügbarkeit, den Netzwerk- und IP-Backbone-Zugriff, die Kundenbereitstellung und das Problemmanagement. Der Zugang zu den Rechenzentren ist auf autorisiertes Personal beschränkt und wird durch biometrische Identitätsprüfungen kontrolliert. Vor Ort sorgen außerdem Wachpersonal, Videoüberwachungsanlagen, Zugangsschleusen und weitere Einbruchsschutzmaßnahmen für Sicherheit. Informationen zur Gewährleistung des physischen Schutzes durch AWS findest du hier: http://aws.amazon.com/compliance/

Eine Richtlinie für Business Continuity und Disaster Recovery sowie ein Plan für Business Continuity und Disaster Recovery sind vorhanden und werden jährlich von den dafür zuständigen Ausschüssen überprüft. Besitzer von unternehmenskritischen Systemen, Prozessen oder Services müssen im Falle einer Katastrophe und im Rahmen festgelegter Störungstoleranzen eine ordnungsgemäße Business Continuity und/oder Disaster Recovery sicherstellen. Entsprechende Pläne werden vierteljährlich geprüft, um Probleme zu identifizieren und zu beheben. Weitere Informationen findest du unter https://www.atlassian.com/trust/security/security-practices#business-continuity-and-disaster-recovery-management und https://www.atlassian.com/trust/security/data-management.

6.09. (b)

Mit welchen Methoden werden Schäden durch Feuer, Überschwemmung, Erdbeben oder Ähnliches verhindert?

• Welche zusätzlichen Sicherheitsmaßnahmen wurden getroffen, um im Katastrophenfall den physischen Zugang zu schützen?
• Gilt dies sowohl an den primären als auch an den sekundären Standorten?

Atlassian verlässt sich darauf, dass unsere Daten-Hosting-Partner ihre Rechenzentrumssicherheit und Umgebungskontrollen ordnungsgemäß validieren. Informationen zu AWS siehe https://aws.amazon.com/compliance/programs.

6.09. (c)

Werden Temperatur und Luftfeuchtigkeit im Rechenzentrum überwacht?

• Was gilt für Klimaanlagen oder die entsprechende Überwachung?

Atlassian verlässt sich darauf, dass unsere Daten-Hosting-Partner ihre Rechenzentrumssicherheit und Umgebungskontrollen ordnungsgemäß validieren. Informationen zu AWS siehe https://aws.amazon.com/compliance/programs.

6.09. (d)

Sind die Gebäude vor Blitzschlag geschützt?

• Gilt dies auch für Strom- und Kommunikationsleitungen?

Atlassian verlässt sich darauf, dass unsere Daten-Hosting-Partner ihre Rechenzentrumssicherheit und Umgebungskontrollen ordnungsgemäß validieren. Informationen zu AWS siehe https://aws.amazon.com/compliance/programs.

6.09. (e)

Sind Notstromaggregate für den Fall eines Stromausfalls vorhanden?

• Wie lange können diese laufen?
• Sind ausreichende Kraftstoffvorräte vorhanden?
• Sind Failover-Notstromaggregate vorhanden?
• Wie oft werden die für die USV benötigten Systeme überprüft?
• Wie oft werden die Notstromaggregate überprüft?
• Sind mehrere Stromversorger vorhanden?

Atlassian verlässt sich darauf, dass unsere Daten-Hosting-Partner ihre Rechenzentrumssicherheit und Umgebungskontrollen ordnungsgemäß validieren. Informationen zu AWS siehe https://aws.amazon.com/compliance/programs.

6.09. (f)

Sind alle Versorger (Strom, Wasser usw.) in der Lage, die Umgebung zu unterstützen?

• Wie oft wird dies neu bewertet und getestet?

Atlassian verlässt sich darauf, dass unsere Daten-Hosting-Partner ihre Rechenzentrumssicherheit und Umgebungskontrollen ordnungsgemäß validieren. Informationen zu AWS siehe https://aws.amazon.com/compliance/programs.

6.09. (g)

Ist die Klimaanlage ausreichend, um die Umgebung zu unterstützen?

• Wie oft wird dies getestet?

Atlassian verlässt sich darauf, dass unsere Daten-Hosting-Partner ihre Rechenzentrumssicherheit und Umgebungskontrollen ordnungsgemäß validieren. Informationen zu AWS siehe https://aws.amazon.com/compliance/programs.

6.09. (h)

Werden die von den Herstellern empfohlenen Wartungszeitpläne eingehalten?

Atlassian verlässt sich darauf, dass unsere Daten-Hosting-Partner ihre Rechenzentrumssicherheit und Umgebungskontrollen ordnungsgemäß validieren. Informationen zu AWS siehe https://aws.amazon.com/compliance/programs.

6.09. (i)

Ist sichergestellt, dass nur autorisiertes Wartungs- oder Reparaturpersonal die Gebäude betreten kann?

• Wie wird die Identität dieser Personen überprüft?

Der physische Zugang zu den Bürogebäuden ist durch elektronische Zugangsausweise, eine während der Geschäftszeiten besetzte Rezeption, an der sich Gäste anmelden müssen, und Videoüberwachung an allen Ein- und Ausgangstüren von Gebäuden geschützt. Die Laderampen werden ständig mit Überwachungskameras und Gebäudepersonal überwacht. Unsere Rechenzentrums-Hosting-Partner sind für die physische Sicherheit zuständig. Wir verlassen uns auf ihre Compliance-Zertifizierungen als Nachweis dafür, dass die Kontrollen wirksam sind.

6.09. (j)

Werden die Daten von Geräten, die zur Reparatur eingesendet werden müssen, vor dem Versenden gelöscht?

• Wie wird dies umgesetzt?

Das Workplace Technology-Team ist für diesen Prozess zuständig. Die Geräte und Medien werden bereinigt und ggf. entmagnetisiert. Atlassian hat keine Kontrolle über physische Medien, die ggf. unsere Cloud-Produkte und -Services unterstützen.

6.10.

Kunden und potenzielle Kunden von Cloud-Anbieter-Services müssen die für sie geltenden nationalen und übernationalen gesetzlichen Auflagen berücksichtigen und sicherstellen, dass diese angemessen erfüllt werden.

Die wichtigsten rechtlichen Fragen, die Kunden dem Cloud-Anbieter stellen sollten, lauten:

6.10. (a)

In welchem Land hat der Cloud-Anbieter seinen Unternehmenssitz?

Atlassian hat 12 Niederlassungen in 8 Ländern, u. a. in Sydney, Amsterdam, Ankara, Boston, Bengaluru, San Francisco, Mountain View, Austin, NYC, Manila, Danzig und Japan. Weitere Informationen findest du hier: https://www.atlassian.com/company/contact

6.10. (b)

Befindet sich die Infrastruktur des Cloud-Anbieters im selben Land oder in verschiedenen Ländern?

Für Atlassian Cloud erfolgt das Hosting derzeit in redundanten AWS-Verfügbarkeitszonen. Weitere Informationen zu den einzelnen Regionen findest du hier: https://www.atlassian.com/trust/reliability/infrastructure

6.10. (c)

Beauftragt der Cloud-Anbieter andere Unternehmen, deren Infrastruktur sich außerhalb der des Cloud-Anbieters befindet?

Atlassian Cloud-Produkte und -Daten werden vom branchenführenden Cloud-Anbieter AWS (Amazon Web Services) gehostet. Unsere Produkte laufen in einer PaaS-Umgebung (Platform as a Service), die in zwei Hauptinfrastrukturgruppen aufgeteilt ist, die wir als Micros und Nicht-Micros bezeichnen. Jira, Confluence, Statuspage, Access und Bitbucket werden auf der Micros-Plattform ausgeführt, während Opsgenie und Trello auf der Nicht-Micros-Plattform ausgeführt werden.

6.10. (d)

Wo ist der physische Speicherort der Daten?

Atlassian verwendet Amazon Web Services (AWS) in den Regionen USA Ost, USA West, Irland, Frankfurt, Singapur und Sydney (Confluence und Jira).

Details zu den spezifischen Produkten:

• Trello: verfügbar in AWS USA Ost (Ohio).
• Jira Align: Der physische Standort der Kundendaten kann per Support-Ticket-Anfrage angefragt werden. Siehe: https://support.atlassian.com/jira-align/.
• Statuspage: verfügbar in den AWS-Regionen USA West (Oregon, Kalifornien) USA Ost (Ohio).
• Opsgenie: hat AWS-Konten sowohl in den USA als auch in Europa. Kunden müssen sich bei der Registrierung für AWS USA (Oregon, Kalifornien) oder EU (Frankfurt) anmelden.
• Halp: gehostet bei AWS in den Regionen USA Ost 2 und USA West 2.
• Bitbucket: Repositorys und Hauptfunktionen der Anwendung werden von AWS in den Regionen USA Ost und den USA West gehostet.


Weitere Informationen zur Datenresidenz findest du unter: https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/.

6.10. (e)

Wird die Zuständigkeit für die Vertragsbedingungen und die Daten aufgeteilt?

Standardmäßig gilt für den Atlassian Customer Contract kalifornisches Recht. Wende dich an unser Enterprise Sales Team, um weitere Informationen zu erhalten.

6.10. (f)

Werden Dienste des Cloud-Anbieters an Subunternehmer vergeben?

Atlassian arbeitet mit externen Subunternehmern zusammen, um Website-, Anwendungsentwicklungs-, Hosting-, Wartungs-, Sicherungs-, Speicher-, virtuelle Infrastruktur-, Zahlungsabwicklungs-, Analyse- und andere Services bereitzustellen. Diese Serviceanbieter haben eventuell Zugriff auf personenbezogene Daten oder verarbeiten diese, damit sie diese Services für uns bereitstellen können.

Atlassian benachrichtigt die betroffenen Kunden über die Nutzung von Subunternehmern, die ihre personenbezogenen Daten bearbeiten könnten, bevor es zur Verarbeitung kommt. Eine Liste mit externen Subunternehmern, mit denen Atlassian zusammenarbeitet, findest du auf der Seite "Unterauftragsverarbeiter von Atlassian" unter https://www.atlassian.com/legal/sub-processors. Hier können Benutzer einen RSS-Feed abonnieren, um Benachrichtigungen darüber zu erhalten, wenn wir neue Auftragsverarbeiter hinzufügen.

6.10. (g)

Werden Dienste des Cloud-Anbieters ausgelagert?

Wenn Atlassian Drittanbieter beauftragt, möchten wir sicherstellen, dass diese Zusammenarbeit unsere Kunden oder ihre Daten in keiner Weise gefährdet. Die Rechts- und Beschaffungsabteilungen von Atlassian überprüfen Verträge, SLAs und interne Anbieterrichtlinien, um sicherzustellen, dass der Anbieter die Anforderungen zu Sicherheit, Verfügbarkeit und Vertraulichkeit einhält. Weitere Informationen findest du unter: https://www.atlassian.com/trust/security/security-practices#supplier-risk-management.

6.10. (h)

Wie werden die vom Kunden und den Kunden des Kunden bereitgestellten Daten erfasst, verarbeitet und übertragen?

Atlassian verarbeitet Daten im Einklang mit der externen Datenschutzrichtlinie von Atlassian und auf eine Weise, die mit den Zwecken vereinbar ist, für die sie erhoben wurden oder für die nachträglich eine Erlaubnis von der betreffenden Person eingeholt wurde.

Der Schutz von Benutzerdaten ist uns wichtig. Darum behandelt Atlassian die Erfassung, Verwendung und Weitergabe von Benutzerinformationen transparent. Weitere Informationen findest du auf unserer Seite "Datenschutz bei Atlassian" in unserem Atlassian Trust Center unter https://www.atlassian.com/trust/privacy und in unserer Datenschutzrichtlinie unter https://www.atlassian.com/legal/privacy-policy.

6.10. (i)

Was passiert mit den Daten, die nach Kündigung des Vertrags an den Cloud-Anbieter gesendet werden?

Atlassian unterhält einen Standard zur Aufbewahrung und Vernichtung von Daten, der festlegt, wie lange wir Daten verschiedener Arten aufbewahren müssen. Daten werden gemäß unserer Atlassian-Richtlinie für Datensicherheit und Information Lifecycle Management und den darauf aufbauenden Kontrollen klassifiziert. Was Kundendaten betrifft, so werden bei Kündigung eines Atlassian-Vertrags die Daten eines Kundenteams aus der Live-Produktionsdatenbank entfernt. Alle direkt auf Atlassian hochgeladenen Dateianhänge werden innerhalb von 14 Tagen entfernt. Die Daten des Teams verbleiben in verschlüsselten Backups, bis das 90-tägige Aufbewahrungsfenster für diese Backups überschritten ist und sie gemäß unserer Atlassian-Datenspeicherungsrichtlinie vernichtet werden. Für den Fall, dass innerhalb von 90 Tagen nach einer angeforderten Datenlöschung eine Datenbankwiederherstellung erforderlich ist, wird das Betriebsteam die Daten so schnell wie möglich erneut löschen, nachdem das Live-Produktionssystem vollständig wiederhergestellt ist. Weitere Informationen findest du unter: https://support.atlassian.com/security-and-access-policies/docs/track-storage-and-move-data-across-products/