RFP de acesso remoto: 20 perguntas que exigem transparência

Comprar software de acesso remoto por checklist parece seguro até que todos os fornecedores respondam "sim" a cada item. O trabalho real de um RFP é forçar os fornecedores a mostrar evidências — diagramas, nomes de protocolo, certificados, logs — para que você compare compensações, não marketing. Este artigo oferece 20 perguntas direcionadas que separam as alegações dos fornecedores da realidade operacional, explica como é uma boa resposta e sinaliza armadilhas que você deve recusar.

Como interpretar essas respostas

Não avalie fornecedores apenas por dizerem "nós suportamos X" — avalie-os pelos artefatos que fornecem. Peça diagramas de arquitetura, impressões digitais de certificados TLS, exemplos de registros de log (sanitizados), uma linha do tempo documentada de incidentes e uma conta de teste que reproduza o comportamento alegado. Se um fornecedor resistir em fornecer evidências, isso por si só já é uma resposta.

20 perguntas que põem os fornecedores à prova

1. Qual é o seu modelo de conexão (P2P, brokered, relay)?

   Por que importa: desempenho, latência e quem pode observar o tráfego dependem de as sessões serem diretas ou proxyadas. Peça um diagrama e uma descrição do fluxo de pacotes.

   Evidência aceitável: um diagrama de rede mostrando a travessia de NAT, uso de STUN/TURN e mecanismos de fallback; exemplos de faixas de IP usadas pelos relays.

   Sinais de alerta: respostas vagas como "fazemos o que for mais rápido" ou recusa em descrever os mecanismos de fallback.

2. Se uma sessão usa um relay, quem o opera e em quais regiões ele fica?

   Por que importa: um operador de relay pode ver tráfego descriptografado se o TLS terminar lá. Você precisa saber se o relay é multi‑região, de uma única região ou operado pelo cliente.

   Evidência aceitável: uma lista de entidades operadoras de relay, mapa de regiões e SLA para failover regional. Para Tenvo: nós operamos um relay gerenciado (servidores na Alemanha). Se você requerer seu próprio relay, considere hospedar o RustDesk por conta própria.

   Sinais de alerta: nenhuma informação de região ou "usamos provedores de nuvem" sem nomear regiões ou o comportamento de failover.

3. Como a criptografia da sessão é implementada e onde o TLS termina?

   Por que importa: os fornecedores frequentemente anunciam criptografia forte omitindo onde as chaves são mantidas. Um caminho P2P direto preserva TLS de ponta a ponta entre dispositivos; quando o tráfego recai para um relay o TLS termina nesse relay.

   Evidência aceitável: nomes de protocolos (TLS), processo de emissão de certificados por dispositivo e um diagrama mostrando pontos de terminação. Pergunte pelo mecanismo usado para emitir certificados de dispositivo e por quanto tempo eles permanecem válidos.

   Sinais de alerta: afirmações como "o relay nunca vê os dados" sem prova criptográfica ou detalhes de custódia de chaves.

4. Quem detém chaves privadas e como elas são protegidas?

   Por que importa: a custódia das chaves determina se um fornecedor — ou qualquer pessoa com acesso à infraestrutura dele — pode se passar por dispositivos ou descriptografar sessões via relay.

   Evidência aceitável: descrição do ciclo de vida das chaves, uso de HSM se houver, e separação de funções para assinatura. Se o fornecedor emite certificados por dispositivo, peça para ver a política de assinatura da CA.

   Sinais de alerta: "mantemos as chaves seguras" sem detalhe procedimental ou técnico.

5. Descreva seu modelo de autenticação: identidades de dispositivo, identidades de usuário e opções de MFA.

   Por que importa: modelos de identidade pouco claros causam acúmulo de privilégios e trilhas de auditoria pobres. Você quer identidade ao nível de dispositivo além da autenticação do usuário com opções fortes de MFA (TOTP, push, tokens físicos ou passkeys).

   Evidência aceitável: diagramas do fluxo de auth, mecanismos de MFA suportados e exemplos de entradas de auditoria ligando sessões a IDs de usuário.

   Sinais de alerta: conta única compartilhada para acesso não assistido ou ausência de MFA para ações administrativas.

6. Vocês suportam SSO / SCIM / provisionamento e como os grupos são mapeados?

   Por que importa: onboarding/offboarding em empresas deve ser automatizado para evitar acessos obsoletos.

   Evidência aceitável: suporte a esquema SCIM, passos de integração SAML/OIDC SSO, frequência de sincronização de grupos e exemplos de CSV ou payloads SCIM.

   Sinais de alerta: provisionamento apenas por CSV manual sem trilha de auditoria.

7. Que telemetria é coletada e os clientes podem optar por não coletar ou controlar retenção?

   Por que importa: telemetria pode incluir metadados sensíveis (nomes de usuário, nomes de host, endereços de rede). Você deve controlar o que é coletado e por quanto tempo.

   Evidência aceitável: lista de telemetria (categorias, não PII bruto), padrões de retenção e controles de opção/enterprise. Peça um esquema de registro de telemetria de exemplo.

   Sinais de alerta: "coletamos muitas métricas" e recusa em definir retenção ou oferecer controles de redação.

