Best Buy Amplia a IA do Google Cloud, mas as Credenciais Compartilhadas Precisavam Sair

A Best Buy substituiu um modelo de acesso intensivo em credenciais enquanto prepara dezenas de milhares de usuários para uma presença maior de IA e análises no Google Cloud. Até agora, parte dos acessos dependia de contas de serviço, identidades sincronizadas e chaves rotacionadas manualmente. Essa estrutura se tornou mais difícil de justificar à medida que o uso se expandiu.

A varejista agora conecta o Microsoft Entra ID diretamente ao Google Cloud por meio do Workforce Identity Federation. O sistema valida a identidade corporativa existente de um desenvolvedor no momento do acesso. Ele não exige que o Google mantenha uma cópia sincronizada de todos os registros da força de trabalho.

A mudança parece um projeto de modernização de identidade. Sua importância maior está em saber se a Best Buy consegue expandir a IA baseada em nuvem sem multiplicar credenciais, trabalho administrativo e registros de auditoria ambíguos. O modelo anterior tratava o acesso como algo que as equipes provisionavam e mantinham. O novo modelo trata a identidade como uma relação de confiança ativa.

Essa distinção pressiona o modelo consolidado de contas de serviço. Ela também ilustra uma disputa mais ampla entre diretórios de nuvem sincronizados e federação direta de identidade. A Best Buy aposta que seu sistema de identidade da Microsoft pode continuar sendo o ponto de controle enquanto os funcionários usam serviços de dados e IA de outro provedor.

A Best Buy Removeu a Camada de Credenciais que Bloqueava a Expansão

A mudança imediata da Best Buy foi simples, mas relevante: os desenvolvedores agora entram no Google Cloud como funcionários identificáveis, em vez de se ocultarem por trás de credenciais compartilhadas de contas de serviço.

A Best Buy descreveu o projeto em um anúncio de 28 de julho. A varejista afirmou que a expansão de suas atividades de análises e IA criou dois problemas relacionados. Ela precisava reduzir o risco das credenciais sem enfrentar o atrito administrativo de sincronizar milhares de usuários de backend.

Historicamente, a empresa operava pipelines de sincronização que copiavam identidades de backend do Microsoft Entra ID para o Google Cloud. O Entra ID é o provedor de identidade corporativa já existente da Best Buy, que autentica funcionários e aplica políticas de acesso empresariais.

A Best Buy usava Cloud Identity sem uma implantação do Google Workspace. Essa configuração deixou a organização de tecnologia precisando de uma ponte prática entre sua força de trabalho gerenciada pela Microsoft e sua coleção crescente de recursos em nuvem.

O acesso do Power BI ao BigQuery expôs os limites do arranjo anterior. O BigQuery é a plataforma gerenciada de dados do Google para cargas de trabalho de análises e IA. Anteriormente, os usuários que trabalhavam por meio do Power BI dependiam de credenciais de contas de serviço ao se conectar a ele.

Uma conta de serviço representa uma aplicação ou processo, e não um funcionário identificado. Ela pode ser adequada para cargas de trabalho de software, mas enfraquece a responsabilização quando várias pessoas usam sua chave para acesso interativo.

Cada chave de longa duração também se torna um elemento que alguém precisa emitir, armazenar, rastrear, rotacionar e, por fim, revogar. A Best Buy afirmou que suas equipes de segurança e plataforma precisavam saber quais credenciais cada equipe possuía. Elas também precisavam considerar a possibilidade de uma chave aparecer em uma mensagem de chat ou em outro local sem controle.

Esses não são incômodos administrativos isolados. Cada credencial adicional cria outro caminho que precisa permanecer protegido durante todo o seu ciclo de vida. O crescimento aumenta tanto o número de caminhos quanto as consequências de perder o controle de um deles.

A nova arquitetura da Best Buy remove essa chave intermediária do fluxo de acesso dos funcionários. Um desenvolvedor entra com uma identidade existente do Entra ID. Em seguida, o Workforce Identity Federation intermedeia a confiança entre o sistema de identidade da Microsoft e os controles de recursos do Google.

