Contraseñas conformes al RGPD: Dónde viven sus datos

Un rollo de documento azul claro rodeado por un anillo blanco brillante sobre un fondo azul. Un sello azul oscuro se superpone al rollo, mostrando «GDPR» en blanco rodeado de seis estrellas amarillas

El Reglamento General de Protección de Datos (RGPD), la ley de protección de datos de la UE, exige un mecanismo de transferencia lícito para enviar datos personales fuera del Espacio Económico Europeo (EEE, la UE más Islandia, Liechtenstein y Noruega), y medidas de seguridad adecuadas al riesgo. Para una gestión de contraseñas conforme al RGPD, es necesario saber en qué lugares existen los datos de las credenciales y disponer de pruebas para cada uno de ellos.

Sus credenciales pueden almacenarse en un centro de datos de Fráncfort y, aun así, quedar sujetas a una orden judicial extranjera si el proveedor está sometido a una jurisdicción ajena a la UE. Una etiqueta «alojado en la UE» tampoco dice nada sobre dónde están las copias de seguridad. Este artículo presenta el mapa de seis zonas de datos de credenciales: los lugares donde un gestor de contraseñas empresarial guarda datos, el artículo del RGPD que activa cada uno y las pruebas que debe conservar. Termina con un paquete de evidencias de 8 puntos que puede comprobar antes de una auditoría.

Puntos clave

El RGPD regula la salida de datos personales del EEE, y cada transferencia necesita un mecanismo lícito.
Una credencial almacenada suele identificar a un empleado, por lo que es un dato personal. El cifrado no cambia eso.
Los datos de las credenciales se reparten en seis zonas: el contenido de la bóveda, el material de claves, los datos de servicio, las copias de seguridad y réplicas, las cachés de los clientes y los subencargados. Cada zona tiene su propia obligación y su propia evidencia.
Si un proveedor trata alguna de las zonas, debe firmar un acuerdo de tratamiento de datos (DPA), un contrato que establece lo que puede hacer con sus datos.
Cuando aloja el sistema usted mismo, asume las copias de seguridad, la recuperación de claves y el mantenimiento de registros que, de otro modo, gestionaría un proveedor.
Su registro de auditoría muestra quién abrió cada credencial y cuándo, lo que ayuda a delimitar el alcance de una vulneración y a decidir si corresponde la notificación de 72 horas.

Qué exige la gestión de contraseñas conforme al RGPD

El RGPD exige que los datos personales se procesen de forma segura, que la protección de datos se integre desde el diseño y que se apliquen medidas proporcionales al riesgo.

Una gestión de contraseñas conforme al RGPD significa poder demostrar que los datos de las credenciales están cifrados, que solo pueden acceder a ellos las personas que los necesitan, que quedan registrados y que están cubiertos por los contratos y registros adecuados, sea donde sea que se almacenen.

La ley fija el resultado (artículos 5(1)(f), 25 y 32). Usted elige los controles y demuestra que funcionan (artículo 5(2)). En la práctica, esto se traduce en cinco requisitos:

Cifre las credenciales almacenadas. El artículo 32(1)(a) cita «la seudonimización y el cifrado de datos personales» como una medida adecuada.
Limite el acceso por rol (RBAC). Cada persona inicia sesión con su propia cuenta y solo ve lo que su trabajo requiere, incluso cuando la credencial que abre es compartida. Esto es protección de datos desde el diseño (artículo 25) aplicada al acceso.
Mantenga el servicio disponible y probado. El artículo 32(1)(b) a (d) cubre la resiliencia, la restauración del acceso tras un incidente y las pruebas periódicas de sus medidas.
Registre quién abrió qué. Un registro de accesos muestra qué credenciales se consultaron y cuándo. Es la evidencia que necesita para valorar si una vulneración afectó a datos personales (artículo 33).
Documente cada lugar donde residen los datos. Esto implica un registro de tratamiento, un contrato con cada tercero que trate los datos y un mecanismo lícito para cualquier transferencia fuera del EEE.

Estas obligaciones alcanzan a las contraseñas por dos motivos. Un registro de credenciales suele identificar a un empleado o estar vinculado a uno, lo que lo convierte en un dato personal (artículo 4(1): cualquier información relativa a una persona identificable). Las credenciales también dan acceso a otros sistemas, como RR. HH., CRM y bases de datos de clientes, donde se almacenan datos personales. El artículo 32(2) exige evaluar el riesgo de acceso no autorizado a datos personales, por lo que una vulneración del gestor de contraseñas es una vía de entrada a todos los sistemas que desbloquea. El cifrado reduce el riesgo, pero no excluye el registro del ámbito de aplicación.

