Sådan overholder du kravene i 152-FZ, beskytter dine kunders personlige data og ikke træder på vores rake  

Sådan overholder du kravene i 152-FZ, beskytter dine kunders personlige data og ikke træder på vores rake

Ifølge russisk lovgivning bliver enhver virksomhed, der arbejder med sine brugeres personlige data i Rusland, en persondataoperatør, uanset om den ønsker det eller ej. Dette pålægger den en række formelle og proceduremæssige forpligtelser, som ikke enhver virksomhed kan eller ønsker at bære på egen hånd.

Som praksis viser, er det helt rigtigt, at han ikke vil, for dette vidensområde er stadig så nyt og ikke afprøvet i praksis, at der opstår vanskeligheder og spørgsmål selv for fagfolk. I dag vil vi tale om, hvordan vi implementerede et projekt for at gemme personlige data for vores kunde, og hvilke uoplagte vanskeligheder vi stødte på.

Hvordan vi hjalp med at beskytte data under 152-FZ

I begyndelsen af ​​2019 blev vi kontaktet af Smart-Service LLC, en udvikler af en platform til service management HubEx og kontaktdelingsapplikationer myQRcards.
 
Den første løsning giver dig mulighed for at automatisere processen med vedligeholdelse af udstyr på en række forskellige områder - fra opsætning af kaffemaskiner og klimaanlæg i kontorlokaler til reparation af gasturbiner. Den anden er en online designer til at skabe elektroniske visitkort baseret på QR-koder. 

Sådan overholder du kravene i 152-FZ, beskytter dine kunders personlige data og ikke træder på vores rake
Online visitkort myQRcards.

Begge systemer gemmer og behandler brugerdata, der falder ind under klassificeringen "personlige" i henhold til 152-FZ. I dette tilfælde dikterer loven en række restriktioner for lagringssystemer for sådanne personoplysninger for at sikre det nødvendige sikkerhedsniveau og eliminere risikoen for uautoriseret adgang med henblik på tyveri eller misbrug.
 
Loven skal overholdes, men Smart Service havde ikke planer om i sig selv at udvikle kompetencen til at beskytte persondata. Derfor "flyttede" de tjenester og data, som deres brugere delte, til Linxdatacenter. "Smart-Service" overførte serverkapaciteten i arbejdsmiljøet til en separat beskyttet netværkszone i vores datacenter, certificeret i overensstemmelse med kravene angivet i 152-FZ - den såkaldte "Secure Cloud".
 

HVORDAN ER EN SIKKER SKY DESIGNET?

Ethvert informationssystem, der behandler personoplysninger, skal opfylde tre grundlæggende krav: 

  • adgang til datalagrings- og behandlingsservere skal ske gennem en VPN-kanal med kryptering i overensstemmelse med GOST;
  • datalagring og -behandlingsservere skal konstant overvåges af antivirusbeskyttelse for sårbarheder;
  • Lagersystemet skal være placeret i isolerede netværk. 

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

Sådan overholder du kravene i 152-FZ, beskytter dine kunders personlige data og ikke træder på vores rake
Arkitektur af sikker virtuel infrastruktur til Smart Service LLC.

hvordan arbejdet skrider frem

Den første godkendelse af arbejdet blev udført i juni 2019, hvilket kan betragtes som startdatoen for projektet. Alt arbejde skal udføres i et "live" miljø med tusindvis af anmodninger om dagen. Det var naturligvis nødvendigt at gennemføre projektet uden at afbryde den normale drift af begge systemer.

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

  • forberedelse,
  • migration,
  • test og test under virkelige forhold,
  • muliggør overvågningssystemer og adgangsbegrænsninger.

For at være på den sikre side har vi inkluderet en Disaster Recovery Procedure (DRP). Ifølge den oprindelige plan tog arbejdet ikke meget tid og ressourcer og skulle være afsluttet i juli 2019. Hver fase omfattede til sidst en komplet test af systemernes netværkstilgængelighed og funktionalitet.

