Diagrama de flujo de solicitud de acceso a datos (petición a revocación)
Diagrama del proceso de solicitud de acceso a datos: declara la finalidad, lee la clasificación, deja decidir al propietario de los datos, comprueba la privacidad, concede con caducidad y recertifica o revoca.
¿Qué es diagrama de flujo de solicitud de acceso a datos (petición a revocación)?
Las peticiones de datos se tramitan casi siempre como si fueran peticiones de software. Llega un ticket pidiendo acceso al almacén de datos, quien tiene las credenciales lo concede, y alguien que necesitaba una tabla para responder a una pregunta acaba pudiendo leer todos los esquemas del clúster, incluidos los que llevan salarios, identificadores de pacientes o números de tarjeta. Casi todo el daño lo causan tres costumbres. El aprobador se elige por quién puede conceder técnicamente el acceso y no por quién responde de los datos. La solicitud nombra un sistema en lugar de una finalidad, así que no queda nada contra lo que contrastar el mínimo privilegio. Y la concesión no tiene fecha de fin, de modo que sobrevive al proyecto, después al cambio de equipo y a veces incluso a la relación laboral. El acceso a datos es además el único tipo de acceso en el que casi siempre existe una respuesta más pequeña (una columna enmascarada, un filtro a nivel de fila, una tabla preagregada) y nadie la ofrece, porque ofrecerla lleva más tiempo que conceder la tabla en bruto. El resultado es un parque de datos donde nadie sabe decir quién puede leer qué, y en el que ninguna solicitud individual fue nunca descabellada.
Este diagrama trata de conjuntos de datos, no de cuentas. Si alguien que ya está en plantilla necesita una aplicación más y la pregunta es quién la aprueba y quién la aprovisiona, eso es el proceso general de solicitud de accesos en /es/templates/proceso-de-solicitud-de-accesos, y la versión que arranca con un alta o un cambio de puesto en el sistema de RR. HH. está en /es/templates/proceso-de-solicitud-de-accesos-de-empleados. Crear, modificar y desactivar la identidad en sí (la cuenta, el grupo del directorio, la licencia) pertenece al proceso de aprovisionamiento de usuarios en /es/templates/proceso-de-aprovisionamiento-de-usuarios; todo lo de aquí da por hecho que quien solicita ya tiene una cuenta operativa y solo pregunta qué puede leer esa cuenta. Tampoco es una petición de fuera de la organización: cuando una persona pide una copia de sus propios datos personales se activa una obligación legal con su propio reloj, sus propias comprobaciones de identidad y sus propias causas de denegación, y eso está dibujado en /es/templates/proceso-de-ejercicio-de-derechos-rgpd. Y si los datos ya han llegado a donde no debían, este es el diagrama equivocado: la contención, la prueba de riesgo para las personas y la decisión de notificar en 72 horas están en /es/templates/respuesta-ante-brechas-de-datos-personales. Lo que queda aquí es estrecho y concreto: una persona interna, un conjunto de datos con nombre, una finalidad declarada y un propietario que decide.
Las decisiones que la mayoría de los procedimientos escritos de acceso a datos dejan en manos de la costumbre están aquí dibujadas de forma explícita. «¿Catalogado y con propietario asignado?» va antes de cualquier evaluación, porque un conjunto de datos sin propietario no lo puede aprobar nadie, y la posición honesta en casi todas las organizaciones es que la primera solicitud contra una tabla es lo que por fin consigue que se clasifique; la rama No vuelve a pasar por el catálogo en vez de escalar a quien resultara haber montado el pipeline. «¿Qué acceso necesita la finalidad?» es una bifurcación de tres salidas y no un sí o un no, para que la vía enmascarada o agregada exista en el diagrama y haya que descartarla en lugar de no mencionarla nunca. Y el proceso no termina en la concesión: «¿Recertificado antes de la caducidad?» convierte la caducidad en la norma y la renovación en la excepción, que es justo lo contrario de cómo se conserva el acceso en la práctica, mientras que «¿Ha cambiado el rol o la finalidad?» le da al propietario un segundo motivo para revocar que no espera a una fecha de revisión. La vía de emergencia está dibujada por la misma razón: un ingeniero con una incidencia en producción llegará a los datos de una forma o de otra, así que «¿Se ha aprobado a posteriori?» pone la ratificación y la revocación detrás del acceso de emergencia en vez de fingir que no ocurre.
Qué cubre este diagrama de flujo
En esta plantilla
- Cinco carriles (Solicitante, Custodio de datos, Propietario de los datos, Oficina de privacidad y Equipo de plataforma de datos) repartidos en cinco fases: Solicitud, Clasificación, Evaluación del propietario, Aprovisionamiento, y Revisión y revocación.
- Una solicitud que tiene que llevar un motivo: «Crear la solicitud indicando la finalidad» es la única entrada ordinaria, mientras que la bifurcación «¿Acceso de emergencia por incidente?» manda los casos de incidencia en producción directos a «Conceder acceso de emergencia registrado» en lugar de dejar que ocurran fuera del diagrama. Esa concesión se enfrenta después a «¿Se ha aprobado a posteriori?» y termina en «Acceso de emergencia revocado y escalado» si nadie la ratifica.
- «¿Catalogado y con propietario asignado?» en el carril del custodio de datos, cuya rama No ejecuta «Clasificarlo y asignar un propietario» y vuelve a la consulta del catálogo, de modo que un conjunto de datos sin propietario no se puede aprobar por defecto.
- La decisión en manos del propietario de los datos y no de TI: «Evaluar la finalidad y el mínimo privilegio», después «¿La finalidad justifica el acceso?», cuya rama No termina en «Solicitud denegada con motivos registrados», y «¿Hay datos personales implicados?», que deriva al carril de la oficina de privacidad.
- Una rama de datos personales con dientes de verdad: «Registrar la base jurídica y minimizar campos» y después una decisión de tres salidas, «¿La revisión de privacidad aprueba el uso?», que aprueba la solicitud, la deniega contra ese mismo final de rechazo, o la envía por «Completar la EIPD y fijar condiciones» (la evaluación de impacto relativa a la protección de datos, la DPIA en inglés) y de vuelta a una segunda respuesta una vez conocido el riesgo residual.
- Una decisión de tres salidas, «¿Qué acceso necesita la finalidad?»: enmascarado o agregado, datos restringidos en bruto (que añade «Firmar el acuerdo de uso de datos») o datos internos en bruto, que confluyen todas en «Conceder el acceso con fecha de caducidad», el registro de consultas y una entrada en el registro de accesos. «¿Ha cambiado el rol o la finalidad?» y «¿Recertificado antes de la caducidad?» devuelven después el caso a una concesión nueva o lo sacan por «Acceso revocado y registro actualizado».
Cuándo usar esta plantilla
- Estás escribiendo el apartado de accesos de una política de gobierno del dato para un almacén de datos, un lakehouse o la capa de reporting, y necesitas una sola página que enseñe que decide el propietario de los datos y no el equipo que tiene las credenciales.
- Tus analistas conservan accesos concedidos para proyectos que terminaron hace dos años y quieres la caducidad y la recertificación dentro del proceso, en lugar de como una limpieza anual que no le gusta a nadie.
- Estás configurando el flujo de solicitudes en un catálogo de datos o en una herramienta de gobierno de accesos y quieres acordar la ruta de aprobación y los umbrales de clasificación antes de codificarlos.
- Los ingenieros tienen una vía de emergencia hacia los datos de producción que después no revisa nadie, y necesitas los pasos de ratificación y revocación dibujados donde los vean tanto los propietarios de los datos como el turno de guardia.
- Tu equipo de privacidad y tu equipo de plataforma de datos no se ponen de acuerdo sobre quién decide cuando hay datos personales, y quieres la base jurídica, la minimización y la EIPD dentro del flujo y no pegadas al final.
Cómo funciona
Renombra los carriles con los roles de tu organización
Sustituye Solicitante, Custodio de datos, Propietario de los datos, Oficina de privacidad y Equipo de plataforma de datos por los roles que de verdad tienes. Mantén al propietario de los datos separado del equipo de plataforma aunque hoy sea la misma persona quien hace las dos cosas, porque fusionarlos es exactamente lo que produce un proceso en el que quien concede es también quien aprueba. Si no hay oficina de privacidad, nombra a la persona que carga con esa responsabilidad en lugar de borrar el carril, y si la custodia del dato es informal, pon ahí al responsable del dominio y déjalo por escrito.
Mete tu esquema de clasificación en el diagrama
«Leer la clasificación y sus normas de manejo» es un paso inerte hasta que existen los niveles. Ponles nombre (público, interno, confidencial, restringido, o los que use tu esquema) y anota junto a cada uno qué permite: solo consulta sin extracción, extracción permitida, enmascarado obligatorio, acuerdo firmado exigible. Después di qué nivel dispara la rama del acuerdo de uso y qué nivel no puede salir nunca del entorno de análisis. Sin esa tabla, cada solicitud se discute desde cero y las respuestas cambian según quién apruebe.
Haz que la finalidad trabaje de verdad
Define el mínimo que una solicitud tiene que decir: la pregunta que se quiere responder, las tablas y columnas necesarias, de quién son los registros afectados, cuánto tiempo se quiere el acceso y dónde se guardará cualquier extracción. «Para análisis» hay que devolverlo, no aprobarlo. Es el control más barato de la página, porque una finalidad bien escrita vuelve casi mecánicas la evaluación de mínimo privilegio, la decisión de enmascarado y la fecha de caducidad, mientras que una vaga vuelve arbitrarias las tres.
Fija caducidades por defecto según la clasificación
Asocia un valor por defecto a «Conceder el acceso con fecha de caducidad» para cada nivel: algo así como la ventana del incidente para el acceso de emergencia, noventa días para los datos restringidos, seis o doce meses para los datos internos, y la fecha de fin del proyecto cuando lo hay. Deja que quien solicita pida menos tiempo, y haz que cualquier plazo superior al valor por defecto sea una decisión explícita del propietario. La caducidad es el control que sobrevive a las reorganizaciones, a las migraciones de herramienta y a que todo el mundo se olvide de que el proceso existía.
Acuerda la vía de emergencia antes de necesitarla
Decide quién puede activar el acceso de emergencia, qué concede, desde qué cuenta se ejecuta, cómo se registra la sesión y a quién se avisa en el momento de la concesión. Fija después el plazo de ratificación (unos pocos días laborables) y, sobre todo, decide qué pasa cuando nadie ratifica. La revocación automática al vencer el plazo es la única versión de esto que se sostiene, porque una cola de aprobaciones a posteriori sin consecuencia se convierte en atasco permanente en un trimestre.
Recórrelo con quien lo usa y publica una versión
Lleva el diagrama terminado a un propietario de datos, a un analista que pide accesos a menudo, al ingeniero de plataforma que ejecuta las concesiones y a quien lleve la privacidad, y pruébalo contra tres solicitudes reales del último trimestre, incluida una que se denegara y otra que fuera por la vía de emergencia. Corrige el diagrama hacia lo que pasó de verdad y no hacia lo que dice la política. Publica después esa revisión, conserva las anteriores y enlázala desde la política de gobierno del dato, para que quien la abra sepa qué versión está leyendo.
Preguntas frecuentes
¿Cuáles son los pasos de un proceso de solicitud de acceso a datos?
Crear una solicitud que declare la finalidad y no el sistema; localizar el conjunto de datos en el catálogo y leer su clasificación y sus normas de manejo; confirmar que tiene un propietario asignado, y clasificarlo primero si no lo tiene; que ese propietario evalúe la finalidad frente al mínimo privilegio y decida; cuando hay datos personales, registrar la base jurídica, minimizar los campos y pasarlo por una revisión de privacidad o una EIPD; ofrecer una vista enmascarada o agregada antes que el acceso en bruto; añadir un acuerdo de uso firmado para los datos restringidos; conceder el acceso con fecha de caducidad; activar el registro de consultas; anotar el permiso en el registro de accesos; y después recertificarlo antes de que caduque o revocarlo, de inmediato si cambia el puesto de la persona o la finalidad. Los pasos que más se echan en falta en la práctica son la alternativa enmascarada, la fecha de caducidad y el disparador de revocación por cambio de rol.
¿Quién debe aprobar el acceso a un conjunto de datos, TI o el propietario de los datos?
El propietario de los datos, es decir, la persona que responde en el área de negocio que esos datos describen, y no el equipo que opera la plataforma donde están alojados. Lo que se juzga es si esta finalidad justifica estos datos, y eso solo lo puede juzgar quien entiende qué significan los registros. El equipo de plataforma ejecuta la concesión, fija la caducidad y activa el registro; no debería además decidir quién tiene derecho a leer nóminas, historiales de pacientes o datos de clientes. La aprobación del responsable directo merece la pena como primera puerta, porque confirma que la petición forma parte del trabajo de esa persona, pero no sustituye a la decisión del propietario. Que un conjunto de datos no tenga propietario es en sí mismo un hallazgo, y por eso este diagrama pone «¿Catalogado y con propietario asignado?» antes de la evaluación y no después.
¿Cuánto debe durar un acceso a datos antes de caducar?
Lo que dure la finalidad declarada y ni un día más, con el valor por defecto fijado por la clasificación en lugar de negociado solicitud a solicitud. Un patrón que funciona es la duración del incidente para el acceso de emergencia, unos noventa días para los datos restringidos o personales, entre seis y doce meses para los datos internos ordinarios, y la fecha de fin del proyecto cuando la petición va ligada a uno. El mecanismo importa más que las cifras: una fecha de caducidad convierte la retirada en lo que ocurre por defecto y la renovación en el acto deliberado, así que el acceso se degrada solo cuando el proceso se descuida. El acceso sin caducidad, en cambio, se acumula. Y cuando pidas a un propietario que recertifique, mándale el número de consultas junto a la lista: un permiso que nadie ha usado en seis meses se retira sin discusión, mientras que una lista de nombres sin datos de uso se aprueba casi siempre en bloque.
¿Cuándo necesita una EIPD una solicitud de acceso a datos?
El RGPD exige una evaluación de impacto relativa a la protección de datos (EIPD, la DPIA en inglés) cuando es probable que el tratamiento entrañe un alto riesgo para los derechos y libertades de las personas, y la da por esperable en particular en el tratamiento a gran escala de categorías especiales de datos, la observación sistemática y las decisiones automatizadas con efectos jurídicos o similarmente significativos (artículo 35 del RGPD). Las autoridades de control publican además sus propias listas de tratamientos que siempre la requieren; en España las publica la AEPD. Para una solicitud analítica interna, los disparadores honestos suelen ser el tamaño de la población afectada, si hay categorías especiales o datos relativos a infracciones penales, si las personas esperarían razonablemente este uso y si el resultado alimenta una decisión sobre ellas. Dos cosas ayudan en la práctica: cribar toda solicitud con datos personales en lugar de esperar a que alguien plantee una duda, y tratar el resultado como condiciones de la concesión (las columnas enmascaradas, el plazo de conservación, la prohibición de reidentificar) y no como un documento que se archiva y se olvida.
¿En qué se diferencia esto de un proceso general de solicitud de accesos?
El proceso general de solicitud de accesos en /es/templates/proceso-de-solicitud-de-accesos cubre sistemas y aplicaciones: alguien necesita un rol en un sistema de negocio, lo aprueban su responsable directo y el propietario del sistema, se comprueba la segregación de funciones y TI lo aprovisiona. Esta página cubre conjuntos de datos, y eso cambia tres cosas. El aprobador es el propietario de los datos y no el propietario del sistema, porque la pregunta va del significado de los registros y no de la función de una aplicación. En el medio aparece un paso de clasificación, porque la respuesta depende de lo que haya dentro de la tabla. Y existe una alternativa enmascarada o agregada, que no tiene equivalente en el acceso a aplicaciones: no puedes conceder a nadie el sesenta por ciento de un módulo financiero, pero sí puedes darle una vista con los identificadores eliminados. Si estás diseñando el formulario de la mesa de servicio para el acceso a aplicaciones, empieza por el proceso general; si estás gobernando quién puede consultar el almacén de datos, empieza por aquí.