Quero implantar gestão de identidade e SSO

Centralizar identidade em provedor único (Azure AD, Google, Okta) — SSO, MFA, ciclo de vida de conta, governança de acesso, migração de aplicações.

Resposta rápida

Centralizar identidade não começa por ferramenta — começa por inventário. Liste todas as aplicações em uso (cloud, on-premises, internas, terceiras), todos os usuários ativos (colaboradores, contratados, parceiros, contas de serviço) e como cada aplicação autentica hoje. Escolha o provedor de identidade dominante com base em ecossistema da empresa (Microsoft, Google ou plataforma neutra como Okta). Implante em ondas: primeiro MFA em tudo que importa, depois SSO nas aplicações compatíveis, depois ciclo de vida automatizado (admissão, mudança de cargo, desligamento) e por último governança de acesso (revisão periódica, perfis, segregação). Não tente migrar tudo de uma vez — aplicação legada sem suporte a SSO precisa estratégia própria e pode ficar para o fim.

Pequena até 50 colaboradores

Na empresa pequena, gestão de identidade cabe em escolher um provedor (Microsoft 365 ou Google Workspace, na maioria das vezes) e usar o que ele já oferece: SSO nativo para as principais aplicações SaaS, MFA obrigatório, conta única por pessoa. Não compre Okta ou solução corporativa — não há volume nem aplicação que justifique. Foco em três disciplinas: MFA em tudo (e-mail, ERP, bancos), conta criada e revogada quando alguém entra ou sai, e revisão semestral de quem tem acesso a quê. Operação é leve, normalmente conduzida pelo MSP com aprovação do dono ou RH. O risco maior é deixar contas órfãs ativas após desligamento — política simples com checklist resolve.

Média 51–500 colaboradores

Na empresa média, gestão de identidade vira projeto formal. Volume de usuários, aplicações e contratados torna a operação manual cara e arriscada. Implante provedor de identidade dominante (Azure AD/Entra ID, Google ou Okta), SSO nas aplicações principais (esperar cobertura de 60-80% das aplicações SaaS no primeiro ano), MFA universal, e processo automatizado de provisionamento via integração com o RH. Defina perfis de acesso por papel, e revisão trimestral de acessos privilegiados. O risco maior é ignorar aplicações legadas que não suportam SSO moderno: precisam estratégia específica (proxy, gateway de identidade, migração ou mitigação). Não force solução única para tudo.

Grande +500 colaboradores

Na empresa grande, gestão de identidade é programa formal com áreas dedicadas (IAM — Identity and Access Management). Provedor de identidade central federado, SSO em todas as aplicações modernas, MFA com fator forte para acessos privilegiados, PAM (Privileged Access Management) para contas de administração, ciclo de vida totalmente automatizado integrado a RH, e governança formal de acesso com certificação periódica por gestor. Frameworks como ISO 27001 e NIST entram como referência. Atenda exigências de auditoria, compliance e regulador. O risco maior é programa que entrega muito controle e pouca usabilidade — usuário cria caminho paralelo e a segurança real cai. Equilibrar segurança e fricção é o desafio central.

Você está vivendo isso se…
  • Cada sistema tem seu próprio login e os usuários reciclam senha
  • Pessoas desligadas continuam com acesso ativo em sistemas críticos
  • Não há clareza de quem tem acesso a quê, nem por quê
  • MFA é parcial ou inexistente nas aplicações mais sensíveis
  • Onboarding técnico de novo colaborador leva dias entre criação de contas
  • Auditoria, cliente ou seguro começou a pedir evidência de gestão de acesso

Inventário antes de ferramenta

Antes de escolher provedor de identidade, faça o inventário. Aplicações em uso: cloud, on-premises, internas, terceiras, com classificação de criticidade. Usuários ativos: colaboradores, contratados, parceiros, contas de serviço, com fonte autoritativa (RH para colaboradores, contrato para terceiros). Métodos de autenticação atuais: cada aplicação tem como login? Senha local? Active Directory? Federação? Esse mapa revela tamanho do projeto, dependências e onde está o trabalho mais difícil — quase sempre aplicações legadas sem suporte a SSO moderno.

Escolha do provedor de identidade

O provedor de identidade é a fundação. Três caminhos dominam o mercado. Microsoft Entra ID (antigo Azure AD) é natural quando a empresa já vive em Microsoft 365 e Windows. Google Cloud Identity é natural quando o ecossistema é Google Workspace. Okta (ou outras plataformas neutras) é natural quando a empresa tem multi-ecossistema, exige federação ampla e tem complexidade que provedor único de cloud não cobre tão bem. A decisão depende menos de comparação técnica entre os três (todos são maduros) e mais de ecossistema atual, perfil de aplicações e custo total. Para a maioria das empresas, a escolha já está praticamente feita pelo ecossistema dominante.

SSO, MFA, ciclo de vida e governança — quatro disciplinas

Gestão de identidade madura cobre quatro disciplinas. SSO (Single Sign-On) reduz fricção e centraliza controle: uma identidade, vários sistemas. MFA (autenticação multifator) torna senha comprometida menos perigosa — fator obrigatório para qualquer acesso minimamente sensível. Ciclo de vida da conta: criação automática no onboarding com perfil correto, ajuste em mudança de cargo, revogação imediata no desligamento. Governança de acesso: revisão periódica por gestor, perfis padronizados, segregação de funções, atenção especial a contas privilegiadas e contas de serviço.

