はじめに
こんにちは！入社3週目、新人PMおじさんのkenkenです。
先週の主なお仕事は「知らない3文字英語をひたすら調べて理解する」でした。
あとは、なぜか社内ドライブに入っていた「ゼロトラストについてとてもよくわかる本」の発売前原稿を読み込んでいました。
テーマ：Google Workspace構成でAutopilotを使ったゼロタッチデプロイは出来るのか
結論としては「極めて難しい」です。
Google Workspace（GWS）自体は使えるのですが、メインの認証基盤（IdP）としEntra IDをサービスプロバイダ（SP）にする構成ではAutopilotは利用できません。
別のIdPをメインにして、GWSをSPとした構成を取る必要があります。
ではここからは、なぜGWSをメインにできないのか、その詳細な原因と対策を書いていきます。
そもそも：GWSをメインIdPとしてゼロタッチデプロイをしたい、とは？
「ゼロタッチデプロイ」ってご存知ですか？（知らなかったのは私だけですか？）
特にビジネスシーンにおけるPCの管理において、初期設定やソフトウェアのインストールなど、「利用開始時に発生するキッティング作業の自動化」を指しています。
管理者の手作業が不要で、ユーザーの手元に届いて初めて適切な構成が適用されるため、ミスを防ぎ環境に依存せずに組織のポリシーに準拠したデバイスを即座に利用できるため、利便性とセキュリティが両立している比較的新しい手法です。
ゼロタッチデプロイは、ゼロトラストの概念においてデバイス管理のリスクである「キッティング時のセキュリティリスクを排除する」の排除に利用されます。
当社へのご相談では、Microsoft社の提供する「Windows Autopilot」を利用した実現のご希望が多くあります。
また、Google Workspace（以下「GWS」）は、Google社の提供する「ビジネス向けクラウド型グループウェア」として多くの企業で導入されていますが、その中の「Cloud Identity」機能を用いて、GWS（G Suite）アカウントの認証情報をシングルサインオン（SSO）のアカウント管理及び認証基盤（IdP）として利用できます。
シングルサインオンと他要素認証をはじめとした先進認証を組み合わせた仕組みは、ゼロトラストの概念におけるセキュアな認証を実現するための重要な要素となります。
今回のケースでは、Cloud IdentityでGWSを「Googleアカウントを利用したIdP基盤」としてメインに置く構成において、Autopilotを利用してオートキッティングを実現したいケースを取り上げています。
前提：Autopilotを利用するにはEntra IDへのデバイス登録が必要
Autopilotを利用するにあたっては、アカウント管理基盤としてMicrosoft社の提供するEntra IDを利用する必要があり、同時にデバイス管理にIntuneを利用する必要があります。
Entra ID：Microsoft社の提供するクラウド形式のID管理基盤（IDaaS）
Intune：Microsoft社の提供するモバイルデバイス管理（MDM）システム
Autopilotでは、以下のいずれかの方法でEntra IDにデバイスを登録する必要があります。
- Entra Join：Entra ID のみで管理できるクラウド主体の登録形式
- Entra Hybrid Join：オンプレミスのActive DirectlyとEntra IDで管理できるハイブリットな登録形式
どちらの方法を利用するかは、利用するアカウントの種類や利用したい機能によって異なりますが、特に今回のケースでは「GWSのIdPをメイン基盤とする」がゴールのため、以下の流れが理想となります。
Entra IDへアクセス
→ユーザーがGoogleアカウントを利用した認証を実施
→GWSで認証され、Entra IDアカウントと連携
→同時に「Entra Join」でデバイス登録
本題：なぜGWS構成でAutopilotが使えないのか
理由：GWSがメインIdPの場合はEntra Joinが使えない！
実は、GWSをメインIdPとした構成の場合はEntra Joinを使えないのです！
原因は「Entra Joinを利用するための条件を満たしていない」ためです。
・Entra Joinを利用するための条件
SSO環境でEntra Joinを利用するためには、そのIdPがEntraの指定するプロトコル（WS-Trust と Ws-Fed の両方）に対応している必要があります。
もしこのプロトコルに対応したIdPを利用していれば、前述の理想の流れで利用しているデバイスをEntra IDに登録すると同時にIntuneに登録できるため、その後Autopilotにてオートキッティングの実施が可能となります。
・GWSのは必要なプロトコルに対応していない
しかし、GWSがメインIdPとなる場合はこのどちらのプロトコルも対応していませんので、Entra Joinは利用できず、同時にAutopilotも利用できません。
もちろん、何らかの構成でこの問題をクリアできる可能性もないわけではありませんが、少なくとも最適な構成を考えた場合は実装が難しいため「極めて難しい」が結論となります。
対策：Entra Joinに対応したIdPをメインに置き換える
それでもAutopilotを使う必要があれば、「メインIdPの見直し」が対策となります。
例えば別のIDaaS（OktaやEntra ID）を導入し、GWSをその配下にSPとおいて利用すると、現在の構成を可能な限り維持したままAutopilotでゼロタッチデプロイを実現できます。
もちろん、Autopilotの利用が必要かも状況に応じて異なります。ゼロタッチデプロイを何で実施するか、どこまで実施したいかを再検討して、Autopilot以外の手法を選ぶ選択肢もあります。
そもそもGWSのアプリに細かいアクセス権限をしたいため、GWSをメインIdPとした構成が必須である場合も十分想定できます。
何を変えたくて、どのようなリスクがあるかを正確に把握してリスクの優先順位を決め、対策を検討する。
それも踏まえて業務全体の流れを把握して何を導入して何を実行していくか、これがゼロトラストの概念に基づくセキュリティ構成の構築に大きく関わる、といったような内容が先日読んだ本にも書いてありました。
リスクの優先順位の検討にはトレードオフを伴うため、セキュリティと利便性のどっちがいいのかを決める必要がありますが、組織ごと、役職/役割ごと、業務フェーズごとに様々な視点があってとても難しいかと思います。
「やりたいこと」と「やるべきこと」の切り分けが難しい時は、誰かに相談してみるのもいいかもしれませんね！
おわりに
私のエントリーでは、こういう「よくあるお困りポイント」をお伝えしていこうと思います。
ゼロトラストの導入を検討されている方、組織として方針だけ決まってしまってどうやったらいいかお困りの方、これから進めていこうと頑張っている方のお役に立てれば幸いです。
