Saída de colaboradores: guia de revogação segura de acessos em 2026

Quando um colaborador deixa a empresa, o procedimento habitual é este: os RH encerram o ticket, a TI desativa a conta do Active Directory e o portátil volta para a prateleira. Concluído. Mas em 2026, isso já não basta. Fora do perímetro do SSO existem agentes de IA que funcionam com chaves de API guardadas localmente, contas de serviço sem proprietário, palavras-passe partilhadas que nenhum fornecedor de identidade (IdP) irá revogar e prazos de conformidade medidos em horas.

Este guia apresenta a administradores de TI e a equipas de segurança uma abordagem estruturada e prática para a revogação de acessos, que abrange todos estes casos.

Pontos principais

• Desativar uma conta SSO não equivale a revogar o acesso. As chaves de API, as palavras-passe partilhadas e os tokens guardados localmente sobrevivem por completo à desativação no IdP.
• A maioria das listas de verificação de saída de colaboradores ignora por completo as credenciais de agentes de IA. As ferramentas ligadas por MCP guardam chaves de API fora do perímetro do SSO e exigem passos de revogação explícitos.
• Apenas 20 % das organizações têm processos formais para revogar chaves de API quando um colaborador sai. A OWASP classifica a desativação incorreta das identidades não humanas (NHI) na saída de colaboradores como o risco mais elevado do seu Non-Human Identities Top 10 (2025).
• Os quadros de conformidade são específicos e exigentes. O controlo PS-4 do FedRAMP define uma janela de 4 horas; o CC6.1 do SOC 2 e o anexo A 6.5 da ISO 27001 tratam a revogação no próprio dia como o padrão mínimo; a Diretiva NIS2 (artigo 21.º) e o RGPD (artigo 32.º) esperam o mesmo das organizações da UE.
• As palavras-passe partilhadas têm de ser rodadas, e não apenas ter o acesso removido. Se o colaborador conhecia a palavra-passe, retirar apenas o acesso ao cofre não elimina a vulnerabilidade.
• A descoberta prévia à saída é o que torna fiável a execução na hora zero. Sem mapear todos os cofres, chaves de API, contas de serviço e credenciais de ferramentas de IA antes do último dia, a saída de colaboradores é reativa por definição.
• Os processos manuais, baseados em tickets, não conseguem cumprir os prazos de revogação atuais. A automatização entre o sistema de informação de recursos humanos (HRIS) e a gestão de identidades e acessos (IAM) via SCIM é a única arquitetura que elimina a janela de latência de forma consistente.

Os riscos ocultos de uma revogação de acessos tardia

Uma revogação de acessos tardia tem um desfecho previsível: um antigo colaborador mantém credenciais funcionais enquanto a equipa assume que a conta está encerrada. A janela de ameaça abre-se no momento em que a saída é confirmada, e as consequências vão da exfiltração de dados a sanções regulamentares.

Os prazos de conformidade estão a ficar mais apertados

A urgência está hoje consagrada nos principais quadros de conformidade. ISO 27001:2022, anexo A 6.5 (Responsabilidades após a cessação ou alteração da relação laboral) exige a remoção atempada dos direitos de acesso. Diretiva NIS2, artigo 21.º exige medidas adequadas de controlo de acesso como parte da higiene de segurança de base de uma organização. RGPD, artigo 32.º exige medidas técnicas e organizativas para proteger os dados pessoais, e uma conta ativa de um antigo colaborador constitui uma exposição direta ao abrigo dessa obrigação.

«As responsabilidades e os deveres em matéria de segurança da informação que permanecem válidos após a cessação ou a alteração da relação laboral devem ser definidos, aplicados e comunicados ao pessoal relevante e a outras partes interessadas» — ISO/IEC 27001:2022, Annex A, Control 6.5

Para organizações com contratos ou clientes federais nos EUA, FedRAMP e StateRAMP reforçaram as expectativas de implementação do PS-4 para uma janela de revogação de 4 horas, segundo as orientações de conformidade publicadas pela Paramify. SOC 2 Trust Services Criteria CC6.1 define expectativas semelhantes em matéria de controlos de acesso lógico documentados, e os auditores tendem cada vez mais a considerar a revogação no próprio dia como o padrão mínimo aceitável.

