Soberanía de datos y gestión de contraseñas empresariales

Soberanía de datos y gestión de contraseñas: manteniendo las credenciales donde pertenecen

La soberanía de datos es la capacidad de determinar — física, legal y criptográficamente — quién puede acceder a un dato y bajo qué jurisdicción. Una empresa puede cumplir plenamente con el RGPD en el papel y aún así no tener control real sobre dónde residen sus contraseñas. Para las credenciales corporativas, esa brecha entre «cumplimiento» y «control» es donde comienzan las filtraciones, los requerimientos judiciales y las auditorías fallidas.

El Reglamento General de Protección de Datos (RGPD) establece la base que la mayoría de las organizaciones utilizan para evaluar sus prácticas de datos: regula cómo se recopilan, almacenan y transfieren los datos personales, y según el Artículo 3, su ámbito territorial se extiende a cualquier empresa que procese datos de residentes de la UE, independientemente de dónde tenga su sede.

Las contraseñas y los secretos no son datos ordinarios, por eso la gestión de contraseñas necesita su propio modelo de soberanía, separado del almacenamiento general de archivos. Abren el acceso a todo lo demás, se mueven constantemente entre empleados y rara vez pasan por las herramientas de prevención de pérdida de datos (DLP) o clasificación que vigilan contratos y registros de clientes. Una credencial almacenada en el servidor equivocado, en el país equivocado, bajo las claves de cifrado de otra persona, es una responsabilidad que la mayoría de las listas de verificación de cumplimiento no detectan.

Este artículo desglosa lo que la soberanía realmente significa en tres niveles: ubicación física, cifrado y gobernanza de acceso. Compara los modelos on-premise, aislados y de nube en la UE, y muestra dónde encaja un gestor de contraseñas autoalojado y de conocimiento cero como Passwork en esa decisión.

Puntos clave

La soberanía requiere tres controles: ubicación, cifrado y gobernanza de acceso. Una brecha en uno rompe los demás.
Las credenciales necesitan su propio modelo de seguridad. Son de alto valor, se mueven constantemente y escapan a las herramientas DLP estándar.
El cumplimiento del RGPD no aborda quién posee las claves de cifrado. Un proveedor que cumple con la normativa aún puede acceder a los datos del cliente a través de subprocesadores o solicitudes legales.
La arquitectura de conocimiento cero determina si el cifrado en la nube realmente le protege. Si el proveedor tiene las claves, la ubicación del servidor importa menos.
El despliegue on-premise y aislado maximiza el control pero añade carga operativa. Los parches, las copias de seguridad y el tiempo de actividad pasan a ser responsabilidad de su equipo.
El alojamiento en la nube de la UE cierra la brecha de soberanía solo con cifrado del lado del cliente. La residencia cubre la jurisdicción; el cifrado cubre quién tiene las claves.
Las afirmaciones de soberanía del proveedor necesitan verificación de terceros. ISO/IEC 27001, preparación para NIS2 y pruebas de penetración públicas dan a compras un punto de partida.
La elección de despliegue depende de cuatro factores: necesidades de aislamiento, requisitos de alojamiento en la UE, tamaño del equipo y política de autoalojamiento. Diferentes flujos de trabajo pueden usar diferentes modelos.

Qué significa realmente la soberanía de datos para las credenciales

La soberanía de datos es la combinación de tres controles separados: dónde residen físicamente los datos, quién posee las claves de cifrado y quién gobierna el acceso. Perder cualquiera de los tres rompe la soberanía, incluso si los otros dos son sólidos. La mayoría de los proveedores solo publicitan el primero.

