Cómo implementar controles de acceso granulares para datos personales

La Ley 21.719 exige que los responsables y encargados de datos adopten medidas técnicas y organizacionales aptas para proteger los datos personales de accesos no autorizados. De todas las medidas técnicas de seguridad, el control de acceso es la que más directamente determina quién puede ver, modificar y eliminar datos personales — y, por lo tanto, quién puede causar daño a los titulares.

Datos personales accesibles a quienes no los necesitan no es solo un problema de seguridad: es una violación del principio de proporcionalidad de la propia Ley 21.719, que establece que el tratamiento debe limitarse al mínimo necesario para la realización de sus finalidades.

¿Qué son los controles de acceso granulares?

Los controles de acceso granulares son mecanismos que definen, con precisión, quién tiene acceso a qué datos, en qué condiciones y para qué operaciones. La granularidad contrasta con enfoques simplistas (ej.: "todos los empleados tienen acceso al CRM") y establece permisos específicos basados en función, contexto o atributo.

Los tres principios que orientan un sistema de acceso granular son:

1. Principio de menor privilegio (Least Privilege)

Cada usuario, proceso o sistema debe tener acceso solo a lo estrictamente necesario para ejecutar su función — ni más, ni menos.

Ejemplo práctico: un analista de soporte al cliente necesita ver el historial de pedidos y datos de contacto del cliente, pero no necesita ver el RUT, datos bancarios o historial médico. El sistema debe reflejar exactamente esa distinción.

2. Segregación de funciones (Separation of Duties)

Las funciones críticas deben distribuirse entre múltiples personas o roles para evitar que una sola persona tenga control completo sobre un proceso sensible — lo que podría facilitar fraude o uso indebido.

Ejemplo: la misma persona que registra a un nuevo proveedor no debería tener permiso para autorizar pagos a ese proveedor. En el contexto de datos personales, la persona que elimina datos no debería ser la misma que aprueba la solicitud de eliminación.

3. Necesidad de saber (Need to Know)

El acceso a datos personales solo se justifica cuando existe una necesidad funcional concreta. El acceso debe concederse caso a caso, basado en demanda, no por conveniencia o jerarquía.

Modelos de control de acceso

RBAC — Control de Acceso Basado en Roles (Role-Based Access Control)

El modelo más ampliamente adoptado en entornos corporativos. Los usuarios son asignados a roles, y los roles tienen permisos definidos. En lugar de gestionar permisos individualmente para cada usuario, se gestionan permisos por rol.

Ventajas para la gestión de datos personales:

Transparencia: cada usuario está vinculado a un rol con permisos previamente documentados
Escalabilidad: al contratar o cambiar la función de un colaborador, basta con cambiar el rol
Auditabilidad: posible demostrar, ante la APDP, quién tenía acceso a qué datos en cualquier momento

Ejemplo de roles en un contexto de datos personales:

Rol	Acceso a los datos
Agente de servicio al cliente	Nombre, correo, historial de pedidos, teléfono
Analista de RR.HH.	Datos completos de empleados (incluidos datos de salud ocupacional)
Analista de Marketing	Correo, preferencias de comunicación, historial de compras — sin RUT ni datos financieros
DPD	Acceso de lectura al inventario y registros; sin acceso directo a la base de datos de producción
Administrador de base de datos	Acceso técnico (estructura de la base) — sin acceso a datos personales en texto plano
Auditor interno	Acceso de solo lectura a registros de auditoría

ABAC — Control de Acceso Basado en Atributos (Attribute-Based Access Control)

Modelo más granular que el RBAC, donde las decisiones de acceso se basan en atributos del usuario, del recurso y del contexto. Permite reglas como:

"Un médico puede acceder a fichas clínicas solo de pacientes bajo su cuidado"
"El acceso a datos de clientes europeos solo está disponible para colaboradores con capacitación RGPD"
"El acceso a datos sensibles está bloqueado fuera del horario laboral"

El ABAC es más complejo de implementar pero ofrece granularidad superior en entornos con datos sensibles o requisitos regulatorios específicos.