O desenvolvedor pode acessar o BigQuery por meio do Power BI ou usar chamadas diretas de API. O Google Cloud registra a atividade sob a identidade individual, em vez de uma conta de serviço compartilhada. Isso dá às equipes de segurança uma resposta mais clara quando uma auditoria pergunta quem acessou um conjunto de dados ou alterou um recurso.

A Best Buy afirma que o projeto pode atender dezenas de milhares de usuários. Agora, ela está ampliando o modelo para uma força de trabalho mais ampla à medida que os serviços em nuvem se tornam mais importantes para as operações de varejo.

A alegação de expansão ainda precisa de resultados mensurados. A Best Buy não publicou taxas de adoção, duração da migração, reduções de incidentes nem economias administrativas. No entanto, a mudança arquitetural remove uma restrição evidente antes da chegada desses usuários.

Para líderes de tecnologia, essa sequência importa. A Best Buy não esperou que a administração de identidade se tornasse um gargalo ainda maior. Ela mudou o modelo de acesso antes de adicionar outra grande leva de usuários e cargas de trabalho.

Por que a IA do Google Cloud Tornou a Dívida de Identidade Mais Difícil de Ignorar

A expansão da IA não criou a dívida de identidade da Best Buy, mas tornou essa dívida muito mais cara de sustentar.

Análises avançadas dependem de amplo acesso a dados, ambientes de desenvolvimento, modelos e APIs de suporte. Projetos de IA adicionam mais equipes, experimentos e automação a esse cenário. Um processo de credenciais que funciona para um pequeno grupo de dados pode falhar quando a participação atinge escala empresarial.

A pressão recai primeiro sobre as equipes de segurança e plataforma da Best Buy. Elas precisam permitir que os desenvolvedores trabalhem rapidamente sem perder o controle sobre dados sensíveis do varejo. Também precisam preservar evidências de qual pessoa executou cada ação.

Contas de serviço compartilhadas criam tensão entre esses requisitos. Elas podem simplificar uma conexão inicial porque uma equipe recebe uma identidade técnica. No entanto, esse mesmo atalho reduz a atribuição individual e introduz um segredo de longa duração que precisa permanecer protegido.

A rotação não elimina esse problema. Ela transfere o problema para um processo operacional recorrente. As equipes precisam distribuir chaves substitutas, atualizar ferramentas dependentes, remover cópias antigas e confirmar que os fluxos de trabalho de produção continuam funcionando.

Uma credencial expirada pode interromper o trabalho. Uma credencial vazada pode expor recursos. Uma credencial esquecida pode continuar disponível depois que a necessidade comercial original desaparece.

O Google recomenda que as organizações escolham uma alternativa mais segura sempre que possível, porque as chaves de contas de serviço exigem proteção cuidadosa. Suas orientações sobre identidade de carga de trabalho tratam a federação como o modelo preferido para cargas de trabalho de software externas.

O caso de uso da Best Buy envolve identidades da força de trabalho, e não cargas de trabalho de máquinas, mas o princípio de segurança é semelhante. Segredos de longa duração deslocam a responsabilidade para o armazenamento e a rotação. O acesso federado depende de tokens de curta duração e de uma relação de confiança explícita.

Essa mudança se torna mais importante à medida que o acesso aos dados se espalha além de uma equipe central de nuvem. Analistas podem consultar o BigQuery por meio de ferramentas familiares de inteligência de negócios. Desenvolvedores podem acessar APIs diretamente. Aplicações futuras de IA podem levar equipes operacionais adicionais ao mesmo ambiente.

A camada de identidade, portanto, torna-se parte do planejamento de capacidade de IA. Mais capacidade de computação e modelos melhores pouco realizam se cada novo usuário exigir um registro paralelo, uma credencial gerenciada manualmente e mais uma exceção em um processo de auditoria.

A decisão da Best Buy também preserva sua experiência de força de trabalho centrada na Microsoft. Os funcionários continuam se autenticando com credenciais corporativas familiares. A varejista não precisa transformar um segundo repositório de identidades na fonte diária de verdade para esses usuários.

É aqui que o Google Cloud enfrenta sua própria pressão. Clientes empresariais frequentemente operam em ambientes tecnológicos mistos. Uma varejista pode usar a Microsoft para identidade da força de trabalho e inteligência de negócios, enquanto escolhe o Google para processamento de dados ou IA.

Os provedores de nuvem não podem presumir que conquistar uma carga de trabalho de IA também significa substituir o provedor de identidade do cliente. Eles precisam aceitar identidades externas sem enfraquecer seus próprios sistemas de autorização e auditoria.

O Google posiciona a federação de força de trabalho como essa ponte. Ela oferece suporte a SAML e OpenID Connect, dois padrões para trocar informações de identidade entre provedores. Ela também pode mapear atributos externos em políticas de acesso a recursos.

O resultado é mais do que login único. O login único torna a experiência de entrada familiar. A federação também precisa traduzir uma identidade confiável em permissões que o Google Cloud possa avaliar para um recurso específico.

Para a Best Buy, o teste prático é saber se esse modelo acompanha a adoção de IA. Cada novo conjunto de dados, projeto e aplicação introduz outra decisão de autorização. A federação remove credenciais duplicadas, mas não elimina a necessidade de tomar essas decisões com cuidado.

A Federação do Google Cloud Substitui a Sincronização por Confiança em Tempo Real

O mecanismo central é a validação sem estado: o Google verifica um token do Entra ID no momento do acesso, em vez de manter um diretório duplicado da força de trabalho.

O Workforce Identity Federation cria uma relação de confiança entre uma organização do Google Cloud e um provedor de identidade externo. O Entra ID autentica o funcionário. Em seguida, o Google avalia o token resultante e mapeia suas declarações para uma identidade reconhecida por suas políticas de acesso.

Um token é uma declaração digital assinada que contém informações de identidade e um período limitado de validade. O Google valida essa declaração no momento do acesso. A Best Buy não precisa mais de um registro de usuário sincronizado no lado do Google para cada funcionário federado.

Essa é a inversão central do projeto. O sistema antigo copiava identidades para outro ambiente e depois tentava manter essas cópias atualizadas. O novo sistema pede evidências ao provedor autoritativo sempre que uma pessoa solicita acesso.

A sincronização introduz vários problemas de tempo. Um novo funcionário pode esperar por um ciclo de provisionamento antes de receber acesso. Uma mudança de função pode não aparecer imediatamente. O registro copiado de um funcionário desligado pode persistir até que outro sistema o remova.

A federação direta reduz essas lacunas específicas porque o Entra ID continua responsável pela autenticação e pelo ciclo de vida do usuário. Se a Best Buy revogar o acesso de um funcionário ali, a empresa não precisará localizar e rotacionar uma chave pessoal separada no Google Cloud.

O Google ainda controla a autorização dentro de sua plataforma. A autenticação responde quem é a pessoa. A autorização determina o que essa pessoa pode fazer depois que o Google aceita a identidade.

A Best Buy pode mapear atributos e grupos do Entra ID em regras de acesso do Google Cloud. Essa abordagem oferece suporte a políticas baseadas no contexto empresarial, em vez de emitir uma credencial separada para cada conexão.

A empresa também obtém registros de auditoria mais úteis. Em vez de ver uma ação atribuída a uma identidade de serviço compartilhada, os administradores podem associá-la ao funcionário que a iniciou. Essa distinção ajuda em investigações, revisões de acesso e relatórios de conformidade.

Sem estado não significa sem configuração. A Best Buy precisou estabelecer pools de identidade, provedores, mapeamentos de atributos e políticas de acesso. Um pool de identidades da força de trabalho agrupa identidades externas para que os administradores possam controlar o acesso delas aos recursos em nuvem.

A varejista também fez duas escolhas de implementação que revelam a complexidade operacional do projeto. Ela separou o provisionamento e o login único em aplicações empresariais distintas do Entra ID. Isso evita que mudanças em uma função afetem inesperadamente a outra.

