Risco de acesso de terceiros: O que falhou na Dinamarca

O risco de acesso de terceiros é a exposição que resulta de fornecedores, prestadores de serviços ou parceiros de integração deterem credenciais de acesso aos sistemas ou dados da organização. A Dinamarca revelou a dimensão deste risco em outubro de 2026: um atacante utilizou o acesso legítimo de uma empresa de TI com dois colaboradores ao registo nacional da população e expôs dados de cerca de 8,8 milhões de pessoas.

A causa de fundo noticiada é banal. Pelo menos três contas do fornecedor, a Pays ApS, estão associadas à fuga de dados, os seus administradores terão usado a palavra-passe «123456» e o acesso prolongou-se durante 21 dias e 17 horas até os administradores do registo terem conhecimento dele.

Pontos principais

A fuga de dados entrou pelas contas de um fornecedor. Cerca de 8,8 milhões das 11 milhões de entradas do registo foram afetadas.
A dimensão da equipa do fornecedor não limitou os danos. O alcance, a taxa de consultas e o número de contas determinaram o raio de impacto.
Seis controlos formam a verificação do raio de impacto do acesso de fornecedores: acesso delimitado, limites temporais, credenciais únicas geradas, MFA no perímetro que a organização controla, monitorização de sessões e um controlo de saída (offboarding) obrigatório no fim do contrato.
A referência a superar é de 21 dias e 17 horas. Verifique se a monitorização interna assinalaria mais depressa atividade anómala em contas de fornecedores.

O que aconteceu na Dinamarca e porque é um caso de acesso de fornecedores

Em setembro de 2026, um atacante utilizou o acesso legítimo ao registo detido pela Pays ApS, uma empresa de TI dinamarquesa com dois colaboradores, para consultar o Registo Central de Pessoas (CPR) da Dinamarca. Cerca de 8,8 milhões das suas 11 milhões de entradas foram afetadas. O ponto de entrada foram as contas de um fornecedor, não os sistemas do próprio registo.

O Cybernews noticiou que pelo menos três contas da Pays ApS estão associadas à fuga de dados e que os administradores da empresa terão usado «123456» como palavra-passe. O diretor-geral da empresa declarou à estação TV 2 que o seu «acesso legal para pesquisar informação no sistema CPR foi utilizado de forma abusiva». O Registo Central de Empresas da Dinamarca indicava, em julho de 2026, que a empresa tinha dois colaboradores.

Um atacante anónimo disse ao jornal dinamarquês Politiken que a intrusão começou com uma palavra-passe exposta de um antigo colaborador de uma pequena empresa dinamarquesa e que, depois, dois programas extraíram dados do registo. A Autoridade Dinamarquesa de Proteção de Dados afirmou que o ataque envolveu alguma forma de força bruta para enumerar números CPR válidos, segundo o BleepingComputer.

Data (2026)	Acontecimento	Fonte
10 de setembro	Início do acesso, que dura 21 dias e 17 horas no total	Cybernews
2 de outubro	A administração do CPR toma conhecimento da fuga de dados	BleepingComputer
5 de outubro	As autoridades anunciam a fuga de dados, bloqueiam o acesso da empresa e abrem uma investigação policial	BleepingComputer

Em termos de causa e efeito: uma palavra-passe de fornecedor fraca ou exposta deu a um atacante o acesso do fornecedor, esse acesso permitiu três semanas de enumeração e a enumeração devolveu registos de 8,8 milhões de pessoas.

Um número CPR, por si só, não permite fazer-se passar por um cidadão, porque o segundo fator do MitID dinamarquês continua a servir de barreira. O Cybernews observa que os dados podem tornar o phishing mais certeiro e ser cruzados com fugas de dados anteriores.

Porque é que a dimensão do fornecedor não reduz o raio de impacto?

O número de colaboradores de um fornecedor não influencia os danos que as suas credenciais podem causar. O raio de impacto é determinado por aquilo a que uma conta consegue aceder, pela quantidade de dados que consegue extrair por hora e pelo número de contas existentes. Uma empresa de duas pessoas com acesso de pesquisa a um registo de 11 milhões de entradas tem a mesma exposição que uma grande empresa.

