アカウント駆動型ユーザ登録

こんにちはTimm Hannonです ここAppleのCore OSの技術系管理者です このセッションでは 同僚のMelissaと一緒に MDMのユーザ登録 = Enrollment に ついて説明します

ユーザ登録は BYOD つまり個人所有デバイスの持ち込み 要するに組織ではなく ユーザがデバイスを所有する事を念頭に置いて 設計されています ユーザがデバイスを所有しているため ユーザ登録ではMDMソリューションによって デバイスに適用できる ペイロードや制限事項が 限られています ユーザ登録は iOS iPadOS macOSで使用できます

セキュリティとプライバシーは Appleの全ての活動の中核に位置しています ユーザ登録は この両方を組み込んだ 優れた デバイス管理オプションです このデザインのおかげでユーザはプライバシーや 個人情報の安全性が確保でき 一方で組織は データの安全性に自信を持つ事ができます

ユーザ登録の基礎を成す コアコンポーネントは３つあります

１つ目は管理対象Apple ID 管理対象Apple IDがあれば iCloudなどのサービスが利用できます

これは組織が所有管理するもので Apple Business Managerや Apple School Managerから 入手できます Azure Active Directoryとの 連携にも対応しているため ユーザは所属組織の既存の 資格情報を使用して認証を受ける事ができます

２つ目はデータの分離です

登録手続き時には異なる暗号鍵を使用した APFSボリュームが別に作成されます 管理対象Appと管理対象アカウントのデータは 私用コンテンツとは別に ここに保管されます デバイスの管理登録が解消されると ボリュームと暗号鍵は消去されます 最後に管理機能ですが この機能はデバイス上で組織のコンテンツを 管理するのにふさわしい適任者のみに 制限されています

ユーザがデバイスを所有し 使用しているため プライバシー保護は非常に重要です

ユーザ登録を使用すればユーザはデバイス上の 個人データの制御権を維持できます ユーザ登録では デバイスは 監視対象外と見なされます

MDMサーバで使用できる 管理機能を使えば 管理対象コンテンツは 全面的に管理できますが 個人データや設定へのアクセスは 制限されます 個人アカウントやAppの一意のデバイスＩＤ等への アクセスはMDMサーバでは 不可能です またデバイスのリモート消去など システム全体の操作も 行えません

今年はユーザ登録のアップデートに 全力で取り組んできました それをここで紹介できて嬉しいです 私は管理対象Apple IDと 管理対象Appを担当し Melissaがユーザ向けのオンボーディングフローに 関する変更事項や継続的にユーザ認証を 有効にする方法また使用開始方法等を 説明します

では管理対象IDから始めましょう iOS 15では「設定」からの管理対象 アカウントへのアクセスの操作性を改善しました ユーザ登録されたデバイスは 設定の最上部にアカウントが表示されます そこから詳細やiCloudの設定が確認できます これにより 追加アカウントの管理が各段に簡単になりました このようにデザインが一新された事で 組織のコンテンツが明確に分離されている事が 設定にも反映されています ユーザはシステムのどの部分が組織管理の対象で どの部分がそうでないかを判断できます

iOS 15とmacOS Montereyの新機能では 管理対象Apple IDがiCloud Driveに対応しました iCloud DriveはiCloudアカウントの重要な機能です ユーザ登録デバイスでもこれが使用可能になります

iOSとiPadOSでは 「ファイル」Appに新しい場所として表示され

macOSでは Finderに 追加の場所として表示されます 管理対象Apple IDのiCloud Driveを使う事で 組織は簡単に ユーザに 組込みのクラウド ストレージソリューションを提供できます

ドキュメントブラウザ ベースのAppでも追加のiCloud Driveが使用可能 iCloud Driveは当然管理対象Appとデータへの アクセスに対する Managed Open Inによる制限を尊重します

次は管理対象Appについて

macOS Big Surでは初めてmacOSで管理対象Appが 使用できる様になりました

これにより組織はカスタム構成ペイロード等の AppをiOSと同様の方法で管理対象デバイスに インストールする事ができます

またMDMコマンドを使ってデバイスの登録解除時等に Appを削除する事も可能です

macOS Montereyでは この機能性をユーザ登録にも 拡張しています

iOSと同様 Appデータは別のボリュームに分離されており 登録解除時やMDMコマンドを使う事で Appが削除されます Appが削除されると データコンテナも一緒に消去されます