A Best Buy também colocou a conta de serviço de provisionamento do Entra ID em uma unidade organizacional separada e desativou o single sign-on para essa unidade. Sem essa exceção, aplicar o single sign-on globalmente poderia bloquear a conta necessária para configurar o provisionamento.

Esse problema de inicialização é fácil de ignorar. Uma política de identidade pode impedir a própria automação necessária para estabelecer o ambiente de suporte da política. A Best Buy evitou esse ciclo ao isolar a identidade de automação.

Os desenvolvedores veem muito menos dessa infraestrutura. Eles se autenticam uma vez com suas credenciais Microsoft e, em seguida, usam Power BI ou APIs diretas. Parte do valor do sistema vem de ocultar essa fronteira adicional de nuvem do fluxo de trabalho diário.

Essa invisibilidade não deve ser confundida com menor controle. A camada de acesso do Google ainda decide se o principal federado pode usar BigQuery ou outro serviço compatível. Os logs de auditoria da nuvem podem registrar a atividade da pessoa sob esse principal.

O design também separa o acesso de usuários da identidade de software. Desenvolvedores humanos devem acessar como eles próprios sempre que for viável. Aplicações e cargas de trabalho automatizadas ainda exigem suas próprias identidades, permissões e controles de ciclo de vida.

Essa distinção será importante à medida que a Best Buy implemente mais sistemas de IA. Um funcionário consultando dados pelo Power BI não é o mesmo agente que um processo autônomo chamando uma API. Ambos precisam de identidades rastreáveis, mas seus padrões de acesso e salvaguardas são diferentes.

Federar a força de trabalho resolve uma parte desse problema de governança. Isso oferece à varejista uma base mais clara para atribuir responsabilidade humana antes que o acesso automatizado cresça ainda mais.

A Verdadeira Disputa É Federação Versus Diretórios Copiados

A Best Buy escolheu a federação direta em vez de registros de identidade duplicados, mas o mercado mais amplo de nuvem ainda oferece suporte aos dois padrões.

A sincronização de diretórios copia usuários e grupos de um sistema autoritativo para um diretório de destino. Ela fornece ao destino uma representação local de cada identidade. Muitas plataformas empresariais usam esse padrão porque registros locais simplificam atribuições e a integração de aplicações.

A fraqueza surge em escala e durante mudanças. As cópias precisam permanecer alinhadas à sua origem. Atrasos no provisionamento, atualizações com falha, atributos alterados e contas desatualizadas criam trabalho com pouca relação com o valor de negócio de uma aplicação de IA.

A Best Buy já havia enfrentado esse atrito administrativo. As equipes de tecnologia da empresa mantinham pipelines para mover identidades de backend do Entra ID para o Google Cloud. Seu novo modelo evita manter esses registros no Cloud Identity para usuários federados.

A federação direta desloca a dependência. Em vez de depender de um pipeline de sincronização, o acesso depende do Entra ID, da troca de tokens, da configuração do provedor e do caminho de validação do Google.

Isso não elimina a complexidade. É uma decisão sobre onde a complexidade deve ficar. A Best Buy prefere uma fronteira de confiança em tempo real a milhares de identidades duplicadas e chaves de contas de serviço voltadas aos funcionários.

Outros provedores de nuvem fazem concessões relacionadas. A AWS recomenda federação para acesso humano, mas a documentação do IAM Identity Center afirma que usuários e grupos externos geralmente precisam ser provisionados antes que administradores façam atribuições.

A AWS pode se conectar ao Microsoft Entra ID via SAML, enquanto o System for Cross-Domain Identity Management lida com o provisionamento. Seu modelo de identidade externa permite que funcionários usem credenciais corporativas, mas mantém a conscientização sobre usuários e grupos sincronizados dentro do IAM Identity Center.

Isso cria um contraste útil com a implementação do Google pela Best Buy. Ambas as abordagens evitam conceder a cada funcionário uma senha permanente nativa da nuvem. No entanto, diferem na quantidade de estado de identidade que a plataforma de nuvem mantém.

