Volgens de Russische wetgeving wordt elk bedrijf dat met de persoonlijke gegevens van zijn gebruikers in Rusland werkt, een exploitant van persoonlijke gegevens, of het dat nu wil of niet. Dit legt haar een aantal formele en procedurele verplichtingen op die niet ieder bedrijf alleen kan of wil dragen.
Zoals de praktijk laat zien, is het volkomen terecht dat hij dat niet wil, omdat dit kennisgebied nog zo nieuw is en in de praktijk nog niet is getest dat er zelfs voor professionals moeilijkheden en vragen rijzen. Vandaag zullen we praten over hoe we een project hebben geïmplementeerd om persoonlijke gegevens voor onze klant op te slaan en welke niet voor de hand liggende problemen we tegenkwamen.
Hoe we hebben geholpen gegevens te beschermen onder 152-FZ
Begin 2019 werden we gecontacteerd door Smart-Service LLC, een ontwikkelaar van een platform voor servicemanagement en toepassingen voor het delen van contacten .
Met de eerste oplossing kunt u het proces van apparatuuronderhoud op verschillende gebieden automatiseren - van het plaatsen van koffiemachines en airconditioners in kantoorgebouwen tot het repareren van gasturbines. De tweede is een online ontwerper voor het maken van elektronische visitekaartjes op basis van QR-codes.
Online visitekaartje myQRcards.
Beide systemen slaan gebruikersgegevens op en verwerken deze die vallen onder de classificatie ‘persoonlijk’ conform 152-FZ. In dit geval legt de wet een aantal beperkingen op aan de opslagsystemen voor dergelijke persoonlijke gegevens om het vereiste beveiligingsniveau te garanderen en het risico van ongeoorloofde toegang met het oog op diefstal of misbruik te elimineren.
De wet moet worden nageleefd, maar Smart Service was niet van plan om binnen zichzelf de bevoegdheid te ontwikkelen om persoonsgegevens te beschermen. Daarom ‘verhuisden’ de diensten en gegevens die door hun gebruikers werden gedeeld naar Linxdatacenter. “Smart-Service” heeft de servercapaciteit van de werkomgeving overgebracht naar een aparte beschermde netwerkzone van ons datacenter, gecertificeerd volgens de eisen gesteld in 152-FZ - de zogenaamde “Secure Cloud”.
HOE WORDT EEN VEILIGE CLOUD ONTWORPEN?
Elk informatiesysteem dat persoonsgegevens verwerkt, moet aan drie basisvereisten voldoen:
- toegang tot servers voor gegevensopslag en -verwerking moet plaatsvinden via een VPN-kanaal met codering in overeenstemming met GOST;
- servers voor gegevensopslag en -verwerking moeten voortdurend worden gecontroleerd door antivirusbescherming op kwetsbaarheden;
- Het opslagsysteem moet zich in geïsoleerde netwerken bevinden.
Wij plaatsen de servercapaciteiten van de klant in aparte ruimtes die voldoen aan de eisen van 152-FZ en helpen bij het verkrijgen van een conclusie over de naleving.
Architectuur van veilige virtuele infrastructuur voor Smart Service LLC.
voortgang van de werkzaamheden
De eerste goedkeuring van de werkzaamheden vond plaats in juni 2019, wat kan worden beschouwd als de startdatum van het project. Al het werk moet worden gedaan in een ‘live’ omgeving met duizenden verzoeken per dag. Uiteraard was het noodzakelijk om het project te voltooien zonder de normale werking van beide systemen te onderbreken.
Daarom werd er een duidelijk actieplan opgesteld en overeengekomen, verdeeld in 4 fases:
- voorbereiding,
- migratie,
- testen en testen in reële omstandigheden,
- het mogelijk maken van monitoringsystemen en toegangsbeperkingen.
Voor de zekerheid hebben we een Disaster Recovery Procedure (DRP) opgenomen. Volgens het oorspronkelijke plan vergden de werkzaamheden niet veel tijd en middelen en zouden ze in juli 2019 voltooid moeten zijn. Elke fase omvatte aan het einde een volledige test van de netwerkbeschikbaarheid en functionaliteit van de systemen.
De moeilijkste fase waarin ‘er iets mis kon gaan’ was migratie. Aanvankelijk waren we van plan de migratie uit te voeren door volledige virtuele machines over te zetten. Dit was de meest logische optie, omdat er geen extra middelen voor herconfiguratie nodig waren. Het lijkt erop dat vMotion eenvoudiger zou kunnen zijn.
Onverwacht
Maar zoals meestal gebeurt bij projecten op een relatief nieuw terrein, gebeurde er iets onverwachts.
Omdat elke virtuele machine 500 - 1 GB in beslag neemt, duurde het kopiëren van dergelijke volumes, zelfs binnen één datacenter, ongeveer 000-3 uur per machine. Als gevolg hiervan hebben we het toegewezen tijdvenster niet gehaald. Dit gebeurde vanwege fysieke beperkingen van het schijfsubsysteem bij het overbrengen van gegevens naar vCloud.
Door een bug in de gebruikte vCloud-versie kon Storage vMotion niet worden georganiseerd voor een virtuele machine met verschillende soorten schijven, dus moesten de schijven worden vervangen. Hierdoor was het mogelijk om de virtuele machines over te zetten, maar dit duurde langer dan gepland.
Het tweede punt waar we niet in hebben voorzien zijn de beperkingen op het verplaatsen van het databasecluster (Failover Cluster MS SQLServer). Als gevolg hiervan was het noodzakelijk om het cluster over te schakelen naar één knooppunt en dit buiten de beschermde zone te laten.
Opmerkelijk: om nog onduidelijke reden viel het applicatiecluster als gevolg van de overdracht van virtuele machines uit elkaar en moest opnieuw in elkaar worden gezet.
Als resultaat van de eerste poging kregen we een onbevredigende staat van de systemen en werden we gedwongen opnieuw te beginnen met het plannen en ontwikkelen van opties.
Poging #2
Nadat ze aan de fouten hadden gewerkt, realiseerde het team zich dat het juister zou zijn om de infrastructuur in een beschermd gebied te dupliceren en alleen de gegevensbestanden te kopiëren. Er werd besloten om geen extra betaling van de klant te vragen voor extra servercapaciteit die moest worden ingezet om de migratie te voltooien.
Als gevolg hiervan verliep de migratie zonder problemen toen de clusters in het beschermde gebied volledig werden gedupliceerd.
Vervolgens was het alleen nodig om de netwerken van beschermde en onbeschermde zones te scheiden. Hier waren enkele kleine verstoringen. De fase van het testen van het hele systeem in een beschermd gebied zonder enige bescherming kon in de normale modus beginnen. Nadat we positieve statistieken hadden verzameld over de werking van het systeem in deze modus, gingen we verder met de laatste fase: het lanceren van beveiligingssystemen en het beperken van de toegang.
Effectief resultaat en nuttige les
Als gevolg hiervan was het door gezamenlijke inspanningen met de klant mogelijk om aanzienlijke wijzigingen aan te brengen in de bestaande serverinfrastructuur, waardoor het mogelijk werd de betrouwbaarheid en veiligheid van de opslag van persoonlijke gegevens te vergroten, de risico's van ongeoorloofde toegang daartoe aanzienlijk te verminderen, en een certificaat verkrijgen van overeenstemming met de opslagvereisten - een prestatie die nog niet iedereen heeft behaald door ontwikkelaars van vergelijkbare software.
Het komt erop neer dat het werkpakket voor het project er als volgt uitzag:
- Er is een speciaal subnet georganiseerd;
- In totaal zijn er twee clusters gemigreerd, bestaande uit vijf virtuele machines: Failover-databasecluster (twee virtuele machines), Service Fabric-applicatiecluster (drie virtuele machines);
- Gegevensbeschermings- en encryptiesystemen zijn geconfigureerd.
Alles lijkt duidelijk en logisch. In de praktijk blijkt alles iets ingewikkelder te zijn. We waren er opnieuw van overtuigd dat bij het werken met elke individuele taak van een dergelijk plan de hoogste mate van aandacht vereist is voor de ‘kleine dingen’, die in feite geen kleine dingen blijken te zijn, maar de bepalende factoren voor het succes van het gehele project.
Bron: www.habr.com