Em todos estes quadros, a implicação operacional é a mesma: os processos manuais de saída de colaboradores, baseados em tickets, não conseguem cumprir estes prazos de forma fiável. Um processo que depende de um administrador de TI reparar numa mensagem do Slack enviada pelos RH vai falhar.

Exfiltração de dados e ameaças internas

A superfície de ataque é concreta: plataformas de CRM com dados de clientes, repositórios de código com lógica proprietária, buckets de armazenamento na nuvem e credenciais de pipelines de CI/CD.

Cyberhaven identificou, na sua investigação, um aumento de 720 % da atividade de exfiltração de dados nas 24 horas anteriores a um despedimento, na sua maioria para armazenamento pessoal na nuvem, suportes amovíveis e ferramentas de IA generativa. Um antigo colaborador que mantenha acesso após essa janela não precisa de ter más intenções para causar danos; basta um script mal configurado a executar-se com o seu token ainda ativo.

Verizon identifica, no seu 2026 Data Breach Investigations Report (DBIR), o abuso de credenciais como responsável por 13 % das violações de dados, um valor que se concentra sobretudo em acessos que nunca foram devidamente revogados. O risco não é hipotético. Um programador que mantenha um token de acesso pessoal válido para um repositório do GitHub pode clonar todo o código-fonte semanas depois do último dia de trabalho.

Pontos cegos da saída de colaboradores em 2026: Agentes de IA e NHI

As listas de verificação habituais de saída de colaboradores (desativar a conta SSO, revogar a VPN, devolver o portátil) foram concebidas para um modelo de ameaças mais simples. Duas categorias de acesso sobrevivem hoje, de forma rotineira, a todos esses passos.

O problema do acesso dos agentes de IA

Em 2026, os programadores ligam assistentes de programação com IA e ferramentas de automatização a serviços externos através do Model Context Protocol (MCP). Estas integrações autenticam-se com chaves de API que o programador gera manualmente e guarda localmente: em ficheiros .env, ficheiros de configuração da shell, definições do IDE ou o armazenamento de credenciais da própria ferramenta de IA na máquina do programador.

Quando se desativa a conta Okta ou Entra ID desse programador, nenhuma dessas chaves guardadas localmente é afetada. A camada de SSO nunca soube da sua existência. Se o portátil do programador não for apagado de imediato, ou se tiver utilizado um computador pessoal para trabalhar, essas chaves continuam válidas e funcionais. A chave de API do ambiente de produção na nuvem, da conta Stripe ou do pipeline de dados interno não expira só porque a sessão SSO do colaborador terminou.

A solução prática exige dois passos que a maioria das listas de verificação de saída de colaboradores ignora por completo: auditar as chaves de API geradas pelo colaborador que sai (no GitHub, no AWS IAM, em plataformas de nuvem e em sistemas internos) e rodar ou revogar cada uma delas antes do último dia do colaborador, e não depois da recolha do dispositivo.

Identidades não humanas (NHI) órfãs

Non-Human Identities Top 10 da OWASP (2025) coloca o Improper Offboarding (saída de colaboradores sem desativação adequada) na posição NHI1:2025 , o risco com a classificação mais alta de toda a lista. A definição é precisa: desativação ou remoção insuficiente de identidades não humanas, como contas de serviço, chaves de API, tokens OAuth e certificados, quando a pessoa que as criou ou geria sai da organização.

Os relatórios da Cloud Security Alliance, publicados com um ano de intervalo, mostram que o problema não está a melhorar. No relatório de 2024 State of Non-Human Identity Security, a CSA concluiu que apenas 20 % das organizações têm processos formais de saída de colaboradores e de revogação de chaves de API. O estudo de seguimento de 2026, State of Non-Human Identity and AI Security, concluiu que as lacunas de governação aumentaram à medida que as cargas de trabalho de IA aceleraram a criação de identidades:

• Menos de 25 % das organizações têm políticas documentadas e formalmente adotadas para a criação ou eliminação de identidades de IA
• Mais de 16 % não monitorizam de todo a criação de novas identidades relacionadas com IA, o que deixa um subconjunto crescente de tokens e contas de serviço fora de qualquer inventário formal
• Apenas 12 % das organizações indicam ter elevada confiança na sua capacidade de prevenir ataques através de NHI

