| Prinzip 1: Schutz bei der Übertragung von Daten |
| 1.1 Verschlüsselung | Atlassian behält die Verschlüsselung im internen drahtlosen Netzwerk bei, einschließlich der Änderung der Standardeinstellungen des Anbieters. Das Workplace Technology-Team von Atlassian schützt unsere drahtlosen Netzwerke mithilfe der WPA2-AES-Authentifizierung und der PEAP-EAP-MSCHAPv2-Verschlüsselung. Wir authentifizieren uns in unserem drahtlosen Netzwerk über 802.1x und nutzen unseren internen Identitätsspeicher. Wir suchen regelmäßig nach nicht autorisierten WLAN-Zugangspunkten und führen eine Liste der gefundenen nicht autorisierten Zugangspunkte.
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 | Unsere Sicherheits- und Datenschutzrichtlinien
Verschlüsselung von Daten | Atlassian Trust Center
Datenverschlüsselung | Atlassian Cloud-Architektur und Betriebspraktiken |
| 1.2 Netzwerkschutz | Das Policy Management Program (PMP) von Atlassian beinhaltet eine Kommunikationssicherheitsrichtlinie, die die Verantwortung für das Netzwerkmanagement festlegt.
Für den Netzwerkzugriff verwendet Atlassian ein zentralisiertes, LDAP-fähiges Verzeichnis, das eine rollenbasierte Zugriffskontrolle auf der Grundlage definierter Profile implementiert. Benutzer erhalten auf der Grundlage dieser Profile angemessene Zugriffsrechte, die über Workflow aus unserem Personalverwaltungssystem gesteuert werden. Interne Regeln für den Zugriff auf das Produktionsnetzwerk werden mithilfe explizit festgelegter Sicherheitsgruppen innerhalb von AWS-VPC-Umgebungen verwaltet.
Das Workplace Technology-Team von Atlassian schützt unsere drahtlosen Netzwerke mithilfe der WPA2-AES-Authentifizierung und der PEAP-EAP-MSCHAPv2-Verschlüsselung. Wir authentifizieren uns in unserem drahtlosen Netzwerk über 802.1x und nutzen unseren internen Identitätsspeicher.
Atlassian Network Engineering verwendet IPS-Technologien, die in unsere Cloud- und Office-Firewalls integriert sind, und wir haben 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-Implementierungen von TLS erzwingen die Verwendung starker Chiffren. | Unsere Sicherheits- und Datenschutzrichtlinien
Integration der Sicherheit in unsere Netzwerkinfrastruktur | Atlassian Trust Center |
| 1.3 Authentifizierung | 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.
Atlassian unterstützt die Verwendung von Google-, Microsoft- und Apple-Identitäten zur Authentifizierung bei den meisten Produkten. Wir unterstützen auch SAML für unsere Atlassian Cloud-Services über Atlassian Access, siehe: https://www.atlassian.com/enterprise/cloud/access | Unsere Sicherheits- und Datenschutzrichtlinien
Sicherer Zugriff auf unsere Netzwerke über ZeroTrust | Atlassian Trust Center Service
Authentifizierung und Autorisierung | Atlassian Cloud-Architektur und Betriebspraktiken |
| Prinzip 2: Asset-Schutz und Widerstandsfähigkeit |
| 2.1 Physischer Standort und Gerichtsstand | Physischer Standort
Aktuell unterhält Atlassian Rechenzentren und hostet Daten in den USA, Deutschland, Irland, Singapur und Australien. Wir bieten allen Kunden sichere, schnelle und zuverlässige Services, indem wir ihre Inhalte in mehreren Regionen auf der ganzen Welt hosten.
Alle Atlassian Cloud-Produktionssysteme befinden sich in den Amazon-AWS-Regionen USA Ost, USA West, Irland, Frankfurt, Sydney und Singapur.
Die Atlassian-Plattform optimiert bei der Anmeldung je nach Zugriffspunkt die Ablage von Kundendaten. Dadurch werden eine zuverlässigere Leistung und eine geringere Latenz sichergestellt.
Datenresidenz ist derzeit im Rahmen unserer Cloud-Standard-, -Premium- und -Enterprise-Tarife für Jira Software, Confluence und Jira Service Management verfügbar. Du kannst auch festlegen, ob du bestimmte Produktdaten in Australien, Europa oder in den Vereinigten Staaten hosten möchtest. Hier erfährst du mehr zu Datenresidenzkontrollen.
In unserer Cloud-Roadmap findest du die neuesten Updates zur Datenresidenz für zusätzliche Standorte, zur Datenresidenz für Apps und mehr. | Physischer Standort
Datensicherung | Atlassian Trust Center
Atlassian Cloud-Hosting-Infrastruktur | Atlassian Cloud-Architektur und Betriebspraktiken |
| Verwendung deiner Daten
Bitte lies dir die Kundenvereinbarung von Atlassian, die Datenschutzrichtlinie und den Zusatz zur Datenverarbeitung durch. | Verwendung deiner Daten
Atlassian-Kundenvereinbarung | Atlassian
Datenschutzrichtlinie | Atlassian
Zusatz zur Datenverarbeitung | Atlassian |
| Weitere Überlegungen
Bitte lies dir die Verpflichtung von Atlassian zur DSGVO und anderen Datenschutzgesetzen durch. | Weitere Überlegungen
DSGVO-Verpflichtung | Atlassian | Atlassian |
| 2.2 Sicherheit im Rechenzentrum | Dies wird im Zusatz zur Datenverarbeitung von Atlassian behandelt, in dem sich Atlassian zum Schutz deiner Daten verpflichtet. Dies gilt auch in Bezug auf Rechenzentrums- und Netzwerksicherheit sowie die Datensicherheit.
Atlassian geht von physischen Bedrohungen für seine Rechenzentren aus und hat Gegenmaßnahmen ergriffen, um die Auswirkungen dieser Bedrohungen zu verhindern oder zu begrenzen.
Unsere Atlassian-Büros orientieren sich an unserer internen physischen und ökologischen Sicherheitsrichtlinie, einschließlich der Überwachung physischer Ein- und Ausgangspunkte.
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.
AWS verfügt über mehrere Zertifizierungen zum Schutz seiner Rechenzentren. Informationen zur Gewährleistung des physischen Schutzes durch AWS findest du unter: http://aws.amazon.com/compliance/ | Siehe
https://www.atlassian.com/trust/security/securitypractices#physical-security |
| 2.3 Datenverschlüsselung | Atlassian behält die Verschlüsselung im internen drahtlosen Netzwerk bei, einschließlich der Änderung der Standardeinstellungen des Anbieters. Das Workplace Technology-Team von Atlassian schützt unsere drahtlosen Netzwerke mithilfe der WPA2-AES-Authentifizierung und der PEAP-EAP-MSCHAPv2-Verschlüsselung. Wir authentifizieren uns in unserem drahtlosen Netzwerk über 802.1x und nutzen unseren internen Identitätsspeicher. Wir suchen regelmäßig nach nicht autorisierten WLAN-Zugangspunkten und führen eine Liste der gefundenen nicht autorisierten Zugangspunkte.
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 | Unsere Sicherheits- und Datenschutzrichtlinien
Verschlüsselung von Daten | Atlassian Trust Center
Datenverschlüsselung | Atlassian Cloud-Architektur und Betriebspraktiken |
| 2.4 Datenbereinigung und Geräteentsorgung | 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/ | Datenaufbewahrung und -löschung | Atlassian Trust Center
Speicherung verfolgen und Daten produktübergreifend verschieben | Atlassian-Support |
| 2.5 Physische Resilienz und Verfügbarkeit | Die physischen Sicherheitskontrollen in unseren Büros orientieren sich an unserer Richtlinie für physische und umgebungsbezogene Sicherheit, die sicherstellt, dass in unseren Umgebungen vor Ort und in der Cloud robuste physische Sicherheitsmaßnahmen implementiert werden. Die Richtlinie umfasst unter anderem Themen wie sichere Arbeitsbereiche, die Absicherung unserer IT-Ausrüstung an jedem Standort, die Beschränkung des Zutritts zu unseren Gebäuden und Büros auf geeignetes Personal und die Überwachung von physischen Ein- und Ausgangspunkten. Unsere Verfahren für die Sicherheit vor Ort umfassen die Besetzung des Empfangs während der Arbeitszeit, die Registrierung der Besucher und den Zugang zu nicht öffentlichen Bereichen unter Vorlage eines Ausweises. Wir arbeiten mit dem Bürogebäudemanagement zusammen, um den Zutritt nach den Geschäftszeiten zu regeln und Ein- und Ausgangspunkte sowohl an den Haupteingängen als auch Ladeflächen per Video zu überwachen.
Die Rechenzentren unserer Partner sind mindestens SOC2-konform. Diese Zertifizierungen beziehen sich auf eine Reihe von Sicherheitskontrollen, einschließlich physischer und umgebungsbezogener Sicherheit. Der Zugang zu den Rechenzentren ist auf autorisiertes Personal beschränkt und wird durch biometrische Maßnahmen zur Identitätsprüfung überprüft. Vor Ort sorgen außerdem Wachpersonal, Videoüberwachungsanlagen, Zugangsschleusen und weitere Einbruchsschutzmaßnahmen für Sicherheit.
Zusätzlich zu den oben genannten Maßnahmen veröffentlichen wir in Echtzeit den Verfügbarkeitsstatus unserer Services für unsere Kunden. Hierfür verwenden wir unser Produkt Statuspage. Wenn es Probleme bei einem unserer Produkte gibt, informieren wir unsere Kunden umgehend. | Physische Sicherheit | Atlassian Trust Center |
| Prinzip 3: Trennung zwischen Kunden |
| | Unsere Kunden greifen auf eine gemeinsame cloudbasierte IT-Infrastruktur zu, wenn sie die Produkte von Atlassian nutzen. Wir haben daher Maßnahmen für eine logische Trennung ergriffen, damit die Aktionen eines Kunden die Daten oder Services anderer Kunden nicht gefährden.
Je nach Anwendung verfolgt Atlassian hier unterschiedliche Ansätze. Im Fall von Jira und Confluence Cloud setzen wir auf das Konzept "Tenant Context" (Mandantenkontext), um Kunden logisch zu isolieren. Umgesetzt wird es im Anwendungscode und verwaltet über den von uns entwickelten "Tenant Context Service" (TCS). Das Konzept stellt Folgendes sicher:
- Die ruhenden Daten jedes Kunden werden logisch getrennt von denen der anderen Mandanten aufbewahrt.
- Alle Anfragen, die über Jira oder Confluence verarbeitet werden, verfügen über eine "mandantenspezifische" Ansicht, sodass andere Mandanten davon nicht betroffen sind.
Vereinfacht gesagt speichert der TCS für die einzelnen Mandanten der Kunden einen "Kontext". Der Kontext für jeden Mandanten ist mit einer eindeutigen ID verknüpft, die zentral vom TCS gespeichert wird, und enthält eine Reihe von Metadaten, die mit diesem Mandanten verknüpft sind (z. B. in welchen Datenbanken sich der Mandant befindet, welche Lizenzen der Mandant hat, auf welche Funktionen er zugreifen kann und eine Reihe anderer Konfigurationsinformationen). Wenn ein Kunde auf Jira Cloud oder Confluence Cloud zugreift, stellt der TCS die Metadaten anhand der Mandanten-ID zusammen und verknüpft diese dann mit allen Aktionen, die der Mandant im Sitzungsverlauf in der Anwendung vornimmt.
Der vom TCS bereitgestellte Kontext funktioniert dabei wie eine "Linse", durch die alle Interaktionen mit den Kundendaten getunnelt werden – und diese Linse ist immer auf einen einzigen Mandanten ausgerichtet. So ist sichergestellt, dass der Mandant nicht auf die Daten anderer Mandanten zugreifen kann oder ein Mandant durch seine Aktionen den Service eines anderen Mandanten beeinflusst.
Weitere Informationen zu unserer Cloud-Architektur sind als Teil unserer Cloud-Supportressourcen verfügbar. | Atlassian Cloud-Architektur und Betriebspraktiken | Atlassian Trust Center |
| Prinzip 4: Governance-Framework |
| | Atlassian ist sich bewusst, dass regulierte Unternehmen im Rahmen ihrer Risikobewertungen unsere internen Kontrollen, Systeme sowie die Datensicherheit und den Datenschutz für die Services überprüfen müssen. Atlassian unterzieht sich jährlich mehreren unabhängigen Audits durch Dritte, um unsere Abläufe und internen Kontrollen zu überprüfen.
Um unser aktuelles Compliance-Programm einzusehen, besuche bitte unser Compliance Resource Center. Hier kannst du auf alle herunterladbaren Verifizierungen und Zertifizierungen unserer Produkte zuzugreifen.
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. | Unsere Sicherheits- und Datenschutzrichtlinien
Compliance und Risikomanagement | Atlassian Trust Center
Unser Atlassian Trust Management System (ATMS) | Atlassian Trust Center
Zusatz zur Datenverarbeitung | Atlassian Trust Center |
| Prinzip 5: Betriebssicherheit |
| 5.1 Schwachstellenmanagement | Atlassian arbeitet stets daran, den Schweregrad und die Häufigkeit zu verringern, mit der Schwachstellen in unseren Produkten und Services auftreten. Zu diesem Zweck verfolgen wir einen facettenreichen Ansatz für das Schwachstellenmanagement, der ständig weiterentwickelt wird und sowohl automatisierte als auch manuelle Prozesse zur Identifizierung, Verfolgung und Behebung von Schwachstellen in unseren Anwendungen und Infrastrukturen umfasst.
Für alle unsere Produkte und Serviceangebote gibt es einen umfangreichen Prozess zur Fehlerbehebung. (Hierfür verwenden wir unser eigenes Produkt Jira, mit dem wir Vorgänge erfassen und Anfragen bearbeiten.) Diese Prozesse werden durch zahlreiche Richtlinien, Beratungsservices und SLOs zur Behebung von Sicherheits-Bugs untermauert, an die wir uns halten. Wir nehmen Fehlerberichte über unseren Support-Kanal, unser Bug-Bounty-Programm und über security@atlassian.com entgegen. Weitere Informationen zu unseren SLOs zur Behebung von Sicherheitsproblemen sind in unserem Trust Center (https://www.atlassian.com/trust) verfügbar (https://www.atlassian.com/trust/security/bug-fix-policy ).
Unser Atlassian-Sicherheitsteam verwendet verschiedene Methoden, um Sicherheitslücken sowohl in der internen als auch in der externen Infrastruktur zu erkennen. Jira-Tickets werden zur Nachverfolgung und Fehlerbehebung erstellt. Die Fälligkeitsdaten werden gemäß unserem SLO vergeben, basierend sowohl auf dem Schweregrad als auch auf der Quelle des Sicherheitsrisikos. Ein fortlaufender Prozess erstellt Tickets für identifizierte Sicherheitslücken für Systembesitzer. Unser Sicherheitsmanagementteam überprüft alle gemeldeten Sicherheitslücken und stellt sicher, dass geeignete Maßnahmen zur Behebung ergriffen werden.
Weitere Informationen sind in unserem Whitepaper Unser Ansatz für das Schwachstellenmanagement verfügbar.
Weitere Informationen zu unserem Ansatz für Sicherheitstests findest du auch in unserem Trust Center unter: Ansatz für externe Sicherheitstests | Atlassian | Schwachstellenmanagement | Atlassian Trust Center
Richtlinie zur Behebung von Sicherheitslücken | Atlassian Trust Center
Ansatz für externe Sicherheitstests | Atlassian Trust Center
Ansatz für das Schwachstellenmanagement | Atlassian Trust Center |
| 5.2 Schutzüberwachung | Angesichts immer komplexerer Bedrohungen müssen wir unseren Ansatz zum Vorfallmanagement weiterentwickeln. Daher hat Atlassian das Security Detections-Programm ins Leben gerufen. Erkennungen sind proaktive Suchen, die auf der SIEM-Plattform (Security Incident and Event Management) von Atlassian durchgeführt werden, um böswillige Aktivitäten zu ermitteln, die auf Atlassian und seine Kunden abzielen.
Unser Team für Erkennung und Reaktion konzentriert sich auf die regelmäßige Erstellung neuer Erkennungen, die Optimierung und Verbesserung bestehender Erkennungen sowie die Automatisierung von Erkennungsreaktionen. Dabei deckt es mehrere Bereiche ab, einschließlich Produkten, Angriffstypen und Protokollquellen, um sicherzustellen, dass die Erkennungen so effektiv und umfassend wie möglich sind.
Mit dem Programm möchten wir uns nicht nur vor aktuellen Bedrohungen schützen, sondern auch künftige Bedrohungen vorhersagen und uns adäquat auf sie vorbereiten. Unser Team für Erkennung und Reaktion hat außerdem ein Tool entwickelt, mit dem die erstellten Erkennungen standardisiert werden können. So erreichen wir hohe Konsistenz und Qualität bei den Erkennungen, die wir durchführen. Dies ist – soweit wir wissen – eine echte Branchenneuheit.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. 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 hier: https://www.atlassian.com/trust/security/detections-program | Atlassian Detections-Programm | Atlassian Trust Center
Nutzung von Protokollen | Atlassian Trust Center
Zusatz zur Datenverarbeitung | Atlassian Trust Center |
| 5.3 Vorfallmanagement | Atlassian verfolgt einen umfassenden Ansatz beim Umgang mit Sicherheitsvorfällen. Wir betrachten Sicherheitsvorfälle als etwas, das sich negativ auf die Vertraulichkeit, Integrität oder Verfügbarkeit von Kundendaten, Daten von Atlassian oder Atlassian-Services auswirken kann.
Wir haben ein klar definiertes internes Framework, das dokumentierte Playbooks für verschiedene Vorfallarten umfasst. Das Framework deckt die Schritte ab, die wir in allen Incident-Response-Phasen unternehmen müssen, um sicherzustellen, dass unsere Prozesse konsistent, wiederholbar und effizient sind. Dazu gehören die Erkennung, Analyse, Kategorisierung, Eindämmung und Behebung von Vorfällen sowie Wiederherstellungsmaßnahmen. Ein einheitliches Vorgehen wird dabei durch die Verwendung unserer eigenen Produkte unterstützt. Bei unseren Incident-Response-Prozessen kommen zum Beispiel Confluence, Jira und Bitbucket zum Einsatz.
- Wir verwenden Confluence, um Incident-Response-Prozesse an einem zentralen Ort zu erstellen, zu dokumentieren und zu aktualisieren.
- Wir verwenden Jira, um Tickets zu erstellen, mit denen der Fortschritt eines Incident-Response-Prozesses für potenzielle und tatsächliche Vorfälle von Anfang bis Ende verfolgt werden kann.
- Wir verwenden Bitbucket, wenn wir codebasierte Lösungen entwickeln, um auf bestimmte Grenzfälle zu reagieren, die bei bestimmten Vorfällen auftreten.
Dank einer umfassenden und zentralen Protokollierung und Überwachung unserer Produkte und Infrastruktur können wir potenzielle Vorfälle schnell erkennen. Dabei unterstützt uns ein Team hochqualifizierter, auf Abruf bereitstehender Vorfallmanager, die über umfassende Erfahrungen in der Koordination effektiver Gegenmaßnahmen verfügen. Wir ziehen außerdem externe Experten heran, die uns dabei unterstützen, Vorfälle möglichst effizient zu untersuchen und zu beheben.
Wir benachrichtigen unsere Kunden, wenn ihre Daten von einem bestätigten Vorfall betroffen sind. Außerdem verfügen wir über einen zuverlässigen Prozess für die Post-Mortem-Analyse von Vorfällen, um daraus zu lernen und so unsere Verfahren zu verbessern und es böswilligen Angreifern in Zukunft schwerer zu machen. Weitere Informationen findest du im Atlassian Trust Center in unserem Whitepaper Unser Ansatz für die Handhabung von Sicherheitsvorfällen. | Vorfallmanagement | Atlassian Trust Center
Zusatz zur Datenverarbeitung | Atlassian Trust Center |
| 5.4 Konfiguration und Änderungsmanagement | Unser Prozess für das Änderungsmanagement unterscheidet sich etwas von herkömmlichen Herangehensweisen. Herkömmliche Änderungsmanagementprozesse basieren auf einer pyramidenähnlichen Änderungskontrollhierarchie. Das heißt: Wenn jemand eine Änderung vornehmen möchte, muss er diese einem Gremium vorlegen, das diese schließlich genehmigt oder ablehnt.
Wir hingegen verfolgen einen Ansatz im Open-Source-Stil, den wir "Peer Review, Green Build" (PRGB) nennen. Im Gegensatz zu herkömmlichen Änderungsmanagementprozessen verlangt der PRGB-Ansatz, dass jede Änderung – sei es eine Codeänderung oder eine Infrastrukturänderung – von einem oder mehreren Mitarbeitern überprüft wird, um Probleme zu identifizieren, die möglicherweise durch die Änderungen entstehen können. Wir erhöhen die Anzahl der Prüfer basierend auf der Wichtigkeit der Änderung oder der Wichtigkeit der Systeme, die von der Änderung betroffen sind. Dabei vertrauen wir darauf, dass unsere Techniker Probleme identifizieren und sie kennzeichnen, bevor die Änderung durchgeführt wird. Dieser Prozess ist eine verlässliche, dynamische und anpassungsfähige Methode für das Änderungsmanagement in unserer Umgebung. Das "Green Build"-Element dieser Kontrolle bezieht sich auf einen erfolgreichen oder sauberen Build in unserem CI/CD-Prozess, der die neuen Änderungen enthält. Wenn die Änderung Komponenten umfasst, die die Integrations-, Funktions-, Unit- und Sicherheitstest nicht bestehen, wird der Build abgelehnt und der Prozess beginnt erneut bei der Änderungsanfrage, damit Probleme behoben werden 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 | Umgang mit Veränderungen in unserer Umgebung | Atlassian Trust Center
Wie du von der Qualitätssicherung zur Qualitätsunterstützung übergehst |
| Prinzip 6: Personalsicherheit |
| | Unternehmenswerte
Informationen zu den Unternehmenswerten von Atlassian sind hier verfügbar: https://www.atlassian.com/company/values
| Unternehmenswerte
Unternehmenswerte | Atlassian
|
| Hintergrundüberprüfungen bei Mitarbeitern
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. | Hintergrundüberprüfungen bei Mitarbeitern
Hintergrundüberprüfungen | Atlassian Trust Center |
| Sicherheitsschulungen für alle Atlassian-Mitarbeiter
Atlassian bietet Schulungen zur Informationssicherheit als Bestandteil des Onboarding-Trainings ("Tag 1") für Neueinsteiger und fortlaufend für alle Mitarbeiter an.
Zusätzlich zu diesen allgemeinen Schulungen zur Informationssicherheit werden für unsere Entwickler gezieltere Schulungen zum Thema sichere Codierung 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. Sicherheitsbewusstsein | Atlassian Trust Center | Sicherheitstraining für alle Atlassian-Mitarbeiter
Sicherheitsbewusstsein | Atlassian Trust Center |
| Prinzip 7: Sichere Entwicklung | 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 Verfahren in der Designphase gehören Bedrohungsmodellierung, Designprüfungen und eine regelmäßig aktualisierte Bibliothek mit Sicherheitsstandards, die gewährleistet, dass die entsprechenden 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 durch Schulungsprogramme zur Anwendungssicherheit und einer vom Sicherheitsteam verwalteten Sicherheitswissensdatenbank unterstützt.
Formale Betriebsbereitschafts- und Änderungskontrollprozesse stellen dann sicher, dass nur genehmigte Änderungen in die Produktion übernommen werden. Nach der Bereitstellung setzen wir regelmäßige automatische Schwachstellenscans und ein branchenführendes Bug-Bounty-Programm (Bug-Bounty-Programm von Atlassian | Bugcrowd ) ein, um die kontinuierliche Sicherheit unserer Anwendungen zu gewährleisten.
Darüber hinaus kannst du den SOC 2-Bericht von Atlassian überprüfen. Zweck des Berichts ist eine Evaluierung aller Systeme einer Organisation, die relevant für die Sicherheit, die Verfügbarkeit, die Verarbeitungsintegrität, die Vertraulichkeit und den Datenschutz sind. | Ergänzung zur Datenverarbeitung | Atlassian Trust Center |
| Prinzip 8: Sicherheit der Lieferkette | Wenn Atlassian Drittanbieter (einschließlich Auftragnehmer und Cloud-Serviceanbieter) beauftragt, möchten wir sicherstellen, dass diese Zusammenarbeit unsere Kunden oder ihre Daten in keiner Weise gefährdet. Zu diesem Zweck wird jede vorgeschlagene Zusammenarbeit mit Drittanbietern einer Überprüfung durch unsere Rechts- und Beschaffungsteams unterzogen. Wenn wir das Risiko einer Zusammenarbeit als hoch oder kritisch einstufen, führen unsere Sicherheits-, Risiko- und Compliance-Teams weitere Prüfungen durch. Außerdem setzen wir auf Folgeprüfungen, die je nach Risikoniveau bei Vertragsverlängerung oder jährlich durchgeführt werden.
Zudem verlangt Atlassian von seinen Anbietern, dass sie im Rahmen unserer Zusammenarbeit die Mindestsicherheitsanforderungen erfüllen. Diese werden durch die Aufnahme in unsere Lieferantenverträge durchgesetzt. Die Anforderungen variieren je nach Risikoniveau der Zusammenarbeit und umfassen Folgendes:
- SAML-Integration mit Atlassians Single-Sign-On-Plattform
- Verschlüsselung von Daten während der Übertragung und im Ruhezustand mithilfe nicht veralteter Algorithmen
- Ausreichende Protokollierungsmechanismen, um Atlassian relevante Informationen über potenzielle Sicherheitsvorfälle zur Verfügung zu stellen
| Risikomanagement für Lieferanten | Atlassian Trust Center
Atlassian SOC 2 | Seite 29 (Lieferantenmanagement) |
| Prinzip 9: Sichere Benutzerverwaltung |
| 9.1 Authentifizierung von Benutzern gegenüber Verwaltungsschnittstellen und Support-Kanälen | Atlassian ist der Ansicht, dass dies eine gemeinsame Verantwortung zwischen dem Kunden und Atlassian ist.
Authentifizierte Benutzer
Für alle Kundendaten gilt dieselbe Vertraulichkeitsstufe und der Zugriff auf diese Daten wird streng kontrolliert. Unsere Mitarbeiter und Auftragnehmer nehmen im Rahmen des Onboardings an einer Sensibilisierungsmaßnahme teil und erlernen den sicherheitsbewussten Umgang mit Kundendaten.
Innerhalb unseres Unternehmens haben ausschließlich autorisierte Atlassian-Mitarbeiter Zugriff auf die Kundendaten, die in unseren Anwendungen gespeichert sind. Die Authentifizierung erfolgt über individuelle passwortgeschützte öffentliche Schlüssel und Server akzeptieren nur eingehende SSH-Verbindungen von Atlassian und internen Rechenzentrumsstandorten. Der Zugriff ist grundsätzlich auf berechtigte Gruppen beschränkt, es sei denn, er wurde speziell angefragt und geprüft. Zudem ist eine Zwei-Faktor-Authentifizierung (2FA) erforderlich.
Unser für Wartungs- und Supportprozesse zuständiges Supportteam befolgt strenge Regeln zur Authentifizierung und Autorisierung. Der Zugriff auf die gehosteten Anwendungen und Daten erfolgt zur Überwachung der Anwendungsfunktionen und zur Durchführung der System- und Anwendungswartung oder nach Kundenanfrage über unser Supportsystem. Über unseren Consent Control Checker können Kunden zudem prüfen, welche Supporttechniker im Rahmen einer ausdrücklichen Zustimmung auf ihre Daten zugreifen dürfen.
Der unautorisierte oder missbräuchliche Zugriff auf Kundendaten wird als Sicherheitsvorfall eingestuft und über unseren Vorfallmanagementprozess verfolgt. Der Prozess umfasst Anweisungen zur Benachrichtigung betroffener Kunden, sofern es zu einem Richtlinienverstoß kam. | Kontrolle des Zugriffs auf Kundendaten | Atlassian Trust Center
Zusatz zur Datenverarbeitung | Atlassian Trust Center |
| 9.2 Trennung und Zugriffskontrolle innerhalb der Verwaltungsschnittstellen | Mit dieser AWS-Architektur hosten wir eine Reihe von Plattform- und Produktservices, die in unseren Lösungen zum Einsatz kommen. Dazu gehören Plattformfunktionen, die von mehreren Atlassian-Produkten wie Media, Identity, Commerce und unserem Editor gemeinsam genutzt werden, sowie produktspezifische Funktionen wie Jira-Issue-Service und Confluence Analytics.
Atlassian-Entwickler stellen diese Services über eine intern entwickelte Platform as a Service (PaaS) namens Micros bereit, die automatisch die Bereitstellung von Shared Services, Infrastruktur, Datenspeichern und deren Verwaltungsfunktionen, einschließlich Sicherheits- und Compliance-Kontrolle, orchestriert (siehe Abbildung 1 oben). Typischerweise besteht ein Atlassian-Produkt aus mehreren "containerisierten" Services, die mithilfe von Micros auf AWS bereitgestellt werden. Atlassian-Produkte verwenden Kernplattformfunktionen (siehe Abbildung 2 unten), die vom Anforderungsrouting bis hin zu binären Objektspeichern, Authentifizierung/Autorisierung, transaktionalen benutzergenerierten Inhalten (UGC) und Entitätsbeziehungsspeichern, Data Lakes, allgemeiner Protokollierung, Anforderungsablaufverfolgung, Beobachtbarkeits- und Analyseservices reichen.
Zusätzlich zu unserer Cloud-Infrastruktur haben wir eine mehrmandantenfähige Microservice-Architektur zusammen mit einer geteilten Plattform, die unsere Produkte unterstützt, aufgebaut und betrieben. In einer Mehrmandantenarchitektur bedient ein einziger Service mehrere Kunden, einschließlich Datenbanken und Recheninstanzen, die für die Ausführung unserer Cloud-Produkte erforderlich sind. Jeder Shard (im Wesentlichen ein Container – siehe Abbildung 3 unten) enthält die Daten für mehrere Mandanten, aber die Daten jedes Mandanten sind isoliert und für andere Mandanten nicht zugänglich. Bitte beachte, dass wir keine Einzelmandantenarchitektur anbieten.
Weitere Informationen erhältst du unter: https://www.atlassian.com/trust/reliability/cloud-architecture-and-operational-practices#cloud-infrastructure | Mehrmandantenarchitektur | Atlassian Cloud-Architektur und Betriebspraktiken
Zusatz zur Datenverarbeitung | Atlassian Trust Center |
| Prinzip 10: Identität und Authentifizierung |
| | Weitere Informationen zur Authentifizierung und Zugriffsverwaltung findest du unter 9.1 und 9.2. | N/A |
| Prinzip 11: Externer Schnittstellenschutz |
| | Weitere Informationen darüber, wie Atlassian Trust unsere Cloud-Kunden schützt, findest du unter Prinzip 5. | N/A |
| Prinzip 12: Sichere Serviceadministration |
| | Im Zusatz zur Datenverarbeitung von Atlassian verpflichten wir uns, Kundendaten zu schützen, einschließlich Zugriffskontrolle und Rechteverwaltung.
Weitere Informationen zur Authentifizierung und Zugriffsverwaltung findest du unter 9.1 und 9.2. | N/A |
| Prinzip 13: Prüfungsinformationen für Benutzer |
| | Jeglicher Zugriff auf die Kundenanwendung wird protokolliert. Jede Interaktion mit der Benutzeroberfläche wird im Audit-Protokoll der Anwendung aufgezeichnet.
Atlassian schränkt den privilegierten Zugriff auf unseren Atlassian Account Identity Store sowie auf andere Verwaltungssysteme für die Informationssicherheit ein, protokolliert und überwacht ihn.
Die Protokolle werden in einem logisch separierten System gespeichert und der Schreibzugriff auf die Protokolle wird auf Mitglieder des Sicherheitsteams beschränkt. Wenn bestimmte Aktionen oder Ereignisse in den Protokollen identifiziert werden, werden Benachrichtigungen an das Sicherheitsteam oder den Servicedesk gesendet. Unser zentraler Logging-Service (der die Atlassian Cloud Platform, JIRA, Confluence und Bamboo abdeckt) ist für automatische Analysen in unsere Infrastruktur für Sicherheitsanalysen integriert. Es werden Warnmeldungen erstellt, um potenzielle Probleme zu identifizieren.
Bei Bitbucket werden Audit-Protokolle für die Untersuchung nach einem Vorfall verwendet. Die Konfiguration des verwalteten Services von Puppet und das deklarative Konfigurationsformat stellen sicher, dass alle Systemkonfigurationen, die durch seine Manifeste verwaltet werden, bei jeder Ausführung richtig konfiguriert werden. Es gibt Überwachungswarnungen, falls Puppet auf einem bestimmten Server nicht ausgeführt wird. Zu unseren internen und externen Schwachstellenscannern gehören Benachrichtigungen über unerwartete offene Ports oder andere Konfigurationsänderungen (z. B. TLS-Profile von Listening-Servern).
Weitere Informationen findest du unter: Atlassian Access | Sicherheit und SSO für Jira, Confluence usw.
Intern für Atlassian werden Protokolle in einem logisch getrennten System gespeichert, und der Schreibzugriff auf die Protokolle ist auf Mitglieder des Sicherheitsteams und unseres Beobachtungsteams beschränkt. Unser zentraler Protokollierungsservice ist für automatische Analysen in unsere Infrastruktur für Sicherheitsanalysen integriert. Es werden Warnmeldungen erstellt, um potenzielle Probleme zu identifizieren.
Für Atlassian Cloud-Kunden sind Audit-Protokolle für Änderungen an der Organisation als Teil von Atlassian Access verfügbar. Mit Audit-Protokollen hast du Einblick in die Admin-Aktionen für Nutzer, Gruppen, Berechtigungen usw. Weitere Informationen findest du hier: https://support.atlassian.com/security-and-access-policies/docs/track-organization-activities-from-the-audit-log/
Die Cloud-Produkte von Atlassian verfügen auch über eine eigene Audit-Protokollierung für produktspezifische Änderungen. | N/A |
| Prinzip 14: Sichere Nutzung des Service |
| | Atlassian ist der Ansicht, dass dies eine gemeinsame Verantwortung zwischen dem Kunden und Atlassian ist.
Es gibt eine Reihe weiterer Ressourcen, auf die wir in diesem Dokument hingewiesen haben, mit denen du dich näher über unseren Ansatz für das Schwachstellenmanagement oder das Thema Sicherheit im Allgemeinen informieren kannst.
| N/A |