Selon la législation russe, toute entreprise traitant des données personnelles de ses utilisateurs en Russie devient un opérateur de PDN, que cela lui plaise ou non. Cela impose à l'entreprise un certain nombre d'obligations formelles et procédurales que toutes les entreprises ne peuvent pas ou ne souhaitent pas assumer elles-mêmes.
Comme le montre l'expérience, il est tout à fait compréhensible de ne pas vouloir le faire, car ce domaine de connaissance est encore si nouveau et peu éprouvé dans la pratique, que des difficultés et des questions se posent même aux professionnels. Aujourd'hui, nous allons parler de la manière dont nous avons réalisé un projet pour le stockage de données personnelles pour notre client et des difficultés non évidentes auxquelles nous avons été confrontés.
Comment nous avons aidé à protéger les données conformément à la loi 152-FZ
Au début de l'année 2019, nous avons été contactés par la société LLC «Smart-Service», développeur d'une plateforme de gestion des services. et d'une application d'échange de contacts .
La première solution permet d'automatiser le processus de maintenance de l'équipement dans divers domaines - de la configuration des machines à café et des climatiseurs dans les bureaux à la réparation de turbines à gaz. La seconde est un créateur en ligne pour la création de cartes de visite électroniques basées sur des codes QR.
Carte de visite en ligne myQRcards.
Les deux systèmes stockent et traitent des données d'utilisateurs classées comme «personnelles» selon la loi 152-FZ. Dans ce cas, la loi impose un certain nombre de restrictions aux systèmes de stockage de ces données personnelles afin d'assurer le niveau de protection requis et d'exclure le risque d'accès non autorisé dans le but de vol ou d'utilisation abusive.
La loi doit être respectée, mais «Smart-Service» ne prévoyait pas de développer en interne des compétences en matière de protection des PDN. Par conséquent, les services et données partagés par leurs utilisateurs ont «déménagé» chez Linxdatacenter. «Smart-Service» a transféré les capacités serveur de son environnement de travail dans une zone réseau protégée de notre data center, certifiée conformément aux exigences énoncées dans la loi 152-FZ - le soi-disant «cloud sécurisé».
COMMENT EST STRUCTURÉ LE CLOUD SÉCURISÉ
Tout système d'information traitant des données personnelles doit satisfaire à trois exigences principales :
- L'accès aux serveurs de stockage et de traitement des données doit se faire via un canal VPN avec chiffrement conformément aux normes GOST ;
- Les serveurs de stockage et de traitement des données doivent être sous surveillance constante d'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 hébergeons les ressources serveur des clients dans des zones distinctes respectant les exigences de la loi 152-FZ et aidons à obtenir une attestation de conformité.
Architecture d'une infrastructure virtuelle sécurisée pour la SARL « Smart Service ».
Progrès des travaux
L'approbation initiale des travaux a été réalisée en juin 2019, date que l'on peut considérer comme le début du projet. Tous les travaux doivent être effectués dans un environnement « actif » avec des milliers de requêtes par jour. Évidemment, il était nécessaire de réaliser le projet sans interrompre le mode de fonctionnement normal des deux systèmes.
Par conséquent, un plan d'action clair a été élaboré et approuvé, divisé en 4 étapes :
- préparation,
- migration,
- tests et vérifications en conditions réelles,
- activation des systèmes de surveillance et de restrictions d'accès.
Par précaution, nous avons prévu une procédure de récupération en cas de situation imprévue (DRP). Selon le plan initial, les travaux ne prenaient pas beaucoup de temps et de ressources et devaient s'achever en juillet 2019. Chaque étape prévoyait au final un test complet de la disponibilité réseau et de la fonctionnalité des systèmes.
L'étape la plus complexe, où quelque chose pouvait « mal se passer », était la migration. Initialement, nous avions prévu d'effectuer la migration en transférant les machines virtuelles dans leur intégralité. C'était l'option la plus logique, car elle ne nécessitait pas de ressources supplémentaires pour la reconfiguration. Quoi de plus simple que vMotion.
À l'improviste
Cependant, comme cela arrive souvent dans des projets dans un domaine relativement nouveau, ce qu'on n'attendait pas s'est produit.
Étant donné que chaque machine virtuelle occupe entre 500 et 1 000 Go, la copie de tels volumes même dans un seul centre de données a pris environ 3 à 4 heures par machine. En fin de compte, nous n'avons pas pu respecter le créneau horaire imparti. Cela s'est produit en raison des limites physiques du sous-système de disque lors du transfert des données dans vCloud.
Un bug dans la version utilisée de vCloud a empêché l'organisation du Storage vMotion pour une machine virtuelle avec différents types de disques, donc les disques ont dû être remplacés. En fin de compte, les machines virtuelles ont pu être transférées, mais cela a pris plus de temps que prévu.
Le deuxième point que nous n’avons pas prévu est la limitation du déplacement du cluster de bases de données (Failover Cluster MS SQLServer). En conséquence, nous avons dû passer le cluster en mode un nœud et le laisser en dehors de la zone protégée.
Fait intéressant : pour une raison encore incomprise, le transfert des machines virtuelles a causé une destruction du cluster d'applications, qui a dû être reconstruit.
À la suite de la première tentative, nous avons obtenu un état insatisfaisant des systèmes et avons été contraints de recommencer la planification et l'élaboration d'options.
Tentative n°2
Après avoir analysé les erreurs, l'équipe a compris qu'il serait préférable de dupliquer l'infrastructure dans la zone protégée et de ne copier que les fichiers de données. Il a été décidé de ne pas demander au client un supplément pour les capacités serveur supplémentaires qui ont dû être mises en place pour terminer la migration.
En conséquence, lorsque les clusters de la zone protégée ont été entièrement dupliqués, la migration s'est déroulée sans problème.
Ensuite, il ne restait plus qu'à séparer les réseaux de la zone protégée et de la zone non protégée. Cela a impliqué quelques interruptions mineures du service. L'étape de test de l'ensemble du système dans la zone protégée sans aucune protection a pu être lancée en mode normal. Ayant recueilli une statistique de fonctionnement positive dans ce mode, nous sommes passés à la dernière étape : l'activation des systèmes de protection et la limitation de l'accès.
Un résultat réussi et une leçon utile
En fin de compte, grâce à un effort commun avec le client, nous avons pu apporter d'importants changements à l'infrastructure serveur existante, ce qui a permis d'améliorer la fiabilité et la sécurité du stockage des données personnelles, de réduire considérablement les risques d'accès non autorisé, et d'obtenir le certificat d'attestation des exigences de stockage - une réalisation à laquelle tous les développeurs de logiciels similaires n'ont pas encore abouti.
En résumé, l'ensemble des travaux pour le projet était le suivant :
- Un sous-réseau dédié a été organisé;
- Au total, deux clusters ont été migrés, composés de cinq machines virtuelles : un cluster de bases de données en mode de basculement (deux machines virtuelles), un cluster d'applications Service Fabric (trois machines virtuelles);
- Les paramètres de protection et de chiffrement des données ont été configurés.
Cela semble clair et logique. En pratique, cependant, tout s'avère un peu plus compliqué. Nous avons de nouveau constaté que le traitement de chaque tâche de ce type nécessite un niveau de attention élevé aux «détails», qui se révèlent être des facteurs déterminants du succès de l'ensemble du projet.
Source : habr.com
