OneNymID de proxy y tokens
Órdenes y miembros de referencia.
Reducir el almacenamiento directo de datos personales.
PLATAFORMA ONENYM / DISEÑO TÉCNICO
Realizar la acción necesaria,
sin compartir datos personales.
Evite la duplicación de datos personales entre empresas,
hacia la ejecución de acciones permitidas con acceso limitado.
OneNym Platform combina ID de proxy, tokens, autorización y una bóveda independiente. Su diseño separa los datos personales de los sistemas comerciales y limita su uso a los fines necesarios.
01 / ARQUITECTURA
Separe identidad, permisos y datos.
Los sistemas empresariales manejan tokens e ID de proxy. La recuperación y el procesamiento pasan por una autorización independiente. Mantenga los datos personales en una bóveda separada y reduzca las copias entre sistemas.
Solicitar una acción
↓
↓
Sólo acciones permitidas
Verificar solicitante, finalidad, registro y caducidad.
Rechazar solicitudes fuera de la autorización.
Limitar a la información necesaria
↓
↓
Bóveda de datos
Gestionar datos personales y mapeos.
Devolver resultados o campos limitados.
Diagrama conceptual. Las asignaciones entre ID de proxy y datos personales también requieren protección como información confidencial.
02 / CUATRO COMPONENTES
Reducir la exposición a través del diseño.
01 / PROXY IDENTITY
ID de proxy
Haga referencia a una persona a través de identificadores específicos del servicio en lugar de datos personales. Las identificaciones separadas entre servicios reducen las oportunidades de correlación y seguimiento.
Consideraciones: aislamiento de organizaciones y servicios, identificaciones impredecibles, rotación, eliminación y acceso restringido a mapas.
02 / TOKENIZATION
Tokenización
Utilice tokens de referencia específicos en lugar de direcciones o correos electrónicos. Gestione las acciones permitidas, la caducidad y los límites de uso.
Consideraciones: abuso de tokens robados, límites de reutilización, revocación y quién puede resolver un token. El hash simple no hace que los datos sean anónimos.
03 / PERMISSIONS
Permisos de acceso
Consulta las condiciones de cada operación, como permitir que la empresa A utilice una vez la dirección de este pedido para la entrega. Verificar quién puede manejar qué datos y con qué finalidad, más allá del estado de inicio de sesión.
Consideraciones: aislamiento de organizaciones, propósito, alcance, vencimiento, revocación, administración y pistas de auditoría. El permiso técnico es distinto del consentimiento o de los motivos contractuales.
04 / DATA VAULT
Bóveda de datos
Separe los datos personales de los registros comerciales y expóngalos solo a través de rutas restringidas. Diseñe juntos el cifrado, la gestión de claves, la administración, las copias de seguridad y la eliminación. Utilice servicios clave en la nube como Azure Key Vault o AWS KMS según el entorno de implementación.
Consideraciones: separación de claves y datos, límites de organizaciones, recuperación, disponibilidad, registros de auditoría y retención. Una bóveda centralizada puede convertirse en un objetivo valioso.
03 / EJEMPLO DE INTEGRACIÓN
Solicitar entrega sin almacenar la dirección.
Un ejemplo de diseño para un minorista y proveedor de entrega. La integración de proveedores, la custodia de datos y los motivos de uso requieren un diseño y un acuerdo por separado.
Registrar los datos requeridos en la bóveda
Registre una dirección de entrega y devuelva al minorista un ID de proxy relacionado con el pedido. Diseñe una ruta de entrada que evite los servidores y registros del minorista.
Emitir un token con un propósito específico
Limite un token al pedido, al transportista y al vencimiento. El minorista pasa el token en lugar de la dirección.
Autorizar al proveedor de entrega
Autenticar al proveedor y validar el alcance del token. Devolver sólo los datos de entrega permitidos.
Aplicar caducidad y revocación
Detenga el acceso futuro cuando una concesión expire o sea revocada. La eliminación de direcciones ya recuperadas depende de las operaciones y acuerdos del proveedor.
Registros de ejemplo retenidos por el minorista
ID de pedido, ID de proxy, token de entrega y estado de entrega.
Datos de ejemplo con retención directa reducidaNombre, código postal y dirección. Determine por separado qué facturación y atención al cliente deben conservar.
TECHNICAL DEEP DIVE
Explore los diseños a nivel de implementación.
Lea ejemplos concretos de asignaciones de identificadores, autorización, claves de cifrado y eliminación.
PROXY IDENTITY
ID de proxy y aislamiento de organizaciones
Separe los identificadores de los datos personales y establezca límites por organización y servicio.
Leer el diseño técnico.TOKENIZATIONTokens con un propósito específico y revocación
Pasar referencias en lugar de datos, limitando registros, destinatarios, finalidades y caducidad. Separe la posesión de un token del permiso para recuperar datos.
Leer el diseño técnico.PERMISSIONSAutorización e integración API
La autenticación identifica al solicitante. La autorización determina las acciones permitidas. Consultar el registro y finalidad de cada operación.
Leer el diseño técnico.DATA VAULTCifrado, gestión de claves y almacenamiento
Almacene los datos personales por separado y restrinja las rutas de descifrado. Diseñe el almacenamiento, el uso, la eliminación y la recuperación como un solo ciclo de vida.
Leer el diseño técnico.04 / LÍMITES Y CONSIDERACIONES
Reducir la retención es sólo una parte de la solución.
Los ID de proxy también necesitan protección
Los ID y tokens que identifican o vinculan a una persona no son automáticamente anónimos. Gestionar el almacenamiento y el acceso de forma adecuada.
Los datos recuperados pueden permanecer
Revocar el acceso no borra las copias ni los registros ya creados. Los socios necesitan políticas de retención y eliminación.
Disponibilidad y responsabilidades
Acuerde el impacto de la interrupción, la recuperación, las responsabilidades, la ubicación de los datos y la retención durante la implementación.
Decisiones de diseño antes de la implementación.
Defina autenticación, autorización, claves, registros de auditoría, retención, eliminación, comportamiento de falla y migración. Las API y el alcance de la integración dependen del sistema y el flujo de trabajo.
FROM EXPOSURE TO ARCHITECTURE
Empiece por comprender su flujo de datos.
Una prueba de exposición puede evaluar las rutas actuales hacia los datos personales.
Contáctenos para discutir la reducción de la retención de datos.