Sicherheits- und Backup-Richtlinie

RASCI Matrix
R	Responsible – Wer ist verantwortlich für die Durchführung der entsprechenden Aufgabe?	Diese Rollen und Verantwortlichkeiten werden während des Onboardings des Kunden festgelegt und in den Verträgen entsprechend benannt. Sie werden von allen Stakeholdern UNTERSCHRIEBEN.
A	Accountable (auch Approver) – Wer ist verantwortlich für die gesamte Aufgabe und wer ist verantwortlich dafür, was gemacht wurde?
S	Support – Wer leistet Support während der Durchführung der Aktivität / des Prozesses / der Services?
C	Consulted – Wer kann für die Aufgabe wertvolle Tipps geben oder beraten?
I	Informed – Wer muss über den Fortschritt der Aufgabe oder Entscheidungen informiert werden?

Valiantys-Support

		Kunde	Valiantys	Atlassian	App-Anbieter
Tools-Administration	Upgrade Apps (früher Add-ons) (eine App / ein Add-on direkt in Jira, Confluence etc. upgraden)	R	A	–	S
	Konfigurationsobjekte (Workflows, Benachrichtigungen etc.) (Konfigurationsobjekte innerhalb von Jira, Confluence etc. verwalten)	R	A	S	S
	Erstellung/Modifizierung/Löschung von Projekten/Spaces/Repositories/Benutzerverzeichnissen (Verwaltung von Projekten, Spaces, Repositories, Benutzerverzeichnissen in Jira, Confluence etc.)	R	A	S	S
	Benutzerzugriffsverwaltung (Nutzer in Jira, Confluence etc. verwalten)	R	A	–	–
	Funktionales Problemmanagement (Globales Problem- und Projektmanagement)	R	A	S	S
	Produkt- und App-Lizenzverwaltung (Lizenzinstallation für Atlassian-Produkte und Add-ons)	R	A	–	–
Infrastruktur	Installation der Umgebung (Installation von Jira, Confluence etc.)	R	I	–	–
	Patch-Management Atlassian-Anwendung und Apps/Add-ons (Deployment von Patches für Apps/Add-ons, Jira, Confluence etc.)	R (Silver/Gold) A (Platinum)	S (Silver/Gold) R (Platinum)	S	S
	Patch-Management OS und Middleware (RProxy, Datenbank, Mailserver etc.) (Deployment von OS- und Middleware-Patches)	R	I	–	–
	Upgrade OS und Middleware (RProxy, Datenbank, Mailserver etc.) (Upgrade von OS und Middleware)	R	I	–	–
	Upgrade von Atlassian-Produkten (Upgrade von Jira, Confluence etc.)	R	S	S	S
	System- und Anwendungsperformance (Anwendungsperformance)	R	S	S	S
	System- und Anwendungsüberwachung (Überwachung von Health und Performance des Systems und der Anwendungen)	R	I	–	–
	Anwendungsausfall (Anwendung oder System reagiert nicht / nicht verfügbar)	R	S	S	S
	Sicherheitsvorfall (Ereignisse, die Auswirkungen auf Ihre Sicherheit oder die Kontrolle Ihrer Daten haben können – CVE-Release, Bekanntmachungen etc.)	R	S	S	S
	Probleme bei ausgehenden E-Mails (Vorfälle, die Auswirkungen auf ausgehende E-Mails von Ihrem Jira, Confluence etc. haben)	R	S	S	S
	Probleme bei eingehenden E-Mails (Vorfälle, die Auswirkungen auf eingehende E-Mails bei Ihrem Jira, Confluence etc. haben)	R	S	S	S
Angebotsmanagement	Verwaltung der Support-Kontakte (Management der angegebenen Kontakte im Valiantys-Support-Portal)	R	A	–	–
	Supportangebot Reporting (Übermittlung eines monatlichen Berichts)	I	R	–	–
	Supportangebot Follow-up-Meetings (Von Valiantys geplantes Follow-up-Meeting)	I nur für Platinum	R nur für Platinum	–	–

Valiantys Cloud

		Kunde	Valiantys	Cloud-Anbieter	Monitoring-Anbieter	Atlassian	App-Anbieter
Infrastruktur	Installation der Umgebung (Installation von Atlassian-Anwendungen – Jira, Confluence etc.– in Server-, Cold Standby- oder Data Center-Architekturen)	I	R	S	–	S	–
	VPN-Konfiguration (Sichere Verbindung zwischen VPC des Kunden und dem Kundennetzwerk über ein VPN)	R	R	S	–	–	–
	Patch-Management der Atlassian-Anwendungen (Deployment von Patches für die Anwendungen – Jira, Confluence etc.– oder die Apps/Add-ons)	I	R	–	–	S	S
	Upgrades der Atlassian-Anwendungen (Jira, Confluence etc.)	R	A	–	–	S	S
	System- und Anwendungsperformance (Management der Ressourcen – CPU, RAM – der Umgebungen, auf denen die Atlassian-Anwendungen laufen)	A	R	S	S	S	S
	System- und Anwendungsüberwachung (Überwachung von Health und Performance des Systems und der Anwendungen)	I	R	S	S	–	–
	Patch-Management des Systems und der Middleware (Deployment von Patches auf Ubuntu OS und/oder Middleware-Anwendungen – Apache, PostgreSQL, Postfix etc.)	I	R	S	–	–	–
	System-/ Middleware-Upgrades (Ubuntu OS, Apache, DB, Postfix etc.)	I	R	–	–	–	–
	Anwendungsausfall (System oder Atlassian-Anwendung reagiert nicht / nicht verfügbar)	I	R	A	–	S	S
	Sicherheitsvorfall (Ereignisse, die Auswirkungen auf die Sicherheit oder die Kontrolle Ihrer Daten haben können – CVE-Release, Bekanntmachungen etc.)	I	R	S	–	S	S
	Probleme bei ausgehenden E-Mails (Vorfälle, die Auswirkungen auf ausgehende E-Mails von Atlassian-Anwendungen haben – Jira, Confluence etc.)	I	R	S	–	S	S
	Probleme bei eingehenden E-Mails (Vorfälle, die Auswirkungen auf eingehende E-Mails bei den Atlassian-Anwendungen haben – Jira, Confluence etc.)	I	R	–	–	S	S
Angebotsmanagement	Verwaltung der technischen Support-Kontakte (Verwaltung der angegebenen Kontakte im Valiantys-Support-Portal)	R	A	–	–	–	–
	Reporting Cloud-Angebote (Monitoring/Verfügbarkeitsberichte)	I	R	–	–	–	–

Definitionen

Begriff	Beschreibung
AWS-Regionen und Availability Zones	Amazon EC2 wird an mehreren Standorten weltweit gehostet. Diese Standorte bestehen aus AWS-Regionen und Availability Zones. Jede Region ist ein separater geografischer Bereich. Availability Zones sind mehrere isolierte Standorte innerhalb jeder Region.
VPC und Subnetze	Eine Virtual Private Cloud (VPC) ist ein konfigurierbarer Pool gemeinsam genutzter Computerressourcen, die innerhalb einer Public Cloud-Umgebung zugewiesen werden und ein bestimmtes Maß an Isolation zu anderen Organisationen (im Folgenden “Benutzer”), die diese Ressourcen nutzen, bietet. VPC-Benutzer werden von anderen Benutzern derselben Cloud (sowohl anderen VPC-Benutzern als auch anderen Benutzern der Public Cloud) isoliert. Diese Isolation wird in der Regel durch die Zuweisung eines Private IP-Subnetzes und eines virtuellen Kommunikationskonstruktes pro Benutzer (zum Beispiel ein VLAN oder eine Reihe von verschlüsselten Kommunikationskanälen) erreicht. Bei einer VPC-Lösung wird der zuvor beschriebene Mechanismus, der für die Isolation innerhalb der Cloud sorgt, durch eine VPN-Funktion ergänzt (wieder zugewiesen pro VPC-Benutzer), die durch Authentifizierung und Verschlüsselung den Fernzugriff der Organisation auf dessen VPC-Ressourcen sichert. Faktisch arbeitet eine Organisation, die diesen Service nutzt, dank der beschriebenen Isolationsebenen in einer “virtuell privaten“ Cloud, also ganz so, als würde die Cloud-Infrastruktur nicht mit anderen Benutzern gemeinsam genutzt werden: daher die Bezeichnung Virtual Private Cloud (VPC).
Sicherheitsgruppe	Eine Sicherheitsgruppe dient als virtuelle Firewall zur Steuerung von Datenverkehr für eine oder mehrere Instanzen. Wenn Sie eine Instanz starten, können Sie der Instanz eine oder mehrere Sicherheitsgruppen zuweisen. Sie fügen zu jeder Sicherheitsgruppe Regeln hinzu, die den Datenaustausch mit den zugeordneten Instanzen gestatten. Sie können die Regeln für eine Sicherheitsgruppe jederzeit ändern. Neue Regeln gelten automatisch für alle Instanzen, denen Sie die Sicherheitsgruppe zugewiesen haben. Bei der Entscheidung, ob zugelassen wird, dass Datenverkehr eine Instanz erreicht, bewerten wir alle Regeln aus allen Sicherheitsgruppen, die der Instanz zugewiesen sind.
Elastic IP-Adressen	Eine Elastic IP-Adresse ist eine statische IP-Adresse, die für dynamisches Cloud-Computing konzipiert ist. Ihrem AWS-Konto wird eine Elastic IP-Adresse zugewiesen. Mit einer Elastic IP-Adresse können Sie Ausfälle bei Instanzen oder Software maskieren. Weisen Sie dazu die Adresse einer anderen Instanz in Ihrem Konto zu.

Rechenzentrumsstandorte

Amazon Web Services	Orange Flexible Engine
USA Ost Nord-Virginia, Ohio	France Pantin, Aubervilliers und Saint Denis
USA West Nord-Kalifornien, Oregon
Kanada Zentral
Europa Frankfurt, Dublin, London, Paris, Stockholm

