宣言的デバイス管理の進化

♪ ♪

こんにちは 「宣言的デバイス管理の進化」の セッションにようこそ 私はCyrus Dabooです Device Management Clientチームの エンジニアです 今日はみなさんに 宣言的デバイス管理の新機能について 説明していきます 宣言的デバイス管理は すべてのAppleデバイスを対象にした 新しいデバイス管理ソリューションです 自律的でプロアクティブな管理機能を提供し デバイスはサーバから促されずにも 管理ロジックを適用することができ 非同期の状況報告が サポートされているので サーバがデバイスにポーリングする 必要もなくなります

また MDMに内蔵されるため 既存のプロダクトとの 移行や統合が容易になります

WWDC22にAppleから 「将来のプロトコル機能の焦点は 宣言的デバイス管理になるだろう」 とお伝えしました それを受けて今回のリリースでは 新たなプロトコル機能の焦点が 宣言的デバイス管理になりました 今回のリリースでの注目すべき新機能は 宣言的デバイス管理を通してのみ 利用可能なものです その中には MDMに相応する 機能性を提供したり MDMからの移行に役立つ機能があります WWDC21で初めて導入され WWDC22では さらに多くの 基本的機能で強化された 宣言的デバイス管理は MDMデベロッパや企業管理者に その画期的な機能性から 非常に喜ばれてきました

宣言的デバイス管理の サポートを持つMDMサーバを 既に実装して出荷した MDMデベロッパも何人かいます 今リリースでの新機能で さらに多くのデベロッパが 強化された管理機能セットをカスタマーに 提供したいと思うでしょう

WWDC21とWWDC22のセッションを参照して 宣言的デバイス管理とは何か そして自分のプロダクトに どう採用するのか 詳しくご確認ください

プラットフォームサポートの アップデートを簡単に見てみましょう

MDMと宣言的デバイス管理は watchOSでも利用可能になりました

その詳細は「Meet device management for Apple Watch」でご覧ください

宣言的デバイス管理はApple内の 多くの異なるチーム間での コラボレーションの成果であり MDMデベロッパや企業管理者のために 堅固で安全なソリューションを 提供することを目標としています

私たちの焦点は常に ユーザーやそのデバイスのプライバシーと 安全性を保護する スムーズなユーザー体験の提供で それと同時に 企業データを保護し ポリシーの遵守を強制できるツールも 管理者に提供していきます

また MDMデベロッパや企業管理者との コラボレーションでもあります みなさんのフィードバックのおかげで 今リリースでお届けする 機能を優先することができました

宣言的デバイス管理の基盤要素が 既に備わった今 私たちの焦点は コアな管理機能の実装へと移っています 一体どういうものなのでしょうか まずは ソフトウェアアップデートを 強制する新しい方法です 2つ目は アプリの管理です

3つ目は システムサービスのロックダウンと バックグラウンドタスクの― モニタリングで デバイスの保護を行うことです

これには デバイスを使用するための 証明書やID認証情報の インストールが追って発生します 最後に MDMから宣言的デバイス管理への プロファイルの移行を簡単にする 新しい動作です

Appleのソフトウェア アップデートチームと共同で 宣言的デバイス管理で構築された macOSやiOSそしてiPadOSデバイスに 新たな管理対象ソフトウェア アップデート体験を提供します IT管理者は 要求された機能や修正の 実行を確実にするには 必ずユーザーのデバイスに 最新のシステムソフトウェア アップデートがインストールされて いることを確かめる必要があります 管理者はソフトウェアアップデートを 強制する必要がありますが 同時に 短期間だけアップデートの インストールを延期して 新しいOSリリースが 組織のアプリやサービスと互換性があるか 確かめる必要もあります デバイスのアップデートが要求されたら それが適切にアップデートされたか 検証する必要もあります 大量のデバイスの場合 これは時間のかかる仕事です そこで 管理者はMDMコマンドを使って 監視対象デバイスに アップデートがインストール できるようになりました サーバがデバイスにポーリングすれば アップデートの状態について フィードバックを受けることができます

また管理者は プロファイル経由で 大小規模のアップデートを延期し 監視対象デバイスが一定期間 ユーザーに対し ソフトウェアアップデートを促すのを 防ぐことができます ですが フィードバックから見ると 管理者とユーザー双方のために 管理対象ソフトウェア アップデート体験の改善が 望まれているようです

宣言的デバイス管理は アップデートプロセスにおける 管理者のコントロールを増大し よりわかりやすい体験をユーザーに 提供するメカニズムで 同時に アップデートがタイムリーに 実施されることを保証するものです こちらがその仕組みです

構成で ソフトウェアアップデートの 動作を定義できます デバイスは該当する指示を プロアクティブに実行し 同時にユーザーに アップデートプロセスを伝え 期限切れになる前に ユーザーが自分でアップデートを 行う機会を与えます

パワーで洗練されたロジックに Predicateを使って デバイスを シードやGMビルドに アップグレードする時か 早急なセキュリティ対応が 利用可能になった時に ソフトウェアアップデートの命令を 管理できます

非同期の状況報告が ソフトウェアアップデートフローの 最新状況を報告するので 問題が生じた際は 素早く解決できます どのように実装されるのかを 見てみましょう

特定の時間までに 監視対象デバイスの 強制ソフトウェアアップデートを 管理する構成が追加されました デバイスのソフトウェアアップデート フローに関して報告する 新しいステータスアイテムの セットもあり その中には インストール状況の詳細や あらゆる失敗の理由があります いくつか例を詳しく見ましょう

この例の構成では 特定のOSバージョンとビルドのための ソフトウェアアップデートを 特定の時間に行うよう強制しています TargetOSVersionキーはデバイスが アップデートするOSバージョンを示します

オプションのTargetBuildVersionキーで 特定のシードビルドを狙うこともできます 両方ある時はTargetBuildVersionが TargetOSVersionに優先されます 特定のバージョンの アップデートが見つからない場合は デバイスはソフトウェアアップデートサーバの デフォルトのアップデートを探します

TargetLocalDateTimeキーは アップデートが強制で行われる ローカルの日時を特定します

softwareupdateステータスアイテムの 状況報告の例がこちらです

install-reasonsステータスアイテムは なぜインストールが起こるかという 理由の記述の配列です ここにはアップデートを開始したのが 宣言なのかシステムなのか ユーザーなのか あるいはそのいずれかの 組み合わせなのかも含まれます pending-versionステータスアイテムは どのソフトウェアアップデートバージョンを システムがインストールしようと しているのかを示します install-stateステータスアイテムは アップデートに関して システムが現在どの状況に あるのかを示しています

failure-reasonステータスアイテムは あらゆるエラーのカウントと 最新のエラーの理由と タイムスタンプを特定しています ユーザーの視点からは これがどう見えるでしょうか

どのアップデートがいつまでに強制されるか ユーザーは明らかに識別できます

期限までにアップデートするか その夜にスケジュールするか 簡単に選べます

ユーザーが「Update Tonight」を選べば アップデートはダウンロードされ 準備が行われ デバイスの充電が十分で ある程度非アクティブの状態であれば その夜にアップデートされるよう 待機状態に入ります

ユーザーがすぐにアップデートを 始めない場合は ソフトウェアアップデートは期限まで毎日 Updates Availableの通知を出します macOSでは 通知が表示されると ユーザーは「Install」か 「Try Tonight」を選べます 期限の24時間前には この通知は一時間ごとに出され 「Do Not Disturb」を無視します 期限の一時間前には 通知は30分ごとになり そのあとは10分ごとです

では ユーザーは休暇に出ていて デバイスは電源がオフになっていたので 期限を過ぎてしまったとしましょう ユーザーがデバイスを再起動すると ソフトウェアアップデートが通知を出し アップデートの期限が 過ぎていることを知らせ そのあと1時間以内に アップデートを行おうとします

iOSとiPadOSでも同様の体験が起こります

ここでは管理者が iOS 17.0へのアップデートを強制していて 画面下のハイライトのように 表示されます ユーザーは簡単に「Update Now」か 「Update Tonight」を選べて macOS同様 期限前のアップデート インストールを確認しています

そして macOSの時と同様に リマインダー通知は ユーザーが自分から アップデートを開始しない場合 表示の頻度が上がっていきます 期限切れの時の動作も同じです

ソフトウェアアップデート宣言は MDMコマンドとプロファイルと共存できます

ですが 宣言によって強制された ソフトウェアアップデートは MDMコマンドとプロファイルに対して 常に優先されます

ソフトウェアアップデート構成と ステータスアイテムは macOSと iOSおよびiPadOSで利用可能です

今度はデバイス管理の もう1つの重要な側面に移りましょう アプリです

管理者は管理対象デバイスのアプリの ライセンスの付与や インストール アップデート 削除等の管理を求められます 問題が起きた時のサポートの提供や 組織の様々な役割を持つ別のユーザーに デバイスが割り当てられた時の デバイスの再プロビジョニングも 含まれます

MDMデベロッパは管理者に 様々なアプリ管理のツールを提供し MDMのアプリ関連コマンドを利用したり アプリのメタデータ検索に AppleサーバのAPIを使ったり ライセンスの付与を管理したりできます

MDMは命令的で ポーリングをしたがるため 問題が起こった時や ユーザーの役割が変わった時 あるいはユーザー間でデバイスを 使い回す必要がある時などに 管理者はなかなかタイムリーに 対応できないことが多くなります また デバイスの初期設定時や 変更を行なった時は ユーザーのデバイスは反応が遅くなります

宣言的デバイス管理なら 管理者はもっと効率良く アプリを管理できるようになり ユーザーにも より反応が良く さらに信頼できる体験を 提供できます どのようにできるか説明しましょう

構成を使って 必要な時にデバイスで利用可能な アプリを特定します 構成を予めデバイスに送っておけば デバイスがこれを必要とする状況が発生したら すぐに利用できます

デバイスステータス あるいは サーバによって設定された 管理プロパティに基づいて Predicateを使ってパワーロジックを行い どのユーザーに どのアプリのセットを 利用させるかコントロールできます ゆえに管理者は必要に応じて素早く アプリのセット間で切り替えできます

アプリはインストールせずとも ユーザーに提示できるので サーバの介入無しに いつインストールするのかを ユーザーが選べます これにより わずらわしい ユーザーの同意プロンプトも不要です 管理対象アプリへの最新の変更があれば 非同期の状況報告が 管理者に知らせるので 問題が起こっても素早く対応できます

これがどのように実装されるか 見てみましょう

個別のアプリのインストールや アップデートおよび削除を 管理するための構成が追加されました 管理対象アプリのリストに関して報告する 新しいステータスアイテムもあります アプリはApp Storeからでも MDMに似たマニフェストにより特定された 企業アプリでも構いません

macOSでは パッケージはサポート対象ですが 中身は単一アプリでなければなりません また アプリのインストールは オプショナルにしておいて ユーザーに開始させることができます いくつか例を見ていきましょう

この例にある管理対象アプリの構成は App StoreからPagesを インストールしようとします インストールの動作から アプリが必須であることがわかります これにより構成が有効になると ただちにアプリがインストールされ 管理されます このアプリは ユーザーには 削除することはできません

あるいは インストールの動作は 「Optional」に設定することもできます

この構成が有効になると ユーザーが選んだタイミングでアプリを ダウンロードできるようになります また ユーザーは好きなタイミングで アプリを削除できます

アプリごとのVPNなど コントロール管理の その他の属性も構成に含まれます

この例が示すのは インストールが完了したPagesの ステータスアイテムです

識別子キーがステータスオブジェクトの 固有の識別子で アプリのバンドルIDにセットされています declaration-identifierキーは アプリを管理している構成の 識別子です デバイスに変化が起こると ステータスは非同期で更新されるので ポーリングは不要です 今度は ユーザー体験の方に 目を向けてみましょう MDMデベロッパの多くが提供するアプリでは ユーザーに管理体験をコントロールできる オプションを与えています しばしば アプリのリストが表示され ユーザーにいつ何をインストールするか 選択肢を与えてくれます ユーザーはアプリをタップして インストールを開始できます これを実行するには アプリとMDMサーバの間に アプリのリストを伝えて アクションをユーザーから サーバに送り返す プライベートプロトコルが必要です そしてサーバはMDMコマンドを送り インストールが開始されます この一連のやり取りのために ユーザー体験に さらなる遅延が発生します この改善のために オプショナルアプリの インストールを単純で早いものにし 安全性も維持したいと思います

新しい ManagedAppDistribution フレームワークが サードパーティの管理アプリでも 利用可能になりました これの利用にはエンタイトルメントが 必要ですが App Storeへの提出の際に リクエストできます このフレームワークが含むSwiftUI View Extensionは 各管理対象アプリを カスタム可能なレイアウトに配置できる SwiftUIビューとして公開します ユーザーはアプリの詳細を見て タップしてインストールできます MDMサーバへの往復による遅延もなく アプリをただちにインストールできて 進行中にもより良い フィードバックが提供できるので ユーザー体験は改善されます みなさんが作成するようなアプリで どのようになるか見てみましょう

このスライドはiOSの MDM管理アプリを表示していて 新しいビューサービスを使って アプリのリストをユーザーに見せています

現在 アプリが一つインストールされています 一つはダウンロード中で その進捗状況を表示しています もう一つはオプショナルで インストール待ちです アプリのビューのスタイルは カスタマイズ可能で この場合は 標準のリストスタイルです

macOSでは さらに拡張的な レイアウトも使用可能で こちらのグリッドレイアウトのように 異なるスタイルのアプリビューが使えます

ビューサービスを使ったアプリは あらゆる方法でアプリのセットを 種類分けしてまとめられます 既にアプリのリストを表示する 管理アプリを持っている場合は このビューサービスは 代替策として利用可能で より素晴らしい体験を ユーザーに提供できます これから管理アプリを 提供しようと計画している方は このビューサービスで 有利なスタートを切れるでしょう

注意点ですが 新しい管理対象アプリ構成の オプショナルのインストール方法を 使うつもりであれば 組織の管理アプリをユーザーに 提供しなければなりません

管理アプリ構成およびステータスアイテムと パブリックフレームワークと View Extensionは macOSとiOSとiPadOSで利用可能です

追加として 管理アプリの体験を 向上させるための ゴールの一環として みなさんにお伝えしたいのが 新しい「Apps and Books for Organizations」サーバAPIで これは今すぐに利用可能です

これは 既存のcontentMetadataLookup サーバAPIに置き替わるものです

新しいAPIは 新たなカスタマイズや バージョニング機能の他に パフォーマンスの向上や 稼働時間を提供します 新しいAPIの使用に関する詳細は developer.apple.comのサイトをどうぞ それでは macOSシステムサービスや バックグラウンドタスクのための セキュリティ遵守の実施と確認における 宣言的デバイス管理の利点を見ましょう

多くの場合 サポートするデバイスが 必ず一貫した安全な方法で 動作するようことが管理者に要求されます 一貫性が確立している限り 大量のデバイスでも すべて同じように構成されていれば サポートするのは容易です 確実に遵守されていれば デバイスは基本的に保護されていて 組織のデータは安全だということが 保証されます

すべてのデバイスに 変更を加える必要がある場合や 新しいデバイスを追加する場合 スピーディで効率の良い方法で これらを行う必要があります

この要件の中には デバイスに インストールされたシステムや サードパーティサービスへの構成や モニタリングが含まれています

macOSは システム構成ファイル経由で コントロールされている 多くのシステムサービスと 一緒に出荷されます 例えばsshdは /etc/sshの辞書内の ファイル経由で構成されています

これらのシステムサービスの多くは 組織の要求する一貫性と遵守を 保証するために 管理者によって 安全に構成されなければなりません ゆえに ユーザーが故意に あるいはうっかりであっても これらのシステム構成を変更できない ようにしておくことが重要です

ですが その実現は困難です 多くの場合 ユーザーは システム構成ファイルを変更したり カスタム構成ファイルを使うために システムサービスを上書きしたりする ことができるからです

