Roles básicos y por qué se desaconsejan

Los roles básicos son tres: lector, editor y propietario. Cada uno es una suma de permisos de casi todos los servicios del proyecto. El lector lee casi todo; el editor, además, crea, modifica y borra recursos en casi todos los servicios; el propietario, además, administra los permisos de otros y la facturación.

Los marcos de buenas prácticas de las nubes desaconsejan usarlos en producción: conceden mucho más de lo que una tarea necesita, y quien los tiene lo tiene sobre servicios que ni conoce. Un rol predefinido de un servicio, o uno personalizado, agrupa solo las acciones que el trabajo requiere. El mínimo privilegio se parece a esto: el rol más pequeño con el que la tarea sale.

ls basicos
cat basicos/que-concede-cada-rol-basico.txt

El propietario es el rol más poderoso de un proyecto: puede darse a sí mismo o a otros cualquier rol. Por eso conviene que sea escaso, nominal y vigente. Una persona con propietario que lleva meses sin tocar el proyecto es un acceso que nadie vigila y que, si la cuenta se compromete, entrega el proyecto entero.

Lee el inventario y busca, entre las personas con propietario, a la que más tiempo lleva sin usarlo.

cat basicos/asignaciones-de-roles-basicos.csv
grep owner basicos/asignaciones-de-roles-basicos.csv

Los roles básicos no son solo de personas. Las cuentas de servicio son identidades de las aplicaciones, y es frecuente encontrarlas con editor porque «así funcionó la primera vez». Es peor que en una persona: una aplicación con editor y una vulnerabilidad en su código le entrega a quien la explote la edición de todo el proyecto.

En el inventario, la columna tipo distingue personas, grupos y cuentas de servicio. Cuenta las cuentas de servicio con rol básico, sin importar cuál.

Reemplazar un rol básico exige saber qué usa de verdad la cuenta. La tabla de reemplazos junta, para cada una, lo que hace y el rol específico sugerido. Es una propuesta de quien revisó la actividad: el dueño de la aplicación la confirma antes del cambio.

cat basicos/reemplazos-sugeridos.csv

Quitar un rol básico sin haber dado antes el específico deja la aplicación sin permisos y la detiene. El orden prudente es: primero se añade el rol específico, después se comprueba que la aplicación sigue funcionando con él y por último se retira el básico. Si algo falla, el rol básico sigue ahí para volver atrás con calma.