Acesso de fornecedores à TI: controle e segurança

Acesso de fornecedores à TI é uma das áreas em que empresas costumam criar exceções que permanecem ativas muito além da necessidade original. Um técnico recebe VPN para corrigir um servidor, uma software house ganha usuário administrativo para implantar uma integração, um contador externo entra em um sistema financeiro e um fornecedor de suporte instala uma ferramenta de acesso remoto. O problema surge quando aquilo que deveria durar horas, dias ou um projeto passa a existir indefinidamente sem revisão, expiração e rastreabilidade.

Resposta objetiva: fornecedor não deve ser tratado como “funcionário de fora com acesso permanente”. O modelo mais seguro é criar uma identidade individual e rastreável, exigir autenticação compatível com o risco, liberar somente os sistemas e privilégios necessários, limitar duração, monitorar sessões e revisar periodicamente a necessidade. VPN pode proteger e centralizar o canal remoto, mas não substitui MFA, menor privilégio, segmentação, PIM, Access Reviews, expiração e offboarding. Quanto mais crítico o recurso, menor deve ser a quantidade de privilégio permanente concedido ao terceiro.

A CISA trata relações com terceiros e Managed Service Providers como um vetor que precisa de atenção específica. Em sua orientação contra ransomware, a agência recomenda aplicar menor privilégio e separação de funções ao configurar o acesso de terceiros, restringindo-os aos dispositivos e servidores necessários às responsabilidades contratadas. A orientação também recomenda revisar contas administrativas e de usuários inativos e priorizar a auditoria de acessos concedidos a MSPs. Fonte: CISA - StopRansomware Guide

O NIST segue a mesma direção dentro de Zero Trust. Localização de rede ou propriedade do equipamento não devem gerar confiança implícita. A decisão precisa considerar identidade, recurso, contexto e autorização, aplicando privilégios mínimos ao que realmente precisa ser executado. Em sua implementação prática de Zero Trust, o NIST descreve o princípio de disponibilizar apenas os privilégios necessários no momento em que são necessários e removê-los depois. Fonte: NIST - Implementing a Zero Trust Architecture

Isso muda a maneira de pensar acesso de fornecedor. A pergunta não é apenas “podemos liberar a VPN?”. A empresa precisa responder quem entrará, em qual dispositivo, em quais sistemas, com qual função, durante quanto tempo e como essa atividade será auditada.

Leia mais sobre:
Gestão de acessos e identidades: como controlar quem entra, até onde entra e por quanto tempo

Por que fornecedores representam uma categoria diferente de acesso?

Porque eles estão dentro do processo empresarial sem pertencer integralmente ao ciclo de identidade dos funcionários.

Um colaborador interno costuma possuir:

• admissão formal;
• cargo;
• gestor;
• matrícula;
• equipamento;
• política de segurança;
• processo de desligamento.

Um terceiro pode chegar por uma demanda urgente:

“O fornecedor precisa entrar agora para corrigir o ERP.”

Essa urgência frequentemente cria atalhos.

Exemplos:

• emprestar senha de administrador;
• liberar VPN genérica;
• instalar ferramenta de acesso remoto sem inventário;
• abrir RDP diretamente;
• criar usuário sem data de expiração;
• adicionar convidado a grupo amplo;
• manter conta ativa depois do projeto.

O risco não existe porque o fornecedor é presumidamente mal-intencionado. Existe porque a organização entregou capacidade operacional a uma identidade externa que precisa ser governada.

Fornecedor deve usar conta compartilhada?

Não deveria.

Considere uma conta chamada:

fornecedor.erp

utilizada por quatro técnicos diferentes.

Se uma alteração crítica for feita, a organização consegue provar qual pessoa executou a ação?

Esse modelo prejudica:

• auditoria;
• rastreabilidade;
• revogação individual;
• investigação;
• MFA;
• responsabilização.

Prefira identidades individualizadas.

Exemplos:

• [email protected];
• [email protected];
• usuário convidado B2B;
• conta administrativa nominativa quando tecnicamente necessária.

