Best Buy amplía Google Cloud AI, pero tuvo que eliminar las credenciales compartidas

Best Buy ha sustituido un modelo de acceso con un uso intensivo de credenciales mientras prepara a decenas de miles de usuarios para una presencia mayor de IA y analítica en Google Cloud. Hasta ahora, parte del acceso dependía de cuentas de servicio, identidades sincronizadas y claves rotadas manualmente. Esa estructura se volvió más difícil de defender a medida que crecía el uso.

El minorista conecta ahora Microsoft Entra ID directamente con Google Cloud mediante Workforce Identity Federation. El sistema valida la identidad corporativa existente de un desarrollador cuando se produce el acceso. No requiere que Google mantenga una copia sincronizada de cada registro de la plantilla.

El cambio parece un proyecto de modernización de identidades. Su importancia mayor se refiere a si Best Buy puede ampliar la IA basada en la nube sin multiplicar las credenciales, el trabajo administrativo y los registros de auditoría ambiguos. El enfoque anterior trataba el acceso como algo que los equipos aprovisionaban y mantenían. El nuevo enfoque trata la identidad como una relación de confianza activa.

Esa distinción presiona al modelo establecido de cuentas de servicio. También ilustra una competencia más amplia entre directorios cloud sincronizados y federación directa de identidades. Best Buy apuesta por que su sistema de identidad de Microsoft puede seguir siendo el punto de control mientras los empleados usan los servicios de datos e IA de otro proveedor.

Best Buy eliminó la capa de credenciales que bloqueaba la expansión

El cambio inmediato de Best Buy fue sencillo pero relevante: los desarrolladores ahora acceden a Google Cloud como empleados identificables en lugar de ocultarse tras credenciales compartidas de cuentas de servicio.

Best Buy describió el proyecto en un anuncio del 28 de julio. El minorista afirmó que su actividad creciente de analítica e IA generó dos problemas relacionados. Necesitaba reducir el riesgo de las credenciales y, al mismo tiempo, evitar la fricción administrativa de sincronizar miles de usuarios de backend.

La empresa operaba históricamente canalizaciones de sincronización que copiaban identidades de backend desde Microsoft Entra ID a Google Cloud. Entra ID es el proveedor de identidad corporativa existente de Best Buy, que autentica a los empleados y aplica políticas empresariales de acceso.

Best Buy utilizaba Cloud Identity sin una implementación de Google Workspace. Esa configuración dejaba a la organización tecnológica necesitando un puente práctico entre su plantilla gestionada por Microsoft y su creciente conjunto de recursos cloud.

El acceso de Power BI a BigQuery dejó al descubierto los límites del acuerdo anterior. BigQuery es la plataforma de datos gestionada de Google para cargas de trabajo de analítica e IA. Los usuarios que trabajaban mediante Power BI dependían anteriormente de credenciales de cuentas de servicio al conectarse a ella.

Una cuenta de servicio representa una aplicación o un proceso, en lugar de un empleado identificado. Puede ser apropiada para cargas de trabajo de software, pero debilita la trazabilidad cuando varias personas utilizan su clave para acceso interactivo.

Cada clave de larga duración se convierte además en un elemento que alguien debe emitir, almacenar, rastrear, rotar y, finalmente, revocar. Best Buy indicó que sus equipos de seguridad y plataforma debían saber qué credenciales tenía cada equipo. También debían considerar la posibilidad de que una clave apareciera en un mensaje de chat u otra ubicación no controlada.

No se trata de molestias administrativas aisladas. Cada credencial adicional crea otra vía que debe seguir protegida durante todo su ciclo de vida. El crecimiento aumenta tanto la cantidad de vías como las consecuencias de perder el control de una de ellas.

La nueva arquitectura de Best Buy elimina esa clave intermedia del flujo de acceso de los empleados. Un desarrollador inicia sesión con una identidad existente de Entra ID. Workforce Identity Federation intermedia entonces la confianza entre el sistema de identidad de Microsoft y los controles de recursos de Google.