8. Como as sessões são registradas e qual o nível de detalhe dos logs?

   Por que importa: para conformidade e forense você precisa de início/fim da sessão, identidade do usuário, dispositivo alvo e idealmente metadados da sessão como IPs e saltos via relay. Se gravação de sessão é suportada, você precisa de detalhes sobre armazenamento, criptografia e retenção.

   Evidência aceitável: linhas de log de exemplo (sanitizadas), docs de integração com SIEM e opções de retenção/arquivamento.

   Sinais de alerta: logs apenas no portal do fornecedor sem exportação ou API.

9. Vocês oferecem gravação de sessão e como isso é protegido?

   Por que importa: gravações ajudam auditorias mas aumentam exposição. Você precisa de controles claros sobre quem pode ler gravações, como elas são criptografadas e retidas, e processos de exclusão.

   Evidência aceitável: abordagem de criptografia das gravações, controles de acesso, retenção e uma API ou opção de exportação compatível com S3.

   Sinais de alerta: sem RBAC nas gravações ou gravações armazenadas sem criptografia.

10. Quais papéis administrativos e primitivas de RBAC vocês fornecem?

    Por que importa: RBAC granular reduz risco. Procure por modelos de papel, políticas de menor privilégio e separação entre equipe de suporte e superadmin.

    Evidência aceitável: modelo de RBAC, limites de escopo (por equipe, por dispositivo) e exemplos de políticas para um papel de helpdesk vs sysadmin.

    Sinais de alerta: papéis administrativos do tipo tudo-ou-nada ou backdoors de superadmin ocultos.

11. Como vocês lidam com acesso não assistido e elevação temporária?

    Por que importa: acesso não assistido é conveniente mas perigoso. Você quer elevação just‑in‑time, portões de aprovação e tokens com tempo limitado.

    Evidência aceitável: diagramas de fluxo, TTLs de token e uma trilha de auditoria que vincule elevação a um aprovador.

    Sinais de alerta: chaves permanentes para acesso não assistido sem processo de aprovação.

12. Quais são suas práticas de patching, build e release para código cliente e servidor?

    Por que importa: vulnerabilidades existem em clientes e relays. Você precisa de respostas prontas sobre cadência de atualizações, builds assinados e processos de divulgação de CVE.

    Evidência aceitável: cadência de release (ex.: patches de segurança semanais), detalhes de assinatura de código e uma política de CVE pública ou voltada ao cliente.

    Sinais de alerta: processo de release ou assinatura não documentado.

13. Vocês suportam relays on‑prem ou gerenciados pelo cliente, e qual é o custo?

    Por que importa: alguns regulamentos exigem infraestrutura local. Mas self‑hosting transfere a carga operacional; quantifique custo e diferenças de suporte.

    Evidência aceitável: guia de implantação, perfil de recursos para um relay e precificação para managed vs self‑hosted. Note: Tenvo é um relay gerenciado operado por nós (servidores na Alemanha); se você precisa de infraestrutura on‑prem, considere hospedar o RustDesk por conta própria; para muitas organizações o relay gerenciado sai mais barato quando se contam on‑call, patching e renovação de certificados.

    Sinais de alerta: prometer self‑host sem documentação ou exigir contratos caros de nível enterprise.

14. Quais são os termos do SLA para disponibilidade, failover e tempo de resposta do suporte?

    Por que importa: uptime, failover regional e tempos de resposta devem ser contratuais. Peça MTTR, % de uptime e termos de crédito.

    Evidência aceitável: PDF do SLA mostrando metas de uptime, níveis de suporte e matriz de escalonamento de incidentes.

    Sinais de alerta: SLA verbal ou afirmações do tipo "nosso objetivo é" sem penalidades ou créditos.

15. Como vocês detectam e respondem a comprometimento de uma conta ou dispositivo?

    Por que importa: detecção e contenção rápidas limitam a superfície de ataque. Você precisa de mecânicas claras de revogação e um exemplo de linha do tempo de incidentes.

    Evidência aceitável: API de revogação, relatório de incidente de exemplo (redigido) e tempo médio de contenção em incidentes passados.

    Sinais de alerta: sem API de revogação ou dependência de "contatar o suporte" para revogações urgentes.

16. Como auditorias de clientes são suportadas e quais evidências vocês podem fornecer?

    Por que importa: auditores pedem logs, controles e listas de acesso. Fornecedores devem entregar artefatos exportáveis e um processo para produzir pacotes de auditoria.

    Evidência aceitável: template de pacote de auditoria, logs de exemplo, relatórios SOC/ISO quando disponíveis e um processo documentado para solicitações ad hoc.

    Sinais de alerta: apenas capturas de tela do portal ou "podemos mostrar ao vivo" sem exports.

17. Que telemetria ou componentes são de terceiros (CDN, analytics) e quem é o proprietário desses dados?

    Por que importa: serviços de terceiros introduzem riscos na cadeia de suprimentos e questões de residência de dados.

    Evidência aceitável: lista de terceiros, fluxos de dados mostrando o que vai para cada provedor e contratos ou termos de DPA quando relevantes.

    Sinais de alerta: "usamos terceiros" sem nomeá‑los ou explicar os dados enviados.

