Plantilla de Política RBAC: Roles, Permisos y Revisiones

Descripción General

La acumulación de privilegios es el fallo de control de acceso que los auditores encuentran primero: la gente cambia de equipo, colecciona roles y nadie revoca los antiguos. Una política de control de acceso basado en roles (RBAC) frena esa deriva al hacer explícito el modelo de roles — qué roles existen, qué otorga cada uno, quién puede asignarlo y cuándo se revisa.

Abajo va un documento de política RBAC completo, escrito para ser copiado y adaptado. Rellena los marcadores entre corchetes, adapta los roles de ejemplo a tus sistemas y tendrás un modelo de acceso auditable que satisface SOC 2, ISO 27001 y la mayoría de revisiones de seguridad internas. Las secciones 6–10 cubren las partes que la mayoría de políticas olvidan: separación de deberes, flujo de solicitud, baja de personal, acceso break-glass y excepciones.

Cuándo Usar

• Estás diseñando el control de acceso de una aplicación nueva o de un sistema que se quedó pequeño para los permisos ad-hoc.
• Una auditoría o certificación (SOC 2, ISO 27001, PCI DSS) exige un modelo de acceso documentado.
• Dos o más equipos comparten servicios y cada uno inventó su propio esquema de permisos.
• Estás migrando usuarios desde permisos directos y necesitas el estado objetivo por escrito.
• La incorporación de personal tarda días porque nadie definió qué rol necesita realmente un nuevo ingreso.

Omite esta plantilla cuando una herramienta de un solo usuario solo necesita reglas allow/deny, o cuando el acceso depende de relaciones entre objetos — “los usuarios pueden editar los documentos que poseen” es un problema de ReBAC o ACL, no de roles. Para decisiones basadas en atributos (hora, ubicación, estado del dispositivo), mira la receta Implementar ABAC.

Prerequisitos

• Un inventario de sistemas, recursos y las acciones que cada uno soporta.
• Una lista de funciones o responsabilidades del equipo — lo que la gente hace, no sus títulos.
• Acuerdo sobre privilegio mínimo: los usuarios reciben el rol mínimo que les permite trabajar.
• Un proveedor de identidad, directorio o plataforma que pueda mapear usuarios y equipos a grupos.
• Un lugar donde la política vivirá y evolucionará — un repositorio, una wiki con historial de versiones o un sistema de gestión documental. Las políticas guardadas en slides mueren en silencio.

Solución

La Plantilla

Copia las secciones siguientes en tu documento de política y reemplaza los marcadores entre corchetes.

1. Propósito y Alcance

Esta política gobierna el acceso a [nombres de sistemas, entornos y clasificaciones de datos]. Aplica a todos los empleados, contratistas y cuentas de servicio. El acceso se otorga solo mediante roles nombrados; las concesiones de permisos directos fuera de esta política requieren una excepción documentada aprobada por [comité de riesgo / equipo de seguridad].

2. Declaración de Política

Todo acceso a sistemas, datos e infraestructura se otorga mediante roles predefinidos. Los roles se alinean con funciones laborales, privilegio mínimo y separación de deberes. Cada asignación requiere aprobación documentada, se registra en el registro de acceso y se revisa con la cadencia definida en la sección 7.

3. Definición de Roles

Rol	Descripción	Permisos	Alcance	Aprobación Requerida
viewer	Acceso de solo lectura para reportes e investigación	lectura	Todos los recursos	Manager
editor	Modificar configuración y datos no productivos	lectura, escritura	No producción	Manager
operator	Desplegar, reiniciar y monitorear servicios	lectura, despliegue, reinicio	Servicios asignados	Team lead
admin	Acceso total para break-glass y cambios críticos	total	Sistema completo	Seguridad + manager
auditor	Acceso de solo lectura a logs y evidencia de cumplimiento	lectura	Logs y datos de auditoría	Compliance officer

Notas de diseño para adaptar la tabla:

• viewer es deliberadamente amplio en alcance — el acceso de solo lectura es barato de otorgar y elimina la mayoría de solicitudes ad-hoc. Restríngelo solo donde la clasificación de datos lo exija.
• editor se detiene en no producción a propósito — las escrituras en producción pertenecen a operator o al pipeline de despliegue, lo que mantiene limpio el rastro de cambios.
• admin existe para emergencias y cambios estructurales poco frecuentes. Cuando alguien usa admin para trabajo diario, el modelo de roles está roto — eso es un hallazgo para la próxima revisión.
• auditor le da al cumplimiento un asiento de solo lectura en la mesa. El acceso de escritura para este rol no debería existir, ni siquiera “solo por una semana”.

