Volgens de Russische wetgeving wordt elk bedrijf dat persoonlijke gegevens van zijn gebruikers in Rusland verwerkt, automatisch een gegevensoperator, of het nu wil of niet. Dit legt een aantal formele en procedurele verplichtingen op die niet elk bedrijf zelfstandig kan of wil dragen.
Uit de praktijk blijkt dat het volkomen begrijpelijk is dat bedrijven dit niet willen, omdat dit vakgebied nog zo nieuw en ongetest is dat zelfs professionals tegen moeilijkheden en vragen aanlopen. Vandaag vertellen we hoe we een project hebben gerealiseerd voor de opslag van persoonlijke gegevens voor onze klant en met welke onvoorziene complicaties we te maken kregen.
Hoe we hielpen bij de bescherming van gegevens volgens de 152-FZ
Begin 2019 nam het bedrijf LLC 'Smart-Service', ontwikkelaar van een platform voor het beheer van serviceonderhoud, contact met ons op. en een applicatie voor het uitwisselen van contactgegevens .
De eerste oplossing maakt het mogelijk om het onderhoudsproces van apparatuur te automatiseren in verschillende gebieden, van het afstemmen van koffiemachines en airconditioners in kantoorruimtes tot het repareren van gasturbines. De tweede is een onlinebouwer voor het creëren van elektronische visitekaartjes op basis van QR-codes.
Online visitekaartje myQRcards.
Beide systemen slaan gebruikersgegevens op en verwerken deze, die onder de classificatie 'persoonsgegevens' vallen volgens de 152-FZ. In dit geval legt de wet een aantal beperkingen op aan systemen voor het opslaan van dergelijke persoonlijke gegevens om het vereiste niveau van bescherming te waarborgen en het risico van ongeautoriseerde toegang met de bedoeling van diefstal of ongeoorloofd gebruik uit te sluiten.
De wet moet worden nageleefd, maar 'Smart-Service' was niet van plan om interne expertise op het gebied van gegevensbescherming te ontwikkelen. Daarom zijn de diensten en gegevens die de gebruikers deelden, 'verhuist' naar Linxdatacenter. 'Smart-Service' heeft de servercapaciteit van de werkomgeving verplaatst naar een aparte beveiligde netwerkzone van ons datacenter, gecertificeerd volgens de eisen van de 152-FZ – het zogenaamde 'Veilige cloud'.
HOE DE VEILIGE CLOUD IS OPGEBOUWD
Elke informatie- en datasysteem dat persoonlijke gegevens verwerkt, moet voldoen aan drie fundamentele eisen:
- Toegang tot opslag- en verwerkingsservers moet plaatsvinden via een VPN-kanaal met encryptie volgens GOST;
- Opslag- en verwerkingsservers moeten continu worden gemonitord door antivirusbescherming op kwetsbaarheden;
- De opslag- en verwerkingssystemen moeten zich in geïsoleerde netwerken bevinden.
Wij plaatsen de servercapaciteit van de klant in aparte zones die voldoen aan de eisen van 152-FZ en helpen bij het verkrijgen van een conformiteitsverklaring.
Architectuur van de beveiligde virtuele infrastructuur voor LLC 'Smart Service'.
Werkvoortgang
Het initiële akkoord over de werkzaamheden vond plaats in juni 2019, wat als startdatum van het project kan worden beschouwd. Alle werkzaamheden moeten worden uitgevoerd in een 'live' omgeving met duizenden verzoeken per dag. Uiteraard was het nodig het project uit te voeren zonder de normale werking van beide systemen te onderbreken.
Daarom werd een duidelijke actieplan opgesteld en goedgekeurd, verdeeld in 4 fasen:
- voorbereiding,
- migratie,
- testen en controleren onder echte voorwaarden,
- inclusief systemen voor monitoring en toegangsbeperkingen.
Voor alle zekerheid hebben we een herstelprocedure voorzien voor het geval er zich een noodsituatie voordoet (DRP). Volgens het oorspronkelijke plan zouden de werkzaamheden niet veel tijd en middelen in beslag nemen en eind juli 2019 afgerond moeten zijn. Elke fase voorzag aan het einde in volledige testen van netwerkmogelijkheden en functionaliteit van de systemen.
De moeilijkste fase, waarin 'iets mis zou kunnen gaan', was de migratie. Aanvankelijk planden we de migratie door de virtuele machines in hun geheel over te zetten. Dit leek de logischste optie, omdat het geen extra middelen vereiste voor herconfiguratie. Wat kan eenvoudiger zijn dan vMotion?
Uiteindelijk, zoals vaak het geval is bij projecten in relatief nieuwe gebieden, gebeurde er iets onverwachts.
Aangezien elke virtuele machine 500 – 1.000 GB in beslag neemt, nam het kopiëren van zulke hoeveelheden zelfs binnen één datacenter ongeveer 3-4 uur per machine in beslag. Hierdoor pasten we niet binnen het gegeven tijdsvenster. Dit gebeurde vanwege fysieke beperkingen van het opslagsubsysteem bij de gegevensoverdracht naar vCloud.
Aangezien elke virtuele machine 500 - 1.000 GB vereist, kostte het kopiëren van dergelijke volumes, zelfs binnen één datacenter, ongeveer 3-4 uur per machine. Als gevolg hiervan slaagden we er niet in om binnen het toegewezen tijdsbestek te blijven. Dit gebeurde vanwege fysieke beperkingen van de opslaginfrastructuur bij het verplaatsen van gegevens naar vCloud.
Een bug in de gebruikte versie van vCloud maakte het onmogelijk om Storage vMotion te organiseren voor virtuele machines met verschillende schijf types, waardoor de schijven moesten worden vervangen. Uiteindelijk konden de virtuele machines worden overgezet, maar dit kostte meer tijd dan gepland.
Een tweede punt dat we niet hadden voorzien, zijn de beperkingen bij de verplaatsing van de database cluster (Failover Cluster MS SQLServer). Dit resulteerde in het feit dat we het cluster moesten omzetten naar één node en buiten de beveiligde zone moesten plaatsen.
Opmerkelijk: om nog onbekende redenen ging tijdens de migratie van de virtuele machines het toepassingscluster uit elkaar, en moest dit opnieuw worden opgebouwd.
Na de eerste poging hadden we een onverkwikkelijke toestand van de systemen, en we moesten opnieuw beginnen met het plannen en uitwerken van alternatieven.
Poging nr. 2
Na het analyseren van de fouten besefte het team dat het beter zou zijn om de infrastructuur in de beveiligde zone te dupliceren en alleen de bestanden met gegevens te kopiëren. Er werd besloten om de klant geen extra kosten te vragen voor de extra servercapaciteit die nodig was om de migratie te voltooien.
Als gevolg hiervan, toen de clusters in de beveiligde zone volledig waren gedupliceerd, verliep de migratie probleemloos.
Vervolgens moesten we alleen de netwerken van de beveiligde en onbeschermde zone scheiden. Dit bracht enkele kleine onderbrekingen in de werking met zich mee. De testfase van het gehele systeem in de beveiligde zone zonder enige bescherming kon normaal worden opgestart. Nadat we positieve statistieken over de werking van het systeem in deze modus hadden verzameld, gingen we over naar de laatste fase: het activeren van de beveiligingssystemen en het beperken van de toegang.
Een succesvolle uitkomst en een waardevolle les
Uiteindelijk is het, met gezamenlijke inspanningen samen met de klant, gelukt om aanzienlijke wijzigingen aan te brengen in de bestaande serverinfrastructuur, wat heeft geleid tot een verbeterde betrouwbaarheid en beveiliging van de opslag van persoonsgegevens, een aanzienlijke vermindering van de risico's van ongeoorloofde toegang tot deze gegevens en het verkrijgen van een certificaat voor de naleving van de opslagvereisten — een prestatie die nog niet door alle ontwikkelaars van soortgelijke software is bereikt.
Samenvattend zag het werk aan het project er als volgt uit:
- Een aparte subnet is georganiseerd;
- In totaal zijn er twee clusters gemigreerd, bestaande uit vijf virtuele machines: een failover cluster voor databases (twee virtuele machines), een Service Fabric cluster voor applicaties (drie virtuele machines);
- Er zijn instellingen voor systeembeveiliging en gegevensversleuteling uitgevoerd.
Het lijkt allemaal vrij duidelijk en logisch. In de praktijk is echter alles iets ingewikkelder. We hebben opnieuw bevestigd dat bij het werken aan elke aparte taak van dit soort een hoog niveau van aandacht voor 'detail' vereist is, wat bij nader inzien geen details zijn, maar bepalende factoren voor het succes van het hele project.
Bron: habr.com
