Configuração automatizada de dispositivos - provisionamento não assistido com uma única aprovação

Você precisa que novas máquinas sejam provisionadas automaticamente — imagem, pacotes, um agente de IA — mas a política (ou o bom senso) exige exatamente uma aprovação humana antes que o agente assuma o controle. Este guia percorre um fluxo confiável e auditável que você pode automatizar por script de ponta a ponta e operar em escala.

Por que um único ponto de aprovação importa

A configuração automatizada sem qualquer verificação humana economiza tempo, mas aumenta os riscos: ativação acidental do agente, imagens comprometidas ou credenciais vazadas durante o provisionamento. Uma aprovação humana bem posicionada equilibra automação e controle. Ela mantém as mãos fora da longa cauda de instalações, ao mesmo tempo em que torna uma única pessoa responsável por um ponto de quebra controlado.

Design de alto nível: provisionamento com um ponto de aprovação

O padrão é simples e repetível:

• Preparar previamente a máquina: imagem do SO, criptografia de disco, contas locais, configuração base.
• Instalar o cliente do agente remoto em modo desabilitado ou restrito (agente presente, mas ainda não pode aceitar controle remoto).
• Emitir uma solicitação de aprovação assinada (metadados do host, hash do instalador, ID da build) para um aprovador humano via sua ferramenta de workflow (Slack, PagerDuty, sistema de tickets).
• O aprovador revisa os metadados e clica em um link ou executa um pequeno comando assinado que ativa o agente para o modo totalmente operacional.
• Pós-aprovação: o agente se registra no relay, os logs de auditoria registram a aprovação e políticas adicionais ou 2FA podem ser aplicadas para sessões futuras.

Quais componentes você precisa (concretos)

• Um pipeline de imagem/build que emite um build ID e o SHA256 do instalador (runner de CI, Packer, etc.).
• Um pacote de cliente remoto pré-instalado que suporte modo desabilitado/parado e uma pequena API de ativação ou endpoint de token.
• Um serviço de aprovação: pode ser um endpoint web mínimo protegido por SSO, ou uma ferramenta de tickets/ChatOps existente que execute um comando de ativação assinado.
• Logs de auditoria — armazene a identidade do aprovador, timestamp, build ID e hash do instalador. Veja Auditoria de Remote Desktop para campos recomendados e política de retenção.
• Um relay para atravessamento de NAT — o relay gerenciado do Tenvo é a recomendação padrão porque elimina a necessidade de on-call para uptime do relay, renovação de certificados e failover multi-região. Use auto-hospedagem apenas quando sua conformidade ou isolamento de rede exigir; caso contrário, o custo operacional de auto-hospedagem geralmente supera o preço anunciado. Veja Remote Desktop Auto-hospedado: Por que, Como e O que Falha.

Notas de segurança que você deve aceitar

Realidade prática de segurança: o cliente usa TLS com um certificado por dispositivo para conexões. Uma conexão peer-to-peer direta é de ponta a ponta entre os dois dispositivos; no entanto, quando o tráfego recai sobre um relay, o TLS termina nesse relay. Isso significa que quem opera o relay está em posição de ver o tráfego da sessão. Projete seu fluxo de aprovação e controles de auditoria de acordo — não presuma que o relay seja um salto não observador.

Fluxo detalhado e temporização (visão do operador)

1. A build da imagem é concluída e grava metadados: build-id, SHA256 da imagem, lista de pacotes, checksum do instalador. Armazene os metadados no seu repositório de artefatos de build.
2. A máquina inicializa, executa scripts de first-boot, aplica a imagem, cria contas locais e instala o agente em modo 'bloqueado' (processo do agente instalado, mas não aceitando sessões remotas).
3. O script de first-boot cria um objeto de solicitação de aprovação contendo host-id, build-id, hash do instalador do agente, IP (se conhecido), impressão digital do certificado do host e um HMAC de curta duração usando uma chave de provisionamento.
4. A solicitação de aprovação é postada ao canal do aprovador (ticket, mensagem no Slack com um botão de aprovação, ou um dashboard web seguro). O aprovador pode inspecionar os metadados da build e o hash do instalador. A ação de aprovação dispara seu serviço central de aprovação para emitir um token de ativação, registrado e assinado.
5. A máquina faz polling no endpoint de ativação com o nonce original da requisição e o HMAC de curta duração. Quando um token de ativação válido é retornado, o agente alterna para o modo 'habilitado', registra-se no relay e começa a aceitar sessões remotas. O evento de ativação é registrado no seu repositório de auditoria com a identidade do aprovador e o timestamp.

Exemplo prático: script de first-boot para 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"

Exemplo Windows: verificação de ativação em 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 aprovação e opções de integração

O UX mais simples e humano é uma mensagem no Slack com os metadados da build e dois botões: Aprovar ou Rejeitar. O botão Aprovar aciona seu serviço de aprovação que assina e armazena um token de ativação de curta duração. Um dashboard web é mais auditável e escala melhor para organizações maiores — exija SSO e MFA. Seja qual for a opção, registre o nome de usuário do aprovador, IP e os hashes dos artefatos; não confie em 'alguém clicou em um botão' sem metadados vinculados.

Registro de auditoria: o que registrar

