Conform legilor rusești, orice companie care lucrează cu datele personale ale utilizatorilor săi din Rusia devine operator de date cu caracter personal, indiferent dacă dorește sau nu. Acest lucru îi impune o serie de obligații formale și procedurale pe care nu orice afacere poate sau vrea să le suporte singură.
După cum arată practica, este foarte corect să nu vrea, deoarece acest domeniu de cunoaștere este încă atât de nou și nu este testat în practică, încât apar dificultăți și întrebări chiar și pentru profesioniști. Astăzi vom vorbi despre modul în care am implementat un proiect de stocare a datelor personale pentru clientul nostru și despre ce dificultăți neevidente am întâmpinat.
Cum am ajutat la protejarea datelor sub 152-FZ
La începutul anului 2019, am fost contactați de Smart-Service LLC, un dezvoltator al unei platforme de management al serviciilor. și aplicații de partajare a contactelor .
Prima soluție vă permite să automatizați procesul de întreținere a echipamentelor într-o varietate de domenii - de la instalarea aparatelor de cafea și a aparatelor de aer condiționat în spațiile de birouri până la repararea turbinelor cu gaz. Al doilea este un designer online pentru crearea de cărți de vizită electronice bazate pe coduri QR.
Carte de vizită online myQRcards.
Ambele sisteme stochează și prelucrează datele utilizatorului care se încadrează în clasificarea „personală” în conformitate cu 152-FZ. În acest caz, legea dictează o serie de restricții privind sistemele de stocare a acestor date cu caracter personal pentru a asigura nivelul necesar de securitate și a elimina riscul accesului neautorizat în scopul furtului sau utilizării abuzive.
Legea trebuie respectată, dar Smart Service nu și-a propus să dezvolte în sine competența de a proteja datele personale. Prin urmare, serviciile și datele partajate de utilizatorii lor „s-au mutat” în Linxdatacenter. „Smart-Service” a transferat capacitatea serverului mediului de lucru într-o zonă separată de rețea protejată a centrului nostru de date, certificată în conformitate cu cerințele prevăzute în 152-FZ - așa-numitul „Secure Cloud”.
CUM ESTE PROIECTAT UN CLOUD SEGUR?
Orice sistem informatic care prelucrează date cu caracter personal trebuie să îndeplinească trei cerințe de bază:
- accesul la serverele de stocare și procesare a datelor trebuie să se facă printr-un canal VPN cu criptare în conformitate cu GOST;
- serverele de stocare și procesare a datelor trebuie monitorizate constant prin protecție antivirus pentru vulnerabilități;
- Sistemul de stocare trebuie să fie amplasat în rețele izolate.
Amplasăm capacitățile de server ale clientului în zone separate care îndeplinesc cerințele 152-FZ și ajutăm la obținerea unei concluzii privind conformitatea.
Arhitectura infrastructurii virtuale securizate pentru Smart Service LLC.
progresul de muncă
Aprobarea inițială a lucrării a fost efectuată în iunie 2019, ceea ce poate fi considerat data de începere a proiectului. Toate lucrările trebuie efectuate într-un mediu „live” cu mii de solicitări pe zi. Desigur, a fost necesară finalizarea proiectului fără a întrerupe funcționarea normală a ambelor sisteme.
Prin urmare, a fost elaborat și convenit un plan de acțiune clar, împărțit în 4 etape:
- pregătire,
- migrație,
- testare și testare în condiții reale,
- activarea sistemelor de monitorizare și restricții de acces.
Pentru a fi în siguranță, am inclus o procedură de recuperare în caz de dezastru (DRP). Conform planului inițial, lucrarea nu a necesitat mult timp și resurse și urma să fie finalizată în iulie 2019. Fiecare etapă a inclus la final un test complet al disponibilității și funcționalității rețelei a sistemelor.
Cea mai dificilă etapă în care „ceva ar putea merge prost” a fost migrația. Inițial, am plănuit să efectuăm migrarea prin transferul de mașini virtuale întregi. Aceasta a fost cea mai logică opțiune, deoarece nu a necesitat implicarea unor resurse suplimentare pentru reconfigurare. S-ar părea că vMotion ar putea fi mai simplu.
Neasteptat
Totuși, așa cum se întâmplă de obicei în proiectele dintr-un domeniu relativ nou, sa întâmplat ceva neașteptat.
Deoarece fiecare mașină virtuală ocupă 500 - 1 GB, copierea unor astfel de volume chiar și într-un singur centru de date a durat aproximativ 000-3 ore pe mașină. Ca urmare, nu am îndeplinit intervalul de timp alocat. Acest lucru s-a întâmplat din cauza limitărilor fizice ale subsistemului de disc la transferul de date către vCloud.
O eroare în versiunea vCloud utilizată nu a permis ca Storage vMotion să fie organizat pentru o mașină virtuală cu diferite tipuri de discuri, așa că discurile au trebuit schimbate. Ca rezultat, a fost posibil să se transfere mașinile virtuale, dar a durat mai mult decât era planificat.
Al doilea punct pe care nu l-am prevăzut sunt restricțiile privind mutarea clusterului de baze de date (Failover Cluster MS SQLServer). Ca urmare, a fost necesar să comutați clusterul pentru a funcționa cu un singur nod și să-l lăsați în afara zonei protejate.
De remarcat: dintr-un motiv încă neclar, ca urmare a transferului de mașini virtuale, clusterul de aplicații s-a destramat și a trebuit să fie reasamblat.
Ca urmare a primei încercări, am primit o stare nesatisfăcătoare a sistemelor și am fost forțați să începem din nou planificarea și dezvoltarea opțiunilor.
Încercarea #2
După ce a lucrat la erori, echipa și-a dat seama că ar fi mai corect să dubleze infrastructura într-o zonă protejată și să copieze doar fișierele de date. S-a decis să nu se solicite plăți suplimentare din partea clientului pentru capacitatea suplimentară a serverului care trebuia implementată pentru a finaliza migrarea.
Ca urmare, când clusterele din aria protejată au fost complet duplicate, migrarea a decurs fără probleme.
În continuare, a fost necesar doar separarea rețelelor de zone protejate și neprotejate. Au fost câteva întreruperi minore aici. Etapa de testare a întregului sistem într-o zonă protejată fără nicio protecție a putut începe în modul normal. După ce am colectat statistici pozitive privind funcționarea sistemului în acest mod, am trecut la ultima etapă: lansarea sistemelor de protecție și restricționarea accesului.
Rezultat eficient și lecție utilă
Ca urmare, prin eforturi comune cu clientul, a fost posibilă efectuarea unor modificări semnificative asupra infrastructurii de server existente, ceea ce a făcut posibilă creșterea fiabilității și securității stocării datelor cu caracter personal, reducerea semnificativă a riscurilor de acces neautorizat la acestea și obțineți un certificat de conformitate cu cerințele de stocare - o realizare pe care nu toată lumea a obținut-o încă dezvoltatorii de software similar.
Concluzia este că pachetul de lucru pentru proiect arăta astfel:
- A fost organizată o subrețea dedicată;
- În total, au fost migrate două clustere, formate din cinci mașini virtuale: cluster de baze de date failover (două mașini virtuale), cluster de aplicații Service Fabric (trei mașini virtuale);
- Au fost configurate sistemele de protecție și criptare a datelor.
Totul pare clar și logic. În practică, totul se dovedește a fi puțin mai complicat. Am fost din nou convinși că atunci când lucrăm cu fiecare sarcină individuală a unui astfel de plan, este necesar cel mai înalt nivel de atenție pentru „lucrurile mărunte”, care de fapt se dovedesc a fi nu lucruri mărunte, ci factori determinanți pentru succesul întregul proiect.
Sursa: www.habr.com
