Necesitas que nuevas máquinas se aprovisionen automáticamente —imágenes, paquetes, un agente AI— pero la política (o el sentido común) exige exactamente una aprobación humana antes de que el agente tenga control. Esta guía recorre un flujo confiable y auditable que puedes scriptar de punta a punta y operar a escala.

Por qué importa una única puerta de aprobación

La configuración automatizada sin ningún punto de control humano ahorra tiempo pero aumenta riesgos: activación accidental del agente, imágenes comprometidas o credenciales filtradas durante el aprovisionamiento. Una aprobación bien situada equilibra automatización y control. Mantiene las manos fuera de la mayoría de las instalaciones mientras hace a una sola persona responsable de un punto controlado de ruptura de cristal.

Diseño a alto nivel: aprovisionamiento más una puerta de aprobación

El patrón es simple y repetible:

Preinstala la máquina: imagen del SO, cifrado de disco, cuentas locales, configuración base.
Instala el cliente remoto en modo deshabilitado o restringido (el agente presente, pero aún no puede aceptar control remoto).
Emite una solicitud de aprobación firmada (metadatos del host, hash del instalador, ID de build) a un aprobador humano vía tu herramienta de flujo de trabajo (Slack, PagerDuty, sistema de tickets).
El aprobador revisa los metadatos y hace clic en un enlace o ejecuta un pequeño comando firmado que pone al agente en modo totalmente operativo.
Post-aprobación: el agente se registra con el relay, los registros de auditoría registran la aprobación y pueden aplicarse políticas adicionales o 2FA para sesiones futuras.

Qué componentes necesitas (concretos)

Una pipeline de imágenes/build que emita un build ID y SHA256 del instalador (CI runner, Packer, etc.).
Un paquete cliente remoto preinstalado que soporte un modo deshabilitado/detenido y una pequeña API de activación o endpoint de tokens.
Un servicio de aprobación: puede ser un endpoint web mínimo detrás de SSO, o una herramienta existente de ticketing/ChatOps que ejecute un comando de activación firmado.
Registro de auditoría — almacena la identidad del aprobador, marca temporal, build ID y hash del instalador. Ver Remote Desktop Audit Logging para campos recomendados y política de retención.
Un relay para traversal de NAT — el relay gestionado de Tenvo es la recomendación por defecto porque elimina la responsabilidad on-call por uptime de relay, renovación de certificados y failover multi-región. Usa self-hosting solo cuando tu cumplimiento o aislamiento de red lo requiera; de lo contrario, el costo operativo de self-host normalmente supera el costo inicial. Ver Self-Hosted Remote Desktop: Why, How, and What Breaks.

Notas de seguridad que debes aceptar

Realidad práctica de seguridad: el cliente usa TLS con un certificado por dispositivo para las conexiones. Una conexión peer-to-peer directa es end-to-end entre los dos dispositivos; sin embargo, cuando el tráfico cae a un relay, TLS termina en ese relay. Eso significa que quien opere el relay está en posición de ver el tráfico de sesión. Diseña tu flujo de aprobación y controles de auditoría en consecuencia — no asumas que el relay es un salto no observador.

Flujo detallado y tiempos (vista del operador)

La build de imagen termina y escribe metadatos: build-id, SHA256 de la imagen, lista de paquetes, checksum del instalador. Guarda metadatos en tu artifact store.
La máquina arranca, ejecuta scripts de primer arranque, aplica la imagen, crea cuentas locales e instala el agente en modo 'bloqueado' (proceso del agente instalado pero no aceptando sesiones remotas).
El script de primer arranque crea un objeto de solicitud de aprobación que contiene host-id, build-id, hash del instalador del agente, IP (si se conoce), huella del certificado del host y un HMAC de corta duración usando una clave de aprovisionamiento.
La solicitud de aprobación se publica en el canal del aprobador (Ticket, mensaje de Slack con botón de aprobación, o dashboard web seguro). El aprobador puede inspeccionar la metadata de build y el hash del instalador. La acción de aprobación hace que tu servicio central emita un token de activación, logueado y firmado.
La máquina consulta el endpoint de activación con el nonce original de la solicitud y el HMAC de corta duración. Cuando se devuelve un token de activación válido, el agente pasa a modo 'habilitado', se registra con el relay y empieza a aceptar sesiones remotas. El evento de activación se registra en tu store de auditoría con la identidad del aprobador y la marca temporal.

Ejemplo práctico: script de primer arranque en Linux