Conta externa deve pertencer ao fornecedor ou à minha empresa?

Depende da arquitetura.

Em ambientes Microsoft, colaboração B2B permite que pessoas de organizações externas utilizem suas próprias identidades para acessar recursos disponibilizados pelo tenant da empresa.

Isso reduz a necessidade de criar senhas paralelas e permite aplicar políticas ao usuário externo.

O Microsoft Entra permite aplicar Conditional Access a diferentes categorias de usuários convidados e externos, inclusive definindo políticas específicas para determinados tenants parceiros. Fonte: Microsoft Learn - autenticação e Conditional Access para usuários B2B

Entretanto, existem situações técnicas em que uma conta local ou administrativa precisa ser criada. Nesses casos, o ciclo de vida dessa conta precisa ser explicitamente gerenciado pela empresa.

O que é Microsoft Entra B2B?

Microsoft Entra B2B Collaboration permite conceder acesso a pessoas de outras organizações para colaboração em recursos da empresa.

Dependendo da arquitetura, o usuário externo pode acessar:

• Teams;
• SharePoint;
• aplicativos empresariais;
• grupos;
• outros recursos integrados ao Microsoft Entra.

A identidade continua relacionada à organização de origem, enquanto a empresa proprietária do recurso controla aquilo que o convidado pode utilizar.

Isso é diferente de simplesmente compartilhar uma senha.

Guest e fornecedor são a mesma coisa?

Não necessariamente.

“Guest” é uma classificação técnica comum no Microsoft Entra para identidades externas.

Fornecedor é uma relação empresarial.

Um fornecedor pode aparecer como:

• B2B guest;
• B2B member;
• service provider user;
• conta local;
• identidade de aplicação;
• conta administrativa específica.

O importante é que a classificação técnica reflita uma política clara.

Qual é o problema de manter conta externa para sempre?

O relacionamento pode terminar enquanto a identidade continua ativa.

Exemplos:

• contrato encerrado;
• técnico trocou de empresa;
• projeto terminou;
• sistema foi substituído;
• fornecedor deixou de atender aquela unidade;
• acesso emergencial não foi removido.

A Microsoft destaca justamente esse problema na governança de identidades externas: usuários convidados podem permanecer no diretório indefinidamente quando não existe processo de ciclo de vida, mesmo depois de perder a última atribuição relevante. Fonte: Microsoft Learn - governança do ciclo de vida de convidados e parceiros

Como definir o acesso mínimo de um fornecedor?

Comece pela tarefa.

Se o objetivo é atualizar um ERP, pergunte:

• precisa acessar todos os servidores?
• precisa acessar domínio inteiro?
• precisa de administrador global?
• precisa enxergar arquivos?
• precisa entrar no banco de dados?
• precisa alterar firewall?
• precisa manter acesso depois da atualização?

Na maioria dos casos, a resposta para várias dessas perguntas será não.

Menor privilégio significa conceder o mínimo necessário para a função e pelo menor período compatível com o trabalho.

Zero Trust significa não confiar no fornecedor?

Não no sentido pessoal.

Zero Trust significa não conceder confiança técnica implícita apenas porque:

• a empresa tem contrato;
• o técnico já trabalha conosco há anos;
• o IP está autorizado;
• a pessoa está conectada à VPN;
• o notebook pertence ao fornecedor.

O NIST define Zero Trust como uma arquitetura em que não existe confiança automática com base somente em localização de rede ou propriedade do ativo. Autenticação e autorização precisam acontecer antes do acesso aos recursos empresariais. Fonte: NIST - Zero Trust Architecture

VPN resolve o acesso do fornecedor?

Resolve apenas uma parte.

VPN cria um canal protegido e pode centralizar o acesso remoto.

Mas ela não responde sozinha:

• quem é a pessoa;
• se deve continuar com acesso;
• quais sistemas pode utilizar;
• qual nível de privilégio possui;
• se o dispositivo é confiável;
• qual MFA foi realizado;
• quando a permissão deve expirar.

VPN é transporte e controle de entrada. Governança de acesso é mais ampla.

Qual é o risco de uma VPN ampla demais?

Uma configuração inadequada pode entregar conectividade a uma quantidade de recursos muito superior ao necessário.

Um técnico que precisa administrar um servidor específico não deveria automaticamente alcançar:

• financeiro;
• RH;
• outros servidores;
• storage;
• backup;
• controladores de domínio;
• estações de trabalho.

O acesso remoto precisa ser segmentado pelo que efetivamente será administrado.

VPN deve usar MFA?

Sim, principalmente quando representa uma porta de acesso remoto ao ambiente corporativo.

A CISA recomenda MFA em conexões VPN e reforça autenticação multifator em acessos remotos como medida importante contra comprometimento de contas. Fonte: CISA - práticas para proteger acessos remotos

Quando possível, acessos críticos podem ainda justificar métodos resistentes a phishing, dependendo da plataforma e do risco.

MFA por SMS é suficiente para fornecedores?

É melhor que senha isolada, mas não representa o nível máximo de proteção.

Se o acesso permite:

• administrar Microsoft 365;
• alterar firewall;
• controlar servidores;
• acessar backup;
• modificar identidade;
• operar sistemas financeiros;

métodos resistentes a phishing merecem avaliação.

Microsoft Entra Conditional Access permite exigir diferentes forças de autenticação para usuários externos que utilizam Microsoft Entra ID. A organização pode, inclusive, exigir uma força resistente a phishing para aplicações sensíveis em cenários compatíveis. Fonte: Microsoft Learn - força de autenticação para usuários externos

Aprofunde neste conteúdo:
MFA resistente a phishing: como elevar a proteção de acessos críticos

Posso confiar no MFA realizado pela empresa do fornecedor?

Em determinados cenários Microsoft Entra entre organizações, sim.

Configurações de acesso entre locatários podem permitir que o tenant que hospeda o recurso confie em determinadas declarações, como MFA realizado no tenant de origem.

Isso pode reduzir atrito operacional.

Mas confiança entre tenants precisa ser configurada deliberadamente.

A empresa deve avaliar:

• qual organização é confiável;
• quais declarações serão aceitas;
• quais usuários externos entram no escopo;
• quais aplicações são sensíveis;
• qual força de autenticação será exigida.

O fornecedor precisa entrar pela rede inteira?

Não.

Quanto mais segmentado for o acesso, menor tende a ser a superfície disponível após uma credencial comprometida.

Uma organização pode utilizar diferentes abordagens:

• VPN segmentada;
• jump server;
• bastion host;
• VDI;
• acesso por aplicativo;
• Zero Trust Network Access;
• redes administrativas específicas.

O desenho depende da infraestrutura.

A CISA recomenda que soluções de RMM autorizadas sejam utilizadas através de mecanismos de acesso remoto aprovados, como VPN ou interfaces de desktop virtual, em vez de deixar ferramentas e portas indiscriminadamente expostas. Fonte: CISA - controle de RMM e acesso de terceiros

O que é RMM e por que merece atenção?

RMM significa Remote Monitoring and Management.

São ferramentas utilizadas por equipes de TI e MSPs para:

• acessar computadores;
• executar comandos;
• instalar software;
• monitorar dispositivos;
• administrar endpoints.

Essas capacidades são extremamente úteis.

Também são poderosas.

Quando uma conta de RMM é comprometida, o invasor pode herdar uma capacidade de administração remota legítima.

Qual é o problema de instalar várias ferramentas remotas?

Cada ferramenta cria uma nova superfície operacional.

Uma empresa pode descobrir que possui simultaneamente:

• AnyDesk;
• TeamViewer;
• RMM do MSP;
• RDP;
• VPN;
• ferramenta do ERP;
• agente do fabricante.

Se ninguém sabe quais são autorizadas, retirar acesso de um fornecedor deixa de ser simples.

A CISA recomenda auditar ferramentas remotas presentes no ambiente e identificar quais soluções RMM são realmente autorizadas. Fonte: CISA - auditoria de ferramentas de acesso remoto

O que é acesso just-in-time?

Just-in-time significa disponibilizar o privilégio no momento da necessidade, em vez de mantê-lo ativo permanentemente.

Um fornecedor pode ser elegível a uma função, mas não possuir o privilégio ativo 24 horas por dia.

Quando precisa executar uma atividade:

• solicita ativação;
• realiza MFA;
• informa justificativa;
• recebe aprovação quando exigida;
• utiliza a função por um período limitado;
• perde o privilégio ao final da janela.

Como Microsoft Entra PIM ajuda?

Privileged Identity Management permite administrar funções privilegiadas com controles baseados em tempo e aprovação.

A Microsoft destaca como capacidades do PIM:

• acesso privilegiado just-in-time;
• elegibilidade em vez de privilégio permanente;
• ativação por tempo limitado;
• MFA;
• justificativa;
• aprovação;
• notificações;
• auditoria;
• revisões.

Fonte: Microsoft Learn - planejamento do Privileged Identity Management

Veja também:
PIM no Microsoft Entra: como reduzir privilégios administrativos permanentes

Todo fornecedor precisa de PIM?

Não.

PIM é especialmente relevante quando existe acesso privilegiado a recursos compatíveis.

Um designer externo que acessa uma pasta do SharePoint não precisa necessariamente de privilégio administrativo.

Um fornecedor que administra:

• tenant Microsoft 365;
• Azure;
• grupos privilegiados;
• segurança;
• Intune;

pode justificar controles mais fortes.

Como lidar com fornecedor que precisa de Global Administrator?

Primeiro, confirme se ele realmente precisa.

Muitas tarefas administrativas podem ser executadas através de funções mais específicas.

Global Administrator é uma das funções mais poderosas do tenant e deve ser tratada como exceção.

Prefira:

• função específica;
• elegibilidade;
• ativação temporária;
• MFA forte;
• aprovação quando adequada;
• logs;
• revisão periódica.

O princípio é conceder a função mínima capaz de executar a tarefa.

Como controlar acesso a SharePoint e Teams por fornecedores?

Não basta convidar e esquecer.

A empresa precisa definir:

• quem pode convidar terceiros;
• quais sites permitem compartilhamento;
• quais Teams aceitam convidados;
• quem é o owner;
• qual informação está envolvida;
• quando o acesso expira;
• quem revisará a permanência.

Esse é um dos cenários em que Access Reviews e Entitlement Management ganham relevância.

O que são Access Reviews?

Access Reviews permitem revisar periodicamente se usuários continuam precisando do acesso concedido.

Em vez de perguntar uma vez na entrada e nunca mais revisar, a organização pode executar uma recertificação.

Para convidados, o Microsoft Entra permite que:

• owner revise;
• gestor revise;
• outro responsável revise;
• o próprio convidado confirme em determinados cenários.

Ao final, acessos que não são mais necessários podem ser removidos conforme a configuração. Fonte: Microsoft Learn - Access Reviews para convidados

Com que frequência revisar terceiros?

Depende da criticidade e duração do relacionamento.

Projetos de curto prazo podem utilizar expiração definida.

Contratos longos podem utilizar revisão recorrente.

A orientação da Microsoft para acesso externo através de Entitlement Management recomenda utilizar expiração e revisões regulares; para pacotes externos, a própria documentação cita revisões trimestrais ou mais frequentes conforme o risco do recurso. Fonte: Microsoft Learn - governança de acesso externo com Entitlement Management

O que é Entitlement Management?

É uma capacidade do Microsoft Entra ID Governance que organiza acesso por pacotes.

Em vez de conceder manualmente:

• grupo A;
• aplicativo B;
• SharePoint C;
• Teams D;

a empresa pode construir um pacote de acesso que represente uma função ou relacionamento.

Exemplo:

Fornecedor de implantação ERP

com:

• aplicativo específico;
• grupo do projeto;
• site SharePoint;
• prazo;
• aprovação;
• revisão.

Aprofunde neste conteúdo:
Entitlement Management no Microsoft Entra: como organizar acesso com aprovação, expiração e ciclo de vida

Acesso deve expirar automaticamente?

Sempre que o processo permitir, expiração automática reduz dependência de memória.

Uma regra pode ser:

• 7 dias;
• 30 dias;
• 90 dias;
• até o fim do projeto;
• até data contratual.

Renovação pode exigir nova aprovação.

Esse modelo é superior a criar conta sem prazo e esperar que alguém lembre de removê-la.

Fornecedor precisa de horário limitado?

Pode ser apropriado.

Um suporte contratado para trabalhar em uma janela específica pode não precisar de acesso administrativo durante toda a madrugada, fins de semana e feriados.

Dependendo da tecnologia, controles podem considerar:

• ativação temporária;
• janela de manutenção;
• sessões;
• restrições condicionais;
• processo formal fora do horário.

O objetivo é reduzir a janela em que uma credencial comprometida teria utilidade.

Posso restringir por IP?

Pode ser uma camada adicional.

Mas não trate IP permitido como prova completa de confiança.

Endereços mudam, redes podem ser comprometidas e usuários podem trabalhar remotamente.

O NIST enfatiza que Zero Trust não concede confiança com base apenas em localização de rede. Fonte: NIST - Zero Trust Architecture

Combine contexto de rede com identidade e autenticação.

Fornecedor pode usar computador pessoal?

Isso precisa ser definido pela política.

Um dispositivo pessoal ou não gerenciado pode trazer riscos como:

• malware;
• sistema desatualizado;
• outros usuários no mesmo equipamento;
• armazenamento local;
• falta de criptografia;
• ferramentas desconhecidas;
• ausência de controles corporativos.

Para acessos críticos, pode ser preferível exigir:

• dispositivo gerenciado;
• VDI;
• jump host;
• bastion;
• equipamento fornecido;
• controle de compliance quando tecnicamente possível.

O que precisa ser registrado nos logs?

O nível de logging depende do sistema, mas a empresa deveria conseguir investigar perguntas como:

• quem entrou;
• quando entrou;
• de onde;
• qual autenticação realizou;
• qual privilégio ativou;
• qual recurso acessou;
• qual ação crítica executou;
• quando a sessão terminou.

A CISA recomenda monitoramento de logs associados ao uso de ferramentas remotas e acessos de terceiros. Fonte: CISA - monitoramento de acesso remoto

Preciso gravar a sessão do fornecedor?

Depende da criticidade, tecnologia, contrato e requisitos aplicáveis.

Para alguns ambientes administrativos, gravação de sessão ou trilhas detalhadas podem ser justificadas.

Em outros casos, logs de autenticação, atividade e comandos podem ser suficientes.

A decisão deve considerar:

• sensibilidade do ambiente;
• privacidade;
• requisitos contratuais;
• investigação;
• compliance;
• custo operacional.

O contrato com o fornecedor deve mencionar segurança?

Sim.

A relação técnica deveria estar alinhada à relação contratual.

Podem ser considerados itens como:

• quem pode acessar;
• como serão criadas identidades;
• MFA obrigatório;
• uso de ferramentas remotas autorizadas;
• tratamento de dados;
• responsabilidade sobre credenciais;
• notificação de incidentes;
• subcontratados;
• devolução ou destruição de dados;
• revogação de acessos;
• requisitos no encerramento.

A CISA recomenda formalizar requisitos de segurança em contratos com terceiros e MSPs, principalmente quando esses fornecedores participam da proteção de ativos críticos como backups. Fonte: CISA - segurança de terceiros e MSPs

Quem deve aprovar acesso de fornecedor?

Não apenas TI.

Dependendo do recurso, pode existir:

• owner técnico;
• owner de negócio;
• segurança;
• gestor do contrato;
• aprovador do sistema.

Exemplo:

