Jerarquía de cuentas y subusuarios

(Sección: Operaciones y Gestión)

1) Tarea y principios

La jerarquía de cuentas define cómo las organizaciones y las personas acceden a los recursos de la plataforma y cómo se distribuyen los derechos, cuotas, presupuestos y responsabilidades.

• Separación de Concerns: la estructura empresarial se refleja en el árbol de las entidades y los derechos en las políticas.
• Privilegio Least: por defecto son los roles mínimos, la mejora temporal a través de JIT.
• Composabilidad: los roles/cuotas/límites se heredan y se redefinen.
• Policy-as-Code: políticas de acceso, cuotas, facturación - artefactos versionables.
• Auditabilidad: cada acción se correlaciona con el sujeto, el contexto y la firma.

2) Modelo de referencia de jerarquía

Tenant
├─ Account - legally/operationally significant unit
│ ├─ Sub-account - Product/Region/Team/Project
│ │ ├─ Spaces/Projects/Environments: prod/stage/dev
│ │ └─ Roles and Groups (RBAC/ABAC) for People and Services
│ └─ Shares (limits, budgets, keys, integrations)
└─ Marketplace/Integrations/Affiliates (Outer Loops)

• Tenant: propietario de contratos, facturación de alto nivel, políticas globales y SSO.
• Cuenta: zona de responsabilidad aislada (marca/país/BOE); presupuestos/límites propios.
• Sub-cuenta: unidad de trabajo (producto/flujo/comando); sus claves, cuotas, roles y auditorías.

3) Modelos de autorización

RBAC: роли Owner/Admin/Operator/Viewer/Billing/Compliance.
ABAC: атрибуты `region`, `tenant`, `account`, `environment`, `risk_score`, `device_posture`.
ReBAC: una relación de «propiedad/participación/revuit» para proyectos y secretos.

Práctica: híbrido - RBAC como base legible, ABAC para restricciones contextuales (región/tiempo/dispositivo), ReBAC para la propiedad de recursos.

4) Delegación y herencia

Delegación hacia abajo: Tenant-admin emite el rol Account Admin, el de Sub-account Maintainer.
Redefiniciones: las cuotas/límites/políticas pueden apretarse hacia abajo en el árbol.
Trust Boundaries: PII/finanzas - sólo en «zonas de confianza» de nivel de Cuenta; Sub-account ve tokens/agregados.
Break-glass: acceso de emergencia con TTL corto, alerta automática y post-mortem.

5) Cuotas, presupuestos, facturación

Cuotas: consultas/segundos, eventos/día, egresos, almacenamiento, claves/webhooks.
Presupuestos: caps y alertas mensuales (80/90/100%), auto-trotling/suspensión.
Facturación: facturas a nivel Tenant/Account; cortes por Sub-cuenta y etiquetas (centros de costo).
Transfer Pricing: intercambios internos entre BU/regiones.
Fair-use: límites públicos, rate-limits, protección contra «burst».

6) Identidades y SSO/SCIM

SSO (SAML/OIDC): entrada centralizada en el nivel Tenant.
SCIM: Creación/desactivación automática de usuarios/grupos y enlace a roles.
JML (Joiner/Mover/Leaver): auto-emisión de funciones iniciales, revisión en la traducción, revocación instantánea en el despido.
MFA/FIDO2: obligatorio para los administradores, las finanzas y el acceso al PII.
Device Posture: tolerancia por estado del dispositivo (cifrado, EDR).

7) Cuentas de servicio y claves

Service Account per Sub-account + Environment, sin secretos compartidos.
Identidad de flujo de trabajo: fichas de vida corta, referencia a la sub/función.
KMS/Vault: rotación de secretos, acceso por roles, firmas DSSE.
Webhooks: firmas HMAC/EdDSA, 'nonce + timestamp', ventana TTL.

8) Modelo de datos (simplificado)

`tenant` `{id, name, sso, billing_profile, policies[]}`

`account` `{id, tenant_id, region, legal_entity, quotas{}, budgets{}, risk_tier}`

`sub_account` `{id, account_id, product, environment, keys[], webhooks[], limits{}}`

`role` `{id, scope: tenant|account|sub_account, permissions[]}`

`membership` `{subject_id, role_id, scope_ref, ttl, justification}`

`policy` `{type: rbac|abac|sod|quota, version, rules, signature}`

`audit_event` `{who, what, where, when, trace_id, signature}`

`quota_usage` `{scope_ref, metric, window, used, cap}`

9) Contratos API

• 'POST/tenants/{ id }/accounts' - crear una cuenta (políticas/cuotas/facturación).
• 'POST/accounts/{ id }/sub-accounts' - crear Sub-account (claves, webhooks).
• 'PUT/roles/{ id}' - política de rol; 'POST/memberships' - asignar un rol.
• 'POST/access/elevate' - Mejora JIT con TTL y justificación.
• 'GET/quotas/usage' - uso/cap; 'POST/quotas/override'.