これに関して 宣言的デバイス管理は 安全で信頼のおけるメカニズムを提供し System Integrity Protectionによって 保護されたシステムサービスの 構成をサポートするのに最適で デバイスの一貫性や 安全性の遵守を保証するために バックグラウンドタスクを モニターする手段を提供します 詳しく見ましょう

宣言的デバイス管理の構成は 異なるシステムサービスのために 改ざん防止システム構成のセットを 特定するのに使えます ステータスはバックグラウンドタスクが 行われた場合のモニターに使えます Predicateはデバイスの状態から 誘発された 洗練された遵守ルールに 必要ならば 完全に自律的な方法で 機能を提供します その実行方法を見てみましょう

システムサービスの構成ファイル管理を サポートするために 宣言的デバイス管理の構成が 追加されました

構成はZIPアーカイブを提供する データアセットを参照します

構成が有効化されると アーカイブはダウンロードされ 改ざん防止された サービスに固有の ロケーションに拡張されます

このロケーションは 新しいライブラリ内の 関数を呼び出すことで プログラム的に見つかるため どのシステムサービスでも管理対象サービス 構成ファイルが採用できます

内臓のシステムサービスは 管理対象サービス構成ファイルを 探すために変更され これを デフォルトまたは上書きされた システム構成よりも常に優先して使います

サードパーティサービスも 管理対象サービス構成ファイルを 同様に採用できます 使用中のサードパーティサービスの デベロッパに連絡して 是非 この新機能を 採用してもらってください その仕組みを見てみましょう

この例の構成は sshdサービスのために 管理対象サービス構成ファイルを インストールしようとします

データアセットへの参照が含まれています

データアセットの例はこちらです

アセットタイプは新しいタイプで 任意データの伝達に使われます

もう一つ新しいのは アセットデータの 取得時に使われる認証のタイプを アセットが示すという方法です これにより アセットが保存される場所の 柔軟性が非常に大きくなり データに安全にアクセスするための 認証や認定の取得方法も柔軟になります

アセット内のデータURLが 示すロケーションは 参照している構成が有効化された時に ZIPアーカイブファイルが ダウンロードできる場所です

アーカイブは 改ざん防止された サービスに固有のロケーションで拡張され そこでアーカイブに sshdプロセスがアクセスし その管理対象サービス構成として使います

この機能を採用する最初の内蔵サービスは sshdと sudoと PAMと CUPSと Apache httpd そして最後に bashとzee shellsです

システムサービス構成を ロックダウンすることに加え 今リリースでは 新しいステータスアイテムも追加され インストールされたバックグラウンド タスクのリストを報告します

これにより管理者は 要求されたタスクが実行され 不要なタスクは実行されていないことを 素早く確認できます どんな風か見てみましょう

バックグラウンドタスクのための 状況配列アイテムが表示されています 詳細に含まれるのは タスクの固有識別子 タスクを実行している ユーザーアカウントのuid その状況 タスクのタイプ　これは daemonか agentか loginアイテムか アプリか あるいはユーザーアイテムのいずれかです 他には ラベルやプログラム引数などの launchdの詳細や サービスのロードに使われるlaunchd プロパティのchecksum hashもあります

さらに今リリースでは macOSのブートボリュームの FileVaultの有効な状態を報告する ステータスアイテムも追加されました ブーリアン値を戻してFileVaultが 有効化どうかを示し activation predicate内で 使いやすくて インストールが安全な場合のみに セキュリティ上機微な構成が インストール可能になります

管理対象サービス構成ファイルや バックグラウンドタスクや FileVault状況の報告を 組み合わせることで 管理者は 組織内のすべてのmacOSデバイスに 確実に一貫性と遵守があることを確かめる パワフルな方法を 得るのです では 宣言的デバイス管理における セキュリティ証明書と IDについて見ていきましょう

管理者は 内部及び外部ネットワークに 保存される組織のリソースへの 安全なアクセスを確立する必要があります

しばしばこのために デバイスに 証明書とIDの追加が要求され アプリサービスへのTLSや認証された アクセスを確立します

異なるアプリサービスが同じ証明書や IDを使うこともあり このような関係が管理できるというのは 重要なことです

また 証明書には有効期限があるので その更新には信用のおける方法が 必要になります