Quando um engenheiro sénior sai, as contas de serviço que criou, os tokens que registou e os certificados que emitiu continuam a funcionar indefinidamente.

O risco agrava-se porque as NHI têm, por rotina, privilégios excessivos. Um engenheiro que precisou de acesso alargado para diagnosticar um problema em produção há três anos pode ter criado uma conta de serviço com permissões de nível de administrador. Essa conta está agora sem proprietário e invisível para as revisões de acessos de utilizadores habituais. As ferramentas de IAM legadas não foram concebidas para lidar com isto: acompanham pessoas, não as credenciais que as pessoas criam.

Tratar a saída de colaboradores no caso das NHI exige um passo de descoberta dedicado antes de o colaborador sair: identificar todas as contas de serviço, tokens e certificados associados a essa pessoa, atribuir um novo proprietário e rodar as credenciais sempre que o colaborador que sai fosse o único a conhecer o segredo.

Como tratar as palavras-passe partilhadas na saída de colaboradores

As credenciais partilhadas são a categoria com maior probabilidade de ser ignorada num processo habitual de saída de colaboradores e a mais provável de ser explorada depois.

O perigo das credenciais partilhadas

As palavras-passe partilhadas não podem ser desativadas através de um SSO centralizado. Quando quatro pessoas de uma equipa partilham o mesmo início de sessão num portal de fornecedor, numa interface de gestão de equipamentos de rede ou numa aplicação legada, desativar a conta SSO de uma delas não afeta essa credencial partilhada. O colaborador que saiu conhece a palavra-passe e vai continuar a conhecê-la, a menos que seja alterada.

O problema agrava-se com a dimensão da equipa e a antiguidade. Um colaborador com muitos anos de casa pode ter acesso a dezenas de credenciais partilhadas acumuladas ao longo do tempo, credenciais que não estão documentadas em lado nenhum, que estão guardadas numa folha de cálculo numa unidade partilhada ou que só são conhecidas por quem as utiliza diariamente.

Gestão empresarial de palavras-passe para o controlo de cofres partilhados

É aqui que um gestor de palavras-passe empresarial dedicado se torna operacionalmente essencial, e não opcional. Quando as credenciais partilhadas estão num cofre estruturado com controlo de acesso baseado em funções (RBAC), a saída de colaboradores passa a ser um procedimento definido, e não um exercício de adivinhação.

Passwork cobre todo o âmbito do trabalho de credenciais na saída de colaboradores numa única plataforma:

• Membros dos cofres partilhados: cada cofre tem membros explícitos. A remoção de um colaborador que saiu revoga o acesso de imediato, sem depender de este se esquecer da palavra-passe ou decidir não a voltar a utilizar.
• Gestão de segredos: chaves de API, tokens, credenciais de bases de dados e certificados ficam ao lado das credenciais humanas na mesma hierarquia de cofres, sob o mesmo modelo de RBAC. Não é necessário um gestor de segredos separado.
• Controlo de contas de serviço: as contas de serviço são armazenadas e geridas centralmente no Passwork. Cada conta tem um proprietário atribuído. Quando esse proprietário sai, a conta surge de imediato na revisão de acessos, em vez de se tornar silenciosamente uma identidade órfã sem ninguém responsável.
• Registo de auditoria completo: todas as credenciais a que o colaborador que sai acedeu ficam registadas, o que dá à equipa de segurança uma lista clara do que é necessário rodar.
• REST API: permite integrar os fluxos de saída de colaboradores diretamente nos sistemas de RH ou de ITSM. A revogação do acesso aos cofres é acionada automaticamente quando é criado um ticket de cessação, sem intervenção manual.
• Acompanhamento da rotação: remover o acesso ao cofre impede acessos futuros. O registo de auditoria confirma que credenciais foram rodadas e quando, o que fecha a lacuna de conformidade.

O passo de rotação continua a ser o crítico. Remover o acesso ao cofre impede acessos futuros. Rodar as credenciais fecha a janela para as credenciais que o colaborador já conhece.

A lista de verificação de revogação segura de acessos para 2026

O modelo de quatro fases apresentado a seguir, o Secure Offboarding Execution Model (SOEM) (modelo de execução segura da saída de colaboradores), fornece aos administradores de TI uma sequência estruturada de revogação de acessos que abrange todo o âmbito do risco atual associado às credenciais.