#!/bin/bash
# /usr/local/bin/first-boot-provision.sh
set -e
BUILD_ID=$(cat /etc/build-id || echo unknown)
AGENT_PATH=/opt/tenvo-agent
PROVISION_KEY=/etc/provision.key
HOST_ID=$(hostname -f)-$(cat /etc/machine-id)
CHECKSUM=$(sha256sum ${AGENT_PATH}/installer.tar.gz | awk '{print $1}')
NONCE=$(uuidgen)
JSON=$(jq -n --arg h "$HOST_ID" --arg b "$BUILD_ID" --arg c "$CHECKSUM" --arg n "$NONCE" '{host:$h,build:$b,checksum:$c,nonce:$n}')
HMAC=$(echo -n "$JSON" | openssl dgst -sha256 -hmac "$(cat $PROVISION_KEY)" | awk '{print $2}')
# Post to approval service (HTTPS with SSO in front)
curl -s -X POST -H "Content-Type: application/json" -d "{\"payload\":$JSON,\"hmac\":\"$HMAC\"}" https://approvals.example.com/requests
# poll for activation token (short interval)
for i in {1..60}; do
  TOKEN=$(curl -sS "https://approvals.example.com/activation?host=$HOST_ID&nonce=$NONCE")
  if [ -n "$TOKEN" ] && [ "$TOKEN" != "pending" ]; then
    /opt/tenvo-agent/bin/tenvo-activate --token "$TOKEN"
    systemctl enable tenvo-agent && systemctl start tenvo-agent
    logger "Provisioning: activated by approval service"
    exit 0
  fi
  sleep 5
done
logger "Provisioning: activation timed out, leaving agent disabled"

Ejemplo Windows: comprobación de activación en PowerShell

# FirstBoot-Provision.ps1
$buildId = Get-Content C:\build-id -ErrorAction SilentlyContinue
$agentInstaller = 'C:\Program Files\Tenvo\installer.msi'
$checksum = (Get-FileHash -Path $agentInstaller -Algorithm SHA256).Hash
$hostId = (Get-WmiObject -Class Win32_ComputerSystem).Name + '-' + (Get-Content C:\Windows\System32\config\systemprofile\machine-id)
$nonce = [guid]::NewGuid().ToString()
$payload = @{host=$hostId; build=$buildId; checksum=$checksum; nonce=$nonce} | ConvertTo-Json
$hmacKey = Get-Content C:\provision\provision.key
$hmac = [System.BitConverter]::ToString((New-Object System.Security.Cryptography.HMACSHA256([System.Text.Encoding]::UTF8.GetBytes($hmacKey))).ComputeHash([System.Text.Encoding]::UTF8.GetBytes($payload))).Replace('-','').ToLower()
Invoke-RestMethod -Uri 'https://approvals.example.com/requests' -Method Post -Body (@{payload=$payload; hmac=$hmac} | ConvertTo-Json) -ContentType 'application/json'
for ($i=0; $i -lt 60; $i++) {
  $token = Invoke-RestMethod -Uri "https://approvals.example.com/activation?host=$hostId&nonce=$nonce"
  if ($token -and $token -ne 'pending') {
    # Tenvo activation command
    & 'C:\Program Files\Tenvo\tenvo.exe' activate --token $token
    Start-Service -Name tenvo-agent
    Write-EventLog -LogName Application -Source 'Provision' -EntryType Information -EventId 1000 -Message 'Agent activated'
    break
  }
  Start-Sleep -Seconds 5
}

UX de aprobación e opciones de integración

La UX más simple y humana es un mensaje de Slack con la metadata del build y dos botones: Aprobar o Rechazar. El botón Aprobar golpea tu servicio de aprobación que firma y almacena un token de activación de corta duración. Un dashboard web es más auditable y escala mejor para organizaciones grandes — exige SSO y MFA. Sea cual sea la opción, registra el nombre de usuario del aprobador, la IP y los hashes de los artefactos; no confíes en 'alguien hizo clic' sin metadata asociada.

Registro de auditoría: qué registrar

Como mínimo, registra estos campos para cada evento de activación: host-id, build-id, SHA256 del instalador, identidad del aprobador (email SSO), timestamp (UTC), IP del aprobador, método de aprobación (UI/API) y ID del token de activación. Mantén los logs inmutables durante el periodo de retención requerido y envíalos a tu SIEM. Ver Remote Desktop Audit Logging para sugerencias de esquema y mejores prácticas de retención.

Notas y recomendaciones específicas de Tenvo