El desarrollador puede acceder a BigQuery mediante Power BI o utilizar llamadas directas a la API. Google Cloud registra la actividad bajo la identidad individual en lugar de una cuenta de servicio compartida. Eso ofrece a los equipos de seguridad una respuesta más clara cuando una auditoría pregunta quién accedió a un conjunto de datos o modificó un recurso.

Best Buy afirma que el diseño puede admitir a decenas de miles de usuarios. Ahora está ampliando el modelo a una plantilla más extensa a medida que los servicios cloud adquieren más importancia para las operaciones minoristas.

La afirmación sobre la expansión aún necesita resultados medidos. Best Buy no ha publicado tasas de adopción, duración de la migración, reducciones de incidentes ni ahorros administrativos. Sin embargo, el cambio arquitectónico elimina una restricción evidente antes de que lleguen esos usuarios.

Para los líderes tecnológicos, esa secuencia importa. Best Buy no esperó a que la administración de identidades se convirtiera en un cuello de botella aún mayor. Cambió el modelo de acceso antes de incorporar otra gran oleada de usuarios y cargas de trabajo.

Por qué Google Cloud AI hizo más difícil ignorar la deuda de identidad

La expansión de la IA no creó la deuda de identidad de Best Buy, pero hizo que mantenerla resultara mucho más costoso.

La analítica avanzada depende de un acceso amplio a datos, entornos de desarrollo, modelos y API de soporte. Los proyectos de IA añaden más equipos, experimentos y automatización a ese panorama. Un proceso de credenciales que funciona para un pequeño grupo de datos puede fallar cuando la participación alcanza escala empresarial.

La presión recae primero en los equipos de seguridad y plataforma de Best Buy. Deben permitir que los desarrolladores trabajen con rapidez sin perder el control de los datos minoristas sensibles. También deben conservar evidencia que muestre qué persona realizó cada acción.

Las cuentas de servicio compartidas generan tensión entre esos requisitos. Pueden simplificar una conexión inicial porque un equipo recibe una identidad técnica. Sin embargo, ese mismo atajo reduce la atribución individual e introduce un secreto de larga duración que debe mantenerse protegido.

La rotación no elimina ese problema. Lo desplaza a un proceso operativo recurrente. Los equipos deben distribuir claves de reemplazo, actualizar las herramientas dependientes, eliminar copias antiguas y confirmar que los flujos de trabajo de producción siguen funcionando.

Una credencial vencida puede interrumpir el trabajo. Una credencial filtrada puede exponer recursos. Una credencial olvidada puede seguir disponible después de que desaparezca la necesidad empresarial original.

Google aconseja a las organizaciones elegir una alternativa más segura siempre que sea posible, porque las claves de cuentas de servicio requieren una protección cuidadosa. Su guía sobre identidades de carga de trabajo considera la federación como el modelo preferido para cargas de trabajo de software externas.

El caso de uso de Best Buy se refiere a identidades de la plantilla, no a cargas de trabajo de máquinas, pero el principio de seguridad es similar. Los secretos de larga duración trasladan la responsabilidad al almacenamiento y la rotación. El acceso federado depende de tokens de corta duración y de una relación de confianza explícita.

Ese cambio cobra más importancia a medida que el acceso a datos se extiende más allá de un equipo cloud central. Los analistas pueden consultar BigQuery mediante herramientas conocidas de inteligencia empresarial. Los desarrolladores pueden acceder directamente a las API. Las futuras aplicaciones de IA pueden incorporar equipos operativos adicionales al mismo entorno.

Por tanto, la capa de identidad pasa a formar parte de la planificación de capacidad de IA. Más capacidad de cómputo y mejores modelos sirven de poco si cada usuario nuevo requiere un registro paralelo, una credencial gestionada manualmente y otra excepción en un proceso de auditoría.

La decisión de Best Buy también conserva su experiencia de plantilla centrada en Microsoft. Los empleados siguen autenticándose con credenciales corporativas conocidas. El minorista no necesita convertir un segundo almacén de identidades en la fuente cotidiana de referencia para esos usuarios.

