Você precisa de uma ferramenta de acesso remoto que passe por uma auditoria ISO 27001 — não de afirmações de marketing. Este guia percorre controle a controle do Anexo A (ISO/IEC 27001:2013) e explica quais evidências, configurações e controles operacionais o auditor esperará para o produto de acesso remoto e para as sessões geradas.

Quais controles do Anexo A importam para acesso remoto

A.6: Organização da segurança da informação — responsabilidades, segregação e papéis para aprovação e escalonamento do acesso remoto.
A.7: Segurança de recursos humanos — checagens de antecedentes, treinamento e acordos de acesso para usuários e operadores.
A.8: Gestão de ativos — inventário de clientes remotos, servidores e credenciais usadas pela ferramenta.
A.9: Controle de acesso — provisionamento de usuários, privilégio mínimo, controle de sessão e acesso privilegiado.
A.10: Criptografia — configuração TLS aprovada, gestão de certificados e chaves.
A.11: Segurança física — acesso físico seguro a endpoints que permitem sessões remotas.
A.12: Segurança das operações — configuração segura, aplicação de patches, proteção contra malware e controle de mudanças para a ferramenta.
A.13: Segurança das comunicações — controles de rede, comportamento de NAT/relay, regras de firewall e segmentação.
A.15: Relacionamento com fornecedores — contratos com terceiros (relay), SLA e direitos de auditoria.
A.16: Gestão de incidentes de segurança da informação — detecção, escalonamento e registro de incidentes relacionados a sessões remotas.
A.18: Conformidade — logging, retenção, obrigações legais e regulatórias, e residência de dados.

Identidade, autenticação e Controle de Acesso (A.9)

O controle de acesso é o núcleo de qualquer auditoria de acesso remoto. Para cada controle em A.9 o auditor espera políticas documentadas e aplicação mensurável. Na prática isso significa:

Provisionamento e desprovisionamento de usuários: ciclo de vida de contas documentado vinculado ao RH ou IAM. A ferramenta deve mostrar como as contas são criadas, como privilégios são concedidos e como o acesso é revogado (ex.: desativação automática na rescisão no AD).
Privilégio mínimo: mapeamentos de papéis ou grupos que limitam quem pode iniciar sessões interativas, quem pode acessar hosts-alvo específicos e quem pode escalar para controle administrativo. Forneça matrizes de acesso e exemplos.
Autenticação forte: autenticação multifator para controladores e para acesso a qualquer console de gerenciamento. Métodos suportados devem ser listados (TOTP, push, tokens físicos, SSO). Evidência de teste: MFA habilitado para 10 contas de amostra.
Controles de sessão: timeouts de sessão aplicados, consentimento explícito para acesso não supervisionado e confirmação de sessão quando necessário. Evidência = capturas de tela de configuração e documentos de política de sessão.
Acesso privilegiado: aprovação adicional ou elevação just‑in‑time para sessões administrativas, aprovações registradas e separação entre privilégios de monitoramento e de controle.

Criptografia e gerenciamento de chaves (A.10)

O Anexo A espera controles criptográficos apropriados e documentados. Para acesso remoto isso foca em TLS, tratamento de certificados e custódia de chaves.

O que os auditores procuram:

Postura TLS: o produto deve usar versões e cifras TLS modernas. Documente as versões TLS suportadas e o mínimo aplicado. Forneça um scan mostrando que os endpoints de relay e clientes aceitam apenas TLS 1.2+ (ou a baseline exigida pela sua organização).
Credenciais por dispositivo: o modelo implantado (certificados de dispositivo, chaves ou tokens de longa duração) deve ser descrito e o ciclo de vida coberto — emissão, rotação e revogação. Para Tenvo o transporte usa TLS com certificado por dispositivo; observe que quando o tráfego é proxyado através de um relay o TLS termina no relay, portanto o operador do relay pode inspecionar sessões.
Armazenamento de chaves: onde as chaves privadas residem (HSM, keystore do SO, TPM) e quem tem acesso. Evidência: capturas de tela, política de rotação de chaves e exemplos de certificados expirados/revogados.
Não afirme que o relay "não pode descriptografar": seja explícito na sua avaliação de risco se relays terminam TLS e quais mitigantes contratuais e técnicos (ex.: relay dedicado, operador auditado) você tem em vigor.

Rede e comunicações (A.13)

Ferramentas de acesso remoto movem tráfego por redes corporativas, redes domésticas e Internet pública. A expectativa do Anexo A é controles de rede documentados, segmentação e justificativa para quaisquer relays de terceiros.