Fase 1: Descoberta prévia à saída

Comece antes do último dia do colaborador. O objetivo é eliminar surpresas na hora zero.

• Audite shadow IT: utilize ferramentas de descoberta de SaaS ou dados de extensões do navegador para identificar as aplicações a que o colaborador acedeu e que não constam do inventário oficial.
• Mapeie as NHI: consulte o AWS IAM, o GitHub, o GitLab, o Azure AD e quaisquer plataformas internas de programação para encontrar contas de serviço, tokens de acesso pessoal e chaves de API associados à identidade do colaborador.
• Identifique os membros dos cofres partilhados: extraia um relatório do gestor de palavras-passe que mostre todos os cofres e pastas a que o colaborador tem acesso.
• Assinale as credenciais que exigem rotação: qualquer palavra-passe partilhada ou credencial de conta de serviço a que o colaborador tenha tido acesso deve ser colocada em fila para rotação, e não apenas para remoção de acesso.
• Atribua a propriedade das NHI: para cada conta de serviço ou token pertencente ao colaborador, designe um novo proprietário antes da saída.

Fase 2: Acionamento na hora zero (ações imediatas)

Execute estes passos no momento exato em que a cessação produz efeitos, idealmente acionados de forma automática pelo sistema de informação de recursos humanos (HRIS).

• Desative a conta do colaborador no fornecedor de identidade (Okta, Microsoft Entra ID, Google Workspace). Isto termina as sessões SSO ativas em todas as aplicações federadas.
• Revogue explicitamente as sessões ativas: a desativação do SSO nem sempre termina as sessões em curso. Force o fim das sessões no IdP e, em separado, nas aplicações de elevado valor (Microsoft 365, Google Workspace, Salesforce, GitHub).
• Revogue os certificados de VPN e as credenciais de acesso à rede.
• Desative o acesso físico: desativação de crachás, se aplicável.
• Notifique a equipa de segurança e o responsável hierárquico do colaborador em simultâneo.

Em ambientes regulados pelo FedRAMP, toda esta fase tem de estar concluída no prazo de 4 horas após o evento de cessação, de acordo com as orientações de implementação do PS-4. As organizações da UE sujeitas à NIS2 ou que tratam dados pessoais ao abrigo do RGPD, artigo 32.º não têm um prazo fixo, mas os reguladores esperam execução no próprio dia, e qualquer acesso ativo após a cessação é difícil de defender numa auditoria.

Fase 3: Limpeza profunda (nas 24 horas seguintes)

Os passos da hora zero cortam o acesso ativo. A fase 3 trata de tudo o que sobrevive a uma conta desativada.

• Rode todas as palavras-passe partilhadas a que o colaborador tinha acesso, com base no relatório de membros dos cofres gerado na fase 1.
• Revogue todas as chaves de API, tokens de acesso pessoal e tokens OAuth associados ao colaborador, incluindo os guardados localmente no dispositivo ou nas configurações de ferramentas de IA. Verifique o GitHub, o GitLab, o AWS IAM, as contas de serviço do GCP, os registos de aplicações do Azure e quaisquer portais internos de programação.
• Transfira a propriedade das contas de serviço e das credenciais de pipelines de CI/CD para um membro da equipa designado.
• Verifique as ferramentas de IA ligadas por MCP: identifique os assistentes de IA que o colaborador utilizou e se essas ferramentas guardaram credenciais localmente. Revogue as chaves de API subjacentes, independentemente do estado do dispositivo.
• Audite o armazenamento na nuvem: verifique unidades partilhadas, buckets S3 ou contentores de armazenamento a que o colaborador tinha acesso direto fora da federação SSO.
• Remova o colaborador das listas de distribuição, dos espaços de trabalho do Slack e de quaisquer ferramentas de colaboração externas (Notion, Confluence, Jira, Figma) que se autentiquem de forma independente.

Fase 4: Recolha e apagamento do dispositivo

O tratamento do dispositivo determina se as credenciais guardadas localmente (incluindo as chaves de API de agentes de IA) ficam neutralizadas de forma permanente.

Para dispositivos da empresa: recolha o dispositivo no último dia ou antes. Execute um apagamento remoto completo antes da recolha se existir qualquer risco de o colaborador ficar na posse física do equipamento. Não conte com a devolução do dispositivo pelo colaborador antes de o apagamento ser iniciado.

