Completa esta página antes de programar la primera oleada de despliegue. Nada del despliegue es difícil de conseguir. Lo que frena un despliegue es descubrir, la mañana de la primera oleada, que una decisión está en otra parte de la organización, o que la persona que puede aprobar una entrada de tráfico saliente está ausente. El inventario siguiente convierte ese descubrimiento en un formulario que alguien completa la semana anterior.
Completa el inventario de preparación en una sola sesión de trabajo, con todas las personas que tienen una respuesta en la sala. La lista de comprobación convierte después esas respuestas en filas agrupadas por fase de trabajo. La última parte indica lo que cuesta el despliegue en horas.
Cada respuesta cambia algo más adelante. Las respuestas sobre los agentes deciden qué máquinas van en qué oleada. Las respuestas sobre los equipos deciden el canal de instalación. Las respuestas de red deciden si la ruta se descubre o se proporciona. Las respuestas de identidad deciden quién administra la organización. Cuando la respuesta sea realmente «ninguno», escribe «ninguno» en lugar de dejarlo vacío, para que un lector posterior distinga una pregunta respondida de una que nunca se hizo.
| Elemento | Por qué importa |
|---|
| Qué agentes se usan y en qué máquinas | La instalación detecta los agentes presentes en una máquina y conecta cada uno. Conocer el conjunto de antemano indica qué máquinas van en qué oleada. En cuanto un agente envía datos, la consola muestra su nivel de control |
| Si algún agente se ejecuta fuera de un equipo personal | El cliente se instala una vez por máquina que ejecuta un agente, esté donde esté esa máquina. Un host de compilación o un equipo compartido que ejecuta un agente entra en el alcance igual que un portátil |
| Elemento | Por qué importa |
|---|
| Combinación de sistemas operativos y número de máquinas por sistema | El cliente se instala y se ejecuta a nivel de usuario en cada plataforma compatible, sin derechos de administrador. Las versiones mínimas son macOS 13, Windows 10 1809 o Windows Server 2019, Ubuntu 20.04 y Debian 10 |
| Arquitecturas de procesador del parque | Hay paquetes para macOS en Apple silicon e Intel, Linux x64 y arm64, y Windows x64. Windows en ARM64 y las distribuciones Linux basadas en musl, como Alpine, no son compatibles |
| El canal de distribución o de configuración que tu organización ya utiliza | Las oleadas 2 y 3 entregan la instalación por un canal que ya llega a estas máquinas. Ese canal también lleva la credencial de la oleada desde tu almacén de secretos |
| Si alguna máquina de una oleada la comparten varias personas | La instalación y el estado local son propios de cada usuario. Cada usuario de una máquina compartida hace su propia instalación |
| Elemento | Por qué importa |
|---|
| Proxy en el camino: sí o no | Decide si la ruta se descubre en la instalación o se le proporciona. Consulta Requisitos de red |
| Tipo de proxy: HTTP CONNECT, SOCKS5 o configuración automática de proxy | Los tres son compatibles. El sistema operativo evalúa el archivo de configuración automática de proxy en Windows y macOS. En Linux, define la ruta explícitamente |
| Autenticación del proxy: ninguna, Basic, Kerberos (Negotiate) o NTLM | Ninguna, Basic y Negotiate son compatibles. NTLM no lo es, por diseño: un entorno solo NTLM prevé una ruta Negotiate o sin autenticación para el cliente antes de la primera oleada |
| Inspección TLS: sí o no, y dónde está la autoridad de certificación de interceptación | La inspección no requiere ninguna excepción. La raíz de interceptación va en el almacén de confianza del sistema operativo, o se proporciona como archivo PEM en la instalación |
| Si los puntos de acceso de modelos a los que ya llegan tus agentes siguen siendo accesibles y quedan exentos del almacenamiento en búfer de respuestas y de la inspección de flujos | Tus agentes llegan a esos puntos de acceso exactamente como antes. Un dispositivo que almacena en búfer una respuesta en streaming hace que la salida del agente llegue de golpe |
| Elemento | Por qué importa |
|---|
| El proveedor de identidad SAML 2.0 de tu organización | La consola autentica una organización mediante SAML 2.0. Microsoft Entra ID, Okta, PingOne y Active Directory Federation Services se conectan así. Conectarlo requiere un administrador en cada lado |
| Dominios de correo permitidos | Los dominios permitidos y las invitaciones controlan juntos quién puede unirse a la organización |
| Directorio para buscar propietarios: Microsoft Entra ID, Okta, Google Workspace, PingOne o Active Directory | Una búsqueda de solo lectura asocia el propietario de un agente a una persona. Nunca crea ni elimina usuarios. Esta conexión es opcional |
| Quién tiene los roles owner y admin en la consola | Los roles de la consola son owner, admin, editor, viewer. Las personas invitadas empiezan como viewer, y los ajustes de identidad requieren admin |
| Elemento | Por qué importa |
|---|
Dónde se guarda la OPENLATCH_API_KEY de cada oleada y cómo llega a una máquina sin aparecer en un script | Una clave por oleada de despliegue, creada en la consola y revocada allí cuando la oleada termina. Las instalaciones gestionadas la leen de tu almacén de secretos como variable de entorno. Nunca se escribe en un script, un paquete ni una línea de comandos |
| Elemento | Por qué importa |
|---|
| Las diez máquinas de la oleada 1 y sus propietarios | La oleada 1 sigue la ruta de desarrollador. Los propietarios con nombre permiten cotejar cada máquina con el registro de agentes de la consola |
| Cómo contactarás con OpenLatch durante el despliegue | Acuerda la vía de soporte antes de la primera oleada, no durante. Consulta Operar |
Cada fila indica de dónde viene el valor y la página que bloquea. Las cuatro fases son independientes: las filas de la consola y las de red avanzan en paralelo la misma semana.
| # | Elemento | De dónde viene | Bloquea |
|---|
| 1 | Organización creada en la consola | Tu contacto de OpenLatch crea la organización e invita a su propietario. Acepta la invitación desde la dirección invitada. Los inicios de sesión posteriores empiezan en app.openlatch.ai con un paso de correo cuya comprobación en el navegador necesita challenges.cloudflare.com | Configurar la organización |
| 2 | SAML conectado y probado | La consola de administración de tu proveedor de identidad, para el identificador de entidad, la URL de inicio de sesión y el certificado o la URL de metadatos. Se introducen en la consola en Settings › SAML SSO | Configurar la organización |
| 3 | Dominios de correo permitidos definidos | Los mismos ajustes SAML que la fila 2 | Configurar la organización |
| 4 | Roles owner, admin, editor y viewer asignados | La consola, en Settings › Users. Las personas invitadas empiezan como viewer | Configurar la organización |
| 5 | Directorio elegido para buscar propietarios, opcional | La consola de administración de tu directorio. La búsqueda es de solo lectura | Configurar la organización |
| 6 | Conservación del registro de auditoría definida | La consola, en Settings › Audit Trail: 90, 180, 365 o 730 días, o un periodo personalizado, con purga automática y exportación | Configurar la organización |
| 7 | Canal de notificación por webhook o Slack, opcional | La consola, en Settings › Notification Channels | Configurar la organización |
| 8 | Credencial de la oleada creada y guardada | La consola, en API Keys de tu cuenta, desde una sesión de navegador iniciada. Guardada en el almacén de secretos de tu organización | Configurar la organización |
| # | Elemento | De dónde viene | Bloquea |
|---|
| 9 | Entrada de tráfico saliente para app.openlatch.ai en TCP 443 aprobada | Tu proceso de cambios, según la tabla de Requisitos de red | Desplegar el cliente |
| 10 | Los puntos de acceso de modelos a los que ya llegan tus agentes siguen siendo accesibles y quedan exentos del almacenamiento en búfer de respuestas y de la inspección de flujos | La configuración de tu proxy o de tu pasarela web segura | Desplegar el cliente |
| 11 | Tipo de proxy y vía de credenciales confirmados | La configuración de tu proxy, leída frente a la matriz de compatibilidad | Desplegar el cliente |
| 12 | Autoridad de certificación de interceptación disponible como archivo PEM, si el sistema operativo aún no confía en ella | La exportación de tu propia autoridad de certificación | Desplegar el cliente |
| # | Elemento | De dónde viene | Bloquea |
|---|
| 13 | Los agentes que quieres cubrir están instalados y con sesión iniciada en esas máquinas | Las propias máquinas, confirmadas con la persona que usa cada una | Desplegar el cliente |
| 14 | Instalación revisada para la ruta gestionada | La ruta gestionada en Desplegar el cliente. Lee OPENLATCH_API_KEY de tu almacén de secretos y nunca la lleva en claro | Desplegar el cliente |
| # | Elemento | De dónde viene | Bloquea |
|---|
| 15 | Lista de máquinas de la oleada 1 con sus propietarios | Tu inventario de equipos, cotejado con los propietarios de los agentes | Verificar y desplegar |
| 16 | Desarrolladores informados de que algunos agentes les piden confirmar la conexión una vez | Tu propia comunicación del despliegue, enviada antes de que empiece la oleada | Verificar y desplegar |
| 17 | Vía de soporte acordada para el despliegue | Operar | Verificar y desplegar |
| 18 | Responsable de la marcha atrás designado | Tu propia decisión: la persona que puede pausar una oleada y retirar el cliente de una máquina | Verificar y desplegar |
El despliegue del cliente se hace en tres oleadas de dos semanas. La oleada 1 instala unas diez máquinas por la ruta de desarrollador. La oleada 2 lleva unas cincuenta máquinas por el canal que ya utilizas. La oleada 3 se extiende al perímetro completo y termina con la decisión de pasarlo a operación habitual.
El esfuerzo se concentra en la primera semana, cuando se prepara la organización y se demuestra la ruta en una máquina de cada sistema operativo del parque. Después, cada oleada repite un procedimiento que ya funcionó.
| Fase de trabajo | Oleada 1 | Oleada 2 | Oleada 3 | Esfuerzo habitual |
|---|
| Preparar la consola | Conectar SAML, definir los dominios permitidos y la conservación de la auditoría, invitar a las personas, crear la credencial de la oleada | Renovar la credencial de la oleada | Traspasar la rutina de operación | Un día la primera semana, luego unas horas por semana |
| Preparar la red | Aprobar la entrada de tráfico saliente y confirmar la ruta del proxy | Revisar la ruta gestionada | Ningún cambio más | Media jornada la primera semana |
| Preparar las máquinas | Demostrar la instalación en una máquina por sistema operativo y pasar diez máquinas por la ruta de desarrollador | Llevar la instalación al canal que ya utilizas y lanzar la oleada | Extender el mismo canal a las máquinas restantes | Unos minutos por máquina tras la primera |
| Confirmar y operar | Confirmar que cada máquina instalada aparece en el registro de agentes con un propietario | Revisión semanal y revisión de la ruta gestionada | Revisión semanal y, después, la decisión de pasar a operación habitual | Una revisión semanal durante todo el despliegue |
- Completa el inventario de preparación en una sola sesión antes de programar la primera oleada. Cada casilla vacía es una decisión que alguien tomará más tarde con prisa.
- Una única entrada de tráfico saliente es obligatoria:
app.openlatch.ai en TCP 443, saliente. Todo lo demás en el camino es el tráfico propio de tus agentes, que no cambia.
- Un entorno cuyo proxy es solo NTLM bloquea el despliegue. Prevé una ruta Negotiate o sin autenticación para el cliente.
- No se necesitan derechos de administrador en una máquina. La instalación y el estado local son propios de cada usuario: una máquina compartida por varias personas necesita una instalación por usuario.
- Una
OPENLATCH_API_KEY por oleada de despliegue, guardada en tu almacén de secretos y revocada en la consola cuando la oleada termina. Nunca aparece en un script, un paquete ni una línea de comandos.