O Cybernews explica porque é que uma empresa dessa dimensão tinha esse acesso: as organizações podem receber acesso autorizado a determinados dados do registo para verificar moradas de clientes ou manter registos de associados. A consequência, nas palavras do site, é que «a segurança do registo depende, em parte, das práticas de segurança das organizações autorizadas a consultá-lo».

A maioria das empresas tem a mesma estrutura na sua própria infraestrutura: um prestador de pagamentos com chaves de API para registos de clientes, um fornecedor de serviços geridos com direitos de administrador de domínio, uma agência com acesso ao CMS de produção. Avalie cada um face a quatro critérios antes de conceder qualquer acesso.

Critério	Pergunta a fazer
Alcance	A quantos registos, sistemas ou credenciais consegue esta conta aceder?
Operação	Pode ler um registo, fazer consultas em massa ou escrever?
Taxa	Existe um limite por conta e um alerta quando o volume dispara?
Contas	Quantas contas existem e cada uma pertence a uma pessoa identificada?

«Somos demasiado pequenos para um programa de gestão do acesso de fornecedores» é a objeção a que este caso responde. A dimensão do programa deve acompanhar o alcance do fornecedor sobre os dados da organização, não o número de colaboradores de qualquer das partes. O que a dimensão do fornecedor altera é o nível de práticas de segurança que se pode presumir: uma empresa de duas pessoas raramente tem uma função de segurança dedicada, pelo que a verificação cabe à organização.

Com que rapidez está a crescer o risco de acesso de terceiros?

O 2026 Data Breach Investigations Report da Verizon concluiu que terceiros estiveram envolvidos em 48 % das fugas de dados, contra 30 % no ano anterior, um salto de 60 %. Esse valor anterior já tinha duplicado face à edição de 2024. A Dinamarca é um exemplo de um padrão que hoje abrange quase metade das mais de 22 000 fugas de dados analisadas no relatório.

A Verizon divide a exposição a terceiros em três arquétipos: um fornecedor na cadeia de abastecimento de software, um fornecedor que aloja os dados da organização e um fornecedor ligado ao ambiente da organização. A Pays ApS pertence ao terceiro grupo. O mesmo relatório mostra a lentidão com que os fornecedores colmatam as falhas por trás do número principal.

Conclusão do relatório de 2026 da Verizon	Valor
Fugas de dados que envolvem terceiros	48 % (30 % na edição anterior)
Organizações terceiras que corrigem totalmente a MFA em falta ou mal configurada em contas na nuvem	23 %
Tempo mediano para resolver metade das falhas de palavras-passe fracas e permissões excessivas	Quase 8 meses
Organizações com pelo menos uma conta de administrador IaaS com a MFA desativada	37 %

Metade das falhas de palavras-passe fracas e permissões excessivas continua por resolver ao fim de quase oito meses. O acesso na Dinamarca durou três semanas.

A fatura também continua a subir. O Cost of a Data Breach Report 2026 da IBM situa a média global em 4,99 milhões de dólares por fuga de dados, um recorde e um aumento de 12 %.

Leitura relacionada

A vertente regulamentar do risco de fornecedores é abordada no guia de segurança da cadeia de abastecimento .

Porque é que exigir MFA não basta para as contas de fornecedores?

A MFA protege os pontos de início de sessão que a organização controla. As contas de fornecedores ficam muitas vezes fora do SSO, fora da aplicação obrigatória da MFA e fora dos processos de saída de colaboradores geridos pelos RH, pelo que uma política forte do lado da organização diz pouco sobre a palavra-passe do lado do fornecedor. No acesso de fornecedores, verifique a higiene das contas no perímetro em vez de a presumir.

