Skip to main content

ChatOps — Slack y Teams

Antes de configurar los Access Flows, es importante integrar Apono con las herramientas de comunicación que el equipo ya utiliza en el día a día. Sin esta integración, las solicitudes y aprobaciones de acceso quedan restringidas al dashboard web — lo que añade fricción y retrasa el proceso.

Apono soporta integración con Slack y Microsoft Teams, permitiendo que todo el flujo de solicitud y aprobación de acceso ocurra directamente en el chat, sin que nadie necesite abrir el dashboard.

¿Por Qué ChatOps?

El concepto de ChatOps aplicado al control de acceso resuelve un problema real: reducir la fricción entre necesitar un acceso y obtenerlo. Si el desarrollador necesita abrir una pestaña separada, hacer login en otro portal y llenar un formulario para solicitar acceso, la tendencia es que busque atajos — como pedir credenciales a un colega o mantener accesos permanentes "por conveniencia".

Con Apono integrado a Slack o Teams:

  • El solicitante pide acceso sin salir del chat — con un simple comando o interacción.
  • El aprobador recibe la notificación en el mismo lugar donde ya trabaja y aprueba con un clic.
  • El acceso se concede en segundos y se revoca automáticamente cuando el tiempo expira.

Esto transforma el JIT Access de un proceso burocrático en algo natural dentro del flujo de trabajo del equipo.

El Proceso Tradicional vs. ChatOps

Para entender el impacto del ChatOps, considera el flujo que la mayoría de las organizaciones sigue hoy cuando un desarrollador necesita un permiso temporal — por ejemplo, acceso de lectura a una base de datos de producción para investigar un incidente:

Sin Apono (Proceso Tradicional)

  1. El desarrollador abre un ticket en Jira (o ServiceNow, Freshdesk, etc.) describiendo el acceso necesario y la justificación.
  2. El ticket entra en la cola del Service Desk.
  3. El Service Desk analiza y redirige al equipo responsable (ej: equipo de IAM, DevOps, DBA, etc).
  4. El responsable evalúa la solicitud, verifica si tiene sentido, y ajusta el role o policy manualmente en la consola de AWS o vía IaC.
  5. El desarrollador es notificado de que el acceso fue concedido.
  6. Después del uso, alguien necesita recordar revocar el acceso — o queda activo indefinidamente.

Tiempo total: de horas a días, dependiendo de la disponibilidad de los equipos involucrados y la prioridad del ticket. Durante un incidente en producción, este tiempo de espera puede significar la diferencia entre una resolución rápida y un downtime prolongado.

Con Apono + ChatOps

  1. El desarrollador escribe /apono en Slack y selecciona el recurso y el permiso.
  2. El aprobador recibe la notificación en Slack y hace clic en Approve.
  3. El acceso se concede automáticamente por Apono en segundos.
  4. Después del tiempo definido, el acceso se revoca automáticamente — sin acción manual.

Tiempo total: segundos a minutos. Todo documentado en el audit log, sin tickets, sin redireccionamientos, sin olvidos.

La diferencia no es solo de velocidad — es de modelo. En el proceso tradicional, el control de acceso depende de que las personas recuerden hacer y deshacer cosas. Con Apono, el sistema garantiza que el acceso se concede solo cuando es aprobado y se revoca cuando expira, sin depender de la memoria humana.

Integración con Slack

Slack es la integración más común y completa de Apono. La configuración se realiza a través de un Slack App (Bot) que se instala en el workspace de tu organización.

Configurando el Slack Bot

  1. En el dashboard de Apono, navega hasta SettingsIntegrationsSlack.
  2. Haz clic en Connect — esto redirige a Slack para autorizar la instalación del app.
  3. Autoriza el app en el workspace deseado con los permisos solicitados.
  4. Después de la autorización, el bot aparece como Active en el dashboard de Apono.

El bot necesita permisos para:

  • Enviar mensajes en canales y DMs.
  • Recibir interacciones (clics en botones de aprobación).
  • Leer información básica del workspace (usuarios, canales).

Apono no lee mensajes de los canales o conversaciones. Los permisos son exclusivamente para enviar notificaciones y recibir interacciones de aprobación.

Qué Hace el Bot en la Práctica

Después de la instalación, el Slack Bot de Apono actúa en dos momentos principales:

Solicitud de Acceso

El usuario puede solicitar acceso directamente por Slack de dos formas:

  • Comando /apono — abre un formulario interactivo (modal) donde el usuario selecciona el recurso, el tipo de permiso y la justificación.
  • Mensaje directo al bot — el bot guía al usuario paso a paso en la solicitud.

El formulario de solicitud respeta los Access Flows configurados — el usuario solo ve los recursos y permisos que los flows permiten para él.

Notificación y Aprobación

Cuando una solicitud requiere aprobación manual, el aprobador recibe un mensaje en Slack con:

  • Quién está solicitando el acceso.
  • Qué — qué recurso y tipo de permiso.
  • Por qué — la justificación proporcionada por el solicitante.
  • Por cuánto tiempo — la duración del acceso solicitado.
  • Botones de acciónApprove y Deny directamente en el mensaje.

El aprobador hace clic en Approve o Deny sin salir de Slack. La decisión se registra en el audit log de Apono con el timestamp y la identidad del aprobador.

Auto-Aprobación en Slack

Cuando un Access Flow está configurado con aprobación automática, el flujo en Slack es aún más rápido:

  1. El usuario solicita vía /apono.
  2. Apono evalúa el flow y aprueba automáticamente.
  3. El usuario recibe la confirmación en Slack en segundos — sin intervención de nadie.

Esto es ideal para ambientes de desarrollo donde el objetivo es dar acceso rápido sin burocracia, pero manteniendo el registro completo en el audit log.

Integración con Microsoft Teams

Apono también soporta integración con Microsoft Teams, siguiendo el mismo concepto de Slack. La configuración se realiza a través del marketplace de apps de Teams o directamente por el dashboard de Apono.

El flujo es similar:

  • Solicitud de acceso vía bot en Teams.
  • Notificaciones de aprobación con botones interactivos.
  • Registro completo en el audit log.

Si tu organización utiliza ambos (Slack y Teams), es posible configurar los dos simultáneamente. Cada Access Flow puede dirigirse a la herramienta más adecuada según el equipo.

Portal Self-Service (Dashboard)

Además de Slack y Teams, Apono mantiene un portal self-service en su propio dashboard web. Este portal está siempre disponible como fallback — incluso si las integraciones de chat están configuradas, cualquier usuario puede acceder al dashboard para solicitar accesos.

El portal es especialmente útil para:

  • Usuarios que no tienen acceso a Slack/Teams (ej: auditores externos, consultores).
  • Visualizar el historial de solicitudes anteriores.
  • Acompañar el estado de solicitudes pendientes.

¿Cuál Configurar Primero?

La recomendación es configurar la integración con Slack (o Teams) antes de crear los Access Flows. Así, cuando los flows sean activados, las notificaciones ya tienen a dónde ir y el equipo ya puede interactuar con el sistema de forma natural.

ChatOps no es solo una conveniencia — es lo que transforma Apono de una herramienta de seguridad en un flujo de trabajo integrado al día a día del equipo. Cuando solicitar y aprobar acceso es tan simple como enviar un mensaje en Slack, la adopción ocurre naturalmente y la resistencia al cambio disminuye significativamente.