Standards

Valiantys richtet sich nach der ISO-Norm 27001 – unterstützt durch starke Prozesse, Dokumentation und Unternehmenskultur. Die von uns verwendeten Rechenzentren haben die folgenden Akkreditierungen:

Amazon Web Services	Orange Flexible Engine
SOC 1 / SSAE 16 / ISAE 3402 (früher SAS 70) – Bericht steht nach Unterzeichnung eines NDAs zur Verfügung SOC 2 SOC 3 FISMA, DIACAP und FedRAMP ISO 9001 / ISO 27001 ITAR FIPS 140-2 MTCS Level 3 GDPL (Einzelheiten unter: https://aws.amazon.com/blogs/security/aws-and-the-general-data-protection-regulation/) Siehe auch https://aws.amazon.com/de/compliance/ für weitere Einzelheiten.	ISAE 3402 Type II (früher SAS 70) SOC 1 Type II SOC 2 Type II ISO 9001 / ISO 27001 ISO 14001:2004 ISO 22301 OHSAS 18001 HDA/HADS PCI-DSS Siehe https://cloud.orange-business.com/en/3rd-az-in-paris-region/

Physische Sicherheit und Umgebungssicherheit

Branderkennung und -unterdrückung

Amazon Web Services

Orange Flexible Engine

Automatische Branderkennungs- und Brandunterdrückungsanlagen wurden installiert, um das Risiko für Brände zu reduzieren. Die Branderkennungsanlage verwendet Rauchsensoren in allen Rechenzentrumsumgebungen, mechanischen und elektrischen Infrastrukturräumen sowie Kühl- und Generatorräumen. Diese Bereiche werden entweder durch Wassersprinkleranlagen, doppelt verriegelte, vorgesteuerte Sprinkleranlagen (Preactionanlagen) oder Gaslöschanlagen geschützt.

Der Brandschutz wird durch zwei komplementäre Systeme gewährleistet: hochsensible Rauchmelder und eine Wassernebel-Löschanlage. Überwachungszentrum

Stromversorgung

Amazon Web Services

Orange Flexible Engine

Die Stromversorgungssysteme der Rechenzentren wurden so entwickelt, dass sie vollständig redundant sind und ohne Beeinträchtigung des Betriebs gewartet werden können – 24 Stunden am Tag sieben Tage die Woche. Eine unterbrechungsfreie Stromversorgung (USV) dient im Falle eines Stromausfalls kritischen und wichtigen Verbrauchern als Reservestromversorgung. Rechenzentren verwenden Generatoren, um Reservestrom für die gesamte Einrichtung zur Verfügung zu stellen.

Energiemanagement: Um den ökologischen Fußabdruck der Infrastrukturen zu reduzieren, nutzt Orange umweltfreundliche Rechenzentren. Um Stromausfälle zu verhindern, wird die Stromversorgung verdoppelt. Außerdem verfügen die Standorte über autonome Generatoren. Redundante Versorgungssysteme Redundante Niederspannungsverteilung Generator – mindestens 72 Stunden autonomer Betrieb Wechselrichter

Klimatisierung und Temperatur

Amazon Web Services

Orange Flexible Engine

Eine Klimatisierung ist erforderlich, um eine konstante Betriebstemperatur für Server und andere Hardware zu halten, eine Überhitzung zu vermeiden und das Risiko von Serviceausfällen zu verringern. Rechenzentren werden so klimatisiert, dass die atmosphärischen Bedingungen immer optimal sind. Personal und Systeme überwachen und kontrollieren Temperatur und Luftfeuchtigkeit, damit sie auf dem richtigen Niveau bleiben.

N+1-Redundanz bedeutet, dass der Ausfall einer Klimaanlage keine Auswirkungen auf das gesamte System der Kälteerzeugung hat.

Stilllegung von Speichermedien

Amazon Web Services

Orange Flexible Engine

Wenn ein Speichergerät das Ende seines Lebenszyklus erreicht hat, umfassen die Verfahren von AWS einen Stilllegungsprozess, der verhindert, dass Kundendaten in die Hände unbefugter Personen gelangen. AWS nutzt die in DoD 5220.22-M (“National Industrial Security Program Operating Manual“) oder in NIST 800-88 (“Guidelines for Media Sanitization”) beschriebenen Techniken, um Daten im Rahmen der Stilllegung zu vernichten. Alle stillgelegten Magnetspeicher werden entmagnetisiert und gemäß Industriestandards physisch zerstört.

Schutz freigegebener Kundendaten Auf Kundendaten, die sich auf freigegebenen Ressourcen befinden, können andere Kunden nicht zugreifen. Dieser Schutz wird durch die internen Mechanismen der von Orange verwendeten Produkte gewährleistet. OpenStack verfügt beispielsweise über einen internen Prozess, um eine Ressource zu löschen, bevor sie einem anderen Kunden zugewiesen wird.Löschung von Kundendaten bei Vertragsbeendigung Wird ein Vertrag beendet, werden alle dem Kunden zugewiesenen Ressourcen wieder freigegeben. Die Kundendaten werden unbrauchbar gemacht, wie im obigen Abschnitt beschrieben.Sichere Entsorgung oder Wiederverwendung von Ausrüstung Alle Ausrüstungsgegenstände, die Speichermedien enthalten, werden überprüft, um zu gewährleisten, dass sensible Daten und lizenzierte Software entfernt oder vor der Entsorgung sicher überschrieben wurden. Orange verfügt über Sicherheitsrichtlinien, die die Verfahren für die Bereinigung und Entsorgung von Speichermedien regeln.

Physischer Zugriff auf das Rechenzentrum

Amazon Web Services

Orange Flexible Engine

Die AWS-Rechenzentren sind hochmodern. Die verwendeten architektonischen und technischen Lösungen sind innovativ. Amazon verfügt über langjährige Erfahrung in der Planung, im Bau und Betrieb von großen Rechenzentren. Diese Erfahrung wurde auf die AWS-Plattform und -Infrastruktur übertragen. AWS-Rechenzentren sind in unauffälligen Gebäuden untergebracht. Professionelles Sicherheitspersonal überwacht sowohl im Umkreis als auch an den Eingangspunkten den physischen Zutritt mithilfe von Videoüberwachung, Einbruchmeldeanlagen und anderen elektronischen Mitteln. Autorisiertes Personal muss an mindestsens zwei Stellen eine Zwei-Faktor-Authentifizierung durchlaufen, um Zutritt zu den Ebenen des Rechenzentrums zu erlangen. Alle Besucher und Auftragnehmer müssen sich ausweisen und werden von autorisiertem Personal angemeldet und durchgängig begleitet. Zugang und Informationen zu den Rechenzentren erhalten von AWS nur Beschäftigte und Auftragnehmer, bei denen eine legitime geschäftliche Anforderung für derartige Privilegien besteht. Besteht bei einem Mitarbeiter keine geschäftliche Anforderung mehr, die diese Privilegien rechtfertigen, wird sein Zugang unverzüglich entzogen, auch wenn er weiterhin bei Amazon oder Amazon Web Services beschäftigt ist. Der physische Zutritt durch AWS-Mitarbeiter zu den Rechenzentren wird erfasst und regelmäßig überprüft.

Physische Sicherheit: strenge Zugangskontrollen für Rechenzentren, einschließlich Identifizierung von Personen nach erteilter Genehmigung zum Betreten der Datenräume. Die Standorte werden rund um die Uhr mit einer dreifachen Zugangskontrolle und Videoüberwachungssystemen geschützt und überwacht. Toleranz gegenüber Ausfällen und Wartung – Die verwendeten technischen Architekturen ermöglichen es, die folgenden Betriebsanforderungen zu erfüllen: Keine Beeinträchtigungen auf die Verbraucher bei der ersten Störung Hohe Ausfalltoleranz – bis zu zwei große Störungen ohne Beeinträchtigungen Keine Betriebsunterbrechung während Wartungsarbeiten Die eingesetzten Verwaltungsmodi und Prozesse gewährleisten die Sicherheit des Personals, des Gebäudes und der darin befindlichen Ausrüstung.

Business Continuity Management

Verfügbarkeit

Amazon Web Services

Orange Flexible Engine

Die Rechenzentren befinden sich in Clustern in verschiedenen Regionen weltweit. Alle Rechenzentren sind online und stehen Kunden zur Verfügung; kein Rechenzentrum ist außer Betrieb (“kalt”). Bei einem Ausfall wird der Verkehr von Kundendaten mithilfe automatisierter Prozesse vom betroffenen Bereich auf einen anderen umgeleitet. Für wichtige Anwendungen gilt der N+1-Standard, damit im Falle eines Ausfalls eines Rechenzentrums, ausreichende Kapazitäten zur Verfügung stehen, um den Datenverkehr auf die verbleibenden Standorte aufzuteilen

Die Infrastruktur unserer Cloud-Services ist über mehrere Standorte (oder in vorübergehenden Ausnahmefällen über mehrere Computerräume) hinweg vollständig redundant. Hochverfügbarkeitsmechanismen machen lokale Ausfälle transparent: Netzwerk (Internetzugriff, VPN-Zugriff, Firewall), Administrationsportal, Virtualisierung, Speicher etc. Sicherungskopien (Konfigurationen, Kunden-Backups) werden priorisiert auf Remote-Standorten repliziert. Kommt es am Produktionsstandort zu einer größeren Störung, wird damit die Verfügbarkeit der Daten garantiert. Je nach Service werden Remote-Backups für Kunden als Option vorgeschlagen. Die Orange Cloud-Services werden von verschiedenen Plattformen betrieben. Wenn ein Betriebsstandort gänzlich unerreichbar ist, bleibt die Betriebskontinuität für die Cloud-Dienste gewährleistet. Die betriebliche Kontinuität wird regelmäßig durch Simulationen getestet.

Unternehmensweite Überprüfung durch die Geschäftsführung

Amazon Web Services	Orange Flexible Engine
Die interne Auditgruppe von Amazon hat vor Kurzem die Resilienzpläne für die AWS-Services überprüft. Diese werden auch regelmäßig von den Mitgliedern des Senior Executive Managment-Teams sowie des Prüfungsausschusses des Aufsichtsrats (Audit Committee of the Board of Directors) überprüft.	Der Sicherheitsausschusses, zu dem auch die Sicherheitsmanager (Engineering und Operations) und der Produktmanager gehören, überprüft bei seinem monatlichen Meeting: die Risiken die Sicherheitsindikatoren den Aktionsplan für Sicherheit die Sicherheitsstrategie

Netzwerksicherheit

Sichere Netzwerkarchitektur

Amazon Web Services

Orange Flexible Engine

Netzwerkgeräte wie Firewalls und andere Komponenten überwachen und steuern die Kommunikation an der äußeren Netzwerkgrenze und an den wichtigsten internen Grenzen innerhalb des Netzwerks. Diese Komponenten verwenden Regelsätze, Zugriffskontrolllisten (Access Control Lists, ACL) und Konfigurationen, um den Informationsfluss zu bestimmten Informationssystemdiensten zu ermöglichen. ACLs oder Datenverkehrsflussrichtlinien werden in jeder verwalteten Schnittstelle hinterlegt. Sie verwalten und ermöglichen den Datenverkehrsfluss. ACL-Richtlinien werden von Amazon Information Security genehmigt. Die Richtlinien werden automatisch mithilfe des ACL-Manage-Tools von AWS übertragen, um zu gewährleisten, dass die verwalteten Schnittstellen die aktuellsten ACLs verwenden.

Die Architekturen verwenden dasselbe Model, um Trust-Bereiche zu trennen, einschließlich des Backends (Orange intern) und des Frontends, das die Cloud-Services der Kunden unterstützt. Die Partitionierung von Backend und Frontend ist physisch, was bedeutet, dass einige Server für das Backend und andere für das Frontend zuständig sind. Innerhalb eines Trust-Bereichs sorgen Sicherheitszonen für eine logische Partitionierung durch die Implementierung bestimmter Funktionen: Virtualisierung (virtuelle Maschinen, virtuelle Firewall, virtuelle Load Balancer, virtuelle Router / VRF) VLANs (802.1Q) virtuelle Netzwerke (VPN IPSec, SSL) virtueller Speicher (virtuelle Treiber) Diese logische Partitionierung gewährleistet die Isolierung der verschiedenen Kundenumgebungen voneinander. Die Kommunikation (Netzwerkdurchfluss) zwischen den verschiedenen Sicherheitszonen wird systematisch durch Firewalls kontrolliert (Stateful Filtering). Die lokale Konfiguration der verschiedenen Komponenten erfolgt auch so, dass die Partitionierung und Sicherheit gestärkt wird (z. B. ACL in Routern).

Sichere Zugriffspunkte

Amazon Web Services

Orange Flexible Engine

AWS hat strategisch eine begrenzte Anzahl von Zugriffspunkten zur Cloud eingerichtet, um eine umfassendere Überwachung der eingehenden und ausgehenden Kommunikation und des Netzwerkdatenverkehrs zu ermöglichen. Diese Kundenzugriffspunkte werden als API-Endpunkte bezeichnet und ermöglichen einen sicheren HTTP-Zugriff (HTTPS). Damit können Sie eine sichere Kommunikationssitzung mit Ihren Speicher- oder Recheninstanzen innerhalb von AWS einrichten. Um Kunden zu unterstützen, die zur Einhaltung der FIPS-Verschlüsselungsstandards verpflichtet sind, sind die SSL-terminierenden Load Balancer in der AWS GovCloud (US) FIPS 140-2-konform. Darüber hinaus hat AWS Netzwerkgeräte implementiert, die die Schnittstellenkommunikation mit den Internetdienstanbietern (Internet Service Provider, ISPs) ermöglichen. AWS nutzt eine redundante Verbindung zu mehr als einem Kommunikationsdienst an jedem internetseitigen Edge des AWS-Netzwerks. Diese Verbindungen haben jeweils dedizierte Netzwerkgeräte.

Flexible Engine erbringt Services, die es einem Benutzer ermöglichen, eine virtualisierte Infrastruktur über eine gemeinsame physische Infrastruktur für alle Benutzer zu schaffen. Die implementierten Virtualisierungsmechanismen ermöglichen eine strenge logische Partitionierung der virtualisierten Ressourcen des Kunden (eine pro Kunde). Der Zugriff auf die Ressourcen eines Tenants erfolgt über die OpenStack-APIs, die eine starke (Login/Passwort/Token) und eine sichere (bei SSL über HTTPS) Authentifizierung implementieren. Die Kunden verbinden sich mit der Cloud-Umgebung für administrative Zwecke oder um auf Anwendungsdienste zuzugreifen. Die Umgebungen können über das Internet und/oder einem privaten Netzwerk (VPN-Client) erreicht werden, je nach den vom Kunden gewählten Funktionen und Optionen. Der Kundenzugang ist immer durch SSL/TLS (HTTPS oder SSH-Flows) gesichert. Die Authentifizierung gegenüber einem Server (Administrationsportale, Anwendungsserver) erfolgt routinemäßig über ein X.509-Serverzertifikat, das von einer anerkannten Zertifizierungsstelle erteilt wurde. Die Authentifizierung eines Kunden erfolgt mithilfe einer Login/Passwort-Kombination, die zuvor sicher übertragen wurde. Bei einigen Produkten ist es möglich über ein X.509-Client-Zertifikat eine starke Authentifizierung zu implementieren, bei der ein Token ein Einmalpasswort erzeugt. Der Netzwerkdurchfluss wird systematisch verschlüsselt (über einen AES-Algorithmus).

Schutz während der Übertragung

Amazon Web Services

Orange Flexible Engine

Sie können sich mit einem AWS-Zugriffspunkt über HTTPS mithilfe von Secure Sockets Layer (SSL) verbinden. Dabei handelt es sich um ein kryptografisches Protokoll, das entwickelt wurde, um vor Abhörmaßnahmen, Manipulation und Fälschung von Nachrichten zu schützen. Für Kunden, die noch mehr Netzwerksicherheit benötigen, bietet AWS die Amazon Virtual Private Cloud (VPC), bei der ein privates Subnetz innerhalb der AWS-Cloud zugewiesen wird, sowie die Möglichkeit, ein IPsec Virtual Private Network (VPN)-Gerät zu nutzen, um einen verschlüsselten Tunnel zwischen der Amazon VPC und Ihrem Rechenzentrum einzurichten.

Die Kunden verbinden sich mit der Cloud-Umgebung für administrative Zwecke oder um auf Anwendungsdienste zuzugreifen. Die Administrationsflows des Kunden werden systematisch von Protokollen gesichert, um die Authentifizierung, die Vertraulichkeit und die Integrität zu gewährleisten (SSLv3/TLS, AES256 etc.). Die Zugriffsmethoden variieren je nachdem, welche Funktionen und Optionen der Kunde gewählt hat. Die Sicherheit der Serviceflows hängt vom Angebot ab, aber in der Regel wird der Austausch durch SSL/TLS-Verbindungen gesichert. Virtual Private Cloud (VPC)-Funktionen, die von der Neutron OpenStack-Komponente bereitgestellt werden, ermöglichen eine logische Partitionierung der Kommunikation im Benutzernetzwerk. Jede Form von Netzwerkverkehr, die nicht von vornherein auf dem Tenant des Kunden zugelassen ist, wird von den Geräten, die das virtuelle Netzwerk des Clients unterstützen, nicht verarbeitet. Damit wird der Einsatz von Spoofing-Technologien verhindert. Der gesamte Datenverkehr des Tenants wird aufsteigend / Richtung Norden geroutet, wobei das Routing auf mehreren Sicherheitsebenen geschützt durch hochmoderne Firewalls nach Industriestandards erfolgt.

Fehlertolerantes Design

Amazon Web Services

Orange Flexible Engine

AWS hat seine Systeme so konstruiert, dass System- oder Hardware-Ausfälle mit minimalen Beeinträchtigungen für den Kunden toleriert werden. Die Rechenzentren befinden sich in Clustern in verschiedenen Regionen weltweit. Alle Rechenzentren sind online und stehen Kunden zur Verfügung; kein Rechenzentrum ist außer Betrieb (“kalt”). Bei einem Ausfall wird der Verkehr von Kundendaten mithilfe automatisierter Prozesse vom betroffenen Bereich auf einen anderen umgeleitet. Für wichtige Anwendungen gilt der N+1-Standard, damit im Falle eines Ausfalls eines Rechenzentrums, ausreichende Kapazitäten zur Verfügung stehen, um den Datenverkehr auf die verbleibenden Standorte aufzuteilen.

TIER-Klassifizierung – Die Rechenzentren für Flexible Engine sind so gebaut und werden so betrieben, dass sie die Anforderungen von TIER III erfüllen. Toleranz gegenüber Ausfällen und Wartung – Die verwendeten technischen Architekturen ermöglichen es, die folgenden Betriebsanforderungen zu erfüllen: Keine Beeinträchtigungen auf die Verbraucher bei der ersten Störung. Hohe Ausfalltoleranz – bis zu zwei große Störungen ohne Beeinträchtigungen. Keine Betriebsunterbrechung während Wartungsarbeiten. Die eingesetzten Verwaltungsmodi und Prozesse gewährleisten die Sicherheit des Personals, des Gebäudes und der darin befindlichen Ausrüstung.

Netzwerküberwachung und -schutz

Amazon Web Services

Orange Flexible Engine

AWS verwendet eine Vielzahl automatisierter Überwachungssysteme, um eine hohe Leistung und Verfügbarkeit der Services zu bieten. Die Überwachungstools von AWS sind so konzipiert, dass sie ungewöhnliche oder unberechtigte Aktivitäten und Vorgänge an den eingehenden und ausgehenden Kommunikationspunkten erkennen. Diese Tools überwachen die Server- und Netzwerknutzung, die Port-Scanning-Aktivitäten, die Anwendungsnutzung und Versuche unbefugten Eindringens. Die Tools bieten die Möglichkeit, individuelle Schwellenwerte für ungewöhnliche Aktivitäten festzulegen. Die Sicherheits- und Überwachungstools von AWS helfen dabei, verschiedene Arten von Denial-of-Service-Angriffen (DoS) zu erkennen. Dazu gehören verteilte (“distributed”), Flooding- und Software-/logische Angriffe. Wird ein DoS-Angriff erkannt, wird der Vorfallreaktionsprozess von AWS eingeleitet. Abgesehen von den DoS-Präventionstools schützen auch redundante Telekommunikationsanbieter in jeder Region sowie zusätzliche Kapazitäten vor möglichen DoS-Angriffen. Das AWS-Netzwerk bietet umfassenden Schutz vor traditionellen Netzwerksicherheitsproblemen. Darüber hinaus können Sie noch weitere Schutzmaßnahmen ergreifen: Im Folgenden einige Beispiele: Distributed-Denial-of-Service-Angriffe (DDoS). Die AWS-API-Endpunkte werden auf einer großen erstklassigen internetbasierten Infrastruktur gehostet, die von derselben technischen Expertise profitiert, die Amazon zum weltweit größten Online-Händler gemacht hat. Es werden proprietäre Technologien zur Abschwächung von DDoS-Angriffen eingesetzt. Darüber hinaus werden die AWS-Netzwerke mit Multihoming auf mehrere Anbieter verteilt, wodurch der Internetzugriff vielfältiger wird. Man-in-the-Middle-Angriffe (MITM). Alle der AWS-APIs sind über SSL-geschützte Endpunkte verfügbar, die für eine Server-Authentifizierung sorgen. Amazon EC2 AMIs erzeugen automatisch neue SSH-Host-Zertifikate beim ersten Booten und protokollieren sie in der Konsole der Instanz. Sie können dann die sicheren APIs verwenden, um die Konsole zu starten und auf die Host-Zertifikate zuzugreifen, bevor Sie sich das erste Mal bei der Instanz anmelden. Wir empfehlen Ihnen die Verwendung von SSL für alle Ihre Interaktionen mit AWS. IP-Spoofing. Amazon EC2-Instanzen können keinen gefälschten (“gespooften”) Netzwerkverkehr versenden. Die AWS-kontrollierte, Host-basierte Firewall-Infrastruktur verhindert, dass eine Instanz Datenverkehr mit einer Quell-IP-oder MAC-Adresse versendet, die nicht ihre eigene ist. Port-Scanning. Unberechtigte Port-Scans durch Amazon EC2-Kunden stellen eine Verletzung der Nutzungsrichtlinie (Acceptable Use Policy) von AWS dar. Verstöße gegen die AWS Acceptable Use Policy werden ernst genommen und jeder gemeldete Verstoß wird untersucht. Kunden können mutmaßlichen Missbrauch über das Kontaktformular auf unserer Website melden: http://aws.amazon.com/contact-us/report-abuse/. Wenn unberechtigtes Port-Scanning von AWS festgestellt wird, wird dies gestoppt und künftig unterbunden. Port-Scans von Amazon EC2-Instanzen sind grundsätzlich unwirksam, da alle eingehenden Ports auf Amazon EC2-Instanzen geschlossen sind und nur durch Sie geöffnet werden. Eine strenge Verwaltung von Sicherheitsgruppen Ihrerseits kann die Gefahr für Port-Scans noch weiter verringern. Wenn Sie die Sicherheitsgruppe so konfigurieren, dass Datenverkehr von jeder Quelle an einen bestimmten Port erlaubt ist, ist dieser bestimmte Port anfällig für einen Port-Scan. In diesem Fall müssen Sie geeignete Sicherheitsmaßnahmen ergreifen, um zu verhindern, dass abhörende Dienste, die für ihre Anwendung unerlässlich sind, durch einen unbefugten Port-Scan entdeckt werden. Beispielsweise muss ein Webserver den Port 80 (HTTP) offensichtlich für die Welt offenhalten und der Administrator dieses Servers ist dann verantwortlich für die Sicherheit der HTTP-Serversoftware, wie zum Beispiel Apache. Sie können um Erlaubnis zur Durchführung von erforderlichen Schwachstellen-Scans bitten, um Ihre speziellen Compliance-Anforderungen zu erfüllen. Diese Scans müssen auf Ihre eigenen Instanzen beschränkt sein und dürfen die Acceptable Use Policy von AWS nicht verletzen. Um eine Genehmigung für derartige Scans einzuholen, stellen Sie eine Anfrage über folgende Website:  https://aws–portal.amazon.com/gp/aws/html-forms-controller/contactus/AWSSecurityPenTestRequest Packet Sniffing durch andere Tenants. Virtuelle Instanzen können im promiskuitiven Modus keinen Datenverkehr empfangen oder “erschnüffeln”, der für eine andere virtuelle Instanz bestimmt ist. Zwar können Sie für Ihre Schnittstellen den promiskuitiven Modus aktivieren, jedoch wird der Hypervisor keinen Datenverkehr an sie weiterleiten, der nicht an sie adressiert ist. Selbst zwei virtuelle Instanzen, die demselben Kunden gehören und sich auf demselben physischen Host befinden, können den Datenverkehr der jeweils anderen nicht abhören. Angriffe wie ARP-Poisoning funktionieren bei Amazon EC2 und Amazon VPC nicht. Auch wenn Amazon EC2 bereits einen umfassenden Schutz davor bietet, dass ein Kunde unbeabsichtigt oder böswillig versucht, Daten anderer Kunden einzusehen, empfehlen wir Ihnen, sensiblen Datenverkehr standardmäßig zu verschlüsseln. Neben der Überwachung werden mithilfe verschiedener Tools auch regelmäßig Schwachstellen-Scans auf dem Host-Betriebssystem, der Web-Anwendung und den Datenbanken in der AWS-Umgebung durchgeführt. Die AWS-Sicherheitsteams haben außerdem Newsfeeds abonniert, um über relevante Sicherheitslücken der Anbieter informiert zu werden und überwachen proaktiv die Websites der Anbieter und andere relevante Stellen, um auf neue Patches aufmerksam zu werden. AWS-Kunden haben auch die Möglichkeit, Schwachstellen an AWS über die AWS Vulnerability Reporting-Website zu melden: http://aws.amazon.com/de/security/vulnerability-reporting/.

DDoS Orange Business Services verfügt bei Flexible Engine über Wege, seine Kunden vor Denial-of-Service-Angriffen und unbefugtem Eindringen ins Netzwerk (Network-Intrusion-Angriff) zu schützen. Um das komplexe und mehrschichtige Sicherheitsdesign (Defense-in-Depth) und die Implementierung von Sicherheitslösungen zu vereinfachen, haben wir basierend auf Geschäftsfunktionen und Sicherheitsrisiken Sicherheitszonen definiert und verfolgen eine ganzheitliche Strategie der Netzwerk-Segregation, um Beeinträchtigungen durch Angriffe zu minimieren. Zusätzlich zu den fortschrittlichen Perimeterschutzmaßnahmen von Flexible Engine, können Tenants auch fein abgestimmte Richtlinien gegen DDoS-Angriffe für ihre EIPs, Sicherheitsgruppen in VPC und Zugriffskontrollen über IAM festlegen, um den Schutz gegen externe und interne Bedrohungen insgesamt zu erhöhen. ECS Sicherheitsarchitektur ECS verwendet Ressourcen- und Netzwerkisolation, Sicherheitsgruppenregeln, Anti-DDoS und Brute-Force-Angriffsprävention, um eine sichere Umgebung zu schaffen. ECS gewährleistet eine Verfügbarkeit (Availability) von 99,95 % und eine Haltbarkeit (Durability) der Daten von 99,99995 %.   VPC Virtual Private Cloud (VPC)-Funktionen, die von der Neutron OpenStack-Komponente bereitgestellt werden, ermöglichen eine logische Partitionierung der Kommunikation im Benutzernetzwerk. Jede Form von Netzwerkverkehr, die nicht von vornherein auf dem Tenant des Kunden zugelassen ist, wird von den Geräten, die das virtuelle Netzwerk des Clients unterstützen, nicht verarbeitet. Damit wird der Einsatz von Spoofing-Technologien verhindert. Der gesamte Datenverkehr des Tenants wird aufsteigend / Richtung Norden geroutet, wobei das Routing auf mehreren Sicherheitsebenen geschützt durch hochmoderne Firewalls nach Industriestandards erfolgt. IP/MAC-Adressen Spoofing-Schutz Um Netzwerkprobleme zu verhindern, wenn Benutzer ihre IP- oder MAC-Adressen beliebig ändern, werden IP- und MAC-Adressen mithilfe von DHCP-Snooping zusammengebunden. Spoofing wird darüber hinaus durch den Einsatz von IP Source Guard und Dynamic ARP Inspection (DAI) verhindert, da Datenpakete von ungebundenen Adressen herausgefiltert werden.   Blackholing-Sensoren im Herzen des Orange Group Netzwerks Dieses System schützt gegen massive Denial-of-Service-Angriffe über das Internet und wird ausgelöst, sobald ein Angriff die Grenze von 1 GB Datenverkehr erreicht hat. Es ist im Herzen des Orange Group Netzwerks implementiert und verwendet eine Sicherheitseinrichtung, die speziell für diesen Zweck entwickelt wurde. Die Lösung umfasst zwei Servicelevel – Standard und mit Zusatzoption: Aktivierung der Funktion Blackhole/Blackholing: Bei dieser Lösung werden die angegriffenen IP-Adressen vom Internet unerreichbar und schützen die anderen Kunden in der Public Cloud vor möglichen Beeinträchtigungen, zum Beispiel einer Verringerung der Internetbandbreite. Dieser Service gehört zum Standard. Der Datenverkehr wird in einen Echtzeit-Cleaning-Center umgeleitet, wo der unerwünschte Datenverkehr aussortiert und der nützliche anschließend wieder durchgelassen wird. Dies ist ein optionaler, kostenpflichtiger Service. Firewalls am Eingang der Orange Cloud-Plattformen Firewalls schützen die Orange Cloud-Plattformen gegen Angriffe mit kleinerem Umfang (weniger als 2 GB). Sie tun dies aber auf eine fein abgestimmtere Art, denn sie filtern nur die verdächtigen Pakete heraus, indem sie bestimmte Protokolle analysieren, wie beispielsweise: IP-Protokolle: SYN-Flood, UDP-Flood, ICMP-Flood, Land Attack, ICMP-Fragmente, ICMP Large Packets, SYN-Fragmente. Anwendungsflows: Firewalls sind auch in der Lage, spezielle Angriffe auf Anwendungsprotokolle zu erkennen: DNS, FTP, HTTP, REAL, RSH, RTSP, TALK, TFTP, XING etc. Sensoren, die ein versuchtes Eindringen in gemeinsame Cloud-Services auf den Orange Cloud-Plattformen erkennen IDS-Sensoren werden zur Überwachung der Cloud-Administrationsservices (Administrationsportal, Administrationsdienste etc.) verwendet. Die virtuellen Maschinen, die einem Kunden zugewiesen sind, werden nicht standardmäßig überwacht, da die Analyse der Warnmeldungen Kenntnisse des Kundenkontextes erforderlich macht. Die Implementierung der Überwachung von Kundenservern kann als Option vorgeschlagen werden. Allgemein gilt: Die Implementierung auf allen Komponenten der Infrastruktur sorgt dafür, dass Eindringlinge global erkannt werden.

Überprüfung und Audit der Konten

Amazon Web Services

Orange Flexible Engine

Die Konten werden alle 90 Tage überprüft; es ist eine ausdrückliche erneute Genehmigung erforderlich, da andernfalls der Zugriff auf die Ressource automatisch entzogen wird. Der Zugriff wird ebenfalls automatisch entzogen, wenn die Akte eines Mitarbeiters aus dem Personalsystem von Amazon entfernt wird. Windows- und UNIX-Konten werden deaktiviert und das Rechteverwaltungssystem von Amazon entfernt den Benutzer von allen Systemen. Zugriffsänderungsanfragen werden im Audit-Log des Mission-Management-Tools von Amazon erfasst. Wenn sich die Funktion eines Mitarbeiters ändert, muss der weitere Zugriff auf die Ressource ausdrücklich genehmigt werden. Andernfalls wird er automatisch entzogen.

Die Autorisierungen und Berechtigungen werden einmal pro Halbjahr überprüft. Bei diesem Vorgang werden die in der Personalakte hinterlegten Rollenbeschreibungen jeder Person mit den tatsächlich im System zugewiesenen Rechten abgeglichen. Werden nicht-legitime Berechtigungen entdeckt, werden geeignete Maßnahmen ergriffen: Sperre des Kontos Untersuchung der Nutzung, um Vorfälle zu erkennen Korrektive Maßnahmen (Aktualisierung von Verfahren, Inkenntnissetzung des Managements etc.) Die Überprüfungen werden in einem Bericht zusammengefasst und einmal im Jahr durch externe Auditoren überprüft. Das Verfahren für die Zuweisung und den Entzug eines Kontos und den dazugehörigen Rechten, genannt CARM (Controlling Access Rights Management), wird angewendet und überwacht. Bei dem Verfahren handelt es sich um eine ISMS-Sicherheitsmaßnahme (Information Security Management Systems). Es ist nach ISO 27001 zertifiziert und wird von Orange angewendet. Die gemeinsame Nutzung von Konten ist verboten.

Hintergrundprüfungen

Amazon Web Services

Orange Flexible Engine

AWS hat formale Richtlinien und Verfahren entwickelt, um die Mindeststandards für den logischen Zugriff auf AWS-Plattformen und Infrastruktur-Hosts darzulegen. AWS führt, soweit rechtlich zulässig, im Rahmen der Einstellungs-Screenings von Mitarbeitern strafrechtliche Hintergrundprüfungen durch. Diese richten sich nach der Funktion des Mitarbeiters sowie dessen Zugriffsberechtigung. Diese Richtlinien legen auch die Verantwortlichkeiten für die Verwaltung des logischen Zugriffs und der Sicherheitsmaßnahmen fest.

Orange verfügt über formale Richtlinien, die gewährleisten, dass Hintergrundprüfungen, soweit diese nach lokalen Bestimmungen zulässig sind, innerhalb des Teams während des Einstellungsprozesses durchgeführt werden.

VPN

Amazon Web Services	Orange Flexible Engine
Optional kann zwischen Ihrem Netzwerk und Ihrem VPC bei AWS eine VPN-Verbindung eingerichtet werden, um Tools von Ihrer Infrastruktur und Tools, die auf unserem Cloud-Service gehostet werden zu integrieren, z. B. die Integration von LDAP/Active Directory, anderen Atlassian-Tools oder Remote-Datenquellen.	VPN-as-a-Service kann Ihr Netzwerk mit dem Orange Flexible Engine VPC verbinden: https://cloud.orange-business.com/en/offers/infrastructure-iaas/public-cloud/features/vpn-as-a-service/

Sicherheit der Arbeitsplätze

Alle Mitglieder unseres Managed Services-Team sind mit Cisco AMP ausgestattet, das uns vor Viren, Malware und Datenverlust schützt.

Separate Private Clouds pro Kunde

Jeder Kunde hat seine eigene VPC (Virtual Private Cloud), bei dem sein Netzwerk und seine Daten von denen anderer Kunden isoliert sind.

Firewalls

Amazon Web Services	Orange Flexible Engine
Jeder Server ist mit einer Sicherheitsgruppe verbunden, die als Firewall für eingehende und ausgehende Verbindungen dient.	Jeder Server ist mit einer Sicherheitsgruppe verbunden, die als Firewall für eingehende und ausgehende Verbindungen dient.

Die Standardkonfiguration ist wie folgt:

Eingehend		Ausgehend
Port	Quelle	Port	Ziel
22	nur Bastion-Server, die ausschließlich von den Valiantys IP-Adressen erreichbar sind	alle	überall
80	überall*
443	überall

*Bitte beachten Sie, dass alle Anfragen, die an Port 80 gesendet werden, automatisch mit HTTPS an Port 443 mithilfe einer Apache HTTPD Rewrite-Regel umgeschrieben werden.

Die Einrichtung der Standard-Firewall kann je nach Kundenanforderungen angepasst werden.

Anmeldedaten

Individuelle Benutzerkonten

Jedes Mitglied unseres Managed Services-Team hat mit einem individuellem Konto Zugriff auf die Administrationskonsole und die Server.

Alle Aktivitäten werden protokolliert und unser Team kann jederzeit darauf zugreifen. Zugriffsprotokolle werden für eine Dauer von vier Wochen aufbewahrt.

Passwortrichtlinie

Die AWS- und OFE-Konsolen erfordern ein Passwort, das aus mindestens 8 Zeichen besteht. Es muss mindestens einen Großbuchstaben, einen Kleinbuchstaben, eine Zahl und ein Sonderzeichen beinhalten. Das Passwort muss alle 40 Tage geändert werden und wird auf Ähnlichkeit mit den letzten fünf Passwörtern überprüft.

Multi-Faktor-Authentifizierung

Zusätzlich zum Login/Passwort-Schutz ist für den Zugriff auf die AWS-Konsole ein Code erforderlich, der mit der mobilen App von Google Authenticator (oder Authy) erzeugt wird, die dem Konto des Benutzers zugeordnet ist. Codes werden alle 30 Sekunden generiert.

Serverzugriff

Der Serverzugriff über SSH ist nur über Bastion-Server der statischen IP-Adressen der unterschiedlichen Valiantys-Standorte basierend auf der Sicherheitsgruppen- und VPC-Peering-Konfiguration möglich. Der Zugriff wird durch einen privaten Schlüssel mit einer individuellen Passphrase gesichert.

Private Schlüssel werden sicher auf den Computern der jeweiligen Personen gespeichert.

Datensicherheit

Datenzugriff

Unsere Anbieter (AWS oder OFE) haben keinen Zugriff auf die Tools, die wir für unsere Kunden installieren. Sie haben auch keinen SSH-Zugang auf die Server, die wir auf ihrer Infrastruktur bereitstellen.

Da die Daten auf den von uns bereitgestellten Datenträgern verschlüsselt sind, haben sie keinen Zugriff auf gespeicherte Daten.

Datenlöschung bei Vertragsende

Valiantys ist dazu verpflichtet, alle Kundendaten bei Vertragsende zu löschen.

Wenn ein Kunde seinen Vertrag nicht erneuern möchte, gilt folgendes Verfahren:

• Wir erstellen eine vollständige Sicherungskopie der Kundenumgebung (XML-Backup und Anhänge für alle Atlassian-Tools).
• Wir stellen dem Kunden die Sicherungskopie über einen sicheren Übertragungsweg zur Verfügung (durch den Kunden bereitgestellt oder standardmäßig mithilfe eines AWS S3 Bucket mit individuellem Login/Passwort).
• Sobald der Kunde alle Daten erfolgreich erhalten hat, entfernen wir die Daten aus dem Repository.
• Wir fahren den Server herunter und löschen ihn vollständig.
• Bevor wir die Server-Snapshots löschen, warten wir einen Monat für den Fall, dass der Kunde Probleme beim Import der Daten hat. Diese Zeitspanne kann auf Wunsch des Kunden verkürzt werden.

Sobald die Daten bei uns gelöscht wurden, senden wir dem Kunden eine E-Mail, die bestätigt, dass Valiantys keine Kundendaten mehr gespeichert hat.

SSL

Der Zugriff auf Atlassian-Tools ist nur über SSL (TLS v1.2-Protokoll) über unser Standard-Zertifikat *.valiantys.net (2048-Bit-Schlüssel) oder Zertifikate möglich, die vom Kunden zur Verfügung gestellt werden und seinem eigenen Domain-Namen zugeordnet sind.

Datenverschlüsselung

Amazon Web Services

Orange Flexible Engine

Das Dateisystem kann mit einem einzigartigen 256-Bit-Schlüssel verschlüsselt werden. In dem Fall werden alle Snapshots von diesem Server mit demselben Schlüssel verschlüsselt. Die Schlüsselverwaltungsinfrastruktur von Amazon verwendet kryptografische Algorithmen, die mit den Federal Information Processing Standards (FIPS) 140-2 konform sind und den National Institute of Standards and Technology (NIST) 800-57-Empfehlungen entsprechen.

Das Dateisystem kann mit einem einzigartigen 256-Bit-Schlüssel verschlüsselt werden. In dem Fall werden alle Snapshots von diesem Server mit demselben Schlüssel verschlüsselt. Die LUKS-Verschlüsselung wird verwendet, um die gesamte Partition zu verschlüsseln, auf der die Atlassian-Tools und die Datenbank installiert sind.

Sicherheitsprotokolle

Auf den von uns verwalteten Servern werden verschiedene Protokolle aufgezeichnet:

• SSH-Zugriffsprotokolle, die alle SSH-Zugriffe auf den Server aufzeichnen
• Apache HTTPD-Zugriffsprotokolle, die alle HTTP-Anfragen aufzeichnen, die beim Server eingehen
• Anwendungs-Zugriffsprotokolle, die alle HTTP-Anfragen aufzeichnen, die bei den Tools eingehen

Diese Log-Dateien werden auf Anfrage zur Verfügung gestellt.

Sicherungskopien (Backups)

Jede Nacht etwa um Mitternacht werden automatisch vollständige VM-Snapshots gemacht und für sieben Tage aufbewahrt. Die Snapshots werden verschlüsselt.

Zusätzlich zu diesen Sicherungskopien werden jeden Tag automatisch XML-Backups auf den Atlassian-Tools erstellt. Sie ermöglichen in manchen Fällen eine schnellere Datenwiederherstellung (z. B. bei versehentlicher Datenlöschung).

Diese XML-Backups können von unserem Team in größeren Umgebungen deaktiviert werden, um Einbußen bei der Performance zu verhindern.

Aufbewahrung von Sicherungskopien

VM-Snapshots und XML-Exporte werden automatisch nach sieben Tagen gelöscht.

Wiederherstellungsverfahren

Das Wiederherstellungsverfahren hängt von der Art des festgestellten Verlusts ab. Unser Managed Services-Team kann nach der Analyse Ihres Problems aus zwei Methoden wählen.

VM-Snapshot-Wiederherstellung:

• Wir verwenden den Snapshot, um eine neue VM mit derselben Größe zu erstellen.
• Wir leiten die Server-IP auf den neu erstellen Server um (dauert in der Regel ca. 10 Minuten).

XML-Export-Wiederherstellung:

• Wir kopieren den XML-Export in den Wiederherstellungsordner.
• Wir starten den XML-Import (kann ein paar Minuten bis zu einigen Stunden je nach Größe der Umgebung dauern).

Überprüfung des Wiederherstellungsvorgangs

Um zu gewährleisten, dass unsere Backups und Backup-Verfahren wie erwartet funktionieren, führen für einmal im Jahr einen Wiederherstellungstest für alle unsere Server durch.

Ein Ergebnisbericht kann dem Kunden auf Anfrage zur Verfügung gestellt werden.

Penetrationstests

Wir führen mindestens einmal im Jahr einen Black-Box-Penetrationstest auf allen unseren Servern durch.

Mindestens einmal im Jahr führen wir einen White-Box-Penetrationstest auf einer von uns erstellten Sandbox-Umgebung durch. Dafür nutzen wir den Standard-Einrichtungsprozess, den wir zur Erstellung einer Client-Umgebung verwenden. Auf diese Weise verbessern wir kontinuierlich unsere Sicherheit.

Wir ermöglichen es unseren Kunden auch, ihre eigenen Penetrationstests durchzuführen (durch sie selbst oder einen Dritten).

Möchte ein Kunde selbst einen Penetrationstest durchführen, muss er uns mindestens vier Wochen im Voraus darüber informieren, da wir von unseren Anbietern eine entsprechende Genehmigung einholen müssen.

Schwachstellenmanagement

Erkennungsprozess

Wir führen eine wöchentliche Überprüfung unserer Referenzdatenbank durch und verwenden dafür spezialisierte Tools zusätzlich zu den Warnmeldungen, die von Atlassian zur Verfügung gestellt werden.

Erkennungszeiten

Die Erkennungszeit liegt bei sieben Tagen (es sei denn es gibt eine Benachrichtigung von Atlassian in diesem Zeitraum).

Zeitraum für Gegenmaßnahmen

Gegenmaßnahmen werden unverzüglich eingeleitet. Sobald eine Schwachstelle bekannt ist, wird automatisch für den Kunden ein Vorfallticket erstellt, um mit ihm gemeinsam Maßnahmen zur Beseitigung zu organisieren und um Beeinträchtigungen auf die Produktion möglichst gering zu halten.

Reagiert der Kunde nicht innerhalb von sieben Tagen, wird die Schwachstelle automatisch und auch ohne dessen Zustimmung außerhalb seiner Geschäftszeiten behoben.

Operations

Sicherheitsorganisation

Aktuell zuständig für die Sicherheit im Unternehmen ist Nathan Chantrenne, CTO.

Wir haben kein spezielles Sicherheitsteam. Alle Mitglieder unseres Managed Services-Team kennen die Sicherheitsregeln, die bei Valiantys angewendet werden, und sind in der Lage mit Sicherheitsvorfällen umzugehen.

Wir verfügen über eine unternehmensspezifische Sicherheitsrichtlinie, die Bestandteil unserer Unternehmensregeln und -bestimmungen ist und die von jedem Mitarbeiter von Valiantys angenommen werden muss. Sie umfasst die folgenden Abschnitte:

Organisation der Richtlinie zur Informationssicherheit

• EINFÜHRUNG
  • Zweck
  • Geltungsbereich
  • Historie
  • Verantwortlichkeiten
  • Allgemeine Definition der Richtlinie
  • Glossar

• NETZWERKZUGRIFFSRICHTLINIE
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie

• DATEN-, INFORMATIONS- UND SICHERHEITSRICHTLINIE
  • Allgemeine Nutzung und Ownership
  • Sicherheits- und proprietäre Informationen
  • Inakzeptable Nutzung

• EINHALTUNG DER RICHTLINIE
  • Messung der Einhaltung (Compliance)
  • Ausnahmen
  • Nichteinhaltung

• IT-ASSETS-RICHTLINIE
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie

• ZUGRIFFSKONTROLLRICHTLINIE
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie

• PASSWORTKONTROLLRICHTLINIE
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie
  • Erklärung von Leitlinien

• E-MAIL-RICHTLINIE
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie

• INTERNETRICHTLINIE
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie

• ANTIVIREN-RICHTLINIE
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie

• RICHTLINIE ZUR KLASSIFIKATION VON INFORMATIONEN
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie

• REMOTE-ZUGRIFFSRICHTLINIE
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie

• OUTSOURCING-RICHTLINIE
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie
  • Vorschriften

• PATCH-MANAGEMENT-RICHTLINIE
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie

• RICHTLINIE ZU CLOUD-ANWENDUNGSINFORMATIONEN
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie

Vor der Einstellung neuer Mitarbeiter, führen für eine Hintergrundprüfung durch, die sich nach den Vorgaben des Landes richten, in dem sie eingestellt werden:

• Offenlegung von Vorstrafen
• Beschäftigungshistorie und Gap-Analyse
• Identitätsüberprüfung
• Überprüfung der Arbeitserlaubnis

Änderungsmanagement-Prozess

Änderungsanfrage einreichen

Wenn in einem Support-Ticket eine Änderung von einem Kunden angefragt oder von einem Support-Mitarbeiter identifiziert wird, kann über einen Workflow-Übergang ein spezieller Status erreicht werden. Aus diesem Status ist es möglich, ein Änderungsticket in dem entsprechenden Jira-Projekt über eine entsprechende Schaltfläche zu erstellen. Das erstellte Änderungsticket enthält die folgenden Informationen:

• Beschreibung – z. B.: Jira-Upgrade auf 8.5.3 auf MyCustomer PROD Instanz
• Priorität – z. B.: Kritisch
• Ursprung – z. B.: Benachrichtigung von Atlassian
• Änderungsgrund – z. B.: Sicherheitslücke in der aktuell installierten Jira-Version
• Risikoanalyse – z. B.:

• • dieselben Parameter in den Konfigurationsdateien von setenv.sh und server.xml
  • Kompatibilität der installierten Apps – ggf. Upgrade der betroffenen Apps
  • Apps, die eine bezahlte Lizenz erfordern – Kunde und Kundenbetreuer müssen informiert werden
  • Keine unvorhersehbaren Sicherheitsrisiken, da die Daten nirgendwohin übertragen werden

• Änderungsverfahren – z. B.: <link_to_the_corresponding_internal_documentation>
• Rollback-Verfahren – z. B.: Wiederherstellung des Snapshots, der vor der Maßnahme erzeugt wurde
• Geschätzte Dauer – z. B.: 1 Stunde
• Link zu dem zugehörigen Support-Ticket – wird automatisch durch die Jira-App definiert, die das Änderungsticket erstellt

Änderungsfreigabe

Nach der Erstellung und abhängig von der Art der erwarteten Änderung, wird das Änderungsticket einem Support Team Leader oder einem Cloud Architect zugewiesen. Der Assignee überprüft die vom Reporter bereitgestellten Informationen und entscheidet, ob er die Änderungsanfrage annimmt oder ablehnt.

Gründe für die Ablehnung der Änderung sind unter anderem: technisches Risiko, Sicherheitsrisiko, unklares oder unvollständiges Verfahren etc. Falls eine Änderung abgelehnt wird, wird das Änderungsticket geschlossen und der Workflow des zugehörigen Support-Tickets wird automatisch auf den vorherigen Status zurückgesetzt.

Wenn die Änderung angenommen wird, ermöglicht ein Formular die Planung des entsprechenden Vorgangs über folgende Felder:

• Startdatum – z. B. Datum und Zeit, wann die Änderungsmaßnahme startet
• Enddatum – z. B. Datum und Zeit, wann der Änderungsmaßnahme endet
• Assignee – z. B. Mitarbeiter verantwortlich für die Durchführung der Maßnahme

In der Folge wird ein Änderungsticket mit diesen Informationen aktualisiert und der Workflow des zugehörigen Support-Tickets erhält automatisch den neuen Status, der anzeigt, dass eine Korrekturmaßnahme geplant ist.

Änderungsumsetzung

Sobald die Änderung umgesetzt wurde, aktualisiert der Mitarbeiter, dem die Maßnahme zugewiesen war, den Workflow-Status des Änderungstickets. Das löst automatisch ein Update des Workflows des zugehörigen Support-Tickets aus, so dass die Bearbeitung dieses Tickets wieder aufgenommen wird.

Notfalländerungen

Im Fall von dringenden Problemen, zum Beispiel, wenn ein von einem Kunden gemeldetes Problem oder eine von Atlassian gemeldete Sicherheitslücke bestimmte Anwendungsversionen betrifft, wird ein Notfalländerungsprozess angewendet, der in folgenden Punkten vom regulären Prozess abweicht:

• Ein Support Team Leader oder ein Cloud Architect bearbeitet das entsprechende Support-Ticket und erstellt und genehmigt das zugehörige Änderungsticket.
• Die Änderung wird abhängig von der Verfügbarkeit der Support-Mitarbeiter und der Vereinbarung mit dem Kunden zum frühestmöglichen Zeitpunkt geplant.

Änderungsausschuss

Jeden Montagnachmittag überprüft der Änderungsausschuss in einem 30-minütigen Meeting mithilfe eines speziellen Jira Dashboards die im vergangenen Zeitraum verarbeiteten Änderungstickets. Zu dem Ausschuss gehören mindestens der Head of Managed Services, die Support Offerings und Cloud Offerings Manager sowie die Support Team Leader.

Vorfallmanagementprozess

Vorfälle werden von Kunden per E-Mail oder über unser Support-Portal oder durch unser Valiantys Managed Services-Team erstellt.

Ein Vorfall wird nach den Schweregraden 1, 2, 3 oder 4 eingeteilt. Die Definitionen unserer Schweregrade sind unter https://valiantys.com/de/rechtliche/sla/ zu finden.

Unser Managed Services-Team bearbeitet Tickets nach folgender Priorität:

• Service-Ausfall (Vorfälle werden automatisch über unser Monitoring-Tool erstellt) – mit einer 30-minütigen Recovery Time Objective
• Sicherheitsvorfälle
• S1 Vorfälle
• Tickets mit SLA-Verstoß
• Alle weiteren Tickets, nach SLA geordnet

Der Workflow für Vorfälle lautet wie folgt:

Workflow

• Wenn ein Ticket erstellt wurde, erhält es den Status “Submitted”.
• Sobald unser Team mit der Arbeit beginnt, geht das Ticket in den Status “In progress” über.
• Wenn wir weitere Informationen von Ihnen benötigen, wird das Ticket in den Status “Waiting for customer” bewegt und ein Kommentar hinzugefügt, welche Informationen wir benötigen, um das Problem zu lösen.
• Wenn wir Unterstützung von Dritten benötigen, um das Problem zu lösen, wird das Ticket in den Status “Waiting for third party” bewegt. Dritte können beispielsweise Atlassian, App-Anbieter oder Hosting-Provider sein.
• Wenn Sie uns eine Antwort geben, erhält das Ticket den Status “Closed”. Ein Kommentar wird hinzugefügt, um Ihnen alle erforderlichen Informationen zu geben.
• Wenn die Antwort Ihre Erwartungen nicht vollständig erfüllt, haben Sie die Möglichkeit, das Ticket wieder zu öffnen, was es in den Status “In progress” versetzt.
• Wenn ein Ticket geplante Maßnahmen erfordert, um es zu lösen (z. B. ein Upgrade oder ein geplanter Neustart), wird es in den Status “Operation planned” versetzt und ein Kommentar informiert Sie darüber, wann die Maßnahme durchgeführt und wer dafür verantwortlich ist.
• Wenn das Ticket als Beratungsleistung identifiziert wird, wird es mit der Lösung “Consulting” geschlossen.

SLA

• Die Reaktionszeit-SLA wird vom Übergang des “Submitted”-Status in die Status “Operation planned”, “Waiting for customer”, “Resolved” oder “Closed” gemessen.
• Die Reaktionszeit-SLA zählt nur die erste Zuordnung der Status “Operation planned” / “Waiting for custumer” / “Resolved” / “Closed”. Das bedeutet, dass die SLA nicht von vorne beginnt, wenn ein Vorgang wieder geöffnet oder in den Status “In progress” zurückgesetzt wird.
• Die Reaktionszeit-SLA wird bei dem Status “Waiting for third party” angehalten.
• Die Reaktionszeit-SLA wird anhand der im Support-Vertrag gewählten Abdeckung gemessen: während der Geschäftszeiten für Kunden, die den Service “Business Hours” und rund um die Uhr für Kunden, die “24/7” gewählt haben.

Benachrichtigungen

• Nach der Ticketerstellung erhält der Ersteller eine E-Mail-Benachrichtigung.
• Der Ersteller kann jederzeit auf die Benachrichtigung antworten, um dem Ticket einen Kommentar hinzuzufügen.
• Der Ersteller erhält eine E-Mail-Benachrichtigung, sobald das Ticket den Status “In progress” erhält, was bedeutet, dass es berücksichtigt wird.
• Der Ersteller bekommt eine E-Mail-Benachrichtigung, wenn das Ticket die Status “Waiting for customer”, “Waiting for third party” oder “Operation planned” erhält.
• Unser Support-Team bekommt eine Benachrichtigung, wenn der Vorgang aus den Status “Waiting for customer” oder “Closed” wieder geöffnet wird.
• Der Ersteller bekommt eine E-Mail-Benachrichtigung, wenn das Ticket den Status “Closed” erhält.
• Der Ersteller erhält jedes Mal eine E-Mail-Benachrichtigung, wenn das Ticket von unserem Support-Team kommentiert wird.

Automationen

• Befindet sich ein Ticket im Status “Waiting for customer” und wurde 3 bzw. 6 Tage nicht verändert, wird es automatisch kommentiert, wodurch eine Benachrichtigung an den Ersteller versendet wird.
• Tickets mit dem Status “Waiting for customer”, die über einen Zeitraum von 12 Tagen nicht verändert wurden, werden automatisch geschlossen, können aber bei Bedarf wieder von Ihnen geöffnet werden.

Eskalation

• Sie haben jederzeit die Möglichkeit, den Vorgang zu eskalieren. Bei einer Eskalation wird an den Leiter des Support-Teams und den Head of Managed Services eine Benachrichtigung verschickt, damit sie das Ticket überprüfen und gegebenenfalls aktiv werden können.
• Wir empfehlen die Eskalations-Schaltfläche in den folgenden Fällen:

• • Sie erhalten nicht die erforderliche Expertise, um das Problem zu lösen.
  • Sie erhalten keine angemessenen Reaktionszeiten, nachdem Sie dem Support Agent, der Ihr Ticket bearbeitet, alle Informationen zur Verfügung gestellt haben.

• Wenn Sie ein sehr dringendes Problem haben, empfehlen wir Ihnen, uns direkt anzurufen, anstatt den Vorgang zu eskalieren. (Unsere Telefonnummern sind hier zu finden: Eine Support-Anfrage stellen)

Regelmäßige Überprüfung der Zugriffsrechte

Jeden Monat werden alle bei Managed Services genutzten Anwendungen überprüft, um zu kontrollieren, dass lediglich autorisiertem Personal Zugriff gewährt wird.

Es wird ein Bericht erstellt und dem Teammanager von Managed Services zur Verfügung gestellt. Für den Fall, dass Zugriffsrechte fälschlicherweise erteilt wurden, werden sofortige Maßnahmen zur Behebung des Problems ergriffen, indem gegebenenfalls ein Sicherheitsvorfall erstellt wird.

Sicherheitsvorfall-Management

Unser Sicherheitsvorfallprozess wird durch unseren Vorfallreaktionsplan abgedeckt.

SCHRITT 1 – Entdeckung und Kategorisierung

Jeder, der einen Vorfall entdeckt, kontaktiert das Valiantys-Support-Team, indem er einen Sicherheitsvorfall in der dafür vorgesehenen Jira Service Desk-Instanz erstellt.

• Name des Anrufers oder der Quelle der Vorfallmeldung (AWS oder Software-Benachrichtigung) – z. B. E-Mail von Atlassian oder Ticket, das von einem Kunden über das Valiantys-Support-Portal erstellt wurde
• Zeitpunkt des ersten Berichts
• Art des Vorfalls – z. B. Schwachstelle in einem Atlassian-Produkt
• Welches System / welche Systeme oder Personen waren beteiligt? – z. B. betroffene Atlassian-Anwendungen (z. B. von der Schwachstelle betroffene Versionen)
• Standort der betroffenen Anlage oder Personen – z. B. Valiantys Cloud-Infrastruktur
• Wie der Vorfall entdeckt wurde – z. B. durch Penetrationstests, die vom Kunden auf ihren Anwendungen durchgeführt wurden

Alle Log-Informationen vom Server müssen für künftige Untersuchungen in das Ticket kopiert werden.

SCHRITT 2 – Eskalation und Exploration

Je nach Art des Sicherheitsvorfalls wird das erstellte Ticket dem Support oder dem Cloud Offerings Manager zugewiesen. Der zugewiesene Mitarbeiter (Assignee)

• überprüft den Inhalt des Tickets und
• bewertet die Liste der beeinträchtigten Umgebungen. Von den Umgebungen werden zur Identifizierung, Sammlung, Erfassung und Aufbewahrung der Daten Sicherungskopien erstellt (sofern kein aktuelles Backup vorhanden ist), da sie als Beweismittel dienen könnten.
• Basierend auf dieser Bewertung entscheidet der Assignee über die Art der Problembehebung, damit der Vorfall so schnell und effizient wie möglich gelöst wird. Die Art und Weise der Problembehebung hängt vom Fall ab:
• • Bereitstellung eines Workarounds, falls möglich
  • System- oder Anwendungsupgrade – z. B.: OS, Apache, PostgreSQL, Atlassian-Tool oder -App
  • Migration in eine neue Umgebung

Für jede Umgebung, die von dem Vorfall beeinträchtigt ist, werden basierend auf dem Änderungsmanagement-Prozess, Änderungstickets in dem speziellen Jira-Projekt erstellt. Diese enthalten die folgenden Informationen:

Änderungsmanagement-Prozess

• Beschreibung – z. B.: Jira-Upgrade auf 8.5.3 auf MyCustomer PROD Instanz
• Priorität – z. B.: Kritisch
• Ursprung – z. B.: Benachrichtigung von Atlassian
• Änderungsgrund – z. B.: Sicherheitslücke in der aktuell installierten Jira-Version
• Risikoanalyse – z. B.:

• • dieselben Parameter in den Konfigurationsdateien von setenv.sh und server.xml
  • Kompatibilität der installierten Apps – ggf. Upgrade der betroffenen Apps
  • Apps, die eine bezahlte Lizenz erfordern – Kunde und Kundenbetreuer müssen informiert werden
  • Keine unvorhersehbaren Sicherheitsrisiken, da die Daten nirgendwohin übertragen werden

• Änderungsverfahren – z. B.: <link_to_the_corresponding_internal_documentation>
• Rollback-Verfahren – z. B.: Wiederherstellung des Snapshots, der vor der Maßnahme erzeugt wurde
• Geschätzte Dauer – z. B.: 1 Stunde
• Link zu dem zugehörigen Support-Ticket – wird automatisch durch die Jira-App definiert, die das Änderungsticket erstellt

Definition Sicherheitsverletzung

Eine Sicherheitsverletzung ist die unbefugte Beschaffung von Daten, die die Sicherheit, Vertraulichkeit oder Integrität von personenbezogenen Informationen, die von Valiantys aufbewahrt werden, beeinträchtigt.

Die Erhebung von personenbezogenen Daten durch einen Arbeitgeber oder einen Vertreter unseres Unternehmens für geschäftliche Zwecke stellt keine Sicherheitsverletzung da, sofern die personenbezogenen Daten nicht unberechtigt weitergegeben werden.

Ersteller der Vorfallbenachrichtigung

Im Folgenden finden Sie einige Beispiele für Werte, die im Origin-Feld des Änderungstickets angegeben werden müssen:

• Kunde
• Atlassian Consultant für Kunden
• Dritte, z. B. die CVE-Datenbank
• Valiantys
• Atlassian
• Unbekannt

Art

Im Folgenden finden Sie einige Beispiele für Werte, die im Reason for Change-Feld des Änderungstickets angegeben werden müssen:

• Verletzung personenbezogener Daten
• Denial-of-Service / Distributed-Denial-of-Service
• Exzessiver Port-Scan
• Verletzung der Firewall
• Ausbruch von Viren
• Exploitation von Server-Ressourcen

Klassifizierung/Kritikalität

Im Folgenden finden Sie einige Beispiele für Werte, die im Priority-Feld des Änderungstickets angegeben werden müssen:

KRITISCH

• Definition: Vorfälle, die kritische Auswirkungen auf das Geschäft des Unternehmens oder den Service für die Kunden von Valiantys Managed Services (MS) haben
• Beispiel: unbefugter Systemzugriff

MEDIUM

• Definition: Vorfälle, die erhebliche oder kritische Auswirkungen auf das Geschäft des Unternehmens oder den Service für die Kunden von Valiantys MS oder das Potenzial dazu haben
• Beispiel: Versuch, Passwörter zu knacken

NIEDRIG

• Definition: Vorfälle, die das Potenzial für erhebliche oder kritische Auswirkungen auf das Geschäft des Unternehmens oder den Service für die Kunden von Valiantys MS haben
• Beispiel: Scannen der Firewall

SCHRITT 3 – Behebung

Jedes betroffene System wird vor der Behebung auf offene Schwachstellen gescannt

Der Sicherheitsvorfall wird über das Änderungsverfahren behoben – angegeben in einem speziellen Feld des Änderungstickets.

Nach Validierung der korrektiven Maßnahme, werden die betroffenen Systeme erneut gescannt, um zu verifizieren, dass die Schwachstelle beseitigt wurde.

SCHRITT 4 – Kommunikation

• Valiantys MS ist zu einer angemessenen Kommunikation gegenüber Kunden oder Partnern verpflichtet, die von der Sicherheitsverletzung betroffen sein könnten. Alle betroffenen Kunden erhalten innerhalb von maximal 24 Stunden per E-Mail (oder über ein im Namen des Kunden erstelltes Support-Ticket) die folgenden Informationen:
  • Details zur Schwachstelle (CVE-Nummer, falls vorhanden)
  • Wie die Schwachstelle ihre Umgebung beeinträchtigt
  • Beschreibung des Plans zur Behebung
  • Beschreibung des Kommunikationsplans
  • Details aus den Untersuchungen, ob die Schwachstelle bereits ausgenutzt wurde

• Das Valiantys Managed Services-Management wird so früh wie möglich ab der Eskalationsstufe und je nach Schweregrad und Umfang der betroffenen Umgebungen in den Prozess eingebunden:
  • Der Valiantys Head of Managed Services muss bei jedem Sicherheitsvorfall der Kritikalität “Kritisch” eingebunden werden.
  • Der CTO von Valiantys muss eingebunden werden, wenn der Sicherheitsvorfall die Valiantys Cloud-Infrastruktur betrifft und die Kritikalität “Kritisch” erreicht.
  • Der CISO von Valiantys muss eingebunden werden, wenn der Sicherheitsvorfall die Valiantys-Infrastruktur betrifft und die Kritikalität “Kritisch” ist.
  • Der CEO von Valiantys muss eingebunden werden, wenn der Sicherheitsvorfall rechtliche oder finanzielle Verpflichtungen für Valiantys bedeutet und die Kritikalität “Kritisch” ist.

SCHRITT 5 – Post-Mortem-Analyse der Reaktions- und Update-Richtlinien

Um vorbeugende Maßnahmen zu ergreifen und zu verhindern, dass der Vorfall erneut eintritt, stellen wir uns mehrere Fragen:

• Hätte eine zusätzliche Richtlinie den Vorfall verhindert?
• Wurde ein Verfahren oder eine Richtlinie nicht befolgt, wodurch der Vorfall ermöglicht wurde? Was kann verändert werden, um zu gewährleisten, dass das Verfahren oder die Richtlinie künftig befolgt wird?
• War die Reaktion auf den Vorfall angemessen? Wie kann sie verbessert werden?
• Sind alle erforderlichen Parteien zeitnah informiert worden?
• Waren die Vorfallreaktionsverfahren detailliert und haben sie die gesamte Lage abgebildet? Wie können sie verbessert werden?
• Wurden Veränderungen vorgenommen, um einen weiteren Vorfall zu verhindern? Wurden alle Systeme gepatcht, Systeme gesperrt, Passwörter geändert, Anti-Viren-Scanner aktualisiert, E-Mail-Richtlinien festgelegt etc.?
• Sollten irgendwelche Sicherheitsrichtlinien aktualisiert werden?
• Welche Erkenntnisse gewinnen wir aus dieser Erfahrung?

Diese Diskussionen können in dem wöchentlichen Meeting des Änderungsausschusses geführt werden, zu dem mindestens der Head of Managed Services, die Support Offerings und Cloud Offerings Manager sowie die Support Team Leader gehören.

Regelmäßige Tests

Das Valiantys Managed Services Team ist dafür verantwortlich, den Reaktionsplan für Sicherheitsvorfälle (Security Incident Response Plan) einmal pro Quartal zu den folgenden Zeitpunkten zu überprüfen:

• Mitte März
• Mitte Juni
• Mitte September
• Mitte Dezember

Disaster Recovery

Alle unsere virtuellen Server (ausgenommen Valiantys Cloud Starter) werden jede Nacht gesichert. Die Sicherungskopie wird in derselben Region wie die Server gespeichert. Für die Disaster Recovery werden alle Snapshots automatisch in eine andere Region kopiert.

Gibt es einen erheblichen Ausfall in der Hauptregion, sind wir in der Lage, den Service sehr schnell mithilfe des letzten Backups neu zu starten, womit wir die Beeinträchtigungen für die Kunden so gering wie möglich halten:

Unsere Recovery Time Objective und Recovery Point Objective sind unter https://valiantys.com/de/rechtliche/sla/ zu finden.

Wir testen diesen Prozess einmal im Jahr auf allen unseren Servern, um im Fall der Fälle bereit zu sein und effizient zu handeln.

Als PDF herunterladen