Su organización es el responsable del tratamiento de la bóveda, la parte que decide por qué y cómo se usan los datos de las credenciales. Un proveedor o proveedor de alojamiento que lo opera o lo respalda siguiendo sus instrucciones es un encargado del tratamiento, y el artículo 28 exige un contrato con él. El artículo 30 exige mantener un registro de actividades de tratamiento (RoPA) que recoja los destinatarios, las ubicaciones y las transferencias de este tratamiento. Encontrar esas ubicaciones es la primera tarea.

Residencia, soberanía y jurisdicción son tres cosas distintas

La residencia de los datos es el lugar donde se almacenan físicamente. La soberanía de los datos significa que los datos están sujetos a las leyes y al control legal de un país determinado. La jurisdicción es qué tribunales y autoridades pueden emitir órdenes contra la empresa del proveedor. Un proveedor sujeto a la legislación de EE. UU. puede almacenar su bóveda en Alemania y, aun así, recibir requerimientos legales estadounidenses.

Término	Qué indica	Qué deja abierto
Residencia	Qué país alberga los servidores	Qué leyes pueden alcanzar los datos
Soberanía	Las leyes de qué país rigen los datos	Si una autoridad extranjera puede seguir alcanzando al proveedor
Jurisdicción	Qué autoridades pueden ordenar actuar al proveedor	Dónde se almacenan sus datos

La CLOUD Act permite a las autoridades estadounidenses exigir a los proveedores de servicios de comunicación electrónica o de computación remota sujetos a la jurisdicción de EE. UU. que entreguen los datos que posean, custodien o controlen, incluso cuando estén almacenados en el extranjero. Por tanto, un proveedor que sea una empresa estadounidense o que tenga una matriz estadounidense puede enfrentarse a este tipo de requerimientos aunque su bóveda esté en una región de la UE. Si un proveedor concreto queda sujeto a esta ley es una cuestión para su equipo legal.

El RGPD no contiene una regla general de localización de datos. Regula las transferencias a terceros países en el capítulo V (artículos 44 a 50), y el acceso remoto desde fuera del EEE, como el soporte del proveedor, puede considerarse una transferencia. Algunas normas nacionales o sectoriales añaden requisitos de localización propios, así que compruebe las que se aplican en su caso.

Transferencias fuera del EEE: Qué mecanismos se aplican

El capítulo V del RGPD exige un mecanismo de transferencia lícito y garantías que se mantengan en el país de destino. El acceso remoto de soporte desde fuera del EEE a una bóveda de contraseñas alojada dentro de él cuenta como una transferencia, por lo que la región de alojamiento por sí sola no resuelve la cuestión. Existen tres vías, y cada una se aplica a una situación distinta.

Decisión de adecuación (artículo 45). La Comisión Europea ha determinado que la protección del país de destino es equivalente. La decisión del Marco de Privacidad de Datos UE-EE. UU. del 10 de julio de 2023 solo cubre a las empresas estadounidenses autocertificadas, así que compruebe si el proveedor figura en la lista del marco. Marcos anteriores entre la UE y EE. UU. fueron anulados por los tribunales, y el actual también ha sido impugnado, por lo que conviene mantener las cláusulas contractuales tipo como respaldo en el DPA.
Garantías adecuadas (artículo 46). Normalmente, cláusulas contractuales tipo (SCC), modelos de contrato aprobados por la Comisión, junto con una evaluación de impacto de la transferencia (TIA). La TIA comprueba si la legislación del país de destino permite a las autoridades acceder a los datos. Se deriva de la sentencia Schrems II y de las Recomendaciones 01/2020 del Comité Europeo de Protección de Datos (CEPD).
Excepciones (artículo 49). Excepciones limitadas, como el consentimiento explícito tras informar al interesado de los riesgos. Son adecuadas para transferencias puntuales y no amparan el tratamiento habitual por parte de un proveedor.

Alojar los datos en una región de la UE reduce el riesgo, pero no lo elimina. El personal de soporte fuera del EEE, los metadatos tratados en otro lugar y una matriz fuera del EEE con acceso pueden, cada uno, generar una transferencia. La capacidad de una autoridad extranjera para ordenar a una matriz que divulgue datos es un riesgo de jurisdicción distinto (véase el apartado de residencia anterior). Trate la región como un factor más en su TIA, no como su conclusión.