Para ambientes BYOD (Bring Your Own Device): o perfil de risco é mais elevado. Não é possível apagar um dispositivo pessoal, pelo que as credenciais guardadas localmente nesse dispositivo permanecem acessíveis indefinidamente. Por isso, a fase 3 (revogar todas as chaves de API e tokens) é inegociável na saída de colaboradores em ambientes BYOD. Os dispositivos BYOD registados na gestão de dispositivos móveis (MDM) permitem o apagamento seletivo dos perfis da empresa, o que remove o e-mail, as aplicações e as credenciais em cache da empresa sem tocar nos dados pessoais. Execute este passo na hora zero.

Documente o estado do dispositivo no registo do processo de saída. Se um dispositivo não for devolvido num prazo definido, escale o caso para o departamento jurídico e trate todas as credenciais que possam ter sido guardadas nele como comprometidas.

Matriz de prioridades de revogação de acessos

Automatizar o fluxo de saída de colaboradores

Integração entre o HRIS e o IAM

Os processos manuais de saída de colaboradores têm uma falha estrutural: dependem de uma pessoa reparar que outra deixou a empresa e agir em conformidade. Essa dependência introduz latência, e a latência é a vulnerabilidade.

A única forma fiável de cumprir janelas de revogação curtas é a automatização. Quando o HRIS (Workday, BambooHR, SAP SuccessFactors) aciona um evento de cessação, esse evento deve propagar-se automaticamente para a plataforma de IAM através de aprovisionamento SCIM ou de uma integração direta por API. A plataforma de IAM executa então a desativação da conta, a revogação de sessões e o desaprovisionamento a jusante sem esperar que seja aberto um ticket.

O padrão de integração é simples: evento de cessação no HRIS → chamada de desaprovisionamento SCIM ao IdP → o IdP desativa a conta e propaga a alteração às aplicações federadas → webhook ou chamada de API automatizados ao gestor de palavras-passe para assinalar o utilizador com vista à remoção do acesso aos cofres.

Esta arquitetura reduz a fase da hora zero de uma lista de verificação manual com vários passos para um único acionamento. O papel do administrador de TI passa de executor a verificador: confirma que os passos automatizados foram concluídos com êxito e trata os casos limite (NHI, chaves de agentes de IA, dispositivos BYOD) que a automatização ainda não consegue abranger.

Para as equipas que desenvolvem esta integração, a REST API e as ferramentas CLI do Passwork permitem o desaprovisionamento automatizado de utilizadores no âmbito de um fluxo de IAM mais amplo, o que possibilita incluir a remoção do acesso aos cofres na mesma sequência automatizada que a desativação da conta no IdP. O Passwork está disponível tanto como solução autoalojada como na nuvem.

Conclusão

A passagem de «desativar a conta do AD» para «revogar todo o rasto de credenciais» não é gradual: reflete um modelo de ameaças fundamentalmente diferente. Os agentes de IA, as NHI e as credenciais partilhadas criaram uma categoria de acesso que existe inteiramente fora do perímetro do SSO. As listas de verificação habituais não chegam lá.

As equipas que lidam bem com isto têm uma característica em comum: fazem o trabalho de descoberta antes do último dia. Sabem a que cofres o colaborador tinha acesso, que chaves de API gerou e que contas de serviço detinha. A execução na hora zero é rápida porque o inventário já existe.

Comece pela auditoria. Mapear os acessos antes da saída é a única forma de garantir que nada fica órfão depois.

Perguntas frequentes sobre a saída de colaboradores e a revogação de acessos

Qual é o maior risco de segurança na saída de um colaborador?

O maior risco é o acesso que sobrevive à desativação normal do SSO. Inclui chaves de API guardadas localmente e usadas por ferramentas de IA e scripts de automatização, palavras-passe partilhadas que não podem ser revogadas de forma centralizada e contas de serviço órfãs criadas pelo colaborador. Desativar uma conta no IdP fecha uma porta; estas credenciais representam pontos de entrada separados, muitas vezes não documentados, que exigem revogação explícita.

Com que rapidez deve ser revogado o acesso quando um colaborador sai?

