Gestão de acessos para terceiros e prestadores

Por que terceiros representam risco crescente de segurança

Terceiros e fornecedores são categoria especial de risco por três razões estruturais:

• Acesso temporário mas crítico: mesmo que o acesso dure apenas semanas ou meses, durante esse período o terceiro pode ter visibilidade sobre dados sensíveis, código-fonte ou configuração de infraestrutura. Caso o terceiro seja comprometido (malware, credencial roubada), o acesso permanece válido até ser descoberto.
• Ciclo de vida não gerenciado: acessos de colaboradores internos são revogados quando a pessoa sai da empresa — processo automático ou semi-automático. Acessos de terceiros dependem de lembretes baseados em data de contrato — frequentemente esquecidos. Dados de incidentes mostram que acesso residual de terceiros é achado comum em forensics pós-breach^[2].
• Escopo indefinido: acessos internos têm baseline — começam com least privilege e evoluem. Acessos de terceiros começam vagos: "precisa acessar sistemas de RH" pode significar apenas nó de folha de ponto, ou pode incluir salários, dados pessoais de todos os colaboradores, e histórico de desligamentos.

A solução não é negar acesso a terceiros — em qualquer organização de tamanho médio, terceiros são necessários para consultoria, desenvolvimento, manutenção e suporte. O desafio é estruturar o acesso de forma que o risco seja visível e controlável.

Modelo de ciclo de vida para acessos de terceiros

O ciclo completo segue 6 fases com pontos de controle explícitos:

1. Solicitação e especificação: quando necessidade de terceiro é identificada, solicitante especifica: nome do fornecedor, duração esperada, escopo exato de acesso (quais dados, quais sistemas, qual ação — read-only vs. modificação). Solicitação é documentada em formulário padronizado ou ticket de TI.
2. Aprovação e validação de contrato: solicitação é aprovada por gerente de linha, gestor de TI, e legal/procurement. Nesta etapa, legal verifica que contrato/SOW especifica exatamente quais dados podem ser acessados — não basta dizer "acesso a sistemas de RH", contrato deve dizer "acesso a nó de processamento de folha de ponto, sem visibilidade a salários".
3. Provisionamento: credenciais são criadas (novo usuário, novo token, novo certificate) com data de expiração alinhada ao fim do contrato. Se modelo for JIT (just-in-time), acesso não é permanentemente criado — é solicitado sob demanda e válido por X horas.
4. Notificação e onboarding: terceiro é notificado de credenciais via canal seguro. Se acesso exigir treinamento (ex: MFA, protocolo de segurança específico), é realizado nesta etapa. Também nesta fase, é reforçado que acesso é for purpose only e sujeito a auditoria.
5. Monitoração ativa: durante validade do acesso, logs são coletados (quando login ocorre, qual sistema foi acessado, qual ação foi realizada). Para acessos críticos, gravação de sessão é ativada — útil para forensics se houver desvio suspeito ou se acesso for comprometido.
6. Revogação e validação: antes do termo do contrato (ou imediatamente após), credenciais são desativadas. Validação ocorre testando se acesso é efetivamente revogado (tentar login deve falhar). Registro de revogação é mantido por auditoria — quando foi feito, por quem, qual a razão.

Controles de segurança adicionais para acessos de terceiros

Para reduzir risco, além do ciclo de vida estruturado, controles adicionais são implementados dependendo do criticidade de acesso:

• MFA (autenticação multifator) obrigatória: mesmo que colaborador interno não use MFA, terceiro deve. MFA adiciona camada — mesmo que senha seja roubada, acesso não é ganho sem segundo fator (celular, hardware key).
• Acesso proxied (indireto): em vez de acesso direto a sistema, terceiro acessa via proxy (VPN, Citrix, RDP). Proxy registra todas as ações em logs centralizados — oferece auditoria melhor e permite desconexão remota se suspeitar de comprometimento.
• Gravação de sessão: para acessos críticos (dados pessoais, código-fonte, configuração de infraestrutura), sessão é gravada — útil para forensics e compliance com LGPD (demonstra que acesso foi monitorado).
• Isolamento de rede: terceiro acessa via segmento de rede isolado — não pode acessar infraestrutura geral da empresa, apenas os sistemas específicos do seu escopo.
• Aviso de aceite de segurança: antes de acesso ser concedido, terceiro deve aceitar termo de segurança — não pode acessar dados além do escopo, não pode compartilhar credencial, não pode baixar dados para máquina pessoal sem aprovação.
• Alertas de anomalia: se acesso ocorre fora do horário usual, de IP diferente ou com padrão de ação suspeito, alerta é disparado para revisar.

Integração com LGPD: obrigações específicas para terceiros

Lei Geral de Proteção de Dados (LGPD) trata fornecedores que acessam dados pessoais como processadores de dados — categoria com obrigações específicas. Artigos 32 e 37 da LGPD exigem^[3]:

• Contrato explícito: contrato com processador deve especificar claramente quais dados pode acessar, por quanto tempo, para qual finalidade. Não basta dizer "acesso a sistemas de RH" — deve dizer "acesso a dados de folha de ponto dos últimos 6 meses, exclusivamente para processamento de audit externo".
• Cláusula de segurança: contrato deve incluir obrigações de segurança — MFA obrigatório, acesso monitorado, logs retidos, vedado compartilhamento de credenciais.
• Termo de sigilo: terceiro deve assinar confidentiality agreement (ainda que contrato já o cubra) — demonstra consentimento explícito de não-divulgação.
• Auditoria periódica: LGPD exige que controlador (sua empresa) realize auditoria periódica do processador — ao menos anual. Pode ser simples: questionário de segurança, revisão de logs de acesso, confirmação de que acesso foi revogado no prazo.
• Documentação do ciclo de vida: para compliance, deve estar documentado: quando acesso foi concedido, qual escopo, quando foi revogado. Registro é mantido por ao menos 3 anos (período de prescrição LGPD).

Políticas práticas: o que documentar em política formal

Uma política de acesso a terceiros deve cobrir:

1. Definição de terceiro: consultores, fornecedores, parceiros, agências — qualquer pessoa externa que precise acessar dados ou sistemas.
2. Duração máxima: especificar limite — ex: 90 dias para consultores, 12 meses para fornecedores de suporte contínuo, com renovação explícita requerida.
3. Aprovadores: quem pode aprovar — ex: gerente de TI para acesso operacional, CFO para acesso a dados financeiros, legal para acesso a documentos jurídicos.
4. Escopo mínimo (least privilege): acesso deve ser o menor possível — read-only quando suficiente, sem acesso a dados além do necessário.
5. Modelo de acesso padrão: definir: MFA é obrigatório? Proxied ou acesso direto? Conta nomeada ou genérica? JIT quando viável?
6. Monitoração obrigatória: quais acessos geram logs, quais exigem gravação de sessão, qual é frequência de revisão de logs.
7. Revogação procedural: como terceiro comunica que terminou, como TI confirma revogação, como registra que foi feito.
8. Exceções e escalação: quando é possível desviar da política (ex: acesso de emergência), como é aprovado, por quanto tempo é válido, como é documentado.