El mapa de seis zonas de datos de credenciales

El mapa de seis zonas de datos de credenciales divide un gestor de contraseñas empresarial en seis lugares donde existen datos de credenciales. Cada zona puede estar en un país distinto y conlleva su propia obligación bajo el RGPD, por lo que comprobar solo «el servidor» deja fuera copias de las que usted es responsable.

Zona	Significado	Obligación del RGPD
1. Credenciales almacenadas	Los inicios de sesión, notas y archivos guardados	Art. 32(1)(a), cifrado
2. Material de claves	Las claves que las desbloquean	Art. 32(1)(a), control de claves
3. Datos de servicio	Registros de quién usó el sistema y cuándo	Art. 30, art. 33
4. Copias de seguridad y réplicas	Copias almacenadas y activas en otros servidores	Art. 28(3)(g), art. 32(1)(c)
5. Cachés de los clientes	Copias en los dispositivos de los usuarios	Art. 32
6. Subencargados	Los proveedores del fabricante y el acceso de soporte	Art. 28(2), 28(4), capítulo V

Un gestor de contraseñas es un sistema de copias. Usted conserva algunas, el proveedor conserva otras, y los proveedores del proveedor conservan el resto. Qué copias quedan en sus manos depende del modelo de despliegue. En un despliegue autoalojado, usted es el operador de todas las zonas, por lo que cada pregunta siguiente se aplica a sus propios equipos y proveedores de alojamiento en lugar de a un proveedor externo.

Cada zona también activa una obligación distinta. Las copias de seguridad generan obligaciones de eliminación al finalizar el contrato (artículo 28(3)(g)), y los proveedores generan obligaciones que deben trasladarse a lo largo de la cadena (artículo 28(4)). Los seis apartados siguientes tratan cada zona y qué pedir.

Zona 1: Credenciales almacenadas

Las credenciales almacenadas son el contenido que guardan los usuarios: inicios de sesión, notas, archivos adjuntos y los secretos que hay detrás de los códigos de un solo uso. Con el cifrado del lado del cliente, llegan al servidor como texto cifrado, datos ilegibles sin la clave. Una copia robada de la base de datos solo expone entonces secretos ilegibles, siempre que la clave que desbloquea la clave privada cifrada permanezca en el dispositivo del usuario (véase la zona 2).

Las credenciales cifradas siguen siendo datos personales cuando se refieren a una persona identificable, por lo que la zona 1 sigue dentro del ámbito de aplicación. El artículo 32(1)(a) cita el cifrado como ejemplo de medida adecuada, y reduce el riesgo. En la entrada de su RoPA para el gestor de contraseñas, anote la ubicación de esta zona y el método de cifrado.

Los nombres de los registros, la estructura de carpetas y los metadatos de auditoría se almacenan por separado y pertenecen a la zona 3. Asígneles su propia línea en el RoPA con la misma ubicación y los mismos detalles de acceso.

Zona 2: Material de claves

El material de claves es el conjunto de claves criptográficas que desbloquean las credenciales almacenadas. Quien posea las claves puede leer los datos, estén donde estén el texto cifrado, por lo que la ubicación de las claves y quién las posee importan tanto como la ubicación del servidor. El artículo 32(1)(a) solo considera el cifrado una medida adecuada cuando las claves se controlan con el mismo cuidado que los datos.

La cadena recorre la contraseña maestra, la clave maestra, la clave privada, las claves de bóveda y las claves de registro. La contraseña maestra del usuario deriva la clave maestra mediante una función como PBKDF2, que ralentiza los intentos de adivinar la contraseña. Esa clave descifra una clave privada, que descifra las claves de bóveda, las cuales a su vez desbloquean las claves de cada registro.

El servidor almacena la clave privada y las claves de bóveda en forma cifrada. La clave que las descifra permanece en el dispositivo del usuario, por lo que una copia de la base de datos por sí sola no concede acceso.

La recuperación es la única vía de claves que merece un mapeo aparte. Algunos diseños incluyen una cuenta de recuperación o una clave en depósito para que una organización pueda restaurar el acceso tras perder la contraseña maestra. Quien posea esa clave también puede acceder al texto en claro, así que trátela como cualquier otra clave: quién la posee, dónde se almacena y qué tribunales pueden obligar a revelarla a quien la posee. Nuestra guía sobre qué protege y qué no protege el cifrado de conocimiento cero explica el mecanismo.

