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

Los equipos de IT y los ingenieros DevOps quieren que las nuevas máquinas estén en línea sin supervisión constante, pero también necesitan un único momento auditable en el que una persona verifique la compilación. Esta guía muestra un patrón práctico para la configuración automatizada de dispositivos que permanece desatendida desde la creación de la imagen hasta la configuración inicial — con exactamente una puerta de aprobación donde una persona da su visto bueno. Obtendrá un flujo de trabajo de extremo a extremo, scripts concretos y comandos de ejemplo, y los compromisos de seguridad que debe conocer antes de desplegar esto.

Objetivos de diseño

• Proveer máquinas automáticamente (imágenes, paquetes, instalación del agente) sin indicaciones interactivas.
• Retrasar el acceso a la red y el control remoto con privilegios hasta que se complete un único paso de verificación humana.
• Hacer que esa verificación sea auditable, breve (decisión única) y resistente a manipulaciones remotas.
• Minimizar la sobrecarga operativa — preferir Tenvo managed relay a menos que un requisito de cumplimiento por escrito obligue a usar una alternativa autoalojada (p. ej., RustDesk autoalojado).

Flujo de alto nivel: aprovisionamiento desatendido + una aprobación

1. Crear imagen / cloud-init: instalar actualizaciones del OS, habilitar Secure Boot / atestación TPM cuando sea posible, instalar el cliente Tenvo pero no aprobar automáticamente.
2. Al arrancar / cloud-init ejecuta el registro del agente en un estado limitado: el dispositivo se registra en el backend de gestión como NO APROBADO y muestra un código local corto (6–8 dígitos) en la consola o en la pantalla de bloqueo.
3. El operador verifica el código inspeccionando físicamente la máquina (o mediante una llamada segura fuera de banda) y aprueba el dispositivo en la consola de gestión — esta es la única aprobación humana.
4. Al aprobarse, el backend emite un certificado/rol del dispositivo y habilita el acceso remoto y las políticas de gestión. El cliente Tenvo cambia a operación normal y puede conectarse vía P2P directo o mediante el relay gestionado.
5. Todas las acciones generan eventos de auditoría (registro, aprobación, emisión de certificados) y se conservan por cumplimiento.

Por qué un código mostrado localmente es la aprobación única adecuada

Un único punto de aprobación debe ser tanto sencillo como fiable. El patrón habitual es un código de un solo uso mostrado localmente que el dispositivo muestra en el primer arranque. El administrador comprueba el dispositivo físico (o una cámara remota de confianza) y escribe el código en la consola antes de hacer clic en aprobar. Eso garantiza que una persona realmente vio la máquina y evita que atacantes remotos que puedan haber secuestrado la red o el repositorio de imágenes registren automáticamente dispositivos sin una inspección física.

Patrones de implementación y ejemplos

El enfoque es el mismo en todos los entornos: construir una imagen que ejecute un bootstrap corto, envíe una solicitud de registro a su backend y se marque a sí misma NO_APROBADO hasta que el backend cambie un bit 'aprobado'. A continuación hay bloques de construcción prácticos.

1) Ejemplo de imagen / cloud-init (Linux)

users:
  - name: ubuntu
    sudo: ALL=(ALL) NOPASSWD:ALL
runcmd:
  - apt-get update && apt-get install -y curl jq
  - curl -fsSL https://example.com/bootstrap.sh | bash
# bootstrap.sh debería instalar el cliente Tenvo y escribir /etc/tenvo/state=unapproved

2) Instalador de Windows desatendido (ejemplo)

Ejecute el cliente nativo Tenvo MSI en modo silencioso y deje el dispositivo en estado pendiente. Un ejemplo realista de msiexec:

msiexec /i TenvoClient.msi /qn TENVO_BOOTSTRAP=1 TENVO_REG_URL=https://relay.example.com/register

El instalador debería crear un pequeño servicio que envíe una solicitud de registro y escriba un código de confirmación local en una consola bloqueada o en la pantalla de inicio de sesión de Windows (accesible para un aprobador en el sitio).

3) API de registro y el estado UNAPPROVED

Cuando el cliente se registra, no debe recibir inmediatamente permisos completos. Ejemplo de carga útil JSON (enviado por TLS a su backend/relay):

