Best Buy、Google Cloud AIを拡大する一方で共有認証情報を廃止

Best Buyは、Google CloudにおけるAIと分析の利用を数万人規模へ拡大する準備として、認証情報に大きく依存したアクセスモデルを置き換えた。これまで一部のアクセスは、サービスアカウント、同期されたID、手動でローテーションするキーに依存していた。利用が拡大するにつれ、この構造を維持・正当化することは難しくなっていた。

同社は現在、Workforce Identity Federationを通じてMicrosoft Entra IDをGoogle Cloudへ直接接続している。この仕組みでは、アクセス時に開発者の既存の企業IDを検証する。Googleが全従業員レコードの同期コピーを維持する必要はない。

この変更はID管理のモダナイゼーションに見える。しかし、より大きな意味は、認証情報、管理作業、不明確な監査記録を増やさずに、Best BuyがクラウドベースのAIを拡大できるかどうかにある。従来の方法では、アクセスはチームがプロビジョニングし、維持するものとして扱われていた。新しい方法では、IDをリアルタイムの信頼関係として扱う。

この違いは、確立されたサービスアカウントモデルに圧力をかける。また、同期型クラウドディレクトリと直接IDフェデレーションの間で広がる競争も示している。Best Buyは、従業員が別プロバイダーのデータおよびAIサービスを利用する場合でも、MicrosoftのIDシステムを制御点として維持できると見込んでいる。

Best Buy、拡大を阻んでいた認証情報レイヤーを排除

Best Buyの直近の変更はシンプルだが重要だ。開発者は共有サービスアカウント認証情報の背後に隠れるのではなく、識別可能な従業員としてGoogle Cloudにアクセスするようになった。

Best Buyはこのプロジェクトを7月28日の発表で説明した。同社によると、分析とAIの活動拡大により、二つの関連する課題が生じた。認証情報のリスクを減らす一方で、数千人規模のバックエンドユーザーを同期する管理上の摩擦を回避する必要があった。

同社は歴史的に、バックエンドIDをMicrosoft Entra IDからGoogle Cloudへコピーする同期パイプラインを運用していた。Entra IDはBest Buyの既存の企業IDプロバイダーであり、従業員を認証し、エンタープライズのアクセスポリシーを適用する。

Best BuyはGoogle Workspaceを導入せずにCloud Identityを利用していた。この構成では、Microsoftで管理される従業員基盤と、拡大するクラウドリソース群との間を実用的に橋渡しする必要が、技術組織に生じていた。

Power BIからBigQueryへのアクセスは、従来の構成の限界を浮き彫りにした。BigQueryは、分析およびAIワークロード向けのGoogleのマネージドデータプラットフォームだ。Power BI経由で作業するユーザーは、以前は接続時にサービスアカウント認証情報へ依存していた。

サービスアカウントは、名前付きの従業員ではなく、アプリケーションまたはプロセスを表す。ソフトウェアワークロードには適している場合があるが、複数人が対話的アクセスのためにそのキーを使うと、説明責任が弱まる。

長期有効なキーはそれぞれ、誰かが発行、保管、追跡、ローテーションし、最終的に無効化しなければならない対象にもなる。Best Buyによると、セキュリティおよびプラットフォームチームは、各チームがどの認証情報を保有しているかを把握する必要があった。また、キーがチャットメッセージやその他の管理されていない場所に現れる可能性も考慮しなければならなかった。

これは単発の管理上の煩わしさではない。認証情報が一つ増えるごとに、そのライフサイクル全体で保護すべき経路が一つ増える。成長は経路の数と、一つを見失った場合の影響の双方を大きくする。

Best Buyの新アーキテクチャは、従業員のアクセスフローからこの中間キーを取り除く。開発者は既存のEntra IDでサインインする。Workforce Identity Federationが、MicrosoftのIDシステムとGoogleのリソース制御の間の信頼を仲介する。

開発者はPower BI経由でBigQueryにアクセスでき、直接API呼び出しも利用できる。Google Cloudは、共有サービスアカウントではなく個人IDの下でアクティビティを記録する。これにより、監査で誰がデータセットにアクセスしたか、あるいはリソースを変更したかが問われた際、セキュリティチームはより明確に答えられる。

Best Buyは、この設計が数万人のユーザーをサポートできるとしている。クラウドサービスが小売業務でより重要になる中、同社は現在、このモデルをより広範な従業員へ拡張している。

この拡張に関する主張には、なお慎重な検証が必要だ。Best Buyは、導入率、移行期間、インシデント削減、管理コスト削減を公表していない。ただし、このアーキテクチャ変更は、それらのユーザーが加わる前に明白な制約を一つ取り除く。

テクノロジーリーダーにとって、この順序は重要だ。Best Buyは、ID管理がさらに大きなボトルネックになるまで待たなかった。次の大規模なユーザーとワークロードの波を追加する前に、アクセスモデルを変更した。

Google Cloud AIがID負債を見過ごせなくした理由

AIの拡大がBest BuyのID負債を生んだわけではないが、その負債を抱え続けるコストを大幅に高めた。

高度な分析には、データ、開発環境、モデル、関連APIへの幅広いアクセスが必要となる。AIプロジェクトは、この環境にさらに多くのチーム、実験、自動化を加える。小規模なデータグループには機能する認証情報プロセスも、参加者がエンタープライズ規模に達すれば破綻し得る。

圧力はまずBest Buyのセキュリティチームとプラットフォームチームにかかる。機密性の高い小売データへの制御を失うことなく、開発者が迅速に作業できるようにしなければならない。また、誰が各操作を実行したかを示す証跡も維持する必要がある。

共有サービスアカウントは、これらの要件の間に緊張を生む。チームが一つの技術IDを受け取るため、初期接続を簡素化できる。しかし同じ近道が個人単位の帰属を弱め、保護し続けなければならない長期有効なシークレットを導入する。

ローテーションはこの問題をなくさない。問題を繰り返し発生する運用プロセスへ移すだけだ。チームは代替キーを配布し、依存ツールを更新し、古いコピーを削除し、本番ワークフローが引き続き機能することを確認しなければならない。

期限切れの認証情報は作業を中断させる可能性がある。漏えいした認証情報はリソースをさらす可能性がある。忘れられた認証情報は、元の業務上の必要性がなくなった後も利用可能なまま残る可能性がある。

Googleは、サービスアカウントキーには慎重な保護が必要なため、可能な場合はより安全な代替手段を選ぶよう組織に勧めている。同社のワークロードIDガイダンスでは、外部ソフトウェアワークロード向けの推奨モデルとしてフェデレーションを位置づけている。

Best Buyのユースケースはマシンワークロードではなく従業員IDに関するものだが、セキュリティの原則は似ている。長期有効なシークレットは、保管とローテーションに責任を移す。フェデレーションアクセスは、短期トークンと明示的な信頼関係に依存する。

データアクセスが中央クラウドチームの外へ広がるにつれ、この転換はより重要になる。アナリストは使い慣れたBIツールからBigQueryをクエリできる。開発者はAPIに直接アクセスできる。将来のAIアプリケーションは、同じ環境へ追加の運用チームを招き入れる可能性がある。

したがってIDレイヤーは、AIのキャパシティ計画の一部となる。新しいユーザーごとに並行レコード、手動管理の認証情報、監査プロセスにおける新たな例外が必要なら、計算能力や優れたモデルを増やしても効果は限られる。

Best Buyの決定は、Microsoft中心の従業員体験も維持する。従業員は、使い慣れた企業認証情報で引き続き認証を行う。同社は、これらのユーザーにとって二つ目のIDストアを日常的な唯一の情報源にする必要がない。

ここでGoogle Cloudにも独自の圧力がかかる。エンタープライズ顧客は、しばしば混在した技術環境を運用している。小売企業は、従業員IDやBIにはMicrosoftを使いながら、データ処理やAIにはGoogleを選ぶ場合がある。

クラウドプロバイダーは、AIワークロードを獲得すれば顧客のIDプロバイダーも置き換えられると想定できない。自らの認可および監査システムを弱めずに、外部IDを受け入れる必要がある。