Implantação em quatro ondas
  1. Onda 1: MFA universal. Antes de qualquer migração de aplicação, ativar MFA em todos os sistemas que suportam, com foco em e-mail, ERP, bancos e administração de TI.
  2. Onda 2: SSO nas aplicações compatíveis. Integrar as aplicações SaaS e on-premises modernas ao provedor de identidade. Esperar cobertura crescente onda a onda.
  3. Onda 3: ciclo de vida automatizado. Integração com RH para criar, ajustar e revogar contas automaticamente, com perfis por papel.
  4. Onda 4: governança de acesso. Revisão periódica por gestor, PAM para contas privilegiadas, segregação de funções, relatórios de auditoria.
Atenção comum: aplicações legadas sem suporte a SSO moderno (SAML, OIDC) são quase sempre o que sobra para o fim do projeto. Para essas, três caminhos. Substituir por alternativa moderna se houver. Usar gateway de identidade ou proxy de aplicação para encaixar à força. Manter com mitigação (senha forte, MFA local, segregação de rede) enquanto a substituição não acontece. Não força solução elegante onde não cabe.

Contas privilegiadas e de serviço pedem atenção extra

Contas privilegiadas (administradores de sistema, root, contas com poder amplo) e contas de serviço (usadas por sistemas para integração) são as mais perigosas em incidente de segurança e as mais negligenciadas em gestão. Trate separado: PAM (Privileged Access Management) para contas privilegiadas, com cofre de senhas, sessões gravadas, MFA forte e revisão constante. Para contas de serviço, inventário obrigatório (cada conta com dono, propósito e prazo de revisão), senhas rotacionadas e privilégios mínimos. Boa parte de incidente grave começa em conta privilegiada esquecida ou conta de serviço com poder demais.

Armadilhas comuns na implantação de IAM

Comprar Okta sem precisar. Empresa pequena com Microsoft 365 já tem boa parte do necessário. Adicionar plataforma de identidade extra duplica custo e governança sem ganho proporcional.

SSO sem MFA. SSO concentra acesso, e isso multiplica o estrago se uma senha vaza. MFA é pré-requisito, não complemento.

Esquecer aplicações legadas. Forçar SSO em aplicação sem suporte gera atraso e frustração. Trate como categoria à parte, com estratégia específica.

Ciclo de vida manual. Criação e revogação de conta via ticket leva a contas órfãs e onboarding lento. Integração com RH é o que torna o programa sustentável.

Governança que vira controle de teatro. Revisão de acesso aprovada em bloco por gestor sem entender o que aprova não reduz risco. Foque em qualidade da revisão, não em volume aprovado.

Antes de declarar IAM em operação, confira:
  • Inventário de aplicações, usuários e métodos de autenticação atualizado
  • Provedor de identidade central escolhido com justificativa de ecossistema
  • MFA ativo em todos os sistemas críticos
  • SSO operando em cobertura crescente das aplicações compatíveis
  • Ciclo de vida da conta integrado a fonte autoritativa (RH ou contrato)
  • Estratégia explícita para aplicações legadas sem suporte a SSO
  • Governança de contas privilegiadas (PAM) e contas de serviço
  • Processo de revisão periódica de acessos com gestor

O que é gestão de identidade e por que importa?

Gestão de identidade (IAM — Identity and Access Management) é a disciplina que controla quem tem acesso a quê e em que condições. Cobre quatro frentes: SSO para reduzir fricção e centralizar controle, MFA para reduzir risco de senha comprometida, ciclo de vida automatizado da conta (admissão, mudança, desligamento) e governança de acesso (revisão periódica, perfis, segregação). Importa porque reduz risco de incidente, agiliza onboarding, simplifica auditoria e prepara a empresa para crescimento sem caos de senha.

Qual provedor de identidade escolher: Microsoft, Google ou Okta?

A decisão depende menos de comparação técnica (todos são maduros) e mais de ecossistema da empresa. Microsoft Entra ID é natural quando a empresa vive em Microsoft 365 e Windows. Google Cloud Identity é natural com Google Workspace. Okta (ou plataformas neutras) faz sentido em empresa multi-ecossistema, com federação ampla e complexidade que provedor único de cloud não cobre. Para a maioria, a escolha já está praticamente feita pelo ecossistema dominante. Pagar por plataforma extra sem necessidade duplica custo.

Por onde começar a implantar SSO e MFA?

Comece por MFA universal antes de qualquer migração de aplicação. Ative MFA em todos os sistemas que suportam, com foco em e-mail, ERP, bancos e administração de TI. Em paralelo, integre as aplicações SaaS e on-premises modernas ao provedor de identidade, expandindo cobertura de SSO onda a onda. Não tente migrar tudo de uma vez — aplicação legada sem suporte a SSO precisa de estratégia específica e pode ficar para o fim do projeto. Sem MFA, SSO concentra acesso e multiplica risco.

Como lidar com aplicações antigas que não suportam SSO?

Três caminhos. Substituir por alternativa moderna se houver solução de mercado equivalente. Usar gateway de identidade ou proxy de aplicação para encaixar à força a aplicação ao provedor central — solução técnica que muitas plataformas oferecem. Manter com mitigação (senha forte, MFA local na aplicação se possível, segregação de rede, monitoramento extra) enquanto a substituição não acontece. Não force solução elegante onde não cabe; trate legado como categoria à parte com estratégia explícita.

O que fazer com contas privilegiadas e de serviço?

Tratá-las separado. Para contas privilegiadas (administradores, root), use PAM (Privileged Access Management) com cofre de senha, sessões gravadas, MFA forte e revisão constante. Para contas de serviço (usadas por sistemas em integração), mantenha inventário obrigatório com dono, propósito e prazo de revisão, rotacione senhas, aplique privilégio mínimo. Boa parte de incidente grave começa em conta privilegiada esquecida ou conta de serviço com poder demais — esses dois tipos pedem atenção desproporcional à quantidade.