Sicherheits- und Backup-Richtlinie

Übersicht

Dieses Dokument soll einen Überblick über die Verfahren geben, die wir einsetzen, um die Verfügbarkeit Ihrer Systeme und die Sicherheit Ihrer vertraulichen Informationen zu gewährleisten. Es umfasst die Informationen über Ihr Unternehmen und Ihre Prozesse, die Sie mit uns teilen, sowie Ihre Daten, die Sie in unserer gehosteten Umgebung verwalten.

Sie sollten diese Richtlinie in Verbindung mit unseremService Level Agreement und denAllgemeinen Geschäftsbedingungen für Dienstleistungen lesen.

Verantwortungsmatrix

Für einige Bereiche der Sicherheit ist unser Hosting-Anbieter verantwortlich, der uns ein Rechenzentrum vermietet. Einige Bereiche fallen in den Zuständigkeitsbereich von Valiantys, das für die Installation und den Support der Dienste zuständig ist. Für einige Bereiche schließlich ist Atlassian verantwortlich, das die Software entwickelt und wartet.

Valiantys-Unterstützung

Valiantys-Cloud

Definitionen

Begriff	Beschreibung
AWS-Regionen und Verfügbarkeitszonen	Amazon EC2 wird an mehreren Standorten weltweit gehostet. Diese Standorte sind in Regionen und Availability Zones unterteilt. JedeRegion ist ein separates geografisches Gebiet. Jede Region hat mehrere isolierte Standorte, die alsAvailability Zones bekannt sind.
VPC und Teilnetz	EineVirtual Private Cloud (VPC) ist ein nach Bedarf konfigurierbarer Pool gemeinsam genutzter Rechenressourcen, die innerhalb eineröffentlichen Cloud-Umgebung zugewiesen werden und ein bestimmtes Maß an Isolierung zwischen den verschiedenen Organisationen (im Folgenden alsNutzer bezeichnet) bieten, die die Ressourcen nutzen. Die Isolierung zwischen einem VPC-Nutzer und allen anderen Nutzern derselben Cloud (anderen VPC-Nutzern sowie anderen Nutzern der öffentlichen Cloud) wird in der Regel durch die Zuweisung eines privaten IP-Teilnetzes und eines virtuellen Kommunikationskonstrukts (z. B. ein VLAN oder eine Reihe verschlüsselter Kommunikationskanäle) pro Nutzer erreicht. In einer VPC-Lösung wird der zuvor beschriebene Mechanismus, der für eine Isolierung innerhalb der Cloud sorgt, mit einer VPN-Funktion (wiederum pro VPC-Benutzer zugewiesen) kombiniert, die mittels Authentifizierung und Verschlüsselung den Fernzugriff des Unternehmens auf seine VPC-Cloud-Ressourcen sichert. Mit der Einführung der beschriebenen Isolationsebenen arbeitet eine Organisation, die diesen Dienst nutzt, tatsächlich in einer "virtuell privaten" Cloud (d. h. so, als ob die Cloud-Infrastruktur nicht mit anderen Nutzern geteilt wird), daher der Name VPC.
Sicherheitsgruppe	EineSicherheitsgruppe fungiert als virtuelle Firewall, die den Datenverkehr für eine oder mehrere Instanzen kontrolliert. Wenn Sie eine Instanz starten, verknüpfen Sie eine oder mehrere Sicherheitsgruppen mit der Instanz. Sie fügen jeder Sicherheitsgruppe Regeln hinzu, die den Datenverkehr zu oder von den zugeordneten Instanzen zulassen. Sie können die Regeln für eine Sicherheitsgruppe jederzeit ändern; die neuen Regeln werden automatisch auf alle Instanzen angewendet, die mit der Sicherheitsgruppe verbunden sind. Wenn wir entscheiden, ob wir den Verkehr zu einer Instanz zulassen, werten wir alle Regeln aller Sicherheitsgruppen aus, die mit der Instanz verbunden sind.
Elastische IP	Eineelastische IP-Adresse ist eine statische IP-Adresse, die für dynamisches Cloud Computing entwickelt wurde. Eine elastische IP-Adresse ist mit Ihrem AWS-Konto verknüpft. Mit einer elastischen IP-Adresse können Sie den Ausfall einer Instanz oder Software verbergen, indem Sie die Adresse schnell einer anderen Instanz in Ihrem Konto zuordnen.

Standort des Rechenzentrums

Amazon Webdienste	Orange Flexible Engine
US-Ost N. Virginia, Ohio	Frankreich Pantin, Aubervilliers und Saint Denis
US-West N. Kalifornien, Oregon
Kanada Zentral
Europa Frankfurt, Dublin, London, Paris, Stockholm

Normen

Valiantys richtet sich nach ISO 27001, unterstützt durch starke Prozesse, Dokumentation und Kultur. Die von uns genutzten Rechenzentren verfügen über die folgenden Akkreditierungen:

Amazon Webdienste	Orange Flexible Engine
SOC 1/SSAE16/ISAE 3402 (früher SAS 70) - Bericht nach Unterzeichnung eines NDA verfügbar SOC 2 SOC 3 FISMA, DIACAP und FedRAMP ISO 9001 / ISO 27001 ITAR FIPS 140-2 MTCS Stufe 3 GDPL (Einzelheiten hier: https://aws.amazon.com/blogs/security/aws-and-the-general-data-protection-regulation/) Siehehttps://aws.amazon.com/fr/compliance/ für weitere Einzelheiten.	ISAE 3402 Typ II (ehemals SAS 70) SOC 1 Typ II SOC 2 Typ II ISO 9001 / ISO 27001 ISO 14001:2004 ISO 22301 OHSAS 18001 HDA/HADS PCI-DSS Siehehttps://cloud.orange-business.com/en/3rd-az-in-paris-region/

Physische und umgebungsbezogene Sicherheit

Branderkennung und -unterdrückung

Amazon Webdienste	Orange Flexible Engine
Zur Risikominderung wurden automatische Brandmelde- und -unterdrückungsanlagen installiert. Das Brandmeldesystem verwendet Rauchmelder in allen Rechenzentrumsumgebungen, mechanischen und elektrischen Infrastrukturräumen, Kühlräumen und Generatoranlagenräumen. Diese Bereiche sind entweder durch Nassrohr-, doppelt verriegelte Pre-Action- oder organische Sprinklersysteme geschützt.	Der Brandschutz wird durch zwei sich ergänzende Systeme gewährleistet: hochempfindliche Rauchdetektoren und ein Wassernebel-Löschsystem. Überwachungszentrum

Strom

Amazon Webdienste

Orange Flexible Engine

Die Stromversorgungssysteme des Rechenzentrums sind so konzipiert, dass sie vollständig redundant sind und ohne Beeinträchtigung des Betriebs 24 Stunden am Tag und sieben Tage die Woche gewartet werden können. Unterbrechungsfreie Stromversorgungseinheiten (USV) liefern im Falle eines Stromausfalls Notstrom für kritische und wichtige Verbraucher in der Einrichtung. Rechenzentren verwenden Generatoren, um die gesamte Einrichtung mit Notstrom zu versorgen.

Energiemanagement: Um den ökologischen Fussabdruck der Infrastrukturen zu reduzieren, hat Orange ein umweltfreundliches Rechenzentrum gewählt. Um Stromausfälle zu vermeiden, wird die Stromversorgung verdoppelt und die Standorte verfügen über autonome Generatoren. Redundante Versorgungssysteme Redundante allgemeine Tabelle der Niederspannungsverteilung Generator - mit 72-stündiger Mindestautonomie Wechselrichter

Klima und Temperatur

Amazon Webdienste

Orange Flexible Engine

Die Klimakontrolle ist erforderlich, um eine konstante Betriebstemperatur für Server und andere Hardware aufrechtzuerhalten, was eine Überhitzung verhindert und die Möglichkeit von Serviceausfällen reduziert. Rechenzentren sind klimatisiert, um die atmosphärischen Bedingungen auf einem optimalen Niveau zu halten. Personal und Systeme überwachen und steuern Temperatur und Luftfeuchtigkeit auf einem angemessenen Niveau.

N+1-Redundanz, d. h. der Ausfall eines Klimageräts hat keine Auswirkungen auf die Kühlkette

Außerbetriebnahme von Speichergeräten

Amazon Webdienste

Orange Flexible Engine

Wenn ein Speichergerät das Ende seiner Nutzungsdauer erreicht hat, umfassen die AWS-Verfahren einen Stilllegungsprozess, der verhindern soll, dass Kundendaten in die Hände Unbefugter gelangen. AWS wendet die in DoD 5220.22-M ("National Industrial Security Program Operating Manual") oder NIST 800-88 ("Guidelines for Media Sanitization") beschriebenen Techniken an, um Daten im Rahmen des Stilllegungsprozesses zu vernichten. Alle außer Betrieb genommenen Magnetspeichergeräte werden entmagnetisiert und gemäß dem Industriestandard physisch vernichtet.

Schutz von nicht mehr zugewiesenen Kundendaten Auf Kundendaten, die sich auf nicht mehr zugewiesenen Ressourcen befinden, kann kein anderer Kunde zugreifen. Dieser Schutz wird durch die internen Mechanismen der von Orange verwendeten Produkte gewährleistet. OpenStack verfügt zum Beispiel über einen internen Prozess, um die Ressource zu löschen, bevor sie einem anderen Kunden zugewiesen wird. Löschung von Kundendaten bei Vertragsbeendigung Wenn der Vertrag endet, werden alle den Kunden zugewiesenen Ressourcen gelöscht, und die Kundendaten werden unbrauchbar, wie im vorherigen Absatz erläutert. Sichere Entsorgung oder Wiederverwendung von Geräten Alle Geräte, die Speichermedien enthalten, werden überprüft, um sicherzustellen, dass alle sensiblen Daten und lizenzierte Software vor der Entsorgung entfernt oder sicher überschrieben worden sind. Orange hat Sicherheitsrichtlinien erstellt, in denen die Sanierungs- und Entsorgungsverfahren für den Umgang mit Speichermedien genau beschrieben sind.

Physischer Zugang zum Rechenzentrum

Amazon Webdienste

Orange Flexible Engine

Die Rechenzentren von AWS sind auf dem neuesten Stand der Technik und nutzen innovative architektonische und technische Ansätze. Amazon verfügt über viele Jahre Erfahrung in der Entwicklung, dem Bau und dem Betrieb großer Rechenzentren. Diese Erfahrung ist in die AWS-Plattform und -Infrastruktur eingeflossen. Die AWS-Rechenzentren sind in unauffälligen Einrichtungen untergebracht. Der physische Zugang wird sowohl an den Außengrenzen als auch an den Gebäudeeingängen durch professionelles Sicherheitspersonal mit Hilfe von Videoüberwachung, Einbruchserkennungssystemen und anderen elektronischen Mitteln streng kontrolliert. Autorisierte Mitarbeiter müssen mindestens zweimal eine Zwei-Faktor-Authentifizierung durchlaufen, um Zugang zu den Etagen des Rechenzentrums zu erhalten. Alle Besucher und Auftragnehmer müssen sich ausweisen, werden angemeldet und ständig von autorisiertem Personal begleitet. AWS gewährt den Zugang zum Rechenzentrum und zu Informationen nur Mitarbeitern und Auftragnehmern, die einen legitimen geschäftlichen Bedarf für diese Privilegien haben. Wenn ein Mitarbeiter diese Rechte nicht mehr benötigt, wird ihm der Zugang sofort entzogen, auch wenn er weiterhin ein Mitarbeiter von Amazon oder Amazon Web Services ist. Jeder physische Zugang von AWS-Mitarbeitern zu Rechenzentren wird protokolliert und routinemäßig überprüft.

Physische Sicherheit: Strenge Zugangskontrollen zu den Rechenzentren, einschließlich der Identifizierung von Personen nach Erteilung der Genehmigung zum Betreten der Datenräume. Die Standorte werden rund um die Uhr mit dreifacher Zugangskontrolle und Videoüberwachungssystemen geschützt und beaufsichtigt. Störungs- und Wartungstoleranz: Die verwendeten technischen Architekturen ermöglichen die Einhaltung der folgenden Betriebsvorgaben: Keine Beeinträchtigung der Last beim Auftreten der ersten Störung. Hohe Störungstoleranz, bis zu 2 größere Störungen ohne Beeinträchtigung. Keine Unterbrechung des Betriebs während der Wartungsarbeiten. Die Verwaltungsmodi und die verwendeten Verfahren gewährleisten die Sicherheit des Personals, der Gebäude und der darin befindlichen Anlagen.

Management der Geschäftskontinuität

Verfügbarkeit

Amazon Webdienste

Orange Flexible Engine

Die Rechenzentren werden in Clustern in verschiedenen globalen Regionen aufgebaut. Alle Rechenzentren sind online und bedienen Kunden; kein Rechenzentrum ist "kalt". Im Falle eines Ausfalls wird der Datenverkehr der Kunden durch automatisierte Prozesse aus dem betroffenen Gebiet umgeleitet. Die Kernanwendungen werden in einer N+1-Konfiguration bereitgestellt, so dass bei einem Ausfall eines Rechenzentrums genügend Kapazität vorhanden ist, um den Datenverkehr auf die verbleibenden Standorte auszugleichen.

Alle unsere Cloud-Dienste verfügen über eine vollständige Redundanz der Infrastruktur über mehrere Standorte (oder, als vorübergehende Ausnahme, über mehrere Computerräume), mit Hochverfügbarkeitsmechanismen, so dass lokale Ausfälle transparent gemacht werden: Netzwerk (Internetzugang, VPN-Zugang, Firewall), Verwaltungsportal, Virtualisierung, Speicherung usw. Backups (Konfigurationen, Kunden-Backups) werden vorrangig an entfernten Standorten repliziert, um die Verfügbarkeit der Daten im Falle eines größeren Störfalls am Produktionsstandort zu gewährleisten. Je nach Dienst werden Remote-Kunden-Backups nur als Option angeboten. Die Cloud Orange-Dienste werden von verschiedenen Betriebsplattformen aus betrieben. Wenn also ein Betriebsstandort vollständig ausfällt, ist die Kontinuität der Verwaltung für die Cloud-Dienste gewährleistet. Die betriebliche Kontinuität wird regelmässig durch Simulationen getestet.

Unternehmensweite Überprüfung durch die Geschäftsleitung

Amazon Webdienste	Orange Flexible Engine
Amazons Innenrevisionsgruppe hat vor kurzem die Pläne für die Ausfallsicherheit der AWS-Services überprüft, die auch regelmäßig von Mitgliedern des Senior Executive Management Teams und des Audit Committee des Board of Directors überprüft werden.	Ein Sicherheitsausschuss, dem die Sicherheitsmanager (Technik und Betrieb) und der Produktmanager angehören, führt monatliche Überprüfungen durch: Die Risiken die Sicherheitsindikatoren den Sicherheitsaktionsplan Die Sicherheitsstrategie

Sicherheit des Netzes

Sichere Netzwerkarchitektur

Amazon Webdienste

Orange Flexible Engine

Netzwerkgeräte, einschließlich Firewalls und andere Grenzgeräte, überwachen und steuern die Kommunikation an der externen Grenze des Netzwerks und an wichtigen internen Grenzen innerhalb des Netzwerks. Diese Boundary-Geräte verwenden Regelsätze, Zugriffskontrolllisten (ACL) und Konfigurationen, um den Informationsfluss zu bestimmten Informationssystemdiensten zu erzwingen. ACLs oder Richtlinien für den Datenfluss werden auf jeder verwalteten Schnittstelle eingerichtet, die den Datenfluss verwalten und erzwingen. Die ACL-Richtlinien werden von Amazon Information Security genehmigt. Diese Richtlinien werden automatisch mit dem ACL-Manage-Tool von AWS übertragen, um sicherzustellen, dass diese verwalteten Schnittstellen die aktuellsten ACLs durchsetzen.

Die Architekturen verwenden dasselbe Modell zur Trennung der Vertrauensbereiche, einschließlich des Back-Ends (internes Orange) und des Front-Ends, das die Cloud-Services für die Kunden unterstützt. Die Partitionierung zwischen Back-End und Front-End ist physisch, was bedeutet, dass einige Server dem Back-End und andere dem Front-End gewidmet sind. Innerhalb jedes Vertrauensbereichs sorgen Sicherheitszonen für eine logische Partitionierung durch die Implementierung bestimmter Funktionen wie z. B.: Virtualisierung (virtuelle Maschinen, virtuelle Firewall, virtuelle Load-Balancer, virtuelle Router / VRF) VLANs (802.1Q) Virtuelle Netzwerke (VPN IPSec, SSL) Virtuelle Speicherung (virtuelle Laufwerke) Diese logische Partitionierung garantiert die Isolierung der verschiedenen Kundenumgebungen. Die Kommunikation (Netzwerkfluss) zwischen den verschiedenen Sicherheitszonen wird systematisch durch Firewalls kontrolliert (Stateful Filtering). Die lokale Konfiguration der verschiedenen Komponenten wird ebenfalls so gestaltet, dass die Partitionierung und die Sicherheit verstärkt werden (z. B. ACL in Routern).

Sichere Zugangspunkte

Amazon Webdienste

Orange Flexible Engine

AWS hat strategisch eine begrenzte Anzahl von Zugangspunkten zur Cloud eingerichtet, um eine umfassendere Überwachung der ein- und ausgehenden Kommunikation und des Netzwerkverkehrs zu ermöglichen. Diese Kundenzugriffspunkte werden als API-Endpunkte bezeichnet und ermöglichen einen sicheren HTTP-Zugriff (HTTPS), der es Ihnen ermöglicht, eine sichere Kommunikationssitzung mit Ihren Speicher- oder Recheninstanzen innerhalb von AWS aufzubauen. Um Kunden mit FIPS-Kryptoanforderungen zu unterstützen, sind die SSL-terminierenden Load Balancer in AWS GovCloud (US) FIPS 140-2-kompatibel. Darüber hinaus hat AWS Netzwerkgeräte implementiert, die für die Verwaltung der Schnittstellenkommunikation mit Internetdienstanbietern (ISPs) zuständig sind. AWS verwendet eine redundante Verbindung zu mehr als einem Kommunikationsdienst an jedem dem Internet zugewandten Rand des AWS-Netzwerks. Diese Verbindungen verfügen jeweils über dedizierte Netzwerkgeräte.

Flexible Engine bietet Services, die es einem Benutzer ermöglichen, eine virtualisierte Infrastruktur über eine gemeinsam genutzte physische Infrastruktur für alle Benutzer zu erstellen. Die implementierten Virtualisierungsmechanismen gewährleisten eine starke logische Partitionierung der virtualisierten Ressourcen des Mandanten (eine pro Mandant). Der Zugriff auf die Ressourcen eines Mandanten erfolgt über die OpenStack-APIs, die eine starke (Login / Passwort / Token) und sichere (in SSL über https) Authentifizierung implementieren. Die Kunden verbinden sich mit den Cloud-Umgebungen zum Zwecke der Verwaltung oder des Zugriffs auf Anwendungsdienste. Der Zugriff auf die Umgebungen kann über das Internet und/oder ein privates Netzwerk (VPN-Client) erfolgen, je nach den vom Kunden gewählten Funktionen und Optionen. Der Zugang der Kunden ist immer über SSL / TLS (HTTPS oder SSH-Flows) gesichert: Die Authentifizierung gegenüber einem Server (Verwaltungsportale, Anwendungsserver) erfolgt routinemäßig über ein X.509-Zertifikat des "Servers", das von einer anerkannten Zertifizierungsstelle bereitgestellt wird. Die Authentifizierung eines Kunden erfolgt über eine Login/Passwort-Kombination, die zuvor über ein gesichertes Verfahren übermittelt wurde. Bei einigen Angeboten ist es möglich, eine starke Authentifizierung zu implementieren (Token-Generierung eines Passworts zur einmaligen Verwendung, "Client"-X.509-Zertifikat). Die Netzwerkflüsse werden systematisch verschlüsselt (mit AES-Algorithmus).

Schutz der Übertragung

Amazon Webdienste

Orange Flexible Engine

Sie können eine Verbindung zu einem AWS-Zugangspunkt über HTTPS mit Secure Sockets Layer (SSL) herstellen, einem kryptografischen Protokoll, das vor Abhören, Manipulation und Nachrichtenfälschung schützen soll. Für Kunden, die zusätzliche Ebenen der Netzwerksicherheit benötigen, bietet AWS die Amazon Virtual Private Cloud (VPC) an, die ein privates Subnetz innerhalb der AWS-Cloud bereitstellt und die Möglichkeit bietet, ein IPsec Virtual Private Network (VPN)-Gerät zu verwenden, um einen verschlüsselten Tunnel zwischen der Amazon VPC und Ihrem Rechenzentrum bereitzustellen.

Die Kunden stellen eine Verbindung zu Cloud-Umgebungen her, um sie zu verwalten oder auf Dienste zuzugreifen. Die Verwaltungsabläufe der Kunden werden systematisch durch Protokolle zur Gewährleistung der Authentifizierung, Vertraulichkeit und Integrität (SSLv3/TLS, AES256, ...) gesichert. Die Zugriffsmethoden variieren je nach den vom Kunden gewählten Funktionen und Optionen. Die Sicherheit der Dienstflüsse hängt vom jeweiligen Angebot ab, aber im Allgemeinen ist der Austausch durch SSL/TLS-Verbindungen gesichert. Virtual Private Cloud (VPC)-Funktionen, die von der Neutron Openstack-Komponente getragen werden, bieten eine logische Partitionierung der Kommunikation im Benutzernetzwerk. Jede Form von Netzwerkverkehr, die nicht von Natur aus für den Kunden-Tenant zugelassen ist, wird von den Geräten, die das virtuelle Netzwerk des Kunden unterstützen, nicht verarbeitet, wodurch der Einsatz von Spoofing-Technologien verhindert wird. Der gesamte Datenverkehr des Kunden wird nach Norden und nach oben geleitet, wobei das Routing unter einer Sicherheitsschicht erfolgt, die durch eine Firewall auf Industrieniveau mit hochmodernen Firewall-Geräten bereitgestellt wird.

Fehlertolerantes Design

Amazon Webdienste

Orange Flexible Engine

AWS hat seine Systeme so konzipiert, dass System- oder Hardwareausfälle mit minimalen Auswirkungen auf den Kunden toleriert werden können. Die Rechenzentren werden in Clustern in verschiedenen globalen Regionen aufgebaut. Alle Rechenzentren sind online und bedienen Kunden; kein Rechenzentrum ist "kalt". Im Falle eines Ausfalls wird der Datenverkehr der Kunden durch automatisierte Prozesse aus dem betroffenen Bereich umgeleitet. Die Kernanwendungen werden in einer N+1-Konfiguration bereitgestellt, so dass bei einem Ausfall eines Rechenzentrums genügend Kapazität vorhanden ist, um den Datenverkehr auf die verbleibenden Standorte auszugleichen.

TIER-Klassifizierung - Die Rechenzentren für Flexible Engine werden so gebaut und betrieben, dass sie mit den TIER III-Anforderungen kompatibel sind. Toleranz gegenüber Ausfällen und Wartung - Die verwendeten technischen Architekturen ermöglichen die Einhaltung der folgenden Betriebsbedingungen: Keine Beeinträchtigung der Last beim Auftreten der ersten Störung. Hohe Störungstoleranz, bis zu 2 größere Störungen ohne Beeinträchtigung. Keine Unterbrechung des Betriebs während der Wartungsarbeiten. Die Verwaltungsmodi und die verwendeten Verfahren gewährleisten die Sicherheit des Personals, der Gebäude und der darin befindlichen Anlagen.

Überwachung und Schutz des Netzes

Amazon Webdienste

Orange Flexible Engine

AWS nutzt eine Vielzahl von automatisierten Überwachungssystemen, um ein hohes Maß an Serviceleistung und Verfügbarkeit zu gewährleisten. Die AWS-Überwachungstools sind so konzipiert, dass sie ungewöhnliche oder nicht autorisierte Aktivitäten und Bedingungen an Eingangs- und Ausgangskommunikationspunkten erkennen. Diese Tools überwachen die Server- und Netzwerknutzung, Port-Scanning-Aktivitäten, Anwendungsnutzung und unbefugte Eindringungsversuche. Die Tools haben die Möglichkeit, benutzerdefinierte Schwellenwerte für Leistungsmetriken bei ungewöhnlichen Aktivitäten festzulegen. Die AWS-Sicherheitsüberwachungs-Tools helfen bei der Erkennung verschiedener Arten von Denial-of-Service-Angriffen (DoS), einschließlich verteilter Angriffe, Flooding-Angriffe und Software/Logik-Angriffe. Wenn DoS-Angriffe identifiziert werden, wird der AWS-Reaktionsprozess eingeleitet. Zusätzlich zu den DoS-Präventionstools schützen redundante Telekommunikationsanbieter in jeder Region sowie zusätzliche Kapazitäten vor der Möglichkeit von DoS-Angriffen. Das AWS-Netzwerk bietet einen erheblichen Schutz gegen herkömmliche Netzwerksicherheitsprobleme, und Sie können weitere Schutzmaßnahmen implementieren. Im Folgenden finden Sie einige Beispiele: Verteilte Denial-of-Service-Angriffe (DDoS). AWS-API-Endpunkte werden auf einer großen, internetfähigen Infrastruktur von Weltklasse gehostet, die von derselben technischen Expertise profitiert, die Amazon zum weltweit größten Online-Händler gemacht hat. Es werden proprietäre DDoS-Abwehrtechniken eingesetzt. Darüber hinaus werden die AWS-Netzwerke über mehrere Anbieter gehostet, um einen vielfältigen Internetzugang zu gewährleisten. Man-in-the-Middle-Angriffe (MITM). Alle AWS-APIs sind über SSL-geschützte Endpunkte verfügbar, die eine Server-Authentifizierung ermöglichen. Amazon EC2 AMIs generieren beim ersten Start automatisch neue SSH-Host-Zertifikate und protokollieren sie in der Konsole der Instanz. Sie können dann die sicheren APIs verwenden, um die Konsole aufzurufen und auf die Host-Zertifikate zuzugreifen, bevor Sie sich zum ersten Mal bei der Instanz anmelden. Wir empfehlen Ihnen, SSL für alle Ihre Interaktionen mit AWS zu verwenden. IP-Spoofing. Amazon EC2-Instanzen können keinen gefälschten Netzwerkverkehr senden. Die von AWS kontrollierte, hostbasierte Firewall-Infrastruktur erlaubt es einer Instanz nicht, Datenverkehr mit einer anderen Quell-IP oder MAC-Adresse als der eigenen zu senden. Port-Scans. Unerlaubte Port-Scans durch Amazon EC2-Kunden stellen einen Verstoß gegen die AWS Acceptable Use Policy dar. Verstöße gegen die AWS Acceptable Use Policy werden ernst genommen, und jeder gemeldete Verstoß wird untersucht. Kunden können vermuteten Missbrauch über die auf unserer Website verfügbaren Kontakte melden: http://aws.amazon.com/contact-us/report-abuse/. Wenn AWS unautorisiertes Port-Scanning feststellt, wird es gestoppt und blockiert. Port-Scans von Amazon EC2-Instanzen sind im Allgemeinen unwirksam, da standardmäßig alle eingehenden Ports auf Amazon EC2-Instanzen geschlossen sind und nur von Ihnen geöffnet werden. Ihre strikte Verwaltung von Sicherheitsgruppen kann die Bedrohung durch Port-Scans weiter eindämmen. Wenn Sie die Sicherheitsgruppe so konfigurieren, dass Datenverkehr von einer beliebigen Quelle zu einem bestimmten Port zugelassen wird, ist dieser bestimmte Port für einen Port-Scan anfällig. In diesen Fällen müssen Sie geeignete Sicherheitsmaßnahmen ergreifen, um abhörende Dienste, die für ihre Anwendung wichtig sind, davor zu schützen, von einem nicht autorisierten Port-Scan entdeckt zu werden. Beispielsweise muss ein Webserver den Port 80 (HTTP) eindeutig für die Welt geöffnet haben, und der Administrator dieses Servers ist für die Sicherheit der HTTP-Server-Software, wie z. B. Apache, verantwortlich. Sie können die Erlaubnis zur Durchführung von Schwachstellen-Scans beantragen, wenn dies zur Erfüllung Ihrer spezifischen Compliance-Anforderungen erforderlich ist. Diese Scans müssen auf Ihre eigenen Instanzen beschränkt sein und dürfen nicht gegen die AWS Acceptable Use Policy verstoßen. Eine erweiterte Genehmigung für diese Art von Scans kann durch Einreichen einer Anfrage über die Websitehttps://aws-portal.amazon.com/gp/aws/html-forms-controller/contactus/AWSSecurityPenTestRequest beantragt werden. Packet Sniffing durch andere Mieter. Es ist nicht möglich, dass eine virtuelle Instanz, die im Promiscuous-Modus läuft, Datenverkehr empfängt oder "schnüffelt", der für eine andere virtuelle Instanz bestimmt ist. Sie können Ihre Schnittstellen zwar in den Promiscuous-Modus versetzen, aber der Hypervisor leitet keinen Datenverkehr an sie weiter, der nicht für sie bestimmt ist. Selbst zwei virtuelle Instanzen, die demselben Kunden gehören und sich auf demselben physischen Host befinden, können den Datenverkehr des jeweils anderen nicht abhören. Angriffe wie ARP-Cache-Poisoning funktionieren nicht innerhalb von Amazon EC2 und Amazon VPC. Auch wenn Amazon EC2 einen ausreichenden Schutz davor bietet, dass ein Kunde versehentlich oder böswillig versucht, die Daten eines anderen Kunden einzusehen, sollten Sie den sensiblen Datenverkehr standardmäßig verschlüsseln. Zusätzlich zur Überwachung werden regelmäßige Schwachstellen-Scans des Host-Betriebssystems, der Webanwendung und der Datenbanken in der AWS-Umgebung mit einer Vielzahl von Tools durchgeführt. Außerdem abonnieren die AWS-Sicherheitsteams Newsfeeds für Schwachstellen von Anbietern und überwachen proaktiv die Websites von Anbietern und andere relevante Stellen auf neue Patches. AWS-Kunden haben auch die Möglichkeit, AWS Probleme über die AWS Vulnerability Reporting-Website zu melden: http://aws.amazon.com/fr/security/vulnerability-reporting/.

DDoS Orange Business Services verfügt über Mittel zum Schutz seiner Kunden vor Denial-of-Service-Angriffen und Angriffen auf das Netzwerk in Flexible Engine. Um das komplexe Defense-in-Depth-Sicherheitsdesign und die Implementierung von Sicherheitslösungen zu vereinfachen, haben wir Sicherheitszonen und eine ganzheitliche Netzwerksegregationsstrategie definiert, um die Auswirkungen von Angriffen auf der Grundlage von Geschäftsfunktionen und Sicherheitsrisiken zu minimieren. Zusätzlich zu den fortschrittlichen Perimeterschutzmaßnahmen von Flexible Engine können die Mieter auch fein abgestufte Richtlinien für Anti-DDoS für ihre EIPs, Sicherheitsgruppen in VPC und Zugriffskontrollen über IAM festlegen, um den Gesamtschutz gegen externe Bedrohungsakteure und böswillige Insider zu stärken. ECS-Sicherheitsarchitektur ECS nutzt Ressourcenisolierung, Netzwerkisolierung, Sicherheitsgruppenregeln, Anti-DDoS und die Verhinderung von Brute-Force-Angriffen, um eine sichere Umgebung zu schaffen. ECS unterstützt 99,95 % Verfügbarkeit und 99,99995 % Datenbeständigkeit. VPC Virtual Private Cloud (VPC)-Funktionen, die von der Neutron Openstack-Komponente getragen werden, bieten eine logische Partitionierung der Kommunikation im Benutzernetzwerk. Jede Form von Netzwerkverkehr, die nicht von Natur aus für den Kunden-Tenant zugelassen ist, wird von den Geräten, die das virtuelle Netzwerk des Kunden unterstützen, nicht verarbeitet, wodurch der Einsatz von Spoofing-Technologien verhindert wird. Der gesamte Datenverkehr des Kunden wird nach Norden und nach oben geleitet, wobei das Routing unter einer Sicherheitsschicht erfolgt, die durch eine Firewall auf Industrieniveau mit hochmodernen Firewall-Geräten bereitgestellt wird. Schutz vor IP/MAC-Adressen-Spoofing Um Netzwerkprobleme zu vermeiden, die auftreten können, wenn Benutzer ihre IP- oder MAC-Adressen nach Belieben ändern, werden IP- und MAC-Adressen durch DHCP-Snooping aneinander gebunden. Spoofing wird außerdem durch den Einsatz von IP Source Guard und dynamischer ARP-Inspektion (DAI) verhindert, um Pakete von nicht gebundenen Adressen herauszufiltern. Blackholing-Sonden im Herzen des Orange Group Netzwerks Dieses System schützt vor massiven Denial-of-Service-Angriffen aus dem Internet und wird ausgelöst, sobald der Angriff 1 Gb Datenverkehr erreicht. Es wird im Herzen des Betreibernetzes der Orange Gruppe eingesetzt und verwendet eine speziell für diesen Zweck entwickelte Sicherheitsausrüstung. Die Lösung bietet zwei Leistungsstufen, eine Standard- und eine optionale Stufe: Aktivierung einer Funktion des Typs "black-hole" / "blackholing": Diese Lösung macht die angegriffenen IP-Adressen vom Internet aus unerreichbar und schützt die anderen Kunden der Public Cloud vor möglichen Randeffekten, wie z.B. einer Leistungsverschlechterung der Internetbandbreite. Dies ist standardmäßig im Dienst enthalten. Umleitung von Datenströmen an ein Echtzeit-Reinigungszentrum und anschließende Weiterleitung an den gesunden Datenverkehr. Dies ist ein kostenpflichtiger optionaler Dienst. Firewalls an den Eingängen der Orange Cloud-Plattformen Firewalls schützen die Orange Cloud-Plattformen vor Angriffen mit geringerem Volumen (weniger als 2 GB), aber auf feinere Art und Weise, indem sie nur die Pakete filtern, die durch die Analyse bestimmter Protokolle als verdächtig eingestuft werden, wie z. B.: IP-Protokolle: SYN Flood, UDP Flood, ICMP Flood, Land Attack, ICMP Fragment, ICMP Large Packets, SYN Fragmente. Anwendbare Datenströme: Firewalls sind auch in der Lage, spezifische Angriffe auf einige Anwendungsprotokolle zu erkennen: DNS, FTP, HTTP, REAL, RSH, RTSP, TALK, TFTP, XING, ... Erkennung von Eindringversuchen in gemeinsam genutzte Cloud-Dienste, die sich auf den Orange Cloud-Plattformen befinden IDS-Sonden werden zur Überwachung der Cloud-Verwaltungsdienste (Verwaltungsportal, Verwaltungsdienste, ...) eingesetzt. Die einem Kunden gewidmeten virtuellen Maschinen werden standardmässig nicht überwacht, da die Analyse der Alarme die Kenntnis des Kundenkontextes erfordert. Die Implementierung der Überwachung der Server des Kunden kann als Option vorgeschlagen werden. Allgemeiner ausgedrückt: Die Überwachung aller Komponenten der Infrastruktur gewährleistet eine globale Erkennung von Eindringlingen.

Kontoüberprüfung und Audit

Amazon Webdienste

Orange Flexible Engine

Konten werden alle 90 Tage überprüft; eine explizite erneute Genehmigung ist erforderlich, oder der Zugriff auf die Ressource wird automatisch widerrufen. Der Zugriff wird auch automatisch entzogen, wenn der Datensatz eines Mitarbeiters in Amazons Human Resources System beendet wird. Windows- und UNIX-Konten werden deaktiviert und Amazons Berechtigungsmanagementsystem entfernt den Benutzer aus allen Systemen. Anträge auf Änderungen des Zugriffs werden im Audit-Protokoll des Amazon-Pro-Missions-Management-Tools erfasst. Wenn sich die Funktion eines Mitarbeiters ändert, muss der weitere Zugriff auf die Ressource explizit genehmigt werden, sonst wird er automatisch widerrufen.

Eine Überprüfung der Berechtigungen und Rechte wird jedes Semester durchgeführt. Dabei wird die Personalakte, in der die Rollen der einzelnen Personen beschrieben sind, mit den tatsächlich in den Systemen zugewiesenen Rechten verglichen. Werden nicht legitimierte Rechte festgestellt, werden geeignete Maßnahmen ergriffen: Sperrung des Kontos Untersuchung der Nutzungsspuren, um eventuelle Vorfälle aufzudecken Abhilfemaßnahmen (Aktualisierung der Verfahren, Sensibilisierung der Leitung usw.). Das Verfahren zur Zuweisung/Widerruf eines Kontos und der damit verbundenen Rechte, CARM (Controlling Access Rights Management) genannt, wird angewendet und überwacht. Dieses Verfahren ist eine ISMS-Sicherheitsmassnahme (Information Security Management Systems), die nach ISO 27001 zertifiziert ist und von Orange eingesetzt wird. Gemeinsam genutzte Konten sind verboten.

Hintergrund-Checks

Amazon Webdienste

Orange Flexible Engine

AWS hat formelle Richtlinien und Verfahren eingeführt, um die Mindeststandards für den logischen Zugriff auf AWS-Plattform- und Infrastruktur-Hosts festzulegen. AWS führt, soweit gesetzlich zulässig, im Rahmen der Einstellungsprüfung für Mitarbeiter und entsprechend der Position des Mitarbeiters und der Zugriffsebene kriminelle Hintergrundüberprüfungen durch. Die Richtlinien legen auch die funktionalen Verantwortlichkeiten für die Verwaltung des logischen Zugriffs und der Sicherheit fest.

Orange verfügt über formelle Richtlinien, die sicherstellen, dass während des Einstellungsprozesses Hintergrundüberprüfungen innerhalb des Teams durchgeführt werden, und zwar in Übereinstimmung mit den lokalen Vorschriften.

VPN

Amazon Webdienste	Orange Flexible Engine
Eine VPN-Verbindung kann als Option zwischen Ihrem Netzwerk und Ihrem VPC auf AWS eingerichtet werden, um Tools aus Ihrer Infrastruktur und Tools, die auf unserem Cloud-Angebot gehostet werden, zu integrieren, z. B. LDAP/Active Directory-Integration, andere Atlassian-Tools, Remote-Datenquelle...	VPN as a Service ist verfügbar, um Ihr Netzwerk mit der Orange Flexible Engine VPC zu verbinden: https://cloud.orange-business.com/en/offers/infrastructure-iaas/public-cloud/features/vpn-as-a-service/

Sicherheit der Workstations

Alle Mitarbeiter unseres Managed-Services-Teams sind mit Cisco AMP ausgestattet, das uns vor Viren, Malware und Datenverlusten schützt.

Getrennte Private Clouds pro Kunde

Jeder Kunde hat seine eigene VPC (Virtual Private Cloud), die sein Netzwerk und seine Daten von denen anderer Kunden trennt.

Firewalls

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

Die Standardkonfiguration sieht wie folgt aus:

Eingehend		Ausgehend
Anschluss	Quelle	Anschluss	Ziel
22	Nur Bastion-Server, die nur von den IP-Adressen der Valiantys-Büros aus erreichbar sind	Alle	Überall
80	Überall*
443	Überall

*Bitte beachten Sie, dass alle Anfragen, die an Port 80 gesendet werden, mit HTTPS automatisch auf Port 443 umgeschrieben werden, indem eine Apache HTTPD Rewrite-Regel verwendet wird.

Diese Standard-Firewall-Einstellung kann je nach den Anforderungen des Kunden angepasst werden.

Berechtigungsnachweise

Individuelle Benutzerkonten

Jedes Mitglied unseres Managed Services-Teams hat über ein individuelles Konto Zugriff auf die Verwaltungskonsole und die Server.

Alle Aktionen werden protokolliert und können jederzeit von unserem Team eingesehen werden. Die Zugriffsprotokolle werden für einen Zeitraum von 4 Wochen aufbewahrt.

Passwort-Richtlinie

Für den Zugang zur AWS- und OFE-Konsole ist ein Passwort erforderlich, das mindestens 8 Zeichen enthält, darunter einen Großbuchstaben, einen Kleinbuchstaben, eine Zahl und ein Sonderzeichen. Das Passwort muss alle 40 Tage geändert werden, und es wird eine Ähnlichkeitsprüfung mit den letzten 5 Passwörtern durchgeführt.

Multi-Faktor-Authentifizierung

Zusätzlich zum Anmelde-/Passwortschutz ist für den Zugriff auf die AWS-Konsole ein Code erforderlich, der von der mobilen App Google Authenticator (oder Authy) generiert wird, die mit dem Konto des Nutzers verbunden ist. Die Codes werden alle 30 Sekunden generiert.

Server-Zugang

Der Serverzugriff über SSH ist aufgrund der Sicherheitsgruppen- und VPC-Peering-Konfiguration nur über die statische IP der Bastion-Server an den verschiedenen Standorten von Valiantys möglich. Der Zugang ist durch einen individuellen passphrasengeschützten privaten Schlüssel gesichert.

Die privaten Schlüssel werden sicher auf den Computern der einzelnen Personen gespeichert.

Sicherheit der Daten

Zugang zu den Daten

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

Da die Daten auf den von uns bereitgestellten Volumes verschlüsselt sind, haben sie keinen Zugriff auf die gespeicherten Daten.

Löschung der Daten bei Vertragsende

Valiantys verpflichtet sich, alle Kundendaten nach Ablauf des Vertrags zu löschen.

Wenn ein Kunde seinen Vertrag nicht verlängern möchte, folgen wir diesem Prozess:

• Wir führen ein vollständiges Backup der Kundenumgebung durch (XML-Backup + Anhänge für alle Atlassian-Tools)
• Wir stellen dem Kunden dieses Backup über eine sichere Methode zur Verfügung (vom Kunden bereitgestellt oder standardmäßig über einen AWS S3-Bucket mit eigenem Login/Passwort)
• Sobald der Kunde alle Daten erfolgreich abgerufen hat, entfernen wir diese Daten aus dem Repository
• Wir fahren den Server herunter und löschen ihn vollständig
• Wir warten 1 Monat, bevor wir die Snapshots der Server löschen, für den Fall, dass der Kunde Probleme beim Importieren der Daten auf seiner Seite hat. Diese Wartezeit kann auf Wunsch des Kunden verkürzt werden.

Sobald alle Daten auf unserer Seite gelöscht wurden, senden wir dem Kunden eine E-Mail, in der wir ihm mitteilen, dass Valiantys keine Kundendaten mehr besitzt.

SSL

Der Zugriff auf die Atlassian-Tools ist nur über SSL (TLS v1.2-Protokoll) unter Verwendung unseres Standardzertifikats *.valiantys.net(2048-Bit-Schlüssel) oder über vom Kunden bereitgestellte Zertifikate, die mit seinem eigenen Domainnamen verknüpft sind, möglich.

Verschlüsselung der Daten

Amazon Webdienste

Orange Flexible Engine

Das Dateisystem kann mit einem eindeutigen 256-Bit-Schlüssel verschlüsselt werden; alle Snapshots von diesem Server werden dann mit demselben Schlüssel verschlüsselt. Die gesamte Schlüsselverwaltungsinfrastruktur von Amazon verwendet nach Federal Information Processing Standards (FIPS) 140-2 genehmigte kryptografische Algorithmen und entspricht den Empfehlungen des National Institute of Standards and Technology (NIST) 800-57.

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

Sicherheits-Logs

Auf den von uns verwalteten Servern werden alle Arten von Protokollen aufgezeichnet:

• SSH-Zugriffsprotokolle, die alle SSH-Zugriffe auf den Server protokollieren
• Apache-HTTPD-Zugriffsprotokolle, die alle HTTP-Anfragen auf dem Server protokollieren
• Anwendungszugriffsprotokolle, die alle HTTP-Anfragen protokollieren, die auf die Tools eingehen

Diese Protokolldateien sind auf Anfrage zugänglich.

Backups

Vollständige VM-Snapshots werden automatisch jede Nacht gegen Mitternacht erstellt und 7 Tage lang aufbewahrt. Die Snapshots sind verschlüsselt.

Zusätzlich zu diesen Backups werden jeden Tag automatisch XML-Backups von den Atlassian-Tools erstellt. Sie ermöglichen in manchen Fällen eine schnellere Wiederherstellung der Daten (z. B. bei Daten, die durch einen Fehler gelöscht wurden).

Diese XML-Backups können von unserem Team in größeren Umgebungen deaktiviert werden, um Leistungsprobleme zu vermeiden.

Aufbewahrung von Backups

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

Wiederherstellungsvorgang

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

VM-Snapshot-Wiederherstellung:

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

XML-Export-Wiederherstellung:

• Wir kopieren den XML-Export in den Wiederherstellungsordner
• Wir starten den XML-Importprozess (kann je nach Größe der Umgebung zwischen einigen Minuten und einigen Stunden dauern)

Überprüfung des Wiederherstellungsprozesses

Um sicherzustellen, dass unsere Sicherungen und Sicherungsverfahren wie erwartet funktionieren, führen wir einmal pro Jahr einen Wiederherstellungstest für alle unsere Server durch.

Ein Bericht über die Ergebnisse kann dem Kunden auf Wunsch zur Verfügung gestellt werden.

Pen-Tests

Wir führen mindestens einmal jährlich Black-Box-Penetrationstests auf allen unseren Servern durch.

Mindestens einmal im Jahr führen wir White-Box-Penetrationstests in einer Sandbox-Umgebung durch, die wir mit dem Standard-Setup-Verfahren erstellen, das wir für die Erstellung der Kundenumgebung verwenden. Dies hilft uns, unsere Sicherheit kontinuierlich zu verbessern.

Wir erlauben unseren Kunden auch, ihre eigenen Penetrationstests durchzuführen (selbst oder durch Dritte).

Wenn ein Kunde Penetrationstests organisieren möchte, muss er sich mindestens 4 Wochen im Voraus mit uns in Verbindung setzen, da wir die Genehmigung von unseren Anbietern einholen müssen.

Schwachstellen-Management

Erkennungsprozess

Wir führen eine wöchentliche Überprüfung unserer Referenzdatenbank mit Hilfe spezieller Tools durch, zusätzlich zu den von Atlassian bereitgestellten Warnmeldungen.

Erkennungszeiten

Der Erkennungszeitraum beträgt 7 Tage (außer bei einer Atlassian-Meldung während dieses Zeitraums).

Verzögerungen bei der Behandlung

Die Behandlung erfolgt sofort. Sobald die Schwachstelle bekannt ist, wird automatisch ein Incident Ticket im Namen des Kunden erstellt, um die Behebung mit seinem Einverständnis zu organisieren und um zumindest den Produktionsdienst zu beeinträchtigen.

Meldet sich der Kunde nicht innerhalb von 7 Tagen, wird die Schwachstelle automatisch behoben, ohne dass die Zustimmung des Kunden für nicht bearbeitete Zeitnischen abgewartet wird.

Betrieb

Organisation der Sicherheit

Der Verantwortliche für die Sicherheit im Unternehmen ist derzeit Nathan Chantrenne, CTO.

Wir haben kein eigenes Sicherheitsteam. Alle Mitglieder unseres Managed Services-Teams kennen die bei Valiantys geltenden Sicherheitsregeln und sind in der Lage, mit Sicherheitsvorfällen umzugehen.

Es gibt eine Unternehmenssicherheitspolitik, die Teil unserer Unternehmensregeln und -vorschriften ist und die von jedem Mitglied von Valiantys akzeptiert werden muss. Sie umfasst die folgenden Abschnitte:

Organisation der Informationssicherheitspolitik

• EINLEITUNG
  • Zweck
  • Geltungsbereich
  • Geschichte
  • Zuständigkeiten
  • Allgemeine Definition der Politik
  • Glossar
• NETZZUGANGSRICHTLINIE
  • Zweck
  • Anwendungsbereich
  • Definition der Richtlinie
• DATEN-, INFORMATIONS- UND SICHERHEITSPOLITIK
  • Allgemeine Verwendung und Eigentum
  • Sicherheit und urheberrechtlich geschützte Informationen
  • Inakzeptable Nutzung
• EINHALTUNG DER RICHTLINIE
  • Messung der Einhaltung
  • Ausnahmen
  • Nichteinhaltung
• IT-VERMÖGENSPOLITIK
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie
• ZUGANGSKONTROLLPOLITIK
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie
• RICHTLINIE ZUR PASSWORTKONTROLLE
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie
  • Erklärung der Richtlinien
• EMAIL-POLITIK
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie
• INTERNET-POLITIK
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie
• ANTIVIRUS-RICHTLINIE
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie
• RICHTLINIE ZUR INFORMATIONSKLASSIFIZIERUNG
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie
• FERNZUGRIFFSPOLITIK
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie
• OUTSOURCING-RICHTLINIE
  • Zweck
  • Geltungsbereich
  • Definition der Politik
  • Obligatorisch
• PATCH-MANAGEMENT-RICHTLINIE
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie
• RICHTLINIE FÜR CLOUD-ANWENDUNGSINFORMATIONEN
  • Zweck
  • Geltungsbereich
  • Definition der Richtlinie

Vor der Einstellung neuer Mitarbeiter führen wir eine Zuverlässigkeitsüberprüfung durch, die von dem Land abhängt, in dem sie eingestellt werden:

• Eine grundlegende strafrechtliche Offenlegung
• Beschäftigungsgeschichte und Lückenanalyse
• Ausweiskontrolle
• Überprüfung des Rechts auf Arbeit

Change-Management-Prozess

Einreichung von Änderungen

Wenn in einem Support-Ticket eine Änderung von einem Kunden angefordert oder vom Support-Techniker identifiziert wird, ermöglicht ein Workflow-Übergang, einen bestimmten Status zu erreichen. Von diesem Status aus ist es möglich, ein Change Ticket im entsprechenden Jira-Projekt über eine spezielle Schaltfläche zu erstellen. Das erstellte Änderungsticket enthält die folgenden Informationen:

• Beschreibung - z.B.:Jira Uprgade auf 8.5.3 auf MyCustomer PROD Instanz
• Priorität - z.B.:Kritisch
• Herkunft - z.B.:Benachrichtigung von Atlassian
• Grund für die Änderung - z.B.:Sicherheitslücke in der aktuell installierten Jira-Version
• Risikoanalyse - z. B:
  • Gleiche Parameter in den Konfigurationsdateien setenv.sh und server.xml
  • Kompatibilität der installierten Anwendungen - aktualisieren Sie die betroffenen Anwendungen, falls erforderlich
  • Apps, für die eine kostenpflichtige Lizenz erforderlich ist - der Kunde muss darüber informiert werden, ebenso wie der Kundenbetreuer
  • Kein unvorhergesehenes Sicherheitsrisiko, da die Daten nirgendwo übertragen werden

• Änderungsverfahren - z.B.:<Link_zur_entsprechenden_internen_Dokumentation>
• Rollback-Verfahren - z.B.:Wiederherstellung des vor der Operation erstellten Snapshots
• Geschätzte Dauer - z.B.: 1h
• Link zum zugehörigen Support-Ticket - wird automatisch von der Jira-App definiert, die das Änderungs-Ticket erstellt

Genehmigung der Änderung

Nach der Erstellung und je nach Art des erwarteten Changes wird das Change-Ticket einem Support-Teamleiter oder einem Cloud-Architekten zugewiesen. Der zugewiesene Mitarbeiter prüft die vom Reporter bereitgestellten Informationen und entscheidet, ob er die Change-Anfrage genehmigt oder ablehnt.

Es gibt einige Gründe für die Ablehnung eines Change: technisches Risiko, Sicherheitsrisiko, unklares oder unvollständiges Verfahren usw. Wird der Change abgelehnt, wird das Change-Ticket geschlossen und der Workflow des zugehörigen Support-Tickets automatisch auf den vorherigen Status zurückgesetzt.

Wird der Change genehmigt, ermöglicht ein Formular die Planung des entsprechenden Vorgangs über die folgenden Felder:

• Startdatum - d.h. Datum und Uhrzeit, zu der der Change-Vorgang beginnen soll
• Enddatum - d.h. Datum und Uhrzeit, zu der der Änderungsvorgang enden soll
• Beauftragter - d.h. die Ressource, die für die Ausführung dieses Vorgangs zuständig ist.

Daraufhin wird das Change-Ticket mit diesen Informationen aktualisiert und der Workflow des zugehörigen Support-Tickets wird automatisch auf einen neuen Status gesetzt, der angibt, dass eine Korrekturmaßnahme geplant ist.

Anwendung ändern

Sobald der Change angewendet wurde, aktualisiert die dem Vorgang zugewiesene Ressource den Workflow-Status des Change-Tickets, was automatisch eine Aktualisierung des Workflows des zugehörigen Support-Tickets auslöst, so dass die Bearbeitung dieses Tickets fortgesetzt wird.

Notfall Change

Bei dringenden Problemen - z. B. bei Blockierungsproblemen, die von einem Kunden gemeldet werden, oder bei Sicherheitslücken, die von Atlassian gemeldet werden und sich auf einige Anwendungsversionen auswirken - wird ein Notfall-Change-Prozess mit den folgenden Abweichungen vom regulären Prozess angewendet:

• Ein Support Team Leader oder Cloud Architect bearbeitet das entsprechende Support-Ticket, erstellt und genehmigt das zugehörige Change-Ticket
• Der Change wird so schnell wie möglich geplant, abhängig von der Verfügbarkeit der Support-Ressourcen und der Zustimmung des Kunden.

Change-Ausschuss

Jeden Montagnachmittag prüft ein 30-minütigerÄnderungsausschuss, dem mindestens der Leiter der Managed Services, die Manager der Support- und Cloud-Angebote und die Leiter der Support-Teams angehören, die im letzten Zeitraum bearbeiteten Änderungsanfragen über ein spezielles Jira-Dashboard.

Prozess des Vorfallmanagements

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

Ein Vorfall kann als Schweregrad 1, 2, 3 oder 4 eingestuft werden. Definitionen für unsere Schweregrade finden Sie unter https://valiantys.com/en/legal/sla/.

Unser Managed-Services-Team bearbeitet Tickets in der folgenden Prioritätsreihenfolge:

• Ausfall von Diensten (Vorfälle werden automatisch von unserem Überwachungstool erstellt) - mit einem Wiederherstellungsziel von 30 Minuten
• Sicherheitsvorfälle
• S1-Vorfälle
• Tickets für SLA-Verstöße
• Alle anderen Tickets nach SLA geordnet

Hier ist der Arbeitsablauf für Vorfälle.

Arbeitsablauf

• Wenn das Ticket erstellt wird, erhält es den Status "Eingereicht".
• Sobald unser Team mit der Bearbeitung beginnt, wechselt das Ticket in den Status "In Bearbeitung".
• Wenn wir weitere Informationen von Ihnen benötigen, wird das Ticket in den Status "Warten auf den Kunden" versetzt, und es wird ein Kommentar zu dem Ticket hinzugefügt, in dem angegeben wird, welche Informationen wir zur Lösung des Problems benötigen.
• Wenn wir einen Dritten zur Lösung des Problems benötigen, wird das Ticket in den Status "Warten auf den Kunden" versetzt. Bei den Dritten kann es sich um Atlassian, einen Add-on-Anbieter oder einen Hosting-Anbieter handeln.
• Wenn Sie eine Antwort erhalten haben, geht das Ticket in den Status "Geschlossen" über. Es wird ein Kommentar hinzugefügt, in dem Sie alle erforderlichen Informationen finden.
• Wenn die Antwort Ihre Erwartungen nicht vollständig erfüllt, können Sie das Ticket erneut öffnen, wodurch das Problem in den Status "In Bearbeitung" übergeht.
• Wenn das Ticket einen geplanten Vorgang erfordert, um gelöst zu werden (z. B. Upgrade, geplanter Neustart), wechselt es in den Status "Vorgang geplant" und teilt Ihnen in einem Kommentar mit, wann der Vorgang stattfinden wird und wer dafür verantwortlich ist.
• Wenn das Ticket als Beratungsaufgabe identifiziert wird, wird es mit der Auflösung "Beratung" geschlossen.

SLA

• Die Antwort-SLA wird vom Status "Eingereicht" bis zum Status "Vorgang geplant", "Warten auf Kunde", "Gelöst" oder "Geschlossen" gemessen
• Response SLA zählt nur den ersten Treffer des Status "Operation geplant"/"Warten auf Kunde"/"Gelöst"/"Geschlossen" - das bedeutet, dass die SLA nicht neu startet, wenn ein Problem erneut geöffnet wird oder wieder den Status "In Bearbeitung" erhält.
• Das Antwort-SLA wird bei folgendem Status pausiert: "Warten auf Drittpartei".
• Antwort-SLA wird entsprechend der für den Supportvertrag gewählten Abdeckung gemessen: während der Geschäftszeiten für Kunden, die die Abdeckung der Geschäftszeiten gewählt haben, und 24/7 für Kunden, die die Abdeckung 24/7 gewählt haben.

Benachrichtigungen

• Nach der Erstellung eines Tickets erhält der Ersteller eine E-Mail-Benachrichtigung.
• Der Ersteller kann jederzeit auf diese Benachrichtigung antworten, um einen Kommentar zu der Anfrage hinzuzufügen.
• Der Ersteller erhält eine E-Mail-Benachrichtigung, sobald die Anfrage in den Status "In Bearbeitung" übergeht, was bedeutet, dass das Problem berücksichtigt wurde.
• Der Ersteller erhält eine E-Mail-Benachrichtigung, wenn die Anfrage den Status "Warten auf Kunden", "Warten auf Dritte" oder "Operation geplant" erhält.
• Unser Support-Team erhält eine Benachrichtigung, wenn das Problem vom Status "Warten auf Kunden" oder "Geschlossen" wieder geöffnet wird.
• Der Ersteller erhält eine E-Mail-Benachrichtigung, wenn das Ticket den Status "Geschlossen" erhält.
• Der Ersteller erhält jedes Mal eine E-Mail-Benachrichtigung, wenn das Ticket von unserem Support-Team kommentiert wird.

Automatisierungen

• Anfragen mit dem Status "Warten auf Kunden", die seit 3 und 6 Tagen nicht mehr geändert wurden, werden automatisch kommentiert, was eine Benachrichtigung an den Ersteller sendet.
• Tickets mit dem Status "Warten auf den Kunden", die 12 Tage lang nicht geändert wurden, werden automatisch geschlossen, können aber bei Bedarf wieder geöffnet werden.

Eskalation

• Zu jedem Zeitpunkt haben Sie die Möglichkeit, das Problem zu eskalieren. Bei der Eskalation des Problems wird eine Benachrichtigung an den Leiter des Support-Teams und den Leiter der Managed Services gesendet, damit diese das Ticket überprüfen und gegebenenfalls Maßnahmen ergreifen können.
• Wir empfehlen, diese Eskalationsschaltfläche zu verwenden, wenn
  • Sie nicht das erforderliche Maß an Fachwissen für die Bearbeitung eines Problems erhalten
  • Sie keine angemessene Antwortzeit erhalten, nachdem Sie dem Support-Mitarbeiter alle Informationen für die Bearbeitung Ihrer Anfrage zur Verfügung gestellt haben
• Wenn Sie ein sehr dringendes Problem haben, empfehlen wir Ihnen, uns direkt anzurufen, anstatt das Problem zu eskalieren (zur Erinnerung: Unsere Telefonnummern finden Sie hier:Support-Anfrage stellen)

Regelmäßige Überprüfung der Zugriffsrechte

Jeden Monat werden alle Anwendungen, die auf der Ebene der verwalteten Dienste genutzt werden, überprüft, um sicherzustellen, dass nur befugte Personen Zugang erhalten.

Es wird ein Bericht erstellt und an den Teamleiter der verwalteten Dienste weitergeleitet. Bei fehlerhaften Zugriffsrechten werden sofort Maßnahmen ergriffen, um das Problem zu beheben, indem gegebenenfalls ein Sicherheitsvorfall erzeugt wird.

Verwaltung von Sicherheitsvorfällen

Unser Prozess für Sicherheitsvorfälle wird durch unseren Plan zur Reaktion auf Vorfälle abgedeckt.

SCHRITT 1 - Entdeckung und Einstufung

Jeder, der den Vorfall entdeckt, kontaktiert das Valiantys-Supportteam, indem er einen Sicherheitsvorfall in der speziellen Jira Service Desk-Instanz erstellt:

• Name des Anrufers oder Quelle der Vorfallsmeldung (AWS- oder Software-Benachrichtigungen) - z. B.:E-Mail von Atlassian oder von einem Kunden im Valiantys-Supportportal erstelltes Ticket
• Zeitpunkt der ersten Meldung
• Art des Vorfalls - z. B.:Schwachstelle in einem Atlassian-Produkt
• Welche(s) System(e) oder Personen waren betroffen - z. B.:betroffene Atlassian-Anwendungen (d. h. von der Sicherheitslücke betroffene Versionen)
• Standort der betroffenen Geräte oder Personen - z. B.:Valiantys Cloud-Infrastruktur
• Wie wurde der Vorfall entdeckt - z. B. durchPen-Tests, die von einem Kunden für seine Anwendungen durchgeführt wurden

Alle Protokollinformationen des Servers müssen für zukünftige Untersuchungen in das Ticket kopiert werden.

SCHRITT 2 - Eskalation und Erkundung

Je nach Art des Sicherheitsvorfalls wird das erstellte Ticket dem Support oder dem Cloud Offerings Manager zugewiesen. Der designierte Zuweiser:

• Überprüft den Inhalt des Tickets
• Er bewertet die Liste der betroffenen Umgebungen. Diese Umgebungen müssen gesichert werden (es sei denn, es ist bereits ein aktuelles Backup verfügbar), um die Informationen für die Identifizierung, Sammlung, Erfassung und Aufbewahrung zu schützen, die als Beweismittel dienen können.
• Auf der Grundlage dieser Bewertung entscheidet der Beauftragte über die Art der anzuwendenden Abhilfemaßnahmen, damit der Vorfall so schnell und effizient wie möglich behoben wird. Je nach Fall wird die Art der Abhilfemaßnahmen sein:

• • Bereitstellung eines Workarounds, falls vorhanden
  • System- oder Anwendungs-Upgrade - z. B. OS, Apache, PostgreSQL, Atlassian-Tool oder -Anwendung
  • Migration auf eine neue Umgebung

Für jede vom Vorfall betroffene Umgebung und auf der Grundlage desChange Management-Prozesseswerden in dem entsprechenden Jira-Projekt Change Tickets mit den folgenden Informationen erstellt:

Change Management-Prozess

• Beschreibung - z.B.:Jira-Upgrade auf 8.5.3 auf der MyCustomer PROD-Instanz
• Priorität - z.B.:Kritisch
• Herkunft - z.B.:Benachrichtigung von Atlassian
• Grund für die Änderung - z. B.:Sicherheitslücke in der derzeit installierten Jira-Version
• Risikoanalyse - z. B:
  • Gleiche Parameter in den Konfigurationsdateien setenv.sh und server.xml
  • Kompatibilität der installierten Anwendungen - aktualisieren Sie die betroffenen Anwendungen, falls erforderlich
  • Apps, für die eine kostenpflichtige Lizenz erforderlich ist - der Kunde muss darüber informiert werden, ebenso wie der Kundenbetreuer
  • Kein unvorhergesehenes Sicherheitsrisiko, da die Daten nirgendwo übertragen werden

• Änderungsverfahren - z.B.:<Link_zur_entsprechenden_internen_Dokumentation>
• Rollback-Verfahren - z.B.:Wiederherstellung des vor der Operation erstellten Snapshots
• Geschätzte Dauer - z.B.: 1h
• Link zum zugehörigen Support-Ticket - wird automatisch von der Jira-App definiert, die das Änderungs-Ticket erstellt

Definition der Sicherheitslücke

Ein Sicherheitsverstoß ist definiert als unbefugte Aneignung von Daten, die die Sicherheit, Vertraulichkeit oder Integrität der von Valiantys verwalteten personenbezogenen Daten gefährdet.

Der gutgläubige Erwerb personenbezogener Daten durch einen Mitarbeiter oder Vertreter unseres Unternehmens zu Geschäftszwecken stellt keinen Verstoß dar, vorausgesetzt, die personenbezogenen Daten werden nicht verwendet oder einer weiteren unbefugten Offenlegung unterzogen.

Anrufer für Vorfallsalarm

Nachfolgend finden Sie einige Beispiele für Werte, die im Feld "Herkunft" des Änderungstickets angegeben werden müssen:

• Kunde
• Atlassian-Berater für einen Kunden
• Drittanbieter wie CVE-Datenbank
• Valiantys
• Atlassian
• Unbekannt

Art

Im Folgenden finden Sie einige Beispiele für Werte, die im FeldReason for Change des Change-Tickets angegeben werden können:

• Verletzung von persönlichen Informationen
• Denial of Service/Distributed Denial of Service
• Übermäßiger Port-Scan
• Firewall-Verletzung
• Ausbruch eines Virus
• Ausbeutung von Server-Ressourcen

Einstufung / Kritikalität

Nachfolgend finden Sie einige Beispiele für Werte, die im FeldPriorität des Änderungstickets angegeben werden sollten:

KRITISCH

• Definition: Vorfälle, die eine kritische Auswirkung auf das Geschäft des Unternehmens oder den Service für Valiantys MS-Kunden haben
• Beispiel: Unbefugter Systemzugriff

MITTEL

• Definition: Vorfälle, die erhebliche oder potenziell kritische Auswirkungen auf die Geschäftstätigkeit des Unternehmens oder die Dienstleistungen für die Kunden von Valiantys MS haben können.
• Beispiel: Versuch, ein Passwort zu knacken

NIEDRIG

• Definitionen: Vorfälle, die das Potenzial haben, erhebliche oder kritische Auswirkungen auf die Geschäftstätigkeit des Unternehmens oder den Service für die Kunden von Valiantys MS zu haben.
• Beispiel: Firewall-Scan

SCHRITT 3 - Abhilfemaßnahmen

Jedes betroffene System wird vor der Anwendung der Abhilfemaßnahmen auf die offene Schwachstelle gescannt.

Der Sicherheitsvorfall wird durch die Anwendung des Änderungsverfahrens behoben, das in einem speziellen Feld des Änderungstickets angegeben wird.

Nach der Validierung der Abhilfemaßnahme werden die betroffenen Systeme erneut gescannt, um zu überprüfen, ob die Schwachstelle beseitigt wurde.

SCHRITT 4 - Kommunikation

• Valiantys MS verpflichtet sich, Kunden oder Partner, die von dem Sicherheitsproblem betroffen sein könnten, innerhalb von maximal 24 Stunden korrekt zu informieren, indem es eine E-Mail an alle betroffenen Kunden schickt (oder ein Support-Ticket im Namen des Kunden erstellt), die folgende Informationen enthält:
  • Details der Sicherheitslücke (CVE-Nummer, falls vorhanden)
  • Wie sich die Schwachstelle auf ihre Umgebung auswirkt
  • Beschreibung des Plans zur Behebung der Schwachstelle
  • Beschreibung des Kommunikationsplans
  • Details der Untersuchung, falls die Schwachstelle bereits ausgenutzt wurde
• Valiantys Managed Services Management muss so früh wie möglich ab der Eskalationsstufe und je nach Schwere und Umfang der betroffenen Umgebungen in den Prozess einbezogen werden:
  • Valiantys Head of Managed Services muss bei jedem Sicherheitsvorfall von kritischer Bedeutung einbezogen werden.
  • Valiantys CTO muss involviert werden, wenn der Umfang des Sicherheitsvorfalls Valiantys Cloud-Infrastruktur betrifft und der Schweregrad kritisch ist.
  • Valiantys CISO muss involviert werden, wenn der Sicherheitsvorfall die Infrastruktur von Valiantys betrifft und als kritisch eingestuft wird.
  • Valiantys CEO muss involviert werden, wenn der Sicherheitsvorfall Valiantys in rechtlicher oder finanzieller Hinsicht belastet und die Kritikalität kritisch ist.

SCHRITT 5 - Post-Mortem-Überprüfung der Reaktion und Aktualisierung der Richtlinien

Um präventive Maßnahmen zu ergreifen, damit sich der Vorfall nicht wiederholt, haben wir uns mehrere Fragen gestellt:

• Hätte eine zusätzliche Richtlinie den Vorfall verhindern können?
• Wurde ein Verfahren oder eine Richtlinie nicht befolgt, wodurch der Vorfall möglich wurde? Was könnte geändert werden, um sicherzustellen, dass das Verfahren oder die Richtlinie in Zukunft befolgt wird?
• War die Reaktion auf den Vorfall angemessen? Wie könnte sie verbessert werden?
• Wurden alle zuständigen Stellen rechtzeitig informiert?
• Waren die Verfahren zur Reaktion auf einen Zwischenfall detailliert und deckten sie die gesamte Situation ab? Wie können sie verbessert werden?
• Wurden Änderungen vorgenommen, um einen weiteren Vorfall zu verhindern? Wurden alle Systeme gepatcht, gesperrt, Passwörter geändert, der Virenschutz aktualisiert, E-Mail-Richtlinien festgelegt usw.?
• Sollten die Sicherheitsrichtlinien aktualisiert werden?
• Welche Lehren wurden aus dieser Erfahrung gezogen?

Diese Diskussion kann im wöchentlichenÄnderungsausschussstattfinden, an dem mindestens der Leiter der verwalteten Dienste, die Leiter der Support- und Cloud-Angebote und die Leiter der Support-Teams teilnehmen.

Regelmäßige Tests

Valiantys Managed Services Team ist dafür verantwortlich, den Security Incident Response Plan vierteljährlich in den folgenden Zeiträumen zu testen und zu überprüfen:

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

Wiederherstellung nach Katastrophen

Alle unsere virtuellen Server (mit Ausnahme der Valiantys Cloud Starter Angebote) werden jede Nacht gesichert. Die Sicherungskopie wird in der gleichen Region wie die Server gespeichert. Für Disaster-Recovery-Zwecke werden alle Snapshots automatisch in eine andere Region kopiert.

Im Falle eines wichtigen Ausfalls in der Hauptregion können wir den Dienst sehr schnell mit dem letzten Backup neu starten und so die Auswirkungen auf die Kunden so gering wie möglich halten:

Unsere Zielvorgaben für die Wiederherstellungszeit und den Wiederherstellungspunkt sind unter https://valiantys.com/en/legal/sla/ verfügbar.

Wir testen diesen Prozess einmal im Jahr auf allen unseren Servern, um im Ernstfall bereit und effizient zu sein.

Restauration de l'export XML :

• Wir kopieren den XML-Export in das Restaurierungsdossier
• Wir führen den XML-Importprozess durch (kann je nach der Größe Ihrer Umgebung einige Minuten bis einige Stunden dauern)

Überprüfung des Wiederherstellungsvorgangs

Um sicherzustellen, dass unsere Sicherheitsvorkehrungen und -verfahren wie vorgesehen funktionieren, führen wir einmal pro Jahr einen Wiederherstellungstest für alle unsere Kunden durch.

Ein Bericht über die Ergebnisse kann dem Kunden auf Anfrage zur Verfügung gestellt werden.

Pen-Tests

Wir führen mindestens einmal pro Jahr Penetrationstests bei allen unseren Servern durch.

Mindestens einmal pro Jahr führen wir Durchdringungstests in einer Umgebung des Typs "bac à sable" durch, die wir mit Hilfe des Standard-Installationsprozesses, den wir für die Erstellung der Kundenumgebung verwenden, erstellen. Dies ermöglicht es uns, unsere Sicherheit kontinuierlich zu verbessern.

Wir ermöglichen es unseren Kunden auch, ihre eigenen Sicherheitstests durchzuführen (selbst oder mit Hilfe einer anderen Person).

Si un client souhaite organiser des tests de pénétration, il doit nous contacter au moins 4 semaines à l'avance, car nous devons obtenir l'approbation de nos fournisseurs.

Verwaltung der Vulnérabilité

Prozess der Erkennung

Wir führen eine tägliche Überprüfung unserer Referenzdatenbank mit Hilfe von Spezialwerkzeugen und den von Atlassian bereitgestellten Warnmeldungen durch.

Erkennungszeitpunkt

Die Erkennungszeit beträgt 7 Tage (außer bei Benachrichtigung durch Atlassian während dieser Zeit).

Dauer der Bearbeitung

Die Behebung erfolgt sofort. Sobald die Schwachstelle bekannt ist, wird automatisch ein Vorfallsticket im Namen des Kunden erstellt, um die Behebung im Einvernehmen mit dem Kunden zu organisieren und den Produktionsdienst so wenig wie möglich zu beeinträchtigen.

Reagiert der Kunde nicht innerhalb von 7 Tagen, wird die Störung automatisch behandelt, ohne dass eine Vereinbarung über die nicht bearbeiteten Geräte getroffen wird.

Operationen

Organisation der Gefahrenabwehr

Die für die Sicherheit im Unternehmen verantwortliche Person ist derzeit Nathan Chantrenne, CTO.

Wir haben kein eigenes Sicherheitsteam. Alle Mitglieder unseres Informationsteams kennen die bei Valiantys geltenden Sicherheitsrichtlinien und sind in der Lage, Sicherheitsvorfälle zu bewältigen.

Es gibt eine Unternehmenssicherheitspolitik, die Teil der Unternehmensrichtlinien und -vorschriften ist, die von allen Valiantys-Mitgliedern akzeptiert werden müssen. Sie umfasst die folgenden Abschnitte:

Organisation der Politik der Informationssicherheit

• EINLEITUNG
  • Zielsetzung
  • Anwendungsbereich
  • Geschichte
  • Zuständigkeiten
  • Definition der allgemeinen Politik
  • Glossar
• Politik des Netzzugangs
  • Zielsetzung der Netzzugangspolitik
  • Anwendungsbereich
  • Definition der Politik Politik
• Politik der Datenübermittlung, D'INFORMATIONS ET DE SÉCURITÉ
  • Allgemeine Nutzung und Eigentum
  • Sicherheit und exklusive Informationen
  • Unzulässige Nutzung
• CONFORMITÉ DE LA POLITIQUE
  • Konformitätsnachweis
  • Ausnahmen
  • NichtKonformität
• POLITIQUE EN MATIÈRE D'ACTIFS INFORMATIQUES
  • Objet de la politique
  • Champ d'application
  • Définition de la politique
• POLITIQUE DE CONTRÔLE D'ACCÈS
  • Objectif
  • Champ d'application
  • Définition de la politique
• POLITIQUE DE CONTRÔLE DES MOTS DE PASSE
  • Objectif
  • Champ
• • d'application
  • Définition de la politique
  • Énoncé des lignes directrices
• POLITIQUE EN MATIÈRE DE COURRIEL
  • Objectif
  • Champ d'application
  • Définition de la politique
• POLITIQUE INTERNET
  • Objectif
  • Champ d'application
  • Définition de la politique
• POLITIQUE ANTIVIRUS
  • Objectif
  • Champ d'application
  • Begriffsbestimmung der Politik
• POLITIK DER KLASSIFIZIERUNG VON INFORMATIONEN
  • Zielsetzung
  • Champ d'application
  • Begriffsbestimmung der Politik
• POLITIK DES FERNZUGANGS
  • Zielsetzung
  • Anwendungsbereich
  • Begriffsbestimmung der Politik
• POLITIK DER EXTERNALISIERUNG
  • Zielsetzung
  • Champ d'application
  • Begriffsbestimmung der Politik
  • Obligatorisch
• POLITIK DER VERWALTUNG DER KORREKTURGÜTER
  • Zielsetzung der Ordnungspolitik
  • Anwendungsbereich
  • Begriffsbestimmung der Politik
• INFORMATIONSPOLITIK IN BEZUG AUF DIE NUKLEAREN ANWENDUNGEN
  • Zielsetzung
  • Champ d'application
  • Begriffsbestimmung der Politik

Bevor wir neue Mitarbeiter einstellen, überprüfen wir ihre Vorgeschichte in Abhängigkeit von dem Land, in dem sie eingestellt wurden:

• Eine Basiserklärung zur Schuldfähigkeit
• Analyse des beruflichen Werdegangs und der Lücken
• Überprüfung des Personalausweises
• Überprüfung des Rechts auf Arbeit

Prozess der Bewältigung von Veränderungen

Einreichung von Änderungen

Wenn im Rahmen eines Betreuungsscheins ein Wechsel von einem Klienten verlangt oder von der Betreuungsperson festgestellt wird, kann durch einen Übergang des Arbeitsflusses ein bestimmter Status erreicht werden. Ausgehend von diesem Status ist es möglich, im Jira-Projekt über eine bestimmte Schaltfläche einen Änderungsbogen zu erstellen. Die erstellte Änderungsübersicht enthält die folgenden Informationen

• Beschreibung - z.B.:Jira uprgade auf 8.5.3 auf MyCustomer PROD Instanz
• Priorität - zum Beispiel:Kritik
• Herkunft - z.B.:Benachrichtigung von Atlassian
• Grund der Änderung - z.B.: Sicherheitslücke in der aktuell installierten Jira-Version
• Risikoanalyse - z.B. :
  • Gleiche Parameter in den Konfigurationsdateien setenv.sh und server.xml
  • Kompatibilität der installierten Anwendungen - ggf. die betreffenden Anwendungen auf den neuesten Stand bringen
  • Anwendungen, für die eine kostenpflichtige Lizenz erforderlich ist - der Kunde muss darüber informiert werden, ebenso wie der Computerverwalter
  • Kein Sicherheitsrisiko im Voraus, da die Daten nicht übertragen werden.

• Änderungsverfahren - ex:<link_zu_der_entsprechenden_internen_Dokumentation> (Link zur entsprechenden internen Dokumentation)
• Verfahren für die Rückkehr zum Ausgangspunkt - z. B.: Wiederherstellung des vor der Operation erzeugten Stroms
• Geschätzte Dauer - z.B.: 1h
• Link zum entsprechenden Support-Ticket - wird automatisch von der Jira-Anwendung, die das Änderungsticket erstellt, erstellt

Freigabe der Änderung

Nach der Erstellung und je nach Art der Änderung wird das Änderungsformular an einen Supportleiter oder einen Cloud-Architekten weitergeleitet. Der ernannte Beauftragte prüft die vom Berichterstatter vorgelegten Informationen und entscheidet, ob er den Änderungsantrag genehmigt oder ablehnt.

Es gibt verschiedene Gründe, eine Änderung abzulehnen: technisches Risiko, Sicherheitsrisiko, unklare oder unvollständige Verfahren usw. Wenn die Änderung abgelehnt wird, wird das Änderungsformular gesperrt und der Arbeitsfluss des zugehörigen Supportformulars automatisch auf den vorherigen Stand gebracht.

Wenn die Änderung genehmigt wurde, kann der entsprechende Vorgang über die folgenden Felder geplant werden:

• Anfangsdatum - d.h. das Datum und die Uhrzeit, zu denen der Änderungsvorgang beginnt.
• Date de fin - c'est-à-dire la date et l'heure auxquelles l'opération de changement prendra fin.
• Bestimmungsort - das ist die für die Durchführung des Vorgangs zuständige Stelle.

Infolgedessen wird das Änderungsticket mit diesen Informationen aktualisiert, und der Arbeitsfluss des zugehörigen Support-Tickets wird automatisch in einen neuen Status versetzt, der anzeigt, dass eine Korrekturmaßnahme geplant ist.

Anwendung der Änderung

Nach der Anwendung der Änderung setzt die für die Operation verantwortliche Ressource den Status des Arbeitsflusses des Änderungstickets auf den neuesten Stand, wodurch automatisch eine Anpassung des Arbeitsflusses des zugehörigen Unterstützungstickets erfolgt, so dass die Bearbeitung des Tickets wieder aufgenommen wird.

Änderung der Dringlichkeit

Bei dringenden Problemen - z. B. einem von einem Kunden gemeldeten Blockadeproblem oder einer von Atlassian gemeldeten Sicherheitslücke, die sich auf bestimmte Anwendungsversionen auswirkt - wird ein Dringlichkeitsänderungsprozess angewandt, der im Vergleich zum regulären Prozess die folgenden Änderungen vorsieht:

• Ein Support-Chef oder ein Cloud-Architekt bearbeitet das entsprechende Support-Ticket, erstellt und genehmigt das entsprechende Änderungs-Ticket.
• Die Änderung wird innerhalb der größtmöglichen Zeitspanne geplant, je nach Verfügbarkeit der Support-Ressourcen und der Zustimmung des Kunden.

Änderungskomitee

Jeden Mittag überprüft ein 30-minütigesÄnderungskomitee, dem mindestens der Verantwortliche für die Informationsdienste, die Verantwortlichen für die Support- und Cloud-Dienste sowie die Leiter der Support-Teams angehören, die im Laufe des Zeitraums bearbeiteten Änderungstickets anhand eines speziellen Jira-Bordbuchs.

Prozess der Verwaltung von Vorfällen

Die Vorfälle werden von den Kunden per E-Mail, von unserem Support-Portfolio oder vom Team von Valiantys Managed Services gemeldet.

Ein Vorfall kann als Vorfall der Schwere 1, 2, 3 oder 4 eingestuft werden. Die Definition unserer Schweregrade kann unter https://valiantys.com/en/legal/sla/ eingesehen werden.

Notre équipe Managed Services behandelt die Tickets in der folgenden Prioritätsreihenfolge:

• Service-Ausfall (die Vorfälle werden automatisch durch unser Überwachungssystem erzeugt) - mit einer angestrebten Wiederherstellungszeit von 30 Minuten
• Störfälle der Sicherheit
• Vorfälle S1
• Tickets wegen Nichteinhaltung der Vereinbarung über das Serviceniveau
• Alle anderen Tickets, die nach SLA klassifiziert sind

Voici le workflow des incidents.

Fluss der Arbeit

• Wenn ein Ticket erstellt wird, erhält es den Status "Bearbeitet".
• Sobald unser Team mit der Arbeit beginnt, geht das Ticket in den Status "In Bearbeitung" über.
• Wenn wir mehr Informationen von Ihnen benötigen, wird das Ticket mit dem Status "En attente du client" versehen, und ein Kommentar wird auf dem Ticket vermerkt, der die Informationen enthält, die wir zur Lösung des Problems benötigen.
• Wenn wir zur Lösung des Problems die Hilfe eines Ansprechpartners benötigen, wird das Ticket mit dem Status "En attente d'un client" versehen. Bei den Ansprechpartnern kann es sich um Atlassian, einen Anbieter von Zusatzmodulen oder einen Berater handeln.
• Wenn wir eine Antwort geben, geht das Ticket in den Status "Fermé" über. Un commentaire est ajouté pour vous fournir toutes les informations nécessaires.
• Wenn die Antwort nicht vollständig auf Ihre Wünsche eingeht, haben Sie die Möglichkeit, die Anfrage neu zu formulieren, wodurch das Problem in den Status "in Bearbeitung" übergeht.
• Wenn das Ticket eine geplante Operation benötigt, um gelöst zu werden (z.B. eine Niveausteigerung, eine geplante Umstellung), erhält es den Status "Geplante Operation", wobei Sie in einem Kommentar angeben müssen, wann die Operation stattfindet und wer dafür verantwortlich ist.
• Wenn das Ticket als Beratungsaufgabe identifiziert wird, wird es mit dem Vermerk "Beratung" abgeschlossen.

SLA

• L'ANS de réponse est mesuré à partir du statut "Soumis" jusqu'au statut "Opération planifiée", "En attente du client", "Résolu" ou "Fermé".
• L'ANS de réponse ne compte que la première occurrence du statut "Opération planifiée"/"En attente du client"/"Résolu"/"Clôturé" - cela signifie que si un problème est rouvert ou revient au statut "En cours", l'ANS ne redémarre pas.
• L'ANS de réponse est mis en pause avec le statut suivant : "En attente d'un tiers".
• L'ANS de réponse est mesure en fonction de la couverture sélectionnée pour le contrat d'assistance : pendant les heures ouvrables pour les clients qui ont choisé la couverture des heures ouvrables et 24 heures sur 24, 7 jours sur 7 pour les clients qui ont choisé la couverture 24 heures sur 24, 7 jours sur 7.

Benachrichtigungen

• Nach der Erstellung eines Tickets erhält der Ersteller eine Benachrichtigung per E-Mail.
• Der Ersteller kann jederzeit auf diese Benachrichtigung antworten, um einen Kommentar zum Ticket abzugeben.
• Der Ersteller erhält eine Benachrichtigung per E-Mail, sobald das Ticket den Status "In Bearbeitung" erreicht hat, was bedeutet, dass das Problem berücksichtigt wurde.
• Der Ersteller erhält eine Benachrichtigung per E-Mail, wenn das Ticket den Status "En attente du client", "En attente d'un tiers" oder "Opération planifiée" hat.
• Notre équipe d'assistance reçoit une notification lorsque le problème est rouvert depuis le statut "En attente du client" ou "Fermé".
• Der Verursacher erhält eine Benachrichtigung per E-Mail, wenn das Ticket den Status "Fermé" erreicht hat.
• Der Ersteller erhält eine E-Mail-Benachrichtigung, sobald das Ticket von unserem Support-Team kommentiert wurde.

Automatisierungen

• Tickets, die den Status "In Bearbeitung" haben und seit 3 und 6 Tagen nicht mehr geändert wurden, werden automatisch kommentiert, worüber der Ersteller eine Benachrichtigung erhält.
• Tickets mit dem Status "En attente d'un client", die seit 12 Stunden nicht mehr geändert wurden, werden automatisch gesperrt, können aber bei Bedarf wiederhergestellt werden.

Escalade

• Zu jedem Zeitpunkt haben Sie die Möglichkeit, das Problem zu eskalieren. Die Eskalation des Problems führt zu einer Benachrichtigung des Leiters des Hilfsteams und des Verantwortlichen für den Dienst, damit diese das Ticket prüfen und gegebenenfalls Maßnahmen ergreifen können.
• Wir empfehlen Ihnen, diese Eskalationstaste zu benutzen, wenn
  • Vous n'obtenez pas le niveau d'expertise requis pour traiter un problème.
  • Sie nicht die erforderliche Antwortzeit erhalten haben, nachdem Sie alle notwendigen Informationen an den Support-Mitarbeiter weitergegeben haben, um Ihr Ticket zu bearbeiten.
• Wenn Sie ein sehr dringendes Problem haben, empfehlen wir Ihnen, sich direkt an uns zu wenden, anstatt das Problem zu eskalieren (siehe unsere Telefonnummern unter: Soumettre une demande d'assistance).

Périodische Überprüfung der Zugangsrechte

Jeden Monat werden alle Anwendungen, die auf der Ebene der bereitgestellten Dienste genutzt werden, überprüft, um sicherzustellen, dass der Zugang nur dem autorisierten Personal gewährt wird.

Es wird ein Bericht erstellt und mit dem Verantwortlichen der Informationsabteilung ausgetauscht. Im Falle einer Verletzung von Zugangsrechten wird sofort gehandelt, um das Problem zu lösen und gegebenenfalls einen Sicherheitsvorfall zu verursachen.

Verwaltung von Sicherheitsvorfällen

Unser Prozess zur Bewältigung von Sicherheitsvorfällen wird durch unseren Plan zur Reaktion auf Vorfälle abgedeckt.

ÉTAPE 1 - Entdeckung und Einstufung

Jede Person, die einen Vorfall entdeckt, wendet sich an die Supportabteilung von Valiantys, indem sie einen Sicherheitsvorfall in der für sie zuständigen Jira Service Desk-Instanz einträgt:

• Name des Antragstellers oder Quelle der Störungsmeldung (AWS oder logische Benachrichtigungen) - z.B.: E-Mail von Atlassian oder Ticket, das von einem Kunden im Support-Portal von Valiantys erstellt wurde
• Zeit des ersten Berichts
• Art des Vorfalls - z. B.: Sicherheitslücke in einem Atlassian-Produkt
• Quel(s) système(s) ou personne(s) est/sont impliqué(s) - ex:applications Atlassian impactées (i.e. versions affectées par la vulnérabilité)
• Standort des Geräts oder der betroffenen Personen - z. B.die Cloud-Infrastruktur von Valiantys
• Comment l'incident a été détecté - ex:Pen tests exécutés par un client sur ses applications

Alle Informationen aus den Protokollen des Servers müssen in das Ticket kopiert werden, um eine spätere Untersuchung zu ermöglichen.

ÉTAPE 2 - Escalade und Erkundung

Je nach Art des Sicherheitsvorfalls wird das erstellte Ticket dem Support oder dem Cloud Offerings Manager zugewiesen. La personne désignée :

• Untersucht den Inhalt des Tickets
• Ermitteln Sie die Liste der betroffenen Umgebungen. Diese Umgebungen müssen abgesichert werden (auch wenn eine aktuelle Absicherung noch nicht verfügbar ist), um die Informationen für die Identifizierung, Erfassung, Erfassung und Aufbewahrung zu schützen, die als Beweismittel dienen können.
• Auf der Grundlage dieser Bewertung entscheidet der Beauftragte über die Art der Abhilfemaßnahmen, die er anwendet, um den Vorfall so schnell und effizient wie möglich zu beheben. Je nach Fall ist die Art des Einsatzes die folgende

• • Einsatz einer Kontaminationslösung, je nach Fall
  • Anpassung des Systems oder der Anwendung - z. B. OS, Apache, PostgreSQL, Gerät oder Anwendung Atlassian
  • Migration auf eine neue Umgebung

Für jede von einem Vorfall betroffene Umgebung und in Abhängigkeit vom Prozess derÄnderungsabwicklung werden in dem entsprechenden Jira-Projekt Änderungstickets mit den folgenden Informationen erstellt:

Prozess der Änderungsverwaltung

• Beschreibung - z.B.:Jira Uprgade auf 8.5.3 auf MyCustomer PROD Instanz
• Priorität - zum Beispiel:Kritik
• Ursprung - z.B.:Benachrichtigung von Atlassian
• Grund der Änderung - z.B.: Sicherheitslücke in der aktuell installierten Jira-Version
• Risikoanalyse - z.B. :
  • Gleiche Parameter in den Konfigurationsdateien setenv.sh und server.xml
  • Kompatibilität der installierten Anwendungen - ggf. die betreffenden Anwendungen auf den neuesten Stand bringen
  • Anwendungen, für die eine kostenpflichtige Lizenz erforderlich ist - der Kunde muss darüber informiert werden, ebenso wie der Computerverwalter
  • Kein Sicherheitsrisiko im Voraus, da die Daten nicht übertragen werden.

• Änderungsverfahren - ex:<link_zu_der_entsprechenden_internen_Dokumentation> (Link zur entsprechenden internen Dokumentation)
• Verfahren für die Rückkehr zum Ausgangspunkt - z. B.: Wiederherstellung des vor der Operation erzeugten Stroms
• Geschätzte Dauer - z.B.: 1h
• Link zum entsprechenden Support-Ticket - wird automatisch von der Jira-Anwendung, die das Änderungsticket erstellt, definiert

Definition einer Sicherheitsstörung

Eine Sicherheitsverletzung ist definiert als die nicht autorisierte Erfassung von Daten, die die Sicherheit, die Vertraulichkeit oder die Integrität der von Valiantys aufbewahrten personenbezogenen Daten gefährden.

Die Erlangung personenbezogener Informationen durch einen Mitarbeiter oder einen Beauftragten unserer Gesellschaft zu beruflichen Zwecken stellt keinen Verstoß dar, vorausgesetzt, dass diese Informationen nicht verwendet werden oder Gegenstand einer nicht autorisierten Weitergabe sind.

Appel d'alerte en cas d'incident

Voici quelques exemples de valeurs à indiquer dans le champOrigine du ticket de changement :

• Kunde
• Atlassian-Berater für einen Kunden
• Tierce partie telle que la base de données CVE
• Valiantys
• Atlassian
• Inconnu

Natur

Voici quelques exemples de valeurs à indiquer dans le champMotifdu changement du ticket de changement :

• Verletzung von persönlichen Informationen
• Déni de service/déni de service distribué
• Balayage excessif de ports
• Verstoß gegen das Datenschutzgesetz
• Einschleusen eines Virus
• Ausbeutung der Ressourcen des Betreibers

Klassifizierung/Kritik

Voici quelques exemples de valeurs à indiquer dans le champPriorité du ticket de changement :

CRITIQUE

• Définition : Vorfälle mit kritischen Auswirkungen auf die Unternehmenstätigkeit oder den Kundenservice von Valiantys MS.
• Beispiel : Nicht autorisierter Zugriff auf das System

MOYEN

• Definition : Vorfälle, die eine signifikante Auswirkung auf die Unternehmenstätigkeit oder den Kundendienst der Valiantys EM haben oder haben könnten.
• Exemple : Tentative de piratage de mot de passe

FAIBLE

• Définitions : Vorfälle, die eine signifikante oder kritische Auswirkung auf die Unternehmensaktivitäten oder die den Kunden von Valiantys MS angebotenen Dienstleistungen haben können.
• Exemple : Analyse du pare-feu

ÉTAPE 3 - Abhilfe

Jedes betroffene System wird gescannt, um offene Schwachstellen zu erkennen, bevor die Entstörung durchgeführt wird.

Der Sicherheitsvorfall wird durch die Anwendung des Änderungsverfahrens behoben, das in einem speziellen Bereich des Änderungstickets angegeben ist.

Nach der Validierung der Korrekturmaßnahme werden die betroffenen Systeme erneut analysiert, um zu überprüfen, ob die Gefährdung beseitigt wurde.

ÉTAPE 4 - Kommunikation

• Valiantys MS verpflichtet sich, eine korrekte Kommunikation mit den Kunden oder Partnern, die von dem Sicherheitsproblem betroffen sein könnten, innerhalb einer Frist von maximal 24 Stunden sicherzustellen, indem es eine E-Mail (oder ein Support-Ticket im Namen des Kunden) an alle betroffenen Kunden schickt, die die folgenden Informationen enthält:
  • Inhalt der Sicherheitslücke (CVE-Nummer, sofern vorhanden)
  • Auswirkungen der Anfälligkeit auf die Umgebung
  • Beschreibung des Plans zur Beseitigung der Schwachstelle
  • Beschreibung des Kommunikationsplans
  • Einzelheiten der Untersuchung, wenn die Sicherheitslücke bereits ausgenutzt wurde
• Die Informationsdirektion von Valiantys muss so schnell wie möglich in den Prozess eingebunden werden, und zwar ab der Eskalationsstufe und je nach Schwere und Dauer der betroffenen Umgebungen:
  • Der Verantwortliche für die Informationsdienste von Valiantys muss für alle kritischen Sicherheitsvorfälle verantwortlich sein.
  • Le CTO de Valiantys doit être impliqué si l'incident de sécurité concerne l'infrastructure Cloud de Valiantys et que la critique est critique.
  • Le CISO de Valiantys doit être impliqué si l'incident de sécurité concerne l'infrastructure de Valiantys et que la critique est critique.
  • Der CEO von Valiantys muss involviert sein, wenn der Sicherheitsvorfall Valiantys in rechtlicher oder finanzieller Hinsicht betrifft und wenn die Kritik kritisch ist.

ÉTAPE 5 - Examen post-mortem de la réponse et mise à jour des politiques

Um vorbeugende Maßnahmen ergreifen zu können, damit sich der Vorfall nicht wiederholt, haben wir uns mehrere Fragen gestellt:

• Könnte eine zusätzliche Politik den Vorfall verhindern?
• Hat die Nichtbeachtung eines Verfahrens oder einer Politik den Vorfall ermöglicht? Was könnte man ändern, damit das Verfahren oder die Politik in Zukunft eingehalten werden?
• War die Reaktion auf den Vorfall angemessen? Wie könnte sie verbessert werden?
• Wurden alle betroffenen Parteien rechtzeitig informiert?
• Sind die Verfahren zur Reaktion auf den Vorfall ausreichend und decken sie die gesamte Situation ab? Wie können sie verbessert werden?
• Welche Änderungen müssen vorgenommen werden, um einen neuen Zwischenfall zu verhindern? Wurden alle Systeme berichtigt oder gelöscht, die Passwörter geändert, das Virenschutzprogramm auf den neuesten Stand gebracht, die Richtlinien für den elektronischen Postverkehr festgelegt usw.?
• Müssen die Sicherheitspolitiken auf dem Laufenden gehalten werden?
• Welche Lehren wurden aus diesen Erfahrungen gezogen?

Diese Diskussion sollte in einer Gruppe von Mitarbeitern geführt werden,diemindestens den Verantwortlichen für die Informationsdienste, die Verantwortlichen für die Support- und Cloud-Angebote sowie die Leiter der Support-Teams umfasst.

Zeitlich begrenzte Tests

Das Infoteam von Valiantys ist dafür verantwortlich, den Reaktionsplan auf Sicherheitsvorfälle in den folgenden Zeiträumen zu testen und zu überarbeiten:

• mi-mars
• mi-juin
• mi-septembre
• mi-décembre

Reprise après sinistre

Alle unsere virtuellen Server (mit Ausnahme der Angebote von Valiantys Cloud Starter) werden jeden Abend gewartet. Die Sicherung wird in der gleichen Region wie die Server gelagert. Für die Wiederherstellung nach einem Neustart werden alle Snapshots automatisch in eine andere Region kopiert.

Bei einer größeren Störung in der Hauptregion sind wir in der Lage, den Dienst nach der letzten Überholung sehr schnell wiederherzustellen und die Auswirkungen auf die Kunden so gering wie möglich zu halten:

Unser Ziel für die Wiederherstellungszeit und unsere Ziele für die Wiederherstellungspunkte sind unter der Adresse https://valiantys.com/en/legal/sla/ abrufbar.

Wir testen diesen Prozess ein Mal pro Jahr bei unseren Kunden, um im nächsten Moment bereit und effizient zu sein.