La ubicación física responde dónde están los servidores. Un gestor de contraseñas alojado en Fráncfort todavía cae bajo el ámbito territorial del RGPD, pero también uno alojado en Virginia si procesa datos de residentes de la UE. La ubicación importa para la jurisdicción, no automáticamente para la exposición legal.
El control del cifrado responde quién puede descifrar los datos. Si el proveedor tiene las claves, una solicitud gubernamental, un infiltrado o una brecha en la infraestructura del proveedor pueden exponer sus credenciales independientemente de la ubicación del servidor.
La gobernanza de acceso responde quién dentro de su organización puede ver qué. El control de acceso basado en roles (RBAC) y los registros de auditoría determinan si el acceso de un empleado que se va se revoca en minutos o se descubre seis meses después.

La verdadera soberanía de datos requiere los tres elementos. Omitir cualquier componente reduce la arquitectura a una lista de verificación de cumplimiento formal.

Por qué las credenciales son una clase de datos distinta

Las credenciales merecen un tratamiento separado porque son de alto valor, alta circulación y en gran medida invisibles para las herramientas estándar de gobernanza de datos. Un registro de cliente filtrado expone un conjunto de datos. Una contraseña de administrador filtrada expone todos los sistemas a los que ese administrador puede acceder, y sigue funcionando hasta que alguien la rota.

El Informe de Investigaciones de Filtraciones de Datos 2026 de Verizon encontró que las credenciales robadas representaron el 13% de los vectores de acceso inicial, pero esa cifra se triplicó (39%) a lo largo de toda la progresión de la filtración. Las contraseñas también se mueven constantemente: compartidas durante la incorporación, copiadas en tickets, pegadas en hilos de chat, reenviadas cuando un proyecto cambia de manos. Las herramientas DLP diseñadas para detectar la exfiltración de documentos rara vez marcan una contraseña enviada en un mensaje de Slack.

Esa combinación de alto impacto y baja visibilidad es la razón por la que el almacenamiento de credenciales necesita su propio modelo de soberanía en lugar de heredar cualquier política que cubra el almacenamiento general de archivos.

Profundice en los números

Para un desglose completo del DBIR 2026 de Verizon (incluyendo vectores de filtración, tendencias de ransomware y riesgo de terceros), consulte nuestro análisis del informe.

Dónde el almacenamiento estándar en la nube introduce fricción legal

Los gestores de contraseñas estándar en la nube introducen exposición legal a través de cadenas de subprocesadores, transferencias de datos transfronterizas y acceso del personal del proveedor, incluso cuando el proveedor cumple plenamente con el RGPD. El cifrado en reposo no elimina estos riesgos si el proveedor, no el cliente, posee las claves de descifrado.

Tres puntos de fricción específicos aparecen repetidamente durante las revisiones de adquisiciones:

Subprocesadores. La mayoría de los proveedores de nube dependen de infraestructura, monitoreo o proveedores de soporte subcontratados. Cada subprocesador es una entidad separada con su propia superficie de acceso. El Artículo 28(2) del RGPD requiere que el encargado no recurrirá a otro encargado (subprocesador) sin la autorización previa por escrito, específica o general, del responsable.
Transferencias a terceros países. El Capítulo V del RGPD regula las transferencias de datos personales fuera de la UE/EEE. El Artículo 44 establece el principio general de que cualquier transferencia no debe socavar el nivel de protección garantizado por el reglamento, y el Artículo 46 requiere garantías apropiadas, como las Cláusulas Contractuales Tipo, cuando no aplica ninguna decisión de adecuación. Las bóvedas de credenciales alojadas en un tercer país, o replicadas a uno con fines de copia de seguridad, caen directamente bajo este capítulo.
Acceso del personal del proveedor y solicitudes legales. Si el proveedor puede técnicamente descifrar los datos del cliente, esos datos están sujetos al proceso legal en la jurisdicción del proveedor. Una citación, orden judicial o solicitud de divulgación extranjera puede obligar el acceso independientemente de dónde esté registrada su empresa.

NIS2 añade un cuarto ángulo: el Artículo 21(2)(d) requiere que las entidades esenciales e importantes evalúen la seguridad de la cadena de suministro, incluyendo los proveedores y herramientas que utilizan para gestionar credenciales de acceso. Una bóveda de contraseñas situada con un subprocesador externo que no ha verificado cae directamente en ese requisito.