4. Reglas de Asignación de Roles

Regla	Descripción
Privilegio mínimo	Los usuarios reciben el rol mínimo necesario para sus funciones actuales.
Separación de deberes	Ningún usuario tiene roles que le permitan realizar y aprobar a la vez cambios sensibles.
Por tiempo	Los roles temporales o elevados expiran automáticamente.
Aprobación del manager	La asignación de un rol requiere aprobación documentada del manager del usuario.
Revocación por cambio	Los roles se revocan cuando un usuario cambia de equipo o deja la organización.
Una identidad privilegiada	Las tareas de administración se ejecutan con una cuenta privilegiada separada, nunca con la cuenta de uso diario.

5. Matriz de Separación de Deberes

Define qué combinaciones de roles están prohibidas. Un usuario con dos roles en conflicto puede saltarse los controles que cada uno fue diseñado para imponer — y el conflicto es invisible hasta que alguien revisa los pares, no los roles. Revisa las asignaciones por pares durante la auditoría trimestral; la matriz de abajo es el punto de partida, extiéndela con combinaciones propias de tus sistemas.

Rol A	Rol B	Conflicto	Resolución
editor	approver	Puede escribir y aprobar sus propios cambios	Dividir funciones o exigir aprobación de un par
operator	auditor	Puede actuar y borrar el rastro de auditoría	Asignar la auditoría a otro equipo
admin	cualquier otro rol	Superset — los demás roles son redundantes	Mantener solo admin, con tiempo limitado
requester	approver (sí mismo)	La autoaprobación anula el control	El aprobador debe ser otra persona

6. Flujo de Solicitud de Acceso

Paso	Acción	Dueño	SLA
1	El usuario envía la solicitud con justificación de negocio	Solicitante	N/A
2	El manager revisa y aprueba	Manager	2 días hábiles
3	El equipo de identidad o plataforma aprovisiona el rol	Equipo IAM	1 día hábil
4	La asignación se registra en el registro de acceso	Equipo IAM	Mismo día
5	El acceso se revisa durante la auditoría trimestral	Dueño del sistema	Trimestral

Las solicitudes de emergencia saltan el SLA, no el control: un incident commander puede aprobar verbalmente una concesión temporal de operator, pero debe registrarse en 24 horas y expirar automáticamente.

7. Revisión y Cumplimiento

Actividad	Frecuencia	Dueño	Evidencia
Revisión de inventario de roles	Anual	Seguridad	Matriz de roles actualizada
Revisión de acceso privilegiado	Trimestral	Dueño del sistema	Registro de atestación
Limpieza de cuentas huérfanas	Trimestral	Equipo IAM	Lista de cuentas desactivadas
Aprobación de excepciones	Según necesidad	Comité de riesgo	Formulario de aceptación de riesgo

Las revisiones solo funcionan cuando la evidencia sobrevive a la revisión. Guarda los registros de atestación y el registro de acceso donde los auditores puedan consultarlos — un drive compartido funciona, una herramienta de revisión de acceso funciona mejor. La Plantilla de Revisión de Control de Acceso cubre el proceso de certificación en detalle.

Una entrada del registro es pequeña — seis campos por asignación son suficientes:

Campo	Ejemplo
requested_at	2026-10-02
user	alice@company.com
role_granted	operator
approver + ticket	j.smith + SEC-1143
provisioned_at	2026-10-03
expires_or_review	2027-01-15

Cualquier almacén sirve — una hoja de cálculo, un informe exportado del IdP, una tabla en la herramienta ITSM. Lo que los auditores realmente revisan es que exista una entrada por cada concesión y que las filas expiradas tuvieran seguimiento, no qué herramienta las produjo.

8. Baja de Personal y Cambios de Rol

Cuando alguien cambia de equipo o deja la empresa, sus roles se revocan el mismo día en que el sistema de RRHH marca la transición — no cuando alguien se acuerda. Automatiza esto con la sincronización de grupos del proveedor de identidad: elimina al usuario del grupo de origen y deja que el aprovisionamiento quite el rol. La baja manual es la primera fuente de cuentas huérfanas en las revisiones de acceso.

9. Acceso Break-Glass

El acceso de emergencia usa cuentas break-glass dedicadas, no el login diario de nadie. Las cuentas están selladas — credenciales en un vault o sobre cerrado — y cada uso dispara una alerta y una revisión post-incidente obligatoria en 24 horas. El uso de break-glass es en sí mismo un evento auditable: si nadie lo revisa, el control no existe.

10. Excepciones

