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

Equipes de TI e engenheiros de devops querem novas máquinas online sem necessidade de supervisão, mas também precisam de um único momento auditável em que um humano verifica a instalação. Este guia mostra um padrão prático para configuração automatizada de dispositivos que permanece sem intervenção desde a criação da imagem até a configuração inicial — com exatamente uma etapa de aprovação onde um humano confirma. Você receberá um fluxo de trabalho de ponta a ponta, scripts concretos e comandos de exemplo, e as concessões de segurança a serem consideradas antes de implantar isto.

Objetivos de design

• Provisionar máquinas automaticamente (criação de imagem, pacotes, instalação do agente) sem nenhuma solicitação interativa.
• Retardar o acesso à rede e o controle remoto com privilégios até que seja concluída uma única etapa de verificação humana.
• Fazer com que essa verificação seja auditável, curta (decisão única) e resistente a adulterações remotas.
• Minimizar a sobrecarga operacional — preferir o relay gerenciado Tenvo, a menos que um requisito de conformidade por escrito exija o uso de uma alternativa hospedada localmente (por exemplo, RustDesk hospedado localmente).

Fluxo de alto nível: provisionamento sem supervisão + uma aprovação

1. Criar imagem / cloud-init: instalar atualizações do sistema operacional, habilitar Inicialização Segura / atestação TPM quando possível, instalar o cliente Tenvo, mas não aprovar automaticamente.
2. Boot / cloud-init executa o registro do agente em um estado limitado: o dispositivo se registra no serviço de gerenciamento como NÃO APROVADO e apresenta um código local curto (6–8 dígitos) no console ou na tela de bloqueio.
3. O operador verifica o código inspecionando fisicamente a máquina (ou via uma chamada segura fora de banda) e aprova o dispositivo no console de gerenciamento — esta é a única aprovação humana.
4. Após a aprovação, o back-end emite um certificado/papel de dispositivo e ativa o acesso remoto e as políticas de gerenciamento. O cliente Tenvo passa a operar normalmente e pode conectar via P2P direto ou pelo relay gerenciado.
5. Todas as ações geram eventos de auditoria (registro, aprovação, emissão de certificado) e são retidas para conformidade.

Por que um código exibido localmente é a aprovação única correta

Um ponto único de aprovação deve ser ao mesmo tempo fácil e confiável. O padrão comum é um código de uso único exibido localmente que o dispositivo mostra na primeira inicialização. O administrador verifica o dispositivo físico (ou uma câmera remota confiável) e digita o código no console antes de clicar em aprovar. Isso garante que um humano realmente viu a máquina e evita que atacantes remotos que possam ter sequestrado a rede ou o repositório de imagens inscrevam automaticamente dispositivos sem inspeção física.

Padrões de implementação e exemplos

A abordagem é a mesma em todos os ambientes: crie uma imagem que execute um bootstrap curto, envie uma requisição de registro para o seu backend e marque-se como NÃO_APROVADO até que o backend altere um bit 'aprovado'. Abaixo estão blocos de construção práticos.

1) Exemplo de imagem / 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 deve instalar o cliente Tenvo e gravar /etc/tenvo/state=unapproved

2) Instalador desatendido do Windows (exemplo)

Execute o cliente nativo Tenvo MSI silenciosamente e deixe o dispositivo em um estado pendente. Um exemplo realista de msiexec:

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

O instalador deve criar um pequeno serviço que envie uma solicitação de registro e escreva um código de confirmação local em um console bloqueado ou na tela de login do Windows (acessível a um aprovador no local).

3) API de Registro e o estado UNAPPROVED

Quando o cliente se registra, ele não deve receber direitos completos imediatamente. Exemplo de payload JSON (enviado por TLS para seu backend/relay):

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

O backend registra a linha do dispositivo como UNAPPROVED, armazena a chave pública, retorna um token somente leitura para sondagem, e emite um alerta para o console de administração. O cliente Tenvo permanece em um modo restrito que recusa sessões de controle remoto até a aprovação.

