Access Flows — El Motor de Apono

En artículos anteriores, vimos cómo el Inventory cataloga los recursos, cómo los Scopes segmentan lo que cada flujo puede alcanzar y cómo funcionan los permisos internamente. Ahora llegamos a la pieza que conecta todo: el Access Flow.

El Access Flow es donde defines quién puede solicitar acceso, a qué, con qué aprobación, por cuánto tiempo y con qué permisos. Es el motor de Apono — sin él, el inventario es solo un catálogo de lectura y los Scopes son filtros sin propósito.

Anatomía de un Access Flow

Todo Access Flow se compone de cinco elementos fundamentales:

Cada uno de estos elementos es una decisión de seguridad. Detallemos cada uno.

1. Quién Solicita (Requesters)

Define qué usuarios o grupos pueden solicitar acceso a través de este flow. La configuración se realiza apuntando a grupos del Identity Provider (IdP) — como Entra ID, Okta o Google Workspace.

Buenas prácticas:

• Usa grupos del IdP, no usuarios individuales. Si un ingeniero sale del equipo, basta con eliminarlo del grupo en el IdP y pierde automáticamente el acceso a todos los flows asociados.
• Granulariza por función. En lugar de un grupo genérico "Ingeniería", usa grupos como "Backend", "Data", "SRE". Esto permite crear flows diferentes con permisos adecuados para cada función.
• Evita el grupo "Todos". Un flow disponible para toda la organización es casi siempre excesivo. Incluso en ambientes de desarrollo, restringe por equipo.

En la configuración de los requesters, Apono permite elegir entre grupos propios de Apono o grupos del Identity Provider (IdP). Siempre que sea posible, prefiere grupos del IdP — ya reflejan la estructura organizacional, son gestionados por el equipo de identidad y se actualizan automáticamente cuando alguien entra o sale de un equipo. Los grupos internos de Apono pueden ser útiles para casos puntuales, pero crear una estructura paralela de grupos genera duplicidad y riesgo de divergencia.

2. A Qué Puede Acceder (Scope + Permisos)

Aquí entran los dos elementos que definen la superficie de acceso:

• Scope — qué recursos están disponibles para este flow (definido en el artículo anterior)
• Permisos — qué nivel de acceso se concederá sobre esos recursos

Los permisos varían por tipo de recurso. Algunos ejemplos:

Recurso	Permisos Comunes	Cuándo Usar
EC2	SSM Session (shell)	Troubleshooting, debugging
RDS	SELECT only	Consulta de datos, investigación
RDS	Full Access (CRUD)	Migraciones, correcciones puntuales
S3	ReadOnly	Descarga de logs, análisis
S3	ReadWrite	Subida de archivos, correcciones
IAM	ViewOnly	Auditoría, investigación

La combinación de Scope + Permisos es lo que determina el blast radius real del flow. Un Scope amplio con permisos restringidos (ej: todos los RDS de dev, solo SELECT) puede ser aceptable. Un Scope restringido con permisos amplios (ej: un RDS específico, Full Access) también. El peligro está en Scope amplio con permisos amplios.

3. Cómo se Aprueba (Approval Policy)

La política de aprobación define qué sucede cuando alguien solicita acceso por este flow. Apono ofrece diferentes modelos:

Auto-aprobación

El acceso se concede automáticamente, sin intervención humana. El solicitante hace clic, espera unos segundos y ya tiene acceso.

Cuándo usar:

• Ambientes de desarrollo y sandbox
• Recursos de bajo riesgo con permisos restringidos
• Escenarios donde la velocidad importa más que el control individual

Cuándo evitar:

• Cualquier recurso de producción
• Recursos con datos sensibles, independientemente del ambiente

Aprobación por gestor o responsable

Una o más personas necesitan aprobar la solicitud antes de que se conceda el acceso. El aprobador recibe una notificación (email, Slack o Teams) con los detalles de la solicitud.

Cuándo usar:

• Ambientes de staging y producción
• Recursos con datos internos o de baja criticidad en producción

Buenas prácticas para aprobadores:

• Cuando hay un único aprobador, generalmente es el manager directo del equipo — el responsable que conoce el contexto del trabajo y sabe si la solicitud tiene sentido.
• Define más de un aprobador para evitar bloqueos cuando el manager está ausente (vacaciones, licencia, zona horaria diferente). Un respaldo evita que el equipo quede parado esperando aprobación.
• Elige aprobadores con contexto técnico sobre los recursos — un gestor de producto aprobando acceso a una base de datos es un control frágil
• Para recursos críticos, considera incluir a alguien del equipo de security o compliance/GRC como aprobador adicional

Múltiples aprobadores para recursos críticos

Para recursos de alta criticidad, la estrategia es configurar múltiples aprobadores en el mismo flow — por ejemplo, el gestor del equipo, el DBA y alguien de compliance. Apono notifica a todos y cualquiera de ellos puede aprobar o denegar.

Cuándo usar:

• Acceso a datos PII en producción
• Modificaciones en IAM Roles o políticas de seguridad
• Ambientes regulados (PCI-DSS, HIPAA, SOC 2)
• Cualquier escenario donde el equipo de GRC exige trazabilidad formal

La idea es que cuanto más crítico el recurso, más personas deben tener visibilidad sobre la solicitud. Incluso si solo un aprobador es necesario para conceder el acceso, el hecho de que múltiples personas sean notificadas aumenta la probabilidad de que alguien cuestione una solicitud indebida.

Punto de atención: actualmente, cuando un flow tiene múltiples aprobadores, todos reciben la notificación de aprobación al mismo tiempo. En la práctica, esto genera un broadcast innecesario — especialmente cuando el primer aprobador ya resolvió la solicitud en segundos y los demás reciben una notificación que ya no tiene utilidad. Lo ideal sería una lógica de escalamiento: notificar al aprobador primario primero y, si no responde dentro de un tiempo configurable, escalar a los demás. Esto reduciría el ruido y evitaría la fatiga de notificación que, con el tiempo, hace que los aprobadores ignoren las alertas.

Cómo Funciona la Estructura de Aprobadores

Apono permite configurar la aprobación en capas con lógica flexible. Cada flow puede tener múltiples grupos de aprobadores, y cada grupo puede contener una o más personas (o un grupo completo del IdP). La lógica de aprobación funciona en dos niveles:

Dentro de cada grupo de aprobadores:

• Cualquiera (OR) — basta con que una persona del grupo apruebe para que el grupo se considere aprobado. Útil para grupos donde cualquier miembro tiene autoridad equivalente (ej: cualquier SRE del equipo).
• Todos ellos (AND) — todas las personas del grupo necesitan aprobar. Útil cuando cada miembro aporta una perspectiva diferente que debe considerarse (ej: el DBA y el responsable de la aplicación).

Entre los grupos de aprobadores:

La misma lógica se aplica entre los grupos. Si el flow tiene Aprobador 1 (gestor) y Aprobador 2 (security):

• Cualquiera (OR) — basta con que un grupo apruebe
• Todos ellos (AND) — ambos grupos necesitan aprobar

Ejemplo práctico:

Flow: Acceso RDS Producción PII

Aprobador 1: Equipo de Data (cualquiera)
  - María (DBA)
  - Juan (DBA)

Aprobador 2: Security (cualquiera)
  - Ana (Security Engineer)
  - Carlos (Security Lead)

Lógica entre grupos: Todos ellos (AND)

En este ejemplo, cualquier DBA puede aprobar por el grupo 1, y cualquier persona de security puede aprobar por el grupo 2 — pero los dos grupos necesitan aprobar para que el acceso sea concedido. Esto combina agilidad (no depende de una persona específica) con rigor (dos áreas diferentes validan).

4. Por Cuánto Tiempo (Duration)

La duración define por cuánto tiempo el acceso permanece activo tras la aprobación. Cuando el tiempo expira, Apono revoca automáticamente los permisos — sin depender de acción manual.

Aunque Apono es una herramienta de Just-in-Time Access, hay que ser pragmático con la duración. En un mundo ideal, todo acceso sería lo más corto posible. En la práctica, si el manager necesita aprobar el mismo acceso 5 veces al día para la misma persona en los mismos recursos, el control se convierte en burocracia — y el aprobador comienza a aprobar automáticamente, lo que derrota el propósito de la herramienta.

La regla es simple: la duración debe ser proporcional al riesgo del recurso. Recursos de uso diario en ambientes de bajo riesgo deben tener duraciones más largas para evitar fricción. Recursos críticos de producción deben tener duraciones cortas, aunque generen más solicitudes — porque en esos casos, cada solicitud merece ser evaluada.

Escenario	Duración Sugerida	Justificación
Dev / Sandbox (uso diario)	1-7 días	El ingeniero usa los mismos recursos durante toda la semana. Duraciones de una semana con posibilidad de extensión evitan solicitudes repetitivas sin ganancia de seguridad
Staging (uso frecuente)	4-8 horas	Ambiente intermedio — menos sensible que producción, pero el acceso no necesita ser permanente
Troubleshooting en producción	2-6 horas	Ambiente crítico, acceso puntual. La duración corta se justifica por el riesgo
Consulta de datos PII	30 min - 1 hora	Datos sensibles exigen ventana mínima, independientemente del ambiente
Deploy o migración	2-4 horas	Operación planificada con inicio y fin definidos
Break-glass (incidente)	30 min - 1 hora	Emergencia — el mínimo para contener y diagnosticar

La fricción excesiva es enemiga de la seguridad. Cuando el proceso es demasiado pesado para tareas rutinarias, las personas buscan atajos — piden credenciales a colegas, mantienen sesiones abiertas o presionan para obtener accesos permanentes. Un flow con duración generosa en dev y auto-aprobación es más seguro que un flow restrictivo que nadie quiere usar.

Para recursos críticos de producción y datos sensibles, las duraciones cortas son innegociables. En esos casos, el costo de la fricción compensa: cada solicitud genera un registro de auditoría, y el aprobador tiene la responsabilidad real de evaluar si ese acceso tiene sentido.

El ingeniero también puede finalizar el acceso manualmente antes de que expire el tiempo, si termina la tarea antes. Esta es una buena práctica que el equipo de seguridad puede incentivar — y que refuerza la cultura de privilegio mínimo sin depender solo de temporizadores automáticos.

Los valores anteriores son sugerencias, no reglas absolutas. La duración ideal depende mucho del momento que la empresa está viviendo. Organizaciones con equipos de seguridad maduros y aprobadores dedicados pueden trabajar con ventanas más cortas. Pero empresas menores o en fase de adopción de Apono pueden necesitar duraciones mucho más largas — hasta 1 mes en algunos casos — simplemente porque no hay suficientes personas para evaluar solicitudes con frecuencia. Si nadie aprueba, las personas quedan bloqueadas y no pueden trabajar — y eso es peor que un acceso con mayor duración.

El equilibrio correcto se encuentra con el tiempo. Comienza con duraciones más generosas, monitorea el uso y ajusta conforme la madurez del proceso de aprobación aumenta.

5. Dónde Solicitar (Portal / Slack / Teams)

El Access Flow es accesible por todos los canales configurados en Apono:

• Portal Web — el dashboard de Apono, interfaz completa con todos los detalles
• Slack — vía ChatOps, solicitud y aprobación directamente en el chat
• Microsoft Teams — misma experiencia que Slack para organizaciones que usan Teams

Independientemente del canal, el flow es el mismo. La diferencia es dónde interactúa el solicitante — lo que importa es reducir la fricción para que el desarrollador use Apono en lugar de buscar atajos.

Estructurando Flows en la Práctica

La estructura de los flows debe reflejar la realidad de la organización. No existe un modelo único, pero existen patrones que funcionan bien.

Patrón 1: Un Flow por Combinación de Equipo + Ambiente + Recurso

Es el modelo más granular y seguro. Cada flow tiene un propósito claro:

Flow	Requesters	Scope	Aprobación	Duración	Permisos
Backend → EC2 Dev	Backend	ec2-dev	Auto	8h	SSM Session
Backend → EC2 Prod	Backend	ec2-prod	Gestor + SRE	2h	SSM Session
Data → RDS Dev	Data	rds-dev	Auto	4h	Full Access
Data → RDS Prod (PII)	Data	rds-prod-pii	Gestor + DBA + Compliance	1h	SELECT
SRE → EC2 Prod	SRE	ec2-prod	Gestor	4h	SSM Session
Data → S3 Prod (sensible)	Data	s3-prod-sensitive	Gestor + Security	1h	ReadOnly

Ventaja: Control total sobre cada combinación. Cada flow es auditable individualmente.

Desventaja: El número de flows crece con la combinación de equipos × ambientes × recursos. En organizaciones grandes, puede llegar a decenas de flows.

Patrón 2: Flows Agrupados por Caso de Uso

Agrupa flows por escenario de negocio en lugar de por recurso individual:

Flow	Requesters	Scopes Incluidos	Aprobación	Duración
Troubleshooting Dev	Backend + Data	ec2-dev, rds-dev, s3-dev	Auto	4h
Troubleshooting Prod	Backend + SRE	ec2-prod, rds-prod-internal	Gestor + SRE	2h
Análisis de Datos	Data	rds-prod-pii, s3-prod-sensitive	Gestor + Compliance	1h
Auditoría	Security + Compliance	Todos los scopes ReadOnly	Auto	2h

Ventaja: Menos flows que gestionar. Refleja cómo los equipos realmente trabajan.

Desventaja: Menos granularidad. Un flow de "Troubleshooting Prod" puede incluir recursos que no siempre son necesarios para la tarea específica.

¿Qué Patrón Elegir?

En la práctica, la mayoría de las organizaciones usa una combinación de ambos:

• Patrón 1 para recursos críticos (producción, PII, IAM) — control granular donde importa
• Patrón 2 para ambientes de bajo riesgo (dev, sandbox) — simplicidad donde el riesgo es menor

Lo importante es que la estructura sea revisada periódicamente. Los equipos cambian, los recursos se crean y eliminan, y la organización puede necesitar nuevos flows o ajustar los existentes.

Break-Glass: Acceso de Emergencia

No todo acceso sigue el flujo estándar. En incidentes críticos — como una caída de producción a las 3 de la mañana — esperar una cadena de aprobación no es viable. Para estos escenarios, Apono permite configurar flows de break-glass.

Un flow break-glass tiene características específicas:

• Auto-aprobación o aprobación mínima — el acceso se concede inmediatamente o con un único aprobador
• Duración corta — 30 minutos a 1 hora, el mínimo para contener el incidente
• Scope restringido — solo los recursos necesarios para diagnóstico y mitigación
• Notificación amplia — el equipo de security, gestores y compliance son notificados inmediatamente de que un acceso break-glass fue utilizado
• Auditoría reforzada — toda acción durante el acceso se registra para revisión posterior

El break-glass no es un atajo para evitar el proceso de aprobación. Es un flow formal, auditado y monitorizado. La diferencia es que la verificación sucede después del acceso, no antes. Cualquier uso de break-glass debe generar una revisión post-incidente documentada.

Justificación en la Solicitud

Una característica importante de los Access Flows es la posibilidad de exigir que el solicitante proporcione una justificación al pedir acceso. Esta justificación queda registrada en la auditoría y ayuda al aprobador a tomar una decisión más informada.

Buenas prácticas:

• Exige justificación en todos los flows de producción. Incluso si el aprobador no las lee todas, el registro existe para auditoría.
• Vincula a tickets o incidentes. Incentiva a los solicitantes a incluir el número del ticket (Jira, ServiceNow, PagerDuty) en la justificación. Esto crea trazabilidad entre el acceso y el motivo de negocio.
• En flows de auto-aprobación en dev, la justificación puede ser opcional para reducir fricción.

Errores Comunes

1. Un flow para todo

Crear un único Access Flow genérico que sirve para todos los equipos y todos los recursos. En la práctica, esto equivale a no tener segmentación — y toda la seguridad depende exclusivamente del aprobador.

2. Mismo aprobador para todo

Usar el mismo gestor como aprobador de todos los flows. Además de crear un cuello de botella (si está ausente, nadie es aprobado), el aprobador sufre de fatiga de aprobación — aprueba todo sin evaluar porque el volumen es demasiado alto.

3. No usar Scopes

Crear flows apuntando directamente a la integración sin Scope. Ya detallamos este problema en el artículo sobre Scopes — sin Scope, el solicitante ve todos los recursos y el blast radius de una aprobación es toda la integración.

4. Ignorar el break-glass

No tener un flow de emergencia hace que, en incidentes, las personas busquen atajos — como usar credenciales compartidas, pedir acceso permanente a un administrador o eludir Apono por completo. Un flow break-glass formal es más seguro que la improvisación.

5. No revisar flows periódicamente

Flows creados hace meses pueden estar desactualizados: equipos cambiaron, recursos fueron decomisionados, aprobadores dejaron la empresa. Una revisión trimestral de los flows es el mínimo recomendado — y el equipo de GRC o compliance debe estar involucrado en esta revisión.

Ciclo de Vida de una Solicitud

Para cerrar, acompañemos el ciclo completo de una solicitud de acceso por un Access Flow:

Cada etapa de este ciclo genera un registro de auditoría en Apono — quién solicitó, cuándo, por qué, quién aprobó, cuánto tiempo duró y cuándo fue revocado. Esta pista de auditoría es fundamental para compliance e investigaciones de seguridad.