Nem o Cybernews nem o BleepingComputer mencionam um segundo fator nas contas comprometidas. As falhas noticiadas situam-se uma camada abaixo da MFA: uma palavra-passe trivial em contas de administrador e a palavra-passe exposta de um antigo colaborador que, segundo o atacante, abriu a porta de entrada.

Depois de uma credencial ser exposta, a revogação é lenta. O State of Secrets Sprawl 2026 da GitGuardian acompanhou segredos válidos encontrados em commits públicos no GitHub em 2022 e concluiu que 64 % continuavam por revogar em 2026. Uma credencial de fornecedor exposta mantém-se ativa até alguém assumir a responsabilidade de a revogar.

«Os nossos fornecedores são certificados» não resolve a lacuna. Um certificado descreve o programa de um fornecedor. Não indica se a conta que um prestador de serviços abre hoje usa uma palavra-passe única e gerada ou um acesso partilhado por toda a empresa. Os acessos partilhados também tornam o registo de auditoria ilegível: o log mostra a empresa, não a pessoa.

Se hoje os acessos de fornecedores estão em folhas de cálculo e conversas de chat, mova-os para um cofre onde cada credencial é gerada, delimitada e registada. Inicie um teste gratuito do Passwork e experimente-o primeiro com um único fornecedor.

Verificação do raio de impacto: Seis controlos para o acesso de terceiros

A verificação do raio de impacto do acesso de fornecedores é uma rotina de seis controlos para dimensionar e limitar aquilo a que as credenciais de um fornecedor conseguem aceder: delimitar o acesso à tarefa, limitar o acesso no tempo, emitir credenciais únicas, impor a MFA no perímetro da organização, monitorizar as sessões de fornecedores e condicionar o fecho do contrato à saída do fornecedor. Execute-a antes de conceder acesso e em cada revisão.

A Diretiva NIS2 da UE abrange esta camada. O artigo 21.º, n.º 2, alínea d), da Diretiva (UE) 2022/2555 (NIS2) inclui a segurança da cadeia de abastecimento entre as medidas de gestão de riscos que as entidades essenciais e importantes adotam, incluindo os aspetos de segurança relativos à relação com cada fornecedor direto ou prestador de serviços.

Delimitar o acesso à tarefa. Aplique o princípio do menor privilégio a cada fornecedor: conceda os cofres, sistemas ou âmbitos de API específicos de que o contrato necessita, dimensione-os com os quatro critérios acima e mantenha separadas as contas de administrador e as contas de uso corrente. O acesso baseado em funções torna isto repetível, e o guia de RBAC mostra como associar o âmbito à função profissional. Na Dinamarca, um único conjunto de credenciais conseguia enumerar milhões de entradas.
Limitar o acesso no tempo. Associe cada conta de fornecedor à data de fim do contrato ou do projeto, remova o acesso permanente quando o trabalho é interrompido e volte a aprovar o acesso em cada marco através de uma revisão de acessos agendada. Uma palavra-passe exposta só funciona enquanto a conta funcionar. Se a fuga dinamarquesa partiu de um antigo colaborador, o processo de saída de colaboradores era o controlo que a teria neutralizado.
Emitir credenciais únicas e atribuíveis a cada pessoa. Uma conta por pessoa, nunca uma por empresa. Gere as palavras-passe em vez de deixar que as pessoas as escolham e rejeite valores sabidamente fracos, como «123456», no momento da criação. Comece por inventariar as credenciais detidas por fornecedores; o guia de gestão de credenciais SaaS mostra como.
Impor a MFA no perímetro que a organização controla. Coloque o segundo fator no gateway, no portal ou no início de sessão do cofre, independentemente da postura de segurança do próprio fornecedor. Assim, uma palavra-passe adivinhada ou exposta não abre nada por si só. As contas de fornecedores dentro dos sistemas da organização seguem a mesma regra que as contas dos colaboradores.
Monitorizar as sessões de fornecedores como sessões privilegiadas de colaboradores. Registe todas as sessões, crie alertas para picos de volume, acessos fora de horas e consultas sequenciais, e reveja a atividade dos fornecedores com uma periodicidade fixa. A gestão de acessos privilegiados (PAM) abrange a gravação de sessões e a elevação just-in-time. A secção seguinte apresenta uma referência para a rapidez com que esses alertas têm de disparar.
Tornar a saída do fornecedor uma condição obrigatória no fim do contrato. O contrato não é encerrado enquanto as contas do fornecedor não forem desativadas, as credenciais partilhadas não forem rodadas e uma revisão final de acessos não for assinada. Desativar uma conta não equivale a rodar aquilo que ela conhecia, porque as palavras-passe, chaves de API e tokens que o fornecedor já viu continuam válidos até serem alterados. O guia de saída de colaboradores aplica a mesma lógica aos funcionários e transpõe-se diretamente para os prestadores de serviços.