CloudKitを使う管理対象 AppではMDMプロファイルに関連した 管理対象Apple IDが使用されます InstallAsManagedキーをInstallApplication コマンドに追加する必要があります 念のため申し上げますが 管理対象AppはAppフォルダに インストールする必要があり １つのAppバンドルのみを含めるようにしてください データ保護キーチェーンとAppのサンドボックス化を 採用して データが確実に 正しく分離されるように する事をお勧めします

またユーザ登録に関してすべての種類の 管理対象Appにいくつかの機能強化を 加えました まず管理対象オープンインの 制限機能が拡張され コピー＆ペーストが対象として追加されました これにより組織は管理対象の境界全体で データがペーストされるのを双方向から 管理できるようになります また デバイスが管理･登録 された時に必要なAppをインストールするように 指定する機能も追加されました デバイスが登録された時点でAppをインストールする 承認が下りるため 追加のユーザ確認が不要になります 管理対象ペーストボードと必要なAppの インストールに関する詳細については 「Appleデバイス管理に関する新機能」 をご確認下さい では Melissaに 登録と継続的なユーザ認証に ついて話してもらいましょう

Tim ありがとう 今回のユーザ登録機能の強化に伴い オンボーディングフローを 更新して よりユーザ主体の 体験を可能にしました iOS 13で導入されたオンボーディングでは 登録手続きを開始して 作業を進めるのに MDM登録プロファイルが必要です このプロファイルはユーザごとに管理者が 作成･配布していました iOS 15では ユーザと管理者双方の操作性を 簡素化するために 新しく作成したユーザ登録オンボーディングでは エントリポイント時点でユーザの組織ＩＤを 設定します ユーザはすでに所属組織の ＩＤにサインインしてメールやカレンダーなどの サービスを設定するのには慣れていますから 組織のＩＤを使用してiPhoneでMDMを 設定するのもすぐに慣れるでしょう このオンボーディングにより 新たにセキュリティ 機能が導入されました MDMプロファイルが ダウンロードされて 組織のデータがそこに送信される前に MDMサーバがユーザを確認できるように 登録フローにセキュリティ レイヤーが追加されました

このアカウントベースのフローを詳しく見てみます

ユーザ登録の オンボーディングフローには４つの要素があります サービス検出 ここではデバイスが組織のMDMサーバを認識します

ユーザ認証 これはMDMサーバがユーザを認証する方法です

セッション･トークンの発行 この方法で認証を継続的に行います

そして登録MDMペイロードを デバイスにインストールします それぞれの要素を詳しく見てみましょう

ユーザがオンボーディングフローを開始すると 組織ＩＤの入力を求められます

このＩＤは２つの部分から構成されており @記号で区切られています 最初の部分はユーザＩＤで ２つ目の部分は組織のドメイン またはサブドメインです ユーザが組織のＩＤを入力すると デバイスはその識別子のドメイン部分を そのドメインの既知の HTTPリソースを指すHTTPS URLに変換します

この検出先URLに 登録エンドポイントの場所をデバイスに知らせる MDMサーバの文書がホストされています

続いてデバイスはそのURLにGETリクエストを実行し JSON文書が返されて来るのを待ちます

受け取るJSONオブジェクトには サーバがサポートする登録のタイプを デバイスに知らせるバージョンキーと MDMサーバの登録エンドポイントのURLを 指定するbaseURLキーが含まれています

この情報によりデバイスは登録プロファイルを サーバからリクエストする準備ができます

デバイスは様々な デバイス属性と一緒にサーバ登録エンドポイントに プロパティ一覧をPOSTします

無線経由のプロファイル 配信プロセスになじみのある方はわかる通り これはデバイスがプロファイルサービス エンドポイントに行うのと同じリクエストです

ただ 主な違いは サーバが 登録プロファイルを渡す前に ユーザに自身の認証を 行うよう求める所です

方法としてはHTTP 401 Unauthorized応答を 発行して ユーザに資格情報の入力を求めます 登録を正常に完了するにはサーバはこの 認証チャレンジを発行する必要があります

重要なのは この401応答に デバイスが認証時に使う情報と一緒に WWW-Authenticateヘッダが含まれている事です このWWW-Authenticateヘッダは Bearer認証スキームと２つの追加パラメータを 使用します

methodパラメータはデバイスに どんな種類の認証が使われているかを知らせます この値は デバイスがユーザの認証に AuthenticationServices webサインインフローを 使用することを示します 現在 この値は固定値です