PBAC — Control de Acceso Basado en Políticas (Policy-Based Access Control)

Extensión del ABAC que incorpora políticas explícitas de cumplimiento — como "ningún dato personal de menor de 14 años puede ser accedido por usuarios sin autorización específica del DPD". Adecuado para organizaciones con múltiples normativas de privacidad aplicables.

Implementación práctica: paso a paso

Paso 1: Mapee los sistemas que contienen datos personales

Antes de definir controles, sepa dónde están los datos. Los sistemas típicos en una organización que contienen datos personales incluyen:

CRM (datos de clientes y prospectos)
ERP/nómina (datos de empleados)
Sistema de salud ocupacional o beneficios
Correo corporativo (frecuentemente ignorado)
Repositorios de archivos (Google Drive, SharePoint, servidores de archivos)
Bases de datos de aplicaciones web
Herramientas de soporte y mesa de ayuda
Sistemas de analytics y BI

Paso 2: Clasifique los datos por sensibilidad

No todos los datos personales requieren el mismo nivel de protección. Una clasificación práctica:

Nivel	Tipo de dato	Control de acceso
Crítico	Datos sensibles (salud, biometría, datos financieros detallados, RUT+datos bancarios combinados)	Acceso muy restringido; MFA obligatorio; registro de cada acceso
Confidencial	Datos personales generales con riesgo moderado (RUT aislado, datos de RR.HH., domicilio)	Acceso basado en necesidad funcional documentada
Interno	Datos personales de bajo riesgo (nombre, correo corporativo)	RBAC estándar; acceso por departamento

Paso 3: Defina los roles y sus permisos

Para cada sistema mapeado, defina:

Qué roles existen
Qué datos puede acceder cada rol
Qué operaciones puede ejecutar cada rol (lectura, creación, edición, eliminación)
Si el acceso es permanente o por demanda (just-in-time access)

Documente esta matriz de roles y permisos — será fundamental para auditorías y para demostrar cumplimiento.

Paso 4: Implemente autenticación multifactor (MFA)

El MFA no es un control de acceso en sí mismo, pero es el requisito mínimo para cualquier sistema que contenga datos personales. Sin MFA, una contraseña comprometida concede acceso sin restricciones.

Priorice MFA para:

Cualquier acceso remoto (VPN, acceso a sistemas en la nube)
Sistemas con datos sensibles
Cuentas privilegiadas (administradores, DBAs)
Acceso al panel de gestión de identidades

Paso 5: Configure registros de auditoría de acceso

Para demostrar cumplimiento con la Ley 21.719 e investigar incidentes, cada sistema con datos personales debe registrar:

Quién accedió (usuario identificado)
Qué fue accedido (registro o conjunto de datos)
Cuándo (fecha y hora con precisión)
Desde dónde (dirección IP, dispositivo)
Qué se hizo (lectura, exportación, edición, eliminación)

Retención de registros: los registros de acceso a datos personales deben conservarse por un plazo suficiente para investigar incidentes. La práctica recomendada es de 6 a 12 meses para registros operacionales, con posibilidad de archivo de largo plazo para incidentes investigados.

Paso 6: Implemente un proceso de revisión periódica de accesos

Los permisos se acumulan. Los colaboradores cambian de cargo, los proyectos terminan, los terceros ven sus contratos finalizados — pero los accesos frecuentemente permanecen activos. La revisión periódica es el mecanismo que corrige esa acumulación.

Frecuencia recomendada:

Accesos a datos críticos: revisión trimestral
Accesos a datos confidenciales: revisión semestral
Accesos de prestadores y terceros: revisión a cada renovación de contrato

Cómo conducir la revisión:

Genere un informe de todos los usuarios con acceso a cada sistema
Envíe al jefe responsable de cada área para validación
El jefe confirma qué accesos son necesarios y solicita la revocación de los innecesarios
TI ejecuta las revocaciones y registra los cambios

Paso 7: Establezca procesos de desvinculación (offboarding)

La desvinculación de un colaborador (renuncia, despido, finalización de contrato de tercero) debe activar inmediatamente la revocación de todos los accesos a sistemas con datos personales.