Aquí es donde Google Cloud enfrenta su propia presión. Los clientes empresariales operan con frecuencia en entornos tecnológicos mixtos. Un minorista puede utilizar Microsoft para la identidad de la plantilla y la inteligencia empresarial, al tiempo que elige Google para el procesamiento de datos o la IA.

Los proveedores cloud no pueden asumir que ganar una carga de trabajo de IA también implica reemplazar al proveedor de identidad del cliente. Deben aceptar identidades externas sin debilitar sus propios sistemas de autorización y auditoría.

Google presenta la federación de plantilla como ese puente. Admite SAML y OpenID Connect, dos estándares para intercambiar información de identidad entre proveedores. También puede asignar atributos externos a políticas de acceso a recursos.

El resultado es más que inicio de sesión único. El inicio de sesión único hace que la experiencia de acceso resulte familiar. La federación también debe traducir una identidad de confianza en permisos que Google Cloud pueda evaluar para un recurso específico.

Para Best Buy, la prueba práctica es si este modelo mantiene el ritmo de la adopción de IA. Cada nuevo conjunto de datos, proyecto y aplicación introduce otra decisión de autorización. La federación elimina las credenciales duplicadas, pero no elimina la necesidad de tomar esas decisiones con cuidado.

La federación de Google Cloud reemplaza la sincronización por confianza activa

El mecanismo central es la validación sin estado: Google comprueba un token de Entra ID cuando se produce el acceso, en lugar de mantener un directorio duplicado de la plantilla.

Workforce Identity Federation crea una relación de confianza entre una organización de Google Cloud y un proveedor de identidad externo. Entra ID autentica al empleado. Después, Google evalúa el token resultante y asigna sus reclamaciones a una identidad que sus políticas de acceso reconocen.

Un token es una declaración digital firmada que contiene información de identidad y un período limitado de validez. Google valida esa declaración en el momento del acceso. Best Buy ya no necesita un registro de usuario sincronizado del lado de Google para cada empleado federado.

Esta es la inversión clave del proyecto. El sistema anterior copiaba identidades a otro entorno y después intentaba mantener actualizadas esas copias. El nuevo sistema pide pruebas al proveedor autorizado cada vez que una persona solicita acceso.

La sincronización introduce varios problemas de tiempo. Un nuevo empleado podría esperar un ciclo de aprovisionamiento antes de recibir acceso. Un cambio de rol podría no aparecer de inmediato. El registro copiado de un empleado que se marcha podría persistir hasta que otro sistema lo elimine.

La federación directa reduce esas brechas concretas porque Entra ID sigue siendo responsable de la autenticación y del ciclo de vida del usuario. Si Best Buy revoca allí el acceso de un empleado, la empresa no necesita localizar ni rotar una clave personal separada en Google Cloud.

Google sigue gobernando la autorización dentro de su plataforma. La autenticación responde quién es la persona. La autorización determina qué puede hacer esa persona después de que Google acepte la identidad.

Best Buy puede asignar atributos y grupos de Entra ID a reglas de acceso de Google Cloud. Ese enfoque admite políticas basadas en el contexto empresarial, en lugar de emitir una credencial independiente para cada conexión.

La empresa también obtiene registros de auditoría más útiles. En lugar de ver una acción atribuida a una identidad de servicio compartida, los administradores pueden asociarla con el empleado que la inició. Esa distinción ayuda en investigaciones, revisiones de acceso e informes de cumplimiento.

Sin estado no significa sin configuración. Best Buy tuvo que establecer grupos de identidades, proveedores, asignaciones de atributos y políticas de acceso. Un grupo de identidades de plantilla agrupa identidades externas para que los administradores puedan controlar su acceso a recursos cloud.

El minorista también tomó dos decisiones de implementación que revelan la complejidad operativa del proyecto. Separó el aprovisionamiento y el inicio de sesión único en aplicaciones empresariales distintas de Entra ID. Esto evita que los cambios en una función afecten inesperadamente a la otra.