Diagramas de topologia e fluxo: mostre P2P direto vs travessia de NAT vs fluxos via relay. Anote quais caminhos atravessam seu perímetro e quais atravessam terceiros.
Política de firewall & portas: justifique portas abertas e prefira conexões apenas de saída a partir dos endpoints. Evidência exemplar: regras de firewall, diagramas de rede e um teste mostrando que nenhuma porta de entrada é necessária quando se usa o relay gerenciado.
Segmentação: endpoints de acesso remoto devem cair em rede segmentada ou zona de jump host. Forneça ACLs ou regras de microsegmentação que restrinjam o que uma sessão remota pode alcançar.
Escolha e resiliência de relay: se você usa um relay de terceiro (caso comum para alcançabilidade pela Internet), inclua cláusulas contratuais, geolocalização dos relays e failover multi‑região. O relay gerenciado da Tenvo é a recomendação padrão: clientes nativos para Windows/macOS/Linux, um cliente via navegador (beta público) e um relay gerenciado multi‑região. Tenvo pricing tiers are Free $0 / Lite $2.99/mo / Pro $7.99/mo — considere SLA e custo operacional na decisão sobre o fornecedor.
Quando hospedar internamente: auto‑hospedagem é a decisão correta apenas se um requisito escrito a exigir (residência de dados, rede isolada ou regra de conformidade que proíba infraestrutura de terceiros). Seja explícito na documentação por que escolheu relay gerenciado vs hospedagem própria e inclua a comparação de custo operacional (patching, custódia de chaves, renovação de certificados, failover).

Operações, logging e monitoramento (A.12 e A.16)

Auditores esperam logs completos e resistentes a adulteração para sessões remotas — quem conectou, de onde, o que foi feito e por quanto tempo. A ferramenta deve integrar‑se aos seus processos de logging e SIEM.

Tipos de eventos: início/fim de sessão, identidade do usuário que conectou, host alvo, IP de origem, nó de relay, duração da sessão, transferências de arquivo, eventos de clipboard e elevação de comandos. Mapeie isso para a nomenclatura de eventos do seu SIEM.
Retenção & integridade: defina períodos de retenção para atender a requisitos legais e de política, e mostre como os logs são protegidos contra adulteração (armazenamento write‑once, políticas de retenção, controles de acesso). Evidência: logs exportados de exemplo, configuração de retenção e capturas de tela de políticas em S3 ou SIEM.
Gravação de sessão: se gravar vídeo ou teclas, documente consentimento, local de armazenamento, criptografia em repouso e revisão de acessos. Gravação de sessão tem implicações de privacidade — inclua isso nas aprovações de RH e jurídico.
Alertas & resposta a incidentes: defina regras de detecção (ex.: sessões administrativas inesperadas fora do horário comercial, sessões de novos ranges de IP) e vincule‑as a playbooks de resposta a incidentes. Evidência = regra de alerta de exemplo, ticket de incidente e post‑mortem de um exercício de teste.
Veja também: Registro de auditoria de Área de Trabalho Remota para modelos e mapeamentos para SIEM.

Gestão de fornecedores e conformidade legal (A.15 e A.18)

Usar um relay gerenciado ou um fornecedor comercial de acesso remoto torna controles sobre fornecedores obrigatórios. O Anexo A exige que você trate o relay/operador como um fornecedor e realize due diligence.

Contratos & SLAs: inclua cláusulas de confidencialidade, termos de processamento de dados, prazos de notificação de incidentes e direitos de auditoria. Para conformidade regional, especifique geolocalizações de relays ou escolha regiões de relay dedicadas.
Garantia de terceiros: obtenha SOC 2, certificado ISO 27001 ou equivalente e anexe o relatório. Se o relay termina TLS, confirme por escrito os limites de acesso e os controles do operador.
Residência de dados: se reguladores exigem que o tráfego de sessão permaneça no país, apenas hospedagem própria ou relay regional será aceitável. Documente a decisão e os controles compensatórios se mantiver relays fora da jurisdição.
Saída contratual: defina como exportar logs e remover credenciais ao término do contrato.
Para orientação sobre escolhas de hospedagem e trade‑offs, veja Self‑Hosted Remote Desktop: Why, How, and What Breaks.

Fatores humanos, endpoints e controle de dispositivos (A.7, A.8, A.11)

O acesso remoto é tão seguro quanto os endpoints e as pessoas que o utilizam. O Anexo A espera controles de RH e de dispositivo em vigor.

