Hvordan man opfylder kravene i 152-FZ, beskytter personlige data for sine kunder og undgår at træde på vores egne greb.  

Hvordan man opfylder kravene i 152-FZ, beskytter personlige data for sine kunder og undgår at træde på vores egne greb.  

Ifølge russiske love bliver enhver virksomhed, der arbejder med personlige data om sine brugere i Rusland, operatør af persondata, uanset om de ønsker det eller ej. Dette medfører en række formelle og proceduremæssige forpligtelser, som ikke alle virksomheder kan eller ønsker at påtage sig alene.

Som praksis viser, er det helt korrekt, at man ikke ønsker det, fordi dette område er så nyt og ikke testet i praksis, at der opstår vanskeligheder og spørgsmål selv hos fagfolk. I dag vil vi fortælle, hvordan vi gennemførte et projekt til opbevaring af personlige data for vores kunde, og hvilke ikke-åbenlyse udfordringer vi stødte på.

Hvordan vi hjalp med at beskytte data i henhold til 152-FZ.

I begyndelsen af 2019 henvendte virksomheden LLC "Smart-Service" sig til os, udvikleren af en platform til styring af serviceeftersyn. HubEx og en applikation til udveksling af kontaktoplysninger. myQRcards.
 
Den første løsning gør det muligt at automatisere processen for vedligeholdelse af udstyr inden for en række områder – fra opsætning af kaffemaskiner og klimaanlæg i kontorlokaler til reparation af gasturbiner. Den anden – en online konstruktor til at skabe elektroniske visitkort baseret på QR-koder. 

Hvordan man opfylder kravene i 152-FZ, beskytter personlige data for sine kunder og undgår at træde på vores egne greb.  
Online visitkort myQRcards.

Begge systemer opbevarer og behandler brugerdata, der falder ind under klassifikationen "personlige" i henhold til 152-FZ. I dette tilfælde dikterer loven en række begrænsninger for systemer til opbevaring af sådanne personlige data for at sikre det krævede niveau af beskyttelse og udelukke risikoen for uautoriseret adgang med det formål at stjæle eller misbruge dem.
 
Loven skal overholdes, men "Smart-Service" havde ikke planer om at udvikle interne kompetencer til beskyttelse af persondata. Derfor "flyttede" tjenesterne og dataene, som deres brugere delte, til Linxdatacenter. "Smart-Service" flyttede de serverressourcer, der var nødvendige for arbejdsomgivelserne, til en separat beskyttet netværkszone i vores datacenter, som er attesteret i henhold til kravene angivet i 152-FZ – det såkaldte "Beskyttede cloud."
 

HVORDAN ER DET BESKYTTEDE CLOUD OPBYGGET

Enhver informationssystem, der behandler personlige data, skal opfylde tre grundlæggende krav: 

  • Adgang til servere til opbevaring og behandling af data skal ske via en VPN-forbindelse med kryptering iht. GOST;
  • Servere til opbevaring og behandling af data skal være under konstant overvågning af antivirusbeskyttelse for at sikre, at der ikke er sårbarheder;
  • Lagringssystemet skal være placeret i isolerede netværk. 

Vi placerer kundens servere i separate zoner, der opfylder kravene i 152-FZ, og hjælper med at opnå en konklusion om overensstemmelse.

Hvordan man opfylder kravene i 152-FZ, beskytter personlige data for sine kunder og undgår at træde på vores egne greb.  
Arkitekturen for den beskyttede virtuelle infrastruktur for LLC «Smart Service».

Arbejdsforløb

Den indledende godkendelse af arbejdet blev foretaget i juni 2019, hvilket kan betragtes som projektets startdato. Alle arbejde skal udføres i et 'live' miljø med tusinder af forespørgsler om dagen. Det var nødvendigt at gennemføre projektet uden at forstyrre den normale drift af begge systemer.

Derfor blev der udarbejdet og godkendt en klar handlingsplan, opdelt i 4 faser:

  • forberedelse,
  • migration,
  • test og kontrol under reale forhold,
  • og aktivering af overvågningssystemer og adgangsbegrænsning.

