Governação do acesso remoto seguro e de VPN para NIS2 e DORA

Às 07:42 de uma segunda-feira, Maria, CISO de um prestador FinTech SaaS em rápido crescimento, recebe três mensagens antes do café.
A primeira vem do SOC: uma conta VPN pertencente a um engenheiro de suporte autenticou-se a partir de um país onde a empresa não tem pessoal. A segunda vem da área comercial: um cliente de serviços financeiros quer evidência de que todo o acesso remoto privilegiado é protegido por MFA, registado, segmentado e revisto ao abrigo de controlos de gestão do risco das TIC alinhados com a DORA. A terceira vem do departamento jurídico: o mesmo evento pode envolver acesso a dados pessoais, pelo que o EPD quer perceber se a evidência do Article 32 do GDPR da UE é suficientemente completa para demonstrar medidas técnicas e organizativas adequadas.
Nada explodiu ainda. Não há nota de ransomware. Não há exfiltração confirmada. Não há indisponibilidade para clientes.
Mas Maria conhece a verdade incómoda. Quando a governação do acesso remoto é fraca, todas as conversas de conformidade passam a ser defensivas. Uma autenticação VPN transforma-se numa questão de higiene de cibersegurança NIS2. Uma conta de contratado transforma-se numa questão de risco de terceiros TIC ao abrigo da DORA. Uma sessão de ambiente de trabalho remoto num ambiente de cliente transforma-se numa questão de segurança do tratamento ao abrigo do GDPR da UE. Um log em falta transforma-se numa constatação de auditoria.
O relatório de auditoria externa que já está na sua secretária agrava a situação. Os auditores não encontraram um ataque zero-day sofisticado. Encontraram contas partilhadas de contratados, autenticação multifator inconsistente, grupos VPN legados, exceções não geridas e gigabytes de logs demasiado ruidosos para apoiar uma investigação. Era dívida técnica transformada em exposição regulatória.
Em 2026, a governação do acesso remoto seguro e da VPN não é um tema restrito de segurança de redes. É um sistema de controlo ao nível do conselho de administração que liga identidade, segurança de endpoints, acesso de fornecedores, gestão de vulnerabilidades, registo, resposta a incidentes, responsabilização em matéria de privacidade e resiliência operacional.
O problema do acesso remoto mudou
Há alguns anos, a governação do acesso remoto era frequentemente resumida a uma resposta simples: “temos uma VPN”. Essa resposta já não resiste a um escrutínio sério.
Um ambiente moderno de acesso remoto pode incluir concentradores VPN corporativos, gateways Zero Trust Network Access, servidores de salto, hosts bastião de gestão de acessos privilegiados, hosts bastião para administração de nuvem, infraestrutura de ambientes de trabalho remotos, túneis de manutenção de fornecedores, acesso de prestadores de serviços geridos, contas de emergência break-glass, portais de administração SaaS, acesso de programadores à produção, dispositivos móveis, redes domésticas, Wi‑Fi público e exceções BYOD.
Cada via pode transformar-se num ponto de evidência regulatória.
O NIS2 Article 21 espera medidas técnicas, operacionais e organizativas adequadas e proporcionadas. Estas incluem análise de riscos e políticas de segurança dos sistemas de informação, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, aquisição e manutenção seguras, tratamento de vulnerabilidades, políticas para avaliar a eficácia da cibersegurança, higiene de cibersegurança, formação em cibersegurança, criptografia e cifragem quando relevante, segurança de recursos humanos, políticas de controlo de acesso, gestão de ativos, autenticação multifator ou autenticação contínua quando apropriado, comunicações seguras e comunicações de emergência seguras.
A DORA exige que as entidades financeiras mantenham quadros documentados de gestão do risco das TIC, processos de incidentes TIC, testes de resiliência operacional digital e governação do risco de terceiros TIC. O DORA Article 5 atribui ao órgão de gestão a responsabilidade por definir, aprovar, supervisionar e manter a responsabilização pela gestão do risco das TIC. O Article 28 exige que o risco de terceiros TIC seja gerido como parte integrante desse quadro.
O GDPR Article 32 exige medidas técnicas e organizativas adequadas para a segurança do tratamento, incluindo confidencialidade, integridade, disponibilidade, resiliência, capacidade de restauro, testes e a capacidade de demonstrar que os dados pessoais estão protegidos contra acesso não autorizado, perda, alteração ou divulgação.
O problema do CISO não é saber se a VPN funciona. A questão real é saber se a organização consegue demonstrar que o acesso remoto é governado, sujeito a avaliação de risco, aprovado, endurecido, monitorizado, revisto, testado e integrado na resposta a incidentes.
É aqui que a ISO/IEC 27001:2022 se torna útil. Não trata a VPN como um equipamento isolado. Coloca o acesso remoto dentro do SGSI: âmbito, partes interessadas, avaliação de riscos, seleção de controlos, planeamento e controlo operacional, gestão de fornecedores, auditoria interna, revisão pela gestão e melhoria contínua.
Comece pelo âmbito do SGSI, não pela regra de firewall
Quando a Clarysec revê a governação do acesso remoto, não começamos por pedir uma captura de ecrã da configuração da VPN. Começamos pelo perímetro do SGSI.
A ISO/IEC 27001:2022 exige que a organização defina o seu contexto, partes interessadas, requisitos e âmbito do SGSI, incluindo interfaces e dependências com outras organizações. Para o acesso remoto, o âmbito deve incluir explicitamente as pessoas, sistemas, fornecedores e serviços de rede que tornam possível o trabalho remoto.
Uma organização SaaS ou de tecnologia financeira deve identificar:
- Colaboradores que acedem remotamente a sistemas de produção
- Contratados e programadores com direitos de administração remota
- MSP, MSSP e outros fornecedores com acesso operacional
- Pessoal de suporte ao cliente que acede a dados de clientes
- Utilizadores de finanças, recursos humanos e jurídico que acedem remotamente a dados pessoais
- Consolas de nuvem e interfaces de programação de aplicações de gestão remota
- VPN, ZTNA, fornecedor de identidade e plataformas de gestão de endpoints
- Logs, integrações SIEM e locais de retenção
- Exceções de acesso remoto e procedimentos de acesso de emergência
- Dispositivos de borda geridos por fornecedores e ferramentas de suporte remoto
Isto é mais do que higiene documental. O âmbito NIS2 pode incluir prestadores de serviços de nuvem, centros de dados, MSP, MSSP, prestadores de comunicações eletrónicas, prestadores de infraestrutura digital e prestadores de gestão de serviços TIC, dependendo da dimensão, setor e designação. A DORA aplica-se a entidades financeiras e funciona como o regime setorial específico de risco das TIC para essas entidades. O GDPR da UE pode aplicar-se a organizações da UE e de fora da UE quando o tratamento diga respeito a pessoas na UE, estabelecimentos na UE, serviços oferecidos a pessoas na União ou monitorização do comportamento.
Se o âmbito do SGSI ignora o acesso remoto de terceiros, a administração remota, a infraestrutura VPN ou a conectividade gerida por fornecedores, o conjunto de controlos pode estar incompleto antes mesmo de o auditor começar a amostragem.
Construa uma pilha de controlos de acesso remoto
Um programa robusto de acesso remoto deve ser construído como uma pilha de controlos, não como uma única política. Nos trabalhos de implementação da Clarysec, os controlos centrais da ISO/IEC 27002:2022 incluem normalmente:
- 6.7 Trabalho remoto
- 5.15 Controlo de acesso
- 5.16 Gestão de identidades
- 5.17 Informação de autenticação
- 5.18 Direitos de acesso
- 8.5 Autenticação segura
- 8.1 Dispositivos endpoint de utilizador
- 8.8 Gestão de vulnerabilidades técnicas
- 8.9 Gestão da configuração
- 8.15 Registo
- 8.16 Atividades de monitorização
- 8.20 Segurança de redes
- 8.22 Segregação de redes
- 5.19 Segurança da informação nas relações com fornecedores
- 5.20 Tratamento da segurança da informação em acordos com fornecedores
- 5.21 Gestão da segurança da informação na cadeia de fornecimento de TIC
- 5.22 Monitorização, revisão e gestão de alterações de serviços de fornecedores
- 5.23 Segurança da informação para utilização de serviços na nuvem
- 5.24 Planeamento e preparação da gestão de incidentes de segurança da informação
- 5.26 Resposta a incidentes de segurança da informação
- 5.28 Recolha de evidência
- 5.30 Preparação das TIC para a continuidade de negócio
Zenith Controls: o guia de conformidade cruzada mapeia o Trabalho remoto 6.7 como um controlo preventivo que apoia confidencialidade, integridade e disponibilidade, com ligações operacionais à gestão de ativos, proteção da informação, segurança física e segurança de sistemas e redes. Também liga o Trabalho remoto à Segurança de ativos fora das instalações 7.9, Dispositivos endpoint de utilizador 8.1, Sensibilização, educação e formação em segurança da informação 6.3, Transferência de informação 5.14, Segurança de redes 8.20, Segregação de redes 8.22, Mesa limpa e ecrã limpo 7.7 e Preparação das TIC para a continuidade de negócio 5.30.
Esta relação é relevante. Um requisito de VPN sem gestão de endpoints não protege contra um computador portátil roubado. MFA sem registo não apoia a investigação. Acesso de fornecedores sem segmentação aumenta o raio de impacto. Trabalho remoto sem comunicação de incidentes atrasa a contenção.
| Risco de acesso remoto | Foco do controlo ISO/IEC 27002:2022 | Evidência esperada pelos auditores |
|---|---|---|
| Credenciais roubadas usadas através de VPN | 8.5 Autenticação segura, 5.15 Controlo de acesso, 5.17 Informação de autenticação | Configuração de MFA, regras de acesso condicional, alertas de autenticação falhada, logs de autenticação |
| Antigo contratado mantém acesso | 5.18 Direitos de acesso, 5.16 Gestão de identidades, controlos de fornecedores 5.19 a 5.23 | Registos de admissões, movimentações e desligamentos, tickets de offboarding de fornecedores, evidência de revisão de acessos |
| Computador portátil comprometido liga-se remotamente | 8.1 Dispositivos endpoint de utilizador, 6.7 Trabalho remoto, 8.8 Gestão de vulnerabilidades técnicas | Conformidade MDM, estado EDR, evidência de cifragem, relatórios de patches |
| Dispositivo de borda VPN sem patches | 8.8 Gestão de vulnerabilidades técnicas, 8.9 Gestão da configuração, 8.20 Segurança de redes | Registo do ativo, resultados de scan, SLA de aplicação de patches, aprovação de exceção |
| Fornecedor usa conta remota partilhada | 5.15 Controlo de acesso, 5.16 Gestão de identidades, 8.5 Autenticação segura | Identificadores únicos de utilizador, contas nominativas de fornecedor, logs de MFA, requisitos contratuais |
| Sessão remota suspeita não pode ser reconstruída | 8.15 Registo, 8.16 Atividades de monitorização, 5.24 Planeamento e preparação da gestão de incidentes de segurança da informação | Logs de VPN, IP de origem, duração das sessões, alertas SIEM, cronologia do incidente |
A pilha de controlos muda a conversa. Em vez de debater se “a VPN está em conformidade”, a organização cria um modelo rastreável: risco de acesso remoto, controlo ISO, requisito da política, implementação técnica, proprietário da evidência e cadência de revisão.
Transforme a intenção da política em evidência de auditoria
Os auditores raramente aceitam “normalmente usamos MFA” como evidência. Procuram requisitos formalmente aprovados, controlos implementados e registos que comprovem a operação.
O toolkit de políticas da Clarysec fornece às equipas linguagem precisa que podem adotar e adaptar. A Política de segurança de redes - PME estabelece na cláusula 5.5.1:
“O acesso VPN deve exigir autenticação multifator (MFA) e ser restrito a pessoal designado.”
A mesma política para PME transforma o registo num requisito de retenção na cláusula 6.3.3:
“O acesso através de VPN deve ser registado, com a duração das sessões e os endereços IP de origem retidos por um período mínimo de 6 meses.”
Para o comportamento em trabalho remoto, a Política de trabalho remoto - PME estabelece na cláusula 5.2.3:
“O Wi‑Fi público só pode ser utilizado quando estiver ativo um túnel seguro (VPN).”
Para ambientes empresariais, a Política de trabalho remoto é ainda mais direta. A cláusula 5.2.1.1 exige que o pessoal:
“Utilize VPN aprovada pela empresa ou infraestrutura de ambientes de trabalho remotos.”
A cláusula 5.2.1.2 exige que as organizações:
“Exijam autenticação multifator (MFA) para todas as tentativas de autenticação.”
A Política de segurança de redes alinha a linha de base técnica com a cláusula 6.3.1:
“Todo o acesso remoto deve ser cifrado, por exemplo, através de IPsec ou SSL VPN, e exigir autenticação multifator (MFA).”
A Política de controlo de acesso estabelece na cláusula 5.6.1:
“Os eventos de acesso devem ser registados e retidos de acordo com a Política de registo e monitorização.”
Para fornecedores, a Política de segurança de terceiros e fornecedores exige na cláusula 6.3.2:
“Todo o acesso de terceiros deve ser registado e monitorizado e, quando viável, segmentado através de hosts bastião, VPN ou gateways Zero Trust.”
A Política de gestão de vulnerabilidades e patches - PME estabelece na cláusula 6.5.1:
“Os sistemas que tratam dados pessoais, fornecem acesso remoto ou estão expostos externamente devem ser priorizados para scans e atualizações.”
Estas cláusulas tornam-se poderosas quando são ligadas à evidência operacional. A política diz que a MFA é obrigatória. O fornecedor de identidade comprova a aplicação. O log VPN comprova a utilização. O alerta SIEM comprova a monitorização. A revisão de acessos comprova a necessidade de negócio continuada. O relatório de vulnerabilidades comprova que o serviço de acesso remoto é priorizado. O playbook de incidente comprova a capacidade de resposta.
Essa é a diferença entre ter uma política e operar um controlo.
As cinco perguntas que todo CISO deve responder
O modelo de governação de acesso remoto da Clarysec assenta em cinco perguntas que funcionam para auditorias ISO 27001, preparação NIS2, revisões de risco TIC DORA e pacotes de evidência do Article 32 do GDPR da UE.
1. Quem está autorizado a ligar-se remotamente?
O acesso remoto deve ser restrito a utilizadores, funções e fornecedores autorizados. Os controlos ISO/IEC 27002:2022 Controlo de acesso 5.15, Gestão de identidades 5.16 e Direitos de acesso 5.18 definem a base de governação.
Zenith Controls mapeia o Controlo de acesso 5.15 como um controlo preventivo centrado na gestão de identidades e acessos. Liga este controlo à gestão de identidades, direitos de acesso, informação de autenticação, dispositivos endpoint de utilizador, autenticação segura e conformidade com as políticas. Na prática, uma política de acesso só é credível se as identidades forem únicas, geridas ao longo do ciclo de vida, autenticadas e revistas.
Um bom registo de acesso remoto deve responder:
- Que pessoa ou fornecedor tem acesso?
- A que sistemas consegue chegar?
- Que função ou contrato justifica o acesso?
- Quem o aprovou?
- A MFA está aplicada?
- Quando foi o acesso revisto pela última vez?
- Quando expira o acesso temporário?
- Que fonte de log comprova a utilização?
Isto também apoia os resultados PR.AA do NIST Cybersecurity Framework 2.0 para gestão de identidades, autenticação, autorização, princípio do menor privilégio e segregação de funções.
2. Que postura de dispositivo e rede é exigida?
O acesso remoto deve depender da confiança no dispositivo, não apenas das credenciais do utilizador. Uma palavra-passe válida e uma aprovação MFA a partir de um dispositivo não gerido, infetado ou sem patches continua a representar um risco elevado.
Zenith Blueprint: roteiro de 30 passos para auditores explica isto na fase Controlos em ação, passo 16, Controlos de pessoas II:
“Os trabalhadores remotos devem ser obrigados a utilizar apenas dispositivos aprovados pela empresa, configurados pela TI com cifragem integral de disco, proteção de endpoint ativa, aplicação automática de patches e tempos limite de bloqueio de ecrã impostos.”
O mesmo passo salienta que o acesso remoto deve passar pela VPN corporativa, idealmente protegida por MFA, e que o BYOD deve ser proibido ou permitido apenas sob condições estritas, como inscrição em MDM, contentorização e apagamento remoto.
É aqui que Dispositivos endpoint de utilizador 8.1, Trabalho remoto 6.7, Gestão de vulnerabilidades técnicas 8.8, Gestão da configuração 8.9 e Segurança de redes 8.20 convergem.
Para o GDPR Article 32, a postura do dispositivo é relevante porque os endpoints remotos fazem parte das medidas técnicas e organizativas que protegem os dados pessoais. Para a DORA, a postura de endpoint apoia a gestão do risco das TIC e a resiliência operacional. Para a NIS2, apoia a higiene de cibersegurança, o controlo de acesso, a gestão de ativos e o tratamento de vulnerabilidades.
3. Como é protegida a sessão?
Uma sessão segura de acesso remoto deve usar transporte cifrado, autenticação forte, segmentação e vias administrativas controladas.
Zenith Blueprint, fase de Gestão de riscos, passo 14, Políticas de tratamento de riscos e referências regulamentares cruzadas, define a expectativa para o acesso remoto:
“Todo o acesso remoto a sistemas internos deve utilizar VPN segura ou ligação cifrada equivalente. A autenticação multifator (MFA) é obrigatória para autenticação remota nas redes da empresa.”
O passo 20, Controlos 8.18 a 8.26, instrui as organizações a validar a segurança dos serviços de rede através da listagem de todos os serviços de rede internos e externos, como DNS, VPN, SMTP, DHCP e gateways API, confirmando protocolos seguros, revendo controlos de acesso e verificando cláusulas de segurança de terceiros quando os serviços são geridos externamente.
Uma VPN não é apenas um dispositivo. É um serviço de rede com escolhas de protocolo, restrições de acesso, certificados, caminhos de firewall, dependências de terceiros, requisitos de aplicação de patches e logs.
4. Como é o acesso monitorizado e investigado?
A governação do acesso remoto deve incluir registo e monitorização. O NIS2 Article 23 estabelece expectativas de reporte faseado para incidentes significativos, incluindo aviso prévio no prazo de 24 horas, notificação de incidente no prazo de 72 horas e relatório final no prazo de um mês. A DORA exige que as entidades financeiras detetem, giram, classifiquem, escalem e reportem incidentes graves relacionados com TIC, incluindo análise de causa raiz e comunicação quando os interesses financeiros dos clientes sejam afetados. A análise de violação ao abrigo do GDPR da UE depende de compreender se os dados pessoais foram acedidos, alterados, divulgados, perdidos ou de outra forma comprometidos.
Sem logs de acesso remoto, a organização não consegue responder com confiança à primeira pergunta do regulador: o que aconteceu?
Um registo robusto deve capturar identidade do utilizador, resultado da autenticação, IP de origem, geolocalização quando apropriado, identidade do dispositivo, serviço de destino, ação privilegiada, duração da sessão, tentativas falhadas, alterações administrativas e correlação com eventos de endpoint e identidade.
5. Como são tratadas as exceções e vulnerabilidades?
A infraestrutura de acesso remoto tem elevado valor. Gateways VPN, appliances ZTNA, fornecedores de identidade, hosts bastião e serviços de ambientes de trabalho remotos devem estar entre os ativos geridos de forma mais rigorosa no programa de vulnerabilidades.
Um processo maduro de exceções deve incluir proprietário do ativo, serviço de acesso remoto afetado, severidade da vulnerabilidade, explorabilidade, exposição de dados, controlos compensatórios temporários, aprovação do proprietário do risco, data de expiração, evidência de novo teste e ligação ao registo de riscos e ao plano de tratamento de riscos.
Para a ISO/IEC 27001:2022, isto apoia o tratamento de riscos, o controlo operacional e a melhoria contínua. Para a DORA, apoia a gestão do risco das TIC, os testes e a remediação. Para a NIS2, apoia o tratamento de vulnerabilidades e a ação corretiva sem demora indevida. Para o GDPR da UE, ajuda a demonstrar que a segurança do tratamento foi baseada no risco e não ad hoc.
O acesso remoto de fornecedores é a armadilha de auditoria oculta
Muitas falhas de acesso remoto não são falhas de colaboradores. São falhas de governação de fornecedores.
Um MSP tem uma conta VPN antiga. Um fornecedor de software usa uma credencial partilhada. Um parceiro de suporte liga-se por ambiente de trabalho remoto para resolver um problema com impacto no cliente. Um prestador de serviços de nuvem gere o gateway de acesso remoto. Um contratado mantém o acesso após o encerramento do projeto.
A DORA é particularmente rigorosa aqui. O Article 28 exige que as entidades financeiras giram o risco de terceiros TIC como parte do quadro de gestão do risco das TIC e permaneçam totalmente responsáveis mesmo quando os serviços TIC são externalizados. Espera registos de acordos contratuais TIC, diligência prévia, normas de segurança da informação, direitos de auditoria e inspeção, direitos de cessação, análise de risco de concentração e estratégias de saída para funções críticas ou importantes. O Article 30 especifica disposições contratuais como proteção de dados, níveis de serviço, locais de tratamento, acesso e recuperação de dados, assistência durante incidentes, cooperação com autoridades, medidas de segurança, direitos de auditoria e apoio à saída.
O NIS2 Article 21 também inclui segurança da cadeia de fornecimento e relações com fornecedores e prestadores de serviços, com atenção a vulnerabilidades específicas dos fornecedores e práticas de cibersegurança dos fornecedores.
O NIST CSF 2.0 GV.SC fornece um modelo operacional prático: estratégia de risco da cadeia de fornecimento, papéis, criticidade de fornecedores, requisitos contratuais, diligência prévia, monitorização, participação em incidentes e atividades pós-relação.
Para os clientes da Clarysec, a regra prática é simples: o acesso remoto de terceiros deve ser tratado como acesso privilegiado, salvo prova em contrário. Deve ser nominativo, aprovado, limitado no tempo, protegido por MFA, registado, monitorizado e segmentado.
Mapeamento de conformidade cruzada: um sistema de controlo, muitas obrigações
A governação do acesso remoto é um dos exemplos mais fortes de conformidade cruzada. A mesma evidência pode satisfazer múltiplas obrigações se for concebida corretamente.
| Driver de conformidade | Expectativa de acesso remoto | Evidência a manter |
|---|---|---|
| ISO/IEC 27001:2022 | Seleção de controlos baseada no risco, governação de acessos, controlo de fornecedores, evidência operacional e melhoria contínua | Avaliação de riscos, Declaração de Aplicabilidade, políticas, revisão de acessos, logs, constatações de auditoria interna |
| NIS2 | Higiene de cibersegurança, controlo de acesso, gestão de ativos, MFA quando apropriado, tratamento de incidentes, continuidade de negócio e segurança da cadeia de fornecimento | Registos de MFA, formação em higiene de cibersegurança, controlos de acesso de fornecedores, relatórios de incidente, ações corretivas |
| DORA | Governação do risco das TIC, autenticação forte, ciclo de vida de incidentes, testes de resiliência, risco de terceiros TIC e responsabilização do órgão de gestão | Registo de riscos TIC, testes de acesso remoto, classificações de incidentes, registos de fornecedores, planos de saída, direitos de auditoria |
| GDPR Article 32 | Segurança do tratamento adequada, confidencialidade, integridade, disponibilidade, resiliência, testes e responsabilização | Logs de acesso, evidência de cifragem, aplicação de MFA, registos de avaliação de violação, resultados dos testes |
| NIST CSF 2.0 | Resultados Govern, Identify, Protect, Detect, Respond e Recover | Perfis atual e alvo, inventário de ativos, controlos de identidade PR.AA, monitorização DE.CM, análise RS.AN |
| COBIT 2019 e garantia ISACA | Objetivos de governação, práticas de gestão, desenho de controlos e eficácia operacional | RACI, propriedade do processo, métricas de desempenho dos controlos, trilho de auditoria, acompanhamento da remediação |
Um mapeamento mais detalhado dos controlos ISO mostra porque a governação do acesso remoto tem tanto valor de conformidade.
| Controlo ISO/IEC 27002:2022 | Alinhamento NIS2 | Alinhamento DORA | Evidência do GDPR Article 32 |
|---|---|---|---|
| 6.7 Trabalho remoto | Apoia a higiene de cibersegurança, o controlo de acesso e as práticas de trabalho seguras do Article 21 | Apoia políticas e procedimentos TIC para trabalho remoto e resiliência operacional | Demonstra medidas organizativas para pessoal que trata dados pessoais fora do escritório |
| 8.5 Autenticação segura | Apoia o Article 21(2)(j) sobre autenticação multifator ou contínua quando apropriado | Apoia expectativas de autenticação forte ao abrigo de medidas de proteção e prevenção TIC | Demonstra uma medida técnica para reduzir o acesso não autorizado a dados pessoais |
| 8.20 Segurança de redes | Apoia comunicações seguras, cifragem e proteção de serviços de rede | Apoia a proteção contra intrusão, utilização indevida e acesso TIC não autorizado | Demonstra proteção de dados em trânsito e caminhos de rede controlados |
| 8.22 Segregação de redes | Apoia a limitação de impacto e a aplicação de limites de controlo de acesso | Apoia resiliência e contenção para funções críticas ou importantes | Reduz a exposição de dados pessoais ao limitar os sistemas alcançáveis |
| Controlos de fornecedores 5.19 a 5.23 | Apoia a segurança da cadeia de fornecimento do Article 21(2)(d) | Apoia o risco de terceiros TIC e a governação contratual dos Articles 28 e 30 | Apoia a responsabilização de subcontratantes e fornecedores pelo acesso seguro |
| 8.15 Registo e 8.16 Atividades de monitorização | Apoia o tratamento de incidentes e a avaliação da eficácia | Apoia a deteção, classificação, escalonamento e reporte de incidentes TIC | Apoia a avaliação de violação e a evidência forense |
| 8.8 Gestão de vulnerabilidades técnicas | Apoia manutenção segura e tratamento de vulnerabilidades | Apoia a redução do risco TIC, testes e remediação | Demonstra proteção baseada no risco dos sistemas que tratam dados pessoais |
A NIS2 também introduz responsabilização explícita da gestão. O Article 20 exige que os órgãos de gestão de entidades essenciais e importantes aprovem medidas de gestão de riscos de cibersegurança, supervisionem a implementação e frequentem formação. O DORA Article 5 exige de forma semelhante que o órgão de gestão das entidades financeiras defina, aprove, supervisione e permaneça responsável pelas disposições de gestão do risco das TIC.
O conselho de administração não precisa de aprovar todas as regras de firewall. Mas deve aprovar a postura de risco do acesso remoto: MFA obrigatória, acesso de fornecedores registado, acesso privilegiado segmentado, infraestrutura de acesso remoto corrigida dentro de prazos definidos, exceções limitadas no tempo e incidentes cibernéticos escalados através de canais acordados.
Um sprint de evidência de acesso remoto em 90 minutos
Uma forma prática de expor lacunas é criar um minipacote de evidência em torno de uma via de acesso. Escolha um exemplo, como “acesso VPN para engenheiros de suporte à produção”, e conclua o seguinte sprint.
| Minuto | Atividade | Resultado |
|---|---|---|
| 0 a 10 | Definir a via de acesso | Uma frase que descreva quem se liga, de onde, a quê e porquê |
| 10 a 25 | Mapear as políticas aplicáveis | Cláusulas da Política de trabalho remoto, Política de segurança de redes, Política de controlo de acesso e Política de segurança de fornecedores, se relevante |
| 25 a 40 | Capturar a aplicação técnica | Capturas de ecrã ou exportações que comprovem MFA, cifragem, pertença a grupos e acesso condicional |
| 40 a 55 | Capturar logs | Autenticação bem-sucedida recente, autenticação falhada, IP de origem, duração da sessão e exemplo de alerta SIEM |
| 55 a 70 | Rever vulnerabilidades e postura do dispositivo | Estado de patch do ativo VPN, relatório de conformidade de endpoint e exceções em aberto |
| 70 a 80 | Verificar evidência de revisão de acessos | Última revisão de acessos, utilizadores removidos, exceções aprovadas e aprovação formal do proprietário |
| 80 a 90 | Criar narrativa de auditoria | Explicação de uma página que mapeie risco, controlo, política, implementação e evidência |
O objetivo não é a burocracia. O objetivo é ligar a política à prova. Se o pacote de evidência não puder ser concluído para uma via de acesso, a organização encontrou uma lacuna real de governação antes de o auditor ou regulador a encontrar.
Este exercício também se enquadra no método de Perfil do NIST CSF 2.0: delimitar o perfil, recolher políticas e requisitos, documentar resultados atuais e alvo, analisar lacunas, criar um plano de ação priorizado e implementar melhorias.
Como os auditores vão testar o acesso remoto
Uma auditoria de acesso remoto pode parecer diferente consoante o perfil do auditor. Zenith Controls ajuda as organizações a prepararem-se porque mapeia as relações entre controlos ISO/IEC 27002:2022 numa visão de conformidade cruzada, em vez de uma única lista de verificação.
| Perspetiva do auditor | Pergunta provável | Resposta robusta |
|---|---|---|
| ISO 27001 | Porque selecionaram estes controlos de acesso remoto? | Avaliação de riscos, justificação da SoA, plano de tratamento e mapeamento de políticas |
| NIST CSF 2.0 | Qual é o vosso estado atual e alvo? | Perfil, análise de lacunas, plano de ação priorizado e melhorias implementadas |
| COBIT 2019 | Quem é responsável pela governação do acesso remoto? | RACI, proprietário do processo, revisão pela gestão e métricas de controlo |
| DORA | Como gerem o acesso remoto de terceiros TIC? | Registo centralizado de fornecedores, diligência prévia, cláusulas contratuais, direitos de auditoria e plano de saída |
| GDPR | Conseguem provar que o acesso a dados pessoais foi controlado? | MFA, princípio do menor privilégio, logs, revisão de acessos e registos de avaliação de violação |
Uma organização preparada para auditoria não corre atrás de capturas de ecrã. Mantém um sistema vivo de evidência.
Constatações comuns em 2026
Nas avaliações, a Clarysec observa repetidamente os mesmos problemas de acesso remoto:
- A MFA está ativada para colaboradores, mas não para fornecedores, contas de emergência ou perfis VPN legados
- Existem logs de acesso remoto, mas não são retidos durante tempo suficiente, centralizados ou associados a identidades
- A conformidade de endpoints é gerida separadamente do acesso VPN, permitindo que dispositivos não geridos continuem a ligar-se
- A revisão de acessos foca-se em aplicações empresariais, mas ignora grupos VPN, permissões de bastion e funções de administração de nuvem
- A infraestrutura de acesso remoto não consta da lista de prioridades de vulnerabilidades
- O acesso de fornecedores é aprovado informalmente e não se reflete nos contratos
- As exceções não têm data de expiração, controlo compensatório ou aprovação do proprietário do risco
- As contas break-glass não são testadas, monitorizadas ou revistas
- As sessões privilegiadas não estão segmentadas do tráfego geral de acesso remoto
- Os playbooks de resposta a incidentes não incluem recolha de evidência de acesso remoto
Estas constatações são evitáveis. Normalmente resultam de propriedade fragmentada. As equipas de rede são responsáveis pela VPN. A IAM é responsável pela MFA. A TI é responsável pelos dispositivos. A aquisição é responsável pelos contratos com fornecedores. O jurídico é responsável pelos termos de tratamento de dados. O SOC é responsável pelos alertas. A conformidade é responsável pela evidência de auditoria.
O SGSI deve ligá-los.
O modelo operacional alvo para acesso remoto seguro
Um modelo maduro de acesso remoto seguro e governação de VPN deve incluir as seguintes práticas operacionais:
- Manter um inventário de todos os métodos de acesso remoto, incluindo VPN, ZTNA, RDP, hosts bastião, portais de administração SaaS e túneis de fornecedores
- Exigir MFA para todo o acesso remoto, incluindo fornecedores, administradores e contas de emergência
- Aplicar a conformidade do dispositivo antes do acesso, quando tecnicamente viável
- Utilizar segmentação, hosts bastião ou gateways Zero Trust para acesso privilegiado e acesso de terceiros
- Registar IP de origem, identidade do utilizador, resultado da autenticação, sistema de destino e duração da sessão
- Reter logs de acordo com a política e com as necessidades regulamentares e de investigação
- Priorizar sistemas de acesso remoto para scans de vulnerabilidades e aplicação de patches
- Rever direitos de acesso periodicamente e em caso de alteração de função, cessação ou alteração contratual de fornecedor
- Limitar no tempo acessos de emergência, temporários e de fornecedores
- Incluir o acesso remoto na resposta a incidentes, na avaliação de violação e em exercícios de crise
- Testar a resiliência do acesso remoto e rotas de acesso de contingência quando exigido para continuidade
- Integrar o acesso remoto de fornecedores em contratos, diligência prévia, monitorização e planeamento de saída
- Reportar métricas de risco de acesso remoto à gestão
Para Maria, isto torna-se um plano de ação prático. Nas primeiras duas semanas, usa o Zenith Blueprint para atualizar documentos de governação, alinhar políticas com obrigações NIS2 e DORA e obter aprovação da gestão. Ao longo do mês seguinte, as suas equipas de TI e segurança aplicam MFA em todos os perfis de acesso remoto, segmentam o acesso de contratados, ajustam o registo e priorizam sistemas VPN e ZTNA para remediação de vulnerabilidades. De forma contínua, realiza revisão de acessos trimestral, testa a recolha de evidência de incidentes e reporta métricas de risco ao conselho de administração.
O resultado não é apenas uma configuração VPN mais limpa. É um sistema de controlo de acesso remoto capaz de resistir a auditorias, apoiar a resposta a incidentes e reduzir o risco operacional real.
Construa o seu pacote de evidência de acesso remoto antes do próximo incidente
O alerta VPN de segunda-feira de manhã não precisa de se transformar numa crise. Mas deve transformar-se num teste de governação.
Consegue identificar o utilizador? Consegue comprovar MFA? Consegue confirmar a postura do dispositivo? Consegue reconstruir a sessão? Consegue determinar se os dados pessoais estavam acessíveis? Consegue demonstrar que a conta foi aprovada e revista? Consegue provar que o dispositivo VPN tinha patches aplicados? Consegue demonstrar que o acesso de fornecedores é registado e segmentado? A gestão consegue ver o risco?
Se a resposta for “ainda não”, a Clarysec pode ajudar.
Comece com Zenith Blueprint: roteiro de 30 passos para auditores para estruturar o seu roteiro de implementação da ISO/IEC 27001:2022, em especial o passo 14 para políticas de tratamento de riscos, o passo 16 para controlos de trabalho remoto, o passo 19 para autenticação segura e o passo 20 para segurança de serviços de rede. Use Zenith Controls: o guia de conformidade cruzada para mapear Trabalho remoto, Controlo de acesso, Autenticação segura, controlos de fornecedores, registo e Segurança de redes para controlos ISO/IEC 27002:2022 relacionados e evidência de conformidade cruzada.
Depois, operacionalize os requisitos com políticas da Clarysec, como a Política de trabalho remoto, a Política de segurança de redes, a Política de controlo de acesso, a Política de segurança de terceiros e fornecedores e os equivalentes preparados para PME.
A sua próxima auditoria não deve ser a primeira vez que a evidência de acesso remoto é reunida. Construa-a agora, teste-a agora e faça da governação do acesso remoto seguro uma das partes mais fortes do seu programa de conformidade. Contacte a Clarysec para uma avaliação de governação de acesso remoto, descarregue os modelos de políticas ou marque uma demonstração para ver como os seus controlos atuais mapeiam para ISO 27001, NIS2, DORA e GDPR Article 32.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


