- Conta dedicada para fornecedor (nada de compartilhar login)
- Menor privilégio: só o necessário, pelo menor tempo
- Escopo controlado: objetos, campos, times, visões e exportações
- Prazo: expiração automática + checklist de desligamento
- Auditoria: trilha de logs e validação pós-acesso
1) Defina o objetivo e o “perímetro” do acesso
Escreva em uma linha o que o terceiro precisa fazer (ex.: “ajustar automação do funil X” ou “importar leads com mapeamento Y”). Em seguida, traduza isso para o CRM: quais módulos/objetos, quais campos, quais pipelines e quais ações (ver, criar, editar, excluir, exportar). O que não entra nessa lista não deve ser liberado.
2) Crie uma identidade separada (usuário dedicado) e evite contas genéricas
Crie um usuário nominal (ou um usuário por pessoa do fornecedor, quando possível) com e-mail corporativo do parceiro. Contas compartilhadas matam a auditoria: quando algo dá errado, ninguém sabe “quem fez”. Se o CRM permitir, identidades individuais também facilitam revogação seletiva.
3) Aplique o menor privilégio com RBAC e exceções explícitas
Use perfis/papéis/grupos para liberar somente o mínimo e, quando precisar de exceções, prefira permissões granulares (por conjunto de permissões, policy, permission set) em vez de elevar o perfil inteiro. Atenção a permissões “invisíveis” que viram porta lateral: exportar, API, acesso a relatórios, e acesso a configurações/automação.
4) Restrinja dados sensíveis por campo, não só por objeto
Mesmo quando o terceiro precisa acessar o objeto (ex.: Contatos), ele quase nunca precisa ver todos os campos. Trate como sensíveis: documentos, dados financeiros, observações internas, campos de compliance/LGPD, e qualquer campo usado para segmentações estratégicas. Onde o CRM não tiver permissão por campo, avalie visões/filters obrigatórios, pipelines separados ou máscaras.
5) Controle “onde” o terceiro enxerga: times, filas, unidades e territórios
Sempre que o CRM suportar, limite o escopo por time, unidade, região, carteira ou fila. Isso reduz o impacto de erro humano (ex.: editar massa no lugar errado) e reduz vazamento interno de informação. Se o trabalho é num projeto específico, crie um time/space de projeto com dados mínimos.
6) Defina prazo e expiração automática (e faça o prazo valer)
Coloque data de término do acesso e combine critérios objetivos para renovação: o que ainda falta, por quê e por quanto tempo. Se o CRM não tiver expiração nativa, use um lembrete de governança (calendário + ticket) e um responsável interno que responde pela revogação.
7) Endureça autenticação: MFA/SSO e regras de sessão
Habilite MFA para esse usuário e, se houver SSO, prefira SSO com políticas da empresa (dispositivo, geolocalização, risco). Ajuste tempo de sessão e restrinja logins simultâneos quando fizer sentido. Acesso temporário sem MFA é o tipo de concessão que vira incidente com facilidade.
8) Delimite integração e API (o ponto que mais dá ruim)
Se o fornecedor precisa de API, crie credenciais separadas das credenciais humanas e limite escopos (scopes), permissões e IPs quando possível. Defina claramente o que pode ser lido/escrito via API. E atenção: tokens persistentes sobrevivem ao “esquecemos de desligar o usuário” se você não revogar também as chaves/tokens.
9) Ative logs e combine um “modo de trabalho” auditável
Garanta que ações relevantes fiquem registradas (alterações de campos, automações, imports/exports, mudanças em regras). Combine que toda alteração significativa terá comentário/registro (ex.: ticket, change log interno, descrição no workflow) para facilitar revisão e rollback.
10) Faça um checklist de desligamento (revogação total) antes de começar
Defina, por escrito, como encerrar o acesso: desativar usuário, remover de grupos, revogar tokens de API, remover chaves de integrações, retirar do SSO, desabilitar webhooks, e revisar automações criadas. O melhor momento para planejar o desligamento é antes de liberar a chave.
O que costuma dar errado quando a empresa “libera só por uma semana”
Acesso temporário costuma virar acesso permanente por esquecimento, não por má intenção. O padrão é: cria-se um usuário, libera-se permissão ampla “para não travar o projeto”, o prazo expira no WhatsApp (não no CRM) e ninguém revoga tokens de integração.
Outro erro recorrente é confundir necessidade operacional com acesso irrestrito a dados: o parceiro precisa ajustar automação, mas recebe permissão de exportar base inteira; precisa mexer em pipeline, mas ganha acesso a configurações globais.
Mapa rápido de permissões: do “seguro” ao “perigoso”
Nem toda permissão tem o mesmo risco. Em governança, vale separar o que impacta dados, o que impacta operação e o que impacta segurança. A tabela abaixo ajuda a priorizar revisões.
| Categoria | Exemplos | Risco típico | Como mitigar |
|---|---|---|---|
| Dados | Exportar, importar, deletar, editar em massa | Vazamento ou perda de base | Bloquear exportação; limitar import; restringir deletar; usar ambiente de teste |
| Operação | Criar/editar automações, regras, filas, roteamentos | Parar o funil/atendimento sem perceber | Permissão só no escopo do projeto; logs; revisão por par |
| Segurança | Gerenciar usuários, permissões, integrações, chaves | Escalada de privilégio; acesso persistente | Separar admin; aprovação; MFA; revogação de tokens |
| Visibilidade | Ver relatórios globais, dashboards executivos | Exposição de estratégia e números internos | Relatórios por time/space; permissões por pasta |
| API/Integrações | Scopes amplos; webhooks para destinos externos | Exfiltração silenciosa de dados | Scopes mínimos; IP allowlist quando existir; revisar destinos |
Uma regra editorial que funciona: acesso de terceiro nunca é “admin” por padrão
Na prática, “admin temporário” é como emprestar a chave mestra do prédio e pedir para a pessoa usar só a sala 302. Pode até dar certo — até o dia em que não dá.
Se o parceiro precisa mexer em configuração, prefira: (1) permissão específica para aquela área do CRM; (2) janela de mudança combinada; (3) supervisão de alguém interno; (4) revisão do que foi alterado. Isso diminui risco sem transformar o projeto num cabo de guerra.
- Evite permissões globais quando o trabalho é local (um pipeline, uma unidade, um time).
- Se o CRM não oferece granularidade suficiente, reduza o escopo por dados (ambiente de teste, base recortada, time/projeto).
- Se algo exige admin, negocie sessões curtas, acompanhadas e registradas (e não “libera aí e me avisa quando terminar”).
Como validar depois: o pós-acesso que quase ninguém faz
Encerrado o trabalho, o mínimo é confirmar três coisas: (1) acesso revogado (usuário e integrações); (2) automações/documentações atualizadas; (3) mudanças revisadas com uma lista do que foi feito.
Esse pós-acesso é o que impede que o CRM vire uma caixa-preta com regras “misteriosas” e permissões herdadas que ninguém lembra por quê existem.
Perguntas frequentes
Posso criar um usuário genérico tipo “[email protected]” para o fornecedor?
Qual é a permissão mais perigosa de liberar sem perceber?
Como conceder acesso sem expor dados pessoais (LGPD) para o fornecedor?
Se eu desativar o usuário do fornecedor, está tudo resolvido?
Leia também
Como configurar permissões e perfis no CRM sem travar o time (e sem virar terra de ninguém)
Guia prático para definir perfis, papéis e permissões no CRM com segurança e fluidez: o que restringir, o que liberar e como auditar sem burocracia.
Ler →
Como auditar permissões no CRM sem parar o time: checklist prático e roteiro em 1 semana
Guia prático para revisar perfis, papéis e acessos no CRM sem travar vendas e atendimento: riscos comuns, checklist, roteiro em 1 semana e perguntas frequentes.
Ler →
SCIM vs provisionamento manual no CRM: quando automatizar usuários e acessos (e quando complica)
Entenda a diferença entre SCIM e provisionamento manual no CRM, com prós, contras, riscos de segurança e uma tabela de decisão para TI, RevOps e Compliance.
Ler →
RBAC vs ABAC no CRM: qual modelo de permissões escolher (sem travar o time)
Entenda a diferença entre RBAC (por função) e ABAC (por atributos) no CRM, com exemplos de vendas/CS, tabela comparativa e um roteiro prático para decidir sem criar burocracia.
Ler →