Hoe kinne jo foldwaan oan 'e easken fan 152-FZ, beskermje de persoanlike gegevens fan jo kliïnten en stap net op ús rake  

Hoe kinne jo foldwaan oan 'e easken fan 152-FZ, beskermje de persoanlike gegevens fan jo kliïnten en stap net op ús rake

Neffens Russyske wetten wurdt elk bedriuw dat wurket mei de persoanlike gegevens fan har brûkers yn Ruslân, in operator foar persoanlike gegevens, oft it dat wol of net. Dit legt der in oantal formele en prosedurele ferplichtingen op dy't net elk bedriuw op himsels drage kin of wol.

Sa't de praktyk docht bliken, is it krekt dat hy dat net wol, om't dit kennisgebiet noch sa nij is en yn 'e praktyk net beproefd is, dat sels foar professionals swierrichheden en fragen opkomme. Hjoed sille wy prate oer hoe't wy in projekt ymplementearre om persoanlike gegevens foar ús klant op te slaan en hokker ûnsichtbere swierrichheden wy tsjinkamen.

Hoe wy holpen gegevens te beskermjen ûnder 152-FZ

Oan it begjin fan 2019 waarden wy kontakt opnommen troch Smart-Service LLC, in ûntwikkelder fan in platfoarm foar tsjinstbehear HubEx en applikaasjes foar dielen fan kontakten myQRcards.
 
De earste oplossing lit jo it proses fan ûnderhâld fan apparatuer yn in ferskaat oan gebieten automatisearje - fan it opsetten fan kofjemasines en airconditioning yn kantoarromten oant it reparearjen fan gasturbines. De twadde is in online ûntwerper foar it meitsjen fan elektroanyske visitekaarten basearre op QR-koades. 

Hoe kinne jo foldwaan oan 'e easken fan 152-FZ, beskermje de persoanlike gegevens fan jo kliïnten en stap net op ús rake
Online visitekaartsje myQRcards.

Beide systemen bewarje en ferwurkje brûkersgegevens dy't falt ûnder de klassifikaasje fan "persoanlik" yn oerienstimming mei 152-FZ. Yn dit gefal diktearret de wet in oantal beheiningen op opslachsystemen foar sokke persoanlike gegevens om it fereaske nivo fan feiligens te garandearjen en it risiko fan unautorisearre tagong foar it doel fan stellerij of misbrûk te eliminearjen.
 
De wet moat wurde observearre, mar Smart Service wie net fan plan om binnen himsels de kompetinsje te ûntwikkeljen om persoanlike gegevens te beskermjen. Dêrom binne de tsjinsten en gegevens dield troch har brûkers "ferpleatst" nei Linxdatacenter. "Smart-Service" hat de serverkapasiteit fan 'e wurkomjouwing oerbrocht nei in aparte beskerme netwurksône fan ús datasintrum, sertifisearre yn oerienstimming mei de easken neamd yn 152-FZ - de saneamde "Secure Cloud".
 

HOE IS IN FEILIGE WOLK ONTWERP?

Elk ynformaasjesysteem dat persoanlike gegevens ferwurket moat oan trije basiseasken foldwaan: 

  • tagong ta gegevens opslach en ferwurkjen tsjinners moatte wurde makke fia in VPN-kanaal mei fersifering yn oerienstimming mei GOST;
  • gegevens opslach en ferwurking tsjinners moatte konstant wurde kontrolearre troch anty-firus beskerming foar kwetsberens;
  • It opslachsysteem moat lizze yn isolearre netwurken. 

Wy pleatse de tsjinner kapasiteiten fan de klant yn aparte gebieten dy't foldogge oan de easken fan 152-FZ en helpe te krijen in konklúzje oer neilibjen.

Hoe kinne jo foldwaan oan 'e easken fan 152-FZ, beskermje de persoanlike gegevens fan jo kliïnten en stap net op ús rake
Arsjitektuer fan feilige firtuele ynfrastruktuer foar Smart Service LLC.

Foarútgong

De earste goedkarring fan it wurk waard útfierd yn juny 2019, wat kin wurde beskôge as de startdatum fan it projekt. Alle wurk moat dien wurde yn in "live" omjouwing mei tûzenen oanfragen per dei. Fansels wie it nedich om it projekt te foltôgjen sûnder de normale wurking fan beide systemen te ûnderbrekken.

Dêrom is in dúdlik aksjeplan opsteld en ôfpraat, ferdield yn 4 stadia:

  • tarieding,
  • migraasje,
  • testen en testen yn echte omstannichheden,
  • it ynskeakeljen fan tafersjochsystemen en tagongsbeperkingen.