Best Buy también ubicó la cuenta de servicio de aprovisionamiento de Entra ID en una unidad organizativa independiente y deshabilitó el inicio de sesión único para esa unidad. Sin esa excepción, aplicar el inicio de sesión único de forma global podría bloquear la cuenta necesaria para configurar el aprovisionamiento.

Ese problema de arranque es fácil de pasar por alto. Una política de identidad puede impedir la misma automatización necesaria para establecer el entorno que respalda dicha política. Best Buy evitó ese bucle aislando la identidad de automatización.

Los desarrolladores ven mucho menos de esta maquinaria. Se autentican una vez con sus credenciales de Microsoft y después usan Power BI o APIs directas. Parte del valor del sistema proviene de ocultar la frontera adicional de la nube en su flujo de trabajo diario.

Esa invisibilidad no debe confundirse con un menor control. La capa de acceso de Google sigue decidiendo si el principal federado puede usar BigQuery u otro servicio compatible. Los registros de auditoría de la nube pueden registrar la actividad de la persona bajo ese principal.

El diseño también separa el acceso de usuarios de la identidad de software. Los desarrolladores humanos deberían acceder como sí mismos siempre que sea práctico. Las aplicaciones y las cargas de trabajo automatizadas siguen requiriendo sus propias identidades, permisos y controles de ciclo de vida.

Esta distinción será importante a medida que Best Buy despliegue más sistemas de IA. Un empleado que consulta datos mediante Power BI no es el mismo actor que un proceso autónomo que llama a una API. Ambos necesitan identidades responsables, pero sus patrones de acceso y salvaguardas difieren.

Federar a la plantilla resuelve una parte de ese problema de gobernanza. Ofrece al minorista una base más clara para asignar responsabilidad humana antes de que el acceso automatizado siga creciendo.

La verdadera competencia es entre federación y directorios duplicados

Best Buy eligió la federación directa en lugar de registros de identidad duplicados, pero el mercado cloud en general sigue admitiendo ambos patrones.

La sincronización de directorios copia usuarios y grupos desde un sistema autorizado a un directorio de destino. Proporciona al destino una representación local de cada identidad. Muchas plataformas empresariales utilizan este patrón porque los registros locales simplifican las asignaciones y la integración de aplicaciones.

La debilidad aparece a escala y durante los cambios. Las copias deben mantenerse alineadas con su origen. Los retrasos de aprovisionamiento, las actualizaciones fallidas, los atributos modificados y las cuentas obsoletas generan trabajo con poca relación con el valor de negocio de una aplicación de IA.

Best Buy ya había experimentado esa fricción administrativa. Los equipos tecnológicos de la empresa mantenían canalizaciones para trasladar identidades de backend de Entra ID a Google Cloud. Su nuevo modelo evita mantener esos registros en Cloud Identity para los usuarios federados.

La federación directa desplaza la dependencia. En lugar de depender de una canalización de sincronización, el acceso depende de Entra ID, el intercambio de tokens, la configuración del proveedor y la ruta de validación de Google.

Eso no elimina la complejidad. Es una decisión sobre dónde debe residir. Best Buy prefiere un límite de confianza activo a miles de identidades duplicadas y claves de cuentas de servicio orientadas a empleados.

Otros proveedores cloud hacen concesiones relacionadas. AWS recomienda la federación para el acceso humano, pero la documentación de IAM Identity Center indica que los usuarios y grupos externos, por lo general, deben aprovisionarse antes de que los administradores realicen asignaciones.

AWS puede conectarse a Microsoft Entra ID mediante SAML, mientras que System for Cross-Domain Identity Management gestiona el aprovisionamiento. Su modelo de identidad externa permite a los empleados usar credenciales corporativas, pero conserva información sincronizada sobre usuarios y grupos dentro de IAM Identity Center.

Esto crea un contraste útil con la implementación de Google de Best Buy. Ambos enfoques evitan dar a cada empleado una contraseña cloud nativa permanente. Sin embargo, difieren en la cantidad de estado de identidad que mantiene la plataforma cloud.