Zona 3: Datos de servicio

Los datos de servicio son todo lo que el sistema registra sobre el uso, no sobre el contenido. El cifrado del lado del cliente no los cubre, por lo que el operador normalmente puede leerlos. Esto los convierte en datos personales por derecho propio y en la parte del sistema a la que puede llegar un requerimiento legal sin tocar el cifrado. Suele incluir:

Identidades de cuenta, direcciones de correo electrónico y registros de facturación
Direcciones IP de inicio de sesión, identificadores de dispositivo y marcas de tiempo de acceso
Registros de auditoría, además de los nombres de los registros y la estructura de carpetas si el producto no los cifra

Se aplican tres obligaciones. Los registros son su evidencia para valorar una vulneración (artículos 32 y 33). La conservación debe limitarse a lo que necesite (artículo 5(1)(e)). Los empleados pueden solicitar sus propios datos (artículo 15). En un despliegue autoalojado, usted mismo gestiona esta zona.

Zona 4: Copias de seguridad, réplicas y recuperación ante desastres

Las copias de seguridad, las réplicas y los sitios de recuperación ante desastres (DR) son las copias de datos de credenciales que existen fuera del servidor principal. Cada copia puede estar en un país distinto y bajo un operador distinto, por lo que cada una necesita su propia respuesta sobre ubicación, cifrado y eliminación.

Las copias de seguridad son copias almacenadas para restaurar datos. Las réplicas son copias activas en otros servidores. Los sitios de recuperación ante desastres (DR) son ubicaciones en espera. Respaldan la disponibilidad y la recuperación (artículo 32(1)(b) y (c)), pero cada copia adicional amplía la superficie de ataque y el conjunto de jurisdicciones aplicables. Pregunte tres cosas:

¿Dónde se almacena cada copia de seguridad y cada réplica, y sale alguna copia de la UE o del EEE? Una copia en un tercer país puede contar como una transferencia conforme al capítulo V.
¿Las copias de seguridad están cifradas, y las claves se mantienen separadas de los datos?
Una vez finalizado el contrato, ¿cuántos días tardan en desaparecer todas las copias, y cómo lo verifica?

El artículo 28(3)(g) exige que el encargado del tratamiento, a elección del responsable, elimine o devuelva todos los datos personales cuando finalicen los servicios, y que elimine las copias existentes salvo que la ley exija su conservación. Las copias de seguridad quedan sujetas a esta obligación. En la práctica, suelen caducar en un ciclo de rotación, por lo que el plazo de conservación es el dato que conviene obtener por escrito.

Zona 5: Cachés de los clientes y almacenes sin conexión

Algunos datos salen del servidor por diseño. Las aplicaciones de escritorio y móviles pueden conservar copias sin conexión, las extensiones del navegador pueden conservar una sesión o una clave de desbloqueo, y los usuarios pueden exportar archivos de la bóveda. Cada una es una copia fuera de sus controles centrales que viaja allí donde va el dispositivo del empleado.

Esta es la zona donde más importa su propia política. Decida si se permite el modo sin conexión, exija el cifrado de disco mediante la gestión de dispositivos móviles (MDM), y restrinja quién puede exportar. Trate las exportaciones con el máximo cuidado, ya que un archivo CSV es legible por cualquiera que lo abra. Pregunte al proveedor si los administradores pueden limitar el modo sin conexión por rol, si los datos en caché se borran automáticamente tras un periodo determinado, y si el uso sin conexión y las exportaciones quedan registrados.

Un dispositivo perdido con una copia de la bóveda es un riesgo conforme al artículo 32(2), que menciona la pérdida y la divulgación no autorizada, y puede activar las obligaciones de notificación de vulneraciones de los artículos 33 y 34. Enumere los endpoints y las ubicaciones de exportación aprobadas en su RoPA.

Zona 6: Subencargados y acceso de soporte

Los subencargados son los proveedores que utiliza un proveedor para prestar el servicio, como el alojamiento, el envío de correo electrónico, la monitorización y las herramientas de soporte. Conforme a los artículos 28(2) y 28(4), el encargado del tratamiento necesita su autorización para contratarlos y debe trasladar las mismas obligaciones de protección de datos a lo largo de la cadena.