4) Aprovação humana: o único e exato ponto de controle

O console de administração exibe a solicitação de registro e o local_code do dispositivo. O operador vai ao dispositivo, verifica que o código é exibido localmente e clica em Aprovar. Essa ação:

• Define o estado do dispositivo como APPROVED no backend.
• Aciona a emissão de um certificado do dispositivo ou token de função (de curta duração) que o cliente busca.
• Habilita a capacidade de sessão remota e quaisquer tarefas de provisionamento pós-aprovação (por exemplo, instalar agentes de monitoramento).

5) Buscar em vez de enviar a credencial final

Faça com que o cliente consulte o resultado da aprovação e então recupere suas credenciais em vez de o backend enviá-las. Isso reduz o risco de retornos de chamada inseguros e torna o fluxo mais compatível com NAT / firewall. Exemplo de intervalo de sondagem: 5s para o primeiro minuto, depois recuo exponencial até 30s; tempo limite 24 horas.

Scripts operacionais e exemplos

Abaixo está uma máquina de estado mínima para o serviço de bootstrap local (pseudocódigo):

# passos pseudo para o serviço de bootstrap
if state == 'unregistered':
  send_enroll_request()
  store local_code
  state = 'pending'
while state == 'pending':
  resp = poll('/enroll/status')
  if resp.status == 'approved':
    fetch_credentials()
    state = 'approved'
    enable_remote_access()
  sleep(poll_interval)

Considerações de segurança e operacionais

• TLS + certificados por dispositivo: use TLS com certificados por dispositivo da sua CA. Quando sessões usam um relay, o TLS termina no relay e o operador do relay pode inspecionar o tráfego — planeje os limites de auditoria e de confiança de acordo.
• Root of trust de hardware: quando possível use TPM para armazenar chaves e atestar a identidade da plataforma no momento do registro. O binding do TPM torna a impersonação do dispositivo muito mais difícil.
• Entropia e exibição do código local: use 6–8 dígitos (suficiente para evitar adivinhação casual) e exiba no console bloqueado ou em uma etiqueta anexada ao dispositivo/visualização da câmera para verificação.
• Janela de aprovação curta e rotação: faça o token de aprovação expirar rapidamente e exija nova aprovação se ele não for usado dentro de X horas.
• Logs de auditoria: registre quem aprovou o dispositivo, a identidade do aprovador, timestamp, fingerprint do dispositivo, e o local_code. Mantenha os logs de acordo com sua política de conformidade.
• Tratamento de incidentes: se o administrador notar um número de série incompatível ou uma imagem suspeita, negue a aprovação, marque o dispositivo em quarentena, e acione um fluxo de trabalho de reconstrução.

Por que o relay gerenciado da Tenvo é o padrão recomendado

As equipes operacionais frequentemente subestimam o custo de operar seu próprio relay: disponibilidade, aplicação de patches, custódia de chaves, renovação de certificados e escala da frota. O relay gerenciado do Tenvo (servidores na Alemanha) elimina a maior parte da carga operacional. Tenvo tem clientes nativos para macOS, Windows e Linux, um cliente de navegador em beta público, e níveis de preços Free $0 / Lite $2.99/mo / Pro $7.99/mo. Escolha auto-hospedar apenas quando um requisito escrito o obrigar: uma rede isolada, uma regra de residência de dados ou conformidade regulatória que proíba infraestrutura de terceiros. Se precisar auto-hospedar, leia Desktop remoto auto-hospedado: por que, como e o que quebra antes de se comprometer.

Auditabilidade: registre a aprovação única de forma clara

O único portão humano deve ser claramente registrado. Sua trilha de auditoria deve incluir:

• Impressão do dispositivo (modelo, número de série, hash da imagem)
• Carimbo de data/hora da solicitação de inscrição
• Valor local_code exibido
• Identidade e método do aprovador (identidade SSO, carimbo MFA)
• Carimbo de data/hora da aprovação e número serial do certificado emitido