Cada regla de arriba encontrará una excepción legítima: un contratista que necesita editor por un tiempo fijo, un sistema legado que no puede unirse al IdP, una ventana de migración donde un operator necesita admin temporalmente. Las excepciones solo se permiten cuando quedan por escrito — el solicitante, el control compensatorio, el aprobador y la fecha de expiración. Sin fecha de expiración, una excepción es solo una concesión permanente con papeleo extra.

Explicación

RBAC colapsa la matriz de permisos. Asignar 20 permisos directamente a 200 usuarios significa gestionar 4.000 concesiones; agrupar esos permisos en cinco roles significa gestionar ~200 asignaciones más cinco definiciones. El modelo también hace legible la intención — un manager que revisa “carol tiene editor” entiende más que “carol tiene las filas 1.247 a 1.268 en una tabla de grants”.

La contrapartida es la rigidez. Los roles capturan qué es alguien, no qué puede tocar ahora mismo. Tres familias de modelos cubren los casos que RBAC no puede:

• RBAC — el acceso sigue a la función laboral. Simple, auditable y el default correcto para la mayoría de sistemas.
• ABAC — el acceso sigue a atributos (departamento, mfa_verificado, env=producción). Maneja contexto que RBAC no puede expresar, a costa de auditorías más difíciles. Mira Implementar ABAC para la mecánica.
• ReBAC / ACL — el acceso sigue a relaciones (“dueño de este proyecto”). Las herramientas colaborativas necesitan concesiones por recurso que los roles no pueden modelar; los sistemas estilo Zanzibar resuelven ese problema a escala.

La mayoría de sistemas en producción acaban híbridos: RBAC para la capa gruesa, atributos o chequeos por recurso para los bordes. Escribe primero la política de roles de todos modos — es el documento que los auditores piden y el fallback cuando los sistemas dinámicos fallan.

El modelo tampoco puede hacer algo por sí solo: llevar registro de nada. El registro de acceso funciona como la memoria del sistema — quién pidió, quién aprobó, cuándo se aprovisionó, cuándo se revisó por última vez. Si te saltas ese log, la política describe intención sin poder demostrarla. Los auditores rara vez preguntan si tus reglas son correctas; lo que realmente quieren es la evidencia de los últimos tres trimestres.

Cómo Aplicar Esta Plantilla

1. Rellena la tabla de roles con funciones reales. Saca la lista de funciones reales de RRHH o de los team leads, no del organigrama. Si un rol existe para una sola persona, fusiónalo — los roles de un solo usuario son concesiones de permisos disfrazadas.

2. Mapea los roles a tu proveedor de identidad. Cada fila de la tabla debería traducirse a un grupo en Okta/Entra/Google Workspace o a un binding con alcance de namespace en Kubernetes. Lo que diga el documento de política, el IdP debe decirlo también — si ambos discrepan, el IdP gana en la práctica y el documento se vuelve ficción. Una tabla de mapeo mantiene honestos a ambos lados:

   Rol de política	Grupo Okta	Binding K8s	Rol AWS
   viewer	app-viewers	developer-read-only	ViewOnlyAccess
   operator	platform-operators	deployer	—
   admin	sec-admins	rbac-object-manager	AdministratorAccess
   auditor	compliance-auditors	—	SecurityAudit

3. Migra usuarios en paralelo, no en sustitución. Asigna roles manteniendo los permisos directos existentes, verifica que los usuarios siguen trabajando y luego elimina las concesiones directas en una ventana de mantenimiento con plan de rollback.

4. Versiona el documento. Guarda la política en un repositorio justo al lado del código IAM que describe. Los cambios al modelo de roles pasan por la misma revisión que los cambios de código.

5. Conecta las revisiones al calendario. Las revisiones trimestrales de acceso privilegiado y los inventarios anuales de roles fallan cuando viven en una wiki que nadie abre. Vincúlalas a tickets o tareas recurrentes con un dueño.

6. Automatiza la aplicación donde puedas. El policy-as-code (OPA, Sentinel, permission boundaries de cloud) convierte el documento de aspiracional en exigible.

Espera que el primer ciclo de revisión saque a la luz desvíos — roles que nadie usa, huecos que la plantilla no cubría, equipos que discretamente mantuvieron concesiones directas. Eso es la plantilla funcionando: anota qué cambió, actualiza la matriz de roles y deja que el siguiente ciclo confirme el arreglo. Trata la política como un documento vivo que envejece con la organización, no como un artefacto que se escribe una vez y se archiva.

Para el lado de implementación — jerarquías de roles, chequeos de permisos en código y enforcement con middleware — la receta Implementar RBAC recorre ejemplos funcionales en Python, Node.js y Java.

Medir Si la Política Funciona