Googleは、workforce federationをその橋渡しとして位置づけている。これは、プロバイダー間でID情報を交換するための二つの標準であるSAMLとOpenID Connectをサポートする。また、外部属性をリソースアクセスポリシーにマッピングすることもできる。

結果はシングルサインオン以上のものだ。シングルサインオンはログイン体験を身近なものにする。フェデレーションではさらに、信頼されたIDを、特定のリソースに対してGoogle Cloudが評価できる権限へ変換しなければならない。

Best Buyにとって実際の試金石は、このモデルがAI導入のペースに追随できるかどうかだ。新しいデータセット、プロジェクト、アプリケーションが追加されるたびに、新たな認可判断が生じる。フェデレーションは重複した認証情報を取り除くが、そうした判断を慎重に行う必要までなくすわけではない。

Google Cloudのフェデレーション、同期をリアルタイムの信頼に置き換える

中核となる仕組みはステートレスな検証だ。Googleは重複した従業員ディレクトリを維持するのではなく、アクセス時にEntra IDトークンを確認する。

Workforce Identity Federationは、Google Cloud組織と外部IDプロバイダーの間に信頼関係を構築する。Entra IDが従業員を認証し、Googleがその結果得られたトークンを評価して、アクセスポリシーが認識するIDへとクレームをマッピングする。

トークンは、ID情報と限定された有効期間を含む、署名付きのデジタルな表明だ。Googleはアクセス時点でその表明を検証する。Best Buyは、フェデレーションを利用する従業員全員について、Google側の同期ユーザーレコードを維持する必要がなくなった。

これがこのプロジェクトの重要な逆転だ。旧システムでは、IDを別の環境にコピーし、そのコピーを最新に保とうとしていた。新システムでは、人がアクセスを要求するたびに、権威あるプロバイダーへ証拠を求める。

同期には複数のタイミング上の問題が伴う。新入社員はアクセスを受け取るまでプロビジョニングサイクルを待つ可能性がある。役割変更がすぐには反映されないこともある。退職した従業員のコピーされたレコードは、別のシステムが削除するまで残り続ける可能性がある。

直接フェデレーションは、Entra IDが認証とユーザーライフサイクルの責任を引き続き担うため、こうした特定の隔たりを減らす。Best Buyがそこで従業員のアクセスを取り消せば、同社はGoogle Cloud内で別個の個人キーを探し出してローテーションする必要がない。

Googleは引き続き、自社プラットフォーム内の認可を管理する。認証はその人物が誰であるかに答える。認可は、GoogleがIDを受け入れた後に、その人物が何をできるかを決定する。

Best BuyはEntra IDの属性とグループをGoogle Cloudのアクセスルールにマッピングできる。このアプローチでは、接続ごとに別の認証情報を発行するのではなく、企業コンテキストに基づいたポリシーをサポートする。

同社はより有用な監査記録も得られる。共有サービスIDに帰属する操作ではなく、管理者はその操作を開始した従業員と結び付けられる。この違いは、調査、アクセスレビュー、コンプライアンス報告に役立つ。

ステートレスだからといって、設定が不要という意味ではない。Best BuyはIDプール、プロバイダー、属性マッピング、アクセスポリシーを確立しなければならなかった。workforce identity poolは外部IDをグループ化し、管理者がクラウドリソースへのアクセスを制御できるようにする。

この小売企業は、プロジェクトの運用上の複雑さを示す二つの実装上の選択も行った。プロビジョニングとシングルサインオンを、別々のEntra IDエンタープライズアプリケーションに分離した。これにより、一方の機能への変更がもう一方に予期せぬ影響を与えることを防ぐ。

Best Buyは、Entra IDのプロビジョニング用サービスアカウントも別の組織単位に配置し、その組織単位ではシングルサインオンを無効にした。この例外がなければ、シングルサインオンをグローバルに強制することで、プロビジョニングの設定に必要なアカウントまでブロックされる可能性があった。

このブートストラップ上の問題は見落としやすい。アイデンティティポリシーが、そのポリシーを支える環境を整備するために必要な自動化そのものを妨げることがある。Best Buyは自動化アイデンティティを分離することで、この循環を回避した。

開発者がこうした仕組みを目にする機会ははるかに少ない。Microsoftの認証情報で一度認証すれば、その後はPower BIまたは直接APIを利用する。このシステムの価値は、追加されたクラウド境界を日常業務のフローから隠せる点にもある。

ただし、この不可視性を制御の弱体化と捉えるべきではない。Googleのアクセス層は、フェデレーションされたプリンシパルがBigQueryや他の対応サービスを利用できるかどうかを引き続き判断する。Cloud監査ログには、そのプリンシパルに紐づけて個人の活動を記録できる。

この設計は、ユーザーアクセスとソフトウェアのアイデンティティも分けている。人間の開発者は、可能な限り本人としてアクセスすべきだ。アプリケーションや自動ワークロードには、依然としてそれぞれ独自のアイデンティティ、権限、ライフサイクル管理が必要となる。

この区別は、Best Buyがより多くのAIシステムを展開する中で重要になる。Power BIを通じてデータを照会する従業員と、APIを呼び出す自律プロセスは同じアクターではない。どちらにも説明責任を果たせるアイデンティティが必要だが、アクセスパターンと保護策は異なる。

従業員をフェデレーションすることは、このガバナンス課題の一部を解決する。自動アクセスがさらに拡大する前に、人間の責任を割り当てるための、より整った基盤を小売企業にもたらす。

本当の競争はフェデレーションと複製ディレクトリの間にある

Best Buyは重複したアイデンティティレコードではなく直接フェデレーションを選択したが、広範なクラウド市場では依然として両方のパターンが支持されている。

ディレクトリ同期は、権威あるシステムからユーザーとグループを宛先ディレクトリへコピーする。これにより、宛先側には各アイデンティティのローカル表現が作られる。ローカルレコードは割り当てやアプリケーション統合を簡素化するため、多くのエンタープライズプラットフォームがこのパターンを採用している。

弱点は、規模の拡大時や変更時に現れる。コピーはソースと整合し続けなければならない。プロビジョニングの遅延、更新失敗、変更された属性、古いアカウントは、AIアプリケーションの事業価値とほとんど関係のない作業を生み出す。

Best Buyはすでに、この管理上の摩擦を経験していた。同社の技術チームは、バックエンドのアイデンティティをEntra IDからGoogle Cloudへ移すパイプラインを維持していた。新たなモデルでは、フェデレーションユーザー向けにCloud Identityでそれらのレコードを維持する必要がない。

直接フェデレーションは依存関係を移し替える。同期パイプラインに依存する代わりに、アクセスはEntra ID、トークン交換、プロバイダー設定、Googleの検証経路に依存する。

これは複雑さの解消ではない。複雑さをどこに置くかという判断だ。Best Buyは、数千件の複製アイデンティティや従業員向けサービスアカウントキーよりも、リアルタイムの信頼境界を選好している。

他のクラウドプロバイダーも関連するトレードオフを提示している。AWSは人間のアクセスにフェデレーションを推奨しているが、IAM Identity Centerのドキュメントでは、通常、管理者が割り当てを行う前に外部ユーザーとグループをプロビジョニングする必要があるとしている。

AWSはSAMLを通じてMicrosoft Entra IDに接続でき、プロビジョニングはSystem for Cross-Domain Identity Managementが担う。その外部アイデンティティモデルでは、従業員は企業の認証情報を利用できるが、IAM Identity Center内には同期されたユーザーおよびグループの情報が保持される。

これはBest BuyのGoogle実装との有用な対比になる。どちらのアプローチも、すべての従業員に恒久的なクラウドネイティブのパスワードを与えることを避ける。ただし、クラウドプラットフォームがどの程度のアイデンティティ状態を維持するかは異なる。

Microsoftは、マシンアイデンティティにも同じくシークレット削減の原則を適用している。そのフェデレーション認証情報に関するガイダンスでは、外部ワークロード向けにクライアントシークレットではなくフェデレーションまたは証明書を推奨している。