Om op 'e feilige kant te wêzen, hawwe wy in Disaster Recovery Procedure (DRP) opnommen. Neffens it earste plan naam it wurk net folle tiid en middels en soe yn july 2019 foltôge wurde. Elke poadium omfette oan 'e ein in folsleine test fan' e netwurkbeskikberens en funksjonaliteit fan 'e systemen.

It dreechste stadium wêryn "wat mis gean koe" wie migraasje. Yn it earstoan wiene wy ​​fan plan de migraasje út te fieren troch folsleine firtuele masines oer te bringen. Dit wie de meast logyske opsje, om't it de belutsenens fan ekstra boarnen net nedich wie foar rekonfiguraasje. It soe lykje dat vMotion koe wêze ienfâldiger.
  

Unferwachts

Lykwols, lykas gewoanlik bart by projekten op in relatyf nij fjild, barde der wat ûnferwachts.

Sûnt elke firtuele masine beslacht 500 - 1 GB, naam it kopiearjen fan sokke folumes sels binnen ien datasintrum sawat 000-3 oeren per masine. As gefolch hawwe wy net foldien oan it tawiisde tiidfinster. Dit barde troch fysike beheiningen fan it skiifsubsysteem by it oerdragen fan gegevens nei vCloud.

In brek yn 'e brûkte vCloud-ferzje liet Storage vMotion net organisearje foar in firtuele masine mei ferskate soarten skiven, sadat de skiven feroare wurde moasten. Dêrtroch wie it mooglik om de firtuele masines oer te dragen, mar it duorre langer as pland. 
 
It twadde punt dat wy net foarsjoen binne de beheiningen foar it ferpleatsen fan it databankkluster (Failover Cluster MS SQLServer). As gefolch wie it nedich om it kluster te wikseljen om mei ien knooppunt te wurkjen en it bûten de beskerme sône te litten. 

Opmerklik: troch in noch ûndúdlike reden, as gefolch fan de oerdracht fan firtuele masines, foel it applikaasjekluster útinoar en moast opnij gearstald wurde.

As gefolch fan de earste poging, wy krigen in ûnfoldwaande steat fan de systemen en waarden twongen om te begjinnen mei plannen en ûntwikkeljen opsjes wer.
 

Poging nr. 2

Nei it wurk oan 'e flaters realisearre it team dat it krekter wêze soe om de ynfrastruktuer yn in beskerme gebiet te duplikearjen en allinich de gegevensbestannen te kopiearjen. Der waard besletten gjin ekstra betelling fan de klant te freegjen foar ekstra serverkapasiteit dy't ynset wurde moast om de migraasje te foltôgjen.

As gefolch, doe't de klusters yn it beskerme gebiet folslein duplikearre waarden, gie de migraasje sûnder problemen.

Dêrnei wie it allinich nedich om de netwurken fan beskerme en net beskerme sônes te skieden. Hjir wiene in pear lytse steuringen. It poadium fan it testen fan it heule systeem yn in beskerme gebiet sûnder beskerming koe yn normale modus begjinne. Nei it sammeljen fan positive statistiken oer de wurking fan it systeem yn dizze modus, binne wy ​​​​ferhuze nei de lêste etappe: lansearring fan beskermingssystemen en beheine tagong.
 

Effektyf resultaat en nuttige les

Hoe kinne jo foldwaan oan 'e easken fan 152-FZ, beskermje de persoanlike gegevens fan jo kliïnten en stap net op ús rake
 
As gefolch, troch mienskiplike ynspanningen mei de klant, wie it mooglik om wichtige feroarings oan te bringen yn 'e besteande serverynfrastruktuer, wêrtroch't de betrouberens en feiligens fan persoanlike gegevens opslach te ferheegjen, de risiko's fan unautorisearre tagong ta har signifikant ferminderje, en krije in sertifikaat fan neilibjen fan opslach easken - in prestaasje dat noch net elkenien hat berikt ûntwikkelders fan ferlykbere software.
 
De ûnderste rigel is dat it wurkpakket foar it projekt der sa út seach:
 

  1. In tawijd subnet is organisearre;
  2. Yn totaal waarden twa klusters migrearre, besteande út fiif firtuele masines: Failover database kluster (twa firtuele masines), Service Fabric applikaasje kluster (trije firtuele masines);
  3. Systemen foar gegevensbeskerming en fersifering binne konfigureare.

Alles liket dúdlik en logysk. Yn 'e praktyk blykt alles wat yngewikkelder te wêzen. Wy wiene nochris oertsjûge dat by it wurkjen mei elke yndividuele taak fan sa'n plan it heechste nivo fan oandacht foar de "lytse dingen" fereaske is, dy't yn feite gjin lytse dingen binne, mar de bepalende faktoaren foar it sukses fan it hiele projekt. 

Boarne: www.habr.com

Add a comment