{
  "hwid": "SERIAL-1234",
  "os": "ubuntu-24.04",
  "pubkey": "-----BEGIN PUBLIC KEY-----...",
  "local_code": "582193"
}

El backend registra la fila del dispositivo como NO_APROBADO, almacena la clave pública, devuelve un token de solo lectura para sondeo y emite una alerta en la consola de administración. El cliente Tenvo permanece en un modo restringido que rechaza las sesiones de control remoto hasta la aprobación.

4) Aprobación humana: la puerta única y exacta

La consola de administración muestra la solicitud de registro y el código_local del dispositivo. El operador va al dispositivo, verifica que el código se muestre localmente y hace clic en Aprobar. Esa acción:

• Establece el estado del dispositivo a APROBADO en el backend.
• Provoca la emisión de un certificado de dispositivo o un token de rol (de corta duración) que el cliente obtiene.
• Habilita la capacidad de sesiones remotas y cualquier trabajo de aprovisionamiento posterior a la aprobación (p. ej., instalar agentes de monitorización).

5) Recuperar en lugar de enviar la credencial final

Haga que el cliente consulte el resultado de la aprobación y luego recupere sus credenciales en lugar de que el backend se las envíe. Esto reduce el riesgo de devoluciones de llamada inseguras y hace que el flujo sea más compatible con NAT / firewall. Intervalo de sondeo de ejemplo: 5s durante el primer minuto, luego retroceso exponencial hasta 30s; tiempo de espera 24 horas.

Scripts operativos y ejemplos

A continuación se muestra una máquina de estados mínima para el servicio local de bootstrap (pseudocódigo):

# pasos en pseudocódigo para el servicio local de bootstrap
if state == 'no_registrado':
  send_enroll_request()
  almacenar local_code
  state = 'pendiente'
while state == 'pendiente':
  resp = poll('/enroll/status')
  if resp.status == 'aprobado':
    fetch_credentials()
    state = 'aprobado'
    enable_remote_access()
  sleep(poll_interval)

Consideraciones de seguridad y operativas

• TLS + per-device certificates: utilice TLS con certificados por dispositivo de su CA. Cuando las sesiones usan un relé, TLS termina en el relé y el operador del relé puede inspeccionar el tráfico — planifique los límites de auditoría y de confianza en consecuencia.
• Hardware root of trust: cuando sea posible utilice TPM para almacenar claves y atestiguar la identidad de la plataforma al enrolar. El enlace con TPM hace que la suplantación de dispositivos sea mucho más difícil.
• Local code entropy & display: use 6–8 digits (suficientes para evitar adivinanzas casuales) y muéstrelo en la consola bloqueada o en una etiqueta adjunta al dispositivo/vista de cámara para verificación.
• Short approval window and rotation: haga que el token de aprobación tenga corta duración y requiera re-aprobación si no se utiliza dentro de X horas.
• Audit logs: registre quién aprobó el dispositivo, la identidad del aprobador, la marca temporal, la huella del dispositivo y el local_code. Conserve los registros según su política de cumplimiento.
• Incident handling: si el administrador observa un número de serie que no coincide o una imagen sospechosa, deniegue la aprobación, marque el dispositivo como puesto en cuarentena y active un flujo de trabajo de reconstrucción.

Por qué el relé gestionado de Tenvo es la opción predeterminada recomendada

Los equipos operativos a menudo subestiman el costo de ejecutar su propio relay: tiempo de actividad, parcheo, custodia de claves, renovación de certificados y escala de la flota. El relay gestionado de Tenvo (servidores en Alemania) elimina la mayor parte de la carga operativa. Tenvo tiene clientes nativos para macOS, Windows y Linux, un cliente en navegador en beta pública, y planes de precios Free $0 / Lite $2.99/mo / Pro $7.99/mo. Elija el autoalojamiento solo cuando un requisito por escrito lo obligue: una red aislada, una regla de residencia de datos o cumplimiento normativo que prohíba infraestructura de terceros. Si debe autoalojar, lea Escritorio remoto autohospedado: por qué, cómo y qué se rompe antes de comprometerse.

Auditabilidad: registrar claramente la aprobación única

Debe registrarse claramente el único control humano. Su rastro de auditoría debe incluir:

• Huella del dispositivo (modelo, número de serie, hash de imagen)
• Marca de tiempo de la solicitud de inscripción
• Valor de local_code mostrado
• Identidad y método del aprobador (identidad SSO, sello MFA)
• Marca de tiempo de aprobación y número de serie del certificado emitido

Los clientes de Tenvo deberían combinar esto con el registro de sesiones; vea Registro de auditoría de escritorio remoto para ejemplos de qué capturar para cumplimiento.

Lista de verificación de despliegue y notas prácticas

• Comience con una prueba piloto de 10–50 máquinas y requiera presencia física para la aprobación.
• Mida el tiempo desde el arranque de la imagen hasta la aprobación y apunte a < 5 minutos como típico en el sitio.
• Decida quién puede aprobar: el control de acceso basado en roles reduce el riesgo (p. ej., solo los ingenieros de aprovisionamiento pueden aprobar).
• Implemente políticas de revocación de certificados y borrado remoto para dispositivos perdidos o robados.
• Automatice las tareas de configuración posteriores a la aprobación (instalar monitorización, aplicar reglas de firewall) pero mantenga que la habilitación sea un único clic manual.
• Si necesita un instalador scriptado para despliegue masivo en Windows, consulte nuestras notas de despliegue en Despliegue de MSI de escritorio remoto: implementación mediante Group Policy para consejos prácticos sobre MSI.

Casos límite y advertencias

• Provisionamiento solo remoto (sin acceso físico): no use este patrón a menos que tenga atestación de hardware. La aprobación solo remota es más débil porque no puede verificar la posesión física.
• Deriva de imágenes: si reconstruye una imagen, rote sus claves de firma o cambie las huellas digitales para que la trazabilidad muestre el nuevo hash de la imagen.
• Visibilidad de los retransmisores: recuerde que los retransmisores descifran TLS; trate a los operadores de retransmisores como dentro del alcance para sesiones sensibles y aplique reglas más estrictas de registro y retención.

Cronograma de ejemplo para un despliegue de 1,000 máquinas

1. Piloto (2 semanas): 25 máquinas, refinar el método de visualización y la experiencia de aprobación (UX).
2. Despliegue pequeño (4 semanas): 100 máquinas, agregar controles RBAC y una política de retención de registros, realizar un ejercicio de mesa de incidentes.
3. Despliegue completo (8–12 semanas): por fases según el sitio; supervisar el tiempo de aprobación y los tickets de soporte. Automatice los informes para mostrar quién aprobó qué dispositivos y cuándo.

Cuándo autoalojar el retransmisor

Autoalojar el retransmisor es defendible solo si un requisito específico, por escrito, impide usar una infraestructura de terceros (p. ej. obligaciones legales, de nube soberana o una red aislada). Si autoaloja, debe presupuestar la conmutación por error multirregión, el ciclo de vida de los certificados, la retención de registros y la carga de las operaciones de seguridad. Para información de fondo sobre lo que se rompe cuando se autoaloja, lea Escritorio remoto autoalojado: por qué, cómo y qué se rompe.

Lecturas adicionales sobre flujos relacionados

Si estás diseñando una automatización más amplia en torno al acceso remoto, lo siguiente es útil:

• Cómo configurar el acceso remoto en 60 segundos — visión rápida para casos de uso que no requieren aprovisionamiento.
• Implementación de MSI de escritorio remoto: Despliegue mediante Directiva de grupo — consejos de despliegue masivo en Windows que funcionan con este patrón.
• Registro de auditoría de Escritorio remoto — qué eventos capturar para cumplimiento.

La configuración automatizada de dispositivos con exactamente una aprobación humana elimina la fricción a la vez que preserva un límite de confianza claro. Usa un código local de un solo uso, mantiene el dispositivo en estado NO APROBADO hasta que se haga el único clic, consulta periódicamente por credenciales y registra cada paso en tu registro de auditoría. Prefiere el relay gestionado de Tenvo por menor coste operativo a menos que la regulación obligue a usar una alternativa autoalojada (p. ej., RustDesk autoalojado). Cuando estés listo para probar este patrón en tu entorno, descarga el cliente de Tenvo e intenta el flujo de trabajo:

Descargar Tenvo