TI pode confirmar que o acesso é tecnicamente seguro, mas o gestor financeiro precisa decidir se determinado fornecedor realmente deve enxergar um sistema financeiro.

Como deve funcionar o onboarding de um fornecedor?

Um processo simples pode registrar:

• empresa;
• nome do profissional;
• responsável interno;
• contrato ou projeto;
• recursos necessários;
• nível de privilégio;
• método de autenticação;
• dispositivo;
• data inicial;
• data final;
• ferramenta de acesso;
• aprovação.

Depois da criação, a pessoa recebe apenas aquilo que foi aprovado.

Como deve funcionar o offboarding?

Offboarding precisa ser técnico e administrativo.

Revise:

• conta;
• VPN;
• grupos;
• Microsoft 365;
• SharePoint;
• Teams;
• aplicações;
• PIM;
• Azure;
• RMM;
• certificados;
• tokens;
• API keys;
• chaves SSH;
• senhas de serviço;
• sessões.

Encerrar contrato sem revogar tecnicamente os meios de acesso não encerra o risco.

O que fazer quando o técnico do fornecedor muda?

Revogue a pessoa antiga e aprove a nova.

Não transfira a mesma conta.

A relação comercial pode permanecer a mesma, mas a identidade humana mudou.

Esse é outro motivo para evitar usuários compartilhados.

Como lidar com subcontratados?

O contrato e a política devem definir se o fornecedor pode repassar acesso.

A empresa precisa saber qual pessoa final realmente acessa seus sistemas.

“Prestador do prestador” não deveria ser uma identidade invisível.

Considere:

• aprovação prévia;
• identificação individual;
• mesmos requisitos de MFA;
• mesma expiração;
• mesmos logs;
• mesma governança.

Como medir maturidade do acesso de fornecedores?

Análise técnica - Eduardo Neto

Acesso de fornecedor não deveria começar perguntando qual VPN será usada. Primeiro precisamos saber qual trabalho essa pessoa realmente precisa executar. Quando começamos pela ferramenta, normalmente liberamos uma rede inteira para resolver uma tarefa pequena. Quando começamos pelo processo, conseguimos definir identidade, sistema, privilégio, duração e evidência. A VPN pode continuar fazendo parte da arquitetura, mas passa a ser apenas um dos controles e não a autorização inteira.

 

O segundo ponto é tempo. Uma das maiores diferenças entre funcionário e fornecedor é que o acesso externo quase sempre nasce associado a projeto, contrato, chamado ou manutenção. Isso deveria gerar uma data de validade natural. Microsoft Entra B2B, Conditional Access, PIM, Entitlement Management e Access Reviews permitem transformar esse princípio em governança técnica. A empresa deixa de depender da memória de alguém para remover o acesso e passa a trabalhar com identidade individual, MFA, privilégio mínimo, expiração, revisão e trilha de auditoria.

 

- Eduardo Neto, CEO Cintra IT

Como montar uma política de acesso de terceiros?

A política pode ser objetiva.

Identidade

Toda pessoa externa precisa utilizar conta individual e identificável.

Autenticação

MFA deve ser exigida nos acessos remotos e sensíveis, com método proporcional ao impacto.

Escopo

O terceiro acessa somente recursos relacionados à atividade contratada.

Privilégio

Administração permanente é evitada quando existe possibilidade de ativação temporária.

Tempo

Todo acesso precisa de prazo, revisão ou evento formal de encerramento.

Dispositivo

A organização define quais endpoints podem ser utilizados para cada categoria de acesso.

Canal remoto

VPN, VDI, bastion ou RMM devem estar explicitamente autorizados.

Logs

Ações relevantes precisam deixar evidência suficiente para investigação.

Offboarding

Contrato encerrado precisa gerar retirada técnica dos acessos.

Casos de Sucesso - Cintra IT

Os exemplos abaixo são cenários ilustrativos, baseados em situações recorrentes de acesso remoto, Microsoft Entra, VPN, PIM e gestão de fornecedores. Não representam promessa de resultado, cliente real identificado ou garantia de desempenho. A proposta é mostrar como o controle de terceiros pode ser estruturado de forma prática.

