iOS 15で導入された宣言型デバイス管理では、宣言型データモデルパラダイムを使用します。このパラダイムにより、MDMにおけるコマンドのシリアル化やデバイスのポーリングに関連する、パフォーマンスと拡張性の一般的な問題がサーバで発生するのを回避できます。
宣言型管理は新しいパラダイムですが、新しいプロトコルではありません。このプロトコルは、採用をよりシンプルにするために既存のMDMプロトコルに追加されています。
宣言型管理データモデルには、デバイスの機能をサポートする「宣言」、デバイスの状態の変化をトラッキングするために使用される「ステータス」、デバイスとサーバが時間の経過とともに機能の変更を通知できるようにする「拡張性」の3つの主要コンポーネントがあります。
宣言は、サーバで定義するペイロードであり、宣言型管理プロトコルを使用してデバイスと同期されます。宣言は、組織がデバイスに適用するポリシーのほか、管理メタデータなどの項目を表します。
宣言はスキーマ駆動型データモデルであり、JSONオブジェクトとしてシリアル化されます。それぞれの宣言には、共通のキーセットがあり、それぞれのキーは必須です。
|
キー |
型 |
内容 |
|
|
文字列 |
宣言のタイプ。ドット区切りのトークンの並び。 |
|
|
文字列 |
デバイスに送信されるすべての宣言のセットに含まれる一意の識別子。通常はUUID文字列です。 |
|
|
文字列 |
宣言の一意のリビジョンを表す識別子。 |
|
|
辞書 |
宣言のデータに対応する部分。宣言のタイプのキーと値が含まれます。 |
Typeは宣言のタイプを定義します。標準的なタイプには、comプレフィックスが含まれます。プレフィックスに続く、タイプのコンポーネントは、activation、asset、configuration、またはmanagementのいずれかです。各宣言のタイプには、類似する項目をグループ化する独自の追加コンポーネントがあります。例えば、様々なタイプのアカウントを表す構成には、comプレフィックスが含まれます。
Identifierは、デバイスに送信されるすべての宣言のセットに含まれる1つの宣言を一意に識別します。通常はUUID値を取ります。サーバとデバイスの間で宣言を同期する時に、この値は、サーバから送信された宣言のセットと、デバイスが以前に受信した宣言のセットを一致させるための主キーとして使用されます。
Serverキーは、特定の宣言のリビジョンを表します。例えば、IdentifierをA、Serverを2に設定した宣言は、IdentifierをA、Serverを1に設定した宣言の更新です。このキーの値は、UUIDまたはシンプルなカウンタです。宣言のPayloadに含まれるいずれかの部分が変更された場合、同期が正しく行われるように、この値を更新します。
IdentifierとServerの組み合わせにより、デバイスは同期動作中に、どの宣言が新しいか、変更されたか、または削除されたかを判断できます。
Payloadキーは、宣言のタイプに関連するデータを表すオブジェクトです。正式なスキーマにより、各宣言のタイプに必要なデータとオプションデータを定義します。値には、文字列、数値、ブール値、配列、または辞書を使用できます。また、1から10までの数字などの範囲を指定したり、文字列を列挙して特定の値のセットに限定したりできます。
すべての宣言には、active状態とvalid状態が関連付けられています。デバイスはステータスチャネルを通じて、これらの状態をサーバと共有します。宣言には、「構成」、「アセット」、「アクティベーション」、「管理」の4つのタイプがあります。
構成はデバイスに適用されるポリシーを表します。例えば、アカウント、設定と制限、ネットワークの設定、フォントなどです。構成はMDMのプロファイルペイロードと似ています。
構成には、active状態があります。その値は、その構成で定義されたポリシーをデバイスが導入している場合はtrueとなり、それ以外の場合はfalseになります。
構成には、次の3つの値を取ることができるvalid状態があります。
valid：システムが構成をチェック済みで、構成が有効です。
invalid：システムが構成をチェック済みで、構成が有効ではありません。
unknown：システムが構成をチェックしていません。
構成は、次の条件を満たしている場合に有効になります。
構成がサーバから正常に同期された。
構成が、構成タイプで定義されたスキーマに従った有効なJSONオブジェクトである。
参照されているすべてのアセットが有効である。
構成がアクティブな場合、デバイスがポリシーを適用できる。
アセットは、構成に必要な付随的なデータを表します。アセットの主な使用例として、次の2つがあります。
サイズの大きなデータ：画像、フォント、フォントスイート全体などの大きなデータ項目。この場合、アセットのPayloadには、実際のデータを指すURL値を持つキーが含まれます。これにより、大きなデータ項目の配信を管理サーバから、そのようなトラフィックの処理により適したサーバ（例えば、コンテンツ配信ネットワーク）に移行できます。アセットのデータは、必要な場合にのみダウンロードされます。
個人のデータ：名前、メールアドレス、アカウントのパスワード、証明書など、ユーザー固有のデータ。この場合、構成からユーザーごとにカスタマイズされたデータが取り出され、より小さな専用のオブジェクトに移動されます。
アセットは構成と一対多数の関係にあります。つまり、1つのアセットが多数の構成から参照される場合があります。参照は、構成ペイロード内で特定のキーの形式を取り、その値はアセットのIdentifierキーの値となります。
アセットのデータは個別に更新でき、そのアセットを参照する構成を更新する必要はありません。システムは、多数の構成で共有される、ユーザーごとのデータまたは大きなデータ項目に対して、小規模な増分更新を行うことができます。
アセットには、active状態があります。その値は、少なくとも1つのアクティブな構成がアセットを参照する場合はtrueになり、それ以外の場合はfalseになります。
アセットには、次の3つの値を取ることができるvalid状態があります。
valid：システムがアセットをチェック済みで、アセットが有効です。
invalid：システムがアセットをチェック済みで、アセットが有効ではありません。
unknown：システムがアセットをチェックしていません。
アセットは、次の条件を満たしている場合に有効になります。
アセットがサーバから正常に同期された。
アセットが、アセットタイプで定義されたスキーマに従った有効なJSONオブジェクトである。
参照されるすべてのアセットデータは、アセットがアクティブであれば、正常にダウンロードされる。
アクティベーションは、構成で定義されたポリシーをシステムがデバイスに適用する方法とタイミングを決定するロジックを指定します。アクティベーションには、システムがデバイスにアトミックに適用する一連の構成が含まれています（つまり、システムは、参照されるすべての構成をまとめて適用するか、まったく適用しません）。したがって、システムがアクティベーションを適用するには、すべての構成と、それらの構成によって参照されるアセットが有効でなければなりません。
アクティベーションには、active状態があります。その値は、アクティベーションがその構成で定義されたポリシーの適用を試みる場合はtrueになり、それ以外の場合はfalseになります。
アクティベーションには、次の3つの値を取ることができるvalid状態があります。
valid：システムがアクティベーションをチェック済みで、アクティベーションが有効です。
invalid：システムがアクティベーションをチェック済みで、アクティベーションが有効ではありません。
unknown：システムがアクティベーションをチェックしていません。
アクティベーションは、次の条件を満たしている場合に有効になります。
アクティベーションがサーバから正常に同期された。
アクティベーションが、アクティベーションタイプで定義されたスキーマに従った有効なJSONオブジェクトである。
アクティベーションは構成と多対多の関係にあります。つまり、1つのアクティベーションで複数の構成を参照することも、複数のアクティベーションで同じ構成を参照することもできます。
構成を参照するアクティベーションが少なくとも1つアクティブになっている場合、システムは構成で定義されたポリシーを適用します。
アクティベーションには、システムが評価する式を定義する述語と、式を評価した結果を含めることができます。結果は、アクティベーションがアクティブか非アクティブかを判断するために使用されます。アクティブかどうかは、アクティベーションに関するその他の規則（前述したもの）で決まります。
述語は、Appleの「述語プログラミングガイド」に準拠した文字列です。述語の構文に従っていない文字列値はエラーとなり、アクティベーションはアクティブになりません。
述語式には、Appleのキー値プロトコルに準拠した、ステータス項目や管理プロパティなどの宣言型デバイス管理データへの参照を含めることができます（詳細については、「キー値コーディングについて」を参照してください）。参照先項目は、ほかの述語要素と正確に区別できるように、拡張要素内の述語に現れる必要があります。そうすることで、参照先項目は、通常は述語トークンでは許可されない文字を使用できるようになります。
@statusステータス項目全体を参照するために使用されるキー。
@keyステータス項目オブジェクトのプロパティを参照するために使用されるキー。
@property管理プロパティを参照するために使用されるキー。
以下は、デバイスがiPadかどうかをチェックする述語の例です。
(@status(device.model.family) == 'iPad')
管理宣言は、デバイスを管理している組織に関する情報や、サーバがサポートする機能の詳細などの管理メタデータを示します。
管理宣言には、active状態があります。その値は常にfalseであり、この状態はアクティベーションプロセスには含まれません。
管理宣言には、次の3つの値を取ることができるvalid状態があります。
valid：システムが管理宣言をチェック済みで、管理宣言が有効です。
invalid：システムが管理宣言をチェック済みで、管理宣言が有効ではありません。
unknown：システムが管理宣言をチェックしていません。
管理宣言は、次の条件を満たしている場合に有効になります。
管理宣言がサーバから正常に同期された。
管理宣言が、管理宣言のタイプで定義されたスキーマに従った有効なJSONオブジェクトである。
デバイスは、ステータスレポートを使用し、デバイスの状態の変化をJSONステータス項目としてサーバに報告します。デバイスの状態には、いくつかのカテゴリがあります。
管理状態 - デバイス上のすべての宣言のvalid状態とactive状態、および宣言が無効または非アクティブである理由を説明するエラーの詳細。
デバイスプロパティ - デバイスのプロパティ（デバイスのモデル、OSのバージョンなど）。
その他のプロパティ（アカウント、パスコード、およびMDMでインストールしたアプリ）。
ステータス項目には、ステータス名（「キーパス」に類似）と、関連付けられている値が含まれます。ステータス名は、トークンをドット区切りで並べた文字列（例：device.identifier.serial-number）です。名前の各セグメントは、総合的な階層ステータス辞書内のキーを定義します。
3つのステータス項目device、device、managementを考えてみます。デバイスから報告されるステータスは、次のようになります。
{
"device": {
"identifier": {
"serial-number": "abc123",
"udid": "d4bffb90be0845c6a8b8184a7e06d487"
}
},
"management": {
"push-token": "xyz789"
}
}
ステータス項目の値は、文字列、数値、ブール値、null、または配列です。
ステータス項目の配列は、適切に定義されたスキーマを使用したJSONオブジェクトを含んでいる値を取ります。配列内のすべての項目に同じスキーマを使用します。スキーマは、ステータスが表す項目のタイプに固有のものです。デバイスは、配列のステータス項目の変化を段階的に報告します（詳細については、「Status」を参照してください）。
ステータス項目に変化が生じた時に、その更新情報を受け取るには、サーバは、Management宣言をデバイスに渡すことによって、各ステータス項目にサブスクリプションする必要があります。すべての管理ステータス項目（management.名前プレフィックスで始まる項目）は自動的にサーバに報告されるので、ステータスサブスクリプションで参照される必要はありません。
デバイスのステータスが変化するか、ステータスサブスクリプション宣言がアクティブになると、デバイスはStatusをサーバに送信します。
宣言型管理によってサポートされる一連の機能は、時間が経過とともに、システムが項目を追加、変更、非推奨にすることにより、変化する可能性があります。デバイスとサーバは、機能を互いに通知するため、サーバとデバイスが別々にアップグレードされた場合でも、新しい動作を取り入れることができ、ロックステップ状態に維持する必要がありません。
デバイスは、そのデバイスがサポートする宣言のタイプとステータス項目のセットをStatusステータス項目を使用して通知します。デバイスが宣言型管理を有効にすると、デバイスは、このステータス項目をサーバに送信します。デバイスの種類やオペレーティングシステムのバージョン以外の要因によって、デバイスの一連の機能が異なる場合があるため、サーバは登録ごとにこのステータス項目を保持する必要があります。サーバは、サポート対象であることを通知していないデバイスに宣言を送信してはなりません。
サーバは、そのサーバがサポートする一連のプロトコル機能をManagement宣言を通じて通知します。サーバは、宣言型管理が有効になった時に、この宣言をデバイスに送信します。有効になったあと、サーバの機能が変更になるたびに、サーバは通常の宣言同期プロセスを使用して、デバイスを新しい値で更新する必要があります。