Laŭ rusaj leĝoj, ĉiu kompanio, kiu laboras kun la personaj datumoj de siaj uzantoj en Rusio, fariĝas telefonisto pri personaj datumoj, ĉu ĝi volas aŭ ne. Ĉi tio trudas al ĝi kelkajn formalajn kaj procedurajn devojn, kiujn ne ĉiu entrepreno povas aŭ volas porti per si mem.
Kiel praktiko montras, estas tute prave, ke li ne volas, ĉar ĉi tiu areo de scio estas ankoraŭ tiel nova kaj ne provita en la praktiko, ke malfacilaĵoj kaj demandoj aperas eĉ por profesiuloj. Hodiaŭ ni parolos pri kiel ni efektivigis projekton por stoki personajn datumojn por nia kliento kaj kiajn nevideblajn malfacilaĵojn ni renkontis.
Kiel ni helpis protekti datumojn sub 152-FZ
Komence de 2019, ni estis kontaktitaj de Smart-Service LLC, programisto de platformo por administrado de servoj. kaj kontaktaj kundividaj aplikaĵoj .
La unua solvo permesas vin aŭtomatigi la procezon de prizorgado de ekipaĵoj en diversaj areoj - de agordo de kafmaŝinoj kaj klimatiziloj en oficejoj ĝis riparado de gasturbinoj. La dua estas interreta dezajnisto por krei elektronikajn vizitkartojn bazitajn sur QR-kodoj.
Interreta vizitkarto myQRcards.
Ambaŭ sistemoj stokas kaj prilaboras uzantajn datumojn, kiuj apartenas al la klasifiko de "personaj" laŭ 152-FZ. En ĉi tiu kazo, la leĝo diktas kelkajn limigojn pri stokadsistemoj por tiaj personaj datumoj por certigi la bezonatan nivelon de sekureco kaj forigi la riskon de neaŭtorizita aliro por ŝtelo aŭ misuzo.
La leĝo devas esti observita, sed Smart Service ne planis disvolvi en si mem la kompetentecon protekti personajn datumojn. Tial, la servoj kaj datumoj dividitaj de iliaj uzantoj "moviĝis" al Linxdatacenter. "Smart-Servo" transdonis la servilan kapaciton de la labormedio al aparta protektita reto-zono de nia datumcentro, atestita laŭ la postuloj deklaritaj en 152-FZ - la tiel nomata "Sekura Nubo".
KIEL ESTAS SEKURA NUBO DESIGNITA?
Ĉiu informsistemo prilaboranta personajn datumojn devas plenumi tri bazajn postulojn:
- aliro al datumstokado kaj prilaborado de serviloj devas esti farita per VPN-kanalo kun ĉifrado laŭ GOST;
- datumstokado kaj prilaborado serviloj devas esti konstante monitoritaj per kontraŭvirusa protekto por vundeblecoj;
- La konserva sistemo devas esti lokita en izolitaj retoj.
Ni metas la servilojn de la kliento en apartajn areojn, kiuj plenumas la postulojn de 152-FZ kaj helpas akiri konkludon pri konformeco.
Arkitekturo de sekura virtuala infrastrukturo por Smart Service LLC.
Laborprogreso
La komenca aprobo de la laboro estis farita en junio 2019, kiu povas esti konsiderata la komenca dato de la projekto. Ĉiu laboro devas esti farita en "viva" medio kun miloj da petoj tage. Kompreneble, estis necese kompletigi la projekton sen interrompi la normalan funkciadon de ambaŭ sistemoj.
Tial, klara agadplano estis ellaborita kaj interkonsentita, dividita en 4 etapoj:
- preparado,
- migrado,
- testado kaj testado en realaj kondiĉoj,
- ebligante monitorajn sistemojn kaj alirlimigojn.
Por esti sekura flanko, ni inkludis Disaster Recovery Procedure (DRP). Laŭ la komenca plano, la laboro ne prenis multe da tempo kaj rimedoj kaj devis esti kompletigita en julio 2019. Ĉiu etapo inkludis fine plenan provon de la reto-havebleco kaj funkcieco de la sistemoj.
La plej malfacila etapo en kiu "io povus misfunkcii" estis migrado. Komence, ni planis efektivigi la migradon transdonante tutajn virtualajn maŝinojn. Ĉi tio estis la plej logika opcio, ĉar ĝi ne postulis la implikiĝon de pliaj rimedoj por reagordo. Ŝajnus, ke vMotion povus esti pli simpla.
Neatendite
Tamen, kiel kutime okazas pri projektoj en relative nova kampo, okazis io neatendita.
Ĉar ĉiu virtuala maŝino okupas 500 - 1 GB, kopii tiajn volumojn eĉ ene de unu datumcentro daŭris ĉirkaŭ 000-3 horojn per maŝino. Kiel rezulto, ni ne renkontis la asignitan tempofenestron. Ĉi tio okazis pro fizikaj limigoj de la disksubsistemo dum transdono de datumoj al vCloud.
Cimo en la uzata versio de vCloud ne permesis organizi Storage vMotion por virtuala maŝino kun malsamaj specoj de diskoj, do la diskoj devis esti ŝanĝitaj. Kiel rezulto, eblis translokigi la virtualajn maŝinojn, sed daŭris pli longe ol planite.
La dua punkto, kiun ni ne provizis, estas la limigoj pri movado de la datumbaza aro (Failover Cluster MS SQLServer). Kiel rezulto, estis necese ŝanĝi la areton por labori kun unu nodo kaj lasi ĝin ekster la protektita zono.
Rimarkinde: pro ankoraŭ neklara kialo, kiel rezulto de la translokigo de virtualaj maŝinoj, la aplikaĵo disfalis kaj devis esti rekunmetita.
Kiel rezulto de la unua provo, ni ricevis nekontentigan staton de la sistemoj kaj estis devigitaj denove komenci planadon kaj evoluadon de elektoj.
Provo n-ro 2
Post labori pri la eraroj, la teamo rimarkis, ke estus pli ĝuste duobligi la infrastrukturon en protektita areo kaj kopii nur la datumdosierojn. Estis decidite ne postuli kroman pagon de la kliento por kroma servila kapacito kiu devis esti deplojita por kompletigi la migradon.
Kiel rezulto, kiam la aretoj en la protektita areo estis tute duobligitaj, la migrado iris sen problemoj.
Poste, necesis nur apartigi la retojn de protektitaj kaj neprotektitaj zonoj. Estis kelkaj malgrandaj interrompoj ĉi tie. La stadio de testado de la tuta sistemo en protektita areo sen ajna protekto povis komenci en normala reĝimo. Kolektinte pozitivajn statistikojn pri la funkciado de la sistemo en ĉi tiu reĝimo, ni pasis al la lasta etapo: lanĉi protektajn sistemojn kaj limigi aliron.
Efika rezulto kaj utila leciono
Kiel rezulto, per komunaj klopodoj kun la kliento, eblis fari signifajn ŝanĝojn al la ekzistanta servila infrastrukturo, kio ebligis pliigi la fidindecon kaj sekurecon de konservado de personaj datumoj, signife redukti la riskojn de neaŭtorizita aliro al ili, kaj akiri atestilon pri konformeco al konservado de postuloj - atingo, kiun ne ĉiuj ankoraŭ atingis programistojn de simila programaro.
La fundo estas, ke la laborpakaĵo por la projekto aspektis jene:
- Diligenta subreto estis organizita;
- Entute, du aretoj estis migritaj, konsistante el kvin virtualaj maŝinoj: Failover datumbaza areto (du virtualaj maŝinoj), Service Fabric-aplikgrupo (tri virtualaj maŝinoj);
- Datenprotekto kaj ĉifradsistemoj estis agordita.
Ĉio ŝajnas klara kaj logika. Praktike ĉio montriĝas iom pli komplika. Ni denove konvinkiĝis, ke kiam oni laboras kun ĉiu individua tasko de tia plano, necesas la plej alta nivelo de atento al la "etaĵoj", kiuj fakte montriĝas ne malgrandaj aferoj, sed la determinaj faktoroj por la sukceso de la tuta projekto.
fonto: www.habr.com