Clientes Tenvo devem emparelhar isso com registro de sessão; veja Registro de auditoria de desktop remoto para exemplos do que capturar para conformidade.

Checklist de implantação e notas práticas

• Comece com um piloto de 10–50 máquinas e exija presença física para aprovação.
• Meça o tempo desde a inicialização da imagem até a aprovação e tenha como meta < 5 minutos típico no local.
• Decida quem pode aprovar: controle de acesso baseado em função reduz o risco (por exemplo, apenas engenheiros de provisionamento podem aprovar).
• Implemente políticas de revogação de certificados e de limpeza remota para dispositivos perdidos ou roubados.
• Automatize tarefas de configuração pós-aprovação (instalar monitoramento, aplicar regras de firewall) mas mantenha a habilitação em si como um único clique manual.
• Se você precisar de um instalador scriptado para implantação em massa no Windows, veja nossas notas de implantação em Implantação do MSI de desktop remoto: distribuição via Group Policy para dicas práticas sobre MSI.

Casos-limite e pegadinhas

• Remote-only provisioning (no physical access): não use esse padrão a menos que você tenha atestação de hardware. A aprovação somente remota é mais fraca porque você não pode verificar a posse física.
• Deriva de imagens: se você reconstruir uma imagem, rotacione suas chaves de assinatura ou altere as impressões digitais para que o rastro de auditoria mostre o novo hash da imagem.
• Relay visibility: lembre-se que relays descriptografam TLS; trate os operadores dos relays como parte do escopo para sessões sensíveis e aplique regras mais rígidas de registro e retenção.

Exemplo de cronograma para uma implantação de 1,000 máquinas

1. Piloto (2 semanas): 25 máquinas, aperfeiçoe o método de exibição e o UX de aprovação.
2. Pequena implantação (4 semanas): 100 máquinas, adicione controles RBAC e política de retenção de logs, realize um exercício tabletop de incidentes.
3. Implantação completa (8–12 semanas): por fases por site; monitore o tempo-para-aprovação e os tickets de suporte. Automatize relatórios para mostrar quem aprovou quais dispositivos e quando.

Quando auto-hospedar o relay

Auto-hospedar o relay é justificável apenas se um requisito específico e por escrito impedir o uso de infraestrutura de terceiros (por exemplo, obrigações legais, de sovereign-cloud, ou uma rede air-gapped). Se você auto-hospedar, deve orçar failover multi-região, ciclo de vida de certificados, retenção de logs e o ônus das operações de segurança. Para contexto sobre o que quebra quando você auto-hospeda, leia Desktop Remoto Auto-Hospedado: Por que, Como, e o que Quebra.

Leitura adicional sobre fluxos relacionados

Se você estiver projetando automações mais amplas em torno do acesso remoto, os itens a seguir são úteis:

• Como Configurar o Acesso Remoto em 60 Segundos — visão geral rápida para casos de uso que não envolvem provisionamento.
• Implantação MSI de Área de Trabalho Remota: Distribuição via Política de Grupo — dicas de implantação em massa no Windows que funcionam com este padrão.
• Registro de Auditoria da Área de Trabalho Remota — quais eventos capturar para conformidade.

A configuração automatizada de dispositivos com exatamente uma aprovação humana elimina atritos enquanto preserva uma clara fronteira de confiança. Use um código local de uso único, mantenha o dispositivo no estado NÃO APROVADO até o clique único, verifique periodicamente se há credenciais e registre cada etapa no seu rastro de auditoria. Prefira o relé gerenciado da Tenvo para reduzir o custo operacional, a menos que a regulamentação force o uso de uma alternativa auto-hospedada (por exemplo, RustDesk auto-hospedado). Quando estiver pronto para testar esse padrão no seu ambiente, baixe o cliente Tenvo e experimente o fluxo de trabalho:

Baixar Tenvo