A Microsoft aplica o mesmo princípio de redução de segredos às identidades de máquina. Suas orientações sobre credenciais federadas recomendam federação ou certificados em vez de segredos de cliente para cargas de trabalho externas.

Esses exemplos mostram que a direção da indústria é consistente, mesmo quando as implementações diferem. Os provedores de nuvem incentivam cada vez mais credenciais temporárias e federadas. Ainda assim, fazem escolhas diferentes sobre provisionamento, diretórios locais, mapeamento de atributos e cobertura de serviços.

Para compradores empresariais, a comparação relevante não é qual provedor oferece um recurso de federação. Todos os principais provedores oferecem várias formas disso. As perguntas importantes dizem respeito a como o estado de identidade se move, onde a política reside e o que acontece quando uma dependência falha.

Um diretório sincronizado pode preservar informações locais de usuários durante algumas interrupções externas. Também pode deixar informações desatualizadas para trás. Um design federado sem estado evita essas cópias, mas depende mais diretamente do provedor de origem durante a autenticação.

Nenhuma das arquiteturas elimina a necessidade de acesso de emergência. Os administradores ainda precisam de um caminho rigidamente controlado para incidentes que envolvam um provedor de identidade indisponível, uma configuração de federação danificada ou alterações equivocadas de política.

O caso da Best Buy, portanto, tem menos a ver com o Google derrotando a Microsoft. A Microsoft continua sendo a autoridade que autentica a força de trabalho da varejista. O Google se torna mais utilizável porque aceita essa autoridade sem exigir outro repositório de usuários.

Esse arranjo reflete como grandes organizações realmente compram tecnologia. Elas combinam serviços de nuvem, identidade, análise e produtividade de vários fornecedores. Um design de acesso que exige que um provedor possua todas as camadas introduz trabalho de migração e resistência.

O Google ganha quando funcionários gerenciados pela Microsoft podem acessar BigQuery sem adotar outra identidade diária. A Microsoft mantém seu lugar no ciclo de vida dos funcionários. A Best Buy reduz o número de credenciais que suas equipes precisam governar.

A conta de serviço perde seu papel inadequado como substituta do acesso humano nomeado. Esse é o principal adversário desta história, não outro fornecedor de nuvem.

Para desenvolvedores, essa fronteira também melhora a documentação operacional. Quando um registro de incidente identifica a pessoa, o projeto e o recurso afetado, as equipes podem construir uma base de conhecimento técnico mais útil. Identidades compartilhadas tornam esse histórico mais difícil de interpretar.

Menos Chaves Não Significam Segurança Automática

A federação elimina um risco de gerenciamento de credenciais, mas sua configuração de confiança se torna um plano de controle de alto valor que a Best Buy precisa testar continuamente.

O Google e a Best Buy descrevem o novo modelo como uma redução da superfície de ataque associada a chaves. Essa afirmação é razoável no nível arquitetural. Uma credencial que não existe mais não pode ser copiada de um laptop, colada em um chat ou esquecida em um repositório.

No entanto, o estudo de caso público não estabelece uma redução mensurada em incidentes de segurança. Ele não fornece uma contagem de antes e depois de chaves expostas, solicitações não autorizadas, auditorias com falha ou tempo de recuperação.

O artigo também não divulga o número de usuários já migrados. Ele afirma que a arquitetura tem como alvo dezenas de milhares de pessoas e que a Best Buy está ampliando o acesso para uma força de trabalho mais ampla. Essas declarações descrevem capacidade e direção, não adoção concluída.

A federação concentra a atenção na validação de tokens e no mapeamento de políticas. Se os administradores confiarem em uma declaração excessivamente ampla, configurarem incorretamente um público ou mapearem um grupo de forma errada, um funcionário válido poderá receber mais acesso do que o pretendido.

O acesso baseado em atributos pode reduzir o trabalho administrativo porque as políticas seguem características da força de trabalho. Também pode distribuir o risco para a qualidade desses atributos. Uma associação equivocada a um grupo no Entra ID pode se tornar um erro de autorização no Google Cloud.