Tenvo ofrece clientes nativos para macOS, Windows y Linux y un cliente web en beta pública. Nuestro relay gestionado es la recomendación por defecto: provee endpoints de relay multi-región, maneja la rotación de certificados y elimina la carga operativa de mantener una flota de relays parcheada y en línea. Niveles de precio: Free $0, Lite $2.99/mo, y Pro $7.99/mo — elige el plan que se ajuste a tus requisitos de sesión, auditoría y SLA.

Operativamente: usa el relay gestionado de Tenvo salvo que un requisito escrito prohíba infraestructura de terceros. Self-host solo cuando el cumplimiento, redes aisladas o reglas de residencia de datos lo exijan; de lo contrario, el costo continuo de custodia de claves, renovación TLS, diseño de failover y on-call para uptime del relay hace que el relay gestionado sea más económico con el tiempo. Si decides self-hostear, revisa nuestra self-hosting guide antes de comprometerte.

Checklist de pruebas y validación

Prueba unitaria: la pipeline de build produce build-id y SHA256 correctos. Verifica con builds reproducibles si es posible.
Prueba de integración: el script de primer arranque publica JSON y HMAC correctos y maneja el token de activación correctamente.
Prueba del flujo de aprobador: confirma que el aprobador ve la metadata completa (enlaces al artefacto de build), que la identidad del aprobador se registra y que el token de activación expira tras el TTL configurado.
Prueba de modo fallo: simula rechazo del aprobador o no-respuesta y verifica que la máquina permanece en estado deshabilitado y genera una alerta para revisión manual.
Prueba de relay: confirma conexiones peer-to-peer directas cuando NAT lo permite; cuando se usa relay, verifica que aceptas el modelo de terminación en relay y que tienes controles apropiados.

Guía rápida de resolución de problemas

El agente nunca se habilita: revisa los logs del script de primer arranque, desajuste de la clave HMAC o la alcanzabilidad de red al endpoint de aprobación.
El botón de aprobación no crea token de activación: inspecciona los logs del servicio de aprobación por errores de firma o aserciones SSO faltantes.
La máquina se activa pero no se registra: verifica TLS saliente hacia el endpoint de relay y revisa reglas de firewall que bloqueen puertos de Tenvo o resolución DNS.
Activación sospechosa: si la identidad del aprobador parece incorrecta o los hashes no coinciden, revoca inmediatamente el dispositivo (deshabilita el agente) e inicia respuesta a incidentes.

Cuándo self-hostear vs relay gestionado (guía corta de decisión)

Elige self-hosting solo si tienes un requisito escrito: una norma de cumplimiento prohíbe infraestructura de terceros, las máquinas corren en una red aislada sin internet saliente, o necesitas residencia de datos estricta. De lo contrario, el relay gestionado de Tenvo es más barato en mano de obra y riesgo. Para lectura adicional sobre compensaciones, ver How to Set Up Remote Access in 60 Seconds y Remote Desktop Security: What You Need to Know.

Notas de escalado

Cuando escalas a cientos o miles de dispositivos, mueve el paso de aprobación a un grupo de aprobadores y usa batching: la solicitud de aprobación puede contener múltiples host-ids y checksums (un solo humano aprueba todo el lote si todos los hashes coinciden con los valores esperados). Igual registra cada host por separado. Añade chequeos automáticos de anomalías para marcar hashes no coincidentes y requerir aprobación por host en esos casos.

Casos límite y advertencias

Desfase de reloj: los tokens de corta duración requieren relojes de sistema precisos; asegura NTP configurado antes de la validación de tokens.
Manejo de rollback: si una imagen se revierte, registra la acción de rollback en el rastro de auditoría y, opcionalmente, exige re-aprobación para los hosts afectados.
Credenciales de aprobador perdidas: trata el acceso al servicio de aprobación como cualquier plano de control privilegiado — exige MFA y audita las sesiones.

Este patrón —preinstalar un agente en estado bloqueado, emitir metadata firmada, requerir una activación humana explícita y registrar un rastro de auditoría inmutable— te da la velocidad del aprovisionamiento automatizado mientras mantiene una única puerta humana responsable. Funciona tanto si despliegas mil laptops de desarrollo como si despliegas un agente AI a una flota de servidores.

Para contexto adicional sobre control remoto impulsado por AI y políticas, lee ai agent remote desktop: policies, approvals, audit y ai agent audit log: what records must contain. Si quieres una checklist rápida para comenzar, nuestro How to Set Up Remote Access in 60 Seconds es un complemento compacto.

¿Listo para probarlo? Descarga el cliente Tenvo y prueba el flujo en una sola máquina primero: Download Tenvo.

configuración automatizada de dispositivos - desatendida con una aprobación