Saída do analista de TI: como não perder o conhecimento da empresa

Por que a saída de um analista de TI vira crise

Em boa parte das empresas brasileiras de pequeno e médio porte, a área de TI é uma pessoa só. Esse profissional configurou o firewall, criou as contas de e-mail, sabe qual servidor roda o ERP, lembra de cor a senha do roteador principal e é o único que já viu o painel do provedor de hospedagem. Enquanto ele está lá, tudo funciona. No dia em que ele pede demissão — ou é desligado — a empresa descobre que boa parte da sua infraestrutura não estava documentada em lugar nenhum: estava na cabeça dele.

O problema não é técnico, é de gestão de risco. Quando o conhecimento crítico de TI vive na memória de um indivíduo, a empresa opera com um ponto único de falha humano. Diferente de um servidor, que pode ter redundância, uma pessoa não tem réplica. E o aviso prévio de trinta dias raramente é usado para transferir conhecimento — normalmente é gasto resolvendo pendências operacionais, enquanto o profissional já está mentalmente no próximo emprego.

Os sintomas aparecem semanas depois da saída: ninguém consegue renovar o certificado SSL porque a conta está no e-mail pessoal do ex-funcionário; a licença do antivírus vence e não há quem saiba com qual revenda foi comprada; o backup para de rodar e ninguém percebe porque o alerta ia para uma caixa que não existe mais. São falhas silenciosas que só viram incidente quando já é tarde.

Mapeie os acessos antes de anunciar a saída

O primeiro erro é começar o inventário depois do pedido de demissão. O inventário de acessos deve existir permanentemente, atualizado, independente de quem está na função. Mas se a empresa está no meio da transição e não tem nada disso, a prioridade é reconstruir o mapa rápido — e com o profissional ainda presente e colaborativo.

Comece pelos acessos que a empresa não controla diretamente, porque são os mais fáceis de perder para sempre. Registro de domínio, DNS, hospedagem do site, contas de provedor de nuvem, portais de licenciamento, painéis de operadora de link, conta do certificado digital e-CNPJ. Se o registro do domínio estiver num e-mail pessoal e ninguém tiver o acesso, a empresa pode literalmente perder o próprio site na próxima renovação.

• Contas administrativas de identidade: Microsoft 365 / Google Workspace, Active Directory, conta de administrador global e contas de emergência.
• Infraestrutura de rede: firewall, switches gerenciáveis, controladora de Wi-Fi, VPN, roteadores de operadora.
• Servidores e virtualização: hypervisor (VMware, Hyper-V, Proxmox), consoles de gerenciamento, iDRAC/iLO, credenciais locais de administrador.
• Backup e recuperação: console do software de backup, repositório em nuvem, chaves de criptografia dos jobs — sem a chave, o backup existe mas não restaura.
• Sistemas de negócio: ERP, banco de dados, integrações fiscais, certificados A1/A3, ambientes de homologação.
• Fornecedores e contratos: quem é a revenda de cada licença, quais contratos vencem quando, qual telefone abre chamado em cada fabricante.

Para cada item registre quatro campos mínimos: onde fica, quem tem acesso hoje, o que quebra se cair e quem é o fornecedor responsável. Sem esses quatro campos, a lista vira um monte de senha solta sem contexto — e senha sem contexto não resolve incidente às duas da manhã.

Cofre de senhas: pare de usar planilha e e-mail

A prática mais comum e mais perigosa é a planilha de senhas. Ela costuma estar num compartilhamento de rede, sem criptografia, com histórico de versões acessível, copiada para o notebook de duas ou três pessoas e frequentemente anexada em e-mails antigos. Quando o analista sai, essa planilha vai embora junto na cópia local dele — e continua válida, porque ninguém troca as senhas.

A alternativa correta é um cofre de senhas corporativo com controle de acesso por perfil, registro de auditoria e a senha nunca trafegando em texto puro. O ponto central é que a credencial pertence à empresa, não ao indivíduo. O técnico consulta o que precisa, o acesso fica logado, e quando ele sai basta revogar o usuário do cofre em vez de sair caçando onde ele guardou cada senha.

Se a saída de uma pessoa obriga a empresa a trocar dezenas de senhas às pressas, o problema não foi a saída — foi não ter cofre desde o começo.

Mesmo com cofre, existem credenciais que devem ser rotacionadas no desligamento por princípio: administrador de domínio, root de servidores, contas de serviço com privilégio elevado, chaves de API, acessos ao provedor de nuvem e ao painel de backup. Não é desconfiança da pessoa — é higiene de segurança. Toda credencial que um humano viu em texto claro deve ser considerada comprometida no momento em que aquele humano deixa de precisar dela.

Outro cuidado: nenhuma conta administrativa deve estar vinculada a um e-mail pessoal ou a um número de celular particular para recuperação e segundo fator. Migre a recuperação para um e-mail corporativo de grupo e o MFA para um método que a empresa controle antes que a pessoa saia. Depois do desligamento, recuperar uma conta atrelada ao celular de um ex-funcionário é um processo lento e humilhante.

