Hogyan feleljünk meg az 152-FZ követelményeinek, védjük ügyfeleink személyes adatait, és kerüljük el a korábbi hibáinkat  

Hogyan feleljünk meg az 152-FZ követelményeinek, védjük ügyfeleink személyes adatait, és kerüljük el a korábbi hibáinkat  

A orosz törvények szerint minden cég, amely a felhasználói személyes adataival foglalkozik Oroszországban, személyes adatkezelővé válik, akarja vagy sem. Ez számos formális és eljárási kötelezettséget ró rá, amelyet nem minden vállalkozás tud vagy akar önállóan vállalni.

A tapasztalatok szerint teljesen helyénvaló, hogy nem akarja, mert ez a tudományág még olyan új és nem előkészített, 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ítottuk meg a személyes adatok tárolására vonatkozó projektet megrendelőnk számára, és milyen nem nyilvánvaló nehézségekkel szembesültünk.

Hogyan segítettünk védeni az adatokat a 152-FZ szerint

2019 elején megkeresett minket a Smart-Service LLC, egy szolgáltatáskezelő platform fejlesztője. HubEx és a kapcsolattartó információk cserélésére szolgáló alkalmazás myQRcards.
 
Az első megoldás lehetővé teszi a berendezések karbantartásának automatizálását a legkülönfélébb területeken – a kávéfőzők és légkondicionálók irodai beállításától kezdve a gázturbina javításáig. A második – online tervező az elektronikus névjegykártyák QR-kód alapú létrehozásához. 

Hogyan feleljünk meg az 152-FZ követelményeinek, védjük ügyfeleink személyes adatait, és kerüljük el a korábbi hibáinkat  
Online névjegy myQRcards.

Mindkét rendszer tárol és feldolgoz felhasználói adatokat, amelyek a 152-FZ szerinti „személyes” adat kategóriájába esnek. Ilyen esetben a jogszabály számos korlátozást diktál az ilyen személyes adatok tárolási rendszereivel szemben, hogy biztosítsa a szükséges védelmi szintet, és kiküszöbölje a jogosulatlan hozzáférés kockázatát, amely a lopás vagy jogellenes felhasználás célját szolgálná.
 
A törvényt be kell tartani, de a Smart-Service nem tervezte, hogy belső személyes adatvédelmi kompetenciákat fejlesszen ki. Ezért a szolgáltatások és adatok, amelyeket a felhasználóik osztottak meg, „átkerültek” a Linxdatacenterbe. A Smart-Service a munkakörnyezetének szerverkapacitását áthelyezte a mi adatközpontunk egy külön védett hálózati zónájába, amelyet a 152-FZ-ben megfogalmazott követelményeknek megfelelően tanúsítottak – az úgynevezett „Védett felhő”.
 

HOGY MŰKÖDIK A VÉDOTT FELHŐ

Bármely információs rendszer, amely személyes adatokat dolgoz fel, három alapvető követelménynek kell megfelelnie: 

  • A hozzáférés az adatkezelő és -tároló szerverekhez VPN-csatornán keresztül, a GOST-nak megfelelő titkosítással kell történnie;
  • Az adatkezelő és -tároló szervereknek folyamatosan antivírus védelem alatt kell állniuk, hogy ne legyenek sebezhetőségeik;
  • A tároló rendszernek izolált hálózatokban kell elhelyezkednie. 

A megrendelő szerverkapacitásait külön zónákban helyezzük el, amelyek megfelelnek az 152-FZ követelményeinek, és segítünk beszerezni a megfelelőségi nyilatkozatot.

Hogyan feleljünk meg az 152-FZ követelményeinek, védjük ügyfeleink személyes adatait, és kerüljük el a korábbi hibáinkat  
Megvédett virtuális infrastruktúra architektúrája az LLC „Smart Service” számára.

A munka előrehaladása

A munkák első egyeztetése 2019 júniusában történt, amelyet a projekt kezdetének lehet tekinteni. Minden munkát 'éles' környezetben kell végrehajtani, napi több ezer kéréssel. Természetesen a projektet úgy kellett megvalósítani, hogy a két rendszer normál működése ne szakadjon meg.

