Nach russischem Recht wird jedes Unternehmen, das mit den personenbezogenen Daten seiner Nutzer in Russland arbeitet, zum Betreiber personenbezogener Daten, ob es dies will oder nicht. Daraus ergeben sich eine Reihe formaler und prozessualer Pflichten, die nicht jedes Unternehmen alleine tragen kann oder will.
Wie die Praxis zeigt, ist es völlig richtig, dass er das nicht möchte, denn dieses Wissensgebiet ist noch so neu und nicht in der Praxis erprobt, dass selbst für Profis Schwierigkeiten und Fragen auftauchen. Heute werden wir darüber sprechen, wie wir ein Projekt zur Speicherung personenbezogener Daten für unseren Kunden umgesetzt haben und auf welche nicht offensichtlichen Schwierigkeiten wir gestoßen sind.
Wie wir dazu beigetragen haben, Daten gemäß 152-FZ zu schützen
Anfang 2019 wurden wir von Smart-Service LLC, einem Entwickler einer Plattform für Service Management, kontaktiert und Kontaktfreigabeanwendungen .
Mit der ersten Lösung können Sie den Prozess der Gerätewartung in verschiedenen Bereichen automatisieren – von der Aufstellung von Kaffeemaschinen und Klimaanlagen in Büroräumen bis hin zur Reparatur von Gasturbinen. Der zweite ist ein Online-Designer zur Erstellung elektronischer Visitenkarten auf Basis von QR-Codes.
Online-Visitenkarte myQRcards.
Beide Systeme speichern und verarbeiten Nutzerdaten, die gemäß 152-FZ unter die Einstufung „persönlich“ fallen. In diesem Fall schreibt das Gesetz eine Reihe von Beschränkungen für Speichersysteme für solche personenbezogenen Daten vor, um das erforderliche Maß an Sicherheit zu gewährleisten und das Risiko eines unbefugten Zugriffs zum Zweck von Diebstahl oder Missbrauch auszuschließen.
Das Gesetz muss beachtet werden, Smart Service hatte jedoch nicht vor, die Kompetenz zum Schutz personenbezogener Daten in sich selbst zu entwickeln. Daher wurden die von ihren Benutzern gemeinsam genutzten Dienste und Daten nach Linxdatacenter „verlagert“. „Smart-Service“ übertrug die Serverkapazität der Arbeitsumgebung in eine separate geschützte Netzwerkzone unseres Rechenzentrums, zertifiziert nach den Anforderungen der 152-FZ – die sogenannte „Secure Cloud“.
Wie ist eine sichere Cloud konzipiert?
Jedes Informationssystem, das personenbezogene Daten verarbeitet, muss drei grundlegende Anforderungen erfüllen:
- Der Zugriff auf Datenspeicher- und -verarbeitungsserver muss über einen VPN-Kanal mit Verschlüsselung gemäß GOST erfolgen.
- Datenspeicher- und -verarbeitungsserver müssen durch einen Virenschutz ständig auf Schwachstellen überwacht werden;
- Das Speichersystem muss sich in isolierten Netzwerken befinden.
Wir platzieren die Serverkapazitäten des Kunden in separaten Bereichen, die den Anforderungen von 152-FZ entsprechen und helfen, eine Aussage über die Einhaltung zu treffen.
Architektur einer sicheren virtuellen Infrastruktur für Smart Service LLC.
Verlauf der Arbeit
Die erste Genehmigung der Arbeiten erfolgte im Juni 2019, was als Starttermin des Projekts gelten kann. Alle Arbeiten müssen in einer „Live“-Umgebung mit Tausenden von Anfragen pro Tag erledigt werden. Selbstverständlich musste das Projekt abgeschlossen werden, ohne den normalen Betrieb beider Systeme zu unterbrechen.
Daher wurde ein klarer Aktionsplan erstellt und vereinbart, der in vier Phasen unterteilt ist:
- Vorbereitung,
- Migration,
- Testen und Testen unter realen Bedingungen,
- Ermöglichung von Überwachungssystemen und Zugangsbeschränkungen.
Zur Sicherheit haben wir ein Disaster Recovery Procedure (DRP) integriert. Nach dem ursprünglichen Plan erforderten die Arbeiten nicht viel Zeit und Ressourcen und sollten im Juli 2019 abgeschlossen sein. Jede Phase beinhaltete am Ende einen vollständigen Test der Netzwerkverfügbarkeit und Funktionalität der Systeme.
Die schwierigste Phase, in der „etwas schief gehen könnte“, war die Migration. Ursprünglich hatten wir geplant, die Migration durch die Übertragung ganzer virtueller Maschinen durchzuführen. Dies war die logischste Option, da keine zusätzlichen Ressourcen für die Neukonfiguration erforderlich waren. Es scheint, dass vMotion einfacher sein könnte.
Unerwartet
Doch wie es bei Projekten in einem relativ neuen Bereich üblich ist, passierte etwas Unerwartetes.
Da jede virtuelle Maschine 500–1 GB belegt, dauerte das Kopieren solcher Volumes selbst innerhalb eines Rechenzentrums etwa 000–3 Stunden pro Maschine. Dadurch haben wir das vorgegebene Zeitfenster nicht eingehalten. Dies geschah aufgrund physischer Einschränkungen des Festplattensubsystems beim Übertragen von Daten an vCloud.
Aufgrund eines Fehlers in der verwendeten vCloud-Version konnte Storage vMotion nicht für eine virtuelle Maschine mit unterschiedlichen Festplattentypen organisiert werden, sodass die Festplatten ausgetauscht werden mussten. Dadurch war die Übertragung der virtuellen Maschinen zwar möglich, dauerte jedoch länger als geplant.
Der zweite Punkt, den wir nicht vorgesehen haben, sind die Einschränkungen beim Verschieben des Datenbankclusters (Failover Cluster MS SQLServer). Daher war es notwendig, den Cluster auf die Arbeit mit einem Knoten umzustellen und ihn außerhalb der Schutzzone zu belassen.
Bemerkenswert: Aus noch unklarem Grund zerfiel der Anwendungscluster durch die Übertragung virtueller Maschinen und musste neu zusammengesetzt werden.
Als Ergebnis des ersten Versuchs erhielten wir einen unbefriedigenden Zustand der Systeme und waren gezwungen, erneut mit der Planung und Entwicklung von Optionen zu beginnen.
Versuch #2
Nach der Bearbeitung der Fehler erkannte das Team, dass es richtiger wäre, die Infrastruktur in einem geschützten Bereich zu duplizieren und nur die Datendateien zu kopieren. Es wurde beschlossen, vom Kunden keine zusätzliche Zahlung für zusätzliche Serverkapazität zu verlangen, die zum Abschluss der Migration bereitgestellt werden musste.
Als die Cluster im geschützten Bereich vollständig dupliziert waren, verlief die Migration daher problemlos.
Als nächstes war es nur noch notwendig, die Netzwerke in geschützte und ungeschützte Zonen zu trennen. Hier gab es ein paar kleinere Störungen. Die Testphase des Gesamtsystems in einem geschützten Bereich ohne jegliche Absicherung konnte im Normalbetrieb beginnen. Nachdem wir positive Statistiken über den Betrieb des Systems in diesem Modus gesammelt hatten, gingen wir zur letzten Phase über: der Einführung von Schutzsystemen und der Einschränkung des Zugriffs.
Effektives Ergebnis und nützliche Lektion
Dadurch konnten durch gemeinsame Anstrengungen mit dem Kunden erhebliche Änderungen an der bestehenden Serverinfrastruktur vorgenommen werden, die es ermöglichten, die Zuverlässigkeit und Sicherheit der Speicherung personenbezogener Daten zu erhöhen, die Risiken eines unbefugten Zugriffs auf diese erheblich zu reduzieren und Erhalten Sie ein Zertifikat über die Einhaltung der Speicheranforderungen – eine Leistung, die noch nicht allen Entwicklern ähnlicher Software gelungen ist.
Unterm Strich sah das Arbeitspaket für das Projekt so aus:
- Es wurde ein dediziertes Subnetz eingerichtet;
- Insgesamt wurden zwei Cluster migriert, bestehend aus fünf virtuellen Maschinen: Failover-Datenbankcluster (zwei virtuelle Maschinen), Service Fabric-Anwendungscluster (drei virtuelle Maschinen);
- Datenschutz- und Verschlüsselungssysteme wurden konfiguriert.
Alles scheint klar und logisch. In der Praxis gestaltet sich alles etwas komplizierter. Wir waren wieder einmal davon überzeugt, dass bei der Bearbeitung jeder einzelnen Aufgabe eines solchen Plans ein Höchstmaß an Aufmerksamkeit für die „kleinen Dinge“ erforderlich ist, bei denen es sich tatsächlich nicht um Kleinigkeiten, sondern um entscheidende Faktoren für den Erfolg handelt das gesamte Projekt.
Source: habr.com