Según la legislación rusa, cualquier empresa que maneje datos personales de sus usuarios en Rusia se convierte en un operador de PDn, quiera o no. Esto le impone una serie de obligaciones formales y procedimentales que no todos los negocios pueden o quieren asumir por sí solos.
Como muestra la práctica, es completamente razonable no querer hacerlo, ya que este campo de conocimiento es aún tan nuevo y poco probado que surgen dificultades y preguntas incluso entre profesionales. Hoy hablaremos sobre cómo implementamos un proyecto para el almacenamiento de datos personales para nuestro cliente y con qué dificultades no evidentes nos encontramos.
Cómo ayudamos a proteger los datos según la Ley 152-FZ
A principios de 2019, nos contactó la empresa LLC «Smart-Service», desarrolladora de una plataforma para la gestión del servicio técnico. y una aplicación para el intercambio de contactos. .
La primera solución permite automatizar el proceso de mantenimiento de equipos en diversas áreas, desde la configuración de cafeteras y aires acondicionados en oficinas hasta la reparación de turbinas de gas. La segunda es un constructor en línea para crear tarjetas de presentación electrónicas basadas en códigos QR.
Tarjeta de presentación en línea myQRcards.
Ambos sistemas almacenan y procesan datos de usuarios que caen bajo la clasificación de «personales» de acuerdo con la Ley 152-FZ. En este caso, la ley impone una serie de restricciones a los sistemas de almacenamiento de tales datos personales para garantizar el nivel de protección requerido y eliminar el riesgo de acceso no autorizado con el fin de robar o utilizar indebidamente esta información.
La ley debe ser cumplida, pero «Smart-Service» no planeaba desarrollar internamente competencias en protección de PDn. Por lo tanto, los servicios y datos compartidos por sus usuarios se «trasladaron» a Linxdatacenter. «Smart-Service» trasladó la capacidad del servidor del entorno operativo a una zona de red protegida de nuestro centro de datos, acreditada de acuerdo con los requisitos establecidos en la Ley 152-FZ, lo que se conoce como «Nube Protegida».
CÓMO FUNCIONA LA NUBE PROTEGIDA
Cualquier sistema de información que procese datos personales debe cumplir con tres requisitos principales:
- El acceso a los servidores de almacenamiento y procesamiento de datos debe realizarse a través de un canal VPN con cifrado de acuerdo con la norma GOST;
- Los servidores de almacenamiento y procesamiento de datos deben estar bajo monitoreo constante con protección antivirus para detectar vulnerabilidades;
- El sistema de almacenamiento debe estar ubicado en redes aisladas.
Colocamos la capacidad de servidor del cliente en zonas separadas que cumplen con los requisitos de la Ley 152-FZ y ayudamos a obtener una conclusión de conformidad.
Arquitectura de infraestructura virtual segura para LLC 'Smart Service'.
Progreso del trabajo
La aprobación inicial del trabajo se llevó a cabo en junio de 2019, que se puede considerar la fecha de inicio del proyecto. Todos los trabajos deben realizarse en un entorno 'en vivo' con miles de solicitudes al día. Naturalmente, se requería llevar a cabo el proyecto sin interrumpir el funcionamiento habitual de ambos sistemas.
Por lo tanto, se elaboró y aprobó un plan de acción claro, dividido en 4 etapas:
- preparación,
- migración,
- pruebas y verificación en condiciones reales,
- incorporación de sistemas de monitoreo y restricción de acceso.
Por si acaso, previmos un procedimiento de recuperación en caso de una situación imprevista (DRP). Según el plan inicial, el trabajo no requería mucho tiempo ni recursos y debería haberse completado en julio de 2019. Cada etapa incluía al final una prueba completa de la accesibilidad de la red y la funcionalidad de los sistemas.
La etapa más complicada, en la que podría 'salir algo mal', fue la migración. Inicialmente, planeamos realizar la migración trasladando las máquinas virtuales en su totalidad. Esta era la opción más lógica, ya que no requería la implicación de recursos adicionales para la reconfiguración. Parecería que no podría ser más sencillo que vMotion.
De repente,
Sin embargo, como suele suceder en proyectos en un área relativamente nueva, ocurrió lo inesperado.
Dado que cada máquina virtual ocupa entre 500 y 1,000 GB, copiar tales volúmenes incluso dentro de un solo centro de datos tomó alrededor de 3-4 horas por cada máquina. Como resultado, no cumplimos con la ventana de tiempo asignada. Esto ocurrió debido a las limitaciones físicas del subsistema de disco al transferir datos a vCloud.
Un bug de la versión utilizada de vCloud impidió realizar Storage vMotion para la máquina virtual con diferentes tipos de discos, por lo que se tuvo que cambiar los discos. Como resultado, se logró trasladar las máquinas virtuales, pero esto tomó más tiempo del planeado.
Otro aspecto que no habíamos previsto son las limitaciones en el movimiento del clúster de bases de datos (Failover Cluster MS SQLServer). Como resultado, fue necesario trasladar el clúster a funcionar con un solo nodo y dejarlo fuera de la zona protegida.
Es notable que, por razones aún no claras, el clúster de aplicaciones se desintegró como resultado de la transferencia de las máquinas virtuales, y tuvimos que reconstruirlo.
A raíz del primer intento, obtuvimos un estado insatisfactorio de los sistemas y nos vimos obligados a replantear la planificación y trabajar en diferentes opciones.
Intento número 2
Tras revisar los errores, el equipo entendió que lo más adecuado sería duplicar la infraestructura en la zona protegida y copiar solo los archivos de datos. Se tomó la decisión de no exigir al cliente un pago adicional por los recursos del servidor que fueron necesarios para completar la migración.
Como resultado, cuando los clústeres en la zona protegida fueron completamente duplicados, la migración se realizó sin problemas.
A continuación, solo era necesario separar las redes de la zona protegida y la no protegida. Aquí hubo solo algunas interrupciones menores en el funcionamiento. La fase de prueba de todo el sistema en la zona protegida sin ninguna defensa se pudo llevar a cabo con normalidad. Al reunir estadísticas positivas sobre el rendimiento del sistema en tal modo, pasamos a la última fase: el lanzamiento de los sistemas de protección y la restricción de acceso.
Resultado exitoso y lección valiosa
Al final, con el esfuerzo conjunto del cliente se lograron realizar cambios significativos en la infraestructura del servidor existente, lo que permitió aumentar la fiabilidad y seguridad del almacenamiento de datos personales, reducir significativamente los riesgos de acceso no autorizado a ellos, y obtener el certificado de cumplimiento de los requisitos de almacenamiento, un logro que aún no ha alcanzado todos los desarrolladores de software similar.
En resumen, el conjunto de trabajos del proyecto fue el siguiente:
- Se organizó una subred dedicada;
- Se han migrado un total de dos clústeres compuestos por cinco máquinas virtuales: un clúster de base de datos de failover (dos máquinas virtuales), un clúster de aplicaciones de Service Fabric (tres máquinas virtuales);
- Se han realizado configuraciones para los sistemas de protección y cifrado de datos.
Parece que todo está claro y lógico. Sin embargo, en la práctica, resulta ser un poco más complicado. Hemos comprobado una vez más que al trabajar con cada tarea individual de este tipo se requiere un nivel excepcional de atención a los "detalles", que, al final, se revelan como factores determinantes para el éxito de todo el proyecto.
Fuente: habr.com