• `GET /audit/events? scope =... '- registros firmados.
• 'GET/status/access' - roles/TTL/claves actuales.
• Вебхуки: `QuotaCapReached`, `RoleExpiring`, `KeyRotationDue`, `PolicyChanged`.

10) RACI (áreas clave)

11) Métricas y SLO

TTG (Time-to-Grant): mediana de emisión de acceso estándar ≤ 4 h.
Cobertura JIT: ≥ el 80% de las operaciones privilegiadas a través de roles temporales.
SoD Violations: 0 в prod; Eliminación de TTR ≤ 24 h.
Orphaned Access: proporción de derechos de ≤ «olvidados» 0. 1%.
Quota Accuracy: coincidencia de devengo/uso ≥ 99. 99%.
Audit Completeness: 100% de acciones críticas con firma/recibo.

12) Dashboards

Access Health: funciones activas por niveles, TTL caducadas, infracciones de SoD.
FinOps: uso de cuotas, previsión presupuestaria, anomalías egress/compute.
Seguridad: rotación de llaves, fallas de MFA/SSO, cohortes de riesgo-score.
Compliance: estado de recertificación, registros de auditoría, violaciones de políticas.
Operaciones: Solicitudes de acceso MTTR, TTFI para nuevos comandos.

13) Delimitación de datos y privacidad

Dominios de datos: PII/Finanzas - sólo a nivel de Cuenta; Sub-account - agregados/tokens.
Regionalidad: localización de datos y claves por región (zonas de confianza).
Solicitudes de PII: sólo a través de jobs aprobados; tokenización y enmascaramiento.

14) Riesgos y anti-patrones

Modelo Flat: todos son «almirantes» → incidentes y fugas.
Secretos compartidos: no trazabilidad e imposibilidad de retroalimentación.
No SoD: una persona crea y aprueba pagos/límites.
Entornos inseparables: claves dev en prod; mezcla de pruebas y datos reales.
Roles «infinitos»: sin TTL/recertificación → acumulación de riesgos.
Cuotas débiles: una Sub-cuenta «come» la capacidad de todos.

15) Playbucks de incidentes

Compromiso de clave Sub-cuenta: revocación inmediata, rotación de dependencias, recuento de cuotas, auditoría de los últimos 7-30 días.
Exceso de cuotas: trottling/pauser automático, notificación del propietario, cap. temporal del presupuesto.
Violación de SoD: bloqueo de la operación, retirada temporal del rol, investigación y fijación de políticas.
Sustitución de webhooks: prohibición de recepción sin firma/fuera de TTL, re-key, status-endpoint swerok.

16) Onboarding y ciclo de vida

1. Inicialización Tenant: SSO/SCIM, perfil de facturación, políticas globales.
2. Creación de cuentas: regiones, cuotas, presupuestos, zonas de datos, roles básicos.
3. Sub-cuenta: claves/webhooks, roles de comando, integración.
4. JML/Recertificación: revisión trimestral de derechos, auto-eliminación de «dormidos».
5. EOL: archivo, revocación de claves, transferencia de propiedad, cierre de facturación.

17) Lista de verificación de implementación

• Armonizar el árbol Tenant → Account → Sub-account y las reglas de herencia.
• Describir roles (RBAC) y políticas contextuales (ABAC), matriz SoD.
• Ejecutar procesos SSO/SCIM, JML y mejoras JIT.
• Introducir cuotas/presupuestos/reglas de tope y alertas.
• Despliegue KMS/Vault, rotaciones y prohibición de secretos compartidos.
• Habilitar directivas como código, lanzamientos firmados y registros WORM.
• Configurar API/webhooks de gestión, endpoints de estado y auditoría.
• Construir dashboards Access/FinOps/Security/Compliance.
• Ejecutar GameDay: fuga de claves, tormenta de cuota, fallo de IdP, violación de SoD.
• Recertificar regularmente los roles y revisar los límites.

18) FAQ

¿Dónde mantener el límite entre Cuenta y Sub-cuenta?
Donde cambian las finanzas/cumplimiento/regulación (Cuenta) y Sub-cuenta es pro-comando/producto/entorno.

¿Se pueden «pegar» las cuotas de varios Sub-account?
Sí, a través de pools y prioridades, pero con protectores para «quemar» la capacidad.

¿Cómo puedo emitir acceso temporal rápidamente?
Aplicación JIT con MFA y TTL, autologia y post mortem para sesiones privilegiadas.

¿Necesitas llaves diferentes los miércoles?
Obligatorio: Cuentas de servicio/claves individuales para dev/stage/prod con aislamiento de redes y derechos.

Resumen: La jerarquía de cuentas y subusuarios es un marco de gobernabilidad: estructura legible de entidades, políticas heredadas, cuotas estrictas y facturación, identidades seguras y auditoría comprobada. Al implementar el híbrido RBAC/ABAC/ReBAC, JIT/SoD y policy-as-code, obtendrá un rápido acoplamiento, costos predecibles y seguridad sostenible al escalar por producto, equipo y región.