Checklist final para controlar acesso de fornecedores à TI

• Identidade individual: elimine contas compartilhadas sempre que tecnicamente possível;
• MFA obrigatório: proteja VPN, cloud, RMM e demais acessos remotos compatíveis;
• Menor privilégio: forneça somente os recursos e funções necessários para a atividade;
• Prazo definido: todo acesso externo precisa de expiração, revisão ou data de encerramento;
• Privilégio temporário: utilize just-in-time e PIM para funções administrativas compatíveis;
• Segmentação: evite conceder visibilidade de rede maior que a necessária;
• RMM autorizado: inventarie e controle ferramentas de administração remota;
• Logs e auditoria: mantenha rastreabilidade de autenticações, ativações e ações relevantes;
• Revisões recorrentes: recertifique acessos de parceiros e convidados de longa duração;
• Offboarding formal: remova contas, VPN, grupos, tokens, certificados, chaves e ferramentas ao fim do relacionamento.

Perguntas frequentes sobre acesso de fornecedores à TI

Como controlar o acesso de fornecedores à TI?

O controle deve combinar identidade individual, MFA, menor privilégio, acesso temporário, segmentação, logs, revisão periódica e desligamento automático ou formal ao fim da necessidade. VPN pode fazer parte da arquitetura, mas não substitui esses controles.

Fornecedor deve usar uma conta compartilhada?

Não é recomendável. O ideal é que cada profissional utilize uma identidade individual e rastreável. Contas compartilhadas dificultam auditoria, responsabilização, revogação e investigação de ações realizadas no ambiente.

VPN é suficiente para proteger o acesso de terceiros?

Não. VPN protege o canal e pode centralizar o acesso remoto, mas não define sozinha quem deve entrar, quais recursos poderá acessar, por quanto tempo, com qual autenticação e com qual privilégio. Ela precisa trabalhar com identidade, MFA, autorização, segmentação e monitoramento.

Fornecedores externos precisam usar MFA?

Sim, especialmente em acessos remotos, administrativos e sensíveis. A Microsoft permite aplicar Conditional Access e forças de autenticação a convidados e usuários externos, enquanto a CISA recomenda MFA para acessos remotos e contas de terceiros.

O que é acesso just-in-time para fornecedores?

É um modelo no qual o privilégio não permanece ativo permanentemente. O fornecedor recebe elegibilidade ou autorização para ativar determinado acesso apenas quando necessário, por tempo limitado e, conforme a política, mediante MFA, justificativa ou aprovação.

Como remover acessos quando um contrato termina?

A organização deve possuir um processo formal de offboarding que revogue contas, sessões, VPN, grupos, aplicativos, funções privilegiadas, chaves, certificados e integrações. Recursos como Access Reviews e Entitlement Management podem ajudar a automatizar expiração e revisão de usuários externos.

Microsoft Entra B2B serve para fornecedores?

Sim, em muitos cenários de colaboração. Ele permite que usuários externos sejam convidados para acessar recursos da organização utilizando identidades externas controladas por políticas do tenant que hospeda o recurso.

Um fornecedor precisa ter administrador global?

Na maioria dos casos, não. A organização deve identificar a função mínima necessária. Quando um privilégio elevado for realmente indispensável, pode ser apropriado utilizar elegibilidade e ativação temporária através de PIM em vez de manter administração permanente.

Como controlar acesso remoto por AnyDesk, TeamViewer ou RMM?

A empresa deve inventariar quais ferramentas são autorizadas, restringir instalações não aprovadas, exigir identidade e autenticação adequadas, acompanhar logs e retirar agentes ou credenciais quando o relacionamento termina. Ferramentas remotas não devem permanecer invisíveis à governança de TI.

Preciso revisar fornecedores mesmo com contrato ativo?

Sim. Um contrato ativo não prova que todas as permissões originalmente concedidas ainda são necessárias. Projetos mudam, técnicos são substituídos e escopos diminuem. Revisões periódicas ajudam a confirmar se o acesso continua compatível com a atividade atual.