Em ambientes FedRAMP e StateRAMP, as orientações de implementação do PS-4 apontam para uma janela de 4 horas após o evento de cessação. Para organizações abrangidas pelo SOC 2 ou pela ISO 27001, a revogação no próprio dia é o padrão de auditoria atual. As organizações da UE abrangidas pela NIS2 (artigo 21.º) ou pelo RGPD (artigo 32.º) não têm um prazo fixo, mas os reguladores esperam execução no próprio dia, e o acesso ativo após a cessação é difícil de defender numa auditoria. Na prática, a revogação na hora zero, acionada automaticamente no momento da cessação, é a única abordagem que elimina por completo a janela de risco.

Como tratar as palavras-passe partilhadas quando um colaborador cessa funções?

As palavras-passe partilhadas têm de ser rodadas, e não apenas ter o acesso removido. Se o colaborador conhecia a palavra-passe, continua a conhecê-la depois de o acesso ao cofre ser revogado. O passo de rotação é o que fecha a vulnerabilidade. Um gestor de palavras-passe empresarial com membros de cofres estruturados torna este processo auditável: é possível ver exatamente a que credenciais partilhadas o colaborador tinha acesso e rodá-las de forma sistemática sem perturbar o resto da equipa.

Qual é o problema dos agentes de IA na saída de colaboradores?

Os assistentes de programação com IA e as ferramentas de automatização ligados por MCP guardam chaves de API localmente na máquina do programador, em ficheiros .env, perfis da shell ou no armazenamento de credenciais da própria ferramenta. Estas chaves não são geridas pelo SSO. A desativação da conta do colaborador no IdP não as revoga. Até estas chaves de API específicas serem identificadas e revogadas (e o dispositivo ser apagado), as credenciais continuam válidas. Esta é uma lacuna em praticamente todas as listas de verificação de saída de colaboradores redigidas antes de 2025.

A desativação de uma conta SSO revoga todo o acesso às aplicações?

Não. A desativação do SSO termina as sessões federadas das aplicações que se autenticam através do IdP. Não afeta: aplicações que se autenticam de forma independente (ferramentas legadas, portais de fornecedores), chaves de API e tokens guardados localmente, sessões ativas estabelecidas antes da desativação e que ainda não expiraram, e credenciais partilhadas que o colaborador conhecia de memória. Cada uma destas categorias exige um passo de revogação separado.

O que deve incluir uma lista de verificação de saída de colaboradores de TI em 2026?

Uma lista de verificação de saída de colaboradores de TI completa para 2026 deve abranger: desativação da conta no IdP/SSO e terminação das sessões ativas, revogação de acessos de VPN e físicos, rotação das palavras-passe partilhadas através de um gestor de palavras-passe, revogação de chaves de API e tokens de acesso pessoal em todas as plataformas de programação, transferência da propriedade das NHI, auditoria das credenciais de ferramentas de IA, remoção de acessos ao armazenamento na nuvem, desaprovisionamento de aplicações SaaS e apagamento do dispositivo ou apagamento seletivo por MDM em BYOD. A fase de descoberta prévia à saída, que mapeia tudo isto antes do último dia, é o que torna fiável a execução na hora zero.

Shadow IT vs shadow AI: Porque a IA é a maior ameaça

Os colaboradores utilizam ferramentas de IA não aprovadas, em contas que não é possível monitorizar, com dados que não é possível recuperar. Eis o que o risco representa na realidade e o que a governação tem de abordar.

Passwork BlogAlex Muntyan

Partilha insegura de palavras-passe: Riscos e soluções seguras em 2026

Sempre que uma credencial circula pelo Slack ou por e-mail, perdem-se de uma só vez a responsabilização, o registo de auditoria e a postura de conformidade. Este guia aborda os riscos reais da partilha insegura de palavras-passe em 2026, as razões pelas quais os colaboradores a fazem e como migrar para o acesso mediado por cofres sem perturbar a equipa.

Passwork BlogAlex Muntyan

Passwork conquista o Top Performer Spring 2026 na SourceForge

O Passwork foi distinguido como Top Performer Spring 2026 pela SourceForge, e posiciona-se no top 10 % de mais de 100 000 soluções. O distintivo baseia-se exclusivamente em avaliações verificadas: 4,8 estrelas no geral, com uma pontuação perfeita de 5,0 em suporte.

Passwork BlogAlex Muntyan