As equipes de segurança, portanto, precisam testar ambos os lados da relação. Elas precisam ter garantia de que o Entra ID emite as declarações esperadas. Também precisam ter garantia de que o Google interpreta essas declarações exatamente como pretendido.

O princípio do menor privilégio continua essencial. Esse princípio concede a cada identidade apenas as permissões necessárias para seu trabalho. A federação não determina, por si só, o nível correto de permissão.

A Best Buy também precisa separar funcionários de cargas de trabalho automatizadas. A empresa removeu chaves de contas de serviço do fluxo de acesso de desenvolvedores descrito. Ela não afirmou que as contas de serviço desapareceram de todas as aplicações ou processos de backend.

Sistemas de IA complicam essa fronteira. Um desenvolvedor pode iniciar um experimento, enquanto pipelines e agentes agendados continuam trabalhando sem a sessão ativa dessa pessoa. Esses processos precisam de identidades de máquina com permissões restritas e propriedade rastreável.

A documentação do Google lista os produtos compatíveis com identidades federadas e observa limitações específicas de cada serviço. A Best Buy precisa confirmar a compatibilidade antes de expandir o design para todos os serviços de nuvem envolvidos em suas operações de varejo.

A disponibilidade apresenta outra concessão. Um login federado depende de vários componentes em funcionamento, incluindo Entra ID, conectividade de rede, troca de tokens do Google e configuração correta do provedor.

Uma interrupção nessa cadeia pode impedir novas sessões. As organizações precisam de contas de emergência cuidadosamente limitadas ou de outro mecanismo de recuperação. Essas exceções exigem monitoramento excepcionalmente rigoroso porque ficam fora do caminho normal de identidade.

O comportamento das sessões também merece análise. Revogar uma pessoa no diretório de origem deve bloquear autenticações futuras, mas tokens ou sessões existentes podem permanecer utilizáveis até o fim de sua vida útil configurada. Sessões mais curtas reduzem a exposição, mas exigem renovação mais frequente.

A auditabilidade melhora quando as ações carregam identidades nomeadas. Ainda assim, os logs só ajudam se as equipes os retiverem, monitorarem e investigarem. A Best Buy ainda precisa de alertas que distingam atividades analíticas normais de exportações incomuns, alterações de permissões ou padrões de acesso atípicos.

Há também uma questão de governança sobre o acesso a dados de IA. A identidade pode provar qual funcionário acessou um conjunto de dados. Ela não pode decidir se o conjunto de dados era apropriado para um modelo, prompt ou experimento específico.

A classificação de dados, a governança de modelos e os controles de privacidade continuam sendo responsabilidades separadas. A federação torna a aplicação de regras mais atribuível, mas não cria as regras subjacentes.

O estudo de caso vem do Google Cloud e de um líder de engenharia de nuvem da Best Buy. Ele deve ser lido como um relato oficial de cliente, não como uma avaliação de segurança independente.

A conclusão mais forte, portanto, é mais limitada do que a mensagem de marketing. A Best Buy removeu credenciais compartilhadas de longa duração de um padrão de acesso importante. Isso dá à sua organização de segurança menos segredos para gerenciar e uma atribuição de usuários mais clara.

Se o resultado permanecer controlado em escala total dependerá de revisões de acesso, qualidade das políticas, cobertura de serviços e desempenho em incidentes. Esses resultados ainda não foram publicados.

Três Sinais Mostrarão se o Modelo Escala

O próximo teste é a evidência operacional: uma adoção mais ampla deve preservar a responsabilização individual sem reconstruir a carga administrativa em outro lugar.

O primeiro sinal é a porcentagem da força de trabalho pretendida da Best Buy que usa federação para acesso ativo à nuvem. A empresa afirma que está ampliando a arquitetura, mas não forneceu um cronograma de migração nem uma métrica de conclusão.

Uma implementação ampla com poucas exceções fortaleceria o argumento a favor de uma identidade de força de trabalho sem estado em escala de varejo. Uma coleção crescente de exceções de contas de serviço sugeriria que a compatibilidade de ferramentas ou o design de fluxos de trabalho continua sendo uma restrição.