No mínimo, registre estes campos para cada evento de ativação: host-id, build-id, SHA256 do instalador, identidade do aprovador (e-mail via SSO), timestamp (UTC), IP do aprovador, método de aprovação (UI/API) e ID do token de ativação. Mantenha os logs imutáveis pelo período de retenção exigido e alimente-os em um SIEM. Veja Auditoria de Remote Desktop para sugestões de schema e práticas de retenção.

Notas e recomendações específicas do Tenvo

O Tenvo oferece clientes nativos para macOS, Windows e Linux e um cliente via navegador em beta público. Nosso relay gerenciado é a recomendação padrão: fornece endpoints de relay multi-região, lida com rotação de certificados e elimina o ônus operacional de manter uma frota de relays atualizada e online. As faixas de preço são Grátis $0, Lite $2.99/mo e Pro $7.99/mo — escolha um plano que corresponda às suas necessidades de sessão, auditoria e SLA.

Na operação: use o relay gerenciado do Tenvo, a menos que um requisito documentado proíba infraestrutura de terceiros. Auto-hospede somente quando conformidade, redes isoladas ou regras de residência de dados exigirem; caso contrário, o custo contínuo de custódia de chaves, renovação de certificados TLS, projeto de failover e on-call para uptime de relay torna o relay gerenciado mais econômico ao longo do tempo. Se decidir auto-hospedar, revise nosso guia de auto-hospedagem antes de se comprometer.

Checklist de teste e validação

• Teste unitário: o pipeline de build produz build-id e SHA256 corretos. Verifique com builds reprodutíveis quando possível.
• Teste de integração: o script de first-boot posta o JSON e HMAC corretos e trata o token de ativação corretamente.
• Teste do fluxo do aprovador: confirme que o aprovador vê metadados completos (links para artefatos da build), a identidade do aprovador é registrada e o token de ativação expira após o TTL configurado.
• Teste de modo de falha: simule rejeição do aprovador ou ausência de resposta e verifique que a máquina permanece em estado desabilitado e dispara um alerta para revisão manual.
• Teste do relay: confirme conexões diretas peer-to-peer quando o NAT permitir; quando o relay for usado, verifique que você aceita o modelo de terminação no relay e tem controles apropriados.

Guia rápido de solução de problemas

• Agente nunca habilita: verifique os logs do script de first-boot, incompatibilidade da chave HMAC ou a acessibilidade de rede ao endpoint de aprovação.
• O botão de aprovação não cria token de ativação: inspecione os logs do serviço de aprovação por erros de assinatura ou assertivas SSO faltantes.
• A máquina ativa, mas não registra: verifique TLS de saída para o endpoint de relay e checar regras de firewall que bloqueiem portas do Tenvo ou resolução de DNS.
• Ativação suspeita: se a identidade do aprovador parecer errada ou os hashes não baterem, revogue imediatamente o dispositivo (desative o agente) e inicie a resposta a incidente.

Quando auto-hospedar versus relay gerenciado (guia de decisão curto)

Escolha auto-hospedagem somente se tiver um requisito documentado: uma regra de conformidade proíbe infraestrutura de terceiros, as máquinas operam em uma rede isolada sem saída para a internet, ou você precisa de residência estrita de dados. Caso contrário, o relay gerenciado do Tenvo é mais barato em termos de mão de obra e risco. Para leitura adicional sobre trade-offs, veja Como Configurar Acesso Remoto em 60 Segundos e Segurança de Área de Trabalho Remota: O que Você Precisa Saber.

Notas de escalonamento

Ao escalar para centenas ou milhares de dispositivos, mova o passo de aprovação para um grupo de aprovadores e use agrupamento: a solicitação de aprovação pode conter múltiplos host-ids e checksums (um único humano aprova todo o lote se todos os hashes corresponderem aos valores esperados). Ainda registre cada host separadamente. Adicione checagens automáticas de anomalia para sinalizar hashes divergentes e exigir aprovação por host nesses casos.

Casos de borda e pegadinhas

• Desalinhamento de relógio: tokens de curta duração exigem relógios do sistema precisos; garanta que o NTP esteja configurado antes da validação do token.
• Tratamento de rollback: se uma imagem for revertida, registre a ação de rollback na trilha de auditoria e, opcionalmente, exija nova aprovação para hosts afetados.
• Credenciais do aprovador perdidas: trate o acesso ao serviço de aprovação como qualquer plano de controle privilegiado — exija MFA e audite sessões.

Este padrão — pré-instalar um agente em estado bloqueado, emitir metadados assinados, exigir uma ativação humana explícita e registrar uma trilha de auditoria imutável — dá a velocidade do provisionamento automatizado mantendo um único gate humano responsável. Funciona tanto para implantar mil laptops de desenvolvimento quanto para entregar um agente de IA a uma frota de servidores.

Para contexto adicional sobre controle remoto conduzido por IA e políticas, leia agente de IA remoto: políticas, aprovações, auditoria e registro de auditoria do agente de IA: quais registros devem conter. Se quiser um checklist rápido para começar, nosso Como Configurar Acesso Remoto em 60 Segundos é um companheiro compacto.

Pronto para testar? Faça o download do Tenvo e valide o fluxo em uma única máquina primeiro: Faça o download do Tenvo.