Com que rapidez seria detetado um acesso anómalo de fornecedores?

No caso dinamarquês, o acesso noticiado durou 21 dias e 17 horas até a administração do registo tomar conhecimento da fuga de dados, a 2 de outubro. Use esse intervalo como referência: se amanhã uma conta de fornecedor começasse a enumerar registos nos sistemas da organização, a monitorização assinalá-lo-ia mais cedo?

O padrão noticiado fornece sinais a testar. Uma enumeração por força bruta gera um elevado volume de consultas a partir de uma conta, muitas delas para identificadores que não existem, e o atacante também transferiu dados para um armazenamento fora do registo.

Sinal	No padrão dinamarquês	Alerta a testar
Volume	Consultas que se prolongaram durante três semanas	Número diário de consultas por conta de fornecedor face à respetiva linha de base
Enumeração	Força bruta para obter números CPR válidos	Taxa elevada de consultas falhadas ou sequenciais a partir de uma conta
Horário e origem	Não noticiado	Inícios de sessão fora do horário contratado ou a partir de novas localizações
Exfiltração	Dados armazenados fora do registo	Leituras ou exportações em massa por uma conta de fornecedor

O acesso permanente torna estes alertas mais difíceis de afinar, porque uma conta sem data de fim não tem um limite de projeto que sirva de referência para avaliar a sua atividade. O acesso limitado no tempo reduz aquilo que é preciso vigiar. Faça um exercício de simulação (tabletop): escolha a conta de fornecedor com maior alcance, simule o padrão de enumeração e meça o tempo até alguém ser alertado.

Como o Passwork ajuda a controlar o acesso de fornecedores e de terceiros

O Passwork permite a uma equipa atribuir a cada fornecedor exatamente as credenciais de que o contrato necessita e retirá-las numa única ação. As permissões ao nível do cofre e da pasta delimitam o acesso, o controlo de acesso baseado em funções separa os administradores dos membros e o registo de atividade guarda quem abriu o quê e quando. O Passwork gere as credenciais guardadas no cofre.

O modelo de gestão de acessos do Passwork corresponde aos seis controlos acima.

Controlo	Funcionalidade do Passwork
1. Delimitar à tarefa	Níveis de acesso definidos por cofre e pasta (Acesso completo, Apenas leitura, Proibido), tipos de cofre personalizados por projeto ou nível de acesso, e administradores corporativos atribuídos por política que o proprietário do cofre não pode remover
2. Acesso limitado no tempo	Links externos com prazo e, opcionalmente, de utilização única para credenciais de que um fornecedor precisa uma só vez, sem necessidade de conta; o acesso contínuo do fornecedor termina quando o grupo do fornecedor é desativado
3. Credenciais únicas	Contas individuais por utilizador e um gerador de palavras-passe integrado que aplica as regras de complexidade definidas pela organização
4. MFA no perímetro da organização	Os administradores podem impor a autenticação de dois fatores (TOTP, WebAuthn) em todas as contas; SAML SSO e LDAP/AD para os colaboradores
5. Monitorização	Registo de atividade das ações de utilizadores, administradores e sistema, exportável para Syslog ou para um SIEM
6. Controlo de saída	Desativação do grupo de um fornecedor sem o eliminar; o painel de segurança assinala as credenciais ainda acessíveis a utilizadores cujo acesso foi revogado, o que fornece a lista de rotação

