Arquitectura de Apono

Visión General

Apono sigue una arquitectura SaaS con agentes ligeros (connectors) desplegados en la infraestructura del cliente. El plano de control reside en la nube de Apono, mientras que los conectores hacen el puente entre Apono y los recursos de tu infraestructura.

Componentes Principales

Apono Cloud (Plano de Control)

El plano de control es el corazón de Apono y se ejecuta completamente en la infraestructura gestionada por Apono (SaaS). Es responsable de:

• Access Engine: Motor de decisión que evalúa solicitudes de acceso contra las políticas definidas (Access Flows). Decide si el acceso debe ser aprobado automáticamente, enviado a aprobación manual o denegado.
• Access Flows (Políticas): Reglas que definen quién puede solicitar qué, con qué nivel de acceso, por cuánto tiempo y quién aprueba. Se configuran por el equipo de seguridad a través del dashboard.
• Audit Log: Registro inmutable de todas las solicitudes, aprobaciones, concesiones y revocaciones de acceso. Es la base para informes de cumplimiento.
• Dashboard: Interfaz web para configuración de políticas, visualización de accesos activos, informes de auditoría y gestión de conectores.

Apono Connector (Agente)

El connector es un componente ligero desplegado dentro de la infraestructura del cliente — generalmente como un contenedor en Kubernetes, una instancia EC2 o una VM. Es el punto de comunicación entre el plano de control de Apono y los recursos de la infraestructura.

Características importantes del connector:

• Comunicación outbound: El connector inicia la comunicación con Apono Cloud (salida), nunca al revés. Esto significa que no es necesario abrir puertos de entrada en el firewall o exponer recursos internos a internet.
• Sin almacenamiento de credenciales en Apono: El connector utiliza las credenciales locales (IAM roles, service accounts, managed identities) para interactuar con los recursos. Las credenciales no salen de la infraestructura del cliente.
• Ligero y stateless: El connector no almacena estado localmente. Toda la lógica de decisión y auditoría permanece en el plano de control.
• Alta disponibilidad: Es posible desplegar múltiples connectors para redundancia.

Integraciones con Identity Providers

Apono se integra con proveedores de identidad para autenticación y para comprender la estructura organizacional (quién pertenece a qué equipo, quién es el gestor de cada persona):

• Okta, Azure AD (Entra ID), Google Workspace: Sincroniza usuarios, grupos y jerarquías.
• SAML / OIDC: Soporte a protocolos estándar para autenticación SSO.
• SCIM: Aprovisionamiento automático de usuarios — cuando alguien es agregado o eliminado del Identity Provider, Apono refleja automáticamente el cambio.

Esta integración es fundamental para que los Access Flows funcionen correctamente, porque Apono necesita saber quién pertenece a qué grupo y quién es el gestor de quién — información que viene directamente del Identity Provider.

En la práctica, cada Access Flow define no solo quién puede solicitar y a qué recurso, sino también quiénes son los aprobadores. Esto es configurable por equipo y por recurso. Algunos ejemplos:

• El equipo backend-team solicita acceso a la base de producción → aprobación del tech lead del equipo.
• El equipo infra-team solicita acceso a una instancia EC2 vía SSM → aprobación automática (sin aprobación manual, ya que es acceso de bajo riesgo para ese equipo).
• Cualquier persona solicita acceso admin al clúster Kubernetes de producción → aprobación del gestor directo + equipo de seguridad.
• Acceso de emergencia (break-glass) → aprobación automática con auditoría reforzada.

Los aprobadores pueden definirse de diferentes formas:

• Gestor directo: Apono consulta la jerarquía del Identity Provider para identificar automáticamente quién es el gestor del solicitante.
• Personas específicas: Se define una lista fija de aprobadores (ej: "María y Juan aprueban accesos a la base de producción").
• Propietarios del recurso (resource owners): El dueño del recurso recibe la notificación y decide.
• Aprobación automática: Para accesos de bajo riesgo, la aprobación se concede automáticamente sin intervención humana.

Esta flexibilidad permite que cada equipo tenga su propio flujo de aprobación, adecuado al nivel de riesgo y a la estructura organizacional.

El Problema de la Aprobación Automática por los Líderes

En la práctica, existe un riesgo real cuando la aprobación depende exclusivamente de los líderes de equipo: tienden a aprobar todo. El líder conoce a su equipo, confía en sus ingenieros y quiere desbloquear el trabajo lo más rápido posible. El resultado es que la aprobación se convierte en una formalidad — el líder hace clic en "aprobar" sin cuestionar el motivo o evaluar el riesgo.

Esto es especialmente problemático en accesos sensibles como producción, bases de datos críticas o permisos administrativos. Un líder que aprueba todo anula el propósito del flujo de aprobación.

Para organizaciones que poseen un equipo de seguridad enfocado en IAM, lo ideal es que este equipo participe en el flujo de aprobación como una capa obligatoria. Apono permite configurar aprobaciones en múltiples niveles, donde todos los niveles necesitan aprobar para que el acceso sea concedido:

• Nivel 1 — Líder del equipo: Valida que la solicitud tiene sentido desde el punto de vista técnico y de negocio.
• Nivel 2 — Equipo de seguridad (IAM): Evalúa el riesgo, verifica si el nivel de acceso solicitado es adecuado y si la justificación es válida.

De esta forma, incluso si el líder aprueba sin cuestionar, el equipo de seguridad actúa como un gate de control que garantiza la gobernanza. Algunos ejemplos de cómo configurar esto:

• Acceso read-only a ambientes de dev/staging → aprobación solo del líder (bajo riesgo).
• Acceso read-only a producción → aprobación del líder + notificación al equipo de seguridad.
• Acceso write/admin a producción → aprobación del líder + aprobación obligatoria del equipo de seguridad.
• Acceso a bases de datos con datos sensibles (PII/financieros) → aprobación del líder + aprobación del equipo de seguridad + justificación obligatoria.

El objetivo no es burocratizar el proceso, sino garantizar que los accesos de alto riesgo pasen por quienes realmente entienden el impacto. Los accesos de bajo riesgo pueden seguir fluyendo rápidamente, mientras que los sensibles reciben la atención que merecen.

Modelo de Seguridad

La arquitectura de Apono fue diseñada con enfoque en seguridad:

• Zero trust: El connector no tiene acceso directo al plano de control más allá de lo necesario. La comunicación está cifrada (TLS) y autenticada.
• Las credenciales nunca salen del cliente: Apono Cloud nunca recibe ni almacena credenciales de acceso a los recursos. Toda la interacción con AWS, Azure, GCP y bases de datos la realiza el connector usando credenciales locales.
• Segregación de responsabilidades: El plano de control decide quién puede acceder a qué. El connector ejecuta la acción en la infraestructura. Ningún componente solo tiene poder total.
• Audit trail inmutable: Todos los eventos se registran de forma inmutable en el plano de control, garantizando trazabilidad completa incluso si el connector es comprometido.