Selon les lois russes, toute entreprise qui travaille avec les données personnelles de ses utilisateurs en Russie devient un opérateur de données personnelles, qu'elle le veuille ou non. Cela lui impose un certain nombre d'obligations formelles et procédurales que toutes les entreprises ne peuvent ou ne veulent pas assumer seules.
Comme le montre la pratique, il est tout à fait vrai qu'il ne le souhaite pas, car ce domaine de connaissances est encore si nouveau et non testé dans la pratique que des difficultés et des questions se posent même pour les professionnels. Aujourd'hui, nous allons parler de la façon dont nous avons mis en œuvre un projet de stockage des données personnelles de notre client et des difficultés non évidentes que nous avons rencontrées.
Comment nous avons contribué à protéger les données sous 152-FZ
Début 2019, nous avons été contactés par Smart-Service LLC, développeur d'une plateforme de gestion de services. et applications de partage de contacts .
La première solution vous permet d'automatiser le processus de maintenance des équipements dans divers domaines - de l'installation de machines à café et de climatiseurs dans les bureaux à la réparation de turbines à gaz. Le second est un concepteur en ligne permettant de créer des cartes de visite électroniques basées sur des codes QR.
Carte de visite en ligne myQRcards.
Les deux systèmes stockent et traitent les données des utilisateurs qui relèvent de la classification « personnelle » conformément au 152-FZ. Dans ce cas, la loi impose un certain nombre de restrictions aux systèmes de stockage de ces données personnelles afin de garantir le niveau de sécurité requis et d'éliminer le risque d'accès non autorisé à des fins de vol ou d'utilisation abusive.
La loi doit être respectée, mais Smart Service n'a pas prévu de développer en son sein la compétence de protection des données personnelles. Par conséquent, les services et les données partagées par leurs utilisateurs ont été « déplacés » vers Linxdatacenter. « Smart-Service » a transféré la capacité du serveur de l'environnement de travail vers une zone réseau protégée distincte de notre centre de données, certifiée conformément aux exigences énoncées dans 152-FZ - ce qu'on appelle le « Cloud sécurisé ».
COMMENT EST CONÇU UN CLOUD SÉCURISÉ ?
Tout système d’information traitant des données personnelles doit répondre à trois exigences fondamentales :
- l'accès aux serveurs de stockage et de traitement des données doit se faire via un canal VPN avec cryptage conformément à GOST ;
- les serveurs de stockage et de traitement des données doivent être constamment surveillés par une protection antivirus pour détecter les vulnérabilités ;
- Le système de stockage doit être situé dans des réseaux isolés.
Nous plaçons les capacités des serveurs du client dans des zones séparées qui répondent aux exigences du 152-FZ et aidons à obtenir une conclusion sur la conformité.
Architecture d'infrastructure virtuelle sécurisée pour Smart Service LLC.
Cours de travail
La première approbation des travaux a été réalisée en juin 2019, date qui peut être considérée comme la date de début du projet. Tout le travail doit être effectué dans un environnement « réel » avec des milliers de demandes par jour. Bien entendu, il était nécessaire de réaliser le projet sans interrompre le fonctionnement normal des deux systèmes.
Un plan d’action clair a donc été élaboré et convenu, divisé en 4 étapes :
- préparation,
- migration,
- essais et tests en conditions réelles,
- permettant des systèmes de surveillance et des restrictions d’accès.
Par mesure de sécurité, nous avons inclus une procédure de reprise après sinistre (DRP). Selon le plan initial, les travaux n'ont pas nécessité beaucoup de temps et de ressources et devaient être achevés en juillet 2019. Chaque étape comprenait à la fin un test complet de la disponibilité du réseau et de la fonctionnalité des systèmes.
L’étape la plus difficile au cours de laquelle « quelque chose pouvait mal tourner » était la migration. Initialement, nous avions prévu de réaliser la migration en transférant des machines virtuelles entières. C'était l'option la plus logique, car elle ne nécessitait pas l'intervention de ressources supplémentaires pour la reconfiguration. Il semblerait que vMotion pourrait être plus simple.
De façon inattendue
Cependant, comme cela arrive habituellement dans les projets dans un domaine relativement nouveau, quelque chose d’inattendu s’est produit.
Étant donné que chaque machine virtuelle occupe entre 500 et 1 000 Go, la copie de tels volumes, même au sein d'un centre de données, prenait environ 3 à 4 heures par machine. En conséquence, nous n’avons pas respecté le délai imparti. Cela s'est produit en raison des limitations physiques du sous-système de disque lors du transfert de données vers vCloud.
Un bug dans la version vCloud utilisée ne permettait pas d'organiser Storage vMotion pour une machine virtuelle avec différents types de disques, il a donc fallu changer les disques. Le transfert des machines virtuelles a ainsi pu être effectué, mais cela a pris plus de temps que prévu.
Le deuxième point que nous n'avons pas prévu concerne les restrictions de déplacement du cluster de base de données (Failover Cluster MS SQLServer). En conséquence, il a fallu faire basculer le cluster pour qu'il fonctionne avec un seul nœud et le laisser en dehors de la zone protégée.
A noter : pour une raison encore floue, à la suite du transfert de machines virtuelles, le cluster d'applications s'est effondré et a dû être remonté.
À la suite de la première tentative, nous avons constaté un état des systèmes insatisfaisant et avons été obligés de recommencer à planifier et à développer des options.
Tentative #2
Après avoir travaillé sur les erreurs, l'équipe s'est rendu compte qu'il serait plus correct de dupliquer l'infrastructure dans une zone protégée et de copier uniquement les fichiers de données. Il a été décidé de ne pas exiger de paiement supplémentaire de la part du client pour la capacité de serveur supplémentaire qui devait être déployée pour achever la migration.
En conséquence, lorsque les clusters de la zone protégée ont été complètement dupliqués, la migration s'est déroulée sans problème.
Il suffisait ensuite de séparer les réseaux de zones protégées et non protégées. Il y a eu quelques perturbations mineures ici. L'étape de test de l'ensemble du système dans une zone protégée sans aucune protection a pu démarrer en mode normal. Après avoir collecté des statistiques positives sur le fonctionnement du système dans ce mode, nous sommes passés à la dernière étape : lancer les systèmes de protection et restreindre l'accès.
Résultat efficace et leçon utile
En conséquence, grâce aux efforts conjoints avec le client, il a été possible d'apporter des modifications significatives à l'infrastructure de serveur existante, ce qui a permis d'augmenter la fiabilité et la sécurité du stockage des données personnelles, de réduire considérablement les risques d'accès non autorisé à celles-ci, et obtenir un certificat de conformité aux exigences de stockage - un exploit que tout le monde n'a pas encore atteint les développeurs de logiciels similaires.
En fin de compte, le lot de travaux du projet ressemblait à ceci :
- Un sous-réseau dédié a été organisé ;
- Au total, deux clusters ont été migrés, composés de cinq machines virtuelles : cluster de base de données de basculement (deux machines virtuelles), cluster d'applications Service Fabric (trois machines virtuelles) ;
- Des systèmes de protection et de cryptage des données ont été configurés.
Tout semble clair et logique. En pratique, tout s'avère un peu plus compliqué. Nous étions une fois de plus convaincus que lorsqu'on travaille sur chaque tâche individuelle d'un tel plan, il faut accorder la plus grande attention aux « petites choses », qui s'avèrent en fait non pas de petites choses, mais des facteurs déterminants pour le succès du projet. l'ensemble du projet.
Source: habr.com