Delegación de roles y accesos

(Sección: Operaciones y Gestión)

1) Por qué la delegación de funciones

El objetivo es dar a cada participante (empleado, socio, servicio) exactamente tantos derechos como sea necesario y exactamente por el tiempo que sea necesario, con total trazabilidad de las acciones. Esto reduce los riesgos de fugas y abusos, acelera el onboarding y el paso de auditorías.

2) Modelo de acceso: niveles y dominios

Dominios de acceso: personas (consola/paneles), servicios (tokens de máquina), datos (tablas/objetos), infraestructura (nube/K8s), contrapartes (integraciones externas), regiones/tenantes.
Niveles de confianza: público → interno → protegido (PII/finanzas) → especialmente crítico (claves/desembolsos).
Zonas de operación: prod/staging/sandbox; la regla «de «abajo» en «arriba» - sólo a través de pipelinas aprobadas».

3) Modelos de autorización

RBAC: los roles están vinculados a tareas («Editor de contenido», «Operador de pagos»). Simple inicio, fácil de verificar.
ABAC: políticas por atributos de sujeto/recurso/contexto (región, tenante, cambio, dispositivo, puntuación de riesgo).
ReBAC (relationship-based): los derechos siguen de las relaciones (propietario del proyecto, miembro del equipo).
Híbrido: RBAC para la matriz básica, ABAC para las restricciones contextuales, ReBAC para la propiedad.

4) Acceso mínimo requerido (Privilegio Least)

Inicio - roles mínimos por defecto (sólo lectura, sin PII).
Aumento - sólo a través de una solicitud con justificación, plazo y propietario.
Límite de tiempo (TTL): los derechos se «derriten» automáticamente; prolongación - conscientemente.
Guardarrailes contextuales: región/tenant, horario de apertura, dispositivo, geo.

5) Reparto de responsabilidades (SoD)

• «Pone límites» ≠ «aprueba límites».
• «Prepara el pago» ≠ «firma el pago».
• "Escribe el código" ≠ "se publicará en prod'.
• «Admin DB» ≠ «lee PII en analítica».
• Implemente el SoD en las políticas y en los propios procesos (dos versiones, M-of-N).

6) Procesos JML (Joiner/Mover/Leaver)

Joiner: asignación automática de roles básicos por puesto/equipo/región, lista de acceso por 24h.
Mover: revisar los roles al cambiar el comando/proyecto; eliminación automática de los derechos «antiguos».
Leaver: revocación de sesiones, claves, tokens; reencarnando secretos, transfiriendo dominios con artefactos.

7) Privilegios temporales: JIT/PAM

Just-In-Time (JIT): levantamiento de derechos sobre la solicitud de 15-240 minutos con MFA y justificación de ticket.
PAM (Privileged Access Management): proxy/inicio de sesión «bajo la cuenta shell», grabación de sesión, registro de comandos.
Break-glass: acceso de emergencia con alerta instantánea, TTL corto y post-mortem obligatorio.

8) Identidades de servicios y claves

Cuentas de servicio: separadas para cada servicio y entorno, sin secretos compartidos.
Identidad de Workload: vincular los tokens a la función/sub/viru; créditos de vida corta.
Secretos: KMS/Vault, rotación, cifrado en dos partes, prohibición de entrar en los registros.
Claves de firma/pago: threshold/MPC, hardware HSM, expansión por dominios de confianza.

9) SSO/MFA/SCIM y ciclo de vida de las cuentas

SSO: IdP (SAML/OIDC), inicio de sesión único, directivas centralizadas de contraseñas/dispositivos.
MFA: obligatorio para administradores/finanzas/PII; preferiblemente FIDO2.
SCIM: Creación/eliminación/modificación automática de cuentas y grupos.
Device Posture: acceso condicional por estado del dispositivo (cifrado de disco, EDR, parches actualizados).

10) Política-como-código y verificación

Servicio de OPA/Authorization: políticas en forma de código (Rego/JSON), rugido a través de PR, pruebas.
Control de deriva: comparaciones regulares «declaradas vs en realidad».
Comprobación previa al vuelo: «¿La política permitirá tal operación?» - pruebe los casos antes del lanzamiento.

11) Acceso a los datos

Clasificación: público/interno/limitado/PII/financiero.
Presión «mínima»: agregados/máscaras en lugar de datos «crudos»; solicitudes PII - sólo a través de jobs aprobados.
Tokenization/DE-ID: sustitución de identificadores, auditoría de solicitudes.
Capas: prod → réplicas → vitrinas → agregados; acceso directo a prod-DB - sólo JIT/PAM.

12) Nube, K8s, redes