Los terceros estuvieron implicados en el 48 % de las vulneraciones registradas en el DBIR 2026 de Verizon, un aumento del 60 % respecto al año anterior. El informe agrupa estos casos en tres arquetipos: un proveedor en su cadena de suministro de software, un proveedor que aloja sus datos en su propio entorno y un proveedor con una conexión a su entorno. Un gestor de contraseñas alojado es del segundo tipo, y un enlace de soporte o integración con sus sistemas puede convertirlo en el tercero. Revise a los proveedores del proveedor con la misma atención que su producto.

Pida cuatro cosas:

Una lista actualizada de subencargados y el país en el que opera cada uno
Aviso previo de los cambios, con derecho a oponerse
Quién del equipo de soporte del proveedor puede ver datos de servicio (zona 3), y bajo qué autorización
Si algún subencargado o canal de soporte puede acceder al material de claves (zona 2)

Mapa de zonas a artículos: La obligación y la evidencia

El mapa de zonas a artículos vincula cada una de las seis zonas de credenciales con la disposición del RGPD que activa, el documento que demuestra el cumplimiento y la parte responsable de aportarlo. Utilícelo como esqueleto para la entrada de su RoPA sobre el gestor de contraseñas, y complete la columna de evidencias antes de que un auditor la solicite. El paquete de evidencias del final enumera los mismos documentos como lista de verificación.

Zona	Disposición del RGPD	Evidencia que conservar	Responsable
1. Credenciales almacenadas	Art. 32(1)(a), art. 30	Descripción del cifrado, entrada del RoPA	El responsable decide, el encargado implementa
2. Material de claves	Art. 32(1)(a), art. 25	Jerarquía de claves y diseño de recuperación	El encargado, revisado por el responsable
3. Datos de servicio	Art. 15, art. 28(3)(e), arts. 44-46	Inventario de datos, procedimiento de exportación de registros, evaluación de transferencia	El responsable decide, el encargado opera
4. Copias de seguridad y réplicas	Art. 28(3)(g), art. 32(1)(c), arts. 44-46	Ubicaciones de las copias, plazo de conservación, condiciones de eliminación	El encargado, verificado por el responsable
5. Cachés de los clientes	Art. 32(2), arts. 33-34	Política de dispositivos, normas de exportación	El responsable
6. Subencargados	Art. 28(2), art. 28(4)	Lista de subencargados, aviso de cambios	El encargado, aprobado por el responsable

Este reparto decide quién notifica. Conforme al artículo 33, el responsable notifica a la autoridad de control en un plazo de 72 horas desde que tiene conocimiento de la vulneración, siempre que sea posible. El encargado debe informarle «sin dilación indebida», una expresión que no fija un número, así que conviene recoger un plazo de notificación en el DPA. Cuando aloja el sistema usted mismo, es a la vez responsable y operador, y la columna de responsable se reduce a sus propios equipos.

El DPA que necesita de un proveedor de gestores de contraseñas

Un acuerdo de tratamiento de datos (DPA) es el contrato que exige el artículo 28(3) entre un responsable y un encargado del tratamiento. En el caso de un proveedor de gestores de contraseñas, debe especificar el objeto, la duración, la naturaleza, la finalidad, los tipos de datos y las categorías de interesados, además de ocho obligaciones recogidas en los puntos (a) a (h). Las Directrices 07/2020 del CEPD sobre responsables y encargados explican cada una.

Término	Artículo	Qué pedir al proveedor
Instrucciones documentadas	28(3)(a)	Tratamiento solo conforme a sus instrucciones por escrito, incluidas las transferencias a terceros países, y la obligación de informarle de inmediato si una instrucción infringe la ley
Confidencialidad	28(3)(b)	Todas las personas autorizadas a tratar los datos, incluido el personal de soporte, sujetas a un deber de confidencialidad
Medidas de seguridad	28(3)(c)	Las medidas del artículo 32, detalladas en un anexo
Subencargados	28(3)(d), 28(2), 28(4)	Su autorización, aviso de cambios con derecho a oponerse, las mismas obligaciones trasladadas a la cadena
Derechos de los interesados	28(3)(e)	Ayuda para responder a solicitudes de acceso y eliminación
Asistencia	28(3)(f)	Ayuda con la seguridad, la notificación de vulneraciones y las evaluaciones de impacto (artículos 32 a 36)
Eliminación o devolución	28(3)(g)	Eliminación o devolución, a su elección, al finalizar el contrato, con un plazo indicado para las copias de seguridad
Auditorías	28(3)(h)	Información que demuestre el cumplimiento, y auditorías que incluyan inspecciones