A métrica útil não é simplesmente o número de usuários cadastrados. A Best Buy deve examinar quantas conexões interativas ainda dependem de credenciais de longa duração. Também deve acompanhar a rapidez com que novos funcionários, transferências e desligamentos recebem o acesso correto.

O segundo sinal é a qualidade dos resultados de autorização e auditoria. O acesso nominal deve reduzir entradas ambíguas nos logs e acelerar investigações. A Best Buy não divulgou evidências que mostrem se essas melhorias se concretizaram.

As equipes de segurança devem observar mapeamentos incorretos de atributos, permissões inesperadas, trocas de tokens malsucedidas e acessos que persistem após mudanças no vínculo empregatício. Uma redução no trabalho manual de rotação de chaves confirmaria que a federação eliminou dívida operacional, em vez de apenas deslocá-la.

Um aumento nos erros de autorização enfraqueceria a promessa central da implementação. Esse resultado poderia indicar que a sincronização de identidades foi substituída por uma manutenção de políticas igualmente difícil.

O terceiro sinal é como a varejista lida com o acesso de IA não humano. A federação da força de trabalho atende funcionários e outros usuários humanos. Agentes de IA, pipelines, notebooks e tarefas agendadas ainda precisam de identidades de máquina distintas.

Uma expansão madura manteria essas identidades de máquina separadas dos funcionários, vinculando cada uma a um responsável, uma finalidade e um escopo de permissões. Ela evitaria voltar a chaves baixáveis apenas porque sistemas automatizados precisam de acesso sem supervisão.

É aí que o projeto da Best Buy pode influenciar outras empresas. O precedente importante não é que os funcionários recebam single sign-on. As empresas já oferecem essa experiência há anos.

O precedente é que uma empresa pode preservar sua autoridade de identidade Microsoft existente enquanto expande análises e IA na plataforma do Google. Ela pode fazer isso sem colocar outra credencial de longa duração entre o funcionário e o recurso na nuvem.

Se a implementação for bem-sucedida, a federação de identidades se tornará uma camada habilitadora para a adoção de IA multicloud. Líderes de tecnologia poderão escolher serviços de dados e modelos sem criar outro diretório da força de trabalho para cada plataforma.

Se enfrentar dificuldades, os problemas mais prováveis aparecerão em exceções, mapeamentos de políticas, limitações de serviços e procedimentos de recuperação. Esses detalhes determinam se a arquitetura funciona além de um caso de uso do BigQuery cuidadosamente selecionado.

Para desenvolvedores, o resultado imediato é mais fácil de perceber. Eles mantêm seu login corporativo estabelecido, enquanto os registros de auditoria podem identificar suas ações. Já não precisam tratar uma chave compartilhada como o preço para acessar dados na nuvem.

Para as equipes de segurança, o trabalho muda em vez de desaparecer. Elas gerenciam relações de confiança, atributos de acesso, regras de sessão, caminhos de emergência e identidades de máquina. Esses controles são mais centralizados, mas erros podem afetar uma população mais ampla.

Para compradores corporativos, a decisão da Best Buy oferece uma questão prática de avaliação: uma plataforma de nuvem aceita as identidades que já governam sua força de trabalho ou exige outro repositório e processo de ciclo de vida?

A Best Buy escolheu o primeiro caminho para sua expansão no Google Cloud. A arquitetura remove uma barreira conhecida antes que o uso de análises e IA alcance uma força de trabalho maior. Os próximos meses devem revelar se a adoção, a qualidade da auditoria e os controles de identidade de máquina sustentam essa confiança.

Organizações que consideram a mesma mudança devem começar pelas próprias evidências de acesso. Identifiquem onde humanos ainda usam chaves de contas de serviço, determinem quais serviços de nuvem aceitam identidades federadas e meçam com que rapidez a revogação alcança sessões ativas. A federação do Google Cloud se torna valiosa quando esses resultados melhoram, e não apenas quando a tela de login muda.