Existe uma pergunta que todo administrador de TI eventualmente para de fazer em voz alta porque aceitou que ela não tem uma resposta simples.
“Por que sei tudo sobre este aparelho — e quase nada sobre quem está realmente sentado na frente dele neste momento?”
Você tem informações sobre o status de patches, conformidade, inventário de aplicativos e localização. Você pode apagar tudo remotamente às 2h da manhã pelo seu celular. Mas e a pessoa que fizer login às 9h? Isso ainda depende basicamente de um acordo informal e uma senha que provavelmente foi reutilizada de outras três contas.
Essa lacuna é o motivo da existência do OneIdP. E, dois anos depois, aqui está a história sincera do que foi necessário para preenchê-la.
O mundo em que as equipes de TI realmente viviam.
A resposta convencional já estava bem estabelecida: comprar uma ferramenta IAM, integrá-la ao seu UEM e configurar o SSO em algum ponto intermediário.
Fornecedores diferentes, painéis de controle diferentes e locais diferentes para que sua política se contradiga silenciosamente no momento em que um caso atípico aparecer.
O problema mais profundo era que Fusão de escamas Os ambientes de TI corporativos reconhecidos não são construídos em torno de cenários ideais — são construídos em torno de exceções. Dispositivos compartilhados, integração remota, contratados usando laptops pessoais e equipes distribuídas em cinco fusos horários diferentes são apenas alguns exemplos.
Esses não eram casos extremos a serem contornados. Eram as condições reais de operação.
No entanto, a maioria das estratégias de acesso ainda era escrita para um mundo onde todos compareciam ao mesmo escritório, usando o mesmo dispositivo gerenciado, todos os dias. Assim, a autenticação tornou-se um mero instrumento para tudo. A autenticação era tratada como um problema resolvido. Verificar a senha, conceder a sessão. Pronto.
A maioria das decisões de acesso ainda era tomada com base apenas em parte das informações. Isso porque saber quem é a pessoa não revela quase nada sobre o dispositivo que ela está usando para acessar. Se o dispositivo foi atualizado. Se pertence à organização. Se é a máquina cadastrada no trimestre anterior ou um laptop pessoal no saguão de um hotel.
Essa era a lacuna que nos propusemos a preencher.
O que enviamos no primeiro dia — e por que isso foi apenas o começo.
Quando lançamos o OneIdP, fizemos uma escolha deliberada que a maioria das equipes de produto não faz. Entregamos uma base sólida em vez de uma lista de funcionalidades.
Um diretório na nuvem. Acesso condicional por meio de cartão de acesso. Autenticação multifator (MFA) integrada ao mesmo painel de controle que as equipes de TI já utilizavam diariamente. A base foi deliberadamente construída de forma sólida antes de receber recursos adicionais.
keycard Permite que as equipes de TI definam condições de acesso reais — locais aprovados, intervalos de IP confiáveis, redes Wi-Fi específicas e janelas de tempo. Para equipes que trabalham com senhas compartilhadas e logins sem contexto, mesmo essa primeira versão representava uma forma diferente de trabalho.
Terreno firme, antes de começarmos a construir.
E então algo aconteceu que nos mostrou que a base havia de fato se consolidado. E em poucos meses, os clientes não estavam mais perguntando se o OneIdP funcionava. Eles já estavam pensando no que viria a seguir.
- Como integrar a configuração existente do Okta ou Entra ao processo.
- Como tomar decisões de acesso que reflitam a conformidade do dispositivo, e não apenas a identidade.
- Como fazer funcionar para equipes em turnos que compartilham máquinas durante um dia inteiro de trabalho.
Esse era o mapa, e nós o seguimos.
Dois anos construindo essa realidade.
A maioria das ferramentas de identificação são construídas com base em suposições.
Que uma credencial válida significa uma sessão segura. Que as equipes de TI reconstruirão seu diretório para se adequar a uma nova plataforma. Que alguém com profundo conhecimento em IAM estará disponível para manter tudo funcionando.
Essas premissas estão enraizadas na gestão de acesso corporativo há anos, porque, bem, ninguém parou para questioná-las.
Questionamos os três.
1. A identidade é suficiente para conceder acesso.
O SSO, da forma como sempre foi implementado no setor, para no momento em que as credenciais são verificadas. O usuário é quem diz ser. Sessão concedida.
O que nunca foi perguntado foi o que está por trás da credencial. Se o dispositivo está atualizado. Se a solicitação vem de um local que faça sentido. Se o aplicativo acessado deveria estar aberto naquela máquina específica naquele momento específico.
Nós construimos Políticas de Acesso Estendido (XAP) Perguntar exatamente isso.
Cada login é avaliado considerando o contexto completo. Os sinais de conformidade do dispositivo em tempo real, provenientes da Veltar, influenciam diretamente a decisão de acesso. Se algo não estiver correto, o acesso é bloqueado antes mesmo de qualquer coisa ser aberta. Sem revisão manual. Sem intervenção do administrador. A política simplesmente funciona.
Em seguida, analisamos o outro lado do mesmo problema.
Em um dispositivo que o OneIdP já conhece e confia, pedir ao usuário para digitar a senha novamente não agrega valor. Apenas cria atrito, o que silenciosamente indica à pessoa do outro lado da tela que o departamento de TI não confia nela. O SSO aprimorado em dispositivos gerenciados elimina isso completamente. O status de conformidade do dispositivo se torna a credencial. A experiência se torna invisível — da melhor maneira possível.
2. Você começará do zero com uma nova identidade.
Toda proposta do tipo "basta migrar para a nossa plataforma" tem o mesmo ponto cego.
Isso pressupõe que as equipes de TI abandonarão anos de configuração de diretórios, integrações de IdP e políticas de acesso, e reconstruirão tudo do zero em uma nova ferramenta. Para uma equipe que gerencia 800 dispositivos em dois continentes, essa não é uma migração fácil.
A Federação de Identidade foi criada para essa realidade.
O OneIdP atua como a camada de política de acesso sobre qualquer infraestrutura já existente. Entra, Google Workspace, Okta, PingOne ou Configurações do Active Directory local que são anteriores à atual equipe de TI — tudo permanece no mesmo lugar.
Levamos isso ainda mais longe com SCIM Entrada e saída. Quando alguém entra na empresa, o acesso é provisionado automaticamente. Quando a função muda, o acesso se adapta. Quando a pessoa sai da empresa, as contas são removidas sem que seja necessário abrir um chamado ou realizar qualquer etapa manual. A representação da força de trabalho em todos os aplicativos conectados permanece precisa.
3. Sempre haverá alguém para administrá-lo.
A decisão sobre a arquitetura é a parte fácil. O problema geralmente está na convivência com a plataforma e na gestão de identidades.
Senhas de administrador local São um bom exemplo de um problema que permanece silenciosamente em segundo plano até que deixe de existir. Credenciais idênticas em centenas de máquinas, inalteradas por meses, porque rotacioná-las manualmente é uma tarefa para a qual ninguém tem tempo. O LAPS automatizou esse processo. A rotação ocorre conforme o cronograma. Todas as credenciais são auditadas. O risco desaparece sem exigir que ninguém tome nenhuma providência.
O Portal do Usuário oferecia aos funcionários um local centralizado para encontrar todos os aplicativos autorizados. Selecionado pela TI, sempre atualizado, sem ambiguidade sobre o que era aprovado. O tipo de coisa que não gera elogios, mas elimina permanentemente uma categoria específica de chamados ao suporte técnico.
O SSO baseado em dispositivo resolveu o problema de dispositivos compartilhados que estava sem solução desde o lançamento. Qualquer usuário cadastrado em uma máquina gerenciada obtém acesso ao aplicativo. Não é necessário cadastrar novamente o usuário entre turnos. O acesso acompanha a pessoa. O dispositivo permanece pronto para quem chegar em seguida.
Os registros de acesso SSO forneceram a todos os CISOs o histórico de auditoria que solicitaram em sua primeira revisão de segurança — automaticamente, sem que ninguém precisasse criá-lo em uma planilha.
Três pressupostos. Três decisões deliberadas para construir de forma diferente.
Mas decisões no papel e decisões na produção são duas coisas muito diferentes.
Eis como tudo realmente aconteceu.
A cronologia, sinceramente.
Ajuda ver como isso se desenrolou — não como um roteiro de produto, mas como uma série de respostas ao que estávamos aprendendo:
Lançamento do OneIdP
Diretório, Autenticação Única, Cartão de Acesso.
Integrações com provedores de identidade
GWS, Entra, Okta, PingOne, AD local, etc.
Portal do usuário e federação de identidades
Portal personalizado e controlado por TI para cada aplicação aprovada.
SCIM v2.0 — Provisionamento em escala
Sincronização de usuários. Funcionários desligados são automaticamente desvinculados do sistema.
Políticas de Acesso Estendido (XAP)
Conceda acesso SSO com base na conformidade do dispositivo, localização, IP e presença do aplicativo.
SSO baseado em dispositivo + LAPS
Permitir que dispositivos gerenciados compatíveis acessem aplicativos independentemente do usuário conectado.
Atribuições de SSO baseadas em grupos de usuários
Adicione exceções ao Acesso Condicional em configurações de SSO ou atribua usuários em massa a configurações de SSO usando o grupo de usuários.
chaves de acesso
Acesso sem senha com biometria, chaves de segurança e dispositivos confiáveis. Gerenciado centralmente pela TI, com autosserviço para os usuários.
Como o OneIdP realmente se parece hoje em dia
Quando lançamos o produto, as conversas giravam em torno da construção da base correta. A ideia era integrar a confiança e a identidade do dispositivo na mesma camada de políticas, fazendo com que o acesso condicional refletisse, de fato, o que estava acontecendo no endpoint em tempo real.
Hoje, as conversas giram em torno do que essa base pode suportar. Integrações mais profundas, cobertura de frota mais ampla, políticas de acesso que se estendem por toda a infraestrutura — porque a plataforma foi construída para isso.
Essa progressão, da base à plataforma completa, é exatamente onde pretendíamos chegar.
OneIdP Hoje, a identidade, a confiança no dispositivo e a política de acesso são avaliadas em conjunto — a cada login, em tempo real, sem lacunas entre o endpoint que você gerencia e o acesso que você controla. O dispositivo e a pessoa por trás dele finalmente compartilham o mesmo universo de políticas.
O que mantivemos ao longo de todo o processo é algo que é constantemente testado no desenvolvimento de produtos: “a plataforma de acesso mais sofisticada só tem valor se a equipe de TI for capaz de, de fato, operá-la. Uma equipe enxuta que gerencia uma frota distribuída não deveria precisar de um engenheiro de IAM dedicado para manter tudo funcionando.”
Todas as versões lançadas nos últimos dois anos seguiram esse princípio: serem suficientemente robustas para um ambiente complexo e suficientemente operacionais para as pessoas que realmente o utilizam.
Esse equilíbrio é o que mais nos orgulha.
O que vem
Dois anos construindo ao lado de equipes de TI te ensinam algo útil: o problema é sempre maior do que aquele que você acabou de resolver.
A confiança nos dispositivos gerou questionamentos sobre o acesso à rede. O acesso à rede, por sua vez, levou a questionamentos sobre a infraestrutura. O suporte ao Cloud RADIUS e o acesso SSH baseado em identidade são as próximas respostas — já em desenvolvimento, moldadas pelas mesmas discussões que deram origem a tudo o que foi mencionado acima.
O escopo do que o acesso de confiança zero precisa governar continua se expandindo, e pretendemos nos expandir junto com ele.