La fila de auditorías es la que exige una lectura más atenta. El artículo 28(3)(h) exige que el contrato le facilite la información que demuestre el cumplimiento y permita auditorías, incluidas inspecciones. Si el proveedor no abre su infraestructura a una inspección in situ, el contrato debería indicar qué la sustituye.

La evidencia que revisa entonces incluye la lista de subencargados, una evaluación de transferencia y los informes de auditoría a los que el contrato le da derecho. Añada sus propios registros de la bóveda, exportados a un SIEM (sistema de gestión de eventos e información de seguridad).

Modelos de despliegue para una gestión de contraseñas conforme al RGPD

Su modelo de despliegue decide cuáles de las seis zonas controla su equipo. Una nube del proveedor deja la mayoría de las zonas en manos del proveedor, una nube en región de la UE reduce dónde se ubican, y el autoalojamiento las traslada a su infraestructura y a su lista de obligaciones. Los entornos aislados (air-gapped) van más allá y añaden la gestión de actualizaciones y registros sin conexión.

Opción	Dónde residen los datos	Situación de transferencia	Obligaciones que asume
Nube del proveedor, cualquier región	A elección del proveedor	Mecanismo y TIA si los datos o el acceso salen del EEE	DPA, revisión de subencargados, plazo de notificación de vulneraciones
Nube en región de la UE	Región de la UE elegida	Exposición menor, no nula	DPA, revisión de subencargados, condiciones de acceso de soporte
Alojamiento soberano de la UE	Proveedor de la UE, de propiedad de la UE	La más baja para un servicio alojado	DPA, auditoría del proveedor
Autoalojado en las instalaciones	Su infraestructura	Ninguna, salvo que el acceso de soporte o las copias de seguridad salgan del EEE	Copias de seguridad, claves, parches, registros
Aislado (air-gapped)	Red aislada	Ninguna	Obligaciones del autoalojamiento, más actualizaciones sin conexión

Un servicio gestionado por el proveedor le da menos control sobre los formatos de exportación y los plazos de salida. Antes de firmar, compruebe cómo saldría: qué formatos puede exportar y el plazo para eliminar las copias de seguridad conforme al artículo 28(3)(g).

Autoalojamiento y RGPD: Qué obligaciones asume

El autoalojamiento traslada las obligaciones del RGPD de un contrato con un proveedor a sus propios procedimientos operativos. Usted controla dónde se ubica cada zona y quién la opera, lo que puede eliminar la relación de encargado del tratamiento para la propia bóveda. Usted también se convierte en el operador, por lo que es usted quien aporta la evidencia. Nuestra página sobre el gestor de contraseñas on-premise trata esta opción de despliegue.

Lo que gana:

Control sobre dónde se ubica cada zona, incluidas las copias de seguridad
Ninguna transferencia a un proveedor ni cadena de subencargados para la propia bóveda

Lo que ahora debe:

Ubicaciones de las copias de seguridad y réplicas, restauraciones probadas y un calendario de conservación
Procedimientos de recuperación de claves, aplicación de parches y alta disponibilidad
Un registro actualizado de actividades de tratamiento (artículo 30)
Su propio proceso de detección y notificación de vulneraciones (artículo 33)

Ejemplo hipotético: un equipo restaura una bóveda tras una caída del servidor y descubre que la tarea de copia de seguridad nocturna llevaba tiempo escribiendo en un almacenamiento situado en un segundo país, configurado años antes por alguien que ya no está en la empresa. La bóveda estaba on-premises, pero una copia nunca lo estuvo. Esa copia plantea una cuestión de transferencia conforme al capítulo V. Una revisión zona por zona la detecta antes de que lo haga un incidente.

El riesgo interno sigue siendo suyo. El cifrado del lado del cliente significa que los administradores no pueden leer el contenido de la bóveda, pero sí pueden eliminar datos, copiar texto cifrado y copias de seguridad, cambiar la configuración o modificar registros. Separe funciones y registre las acciones de los administradores.

Los despliegues aislados (air-gapped) añaden otra obligación. Sin conexión a internet, usted aplica las actualizaciones y traslada los registros manualmente. El aislamiento no elimina las vulnerabilidades, y el soporte físico que introduce se convierte en la vía por la que una actualización llega al sistema.

El artículo 32(1) exige medidas proporcionales al riesgo. Documente quién aprueba un paquete de actualización, cómo verifica su integridad antes de importarlo, con qué frecuencia salen los registros de la red y quién gestiona el soporte físico. Pruebe también el procedimiento de restauración, ya que el 32(1)(c) y (d) cubren la restauración de la disponibilidad y las pruebas periódicas de sus medidas.