Microsoft aplica el mismo principio de reducción de secretos a las identidades de máquina. Su guía sobre credenciales federadas recomienda la federación o los certificados en lugar de secretos de cliente para cargas de trabajo externas.

Estos ejemplos muestran que la dirección de la industria es coherente incluso cuando las implementaciones difieren. Los proveedores cloud fomentan cada vez más las credenciales temporales y federadas. Aun así, toman decisiones distintas sobre aprovisionamiento, directorios locales, mapeo de atributos y cobertura de servicios.

Para los compradores empresariales, la comparación relevante no es qué proveedor ofrece una función de federación. Todos los principales proveedores ofrecen varias formas de ella. Las preguntas importantes se refieren a cómo se mueve el estado de identidad, dónde reside la política y qué sucede cuando falla una dependencia.

Un directorio sincronizado puede conservar información local de usuarios durante algunas interrupciones externas. También puede dejar información obsoleta. Un diseño federado sin estado evita esas copias, pero depende más directamente del proveedor de origen durante la autenticación.

Ninguna arquitectura elimina la necesidad de acceso de emergencia. Los administradores siguen necesitando una vía estrictamente controlada para incidentes que involucren un proveedor de identidad no disponible, una configuración de federación dañada o cambios de política erróneos.

Por tanto, el caso de Best Buy trata menos de que Google derrote a Microsoft. Microsoft sigue siendo la autoridad que autentica a la plantilla del minorista. Google se vuelve más utilizable porque acepta esa autoridad sin exigir otro almacén de usuarios.

Este acuerdo refleja cómo las grandes organizaciones compran tecnología en la práctica. Combinan servicios de nube, identidad, analítica y productividad de varios proveedores. Un diseño de acceso que exige que un proveedor posea todas las capas introduce trabajo de migración y resistencia.

Google gana cuando los empleados gestionados por Microsoft pueden acceder a BigQuery sin adoptar otra identidad diaria. Microsoft conserva su lugar en el ciclo de vida del empleado. Best Buy reduce el número de credenciales que sus equipos deben gobernar.

La cuenta de servicio pierde su papel inapropiado como sustituto del acceso humano nominal. Ese es el principal adversario de esta historia, no otro proveedor cloud.

Para los desarrolladores, este límite también mejora la documentación operativa. Cuando un registro de incidentes identifica a la persona, el proyecto y el recurso afectado, los equipos pueden crear una base de conocimiento técnico más útil. Las identidades compartidas hacen que ese historial sea más difícil de interpretar.

Menos claves no significan seguridad automática

La federación elimina un riesgo de gestión de credenciales, pero su configuración de confianza se convierte en un plano de control de alto valor que Best Buy debe probar continuamente.

Google y Best Buy describen el nuevo modelo como una reducción de la superficie de ataque asociada a las claves. Esa afirmación es razonable a nivel arquitectónico. Una credencial que ya no existe no puede copiarse desde un portátil, pegarse en un chat ni olvidarse en un repositorio.

Sin embargo, el caso de estudio público no establece una reducción medida de incidentes de seguridad. No proporciona un recuento antes y después de claves expuestas, solicitudes no autorizadas, auditorías fallidas o tiempo de recuperación.

El artículo tampoco revela el número de usuarios ya migrados. Indica que la arquitectura está dirigida a decenas de miles y que Best Buy está ampliando el acceso a una plantilla más amplia. Esas afirmaciones describen capacidad y dirección, no adopción completada.

La federación concentra la atención en la validación de tokens y el mapeo de políticas. Si los administradores confían en una reclamación demasiado amplia, configuran incorrectamente una audiencia o mapean un grupo de forma errónea, un empleado válido podría recibir más acceso del previsto.

El acceso basado en atributos puede reducir el trabajo administrativo porque las políticas siguen las características de la plantilla. También puede distribuir el riesgo en la calidad de esos atributos. Una pertenencia errónea a un grupo en Entra ID puede convertirse en un error de autorización en Google Cloud.

Por tanto, los equipos de seguridad deben probar ambos lados de la relación. Necesitan garantizar que Entra ID emite las reclamaciones esperadas. También necesitan garantizar que Google interpreta esas reclamaciones exactamente como se pretende.