このmethodパラメータにはURLも含まれています

このキーの値は認証が行われる エンドポイントを指定する HTTPS URLです このURLはMDMサーバ自体の エンドポイントにすべきです この認証ヘッダを受信すると AuthenticationServices web サインインフローが開始 その仕組みを見てみましょう AuthenticationServices webサインインフローで 最初に表示されるコンテンツは 401応答のURLパラメータで指定された 認証エンドポイントに対する HTTP GETリクエストの結果となります

シンプルな例としてはこのWebサインインフローで ユーザがユーザ名と パスワードを入力するWebフォームを表示できます

もっと複雑なケースでは 企業のシングルサインオンを利用したり 第三機関のＩＤプロバイダにリダイレクトしたり 多要素認証を実施したりできます

デバイスと認証サービス間で複数回のやり取りを 行う事ができます AuthenticationServices webフローは ここで挙げたようにサーバがデバイスにHTTP リダイレクト応答を返すと完了します

この応答にはLocationヘッダと カスタム固定スキーム使用のURLが含まれています

このURLにはaccess-tokenパラメータも 含まれており その値は MDMサーバにリクエストを送る時にセッション トークンに使用する不透明なトークンです

セッショントークンを 入手したデバイスは元のHTTP POSTリクエストを 再発行して 登録プロファイルを取得します

今度のリクエストにはAuthorizationヘッダがあり セッショントークンが値として含まれています サーバはこのトークンを検証し 成功すると 登録プロファイルをデバイスに返します ユーザ登録プロファイルのMDMペイロードには新しい キーが２つ含まれています

最初のキーはAssignedManagedAppleIDキー これは企業ユーザに関連した 管理対象Apple IDです iCloudやiTunesアカウントに サインインするには登録フローの一環として この管理対象Apple IDを認証する事が 必要になります MDM登録が成功すると その管理対象Apple IDが デバイス上で有効である事が 保証されます 登録が失敗するのは AssignedManagedAppleIDキーがないか ユーザ認証が不成功だった場合です

２つ目の新しいキーはEnrollmentModeキーです これは登録がBYODタイプである事を示します デバイスはこの値が現在のモードと 一致しているかを確認し 一致しない場合やキーが存在しない場合は 登録は失敗します この両方の新しいキーでMDMペイロードを 更新する事をお忘れなく 登録プロファイルを受け取ると デバイスは必要な管理対象Apple ID アカウントを設定し MDMサーバに登録します サーバへの全リクエストにAuthorizationヘッダの セッショントークンが含まれる様になります では全部まとめて振り返ってみましょう まずユーザは再設計されたVPNから 「設定」の「デバイス管理」セクションに進み 仕事または学校サインインボタンをタップします 次に組織のＩＤを入力すると サービス検出ステップが開始されます ドメインから登録エンドポイントが 見つかると 認証サービスのWeb UIフローが開始します これは認証に使用するシンプルなWebフォームの 一例です ユーザは組織のパスワードを入力します 組織の認証が成功すると MDMプロファイルがこちらに手渡されます プロファイルからAssignedManagedAppleID キーを取得しユーザがパスワードを 入力する 次のサインイン 画面にあらかじめ入力しておきます この認証が成功すると ユーザは自分のデバイスが 管理できるようになります

デバイスのパスコードを入力し 暗号化された企業データパーティションを作成して MDM登録を許可します これでユーザの登録は正常に完了しました これがユーザ登録の新しいアカウント主体の オンボーディングフローです オンボーディングフローで サーバが登録データを送信する前に サーバが ユーザを認証する方法を確認しましたが iOS 15の新しいユーザ登録では 組織がいつでも ユーザを再認証できる機能を 導入しています これにより サーバとクライアント間の 接続の安全性が今まで以上に高まりました MDMサーバはクライアントからの 全リクエストで認証を確認し いつでもユーザにＩＤ資格情報の再認証を 求める事ができるようになりました この機能はセッション トークンを用いて実行されます

これはMDMクライアントが次のMDMコマンドを 取得するために サーバに確認を取っている例です Authorizationヘッダにはセッショントークンがある これは継続的な認証で使う２つの要素にとって 不可欠な存在です

最初の要素は永続的な認証で クライアントがサーバにリクエストするたびに セッショントークンが送信されます

２つ目の要素はセッショントークンの更新です これにより組織管理者はいつでもユーザに 再認証を求める事ができます