Ezért egy világos cselekvési tervet állítottunk össze, amely négy szakaszra oszlott:

  • előkészítés,
  • migráció,
  • valós körülmények közötti tesztelés és ellenőrzés,
  • monitoring rendszerek telepítése és a hozzáférés korlátozása.

Minden esetre foglalkoztunk egy helyreállítási eljárással váratlan helyzet esetére (DRP). Az eredeti terv szerint a munkák nem foglaltak el sok időt és erőforrást, és 2019 júliusában kellett volna véget érniük. Minden szakasz végén teljes kiterjedésű hálózati hozzáférhetőségi és rendszerteljesítmény tesztelést kellett végezni.

A legnehezebb szakasz, ahol 'valami nem mehetett volna jól', a migráció volt. Eredetileg azt terveztük, hogy a virtuális gépek teljes áthelyezésével hajtjuk végre a migrációt. Ez volt a leglogikusabb lehetőség, mivel nem igényelt plusz erőforrásokat az átkonfigurálásra. Úgy tűnt, hogy mi lehetne egyszerűbb, mint a vMotion.
  

Hirtelen

Ám, ahogyan ez a projekteknél gyakran előfordul az új területeken, olyan dolog történt, amire nem számítottunk.

Mivel minden virtuális gép 500 – 1 000 GB-ot foglal el, ilyen mennyiségek másolása még egy adatközponton belül is körülbelül 3-4 órát vett igénybe gépenként. A végén nem fejeztük be az előírt időkereten belül. Ez a vCloud adathordozási korlátai miatt történt a migráció során.

A bug in the used version of vCloud prevented the organization of Storage vMotion for virtual machines with different disk types, so the disks had to be changed. As a result, the virtual machines were successfully transferred, but it took longer than planned. 
 
The second point we did not foresee was the restrictions on transferring the database cluster (Failover Cluster MS SQLServer). As a result, we had to switch the cluster to work with a single node and leave it outside the protected zone. 

Notably, for reasons still unclear, the application cluster fell apart during the transfer of the virtual machines and had to be rebuilt.

As a result of the first attempt, we ended up with an unsatisfactory system state and had to start over with planning and exploring options.
 

Attempt No. 2

After analyzing the errors, the team realized that it would be better to duplicate the infrastructure in the protected zone and only copy the data files. It was decided not to ask the client for additional payment for the extra server capacity that had to be deployed to complete the migration.

As a result, when the clusters in the protected zone were fully duplicated, the migration went smoothly.

Next, it was necessary to separate the networks of the protected and unprotected zones. This involved a few minor disruptions. The system testing phase in the protected zone without any protection was successfully launched. After gathering positive performance statistics of the system in this mode, we moved to the final stage: launching the protection systems and limiting access.
 

Successful Outcome and Valuable Lesson

Hogyan feleljünk meg az 152-FZ követelményeinek, védjük ügyfeleink személyes adatait, és kerüljük el a korábbi hibáinkat  
 
In the end, through joint efforts with the client, significant changes were made to the existing server infrastructure, which enhanced the reliability and security of personal data storage, significantly reduced the risk of unauthorized access, and obtained a certificate of compliance with storage requirements — an achievement that not all developers of similar software have yet reached.
 
In summary, the project work looked like this:
 

  1. A dedicated subnet was organized;
  2. Összesen két klasztert migráltunk, melyek öt virtuális gépből állnak: Failover adatbázis klaszter (két virtuális gép), Service Fabric alkalmazás klaszter (három virtuális gép);
  3. A rendszerek védelmére és az adatok titkosítására vonatkozó beállításokat elvégeztük.

Első ránézésre minden világosnak és logikusnak tűnik. A gyakorlatban azonban minden kicsit bonyolultabb. Újra megerősítettük, hogy minden egyes feladat esetében a legmagasabb figyelem szükséges a "kisebb részletekre", amelyek valójában nem apróságok, hanem a projekt sikerének meghatározó tényezői. 

Forrás: habr.com

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster