Skip to content
SP StackPractices
intermediate Por StackPractices

Plantilla de Politica RBAC

Una plantilla para definir politicas de control de acceso basado en roles, incluyendo roles, permisos, reglas de asignacion y frecuencia de revision.

Nota para desarrolladores hispanohablantes: Esta guía incluye ejemplos y convenciones de nomenclatura adaptadas a equipos que trabajan en español. Cuando existen diferencias significativas en terminología técnica entre el inglés y el español, se indican explícitamente para facilitar la comunicación en equipos multiculturales.

Descripcion General

Una Plantilla de Politica RBAC define como se otorgan los derechos de acceso a traves de roles nombrados. Documenta los roles, los permisos asociados, quien puede asignarlos y con que frecuencia se revisan. Una politica RBAC clara reduce la acumulacion de privilegios, simplifica la incorporacion y apoya auditorias de cumplimiento.

Cuando Usar

  • Disenando control de acceso para una nueva aplicacion o sistema.
  • Estandarizando permisos a traves de multiples servicios o equipos.
  • Preparandose para una auditoria de seguridad o certificacion.
  • Revisando o refactorizando un modelo de acceso existente.
  • Incorporando empleados con aprovisionamiento basado en roles.

Prerequisitos

  • Un inventario de recursos y acciones del sistema.
  • Una lista de funciones o responsabilidades actuales del equipo.
  • Acuerdo sobre principios de privilegio minimo.
  • Un proveedor de identidad o sistema de gestion de roles.

Solucion

Plantilla

1. Declaracion de Politica

Todo acceso a sistemas, datos e infraestructura se otorga mediante roles predefinidos. Los roles se alinean con funciones laborales, privilegio minimo y separacion de deberes. El acceso debe ser aprobado, documentado y revisado periodicamente.

2. Definicion de Roles

RolDescripcionPermisosAlcanceAprobacion Requerida
viewerAcceso solo lectura para reportes e investigacionlecturaTodos los recursosManager
editorPuede modificar configuracion y datos no productivoslectura, escrituraNo-produccionManager
operatorPuede desplegar, reiniciar y monitorear servicioslectura, despliegue, reinicioServicios asignadosTeam lead
adminAcceso total para emergencias y cambios criticostotalSistema completoSeguridad + manager
auditorAcceso solo lectura a logs y evidencia de cumplimientolecturaLogs y datos de auditoriaCompliance officer

3. Reglas de Asignacion de Roles

ReglaDescripcion
Privilegio minimoLos usuarios reciben el rol minimo necesario para sus funciones actuales.
Separacion de deberesUn solo usuario no puede tener roles que permitan cometer y aprobar cambios sensibles.
Por tiempoRoles temporales o elevados expiran automaticamente.
Aprobacion de managerLa asignacion de un rol requiere aprobacion documentada del manager.
Revocacion por cambioLos roles se revocan cuando un usuario cambia de equipo o deja la organizacion.

4. Flujo de Solicitud de Acceso

PasoAccionDuenoSLA
1El usuario envia solicitud con justificacion de negocioSolicitanteN/A
2El manager revisa y apruebaManager2 dias habiles
3El equipo de identidad o plataforma aprovisiona el rolEquipo IAM1 dia habil
4La asignacion se registra en el registro de accesoEquipo IAMMismo dia
5El acceso se revisa durante la auditoria trimestralDueno del sistemaTrimestral

5. Revision y Cumplimiento

ActividadFrecuenciaDuenoEvidencia
Revision de inventario de rolesAnualSeguridadMatriz de roles actualizada
Revision de acceso privilegiadoTrimestralDueno del sistemaRegistro de atestacion
Limpieza de cuentas huerfanasTrimestralEquipo IAMLista de cuentas desactivadas
Aprobacion de excepcionSegun necesidadComite de riesgoForma de aceptacion de riesgo

Explicacion

RBAC simplifica la gestion de acceso al agrupar permisos en roles en lugar de asignarlos directamente a usuarios. Esta plantilla hace el modelo de roles explicito, ejecutable y auditable. Combinado con aprovisionamiento automatico, reduce errores manuales y acelera la incorporacion y baja de personal.

Variantes

  • Politica ABAC: Usa atributos como departamento, proyecto o ubicacion para decidir acceso dinamicamente.
  • Politica IAM en la nube: Mapea roles a roles y politicas de AWS IAM, Azure RBAC o GCP IAM.
  • RBAC a nivel aplicacion: Define roles dentro de una sola aplicacion, independiente de la identidad corporativa.
  • RBAC orientado a clientes: Modela roles de inquilino, admin y usuario final en sistemas multi-tenant.

Mejores Practicas

  • Comienza con pocos roles y expande solo cuando sea necesario.
  • Evita nombres de roles que coincidan con titulos de trabajo; usa nombres funcionales como editor u operator.
  • Documenta la justificacion de negocio para cada asignacion de rol.
  • Usa grupos y roles, no permisos individuales, para la mayoria de usuarios.
  • Exige MFA para todos los roles privilegiados.
  • Automatiza la revocacion de roles cuando los usuarios cambian o se van.
  • Revisa roles anualmente para eliminar roles sin uso o demasiado amplios.

Errores Comunes

  • Crear demasiados roles, causando explosion de roles y confusion.
  • Conceder permisos directos fuera de roles definidos.
  • Permitir que usuarios mantengan roles antiguos tras transferirse a otro equipo.
  • No definir separacion de deberes para operaciones sensibles.
  • Usar roles genericos como admin para tareas diarias.

FAQs

Cual es la diferencia entre RBAC y ABAC?

RBAC otorga acceso basado en roles asignados. ABAC otorga acceso basado en atributos del usuario, recurso y entorno, como departamento=ingenieria y horario=laboral.

Cuantos roles deberia tener un sistema?

La mayoria de los sistemas necesitan entre tres y siete roles. Mas de diez roles generalmente indica explosion de roles y debe refactorizarse.

Puede un usuario tener multiples roles?

Si, pero los permisos combinados deben revisarse para evitar escalacion no intencionada de privilegios. Roles temporales y permanentes deben rastrearse por separado.