Documentação que sobrevive à pessoa

Documentação de TI só serve se alguém que nunca viu aquele ambiente conseguir usar. Manual de 80 páginas escrito uma vez e nunca revisado não é documentação, é arqueologia. O formato que funciona é o runbook curto e específico: um procedimento por documento, com o passo a passo real, os nomes reais dos servidores e o que fazer quando dá errado.

Priorize documentar o que dói mais se faltar. Não é preciso documentar tudo antes da saída da pessoa — é preciso documentar o que ninguém mais sabe fazer. Peça ao profissional que liste, honestamente, as tarefas que só ele executa. Essa lista é o roteiro da transferência.

1. Diagrama de rede atualizado: links, faixas de IP, VLANs, regras de firewall principais, onde entra a internet e por onde sai.
2. Procedimento de restauração de backup: testado, não apenas descrito. Um restore que nunca foi executado é uma hipótese, não um plano.
3. Rotinas periódicas: o que roda toda noite, todo mês, todo trimestre — e como saber se falhou.
4. Onboarding e offboarding de usuário: criar conta, aplicar permissões, entregar equipamento, bloquear na saída.
5. Contatos de escalonamento: quem chamar para link caído, para servidor parado, para o ERP fora do ar, com número de contrato em mãos.
6. Peculiaridades do ambiente: aquele serviço que precisa subir antes do outro, o sistema legado que só roda numa VM antiga, a integração que quebra se mudar o IP.

O último item é o mais valioso e o mais esquecido. Todo ambiente tem gambiarras históricas que funcionam por motivos que só uma pessoa entende. Documentar essas exceções vale mais do que descrever pela vigésima vez como se instala um sistema operacional.

O checklist prático de transferência

Com o aviso prévio correndo, o tempo é curto e o foco precisa ser cirúrgico. Trate a transferência como projeto, com responsável, prazo e checklist assinado. Idealmente, a pessoa que vai receber o conhecimento executa os procedimentos com o profissional que está saindo assistindo — e não o contrário. Ver alguém fazer não transfere competência; fazer sob supervisão transfere.

• Semana 1: inventário completo de acessos, migração de credenciais para o cofre corporativo, troca de e-mails de recuperação para contas corporativas.
• Semana 2: documentação dos procedimentos críticos e das tarefas exclusivas, com validação de que outra pessoa consegue seguir o texto.
• Semana 3: execução acompanhada — restore de backup, criação de usuário, abertura de chamado em fornecedor, acesso remoto de emergência.
• Semana 4: rotação de credenciais privilegiadas, revogação de acessos, transferência formal de contratos e contatos de fornecedores.
• Dia do desligamento: bloqueio de conta, revogação de sessões ativas e tokens, recolhimento de equipamentos, remoção de VPN e certificados, encerramento de acesso físico.

Não esqueça das sessões já autenticadas. Bloquear a conta no diretório não derruba automaticamente um token de aplicativo válido, um app de celular já logado ou uma sessão de VPN persistente. Revogue explicitamente sessões e tokens nos serviços em nuvem, e verifique dispositivos móveis registrados.

Por fim, registre a entrega. Um termo simples listando o que foi transferido, assinado pelas duas partes, protege a empresa e o profissional. Ele evita a situação clássica de, três meses depois, alguém ligar para o ex-funcionário pedindo uma senha — algo que não deveria acontecer nem juridicamente nem tecnicamente.

Como reduzir a dependência de uma única pessoa

Resolver a saída de um analista é operação de curto prazo. O problema estrutural é a empresa continuar dependendo de uma cabeça só. Enquanto a TI for uma pessoa, cada férias, cada atestado e cada proposta melhor da concorrência é um risco operacional direto para o negócio.

Há três caminhos de redução de dependência. O primeiro é redundância interna, que exige contratar mais gente — caro e nem sempre justificável para uma empresa de 30 a 200 funcionários. O segundo é padronização e documentação rígida, que ajuda mas depende de disciplina contínua. O terceiro é apoiar a TI interna em um parceiro externo que mantenha o conhecimento do ambiente de forma institucional, com equipe, processo e ferramenta — de modo que o conhecimento não more mais em uma pessoa, e sim em uma estrutura.

É exatamente esse o modelo que a Duk Informática & Cloud pratica há mais de 18 anos com mais de 550 empresas atendidas. Como Microsoft Gold Partner, mantemos inventário de ativos, cofre de credenciais corporativo, documentação viva do ambiente e monitoramento contínuo de backup e infraestrutura para cada cliente. Quando um analista sai, o cliente não perde o mapa: a documentação, os acessos e o histórico continuam onde sempre estiveram — na estrutura, não na memória de alguém.

Se a sua empresa está passando por uma transição de TI agora, ou percebeu ao ler este texto que não saberia responder onde está a senha do firewall, o momento de agir é antes do próximo aviso prévio. Um levantamento de acessos e um plano de continuidade custam infinitamente menos do que reconstruir um ambiente do zero porque ninguém sabia onde estava a chave.