Cómo gestiona Passwork la ubicación de los datos y el acceso

Passwork Self-hosted funciona sobre infraestructura que usted controla: servidores on-premises, una nube privada o una red aislada. La bóveda, las claves y las copias de seguridad se ubican donde usted las ponga, de modo que su equipo decide dónde vive cada zona. Las respuestas siguientes siguen las seis zonas y las preguntas planteadas más arriba.

Passwork se instala con Docker en Linux (la vía recomendada), con un script de PowerShell en Windows Server, o manualmente, y los paquetes sin conexión cubren las redes aisladas. Las guías técnicas de Passwork explican cada vía.

Contenido de la bóveda y claves (zonas 1 y 2). Los datos se cifran en el cliente con AES-256, por lo que el servidor solo almacena texto cifrado y material de claves cifrado. La clave maestra se deriva con PBKDF2 y nunca sale del dispositivo del usuario en texto claro. Una segunda capa independiente de AES-256 protege la base de datos en el servidor.

La arquitectura de conocimiento cero decide quién puede leer los datos: solo los usuarios que poseen las claves, de modo que tampoco sus propios administradores pueden leer el contenido de la bóveda. La recuperación se realiza mediante una cuenta de recuperación preconfigurada cuya contraseña maestra usted almacena fuera de línea, y usted decide quién la posee.

Datos de servicio (zona 3). El registro de actividad recoge las acciones de usuarios, administradores y del sistema, y sus pistas de auditoría están listas para integrarse con un SIEM. Los nombres de registros y carpetas, la estructura de acceso y los metadatos de auditoría residen en el servidor, así que incorpórelos a su RoPA. Usted define la política de conservación y mantiene los registros en su propio almacenamiento.

Copias de seguridad y réplicas (zona 4). Los conjuntos de réplicas de MongoDB con tres o más miembros votantes, junto con servidores de aplicación escalados horizontalmente, dan al servicio tolerancia a fallos para más de 10 000 usuarios. Tareas programadas en segundo plano crean y rotan los archivos de copia de seguridad, y usted elige dónde se almacenan.

Cachés de los clientes y almacenes sin conexión (zona 5). El modo sin conexión es de solo lectura y debe activarse voluntariamente en dos niveles: el usuario marca un registro y, después, activa el modo sin conexión en un dispositivo concreto. Los administradores controlan qué roles pueden usarlo, el número máximo de registros por dispositivo y el tiempo máximo sin sincronizar antes de un borrado automático. Las descargas y visualizaciones sin conexión se sincronizan con el registro de actividad y el panel de seguridad cuando el dispositivo vuelve a conectarse.

Subencargados (zona 6). Un despliegue autoalojado no tiene ningún subencargado alojado por un proveedor. Su lista de proveedores se limita a sus propios proveedores de alojamiento y de copias de seguridad, y se les aplican las mismas preguntas anteriores. Un proveedor de nube privada que opere la bóveda por usted es su encargado del tratamiento y necesita su propio DPA.

El acceso sigue el principio de mínimo privilegio. El control de acceso basado en roles (RBAC) define los niveles de acceso para bóvedas y carpetas, la sincronización de grupos de LDAP y Active Directory traslada los cambios del directorio a Passwork, y el SSO mediante SAML gestiona el inicio de sesión. Passwork está certificado según ISO 27001, se somete a pruebas a través de HackerOne, y su código fuente está disponible para auditoría independiente.

Si su caso de cumplimiento depende de dónde están la bóveda, las claves y las copias de seguridad, lo mejor es comprobarlo en su propio entorno. Probar Passwork gratis.

Paquete de evidencias del RGPD para la gestión de contraseñas

El paquete de evidencias de 8 puntos es el conjunto de documentos que debería tener antes de una auditoría del RGPD de su gestor de contraseñas. Cubre los registros de tratamiento, las condiciones del proveedor, las evaluaciones de transferencia, las ubicaciones de las copias de seguridad, las revisiones de acceso y los procedimientos ante vulneraciones. Los puntos 1 a 6 corresponden a zonas individuales, mientras que los puntos 7 y 8 cubren el acceso y la gestión de vulneraciones en todas ellas.