Nada de esto hace que el almacenamiento en la nube sea incumplidor por defecto. Significa que «cumple con el RGPD» es una condición necesaria para la soberanía de credenciales.

Caso ilustrativo: Exposición jurisdiccional

Un gestor de contraseñas en la nube alojado en centros de datos de EE. UU. está sujeto a la legislación estadounidense. Bajo la CLOUD Act, las agencias de aplicación de la ley de EE. UU. pueden obligar a los proveedores de servicios a entregar datos de clientes. Además, la FISA Section 702 permite a las agencias de inteligencia solicitar datos a proveedores de servicios con sede en EE. UU. Si el proveedor controla las claves de descifrado, debe cumplir con estas órdenes federales. El registro de la UE del cliente o las políticas de seguridad internas no pueden anular esta obligación legal.

Mapeo de las tres capas a modelos de despliegue

Una brecha en cualquier capa individual reabre la exposición que las otras dos pretendían cerrar. La tabla siguiente aplica los tres controles de la primera sección — ubicación, descifrado y acceso — a los modelos entre los que las organizaciones realmente eligen.

Capa	On-premise	Aislado	Región de nube en la UE
Dónde residen los datos	Infraestructura propia del cliente	Red aislada, sin ruta a internet	Centro de datos del proveedor con sede en la UE
Quién puede descifrar	Solo el cliente, arquitectura de conocimiento cero	Solo el cliente, arquitectura de conocimiento cero, sin conectividad externa	Depende del modelo de cifrado; seguro solo con cifrado del lado del cliente
Quién gobierna el acceso	RBAC y registros de auditoría del cliente	RBAC del cliente, mantenido manualmente	RBAC del cliente, el proveedor gestiona la capa de infraestructura

Aislado describe una infraestructura sin ninguna ruta de red a internet, la forma más estricta de aislamiento físico.
Conocimiento cero significa que el proveedor nunca puede leer sus datos, bajo ninguna circunstancia.
Cifrado del lado del cliente es el mecanismo que produce esa garantía: el cifrado y descifrado ocurren en el dispositivo del usuario, usando una contraseña maestra que el proveedor nunca recibe ni almacena, por lo que el servidor solo recibe y transmite texto cifrado.

Un esquema de cifrado del lado del cliente mal implementado — uno con una contraseña maestra recuperable o una función de derivación de clave débil — no proporciona automáticamente una verdadera garantía de conocimiento cero. Esta distinción determina si «cifrado en la nube» realmente significa algo para la soberanía.

On-premise y aislado: Aislamiento completo, a costa de carga operativa

El despliegue on-premise otorga a una organización control físico y criptográfico completo sobre su bóveda de credenciales, porque los datos nunca abandonan la infraestructura que la organización posee y administra. El aislamiento lleva esto un paso más allá: la infraestructura no tiene ninguna ruta de red a internet, que es la única configuración que elimina completamente la dependencia de la red externa.

Aislamiento del proveedor: Cifrado de conocimiento cero

Passwork se ejecuta completamente dentro del perímetro corporativo, en infraestructura que la organización controla de extremo a extremo. El gestor de contraseñas y secretos cifra y descifra los datos completamente en el lado del cliente, usando una clave derivada de la contraseña maestra del usuario. El servidor nunca recibe ni almacena texto sin formato en ningún momento — solo contiene blobs cifrados y no tiene ninguna clave capaz de descifrarlos. Para organizaciones con requisitos de aislamiento y políticas de segmentación estrictas, esta es a menudo la única arquitectura que satisface la política de seguridad interna.

Una afirmación como esa no debería aceptarse por fe. El código fuente de Passwork está abierto para que el propio equipo de seguridad de la organización lo audite directamente, línea por línea, en lugar de depender de la descripción del proveedor sobre cómo se implementa el cifrado.

