I henhold til russisk lov blir ethvert selskap som arbeider med personopplysningene til brukerne sine i Russland en personopplysningsoperatør, enten de ønsker det eller ikke. Dette pålegger den en rekke formelle og prosedyremessige forpliktelser som ikke enhver virksomhet kan eller ønsker å bære på egen hånd.
Som praksis viser, er det helt riktig at han ikke vil, fordi dette kunnskapsområdet fortsatt er så nytt og ikke testet i praksis at det oppstår vanskeligheter og spørsmål selv for fagfolk. I dag skal vi snakke om hvordan vi implementerte et prosjekt for å lagre personopplysninger for kunden vår og hvilke uopplagte vanskeligheter vi møtte.
Hvordan vi bidro til å beskytte data under 152-FZ
I begynnelsen av 2019 ble vi kontaktet av Smart-Service LLC, en utvikler av en plattform for serviceadministrasjon og kontaktdelingsapplikasjoner .
Den første løsningen lar deg automatisere prosessen med vedlikehold av utstyr på en rekke områder - fra å sette opp kaffemaskiner og klimaanlegg i kontorlokaler til å reparere gassturbiner. Den andre er en online designer for å lage elektroniske visittkort basert på QR-koder.
Online visittkort myQRcards.
Begge systemene lagrer og behandler brukerdata som faller inn under klassifiseringen "personlig" i henhold til 152-FZ. I dette tilfellet dikterer loven en rekke restriksjoner på lagringssystemer for slike personopplysninger for å sikre det nødvendige sikkerhetsnivået og eliminere risikoen for uautorisert tilgang med det formål tyveri eller misbruk.
Loven skal overholdes, men Smart Service planla ikke å utvikle kompetansen til å beskytte personopplysninger i seg selv. Derfor "flyttet" tjenestene og dataene som ble delt av brukerne deres til Linxdatacenter. "Smart-Service" overførte serverkapasiteten til arbeidsmiljøet til en egen beskyttet nettverkssone i datasenteret vårt, sertifisert i henhold til kravene angitt i 152-FZ - den såkalte "Secure Cloud".
HVORDAN ER EN SIKKER SKY DESIGNET?
Ethvert informasjonssystem som behandler personopplysninger må oppfylle tre grunnleggende krav:
- tilgang til datalagring og behandlingsservere må gjøres gjennom en VPN-kanal med kryptering i samsvar med GOST;
- datalagrings- og behandlingsservere må konstant overvåkes av antivirusbeskyttelse for sårbarheter;
- Lagringssystemet må være plassert i isolerte nettverk.
Vi plasserer kundens serverkapasitet i separate områder som oppfyller kravene i 152-FZ og hjelper til med å få en konklusjon om samsvar.
Arkitektur av sikker virtuell infrastruktur for Smart Service LLC.
fremdriften i arbeidet
Den første godkjenningen av arbeidet ble utført i juni 2019, som kan betraktes som startdato for prosjektet. Alt arbeid må gjøres i et "live" miljø med tusenvis av forespørsler per dag. Naturligvis var det nødvendig å fullføre prosjektet uten å forstyrre den normale driften av begge systemene.
Det ble derfor utarbeidet og vedtatt en klar handlingsplan, delt inn i 4 trinn:
- forberedelse,
- migrasjon,
- testing og testing under reelle forhold,
- muliggjør overvåkingssystemer og tilgangsbegrensninger.
For å være på den sikre siden har vi inkludert en Disaster Recovery Procedure (DRP). I henhold til den opprinnelige planen tok ikke arbeidet mye tid og ressurser og skulle være ferdig i juli 2019. Hvert trinn inkluderte på slutten en fullstendig test av nettverkstilgjengelighet og funksjonalitet til systemene.
Det vanskeligste stadiet der «noe kunne gå galt» var migrasjon. I utgangspunktet planla vi å gjennomføre migreringen ved å overføre hele virtuelle maskiner. Dette var det mest logiske alternativet, siden det ikke krevde involvering av ekstra ressurser for rekonfigurering. Det ser ut til at vMotion kan være enklere.
Uventet
Men som det vanligvis skjer på prosjekter i et relativt nytt felt, skjedde noe uventet.
Siden hver virtuell maskin opptar 500 - 1 GB, tok kopiering av slike volumer selv innenfor ett datasenter omtrent 000-3 timer per maskin. Som et resultat klarte vi ikke det tildelte tidsvinduet. Dette skjedde på grunn av fysiske begrensninger av diskundersystemet ved overføring av data til vCloud.
En feil i vCloud-versjonen som ble brukt tillot ikke at Storage vMotion ble organisert for en virtuell maskin med forskjellige typer disker, så diskene måtte endres. Som et resultat var det mulig å overføre de virtuelle maskinene, men det tok lengre tid enn planlagt.
Det andre punktet som vi ikke sørget for, er begrensningene for flytting av databaseklyngen (Failover Cluster MS SQLServer). Som et resultat var det nødvendig å bytte klyngen til å fungere med en node og la den være utenfor den beskyttede sonen.
Bemerkelsesverdig: av en fortsatt uklar grunn, som et resultat av overføringen av virtuelle maskiner, falt applikasjonsklyngen fra hverandre og måtte settes sammen igjen.
Som et resultat av det første forsøket fikk vi en utilfredsstillende tilstand på systemene og ble tvunget til å begynne å planlegge og utvikle alternativer igjen.
Forsøk nr. 2
Etter å ha jobbet med feilene innså teamet at det ville være mer riktig å duplisere infrastrukturen i et beskyttet område og kopiere kun datafilene. Det ble besluttet å ikke kreve tilleggsbetaling fra kunden for ekstra serverkapasitet som måtte distribueres for å fullføre migreringen.
Som et resultat, da klyngene i det vernede området ble fullstendig duplisert, gikk migrasjonen uten problemer.
Deretter var det bare nødvendig å skille nettverkene av beskyttede og ubeskyttede soner. Det var noen mindre forstyrrelser her. Stadiet med å teste hele systemet i et beskyttet område uten noen beskyttelse kunne starte i normal modus. Etter å ha samlet inn positiv statistikk om systemets drift i denne modusen, gikk vi videre til det siste stadiet: lansering av beskyttelsessystemer og begrenset tilgang.
Effektivt resultat og nyttig leksjon
Som et resultat, gjennom felles innsats med kunden, var det mulig å gjøre betydelige endringer i den eksisterende serverinfrastrukturen, noe som gjorde det mulig å øke påliteligheten og sikkerheten til lagring av personopplysninger, betydelig redusere risikoen for uautorisert tilgang til dem, og få et sertifikat for samsvar med lagringskrav - en prestasjon som ikke alle ennå har oppnådd utviklere av lignende programvare.
Poenget er at arbeidspakken for prosjektet så slik ut:
- Et dedikert undernett er organisert;
- Totalt ble to klynger migrert, bestående av fem virtuelle maskiner: Failover-databaseklynge (to virtuelle maskiner), Service Fabric-applikasjonsklynge (tre virtuelle maskiner);
- Databeskyttelse og krypteringssystemer er konfigurert.
Alt virker klart og logisk. I praksis viser alt seg å være litt mer komplisert. Vi var nok en gang overbevist om at når man arbeider med hver enkelt oppgave i en slik plan, kreves det høyeste nivå av oppmerksomhet på de "små tingene", som faktisk viser seg å ikke være små ting, men de avgjørende faktorene for suksess med hele prosjektet.
Kilde: www.habr.com
