Według rosyjskiego prawa każda firma obsługująca dane osobowe swoich użytkowników w Rosji staje się operatorem PDn, niezależnie od tego, czy tego chce, czy nie. Nakłada to na nią szereg formalnych i proceduralnych obowiązków, które nie każda firma może lub chce ponieść samodzielnie.
Jak pokazuje praktyka – całkowicie słusznie nie chce, ponieważ ta dziedzina wiedzy jest jeszcze na tyle nowa i nieprzetestowana w praktyce, że trudności i pytania pojawiają się nawet wśród profesjonalistów. Dziś opowiemy o tym, jak realizowaliśmy projekt dotyczący przechowywania danych osobowych dla naszego klienta oraz z jakimi nieoczywistymi trudnościami się spotkaliśmy.
Jak pomogliśmy chronić dane zgodnie z ustawą 152-ФЗ
Na początku 2019 roku zwróciła się do nas firma ООО «Смарт-Сервис», deweloper platformy do zarządzania obsługą serwisową i aplikacji do wymiany kontaktów .
Pierwsze rozwiązanie umożliwia automatyzację procesu obsługi sprzętu w różnych obszarach – od ustawienia ekspresów do kawy i klimatyzatorów w biurach, po naprawy turbin gazowych. Drugie – to internetowy kreator do tworzenia elektronicznych wizytówek w oparciu o kody QR.
Wizytówka online myQRcards.
Oba systemy przechowują i przetwarzają dane użytkowników, które są klasyfikowane jako „osobowe” zgodnie z ustawą 152-ФЗ. W takim przypadku prawo narzuca szereg ograniczeń dotyczących systemów przechowywania tych danych osobowych, aby zapewnić wymagany poziom ich bezpieczeństwa i wykluczyć ryzyko nieautoryzowanego dostępu w celu kradzieży lub niewłaściwego wykorzystania.
Prawo trzeba przestrzegać, ale „Смарт-Сервис” nie planował rozwijać wewnętrznych kompetencji w zakresie ochrony PDn. Dlatego usługi i dane, którymi dzielili się ich użytkownicy, „przeprowadziły się” do Linxdatacenter. „Смарт-Сервис” przeniósł moc obliczeniową środowiska roboczego do oddzielnej chronionej strefy sieciowej naszego centrum danych, certyfikowanej zgodnie z wymaganiami określonymi w ustawach 152-ФЗ – tzw. „Chroniona chmura.”
JAK DZIAŁA CHRONIONA CHMURA
Każdy system informacyjny przetwarzający dane osobowe musi spełniać trzy podstawowe wymagania:
- Dostęp do serwerów przechowywania i przetwarzania danych powinien odbywać się przez kanał VPN z szyfrowaniem zgodnie z normą GOST;
- Serwery przechowywania i przetwarzania danych powinny być pod stałym monitoringiem zabezpieczeń antywirusowych w celu wykrywania luk w zabezpieczeniach;
- System przechowywania danych powinien być umieszczony w izolowanych sieciach.
Umieszczamy serwery klientów w osobnych strefach spełniających wymagania ustawy 152-FZ i pomagamy uzyskać certyfikację zgodności.
Architektura chronionej wirtualnej infrastruktury dla LLC »Smart Service«.
Postęp prac
Wstępna akceptacja prac miała miejsce w czerwcu 2019 roku, co można uznać za datę rozpoczęcia projektu. Wszystkie prace musiały być wykonywane w środowisku „na żywo” z tysiącami zapytań dziennie. Naturalnie, projekt musiał być zrealizowany bez przerywania normalnej pracy obu systemów.
Dlatego opracowano i zatwierdzono szczegółowy plan działania, podzielony na 4 etapy:
- przygotowanie,
- migracja,
- testowanie i weryfikacja w warunkach rzeczywistych,
- uruchomienie systemów monitorowania i ograniczenie dostępu.
Na wszelki wypadek przewidzieliśmy procedurę odzyskiwania w sytuacjach awaryjnych (DRP). Według początkowego planu prace nie zajmowały dużo czasu i zasobów i miały zakończyć się w lipcu 2019 roku. Każdy z etapów przewidywał na zakończenie pełne testowanie dostępności sieciowej i funkcjonalności systemów.
Najtrudniejszym etapem, w którym mogło „coś pójść nie tak”, była migracja. Początkowo planowaliśmy przeprowadzić migrację poprzez przeniesienie maszyn wirtualnych w całości. To była najbardziej logiczna opcja, ponieważ nie wymagała zaangażowania dodatkowych zasobów do przerejestrowania. Wydawało się, że nie ma nic prostszego niż vMotion.
Niespodziewanie
Jednak, jak to zwykle bywa w projektach w stosunkowo nowej dziedzinie, zdarzyło się coś, czego nie oczekiwaliśmy.
Ponieważ każda maszyna wirtualna zajmuje od 500 do 1000 GB, kopiowanie takich ilości nawet w ramach jednego centrum danych zajęło około 3-4 godzin na każdą maszynę. W efekcie nie zmieściliśmy się w wyznaczonym czasie. To wydarzyło się z powodu fizycznych ograniczeń systemu dyskowego podczas przenoszenia danych do vCloud.
Błąd używanej wersji vCloud uniemożliwił zorganizowanie Storage vMotion w odniesieniu do maszyny wirtualnej z różnymi typami dysków, dlatego trzeba było je zmienić. W rezultacie udało się przenieść maszyny wirtualne, ale zajęło to więcej czasu, niż planowano.
Drugim punktem, którego nie przewidzieliśmy, były ograniczenia dotyczące przenoszenia klastra DB (Failover Cluster MS SQLServer). W rezultacie musieliśmy przekształcić klaster w pracę z jednym węzłem i pozostawić go poza strefą zabezpieczoną.
Ciekawe: z powodu wciąż niejasnej przyczyny w rezultacie przenoszenia maszyn wirtualnych rozpadł się klaster aplikacji, który trzeba było odbudować.
W wyniku pierwszej próby uzyskaliśmy niezadowalający stan systemów i musieliśmy ponownie przystąpić do planowania oraz opracowania opcji.
Próba nr 2
Po przeanalizowaniu błędów zespół zrozumiał, że lepiej będzie jednak zduplikować infrastrukturę w strefie zabezpieczonej i skopiować tylko pliki z danymi. Podjęto decyzję o niewymaganiu od klienta dopłaty za dodatkowe moce serwerowe, które trzeba było uruchomić, aby zakończyć migrację.
W rezultacie, gdy klastry w strefie zabezpieczonej zostały całkowicie zduplikowane, migracja przebiegła bez problemów.
Następnie należało tylko oddzielić sieci strefy zabezpieczonej i niezabezpieczonej. Tu obyło się bez większych zakłóceń w pracy. Etap testowania całego systemu w strefie zabezpieczonej bez jakiejkolwiek ochrony udało się uruchomić w trybie normalnym. Zbierając pozytywną statystykę pracy systemu w takim trybie, przeszliśmy do ostatniego etapu: uruchomienia systemów ochrony i ograniczenia dostępu.
Efektywny wynik i użyteczna lekcja
W efekcie, wspólnymi siłami z klientem udało się wprowadzić znaczące zmiany w istniejącej infrastrukturze serwerowej, co pozwoliło zwiększyć niezawodność i bezpieczeństwo przechowywania danych osobowych, znacznie zmniejszyć ryzyko nieautoryzowanego dostępu do nich oraz uzyskać certyfikat spełnienia wymagań dotyczących przechowywania — osiągnięcie, do którego jeszcze nie dotarli wszyscy deweloperzy podobnego oprogramowania.
Na koniec kompleks prac w projekcie wyglądał tak:
- Utworzono dedykowaną podsieć;
- Migracja dwóch klastrów, składających się z pięciu maszyn wirtualnych, została zakończona: klaster baz danych Failover (dwie maszyny wirtualne), klaster aplikacji Service Fabric (trzy maszyny wirtualne);
- Konfiguracja systemów ochrony i szyfrowania danych została przeprowadzona.
Wydaje się, że wszystko jest zrozumiałe i logiczne. W praktyce jednak wszystko okazuje się nieco bardziej skomplikowane. Ponownie przekonaliśmy się, że przy pracy nad każdą z takich zadań wymagana jest najwyższa uwaga na "szczegóły", które okazują się być kluczowymi czynnikami sukcesu całego projektu.
Źródło: habr.com