Entrada del registro de actividades de tratamiento del gestor de contraseñas, con las seis zonas (artículo 30)
DPA firmado que cubra las condiciones del artículo 28(3), si un proveedor o proveedor de alojamiento trata alguna zona
Lista actualizada de subencargados y la cláusula de aviso de cambios, en la misma condición
Evaluación de impacto de la transferencia, si alguna zona afecta a un tercer país (capítulo V)
Evaluación de impacto relativa a la protección de datos, si su revisión de riesgos la exige (artículo 35)
Mapa de copias de seguridad y réplicas con ubicaciones y condiciones de eliminación
Revisión de accesos de los permisos de la bóveda, realizada a partir de exportaciones del registro de auditoría
Un procedimiento de vulneraciones de 72 horas que indique quién decide y quién notifica (artículo 33)

El RGPD no fija un intervalo concreto para las revisiones de acceso. Una cadencia trimestral es habitual, así que establezca una que se ajuste a su riesgo y documéntela.

El registro de auditoría es la evidencia que respalda los puntos 7 y 8. Muestra quién accedió a cada credencial y cuándo, lo que ayuda a delimitar el alcance de una vulneración y a valorar si pueden verse afectados datos personales. Expórtelo a su SIEM para que sobreviva a la bóveda y alimente el registro de vulneraciones que exige el artículo 33(5).

Por dónde empezar con la gestión de contraseñas conforme al RGPD

Una gestión de contraseñas conforme al RGPD empieza por hacer coincidir el despliegue con los datos que no puede permitir que salgan de su jurisdicción. Después, mantenga un contrato o un registro para cada zona que gestione un proveedor: dónde se ubican el contenido, las claves, los datos de servicio, las copias de seguridad, las cachés y los subencargados, y qué lo cubre a cada uno.

Empiece con una sola página. Dibuje las seis zonas de su gestor de contraseñas actual y marque las que no puede responder. Esas son sus primeras preguntas para el proveedor, o sus primeras tareas internas si se autoaloja. Una vez completo el mapa, la guía de seguridad de contraseñas del RGPD cubre la siguiente capa: normas de contraseñas y prácticas del personal.

¿Quiere ver cómo se ajusta una bóveda autoalojada a su mapa de zonas? Probar Passwork gratis.

Preguntas frecuentes

¿Exige el RGPD que los datos de las contraseñas se almacenen en la UE?

No, como regla general. El RGPD no impone un requisito general de localización de datos. Restringe las transferencias de datos personales fuera del EEE y exige un mecanismo lícito, como una decisión de adecuación o cláusulas contractuales tipo respaldadas por una evaluación de impacto de la transferencia (artículos 44 a 49). Las normas nacionales o sectoriales pueden añadir límites adicionales.

¿Es una contraseña almacenada un dato personal conforme al RGPD?

Por lo general, sí. Un registro de credenciales suele incluir un nombre de usuario, un correo electrónico o un historial de accesos que identifica a una persona, por lo que queda sujeto a las obligaciones de los artículos 5(1)(f), 25 y 32. Los datos cifrados siguen siendo datos personales. El cifrado es una medida de protección y no excluye los datos del ámbito del reglamento.

¿El cifrado de conocimiento cero nos hace cumplir el RGPD?

No. Protege el contenido de la bóveda, que es una de las medidas del artículo 32. Cuando un proveedor aloja el servicio, los metadatos, como las identidades de cuenta, las direcciones IP de inicio de sesión y las marcas de tiempo de acceso, suelen seguir siendo legibles para el proveedor. Sus obligaciones en materia de contratos, registros de tratamiento y notificación de vulneraciones siguen aplicándose.

¿Necesitamos un acuerdo de tratamiento de datos con el proveedor de nuestro gestor de contraseñas?

Sí, si el proveedor trata datos personales en su nombre. En ese caso es un encargado del tratamiento, y el artículo 28(3) exige un contrato que cubra las instrucciones documentadas, la confidencialidad, la seguridad, los subencargados, los derechos de los interesados, la eliminación o devolución, y los derechos de auditoría. Un despliegue autoalojado sin acceso del proveedor puede no necesitar ninguno. Confírmelo con su equipo legal.

¿Qué hay que documentar conforme al artículo 32?

El artículo 32 exige medidas adecuadas a su riesgo, como el cifrado, la seudonimización, la resiliencia y las pruebas periódicas. El deber de responsabilidad proactiva del artículo 5(2) implica que debe poder demostrarlas. En la práctica, conserve un registro de las medidas, pruebas de que funcionan y exportaciones del registro de auditoría.