これらの例は、実装が異なっても業界の方向性は一貫していることを示している。クラウドプロバイダーは一時的なフェデレーション認証情報をますます推奨している。一方で、プロビジョニング、ローカルディレクトリ、属性マッピング、サービス対応範囲については、依然として異なる選択をしている。

エンタープライズの購買担当者にとって重要な比較は、どのプロバイダーがフェデレーション機能を提供しているかではない。主要プロバイダーはすべて複数の形態でこれを提供している。重要なのは、アイデンティティ状態がどのように移動するか、ポリシーがどこに存在するか、依存関係に障害が発生した場合に何が起きるかという点だ。

同期されたディレクトリは、一部の外部障害時にもローカルのユーザー情報を保持できる。その一方で、古い情報を残すこともある。ステートレスなフェデレーション設計はこうしたコピーを避けるが、認証時にはソースプロバイダーにより直接的に依存する。

どちらのアーキテクチャでも、緊急アクセスの必要性はなくならない。アイデンティティプロバイダーの利用不可、フェデレーション設定の破損、誤ったポリシー変更に関わるインシデントに備え、管理者には厳格に管理された経路が依然として必要だ。

したがって、Best Buyの事例はGoogleがMicrosoftに勝ったという話ではない。Microsoftは引き続き、小売企業の従業員を認証する権威である。Googleは別のユーザーストアを要求せずにその権威を受け入れることで、より使いやすくなる。

この構成は、大規模組織が実際にどのように技術を購入しているかを反映している。クラウド、アイデンティティ、分析、生産性サービスを複数ベンダーから組み合わせている。1社のプロバイダーにあらゆる層の所有を求めるアクセス設計は、移行作業と抵抗を生む。

Microsoftで管理される従業員が、別の日常的なアイデンティティを採用せずにBigQueryへアクセスできれば、Googleにとって利益となる。Microsoftは従業員ライフサイクルにおける位置を維持する。Best Buyは、チームが統制すべき認証情報の数を減らす。

サービスアカウントは、記名された人間のアクセスを代替するという不適切な役割を失う。この物語における主な対抗対象は、別のクラウドベンダーではなく、これである。

開発者にとって、この境界は運用ドキュメントも改善する。インシデント記録に担当者、プロジェクト、影響を受けたリソースが記載されていれば、チームはより有用な技術ナレッジベースを構築できる。共有アイデンティティでは、その履歴の解釈が難しくなる。

キーが減っても自動的に安全になるわけではない

フェデレーションは認証情報管理上の危険を取り除くが、その信頼設定は、Best Buyが継続的に検証すべき高価値のコントロールプレーンとなる。

GoogleとBest Buyは、新モデルがキーに関連する攻撃対象領域を縮小すると説明している。この主張はアーキテクチャ上の観点では妥当だ。存在しない認証情報は、ノートPCからコピーされたり、チャットに貼り付けられたり、リポジトリに置き忘れられたりしない。

ただし、公表されたケーススタディは、セキュリティインシデントが測定可能な形で減少したことを示してはいない。公開されたキー、不正リクエスト、監査失敗、復旧時間について、導入前後の件数は示されていない。

この記事は、すでに移行済みのユーザー数も明らかにしていない。アーキテクチャは数万人を対象とし、Best Buyはより広い従業員層へアクセスを拡大していると述べている。これらは能力と方向性を示すものであり、導入完了を示すものではない。

フェデレーションでは、トークン検証とポリシーマッピングに注目が集約される。管理者が過度に広範なクレームを信頼したり、オーディエンスを誤設定したり、グループを誤ってマッピングしたりすれば、有効な従業員に意図以上のアクセス権が与えられる可能性がある。

属性ベースのアクセスは、ポリシーが従業員の属性に従うため、管理作業を減らせる。ただし、そのリスクは属性の品質へ分散される。Entra IDでグループメンバーシップを誤れば、Google Cloudで認可エラーになる可能性がある。