Un colaborador desvinculado con acceso activo al CRM o a la base de datos de clientes representa un riesgo regulatorio y reputacional concreto.

Checklist de offboarding:

Revocación de acceso a todos los sistemas (CRM, ERP, correo, repositorios, VPN)
Desactivación de cuenta de usuario en el directorio activo / proveedor de identidad
Revocación de tokens de API o credenciales de servicio asociadas al usuario
Verificación de dispositivos (notebooks, smartphones) con datos personales — borrado corporativo
Confirmación de que ninguna copia de datos personales fue retenida indebidamente

Gestión de accesos privilegiados (PAM)

Las cuentas de administrador — de sistemas, de bases de datos, de infraestructura — representan el mayor riesgo en cualquier entorno. Una cuenta de DBA con acceso irrestricto a la base de clientes, si es comprometida, puede exponer millones de registros.

Buenas prácticas para accesos privilegiados

Cuentas de administrador separadas de las cuentas personales: el DBA usa una cuenta común para correo y otra para acceso a la base de datos
Just-in-time access: los accesos privilegiados se conceden solo por el tiempo necesario para la tarea, no de forma permanente
Grabación de sesión: las sesiones de acceso privilegiado son grabadas y archivadas para auditoría
Doble aprobación: las acciones críticas (eliminación masiva, cambio de estructura de base de datos) requieren aprobación de un segundo administrador
Gestión centralizada de credenciales: uso de bóvedas de contraseñas (PAM — Privileged Access Management) en lugar de contraseñas individuales no gestionadas

Privacidad desde el diseño (Privacy by Design)

La Ley 21.719 incorpora el principio de privacidad desde el diseño y por defecto: los sistemas utilizados para el tratamiento de datos personales deben estructurarse de forma que atiendan los requisitos de seguridad y protección de datos desde la concepción — no como adaptación posterior. Checklist para nuevos sistemas:

¿Qué datos personales almacenará o procesará el sistema?
¿Qué roles necesitan acceso a qué datos?
¿El sistema admite RBAC nativo?
¿Existe un mecanismo de registro de acceso?
¿El MFA está disponible y habilitado?
¿Los datos sensibles están cifrados en reposo?

Errores comunes y cómo corregirlos

Error	Riesgo	Corrección
Acceso administrativo compartido ("contraseña genérica del sistema")	Imposible rastrear responsabilidad; compromiso afecta a todos	Cuentas individuales nominadas para cada administrador
Colaboradores con acceso a datos personales de todos los clientes cuando solo necesitan los suyos	Exposición innecesaria; violación del menor privilegio	RBAC con alcance por cartera o territorio
Registros inexistentes o sobreescritos en pocos días	Imposible investigar incidentes; sin evidencia de cumplimiento	Implementar retención mínima de 6 meses para registros
Terceros con acceso permanente a sistemas	Riesgo tras finalización del contrato	Cuentas temporales con fecha de expiración automática
Sin revisión periódica de accesos	Acumulación de permisos obsoletos	Proceso formal de revisión semestral
Datos de desarrollo con datos personales reales	Datos personales en ambiente no productivo, con controles menores	Usar datos enmascarados o sintéticos en dev/test

Conclusión

Los controles de acceso granulares no son solo una buena práctica de seguridad de la información — son una obligación legal bajo la Ley 21.719. La ley exige medidas técnicas adecuadas; el principio de proporcionalidad exige que el tratamiento se limite al mínimo necesario; y el principio de privacidad desde el diseño exige que los sistemas protejan los datos desde su concepción.

La implementación correcta de RBAC, MFA, registros de auditoría, revisión periódica de accesos y gestión del offboarding traduce estos principios legales en realidad operacional — y, en caso de fiscalización de la APDP o de un incidente de seguridad, demuestra que la organización tomó medidas concretas y razonables para proteger los datos bajo su custodia.

Confidata fue desarrollado con controles de acceso granulares nativos: cada usuario accede solo a lo que necesita, con registro de auditoría completo de todas las acciones. Conozca cómo nuestra plataforma protege los datos de su organización.