Coloque as pessoas de cada fornecedor num único grupo e associe a desativação do grupo à data de fim do contrato na lista de verificação de saída. É um único passo, em vez de uma procura conta a conta.

Um cofre gere as credenciais que a organização guarda e emite. Não consegue impor regras de palavras-passe nos sistemas do próprio fornecedor nem num registo governamental, pelo que esses controlos continuam a depender das cláusulas contratuais, dos direitos de auditoria e da monitorização do controlo 5. Revogar o acesso também não apaga o que um prestador de serviços já viu: rode tudo aquilo que ele abriu.

O que fazer quanto ao risco de acesso de terceiros neste trimestre

O registo dinamarquês ficou exposto através das contas de acesso de um fornecedor, e a dimensão desse fornecedor não alterou em nada o resultado. Trate o risco de acesso de terceiros, antes de mais, como um problema de dimensionamento: liste aquilo a que cada conta de fornecedor consegue aceder, atribua a cada pessoa uma credencial gerada exclusivamente para ela e defina uma data de fim e um alerta de monitorização para cada uma.

Próximo passo: esta semana, liste todas as contas de fornecedores e prestadores de serviços com acesso permanente e, depois, execute a verificação do raio de impacto nas três com maior alcance.

Se a equipa concede a fornecedores ou prestadores de serviços acesso a credenciais partilhadas, inicie um teste gratuito do Passwork, delimite esse acesso por cofre, partilhe credenciais pontuais através de links com prazo e revogue o grupo de um fornecedor num só passo, com um registo de auditoria por trás de cada ação.

Perguntas frequentes sobre o risco de acesso de terceiros

O que é o risco de acesso de terceiros?

O risco de acesso de terceiros é a exposição que uma organização assume quando fornecedores, prestadores de serviços ou parceiros de integração têm acesso aos seus sistemas ou dados. O risco situa-se fora do perímetro de segurança da própria organização, mas pode ainda assim expor os seus dados, como na fuga de dados do CPR dinamarquês em 2026, em que as contas comprometidas de um fornecedor chegaram a 8,8 milhões de registos.

Em que difere o acesso de fornecedores do acesso de colaboradores?

As contas de fornecedores ficam muitas vezes fora dos processos de MFA, SSO e saída de colaboradores geridos pelos RH da própria organização, pelo que precisam de uma política de acesso, de uma periodicidade de revisão e de um gatilho de revogação próprios. Associe-os ao contrato, não ao organograma: o acesso começa e termina com o âmbito de trabalho contratado (statement of work), e um responsável identificado assina cada revisão.

Com que frequência rever as permissões de acesso de fornecedores?

Reveja as contas privilegiadas de fornecedores trimestralmente, as contas padrão de fornecedores pelo menos duas vezes por ano e todas as contas nos marcos do contrato, nas alterações de âmbito e no fim do contrato. Trate a revisão final como condição obrigatória para encerrar o contrato. Estas periodicidades são uma base prática; ajuste-as à avaliação de risco da organização.

Um gestor de palavras-passe resolve sozinho o risco de acesso de fornecedores?

Não. Um gestor de palavras-passe controla as credenciais nele guardadas: quem as detém, como são geradas, quem as abriu e quando. Não consegue impor regras de palavras-passe nos sistemas do próprio fornecedor, pelo que as cláusulas contratuais, a MFA no perímetro da organização, a monitorização e os controlos de saída continuam a ser importantes. É a base sobre a qual assentam os restantes controlos.

O que deve acontecer ao acesso de fornecedores quando um contrato termina?

Desative todas as contas do fornecedor, rode cada credencial partilhada e chave de API que o fornecedor pudesse ler, reveja o registo de atividade do período do contrato e registe a aprovação final antes de encerrar o contrato. Desativar apenas as contas deixa válidos as palavras-passe e os tokens que o fornecedor já viu, pelo que a rotação é um passo separado.