Conclusão - acesso de fornecedor precisa terminar quando a necessidade termina

Acesso de fornecedores à TI precisa ser tratado como ciclo de vida e não como uma configuração isolada de VPN. O terceiro entra para executar uma finalidade específica e a autorização deve refletir exatamente essa finalidade, sem transformar conveniência operacional em privilégio permanente.

Identidade individual é o primeiro passo. Quando diferentes técnicos utilizam a mesma conta, a empresa perde capacidade de atribuir ações, revogar somente uma pessoa e investigar incidentes. Em ambientes Microsoft, B2B e External ID podem ajudar a estruturar colaboração externa sem depender de credenciais compartilhadas.

MFA é outra camada indispensável, especialmente em acessos remotos. Porém, autenticação forte não corrige autorização excessiva. Um terceiro perfeitamente autenticado ainda pode possuir permissão maior do que deveria. É por isso que MFA precisa trabalhar com menor privilégio, segmentação e políticas de acesso.

PIM leva essa lógica um estágio adiante para atividades privilegiadas. Se uma função administrativa só é necessária durante uma manutenção, mantê-la ativa durante o mês inteiro cria exposição sem benefício operacional. Just-in-time transforma privilégio em evento temporário e auditável.

Access Reviews e Entitlement Management resolvem outra fragilidade recorrente: permanência. Projetos terminam, técnicos mudam e contratos são encerrados. A governança precisa acompanhar esse movimento para que convidados, grupos e aplicativos não acumulem acessos antigos ao longo dos anos.

Por fim, ferramentas de RMM e suporte remoto precisam entrar no inventário de segurança. Encerrar uma conta VPN e esquecer agentes remotos instalados nos computadores não representa offboarding completo. A empresa precisa conhecer todos os caminhos pelos quais terceiros conseguem administrar seus ativos.

Na visão da Cintra IT, o acesso externo mais seguro não é aquele que impede o fornecedor de trabalhar. É aquele que permite exatamente o trabalho contratado, durante o período necessário, com identidade, autenticação, privilégio e rastreabilidade proporcionais ao risco. A Solução em TI pode integrar Microsoft Entra, VPN, PIM, Conditional Access, ferramentas remotas e processos de governança para estruturar esse controle sem transformar suporte em burocracia.

Como a Cintra IT pode apoiar sua empresa?

A Cintra IT pode apoiar empresas que utilizam fornecedores externos, MSPs, software houses, consultorias ou técnicos com acesso a Microsoft 365, servidores, redes e sistemas críticos. O trabalho pode começar por um inventário dos acessos existentes para identificar contas permanentes, convidados antigos, VPNs, ferramentas de RMM e privilégios que já não correspondem à necessidade atual.

Acesso de terceiros dentro da Solução em TI

• Inventário de contas de fornecedores e terceiros;
• Revisão de usuários convidados no Microsoft Entra;
• Auditoria de VPNs e ferramentas de acesso remoto;
• Revisão de MFA em acessos externos;
• Análise de funções administrativas permanentes;
• Planejamento de Microsoft Entra PIM;
• Planejamento de Conditional Access para convidados;
• Estruturação de Access Reviews;
• Avaliação de Entitlement Management;
• Organização de onboarding e offboarding de fornecedores.

Integração entre fornecedores, identidade, privilégio e rede

• Substituir contas compartilhadas por identidades rastreáveis;
• Limitar acesso ao menor conjunto necessário de recursos;
• Separar conectividade VPN de autorização aos sistemas;
• Aplicar autenticação proporcional à criticidade;
• Reduzir privilégios administrativos permanentes;
• Estruturar ativações just-in-time quando aplicável;
• Inventariar ferramentas de RMM e suporte remoto;
• Centralizar logs relevantes para investigação;
• Definir expiração e revisões recorrentes;
• Retirar tecnicamente o acesso quando contrato, projeto ou necessidade terminam.