1. O desligamento que não terminou quando o profissional saiu

Em uma empresa, o desligamento de um profissional de tecnologia havia sido conduzido como tantos outros: reunião com o RH, devolução do equipamento, assinatura dos documentos e comunicação às áreas. No papel, o vínculo havia terminado. Na infraestrutura, porém, ele continuava existindo.

Dias depois, durante uma revisão preventiva, surgiram contas administrativas que ainda estavam ativas, credenciais compartilhadas cuja senha não havia sido alterada e acessos remotos que ninguém sabia dizer se ainda eram utilizados. Havia também scripts, integrações e rotinas automatizadas criadas pelo ex-colaborador e conhecidas apenas por ele.

Não ocorreu um ataque. Não houve sabotagem. Nenhum dado foi apagado. E justamente por isso o caso é tão importante: a empresa estava exposta sem perceber, não por causa de um invasor sofisticado, mas porque o processo de desligamento havia tratado a saída como uma questão trabalhista e patrimonial, não como um evento de segurança e continuidade.

Para preservar confidencialidade, esta narrativa reúne elementos recorrentes de situações reais que acompanhei ao longo da carreira. O padrão se repete em empresas de diferentes setores: a pessoa sai, mas suas permissões, seus conhecimentos exclusivos e suas dependências técnicas permanecem.

A partir desse momento, a organização passa a carregar um risco que não aparece em relatórios financeiros, não aciona alarmes e não causa indisponibilidade imediata. Ele apenas fica esperando uma oportunidade, um erro ou uma crise para se revelar.

2. O risco que continua trabalhando depois do expediente

Quando pensamos em ameaça interna, é comum imaginar um funcionário mal-intencionado. Essa imagem é incompleta. O risco interno também nasce de descuido, permissões excessivas, contas esquecidas, senhas compartilhadas, acessos de fornecedores e mudanças de função que nunca foram refletidas nos sistemas.

Uma credencial válida é especialmente perigosa porque não precisa “invadir” nada. Ela entra pela porta da frente. Para muitos controles, aquele acesso parece legítimo. É por isso que credenciais continuam entre os principais caminhos explorados por atacantes, e por que a gestão de identidades precisa ser tratada como processo de negócio, não apenas como configuração técnica.

O relatório DBIR 2025 da Verizon destacou novamente a presença elevada do elemento humano e do abuso de credenciais em violações, além de apontar que o envolvimento de terceiros dobrou em relação ao período anterior. A conclusão não é que funcionários e fornecedores sejam inimigos. É que qualquer identidade com acesso representa uma responsabilidade que precisa ter dono, finalidade, prazo e revisão.

Contas administrativas genéricas, como “admin”, “suporte” ou “ti”, dificultam rastreabilidade. Senhas compartilhadas eliminam a capacidade de atribuir uma ação a uma pessoa específica. Acessos permanentes concedidos para uma atividade temporária transformam exceções em vulnerabilidades estruturais.

O risco não está apenas em alguém fazer algo errado. Está também em a empresa não conseguir provar quem fez, quando fez e por que tinha permissão para fazer.

3. Conhecimento concentrado também é uma vulnerabilidade

Nem todo risco de segurança envolve senha. Às vezes, a vulnerabilidade está na cabeça de uma única pessoa.

Quem conhece a arquitetura completa? Quem sabe como restaurar o ambiente? Quem entende as integrações? Quem possui contato direto com fornecedores? Quem sabe onde estão os certificados, chaves, tokens, scripts e contratos? Se a resposta para várias dessas perguntas for o mesmo nome, a empresa possui um ponto único de falha humano.

Essa dependência costuma ser confundida com confiança. “Ele está conosco há muitos anos.” “Sempre resolveu.” “Só ele conhece.” Essas frases parecem elogios, mas também descrevem fragilidade operacional.

Conhecimento concentrado aumenta o custo de desligamentos, férias, afastamentos e promoções. Também enfraquece negociações com fornecedores e profissionais-chave, porque a empresa perde autonomia sobre sua própria operação.

Documentar não significa produzir manuais extensos que ninguém lê. Significa registrar o mínimo necessário para que outra pessoa qualificada consiga compreender o ambiente, executar procedimentos críticos e continuar a operação. Diagramas, inventário, credenciais em cofre, responsáveis, contratos, rotinas de backup, dependências e procedimentos de recuperação não são burocracia. São mecanismos de continuidade.

4. O fornecedor que virou ponto único de falha

Muitas organizações terceirizam infraestrutura, suporte, segurança, desenvolvimento e administração de sistemas. Isso pode ser eficiente. O erro está em terceirizar também o controle.

Em alguns ambientes, o fornecedor possui acesso remoto permanente, contas privilegiadas, conhecimento exclusivo e capacidade de alterar sistemas críticos sem acompanhamento. A empresa, por sua vez, não possui inventário atualizado, logs revisados, plano de saída nem outra equipe capaz de assumir o serviço.

Essa relação deixa de ser parceria e passa a ser dependência. Se o fornecedor falhar, encerrar atividades, trocar a equipe, sofrer um incidente ou simplesmente deixar de responder, a organização descobre que não domina a infraestrutura que financia.

O NIST CSF 2.0 inclui a governança de riscos de fornecedores e parceiros dentro da gestão de risco cibernético. Isso reforça um princípio essencial: acesso de terceiros precisa ser limitado, monitorado, revisado e vinculado a obrigações claras.

Contrato não substitui controle técnico. SLA não substitui plano de contingência. Confiança não substitui evidência.

5. Segurança não começa no firewall

Firewalls, antivírus, EDR, SIEM, autenticação multifator e ferramentas de monitoramento são fundamentais. Mas nenhuma delas compensa indefinidamente uma governança fraca.

Uma empresa pode adquirir a melhor tecnologia e continuar vulnerável se não souber quais ativos possui, quem tem acesso, quais sistemas são críticos, quais fornecedores entram remotamente e como as permissões são encerradas.

O NIST CSF 2.0 elevou “Governar” a uma função central do framework. A mensagem é clara: segurança não é apenas proteger, detectar e responder. É definir responsabilidades, prioridades, políticas, supervisão e relação com o risco empresarial.

Quando a liderança trata segurança como responsabilidade exclusiva da TI, cria um paradoxo. A TI é cobrada por controlar acessos que o negócio insiste em conceder, por corrigir processos que o RH não comunica e por limitar fornecedores que os gestores contratam sem requisitos técnicos.

Segurança começa na clareza de decisão. Quem autoriza? Quem revisa? Quem aceita o risco? Quem responde quando a exceção deixa de ser exceção?

6. O custo acumulado das pequenas exceções

Grandes incidentes frequentemente são construídos por pequenas concessões.

“Deixe o acesso por mais alguns dias.” “Não altere a senha porque a integração pode parar.” “Esse fornecedor é de confiança.” “Depois documentamos.” “Ele precisa ser administrador para trabalhar.” “Sempre funcionou assim.”

Cada frase parece razoável quando analisada isoladamente. O problema aparece quando essas decisões se acumulam por meses ou anos. A empresa cria uma camada de permissões históricas, contas desconhecidas, serviços sem dono e dependências que ninguém deseja tocar por medo de interromper a operação.

Esse fenômeno é uma forma de dívida técnica e de dívida de segurança. A organização recebe um benefício imediato — rapidez, conveniência ou redução de conflito — e transfere o custo para o futuro. O pagamento costuma ocorrer durante uma auditoria, um desligamento, um ataque ou uma indisponibilidade.

Exceções precisam ter prazo, responsável e critério de encerramento. Caso contrário, viram arquitetura.

7. Privilégio excessivo: quando todos podem fazer mais do que precisam

O princípio do menor privilégio é simples: cada pessoa, serviço ou fornecedor deve possuir apenas o acesso necessário para executar sua função, pelo tempo necessário.

Na prática, muitas empresas fazem o contrário. Concedem acesso amplo para evitar chamados, copiam permissões de outros usuários, mantêm antigos privilégios após mudanças de cargo e usam contas administrativas no trabalho cotidiano.

Isso amplia o impacto de erros e compromissos de credenciais. Uma conta comum comprometida possui alcance limitado. Uma conta privilegiada pode alterar configurações, apagar logs, acessar dados sensíveis, criar usuários e desativar controles.

O problema não se resolve apenas com uma revisão anual. Mudanças de função, projetos temporários, férias, afastamentos, novas integrações e fornecedores exigem um ciclo contínuo de gestão de identidade.

Acesso não deve ser entendido como benefício permanente. É uma autorização revogável vinculada a uma necessidade atual.

8. Como conduzir o desligamento seguro de um profissional de TI

O desligamento de alguém com acesso privilegiado é diferente de outras áreas porque essa pessoa pode conhecer credenciais, rotas alternativas, contas de serviço, integrações, falhas e dependências que não aparecem em um inventário comum.

Isso não justifica tratar o profissional como suspeito. Justifica tratar o processo com disciplina.

Um desligamento seguro deve coordenar RH, liderança, jurídico quando necessário e responsáveis técnicos. O momento da revogação precisa ser alinhado à comunicação, reduzindo tanto a exposição quanto o risco de interrupção indevida.

A organização deve revogar contas pessoais, sessões ativas, VPN, e-mail, nuvem, painéis de fornecedores, sistemas de gestão, repositórios de código, cofres de senha e ferramentas de suporte remoto. Também precisa alterar credenciais compartilhadas que a pessoa conhecia, renovar chaves e tokens quando aplicável e revisar contas de serviço criadas ou mantidas por ela.

