Una cuenta con permisos para consultar una tabla puede tener también acceso para exportarla, modificarla o administrar el proyecto que la contiene. Revisar solo el rol que acabamos de asignar deja fuera permisos concedidos mediante grupos, recursos superiores u otras políticas. Una revisión de IAM en una plataforma de datos debe terminar con pruebas de acceso efectivo sobre tareas concretas.
Esta checklist propone una forma de ordenar esa revisión. Es un instrumento de diseño: los nombres exactos de roles, la herencia y la evaluación de políticas deben comprobarse en el proveedor utilizado.
Empezar por acciones sobre recursos identificados
Sustituye expresiones como «acceso a datos» por acciones verificables. Por ejemplo: ejecutar una consulta sobre ventas depuradas, escribir una partición del proceso de ingesta o consultar el estado de un trabajo fallido. Añade el entorno y el conjunto de datos permitido.
| Responsabilidad | Acceso que debe justificarse | Prueba de exclusión |
|---|---|---|
| Analista | Consultar los datos autorizados y ejecutar el trabajo necesario | No modificar las tablas de origen |
| Proceso de ingesta | Leer su origen y escribir su destino | No leer destinos de procesos ajenos |
| Operador | Diagnosticar y recuperar trabajos según un procedimiento | No ampliar sus propios privilegios de forma ordinaria |
| Administrador autorizado | Gestionar las políticas dentro de su ámbito | No usar la identidad administrativa para tareas diarias |
Esta matriz es ilustrativa. Una empresa puede necesitar otra separación. Lo relevante es que cada permiso tenga un responsable, un recurso y una razón que pueda revisarse.
Comprobar cómo se obtiene el permiso efectivo
En Google Cloud IAM, las políticas relacionan principales, roles y recursos. Las concesiones pueden heredarse desde niveles superiores. Un rol más reducido sobre un recurso hijo no elimina por sí solo un permiso que llega de un nivel superior. Las políticas de denegación y otras restricciones también pueden intervenir en la evaluación.
Para cada identidad seleccionada, revisa:
- Asignaciones directas sobre el recurso y sus antecesores.
- Grupos y otras pertenencias que conceden acceso.
- Condiciones o restricciones que cambian el resultado de la autorización.
- Posibilidad de asumir otra identidad o ejecutar como una cuenta de servicio.
- Permisos sobre claves, exportaciones, copias y ubicaciones de destino relacionadas.
Documenta el camino que concede el acceso. Si una prueba falla porque falta un permiso, identifica esa acción concreta antes de ampliar el rol. Dar administración de proyecto para resolver una consulta suele ocultar el problema de diseño y dificulta revisar después qué era necesario.
Separar identidades humanas y de ejecución
Un pipeline necesita una identidad operativa reconocible. Si utiliza las credenciales personales de su creador, la continuidad y la trazabilidad quedan ligadas a esa persona. Asigna cada ejecución al mecanismo de identidad que corresponda a su plataforma y evita reutilizar una misma identidad privilegiada para todos los procesos.
Comprueba también quién puede cambiar el código o la configuración que se ejecutará con esa identidad. Impedir a una persona leer una tabla sirve de poco si puede modificar libremente un trabajo que la lee con otros permisos y envía el resultado a un destino bajo su control.
La revisión debe incluir las dependencias legítimas. Consultar datos puede requerir tanto permiso de lectura como capacidad de crear trabajos de consulta; acceder a datos cifrados puede involucrar una clave. Registrar esas relaciones permite conceder lo necesario sin ensanchar indiscriminadamente el ámbito.
Probar concesión, rechazo y retirada
Ejecuta la matriz con identidades de prueba equivalentes, datos sintéticos y un entorno controlado. Para cada responsabilidad, comprueba una operación permitida y otra que deba rechazarse. Guarda el resultado, el recurso y la política evaluada, sin copiar datos sensibles en la evidencia.
Después retira una pertenencia o una concesión prevista para la prueba y vuelve a comprobar el acceso. Considera la propagación del proveedor, las sesiones y las credenciales ya emitidas: la revocación debe evaluarse con el mecanismo real utilizado, no solo mirando que desapareció una fila de la consola.
Si hay elevación temporal, deja definidos el motivo, la aprobación aplicable, el vencimiento y la comprobación posterior. Si hay una cuenta de emergencia, documenta su custodia y su uso observable. Ninguna de ellas debería convertirse en el camino cotidiano para resolver errores de permisos.
Qué debe quedar al cerrar la revisión
El entregable útil reúne una matriz de responsabilidades, los caminos de concesión efectivos, las pruebas permitidas y denegadas y un responsable para cada excepción. Añade qué volverá a verificarse cuando cambien grupos, destinos o identidades de ejecución.
El control de acceso de la plataforma se complementa con las reglas de consumo, como la seguridad por filas en BI. Son capas distintas y conviene probar su combinación. Si necesitas revisar estas dependencias en una plataforma de datos y Big Data, podemos analizar el recorrido de un proceso concreto desde su identidad hasta los datos que entrega.