La contrapartida operativa

Ese nivel de aislamiento tiene un coste, pagado en esfuerzo operativo. On-premise traslada el mantenimiento del servidor, los parches, la gestión de copias de seguridad y la responsabilidad del tiempo de actividad del proveedor a su propio equipo de TI. Alguien tiene que aplicar actualizaciones, monitorear el espacio en disco, gestionar certificados TLS y manejar la recuperación ante desastres. Para un pequeño equipo de TI ya sobrecargado con otras prioridades, eso es un coste real. Las organizaciones que eligen el autoalojamiento necesitan un recurso de administrador de sistemas dedicado o un proceso interno gestionado para mantener el despliegue actualizado.

El cifrado de conocimiento cero de Passwork mantiene sus datos ilegibles para cualquiera excepto sus propios usuarios. Revise la arquitectura en las guías de usuario antes de comprometer infraestructura, o pruebe el despliegue completo gratis para verlo funcionando en sus propios servidores.

Alojamiento en la nube de la UE: Viable, pero solo con cifrado del lado del cliente

El alojamiento en la nube de la UE puede satisfacer los requisitos jurisdiccionales para equipos más pequeños sin personal de infraestructura dedicado, pero solo si el proveedor implementa cifrado obligatorio del lado del cliente (CSE). Sin CSE, una bóveda alojada en la UE todavía deja al proveedor capaz de descifrar los datos del cliente, lo que reabre la misma exposición que el alojamiento en la UE debía cerrar.

Bajo un modelo CSE adecuado, la contraseña maestra nunca abandona el dispositivo del usuario, y los servidores del proveedor procesan y almacenan solo texto cifrado. Incluso con acceso físico completo al servidor, el proveedor no puede leer el contenido de la bóveda. Esta es una garantía significativamente diferente a «nuestros centros de datos están en la UE», que aborda la jurisdicción pero no dice nada sobre quién tiene las claves.

El alojamiento en la nube de la UE con CSE reduce la exposición legal y satisface los requisitos de residencia de datos para muchos marcos de cumplimiento, pero no es la misma garantía que la soberanía on-premise completa. La infraestructura, la capa de red y el hardware físico permanecen fuera del control directo del cliente. Para organizaciones con mandatos de aislamiento o políticas estrictas de autoalojamiento, la nube de la UE no es un sustituto, independientemente de la fortaleza del cifrado.

On-premise sin conocimiento cero todavía confía a los administradores locales el acceso al texto sin formato. La nube de la UE sin él todavía confía al personal de infraestructura del proveedor. De cualquier manera, la garantía solo se mantiene cuando la contraseña maestra nunca abandona el dispositivo del usuario.

Verificación de las afirmaciones del proveedor: Qué debe comprobar el departamento de compras

Las afirmaciones de soberanía son tan creíbles como la evidencia de terceros que las respalda. Esta verificación se aplica independientemente del modelo de despliegue que elija: un certificado no le dice dónde residen los datos, pero sí le dice si las otras afirmaciones del proveedor se sostienen. Los equipos de compras deben basar una decisión de autoalojamiento en la capacidad administrativa interna y los requisitos de política, luego validar al proveedor preseleccionado a través de certificación independiente, auditoría propia y pruebas de seguridad públicas.

Cuatro verificaciones importan en la práctica:

La certificación ISO/IEC 27001 confirma que un sistema de gestión de seguridad de la información ha sido auditado de forma independiente según el estándar internacional. Passwork posee certificación ISO/IEC 27001:2022, emitida por MSECB y verificable a través de la base de datos IAF CertSearch.
La preparación para NIS2 y RGPD importa para cualquier organización que caiga bajo el alcance de cualquiera de las dos regulaciones. Los requisitos de cadena de suministro del Artículo 21 de NIS2 se extienden a las herramientas que las entidades esenciales e importantes utilizan para gestionar credenciales de acceso, mientras que el Artículo 32 del RGPD requiere «medidas técnicas y organizativas apropiadas», incluyendo cifrado, para cualquier sistema que maneje datos personales. Las organizaciones que evalúan proveedores contra estos requisitos pueden revisar el enfoque de Passwork sobre el cumplimiento de NIS2 como un punto de referencia.
Los derechos de auditoría del código fuente confirman que una afirmación de conocimiento cero es realmente verdadera en lugar de lenguaje de marketing. En un diseño de conocimiento cero genuino, el proveedor no puede recuperar la contraseña maestra de un usuario individual bajo ninguna circunstancia — ni mediante un reinicio del backend, ni mediante un ticket de soporte, ni bajo presión legal. Si un usuario la olvida, los datos detrás de ella desaparecen por diseño, porque el proveedor nunca tuvo la clave en primer lugar. Passwork abre su código fuente a los propios equipos de seguridad de los clientes exactamente por esta razón: es la forma de confirmar que la implementación del cifrado coincide con la arquitectura que el proveedor describe.
Las pruebas de penetración públicas proporcionan evidencia más allá de la postura de seguridad autodeclarada. Passwork ha completado una prueba de penetración independiente a través de HackerOne, que cubre el manejo seguro de datos, el OWASP Top 10 y SANS Top 25, autenticación y control de acceso a API.

Elección de un modelo de despliegue: Un marco de decisión

El modelo de despliegue correcto depende de cinco factores prácticos:

Requisitos de aislamiento
Alojamiento obligatorio en la UE
Tamaño del equipo de administración
Política interna de autoalojamiento
Requisitos de control de infraestructura

Mapear estos factores contra las opciones de despliegue evita el error común de elegir basándose solo en el precio o el reconocimiento de marca. Utilice esta matriz de decisión de residencia de credenciales para mapear las restricciones organizacionales a un modelo de despliegue:

Requisito	Modelo recomendado
Mandato de aislamiento (ICS, entornos clasificados)	On-premise, red completamente aislada
Residencia de datos obligatoria en la UE, sin requisito de aislamiento	On-premise o nube de la UE con cifrado del lado del cliente (la elección depende de los requisitos de control de infraestructura)
Equipo de TI/administración pequeño, capacidad de infraestructura limitada	Nube de la UE con cifrado del lado del cliente
Política interna estricta de autoalojamiento (regulatoria o contractual)	On-premise, infraestructura gestionada por el cliente

Ninguna de estas filas es mutuamente excluyente en la práctica. Una institución financiera podría ejecutar on-premise para su bóveda principal mientras acepta herramientas basadas en la nube para flujos de trabajo de menor sensibilidad. La matriz es un punto de partida para la conversación con los interesados de seguridad y cumplimiento.

Cómo la arquitectura de Passwork se mapea a estas capas

El despliegue autoalojado de Passwork aborda la brecha de soberanía descrita a lo largo de este artículo combinando aislamiento físico, cifrado de conocimiento cero y gobernanza de acceso controlada por el cliente en una sola arquitectura. La bóveda se despliega en infraestructura que el cliente posee, ya sea un servidor Linux individual, un entorno de Windows Server o un contenedor Docker dentro de una red aislada.

El cifrado utiliza AES-256 con un diseño de conocimiento cero, lo que significa que la infraestructura, si alguna vez fuera comprometida, solo contiene texto cifrado. El acceso se gobierna a través de permisos basados en roles y un registro de auditoría completo, para que los administradores puedan ver quién accedió a qué credencial y cuándo, y revocar el acceso inmediatamente cuando alguien cambia de rol o se va. La integración con AD/LDAP y SAML SSO permite que la gobernanza de acceso se conecte a la infraestructura de identidad existente en lugar de funcionar como un silo separado.