パスワード認証を安全なテクノロジーに 置き換えるのも望ましく 例えばパスキーは早くて使いやすく フィッシング耐性もあります 管理者が証明書やIDを管理するために 信頼できて効率の良い方法を MDMデベロッパが提供するのは 非常に重要なことなのです

MDMは既に プロファイル ペイロードを含んでいて それを使ってデバイスのキーチェーンに 証明書やIDを作成できます

また ACMEやSCEPのプロトコル経由で IDプロビジョニングをサポートしたり 証明書リストコマンド経由で 証明書の取得をサポートしたりします ですが MDMのできることには いくつかの制限があります

MDMの証明書やIDは 同プロファイル内で 1つ以上の他のペイロードよって 参照されることができます

ですが 他のプロファイルには 証明書やIDの参照は 許可されていません

つまり 同じアイテムを参照する 全てのペイロードを入れるために プロファイルのサイズを拡大するか あるいは証明書とIDが 複数のプロファイル間で 複製されなければなりませんが これを最新の状態に保つのは 余分な仕事が増えることになります

また 証明書かIDの更新が必要な場合 プロファイル内の他のすべての ペイロードも更新され ユーザー体験に問題を起こす 可能性があります

宣言的デバイス管理は 宣言的データモデルの利用により 証明書やID管理のための 効率的なメカニズムを提供します その仕組みです

証明書とIDはアセット宣言として 定義が可能であり 構成はそれらのアセットを参照できます

複数の構成が同一の証明書 あるいはIDを参照することができ 複数の証明書あるいはIDは 同一の構成により 参照されることができます

そして 証明書かIDが更新される 必要がある時に 更新されなければならないのは アセットだけです このアセットと構成の組み合わせで MDMプロファイルペイロードの 多くの制限が解決します

さらに 証明書やIDのステータスも 報告が可能であり ACMEやSCEPのIDが付与された場合は 簡単なフィードバックも提供でき ポーリングは不要です その実行の様子を見てみましょう

証明書あるいはIDデータを付与するために アセットのセットが追加されました

証明書は PEMかDERのデータ形式を使います

IDは PKCS #12形式を使うか ACMEかSCEPプロトコル経由で プロビジョンできます 利用可能な場合はハードウェアに 紐付けられたキーも これに含まれます

アセット経由でインストールされた 各証明書やIDの報告には 新しいステータスアイテムも利用可能です それでは 例を見てみましょう

この例にあるアセットは 証明書をインストールしようとしています

実際の証明書データを 証明書に送付するURLは 参照の詳細が付与します

別の例が示すのは ACMEサーバ経由でIDを プロビジョンするアセットです

この場合 参照の詳細が付与するURLは ACMEプロトコル交換に必要な プロパティを含む JSONドキュメントを送付します ACMEプロパティJSONドキュメントの 例はこちらです

ディレクトリURLがACMEサーバの URLを特定します どのタイプのキーが生成されたか 定義するプロパティのセットと 生成された証明書の プロパティのセットがあります

では ステータスを見ましょう この例は 2つの証明書で ステータス配列アイテムを表示しています 各アイテムに含まれるのは 関連アセットの識別子と DERエンコードされた証明書データと 証明書がIDと一致するかを見る インジケータです

これで証明書とIDの アセットが揃ったので 新しい構成と既存の構成で それが利用できます

まずは 2つの新しい構成を使って スタンドアロンの証明書とIDが インストールできます どちらも認証情報アセットを使って 実際の証明書 あるいは IDデータを提供します

証明書構成はキーチェーンに 単一の証明書をインストールします 証明書が自己署名証明書で 認証機関である場合は トラストストアにも追加されます

ID構成はキーチェーンに 単一のIDをインストールします

これらの構成はすべてのプラットフォームで 利用可能です

次は 企業パスキーの展開のための構成です

WWDC22では Webサイトやアプリでの パスワードの使用を無くすための ソリューションとして パスキーが紹介されました 今リリースでの焦点は 認定されたデバイスとユーザーのみが パスキーをプロビジョンできるのを 確認することによって 企業での展開を 容易にすることにあります