For en sikkerheds skyld tog vi højde for en genoprettelsesprocedure i tilfælde af uforudsete situationer (DRP). Ifølge den oprindelige plan skulle arbejdet ikke tage meget tid og ressourcer og skulle være færdig i juli 2019. Hver fase indeholdt i slutningen en grundig test af netværksadgang og systemfunktionalitet.

Den mest udfordrende fase, hvor 'noget kunne gå galt', var migreringen. Oprindeligt planlagde vi at udføre migreringen ved at flytte virtuelle maskiner i sin helhed. Det var den mest logiske mulighed, da det ikke krævede involvering af ekstra ressourcer til omkonfiguration. Det kunne synes, at der ikke kunne være noget lettere end vMotion.
  

Uventet

Men som det ofte sker i projekter inden for relativt nye områder, skete der noget, vi ikke havde forventet.

Da hver virtuel maskine optager 500 — 1.000 GB, tog kopiering af sådanne mængder selv inden for det samme datacenter omkring 3-4 timer pr. maskine. Som resultat fik vi ikke gennemført det inden for den tildelte tidsramme. Dette skete på grund af fysiske begrænsninger i det diskbaserede system under dataoverførslen til vCloud.

Fejlen i den anvendte version af vCloud forhindrede os i at gennemføre Storage vMotion for den virtuelle maskine med forskellige disktyper, så diskkene måtte skiftes. Resultatet var, at vi kunne flytte de virtuelle maskiner, men det tog længere tid end planlagt. 
 
Det andet punkt, vi ikke havde forudset, var begrænsningerne for flytningen af DB-klusteret (Failover Cluster MS SQLServer). Derfor måtte vi overføre klusteret til at arbejde med en enkelt node og lade det være udenfor det beskyttede område. 

Bemærkelsesværdigt er, at klusteret af applikationer brød sammen som følge af flytningen af de virtuelle maskiner, og vi måtte samle det på ny af en uklar grund.

Som resultat af det første forsøg fik vi et utilfredsstillende systemstatus og måtte påbegynde planlægning og overvejelser af alternative løsninger igen.
 

Forsøg nr. 2

Efter at have vurderet vores fejl indså teamet, at det ville være korrekt at duplikere infrastrukturen i det beskyttede område og kun kopiere datafilerne. Der blev truffet beslutning om ikke at kræve ekstra betaling fra kunden for de ekstra serverressourcer, der blev nødvendige for at afslutte migreringen.

Som resultat, da klusterne i det beskyttede område var fuldstændig duplikeret, forløb migreringen uden problemer.

Dernæst var det kun nødvendigt at adskille netværkene i det beskyttede og det ubeskyttede område. Her var der kun nogle få ubetydelige driftsforstyrrelser. Testfasen for hele systemet i det beskyttede område uden nogen beskyttelse kunne startes i normal drift. Efter at have indsamlet positive stats for systemets drift i dette mode gik vi videre til den sidste fase: implementering af beskyttelsessystemer og adgangsbegrænsninger.
 

Gevinst og værdifuld lektion

Hvordan man opfylder kravene i 152-FZ, beskytter personlige data for sine kunder og undgår at træde på vores egne greb.  
 
I sidste ende lykkedes det med fælles indsats sammen med kunden at implementere betydelige ændringer i den eksisterende serverinfrastruktur, hvilket forbedrede pålideligheden og sikkerheden i opbevaringen af persondata, væsentligt reducerede risiciene for uautoriseret adgang til dem, samt opnåede et certifikat for opbevaringskravene – en bedrift, som langt fra alle udviklere af lignende software har opnået.
 
I det tørre resumé så projektarbejdet således ud:
 

  1. Der er oprettet et dedikeret subnet;
  2. I alt er migreret to klynger bestående af fem virtuelle maskiner: Failover-databaseklynge (to virtuelle maskiner), Service Fabric applikationsklynge (tre virtuelle maskiner);
  3. Der er foretaget indstillinger for datasikkerhed og kryptering.

Det ser ud til at være klart og logisk. I praksis viser det sig dog at være lidt mere kompliceret. Vi har igen bekræftet, at der kræves et ekstremt højt niveau af opmærksomhed på 'detaljer' i arbejdet med hver enkelt opgave af denne art, som viser sig at være afgørende faktorer for projektets succes. 

Kilde: habr.com

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster