Hogyan tartsa be a 152-FZ követelményeit, védje meg ügyfelei személyes adatait, és ne lépjen ránk  

Hogyan tartsa be a 152-FZ követelményeit, védje meg ügyfelei személyes adatait, és ne lépjen ránk

Az orosz törvények szerint minden olyan vállalat, amely Oroszországban tartózkodó felhasználóinak személyes adataival dolgozik, személyes adatok kezelőjévé válik, akár akarja, akár nem. Ez számos formai és eljárási kötelezettséget ró rá, amelyeket nem minden vállalkozás tud vagy akar egyedül viselni.

Ahogy a gyakorlat mutatja, teljesen jogos, hogy nem akarja, mert ez a tudásterület még annyira új, és a gyakorlatban még nem tesztelt, hogy még a szakemberek számára is nehézségek és kérdések merülnek fel. Ma arról fogunk beszélni, hogyan valósítottunk meg egy projektet ügyfeleink személyes adatainak tárolására, és milyen egyértelmű nehézségekkel találkoztunk.

Hogyan segítettük az adatok védelmét a 152-FZ alatt?

2019 elején megkeresett minket a Smart-Service LLC, a szolgáltatásmenedzsment platform fejlesztője. HubEx és kapcsolatmegosztó alkalmazások myQRcards.
 
Az első megoldás lehetővé teszi a berendezések karbantartásának folyamatának automatizálását számos területen – a kávéfőzők és klímaberendezések irodai helyiségekben történő felállításától a gázturbinák javításáig. A második egy online tervező elektronikus névjegykártyák létrehozására QR-kódok alapján. 

Hogyan tartsa be a 152-FZ követelményeit, védje meg ügyfelei személyes adatait, és ne lépjen ránk
Online névjegykártya myQRcards.

Mindkét rendszer tárolja és feldolgozza a felhasználói adatokat, amelyek a 152-FZ szerint a „személyes” besorolás alá tartoznak. Ebben az esetben a törvény számos korlátozást ír elő az ilyen személyes adatok tárolási rendszereire vonatkozóan, hogy biztosítsák a szükséges biztonsági szintet, és kiküszöböljék a lopás vagy visszaélés céljából történő illetéktelen hozzáférés kockázatát.
 
A törvényt be kell tartani, de a Smart Service nem tervezte a személyes adatok védelmére vonatkozó kompetencia fejlesztését magában. Ezért a felhasználók által megosztott szolgáltatások és adatok a Linxdatacenterbe „költöztek”. A „Smart-Service” átvitte a munkakörnyezet szerverkapacitását adatközpontunk egy külön védett hálózati zónájába, amely a 152-FZ-ben meghatározott követelményeknek megfelelően tanúsítva van - az úgynevezett „Secure Cloud”.
 

HOGYAN VAN A BIZTONSÁGOS FELHŐ TERVEZÉSE?

A személyes adatokat feldolgozó minden információs rendszernek három alapvető követelménynek kell megfelelnie: 

  • az adattároló és -feldolgozó szerverekhez való hozzáférést VPN-csatornán keresztül kell megvalósítani a GOST szerinti titkosítással;
  • az adattároló és -feldolgozó szervereket a vírusvédelemnek folyamatosan felügyelnie kell a sebezhetőségek szempontjából;
  • A tárolórendszert elszigetelt hálózatokban kell elhelyezni. 

Az ügyfél szerverkapacitását külön területeken helyezzük el, amelyek megfelelnek a 152-FZ követelményeinek, és segítenek levonni a megfelelőségi következtetést.

Hogyan tartsa be a 152-FZ követelményeit, védje meg ügyfelei személyes adatait, és ne lépjen ránk
A Smart Service LLC biztonságos virtuális infrastruktúrájának felépítése.

munka előrehaladásáról

A munkálatok kezdeti jóváhagyására 2019 júniusában került sor, ez tekinthető a projekt kezdő időpontjának. Minden munkát „élő” környezetben kell elvégezni, naponta több ezer kéréssel. Természetesen a projektet mindkét rendszer normál működésének megszakítása nélkül kellett befejezni.

Ezért egy világos cselekvési tervet készítettek és fogadtak el, amely 4 szakaszra oszlik:

  • készítmény,
  • migráció,
  • tesztelés és tesztelés valós körülmények között,
  • monitoringrendszerek és hozzáférési korlátozások lehetővé tétele.

A biztonság kedvéért beépítettünk egy katasztrófa-helyreállítási eljárást (DRP). Az eredeti terv szerint a munka nem sok időt és erőforrást igényelt, és 2019 júliusában kellett volna befejezni. Minden szakasz végén a hálózat elérhetőségének és a rendszerek működőképességének teljes körű tesztelése volt.

A legnehezebb szakasz, amikor „valami elromolhat”, a migráció volt. Kezdetben úgy terveztük, hogy az áttelepítést teljes virtuális gépek átvitelével hajtjuk végre. Ez volt a leglogikusabb lehetőség, mivel nem volt szükség további erőforrások bevonására az újrakonfiguráláshoz. Úgy tűnik, hogy a vMotion egyszerűbb is lehetne.
  

Váratlanul

Azonban, ahogy az általában egy viszonylag új területen zajló projekteknél történik, valami váratlan történt.

Mivel minden virtuális gép 500-1 GB-ot foglal el, az ilyen kötetek másolása még egy adatközponton belül is körülbelül 000-3 órát vett igénybe gépenként. Ennek eredményeként nem tartottuk be a megadott időablakot. Ez a lemez alrendszer fizikai korlátai miatt történt az adatok vCloudba való átvitele során.

A használt vCloud verzió hibája nem tette lehetővé a Storage vMotion rendszerezését egy virtuális géphez különböző típusú lemezekkel, ezért a lemezeket ki kellett cserélni. Ennek köszönhetően sikerült átvinni a virtuális gépeket, de ez tovább tartott a tervezettnél. 
 
A második pont, amelyről nem gondoskodtunk, az adatbázis-fürt (Failover Cluster MS SQLServer) mozgatására vonatkozó korlátozások. Ennek eredményeként a klasztert egy csomóponttal kellett dolgozni, és a védett zónán kívül kellett hagyni. 

Figyelemre méltó: máig tisztázatlan okból, a virtuális gépek átvitele következtében az alkalmazásfürt szétesett és újra kellett szerelni.

Az első próbálkozás eredményeként a rendszerek nem kielégítő állapotát kaptuk, és kénytelenek voltunk újra nekilátni a lehetőségek tervezésének, fejlesztésének.
 

2. kísérlet

A hibák kijavítása után a csapat rájött, hogy helyesebb lenne egy védett területen megkettőzni az infrastruktúrát, és csak az adatfájlokat másolni. Úgy döntöttek, hogy nem kérnek további fizetést az ügyféltől az áttelepítés befejezéséhez szükséges további szerverkapacitásért.

Ennek eredményeként, amikor a védett területen lévő klaszterek teljesen megduplázódtak, a migráció problémamentesen ment végbe.

Ezután már csak a védett és a nem védett zónák hálózatát kellett szétválasztani. Itt volt néhány kisebb fennakadás. A teljes rendszer tesztelésének szakasza egy védett területen, védelem nélkül, normál üzemmódban indulhatott el. Miután pozitív statisztikákat gyűjtöttünk a rendszer működéséről ebben az üzemmódban, áttértünk az utolsó szakaszra: a védelmi rendszerek elindítására és a hozzáférés korlátozására.
 

Hatékony eredmény és hasznos lecke

Hogyan tartsa be a 152-FZ követelményeit, védje meg ügyfelei személyes adatait, és ne lépjen ránk
 
Ennek eredményeként az ügyféllel közösen sikerült jelentős változtatásokat végrehajtani a meglévő szerver infrastruktúrán, ami lehetővé tette a személyes adatok tárolásának megbízhatóságának és biztonságának növelését, az azokhoz való jogosulatlan hozzáférés kockázatának jelentős csökkentését, ill. tanúsítványt szerezni a tárolási követelményeknek való megfelelésről - ez olyan eredmény, amelyet még nem mindenki ért el hasonló szoftverek fejlesztői számára.
 
A lényeg az, hogy a projekt munkacsomagja így nézett ki:
 

  1. Dedikált alhálózatot szerveztek;
  2. Összesen két fürt került áttelepítésre, amelyek öt virtuális gépből állnak: Feladatátvételi adatbázis-fürt (két virtuális gép), Service Fabric alkalmazásfürt (három virtuális gép);
  3. Az adatvédelmi és titkosítási rendszerek konfigurálva lettek.

Minden világosnak és logikusnak tűnik. A gyakorlatban minden kicsit bonyolultabbnak bizonyul. Ismét megbizonyosodtunk arról, hogy egy ilyen terv minden egyes feladatával a legmagasabb szintű odafigyelés szükséges az „apróságokra”, amelyek valójában nem kis dolgok, hanem a siker meghatározó tényezői. az egész projektet. 

Forrás: will.com

Hozzászólás