これをサポートするために 新しい企業パスキー認証構成があり デバイスのユーザーが 構成に特定されたサイトを閲覧する際に ユーザーへのパスキーを 安全に作成するために使えます

構成はIDアセットを参照します

そして 生成されたパスキーの 標準WebAuthn認証を行うのに IDが使われます WebAuthnのリライングパーティが この認証を確認し 関連サイトへのアクセスを許可します ゆえに 管理者は特定のパスキーを 管理対象デバイスのみに制限できます

この機能は macOSとiOSと iPadOSで利用可能です

MDMサーバとリライングパーティが どのように協力してこのワークフローを 実行するのかについての詳細は 「Deploy passkeys at work」の セッションでご覧ください 最後に MailとExchangeの アカウント構成がアップデートされ MDMプロファイルペイロードと 同等の機能をもたらす S/MIMEをサポートするようになりました

構成は S/MIMEの署名と暗号化の ために使えるIDアセットを 参照できるようになりました iOSとiPadOSで利用可能です

最後のアイテムとして MDMプロファイルから構成に 移行しやすくなる新しい動作について 見ていきましょう

宣言的デバイス管理が MDMに内蔵されいていて MDMと並行で使うことで 新たな管理機能が追加され 時間の経過とともにプロファイルを 移行できます MDMへの宣言的デバイス管理の実行は MDM DeclarativeManagementの コマンドをデバイスに送って デバイスで有効化された宣言の セットを同期するだけで簡単に行えます

これでサーバは 入ってくる ステータス報告を聞きます

この移行を簡単にするために レガシープロファイル構成が作成され そこで既存のMDMプロファイルが 構成として送られるため プロファイルは宣言的デバイス管理の 自律的でプロアクティブな 動作をフルに活用できる ようになりました

これには まず既存の MDMプロファイルを削除して その同じプロファイルをインストールする 構成を送って有効化します

これは厄介なプロセスで アカウントなどが全データの 更新を強いられたり デバイスからしばらくの間 制限がなくなるといった管理上の ギャップが生じたりします MDMデベロッパが 望んでいたのは レガシープロファイル構成への MDMプロファイルの使用からの 簡単な移行方法です 今 それが可能になりました 説明しましょう 宣言的デバイス管理は MDMプロファイルにインストール済みの 管理を削除せずに それを引き継げるようになりました そのためにサーバがすることは MDMによって既にインストールされたのと 同じプロファイルを含む構成を 送って有効化するだけです 宣言的デバイス管理システムは そのプロファイルの管理を引き継ぎますが その再インストールや アップデートは不要です この時点で 宣言的デバイス管理は プロファイルを所有しています MDMは変更を加えることはできません プロファイルが管理している デバイス状況が分裂することもありません 管理ギャップもありません MDMから宣言的デバイス管理への移行は これではるかに簡単になります

この新しい動作は すべてのプラットフォームで利用可能です

今回の宣言的デバイス管理の リリースで利用可能になった 新機能の最後のアイテムについては これで終了です では まとめましょう 基盤要素が装備された今 今回のリリースの焦点は 宣言的デバイス管理の力を使って 主要な管理機能を構築することです

これらの機能の多くは みなさんのフィードバックで要求された リクエストの結果であり みなさんに御礼申し上げます 宣言的デバイス管理が さらに向上を続ける中で みなさんにとって重要な機能を 優先して取り込むためにも さらなる フィードバックをお待ちしています

新しい管理機能が追加されたのは 宣言的デバイス管理だけなので まだ自分のプロダクトへの サポートを作成していない場合は 今すぐに作成することが重要です 既にサポートがある場合は 今リリースでの新機能で カスタマーに大歓迎されるような 素晴らしいプロダクトを作る チャンスが増えるでしょう

今リリースでの その他の新しい 管理機能についての情報は 「What’s new in managing Apple devices」のセッションをご覧ください 新しい機能やアセット及び ステータスアイテムのスキーマは Appleのオープンソース スキーマリポジトリで閲覧可能で セッションの参照情報の詳細に リンクが出ています

ご視聴ありがとうございました ♪ ♪