Det sværeste stadie, hvor "noget kunne gå galt" var migration. I første omgang planlagde vi at udføre migreringen ved at overføre hele virtuelle maskiner. Dette var den mest logiske mulighed, da den ikke krævede involvering af yderligere ressourcer til omkonfiguration. Det ser ud til, at vMotion kunne være enklere.
  

Uventet

Men som det normalt sker på projekter inden for et relativt nyt felt, skete der noget uventet.

Da hver virtuel maskine fylder 500 - 1 GB, tog kopiering af sådanne mængder selv inden for et datacenter omkring 000-3 timer pr. maskine. Som følge heraf nåede vi ikke det tildelte tidsvindue. Dette skete på grund af fysiske begrænsninger af diskundersystemet ved overførsel af data til vCloud.

En fejl i den anvendte vCloud-version tillod ikke, at Storage vMotion blev organiseret til en virtuel maskine med forskellige typer diske, så diskene skulle ændres. Som følge heraf var det muligt at overføre de virtuelle maskiner, men det tog længere tid end planlagt. 
 
Det andet punkt, som vi ikke sørgede for, er begrænsningerne for flytning af databaseklyngen (Failover Cluster MS SQLServer). Som et resultat var det nødvendigt at skifte klyngen til at arbejde med en knude og lade den være uden for den beskyttede zone. 

Bemærkelsesværdigt: af en stadig uklar grund, som et resultat af overførslen af ​​virtuelle maskiner, faldt applikationsklyngen fra hinanden og måtte samles igen.

Som et resultat af det første forsøg fik vi en utilfredsstillende tilstand af systemerne og var tvunget til at begynde at planlægge og udvikle muligheder igen.
 

Forsøg nr. 2

Efter at have arbejdet på fejlene indså teamet, at det ville være mere korrekt at duplikere infrastrukturen i et beskyttet område og kun kopiere datafilerne. Det blev besluttet ikke at kræve yderligere betaling fra kunden for yderligere serverkapacitet, der skulle installeres for at fuldføre migreringen.

Som følge heraf forløb migrationen uden problemer, da klyngerne i det beskyttede område blev fuldstændig duplikeret.

Dernæst var det kun nødvendigt at adskille netværkene af beskyttede og ubeskyttede zoner. Der var et par mindre forstyrrelser her. Stadiet med at teste hele systemet i et beskyttet område uden nogen beskyttelse var i stand til at starte i normal tilstand. Efter at have indsamlet positive statistikker om systemets drift i denne tilstand, gik vi videre til den sidste fase: lancering af beskyttelsessystemer og begrænsning af adgang.
 

Effektivt resultat og nyttig lektion

Sådan overholder du kravene i 152-FZ, beskytter dine kunders personlige data og ikke træder på vores rake
 
Som følge heraf var det gennem fælles indsats med kunden muligt at foretage væsentlige ændringer i den eksisterende serverinfrastruktur, hvilket gjorde det muligt at øge pålideligheden og sikkerheden af ​​persondatalagringen, væsentligt reducere risikoen for uautoriseret adgang til dem, og opnå et certifikat for overholdelse af lagerkrav - en præstation, som ikke alle endnu har opnået udviklere af lignende software.
 
Den nederste linje er, at arbejdspakken for projektet så således ud:
 

  1. Et dedikeret undernet er blevet organiseret;
  2. I alt blev to klynger migreret, bestående af fem virtuelle maskiner: Failover-databaseklynge (to virtuelle maskiner), Service Fabric-applikationsklynge (tre virtuelle maskiner);
  3. Databeskyttelses- og krypteringssystemer er blevet konfigureret.

Alt virker klart og logisk. I praksis viser alt sig at være lidt mere kompliceret. Vi var endnu en gang overbevist om, at når man arbejder med hver enkelt opgave i en sådan plan, kræves det højeste niveau af opmærksomhed på de "små ting", som faktisk viser sig ikke at være små ting, men de afgørende faktorer for succes med hele projektet. 

Kilde: www.habr.com

Tilføj en kommentar