そのためセキュリティチームは、この関係の両側を検証しなければならない。Entra IDが想定どおりのクレームを発行していることを保証する必要がある。同時に、Googleがそれらのクレームを意図どおりに正確に解釈していることも保証する必要がある。

最小権限は引き続き不可欠だ。この原則では、各アイデンティティに業務に必要な権限だけを与える。フェデレーションだけで適切な権限レベルが決まるわけではない。

Best Buyは、従業員と自動ワークロードも分離しなければならない。同社は、説明されている開発者アクセスフローからサービスアカウントキーを排除した。すべてのアプリケーションやバックエンドプロセスからサービスアカウントがなくなったとは主張していない。

AIシステムはこの境界を複雑にする。開発者が実験を開始する一方で、スケジュールされたパイプラインやエージェントは、その人のアクティブなセッションなしに動作を続ける。こうしたプロセスには、狭い権限と追跡可能な所有者を持つマシンアイデンティティが必要だ。

Googleのドキュメントは、フェデレーションアイデンティティをサポートする製品を列挙し、サービス固有の制限事項を記載している。Best Buyは、この設計を小売事業に関わるすべてのクラウドサービスへ拡大する前に、互換性を確認する必要がある。

可用性には別のトレードオフがある。フェデレーションログインは、Entra ID、ネットワーク接続、Googleのトークン交換、正しいプロバイダー設定など、複数の正常に機能するコンポーネントに依存する。

この連鎖に障害が起きると、新しいセッションが妨げられる可能性がある。組織には、厳格に制限された緊急アカウント、または別の復旧メカニズムが必要だ。こうした例外は通常のアイデンティティ経路の外側にあるため、特に厳しい監視が求められる。

セッションの挙動も精査に値する。ソースディレクトリで人物を無効化すれば将来の認証はブロックされるはずだが、既存のトークンやセッションは設定された有効期間が終わるまで利用可能な場合がある。セッションを短くすれば露出を減らせるが、より頻繁な更新が必要になる。

アクションに記名されたアイデンティティが含まれる場合、監査可能性は向上する。しかしログが役立つのは、チームがそれを保持し、監視し、調査する場合に限られる。Best Buyには、通常の分析活動と、異常なエクスポート、権限変更、アクセスパターンを区別するアラートが依然として必要だ。

AIのデータアクセスには、ガバナンス上の問題もある。アイデンティティは、どの従業員がデータセットへ到達したかを証明できる。だが、そのデータセットが特定のモデル、プロンプト、実験に適切だったかどうかは判断できない。

データ分類、モデルガバナンス、プライバシー管理は、依然として別個の責務である。フェデレーションは施行の説明責任を高めるが、根本となるルールを作り出すものではない。

このケーススタディはGoogle CloudとBest Buyのクラウドエンジニアリング責任者によるものだ。独立したセキュリティ評価ではなく、公式の顧客事例として読むべきである。

したがって、最も確かな結論はマーケティングメッセージより限定的だ。Best Buyは、重要なアクセスパターンの1つから、長期間有効な共有認証情報を排除した。これにより、同社のセキュリティ組織が管理すべきシークレットは減り、ユーザーの帰属も明確になる。

この結果がフルスケールでも統制を維持できるかは、アクセスレビュー、ポリシーの品質、サービス対応範囲、インシデント対応の実績に左右される。これらの成果は、まだ公開されていない。

モデルが拡張可能かどうかを示す3つのシグナル

次の試験は運用上の証拠だ。より広範な導入において、個人の説明責任を保ちつつ、別の場所で管理負担を再構築しないことが求められる。

最初のシグナルは、意図されたBest Buyの従業員のうち、アクティブなクラウドアクセスにフェデレーションを利用している割合である。同社はアーキテクチャを拡張していると述べているが、移行スケジュールや完了指標は示していない。

例外が限られた広範な展開であれば、小売規模におけるステートレスな従業員アイデンティティの有効性を強めることになる。サービスアカウントによる例外が増え続けるなら、ツール互換性またはワークフロー設計が依然として制約となっていることを示唆する。