このセッショントークンのサーバサイド検証 ロジックを実装する事で 組織のセキュリティ規則を管理ソリューションに すぐに追加する事ができます

例えばユーザの資格情報を 定期的に認証して 機密性の高いペイロードが信頼できるユーザ所有の デバイスにのみ送信されるようにする事ができます

この仕組みを見てみましょう セッショントークンが無効になると 再認証が発動します

次回デバイスがMDMのHTTPリクエストを行うと HTTP PUTに含まれていた 無効なセッショントークンが サーバから401応答を引き起こします

サーバが送信する応答には オンボーディングフローの 最初の認証交換で見たのと同じWWW-Authenticate ヘッダが 含まれています

もちろんMDMプロセスはデバイスで バックグラウンドで実行されるため この再認証リクエストはユーザには NotificationCenter経由で表示されます

ユーザは通知をタップして 「設定」から再認証フローを 続けます

クライアントはオンボーディング時の様に 別のAuthenticationServices Webサインインを開始します

ユーザはAuthenticationServices webサインインフローの一環として シンプルなメカニズムか サーバとＩＤプロバイダの 統合によって決められたもっと複雑なメカニズムを 使って認証します

その認証サービスのWebフローが完了すると サーバは再びカスタムLocationヘッダを含む リダイレクト応答を送信し ここに新しいセッショントークンが含まれています

再認証が成功すると デバイスは最初に401応答を 受け取ったMDMリクエストを 直ちに繰り返しサーバからの処理なしで 前回の続きを 実行します 前回と同様 以降の全てのMDM HTTPリクエストには 新しいセッショントークンが含まれています 何らかの理由で ユーザの認証試行が失敗した場合 サーバがそのデバイスを信頼 しなくなる事があります

そのような場合サーバは機密性の高い MDMペイロードを全て 削除するか デバイス登録を 完全に解除する事ができます MDMからの登録解除に関してですが 継続的な認証ではHTTP 401 応答を利用するため プロファイルベースの登録と この新しいユーザ登録との 主な違いについて知っておく事が 重要です

iOS 15以前は MDM登録済みデバイスは全て サーバからの401応答を登録解除コマンドとして 扱っていました この新しいユーザ登録スタイルの実施に伴い 401応答では代わりに再認証がトリガされます

登録解除をトリガするには MDMプロファイルにRemoveProfileコマンドを 送信するという既存のメカニズムが 引き続き使えます これにより MDM登録が完全に解除され 管理対象アカウント管理対象データ データを分離した ボリューム等もデバイスから完全に削除されます

iOS 13のユーザ登録フローを含む プロファイルベースの登録の登録解除の 動作に関する 変更はありません

継続的な認証に関する簡単な説明は以上です では作業に取り掛かるための お手伝いとまとめをします iOS 15では新しいユーザ登録オンボーディングと 継続的な認証を今すぐ開始できます 次の５つの手順を必ず行って下さい 第１に企業ドメイン用に HTTPの既知のリソースファイルを 設定しパブリッシュします

第２にMDMサーバをＩＤプロバイダと統合し 登録時にユーザ認証を 行い 継続的な認証を利用して セキュリティ上の利点を 追加します

第３にApple School Manager またApple Business Managerで管理対象Apple IDを 作成するか 作成済みの管理対象Apple IDを 使用して サーバのMDMペイロードの AssignedManagedAppleIDキーに値を入力します

またMDMペイロードを更新して 新しい EnrollmentModeキーを含めます

最後に新しいiOS 15 Appleデバイス管理の文書を確認して 具体的な更新内容と 本日の説明内容の詳細をご覧下さい アカウントベースのユーザ登録を 開始するために 必要な事は以上です 盛り沢山の内容でしたので 復習しましょう 管理対象Apple IDにiCloud Driveサポートが 導入され 組織にも組込みクラウドストレージの オプションが追加されました ユーザ登録でmacOS上のAppも管理できます MDMソリューションで新しい オンボーディングフローの サポートを構築するか 新しいアカウント主体の オンボーディングサポートをMDMプロバイダに 呼びかけて ユーザ登録を簡単なものにして下さい

管理ワークフロー全体でアカウントに継続的な 認証を組み込んで下さい

iOS 15とmacOS Montereyから始まる これらの新機能を活用する事で 皆さんとそのユーザの両方で BYODワークフローを大幅に 改善する事ができます ありがとうございました WWDCを楽しんで下さい [音楽]