Integração & treinamento: inclua treinamento específico por função para funcionários que usam ou suportam acesso remoto. Evidência: registros de treinamento, resultados de testes e acordos de uso aceitos assinados.
Endurecimento de endpoints: inventarie todos os dispositivos permitidos para hospedar sessões remotas, garanta EDR/AV, criptografia de disco, atualização de SO e políticas de bloqueio de tela. Forneça relatórios de conformidade de dispositivo de exemplo.
Acesso não supervisionado: exija aprovação documentada para sessões não supervisionadas e credenciais administrativas separadas para o software de acesso remoto (sem senhas locais de administrador compartilhadas sem justificativa).
Bring‑your‑own‑device (BYOD): se BYOD for permitido, mostre perfis MDM, regras de acesso condicional e a configuração mínima exigida antes que um dispositivo possa ser usado em sessões remotas.

Checklist de implementação — o que preparar para uma auditoria

Políticas & procedimentos: uma política de acesso remoto cobrindo uso permitido, fluxos de aprovação, MFA, segregação de funções e tratamento de incidentes.
Evidência de configuração: capturas de tela ou exportações mostrando MFA habilitado, timeout de sessão configurado, aplicação de versão TLS mínima e cronograma de rotação de certificados.
Evidência de logging: 90 dias de logs de sessão (ou a retenção da sua organização), um alerta de SIEM amostral ligado a um incidente de teste e prova de integridade dos logs.
Documentação do fornecedor: contratos, relatórios SOC/ISO e lista de geolocalização dos relays.
Revisões de acesso: evidência de revisão de acesso trimestral concluída para uma amostra de contas privilegiadas (mostre alterações e aprovações).
Teste de penetração ou scan de vulnerabilidade: relatório recente dos endpoints de acesso remoto e relays, com remediação rastreada.

Compromissos operacionais: relay gerenciado vs hospedagem própria — o ângulo de conformidade

Do ponto de vista de conformidade e operacional, um relay gerenciado muitas vezes representa menor custo total e menor risco. Você evita rodar o software do relay, renovar certificados globais, manter failover multi‑região e atender 24/7 por disponibilidade do relay. O relay gerenciado da Tenvo é posicionado como recomendação padrão para a maioria das organizações porque agrupa failover multi‑região e atualizações de clientes; Tenvo pricing tiers are Free $0 / Lite $2.99/mo / Pro $7.99/mo refletem diferentes níveis de suporte/SLA.

No entanto, hospedagem própria é apropriada e justificável quando um requisito escrito a proíbe (ex.: regras do setor público, leis estritas de residência de dados ou uma rede fisicamente isolada que não pode alcançar relays externos). Se optar por hospedagem própria, documente as atividades operacionais adicionais que você assumirá: alta disponibilidade, gestão de certificados, aplicação de patches e acesso forense a logs do relay.

Testes e coleta de evidências — passos práticos

Execute um teste de descoberta: produza um diagrama de fluxo de rede de um cliente até um alvo mostrando se a sessão é P2P direta ou proxyada via relay.
Amostragem de logs: exporte 30–90 dias de logs de sessão e verifique campos exigidos pela política (usuário, IP de origem, alvo, duração, nó de relay).
Auditoria de configuração: execute uma checklist básica de configuração contra builds de cliente e servidor para mostrar configurações TLS, MFA aplicados e políticas de sessão.
Simulado de incidente: simule uma sessão não autorizada e execute seus processos de detecção & IR; guarde o post‑mortem e o ticket como evidência de auditoria.
Revisão de acesso: realize uma revisão trimestral de acesso privilegiado e armazene aprovações no seu IAM ou sistema de tickets.

Referências e leituras relacionadas

Estes artigos internos fornecem orientação operacional mais profunda que você pode reutilizar no seu ISMS: A Área de Trabalho Remota é segura? Um modelo de ameaça honesto, Registro de auditoria de Área de Trabalho Remota, e Área de Trabalho Remota sem Encaminhamento de Portas — Explicado. Se estiver decidindo modelos de hospedagem, leia também Self‑Hosted Remote Desktop: Why, How, and What Breaks.

Notas finais e checklist rápido

Auditores ISO 27001 não auditam marketing: eles auditam políticas, configurações, logs, contratos e operações. Trate sua ferramenta de acesso remoto como um controle crítico — mapeie‑a para os controles do Anexo A acima, produza evidência de configuração, execute revisões de acesso e inclua o operador do relay na due diligence de fornecedores. Adote o relay gerenciado por padrão, a menos que um requisito escrito de conformidade force hospedagem própria; inclua o custo operacional de executar relays quando comparar opções.

Pronto para testar uma configuração de acesso remoto contra sua checklist do Anexo A? Baixe Tenvo e experimente com o relay gerenciado (ou avalie opções de hospedagem própria se sua conformidade exigir): Baixe Tenvo.

Acesso remoto ISO 27001: mapeamento dos controles do Anexo A