Una política que nadie mide es una política que nadie sigue. Sigue trimestralmente un conjunto pequeño de números:

Métrica	Objetivo sano	Señal de alerta
Usuarios con admin	< 2 % de la plantilla	Admin permanente para trabajo diario
Asignaciones de rol sin uso (90d)	< 5 %	Roles otorgados “por si acaso”
Cuentas huérfanas por revisión	0	Cuentas activas tras la baja
Tasa de cumplimiento del SLA de aprovisionamiento	> 95 %	Solicitudes esperando pasos manuales
Excepciones abiertas > 90 días	0	Excepciones convertidas en concesiones permanentes
Usos de break-glass por trimestre	0-2	Operaciones rutinarias en break-glass

Un pico en asignaciones sin uso significa que el modelo de roles se alejó de la realidad — o los roles ya no reflejan el trabajo, o las aprobaciones se volvieron un trámite. Ambas son hallazgos de revisión, no emergencias. Revisa los números en la misma reunión que certifica el acceso privilegiado, para que las métricas y la atestación se mantengan sincronizadas.

Variantes

• Política ABAC: otorga acceso según atributos como departamento, proyecto o nivel de acreditación. Más expresiva que los roles y más difícil de auditar — úsala cuando el contexto cambia quién debe entrar, no como opción por defecto.
• Política IAM en la nube: mapea la tabla de roles a roles de AWS IAM, definiciones de Azure RBAC o bindings de GCP IAM. Cada nube añade sus propias primitivas (permission boundaries en AWS, deny assignments en Azure) que la política debe nombrar explícitamente.
• RBAC a nivel aplicación: roles dentro de una sola aplicación, independientes de la identidad corporativa. Común en SaaS multi-tenant donde tenant-admin significa algo distinto por cliente.
• RBAC orientado a clientes: modela roles de usuario final (owner, member, guest) en un producto. Misma estructura, audiencia distinta — la fila “auditor” se convierte en el rol de lectura de tu equipo de soporte.
• RBAC+ABAC híbrido: roles para el modelo grueso más chequeos de atributos encima — por ejemplo, editor más env=producción exige MFA. La mayoría de plataformas cloud lo soportan de forma nativa mediante condition keys.

Lo Que Funciona

• Empieza con tres a cinco roles y expande solo cuando una solicitud real no pueda atenderse. Cada rol que añades es un coste de mantenimiento permanente.
• Nombra los roles por funciones (editor, operator), nunca por personas o títulos de trabajo — los títulos cambian, las funciones no.
• Documenta la justificación de negocio en cada asignación. “Necesario para el lanzamiento Q4” envejece mejor que “aprobado por Dave”.
• Usa grupos y roles, no concesiones individuales, para todos excepto las cuentas break-glass.
• Exige MFA en cada rol privilegiado, y pídelo de nuevo antes de acciones sensibles donde la plataforma soporte step-up auth.
• Automatiza la revocación al cambiar de equipo o salir mediante la sincronización de grupos del IdP — las listas manuales de baja quedan obsoletas en un trimestre.
• Revisa el inventario de roles anualmente y elimina los que nadie usó. Un rol con cero asignaciones durante dos ciclos es peso muerto.
• Implementa break-glass con auditoría completa: cuenta separada y sellada, alerta en cada login y revisión obligatoria después:

# Alertar sobre uso de break-glass
def on_break_glass_login(user: str, resource: str) -> None:
    alert_security_team(
        f"Break-glass account {user} accessed {resource}. "
        f"Post-incident review required within 24 hours."
    )
    create_incident_ticket(user, resource)

• Compón roles a partir de conjuntos de permisos más pequeños en vez de crear un rol nuevo por combinación — frena la explosión de roles:

# Ejemplo de composición de roles
roles:
  deployer:
    inherits: [viewer, editor]
    adds: [deploy, restart]
  incident_commander:
    inherits: [viewer, deployer]
    adds: [scale, rollback, toggle_feature_flag]

Errores Comunes

• Explosión de roles. Veinte roles muy detallados para un equipo de cinco personas significa que nadie sabe cuál pedir. Fusiona agresivamente; el punto óptimo para la mayoría de sistemas es entre tres y siete.
• Concesiones directas fuera del modelo. Cada permiso “solo esta vez” se salta el ciclo de revisión. Dirige las excepciones por el proceso de excepciones con fecha de expiración — para eso está.
• Roles obsoletos tras transferencias. Los usuarios conservan los roles del equipo anterior “temporalmente” para siempre. Los movimientos laterales cuentan como baja para los roles del equipo anterior — revocación el mismo día, sin excepciones por solapamiento “temporal”.
• Sin separación de deberes. Deja que una misma persona despliegue y apruebe su propio despliegue y no queda control alguno — solo pasos extra con una falsa sensación de seguridad.
• admin como atajo durante incidentes. Otorgar admin permanente durante una caída y olvidar revocarlo es el hallazgo clásico. Usa elevación con tiempo limitado — un token de Vault con un tope duro de 4 horas funciona:

# Emitir un token de 4 horas para la política temp-admin
vault token create -policy=temp-admin -ttl=4h -explicit-max-ttl=4h

• Saltarse staging. Los cambios de RBAC que parecen inofensivos rompen flujos de trabajo. Prueba el nuevo conjunto de roles contra rutas reales de usuario primero:

# Verificar que un developer puede leer pero no escribir
kubectl auth can-i get pods --as=developer@company.com -n staging
# Esperado: yes
kubectl auth can-i create pods --as=developer@company.com -n staging
# Esperado: no

• Roles de auditor con acceso de escritura. Otorgar al equipo de cumplimiento permisos de edición “temporalmente” compromete la independencia que el rol existe para proteger.

Soluciones Avanzadas

RBAC de Kubernetes con role bindings

Define roles y bindings RBAC de Kubernetes para un clúster multi-equipo:

# Role: developer-read-only
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer-read-only
  namespace: team-payments
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "configmaps"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets"]
    verbs: ["get", "list", "watch"]
---
# RoleBinding: vincular developers al role
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developers-read-only
  namespace: team-payments
subjects:
  - kind: Group
    name: team-payments-developers
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer-read-only
  apiGroup: rbac.authorization.k8s.io
---
# ClusterRole: el equipo de plataforma gestiona objetos RBAC en todo el clúster
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: rbac-object-manager
rules:
  - apiGroups: [""]
    resources: ["namespaces"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources: ["roles", "rolebindings"]
    verbs: ["get", "list", "watch", "create", "update", "delete"]

Política AWS IAM con boundaries de privilegio mínimo

Define una política IAM con permission boundaries para limitar lo que los developers pueden hacer incluso con roles más amplios:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadWrite",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::team-payments-data",
        "arn:aws:s3:::team-payments-data/*"
      ]
    },
    {
      "Sid": "DenyDeleteBucket",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteBucket",
        "s3:DeleteBucketPolicy"
      ],
      "Resource": "*"
    },
    {
      "Sid": "RequireMFAForSensitiveActions",
      "Effect": "Deny",
      "Action": [
        "iam:CreateAccessKey",
        "iam:DeleteAccessKey",
        "iam:AttachUserPolicy"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Política RBAC as code con OPA Gatekeeper

Aplica reglas RBAC usando Open Policy Agent (OPA) Gatekeeper en Kubernetes. La constraint de abajo bloquea bindings a cluster-admin fuera de los equipos de plataforma y seguridad:

# Constraint: prevenir escalación de privilegios
apiVersion: constraints.gatekeeper.sh/v1
kind: K8sRequiredRoleBindings
metadata:
  name: prevent-privilege-escalation
spec:
  match:
    kinds:
      - apiGroups: ["rbac.authorization.k8s.io"]
        kinds: ["RoleBinding", "ClusterRoleBinding"]
  parameters:
    # Bloquear bindings a cluster-admin para namespaces no-platform
    forbiddenRoles:
      - cluster-admin
    allowedGroups:
      - platform-team
      - security-team

# Política OPA: validar role bindings
package k8srequiredrolebindings

violation[{"msg": msg}] {
  input.review.object.roleRef.name == "cluster-admin"
  not input.review.object.subjects[_].name in input.parameters.allowedGroups
  msg := sprintf("cluster-admin role cannot be bound to %v", [input.review.object.subjects[_].name])
}

Lecturas Adicionales

• Repositorio companion — matriz de roles descargable, manifiestos RBAC de Kubernetes, política de boundaries de AWS IAM y constraint template de OPA.
• Plantilla de Revisión de Control de Acceso — certificación periódica del modelo de acceso que define esta plantilla.
• Plantilla de Análisis de Brechas de Cumplimiento — mapea controles de acceso como estos a requisitos de marcos y rastrea la remediación.
• Plantilla de Baseline de Seguridad de Contenedores — aplica el privilegio mínimo de RBAC a cargas de Kubernetes.
• NIST — Role-Based Access Control — el modelo de referencia detrás de RBAC.
• Autorización RBAC de Kubernetes — documentación oficial de Roles, ClusterRoles y bindings.
• Permission boundaries de AWS IAM — cómo los boundaries limitan los permisos efectivos.
• OPA Gatekeeper — enforcement de policy-as-code para Kubernetes.