有用な指標は、単に登録ユーザー数ではない。Best Buyは、依然として長期有効な認証情報に依存しているインタラクティブな接続がどれだけあるかを確認すべきだ。また、新入社員、異動者、退職者に適切なアクセス権がどれだけ迅速に付与・変更・削除されるかも追跡する必要がある。

2つ目のシグナルは、認可と監査の成果の質だ。記名アクセスにより、曖昧なログ記録が減り、調査が迅速化するはずだ。Best Buyは、こうした改善が実現したかを示す証拠を公開していない。

セキュリティチームは、誤った属性マッピング、想定外の権限、トークン交換の失敗、雇用状況の変更後も残るアクセスに注意を払うべきだ。手動でのキー・ローテーション作業が減少すれば、フェデレーションが運用上の負債を単に移し替えるのではなく、解消したことの裏付けとなる。

認可エラーの増加は、この展開が掲げる中心的な約束を弱める。その結果は、アイデンティティ同期が、同じように難しいポリシー保守に置き換わったことを示している可能性がある。

3つ目のシグナルは、小売企業が人間以外のAIアクセスをどのように扱うかだ。ワークフォース・フェデレーションは従業員やその他の人間のユーザーを対象とする。AIエージェント、パイプライン、ノートブック、スケジュール済みジョブには、引き続き固有のマシン・アイデンティティが必要となる。

成熟した拡張では、こうしたマシン・アイデンティティを従業員とは分離しつつ、それぞれを所有者、目的、権限範囲に結び付ける。自動化システムに無人アクセスが必要という理由だけで、ダウンロード可能なキーへ戻ることは避けるべきだ。

ここに、Best Buyのプロジェクトが他の企業に影響を与え得る理由がある。重要な先例は、従業員がシングルサインオンを利用できることではない。企業は長年にわたり、その体験を提供してきた。

先例となるのは、企業が既存のMicrosoftのアイデンティティ認証基盤を維持しながら、Googleのプラットフォーム上で分析とAIを拡張できることだ。従業員とクラウドリソースの間に、別の長期有効な認証情報を置くことなく実現できる。

この展開が成功すれば、アイデンティティ・フェデレーションはマルチクラウドAI導入を可能にするレイヤーとなる。テクノロジーリーダーは、プラットフォームごとに別のワークフォース・ディレクトリを作成することなく、データサービスやモデルサービスを選択できる。

苦戦する場合、問題は例外処理、ポリシーマッピング、サービスの制約、復旧手順に現れる可能性が高い。こうした詳細が、慎重に選定されたBigQueryのユースケースを超えて、このアーキテクチャが機能するかを左右する。

開発者にとって、当面の結果はより分かりやすい。従来の企業ログインを使い続けながら、監査記録では自らの操作を特定できる。クラウドデータへアクセスするための代償として、共有キーを扱う必要はなくなる。

セキュリティチームにとって、作業はなくなるのではなく変化する。信頼関係、アクセス属性、セッションルール、緊急時の経路、マシン・アイデンティティを管理することになる。これらの制御はより一元化されるが、誤りはより広い範囲の利用者に影響を及ぼし得る。

企業の購入担当者にとって、Best Buyの決定は実用的な評価の問いを提示している。クラウドプラットフォームは、すでに自社の従業員を管理しているアイデンティティを受け入れるのか、それとも別のストアとライフサイクル管理プロセスを要求するのか。

Best Buyは、Google Cloud拡張において前者の道を選んだ。このアーキテクチャは、分析とAIの利用がより大規模な従業員層へ広がる前に、既知の障壁を取り除く。今後数か月で、導入状況、監査の質、マシン・アイデンティティの管理が、その確信を裏付けるかが明らかになるはずだ。

同じ移行を検討する組織は、自らのアクセスに関する証拠から始めるべきだ。人間が依然としてサービスアカウントキーを使用している場所を特定し、どのクラウドサービスがフェデレーションされたアイデンティティを受け入れるかを確認し、失効処理がアクティブなセッションに到達するまでの速さを測定する。Google Cloudのフェデレーションは、ログイン画面が変わっただけでなく、こうした結果が改善したときに価値を持つ。