Cloud IAM: roles per-cuenta/proyecto; la prohibición «Admin» por defecto; limitar las acciones de etiquetas/carpetas.
Kubernetes: RBAC por neymspace, PSP/políticas similares sin «privilegiado», imagen-allowlist, secretos a través de CSI, cuentas de servicio por debajo.
Red: Zero-Trust (mTLS, identity-aware), acceso a jump-host - sólo JIT, grabación de sesiones SSH.

13) Socios externos e integración

Tenantes/llaves aisladas, mínimo de scopes OAuth2, fichas TTL cortas.
Webhooks: firma (HMAC/EdDSA), 'nonce + timestamp', ventana de recepción estrecha.
Rotación de claves en el horario, revocación cuando se compromete, endpoints de estado para «salud».

14) Auditoría, recertificación, presentación de informes

Immutabilidad: registros WORM, firmas de versiones de políticas, cortes de Merkle.
Recertificación: comprobación trimestral de roles críticos, mensualmente - derechos administrativos.
La cuarentena tiene razón: «60 días sin usar» → auto-retiro.
Evidence pack: descarga de la matriz de roles, SoD-positivos, solicitudes JIT, grabación de sesiones PAM.

15) Métricas y SLO

TTG (Time-to-Grant): mediana de la emisión de acceso según la solicitud estándar (objetivo ≤ 4h).
Porcentaje de accesos JIT entre los «privilegiados» (objetivo ≥ del 80%).
SoD-violaciones: 0 en prod, tiempo de eliminación ≤ 24h.
Derechos huérfanos:% de usuarios con derechos redundantes (objetivo → 0. 0x%).
Rotación de secretos: edad media del secreto (objetivo ≤ 30 días para los sensibles).
Cobertura de auditoría: 100% de acciones privilegiadas con artefactos (entradas, recibos).

16) Dashboards

Access Health: roles activos, derechos huérfanos, JIT vs permanentes.
PAM & Sessions: número de sesiones privilegiadas, duración, éxito de MFA.
SoD & Incidents: estadísticas de bloqueos, causas, MTTR.
Secrets & Keys: edad, rotación inminente, llaves «rojas».
JML: SLA de onboarding/offboarding, solicitudes atrasadas.
Audit Evidence: estado de la recertificación trimestral, completeness 100%.

17) Playbucks de incidentes

Compromiso de token/clave: revocación inmediata, búsqueda global de uso, rotación de dependencias, auditoría retro en N días.
Infracción de SoD: bloqueo de operación, desactivación temporal de rol, post-mortem y cambio de política.
Acceso no autorizado a PII: aislamiento, notificación de DPO, inventario de fugas, procedimientos legales.
Escalation abuse: congelación de JIT para la entidad/equipo, análisis de solicitudes/justificaciones, ajuste de límites de TTL.

18) Prácticas operativas

Cuatro ojos para emitir/cambiar derechos críticos.
Directorio de roles con descripciones de tareas, riesgos y operaciones válidas.
Entornos de prueba con datos anonimizados y otros roles.
Política dry-run: simulación de los efectos de los cambios antes de la aplicación.
GameDays por accesos: «pérdida de IdP», «falla de PAM», «fuga de secreto».

19) Lista de verificación de implementación

• Forme una taxonomía de roles y una matriz de SoD sobre procesos clave.
• Habilitar SSO + MFA para todos, secuencias SCIM para JML.
• Despliegue PAM/JIT, configure break-glass con alertas y TTL corto.
• Introduzca políticas de código común (OPA), revisiones a través de PR y autotestas.
• Cuentas de servicio individuales y identidad de taller; prohibición de los secretos compartidos.
• Vault/KMS, rotación regular de secretos y claves, prohibición de secretos en códigos/logs.
• Separar los ambientes y las regiones, consolidar las reglas de los accesos cruzados-regionales.
• Ejecutar dashboards y SLO, informes mensuales de recertificación.
• Realice una exploración SoD del gráfico de derechos y elimine las rutas de escalamiento.
• Enseñanzas regulares y postmortemas con items de acción.

20) FAQ

¿RBAC o ABAC?
RBAC es la capa básica de legibilidad, ABAC es el contexto y la dinámica. Use un híbrido.

¿Necesita PAM si hay JIT?
Sí: PAM da un registro de sesiones y canales de acceso privilegiado administrados.

¿Cómo reducir la «acumulación» de derechos?
TTL en roles, auto-retiro sin usar, recertificación mensual y alertas SoD.

¿Qué hacer con los contratistas externos?
Tenantes/grupos dedicados, escopetas limitadas, TTL cortos, informes obligatorios y recertificación.

Resumen: La delegación de roles y los accesos no son un «conjunto de marcas de verificación», sino un ciclo de vida de derechos: roles mínimos necesarios, SoD, JIT/PAM, políticas como código, observabilidad y recertificación regular. Un bucle de este tipo ofrece un trabajo rápido a los equipos y una seguridad predecible para el negocio y la auditoría.