Esto deliberadamente no es una afirmación de que el autoalojamiento sea adecuado para todos. Las organizaciones sin requisitos de aislamiento o mandatos estrictos de autoalojamiento pueden encontrar suficiente una opción en la nube con cifrado del lado del cliente apropiado. El punto es que cuando la soberanía total es el requisito, la arquitectura necesita soportarlo estructuralmente.

Soberanía de datos en la gestión de contraseñas: Cómo aplicarla a su evaluación

La soberanía es una alineación continua entre dónde residen los datos, quién tiene las claves y quién gobierna el acceso — y esa alineación necesita revisarse cada vez que cambia su infraestructura, contratos con proveedores o alcance regulatorio.

Comience mapeando su propia organización contra los cuatro factores de la matriz de decisión: requisito de aislamiento, alojamiento obligatorio en la UE, tamaño del equipo de administración y política interna de autoalojamiento. Ese mapeo le dirá más sobre el modelo de despliegue correcto que cualquier página de marketing de proveedores.

La única forma de confirmar que una arquitectura autoalojada se adapta a su infraestructura es ejecutarla allí. Passwork ofrece una prueba gratuita que puede desplegar en sus propios servidores, con funcionalidad completa y sin que ningún dato abandone su entorno.

Preguntas frecuentes

¿Qué es la soberanía de datos en el contexto de la gestión de contraseñas?

La soberanía de datos en la gestión de contraseñas significa que la organización, no un proveedor externo, controla dónde residen físicamente los datos de credenciales, quién posee las claves de cifrado y quién puede acceder a ellos. El cumplimiento del RGPD por sí solo no garantiza la soberanía si el proveedor puede técnicamente descifrar los datos o está sujeto a solicitudes legales de una jurisdicción extranjera.

¿Es el cumplimiento del RGPD suficiente para garantizar la soberanía de credenciales?

No. El cumplimiento del RGPD aborda obligaciones amplias de procesamiento de datos, y el Capítulo V regula específicamente las transferencias transfronterizas, pero ninguno aborda quién posee las claves de cifrado. Un proveedor que cumple con el RGPD todavía puede técnicamente descifrar los datos del cliente a menos que la arquitectura utilice conocimiento cero o cifrado del lado del cliente.

¿Cuál es la diferencia entre despliegue on-premise y aislado?

On-premise significa que el software se ejecuta en infraestructura que la organización posee, que aún puede tener conectividad a internet. Aislado significa que esa infraestructura no tiene ninguna ruta de red a internet en absoluto. El aislamiento es un subconjunto más estricto de on-premise, típicamente requerido en entornos de defensa, control industrial o clasificados.

¿El alojamiento en la nube de la UE satisface los requisitos de soberanía de datos?

El alojamiento en la nube de la UE satisface los requisitos jurisdiccionales y de residencia de datos solo cuando se combina con cifrado del lado del cliente, donde el proveedor nunca tiene las claves de descifrado. Sin él, el alojamiento en la UE aborda la ubicación pero no quién puede acceder a los datos, lo que deja una brecha de soberanía significativa para organizaciones con requisitos estrictos.

¿Contra qué protege realmente la arquitectura de conocimiento cero?

La arquitectura de conocimiento cero protege contra compromisos del lado del servidor, acceso de infiltrados en el proveedor y solicitudes legales de datos, porque el servidor solo almacena texto cifrado. La contraseña maestra permanece en el dispositivo del usuario y nunca se transmite ni almacena en la infraestructura del proveedor.

¿Cómo afecta NIS2 a la selección de proveedores de gestores de contraseñas?

El Artículo 21(2)(d) de NIS2 requiere que las entidades esenciales e importantes gestionen el riesgo de seguridad de la cadena de suministro, lo que se extiende a los proveedores que manejan credenciales de acceso. Las organizaciones bajo el alcance de NIS2 deben evaluar las certificaciones y pruebas de seguridad de los proveedores de gestores de contraseñas como parte de sus propias obligaciones de cumplimiento.