El principio de mínimo privilegio sigue siendo esencial. Este principio otorga a cada identidad solo los permisos necesarios para su trabajo. La federación no determina por sí sola el nivel de permisos correcto.

Best Buy también debe separar a los empleados de las cargas de trabajo automatizadas. La empresa eliminó las claves de cuentas de servicio del flujo de acceso de desarrolladores descrito. No afirmó que las cuentas de servicio hayan desaparecido de todas las aplicaciones o procesos de backend.

Los sistemas de IA complican ese límite. Un desarrollador puede iniciar un experimento, mientras que las canalizaciones programadas y los agentes siguen trabajando sin la sesión activa de esa persona. Esos procesos necesitan identidades de máquina con permisos limitados y propiedad rastreable.

La documentación de Google enumera los productos que admiten identidades federadas e indica limitaciones específicas de cada servicio. Best Buy debe confirmar la compatibilidad antes de ampliar el diseño a todos los servicios cloud implicados en sus operaciones minoristas.

La disponibilidad presenta otra concesión. Un inicio de sesión federado depende de varios componentes en funcionamiento, incluidos Entra ID, la conectividad de red, el intercambio de tokens de Google y la configuración correcta del proveedor.

Una interrupción en esa cadena puede impedir nuevas sesiones. Las organizaciones necesitan cuentas de emergencia cuidadosamente limitadas u otro mecanismo de recuperación. Esas excepciones requieren una supervisión especialmente estricta porque quedan fuera de la ruta normal de identidad.

El comportamiento de las sesiones también merece escrutinio. Revocar a una persona en el directorio de origen debería bloquear autenticaciones futuras, pero los tokens o sesiones existentes pueden seguir utilizables hasta que termine su vida útil configurada. Las sesiones más cortas reducen la exposición, pero requieren renovaciones más frecuentes.

La auditabilidad mejora cuando las acciones incluyen identidades nominales. Sin embargo, los registros solo ayudan si los equipos los conservan, supervisan e investigan. Best Buy sigue necesitando alertas que distingan la actividad analítica normal de exportaciones inusuales, cambios de permisos o patrones de acceso atípicos.

También hay una cuestión de gobernanza sobre el acceso a datos de IA. La identidad puede demostrar qué empleado accedió a un conjunto de datos. No puede decidir si el conjunto de datos era apropiado para un modelo, prompt o experimento concreto.

La clasificación de datos, la gobernanza de modelos y los controles de privacidad siguen siendo responsabilidades independientes. La federación hace que la aplicación sea más atribuible, pero no crea las reglas subyacentes.

El caso de estudio procede de Google Cloud y de un responsable de ingeniería cloud de Best Buy. Debe leerse como el relato oficial de un cliente, no como una evaluación de seguridad independiente.

Por tanto, la conclusión más sólida es más limitada que el mensaje de marketing. Best Buy eliminó credenciales compartidas de larga duración de un patrón de acceso importante. Eso proporciona a su organización de seguridad menos secretos que gestionar y una atribución de usuarios más clara.

Que el resultado siga estando controlado a plena escala dependerá de las revisiones de acceso, la calidad de las políticas, la cobertura de servicios y el desempeño ante incidentes. Esos resultados aún no se han publicado.

Tres señales mostrarán si el modelo escala

La próxima prueba es la evidencia operativa: una adopción más amplia debe preservar la responsabilidad individual sin reconstruir la carga administrativa en otro lugar.

La primera señal es el porcentaje de la plantilla prevista de Best Buy que utiliza la federación para el acceso cloud activo. La empresa dice que está ampliando la arquitectura, pero no ha proporcionado un calendario de migración ni una métrica de finalización.

Un despliegue amplio con excepciones limitadas reforzaría el argumento a favor de una identidad de plantilla sin estado a escala minorista. Una colección creciente de excepciones de cuentas de servicio sugeriría que la compatibilidad de herramientas o el diseño de flujos de trabajo siguen siendo una limitación.

