Cómo cumplir con los requisitos de 152-FZ, proteger los datos personales de nuestros clientes y no pisar nuestro rastrillo



Según las leyes rusas, cualquier empresa que trabaje con los datos personales de sus usuarios en Rusia se convierte en un operador de DP, lo quiera o no. Esto le impone una serie de obligaciones formales y de procedimiento que no todas las empresas pueden o quieren asumir de manera independiente.

Como muestra la práctica, ella realmente no quiere, porque esta área de conocimiento todavía es tan nueva y no ha sido probada en la práctica que incluso los profesionales tienen dificultades y preguntas. Hoy hablaremos sobre cómo implementamos el proyecto para almacenar datos personales para nuestros clientes y qué dificultades no obvias encontramos.

Cómo ayudamos a proteger los datos en 152-FZ


A principios de 2019, nos contactó Smart Service LLC, un desarrollador de la plataforma de administración de servicios HubEx y la aplicación de intercambio de contactos myQRcards .

La primera solución le permite automatizar el proceso de mantenimiento de equipos en una variedad de áreas, desde la instalación de cafeteras y aires acondicionados en salas de oficina hasta la reparación de turbinas de gas. El segundo es un diseñador en línea para crear tarjetas de presentación electrónicas basadas en códigos QR.


Tarjeta de visita en línea MyQRcards.

Ambos sistemas almacenan y procesan datos de usuarios que se clasifican como "personales" de acuerdo con 152-FZ. En este caso, la ley dicta una serie de restricciones en los sistemas de almacenamiento de dichos datos personales para garantizar el nivel requerido de protección y eliminar el riesgo de acceso no autorizado por robo o uso indebido.

La ley debe ser respetada, pero Smart Service no planeó desarrollar dentro de sí misma la competencia para proteger los datos personales. Por lo tanto, los servicios y datos compartidos por sus usuarios "se trasladaron" a Linxdatacenter. Smart Service transfirió las capacidades del servidor del entorno de trabajo a una zona de red protegida separada de nuestro centro de datos, certificada de acuerdo con los requisitos establecidos en 152-FZ, la llamada "Nube Protegida".

CÓMO SE UTILIZA UNA NUBE PROTEGIDA


Cualquier sistema de información que procese datos personales debe cumplir tres requisitos básicos:

  • El acceso a los servidores de almacenamiento y procesamiento de datos debe ser a través de un canal VPN con encriptación de acuerdo con GOST;
  • los servidores de almacenamiento y procesamiento deben ser monitoreados constantemente por protección antivirus para vulnerabilidades;
  • El almacenamiento debe estar ubicado en redes aisladas.

Colocamos las capacidades del servidor del cliente en zonas separadas que cumplen con los requisitos de 152- y ayudan a obtener una conclusión sobre el cumplimiento.


Arquitectura de infraestructura virtual protegida para Smart Service LLC.

Progreso


La aprobación inicial del trabajo se llevó a cabo en junio de 2019, que puede considerarse la fecha de inicio del proyecto. Todo el trabajo debe realizarse en un entorno "en vivo" con miles de solicitudes por día. Naturalmente, se requería completar el proyecto sin interrumpir el funcionamiento normal de ambos sistemas.

Por lo tanto, se elaboró ​​y acordó un plan de acción claro, dividido en 4 etapas:

  • preparación
  • migración
  • prueba y verificación en condiciones reales,
  • inclusión de sistemas de monitoreo y restricciones de acceso.

Por si acaso, hemos proporcionado un procedimiento de recuperación de contingencia (DRP). Según el plan de trabajo inicial, no tomaron mucho tiempo y recursos y se suponía que se completarían en julio de 2019. Cada una de las etapas proporcionó una prueba completa de la disponibilidad de la red y la funcionalidad del sistema al final.

La etapa más difícil en la que "algo podría salir mal" fue la migración. Inicialmente, planeamos migrar moviendo máquinas virtuales enteras. Esta era la opción más lógica, ya que no requería la participación de recursos adicionales para la reconfiguración. Parece que vMotion podría ser más simple.

Inesperadamente


Sin embargo, como suele ser el caso con los proyectos en un campo relativamente nuevo, sucedió algo que no se esperaba.

Como cada máquina virtual ocupa entre 500 y 1,000 GB, copiar tales volúmenes incluso en el marco de un solo centro de datos tomó aproximadamente 3-4 horas por máquina. Como resultado, no cumplimos con la ventana de tiempo asignada. Esto se debió a las limitaciones físicas del subsistema de disco al transferir datos a vCloud.

El error de la versión vCloud utilizada no permitió que Storage vMotion se organizara en relación con una máquina virtual con diferentes tipos de discos, por lo que los discos tuvieron que cambiarse. Como resultado, resultó transferir las máquinas virtuales, pero tardó más de lo planeado.

El segundo punto que no preveíamos es las restricciones para mover el clúster de la base de datos (Failover Cluster MS SQLServer). Como resultado, tuvimos que transferir el clúster para trabajar con un nodo y dejarlo fuera de la zona protegida.

Es notable: por alguna razón, como resultado de la migración de máquinas virtuales, el clúster de aplicaciones se desmoronó y tuvo que volverse a montar.

Como resultado del primer intento, obtuvimos el estado insatisfactorio de los sistemas y nos vimos obligados a retomar la planificación y el desarrollo de opciones.

Intento número 2


Después de trabajar en los errores, el equipo se dio cuenta de que sería más correcto duplicar la infraestructura en la zona protegida y copiar solo los archivos de datos. Se decidió no requerir recargos del cliente por las capacidades adicionales del servidor que tuvieron que implementarse para completar la migración.

Como resultado, cuando los grupos en la zona protegida se duplicaron por completo, la migración pasó sin problemas.

Además, solo era necesario separar las redes de las zonas protegidas y no protegidas. Hubo algunas interrupciones menores en el trabajo. La fase de prueba de todo el sistema en el área protegida sin ninguna protección pudo comenzar en modo normal. Después de haber recopilado estadísticas positivas sobre el sistema en este modo, pasamos a la última etapa: iniciar sistemas de seguridad y restringir el acceso.

Resultado efectivo y lección útil




Como resultado, los esfuerzos conjuntos junto con el cliente lograron realizar cambios significativos en la infraestructura del servidor existente, lo que permitió aumentar la confiabilidad y seguridad del almacenamiento PD, reducir significativamente los riesgos de acceso no autorizado a ellos y obtener un certificado de cumplimiento de los requisitos de almacenamiento, un logro que no todos han alcanzado Desarrolladores de software similares.

En resumen, el paquete de trabajo del proyecto se veía así:

  1. Se organiza una subred dedicada;
  2. En total, se migraron dos clústeres que constan de cinco máquinas virtuales: clúster de base de datos de conmutación por error (dos máquinas virtuales), clúster de aplicaciones de Service Fabric (tres máquinas virtuales);
  3. Se han realizado ajustes para la protección de datos y los sistemas de cifrado.

Todo parece ser claro y lógico. En la práctica, todo resulta ser un poco más complicado. Una vez más, estábamos convencidos de que cuando se trabaja con cada tarea individual de dicho plan, se requiere el más alto nivel de atención a las "bagatelas", que en realidad no son bagatelas, sino factores determinantes para el éxito de todo el proyecto.

Source: https://habr.com/ru/post/480086/


All Articles