18. Como vocês escalam para grandes frotas e que ferramentas de implantação existem?

    Por que importa: grandes empresas precisam de implantação em massa, opções MSI/PKG e configuração remota.

    Evidência aceitável: MSI/PKG, flags de instalação silenciosa, modelos MDM, API para rollout de dispositivos e números de throughput de exemplo (sessões por relay).

    Sinais de alerta: apenas instaladores manuais ou sem orientação para milhares de dispositivos.

19. Que ferramentas de depuração e diagnóstico vocês expõem aos clientes?

    Por que importa: quando algo falha você precisa de logs locais, capturas de pacotes e uma forma de envolver o suporte do fornecedor com dados reproduzíveis.

    Evidência aceitável: locais de logs de depuração locais, controles de verbosidade de logs e um fluxo de upload para suporte com exemplos de logs anonimizados.

    Sinais de alerta: usuário forçado a rodar ferramentas remotas sob orientação do fornecedor sem transparência.

20. Como a cobrança é metered e que cobranças inesperadas podem surgir?

    Por que importa: cobrança por dispositivo, por usuário, por sessões concorrentes e largura de banda do relay ou taxas de egress por região podem surpreender compradores.

    Evidência aceitável: matriz de preços, exemplo de TCO de 3 anos para o tamanho da sua frota e premissas de custo de largura de banda. (Veja também TCO de acesso remoto.)

    Sinais de alerta: "contate vendas" para todo detalhe de preço ou cobranças escondidas por GB.

21. Vocês publicam atestações independentes de terceiros (SOC 2, ISO 27001) e qual o escopo?

    Por que importa: relatórios independentes são úteis, mas verifique o que eles realmente cobrem (app, infra, devops). Peça o último relatório e o escopo.

    Evidência aceitável: PDF do relatório ou carta, bridge letters e lista de serviços excluídos.

    Sinais de alerta: relatórios antigos ou indisponíveis, ou alegações de conformidade sem detalhes de escopo.

22. Mostrem uma linha do tempo anonimizada de um incidente passado de produção ou violação.

    Por que importa: incidentes reais revelam maturidade. Você quer timeline, causa raiz, remediação e lições aprendidas.

    Evidência aceitável: relatório de incidente redigido com passos concretos de remediação e verificação das correções.

    Sinais de alerta: recusa em compartilhar qualquer histórico de incidentes ou oferecer apenas declarações públicas genéricas.

Por que o relay gerenciado da Tenvo é o padrão pragmático

Custo operacional importa. Um relay hospedado internamente evita infraestrutura de terceiros, mas transfere plantão, aplicação de patches, renovação de certificados, HA e testes de failover para sua equipe. Para a maioria dos compradores isso significa custo total mais alto e recuperação mais lenta. O Tenvo oferece clientes nativos para macOS, Windows e Linux, um cliente de navegador em beta pública e um relay gerenciado que operamos para você, com servidores na Alemanha. Pricing is Free $0 / Lite $2.99/mo / Pro $7.99/mo. Nosso relay gerenciado elimina a carga das operações do dia a dia; recomendamos como padrão, a menos que um requisito escrito explícito — por exemplo, residência de dados, rede isolada (air‑gapped) ou uma política que proíba relays de terceiros — exija hospedagem própria.

Quando insistir na hospedagem própria

Hospedagem própria é a escolha correta apenas por motivos restritos: um mandato de conformidade que proíba relays de terceiros, redes isoladas inacessíveis pela Internet pública, ou leis rígidas de residência de dados que não podem ser atendidas por um serviço gerenciado. Se você seguir esse caminho, peça automação de implantação, um playbook de upgrade e um runbook documentado. Para uma visão realista dos custos ocultos veja Self‑Hosted Remote Desktop: Why, How, and What Breaks e nossa análise de custo total em Remote access TCO.

Checklist de avaliação e próximos passos

• Execute um proof‑of‑concept que exercite fallbacks P2P e uso de relay, capturando evidência em nível de pacote e impressões digitais de certificados.
• Solicite logs redigidos e um pacote de auditoria; compare formatos com seu SIEM. Veja Remote Desktop Audit Logging para o que auditores esperam.
• Obtenha um TCO de 3 anos de cada fornecedor que inclua plantão, aplicação de patches e custos de egress de relay; compare com o pricing gerenciado da Tenvo.
• Leia atestações de produto e, quando relevante, solicite uma bridge letter. Se precisar comparar profundamente com fornecedores estabelecidos, revise TeamViewer comparison, AnyDesk comparison e RustDesk comparison.
• Se precisar de linguagem para procurement, converta as 20 perguntas acima em itens de prova obrigatórios (diagramas, impressões digitais de certificados, logs) e pontue fornecedores apenas com base em evidências, não em alegações.

Pronto para testar um relay gerenciado e um cliente nativo? Baixe um cliente e execute as mesmas 20 verificações em um piloto curto: Obter Tenvo.