La métrica útil no es simplemente el número de usuarios inscritos. Best Buy debería examinar cuántas conexiones interactivas siguen dependiendo de credenciales de larga duración. También debería medir la rapidez con la que los nuevos empleados, los traslados y las salidas reciben el acceso correcto.

La segunda señal es la calidad de los resultados de autorización y auditoría. El acceso identificado debería reducir las entradas ambiguas en los registros y acelerar las investigaciones. Best Buy no ha publicado evidencia que demuestre si esas mejoras se han materializado.

Los equipos de seguridad deberían vigilar asignaciones incorrectas de atributos, permisos inesperados, intercambios de tokens fallidos y accesos que persistan tras cambios laborales. Una disminución del trabajo manual de rotación de claves confirmaría que la federación eliminó deuda operativa, en lugar de desplazarla.

Un aumento de los errores de autorización debilitaría la promesa central del despliegue. Ese resultado podría indicar que la sincronización de identidades fue sustituida por un mantenimiento de políticas igual de complejo.

La tercera señal es cómo el minorista gestiona el acceso de IA no humano. La federación de la fuerza laboral abarca a empleados y otros usuarios humanos. Los agentes de IA, los pipelines, los notebooks y las tareas programadas siguen necesitando identidades de máquina diferenciadas.

Una expansión madura mantendría esas identidades de máquina separadas de los empleados, al tiempo que vincularía cada una con un responsable, un propósito y un alcance de permisos. Evitaría volver a las claves descargables simplemente porque los sistemas automatizados necesitan acceso sin supervisión.

Ahí es donde el proyecto de Best Buy puede influir en otras empresas. El precedente importante no es que los empleados reciban inicio de sesión único. Las empresas han ofrecido esa experiencia durante años.

El precedente es que una empresa puede conservar su autoridad de identidad de Microsoft existente mientras amplía la analítica y la IA en la plataforma de Google. Puede hacerlo sin colocar otra credencial de larga duración entre el empleado y el recurso en la nube.

Si el despliegue tiene éxito, la federación de identidades se convierte en una capa habilitadora para la adopción de IA multicloud. Los líderes tecnológicos pueden elegir servicios de datos y modelos sin crear otro directorio de fuerza laboral para cada plataforma.

Si tiene dificultades, los problemas probablemente aparecerán en excepciones, asignaciones de políticas, limitaciones de los servicios y procedimientos de recuperación. Esos detalles determinan si la arquitectura funciona más allá de un caso de uso de BigQuery cuidadosamente seleccionado.

Para los desarrolladores, el resultado inmediato es más fácil de ver. Conservan su inicio de sesión corporativo establecido, mientras que los registros de auditoría pueden identificar sus acciones. Ya no necesitan tratar una clave compartida como el precio de acceder a datos en la nube.

Para los equipos de seguridad, el trabajo cambia en lugar de desaparecer. Gestionan relaciones de confianza, atributos de acceso, reglas de sesión, vías de emergencia e identidades de máquina. Esos controles están más centralizados, pero los errores pueden afectar a una población más amplia.

Para los compradores empresariales, la decisión de Best Buy ofrece una pregunta práctica de evaluación: ¿una plataforma en la nube acepta las identidades que ya gobiernan su fuerza laboral o exige otro almacén y proceso de ciclo de vida?

Best Buy ha elegido la primera vía para su expansión en Google Cloud. La arquitectura elimina una barrera conocida antes de que el uso de analítica e IA alcance a una fuerza laboral más amplia. Los próximos meses deberían revelar si la adopción, la calidad de la auditoría y los controles de identidad de máquina respaldan esa confianza.

Las organizaciones que consideren el mismo cambio deberían comenzar con su propia evidencia de acceso. Identifiquen dónde los humanos aún usan claves de cuentas de servicio, determinen qué servicios en la nube aceptan identidades federadas y midan con qué rapidez la revocación llega a las sesiones activas. La federación de Google Cloud se vuelve valiosa cuando esos resultados mejoran, no simplemente cuando cambia la pantalla de inicio de sesión.