É necessário recolher ativos, preservar dados corporativos e garantir que dispositivos pessoais não mantenham informações da empresa. Logs e evidências relevantes devem ser preservados conforme políticas internas e orientação jurídica.

A transferência de conhecimento deve ocorrer antes do desligamento sempre que o contexto permitir, mas não pode depender exclusivamente da boa vontade do profissional. A empresa precisa manter documentação e redundância de conhecimento como prática permanente.

Por fim, alguém deve validar o processo. Não basta marcar itens em um checklist. É preciso testar: o acesso realmente falhou? As sessões foram encerradas? As integrações continuam funcionando? Alguma conta desconhecida permanece ativa?

9. Um checklist executivo para reduzir o risco interno

Uma diretoria não precisa dominar ferramentas de identidade para fazer perguntas importantes. Precisa exigir respostas verificáveis.

Quem possui acesso administrativo aos sistemas críticos? Existem contas compartilhadas? Quando as permissões foram revisadas pela última vez? Quais fornecedores possuem acesso remoto e por qual período? Há contas sem responsável identificado? O RH comunica admissões, mudanças e desligamentos à TI em tempo adequado? Existe documentação suficiente para substituir pessoas-chave? As credenciais privilegiadas ficam em cofre e têm rotação? Os logs permitem atribuir ações a indivíduos? Já simulamos a saída repentina de um profissional crítico?

Se as respostas forem vagas, o risco não está controlado. Está apenas desconhecido.

A CISA recomenda programas estruturados de mitigação de risco interno, e o NIST CSF 2.0 inclui explicitamente práticas de recursos humanos, onboarding, mudança de função e offboarding na governança de cibersegurança. Isso mostra que o problema não pertence a um único departamento.

Gestão de acesso é um processo transversal. Segurança, RH, jurídico, compras, áreas de negócio e fornecedores participam da construção — ou da redução — do risco.

10. O maior risco pode estar autorizado

Não devemos cair no exagero de tratar todos dentro da empresa como ameaça. Culturas baseadas em desconfiança prejudicam colaboração, retenção e desempenho.

O objetivo é o oposto: construir controles que protejam pessoas e organizações sem depender de suspeitas. Processos claros evitam acusações, reduzem ambiguidades e tornam o ambiente mais profissional.

Quando identidades são individuais, permissões são proporcionais, acessos são revisados e desligamentos são coordenados, a empresa reduz o risco para todos. O profissional não carrega responsabilidades indefinidas, o gestor consegue demonstrar governança e a organização preserva sua continuidade.

O maior risco tecnológico pode não ser um hacker porque o hacker ainda precisa encontrar uma forma de entrar. Uma conta esquecida, um fornecedor com privilégio excessivo ou um processo sem dono já estão dentro.

A pergunta que a liderança deveria fazer não é apenas “estamos protegidos contra ataques?”. É também “quem já possui acesso, por que possui e o que aconteceria se esse acesso fosse usado de forma indevida ou simplesmente permanecesse ativo quando não deveria?”.

11. A lição: segurança é governar confiança

A tecnologia empresarial depende de confiança. Confiamos em profissionais, fornecedores, sistemas, processos e decisões. O erro não está em confiar. Está em transformar confiança em ausência de controle.

Boas empresas não eliminam confiança; elas a tornam verificável. Definem responsabilidades, limitam privilégios, registram ações, documentam conhecimento e encerram acessos quando deixam de ser necessários.

O hacker explora vulnerabilidades. Mas as vulnerabilidades mais persistentes costumam sobreviver porque alguém decidiu adiar, tolerar ou ignorar sua correção.

O maior risco tecnológico nem sempre invade sua empresa. Às vezes, ele já possui senha, conhecimento e permissão.

Roteiro mínimo de offboarding privilegiado

Identidades - Revogar contas pessoais, e-mail, VPN, SSO, nuvem e consoles administrativos.

Credenciais - Alterar senhas compartilhadas; renovar chaves, certificados e tokens conhecidos.

Sessões - Encerrar sessões ativas e invalidar tokens persistentes.

Terceiros - Revisar acessos mantidos em portais de fornecedores, suporte remoto e contratos.

Conhecimento - Confirmar documentação, responsáveis substitutos e continuidade das rotinas.

Ativos e dados - Recolher equipamentos; preservar dados corporativos e evidências conforme política.

Validação - Testar a revogação, revisar logs e confirmar que integrações continuam operacionais.

Referências

Verizon. 2025 Data Breach Investigations Report (DBIR).

NIST. The NIST Cybersecurity Framework (CSF) 2.0, 2024.

NIST. SP 1308 — Cybersecurity Framework 2.0: Cybersecurity, Enterprise Risk Management, and Workforce Management Quick-Start Guide, 2026.

NIST NCCoE. Identity and Access Management — SP 1800-2.

CISA. Insider Threat Mitigation Resources and Insider Risk Mitigation Program Evaluation.