Selon les lois russes, toute entreprise qui travaille avec les données personnelles de ses utilisateurs en Russie devient un opérateur PD, qu'elle le veuille ou non. Cela lui impose un certain nombre d'obligations formelles et procédurales que toutes les entreprises ne peuvent pas ou ne veulent pas assumer de manière indépendante.
Comme le montre la pratique, elle ne le veut pas vraiment, car ce domaine de connaissances est encore si nouveau et non testé dans la pratique que même les professionnels ont des difficultés et des questions. Aujourd'hui, nous allons parler de la façon dont nous avons mis en œuvre le projet de stockage des données personnelles pour notre client et des difficultés non évidentes que nous avons rencontrées.
Comment nous avons aidé à protéger les données sur 152-FZ
Début 2019, nous avons été contactés par Smart Service LLC, développeur de la
plateforme de gestion de services
HubEx et de l'
application d' échange de contacts
myQRcards .
La première solution vous permet d'automatiser le processus d'entretien de l'équipement dans une variété de 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 pour 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 utilisateur qui relèvent de la classification des «données personnelles» conformément à 152-FZ. Dans ce cas, la loi impose un certain nombre de restrictions sur les systèmes de stockage de ces données personnelles afin d'assurer le niveau requis de leur sécurité et d'éliminer le risque d'accès non autorisé pour vol ou abus.
La loi doit être respectée, mais Smart Service n'a pas prévu de développer en soi la compétence de protection des données personnelles. Par conséquent, les services et les données partagés par leurs utilisateurs se sont «déplacés» vers Linxdatacenter. Smart Service a transféré les capacités du serveur de l'environnement de travail vers une zone de réseau protégée distincte de notre centre de données, certifiée conformément aux exigences énoncées dans 152-FZ - le soi-disant «Cloud protégé».
COMMENT UN NUAGE PROTÉGÉ EST UTILISÉ
Tout système d'information qui traite des données personnelles doit satisfaire à 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 selon GOST;
- les serveurs de stockage et de traitement doivent être surveillés en permanence par une protection antivirus contre les vulnérabilités;
- Le stockage doit être situé dans des réseaux isolés.
Nous plaçons les capacités du serveur du client dans des zones distinctes qui répondent aux exigences de 152- et aidons à obtenir une conclusion sur la conformité.
Architecture d'infrastructure virtuelle protégée pour Smart Service LLC.Progrès
L'approbation initiale des travaux a été effectuée en juin 2019, ce qui peut être considéré comme la date de début du projet. Tout le travail doit être effectué dans un environnement «en direct» avec des milliers de demandes par jour. Naturellement, il était nécessaire de terminer le projet sans interrompre le 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
- test et vérification en conditions réelles,
- inclusion de systèmes de surveillance et de restrictions d'accès.
Au cas où, nous avons prévu une procédure de récupération d'urgence (DRP). Selon le plan de travail initial, ils ne prenaient pas beaucoup de temps et de ressources et devaient être achevés en juillet 2019. Chacune des étapes prévoyait un test complet de la disponibilité du réseau et de la fonctionnalité du système à la fin.
L'étape la plus difficile à laquelle «quelque chose pourrait mal tourner» a été la migration. Initialement, nous avions prévu de migrer en déplaçant des machines virtuelles entières. C'était l'option la plus logique, car elle ne nécessitait pas la participation de ressources supplémentaires pour la reconfiguration. Il semblerait que vMotion pourrait être plus simple.
De façon inattendue
Cependant, comme c'est généralement le cas pour les projets dans un domaine relativement nouveau, quelque chose qui n'était pas attendu s'est produit.
Étant donné que chaque machine virtuelle occupe 500 à 1 000 Go, la copie de tels volumes, même dans le cadre d'un centre de données unique, a pris environ 3 à 4 heures par machine. Par conséquent, nous n'avons pas respecté la fenêtre de temps allouée. Cela était dû aux limitations physiques du sous-système de disque lors du transfert de données vers vCloud.
Le bogue de la version vCloud utilisée ne permettait pas d'organiser Storage vMotion par rapport à une machine virtuelle avec différents types de disques, donc les disques devaient être changés. En conséquence, il s'est avéré transférer les machines virtuelles, mais cela a pris plus de temps que prévu.
Le deuxième point que nous n'avions pas prévu concerne les restrictions de déplacement du cluster de base de données (Cluster de basculement MS SQLServer). En conséquence, nous avons dû transférer le cluster pour travailler avec un nœud et le laisser en dehors de la zone protégée.
Il est à noter: pour une raison quelconque, à la suite de la migration des machines virtuelles, le cluster d'applications s'est effondré et a dû être remonté.
À la suite de la première tentative, nous avons obtenu l'état insatisfaisant des systèmes et avons été contraints de reprendre la planification et le développement des options.
Tentative numéro 2
Après avoir travaillé sur les erreurs, l'équipe s'est rendu compte qu'il serait plus correct de dupliquer l'infrastructure dans la zone protégée et de copier uniquement les fichiers de données. Il a été décidé de ne pas exiger de surcharges du client pour les capacités de serveur supplémentaires qui devaient être déployées pour terminer la migration.
Par conséquent, 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.
De plus, il était seulement nécessaire de séparer les réseaux des zones protégées et non protégées. Il y a eu quelques petites interruptions de travail. La phase de test de l'ensemble du système dans la zone protégée sans aucune protection a pu démarrer en mode normal. Après avoir collecté des statistiques positives sur le système dans ce mode, nous sommes passés à la dernière étape: lancer des systèmes de sécurité et restreindre l'accès.
Résultat efficace et leçon utile
En conséquence, avec le client, il a été possible d'apporter des modifications importantes à l'infrastructure de serveur existante, ce qui a permis d'augmenter la fiabilité et la sécurité du stockage PD, de réduire considérablement les risques d'accès non autorisé à ces derniers, d'obtenir un certificat de satisfaction des exigences de stockage - une réalisation qui n'a pas encore été atteinte par tous développeurs de logiciels similaires.
En fin de compte, le lot de travaux du projet ressemblait à ceci:
- Un sous-réseau dédié est organisé;
- Au total, deux clusters comprenant cinq machines virtuelles ont été migrés: cluster de base de données de basculement (deux machines virtuelles), cluster d'applications Service Fabric (trois machines virtuelles);
- Les paramètres des systèmes de protection et de cryptage des données ont été définis.
Tout semble clair et logique. En pratique, tout se révèle un peu plus compliqué. Une fois de plus, nous étions convaincus qu'en travaillant avec chaque tâche individuelle d'un tel plan, le plus haut niveau d'attention aux «bagatelles» est requis, qui en réalité ne se révèle pas être des bagatelles, mais des facteurs déterminants pour la réussite de l'ensemble du projet.