Meet declarative device management

ハイライト

Apple は、既存の MDM プロトコルに宣言型デバイス管理を追加しました。これにより、iOS 15 および iPadOS 15 のユーザーはデバイスを登録して、ローカルでポリシーを決定し、構成を適用し、ステータス チャネルを通じてサーバーに変更をプロアクティブに報告できるようになります。

主要内容

大規模な組織が機器を管理する際に最も恐れることは、相次ぐ質問です。

デバイスのポリシーが変更されたため、サーバーはコマンドを送信する必要があります。デバイスが実行された後、サーバーはステータスのクエリを続けます。数千台のデバイスが一緒に更新されると、これらの往復リクエストがサーバー上に蓄積されます。デバイスがパスワード ポリシーを満たしているかどうかを知りたい管理者は、次のポーリング ラウンドを待つしかありません。

このセッションで Apple が出した答えは、Declarative Device Management です。サーバーは各操作をコマンドに分割して発行するのではなく、組織の必要なポリシーをステートメントに書き込んでデバイスに送信します。

デバイスはステートメントを取得した後、現在のステータスをローカルで判断します。ステータスが一致すると、ポリシーが適用されます。ステータスが変化した場合は再計算されます。サーバーはデバイスに問い合わせ続ける必要はなく、関心のあるステータス項目をサブスクライブするだけです。

この変更は 2 つの問題点に直接対処します。

まず、ポリシーの判断はデバイスに近いです。デバイスは、システムのバージョン、ハードウェア モデル、ステートメントが適用されているかどうかを認識しており、ステータスの変更を即座に処理できます。

次に、状況報告が積極的なプッシュになります。デバイスはステータス チャネルを通じてキーの変更を報告し、サーバーはサブスクリプションを受信して​​ステータスの変更を宣言するだけです。

Apple は、MDM ベンダーにプロトコルを置き換えることを要求しません。宣言機能は既存の MDM プロトコルに統合されており、登録、ログアウト、HTTP 送信、デバイス認証、ユーザー認証などの既存のメカニズムを引き続き使用します。

詳細

ステートメント: 組織のポリシーを JSON として記述します

(03:16) 宣言は、アカウント、設定、制限など、組織がデバイスに強制するポリシーを表します。その構造はプロファイル ペイロードに似ており、ネットワーク送信には plist の代わりに JSON オブジェクトが使用されます。

すべての宣言には次の 3 つの必須属性があります。Type、Identifier、ServerToken。Payload宣言された型に関連するデータを格納します。

{
  "Type": "passcode configuration",
  "Identifier": "4D2A0F90-1E1B-4B73-9B8D-8C4D6D1C0F11",
  "ServerToken": "revision-1",
  "Payload": {
    "Policy": "device passcode restrictions"
  }
}

キーポイント:

• Typeこのステートメントがどのポリシーを表すかを定義します。セッションでは例としてパスワード設定を使用します。
• Identifierデバイスが受信したすべてのクレームの中でこのクレームを一意に識別します (通常は UUID 文字列)。
• ServerTokenこの声明の改訂版を表します。Identifierのリビジョンごとに異なる値を使用します。
• Payload特定のポリシー データを保存するには、宣言タイプが異なればフィールドも異なります。

ステートメントは、構成、資産、アクティブ化、管理の 4 つのカテゴリに分類されます。これら 4 つのカテゴリを合わせて、デバイスでローカルに実行可能なポリシー モデルを形成します。

構成とリソース: パブリック ポリシーをユーザー データから分離する

(05:02) 構成はデバイスに適用されるポリシーを表し、既存の MDM プロファイル ペイロードに似ています。アカウント、設定、および制限はすべて構成ステートメントに含めることができます。

アセットは、構成のために参照する必要がある補助データを表します。デバイスが MDM サーバーまたはコンテンツ配信ネットワーク (CDN) からダウンロードできるように、大きなファイルを URL の背後に置くことができます。ユーザー名、電子メール、アカウントのパスワード、および証明書をリソース宣言に個別に生成することもできます。

{
  "Type": "user identity asset",
  "Identifier": "7B52C2F5-A5D8-46BC-9D31-8C02C4A69A22",
  "ServerToken": "revision-3",
  "Payload": {
    "FullName": "A Managed User",
    "EmailAddress": "[email protected]"
  }
}

キーポイント:

• Typeこれがユーザー ID リソースであり、セッションがそれを使用してユーザーの連絡先情報などのデータを記述することを示します。
• Identifier構成がこのリソースを参照できるようにします。
• ServerTokenリソースが更新されたかどうかをデバイスに通知します。
• Payload各ユーザーのカスタマイズされたデータが複数の構成にコピーされるのを避けるために、ユーザー関連のデータを保存します。

(06:41) リソースと構成には 1 対多の関係があります。ユーザー資格情報リソースは、複数のアカウント構成で参照できます。資格情報が更新されると、リソースのみが更新されます。それを参照する構成は変更されません。デバイスは、新しいリソースに基づいてポリシーを更新します。

アクティベーション: デバイスに一連の構成をアトミックに適用させます

(07:38) アクティベーションは、デバイスがアトミックに適用したい設定のセットを表します。デバイスは、グループ内の設定リソースと参照リソースが有効な場合にのみ、グループ ポリシー全体を適用します。いずれかの項目が無効である場合、アクティベーションは失敗します。

アクティベーションには述語を含めることもできます。デバイスはこれを使用して、アクティベーション状態がアクティブかどうかを判断します。セッションでは、iPad でのみ有効にする、または特定のシステム バージョンでのみ有効にするという 2 つの例を挙げました。

{
  "Type": "simple activation",
  "Identifier": "0DCC1890-93AA-4F99-81D5-0F7B2E056D5D",
  "ServerToken": "revision-1",
  "Payload": {
    "Configurations": [
      "4D2A0F90-1E1B-4B73-9B8D-8C4D6D1C0F11",
      "C4712A8E-03F5-4B28-A7F5-35805E4D2F07"
    ],
    "Predicate": "device type is iPad"
  }
}

キーポイント:

• Typeこれが単純なアクティブ化ステートメントであることを示します。
• Identifierこのアクティブ化ステートメントを識別します。
• Configurations一緒に適用される構成識別子を保存します。
• Predicateビジネス ルールをデバイスに分散すると、デバイスのステータスが変化した後に再評価されます。

(09:16) デバイスのステータスが変化すると、サーバーの介入なしでアクティベーション述語が再評価されます。新しいポリシーが適用され、期限切れのポリシーは削除されます。述語がない場合、デバイスは常にアクティベーションによって参照される構成を処理します。

ステータス チャネル: デバイスは変更を積極的に報告します。

(10:23) 宣言されたステータスとデバイスの実際のステータスが一致しない可能性があります。パスワード ポリシーは一般的なシナリオです。ポリシーは発行されましたが、ユーザーは要件を満たす新しいパスワードをまだ設定していません。

ステータス チャネルは、この可視性のギャップを埋めるために使用されます。サーバーは特定のステータス項目をサブスクライブし、デバイスは最初に初期レポートを送信し、次にサブスクリプション項目が変更された場合にのみ増分レポートを送信します。

{
  "Type": "status subscription configuration",
  "Identifier": "F2E64D28-4553-49E6-9380-8D7B50C4630A",
  "ServerToken": "revision-1",
  "Payload": {
    "StatusItems": [
      "device.operating-system.version",
      "device.model.family",
      "device.model.identifier"
    ]
  }
}

キーポイント:

• Typeこれがステータス サブスクリプション構成であることを示します。
• StatusItemsサーバーが気にする状態のキーパスをリストします。
• device.operating-system.version対応するデバイスのシステムバージョン。
• device.model.familyそしてdevice.model.identifier対応するデバイスの種類とモデル。

(11:44) ステータス レポートは増分です。デバイスを iOS 14.5 から iOS 15 にアップグレードした後は、システム バージョンの変更項目のみを報告する必要があります。適用されたかどうかを示す状態の変更は自動的に報告されるため、サーバーはサブスクライブする必要はありません。

スケーラビリティ: デバイスとサーバーが相互に機能を宣言します。

(12:48) 宣言型管理により、データ モデルに拡張性が組み込まれます。デバイスとサーバーはサポートされている機能を相互にリリースし、ハードコードされたシステム バージョンやサーバーへのハードウェアの依存関係を回避します。

サーバーの機能は、管理上の要求を通じてデバイスに送信されます。デバイスの機能はステータス項目を通じてサーバーに送信され、機能が変更されると再報告されます。

{
  "Type": "server capabilities management",
  "Identifier": "A414E797-2ED0-4E76-9B6A-7F634BA18474",
  "ServerToken": "revision-2",
  "Payload": {
    "SupportedFeatures": [
      "declarative management feature"
    ]
  }
}

キーポイント:

• Typeこれがサーバー機能管理ステートメントであることを示します。
• SupportedFeaturesサーバーがサポートするプロトコル機能を示します。
• サーバーがアップグレードされると、他のクレームと同様に、新しい機能がデバイスに同期されます。
• デバイスの機能の変更はステータス項目としてサーバーに報告されます。

(13:31) クライアントは、サポートされるクレームとステータス項目をリストした、サポートされるペイロードも公開します。サーバーはこの情報を取得すると、デバイスの新しい機能とペイロードをすぐに使用できるようになります。

MDM 統合: 既存のプロトコルの起動と同期

(14:17) 宣言型管理は既存の MDM プロトコルに統合されています。登録、ログアウト、HTTP 送信、デバイス認証、ユーザー認証には既存のメカニズムが引き続き使用されます。クレームおよびステータス チャネルは、既存の MDM コマンドおよびプロファイルと共存できます。

宣言型管理を開始するには、新しいものが必要ですDeclarativeManagementMDMコマンド。このコマンドには 2 つの機能があります。デバイス上で宣言型管理をアクティブ化します。同期トークンを保持し、必要に応じて同期プロセスを開始します。

{
  "Command": {
    "RequestType": "DeclarativeManagement",
    "SynchronizationTokens": {
      "DeclarationsToken": "server-token-value"
    }
  }
}

キーポイント:

• RequestType使用DeclarativeManagement、セッション内の新しい MDM コマンドに対応します。
• デバイスはコマンドを受信した後、宣言型管理をアクティブにします。
• アクティベーション後にオフにすることはできませんが、サーバーはすべてのステートメントを削除して、宣言的管理が実際のポリシー効果を生じないようにすることができます。
• SynchronizationTokens同期プロセスをトリガーするために使用できます。

(16:16) 新しいデバイスは、申し立てを同期し、ステータス レポートを送信するときに使用されます。DeclarativeManagement CheckIn request type。

{
  "MessageType": "DeclarativeManagement",
  "Endpoint": "declaration-items"
}

キーポイント:

• MessageTypeに設定DeclarativeManagement。
• Endpointに設定declaration-items、デバイスは宣言マニフェストを要求します。
• サーバーは、宣言されたすべてのマニフェストをリストして返します。IdentifierそしてServerToken。
• 新規または変更されたクレームの場合、デバイスは一意のリソース パスを使用して CheckIn リクエストを開始し、単一のクレーム JSON を取得します。

(17:22) 移行は段階的に行うことができます。 Apple は、プロファイルを構成としてインストールする宣言タイプを提供します。サーバーはまず URL を通じて既存のプロファイルをデバイスに渡し、宣言プロセスを使用してデバイスにプロファイルをインストールさせます。

{
  "Type": "profile configuration",
  "Identifier": "2B1B2C10-88D5-4F8B-A2D7-5F5F29D93F31",
  "ServerToken": "revision-1",
  "Payload": {
    "ProfileURL": "https://mdm.example.com/profiles/account.mobileconfig"
  }
}

キーポイント:

• Typeこれがプロファイル構成ステートメントであることを示します。
• ProfileURL既存のプロファイルをポイントします。
• この構成をアクティブ化すると、デバイスは URL からプロファイルを取得してインストールします。
• このアプローチにより、MDM ベンダーは、プロファイル ワークフロー全体を一度に書き直すことなく、最初にポリシー ロジックを移行できます。

iOS 15 のサポート範囲の最初のバッチ

(19:52) iOS 15 と iPadOS 15 は、宣言型管理を初めてサポートします。これは、iOS 15 の新しいオンボーディング フローと iOS 13 の既存のフローを含む、ユーザー登録タイプにのみ適用されます。

Platform: iOS 15, iPadOS 15
Enrollment: User Enrollment
Configurations: account, passcode, profile, status subscription
Activations: simple activation with optional predicate
Assets: user identity, user credential
Management: organization details, server capabilities
Status: declaration status, device hardware model, operating system

キーポイント:

• アカウントとパスワードの構成は、対応する MDM アカウントとパスコード プロファイル ペイロードをカバーします。
• プロファイル構成では、MDM でサポートされるプロファイルの完全なセットをインストールできます。
• ステータス サブスクリプション設定は、サーバーがどのステータス アイテムを受信したいかを宣言するために使用されます。
• 単純なアクティベーションは、構成リストをアトミックに適用し、述語をもたらすことができます。
• 各請求には独自のステータス項目があり、請求ステータスの変化は自動的に報告されます。

重要ポイント

1. 手順: MDM コンソールに「ステータス サブスクリプション テンプレート」を追加します。 実行する価値がある理由: ステータス チャネルを使用すると、サーバーは関心のあるステータス アイテムのみをサブスクライブできるため、ポーリングが減ります。 開始方法: まずステータス サブスクリプション構成を生成し、サブスクライブしますdevice.operating-system.version、device.model.family、device.model.identifier、デバイスの初期レポートと増分レポートをデバイスの詳細ページに書き込みます。

2. 対処方法: パスワード ポリシーを従来のプロファイルから宣言型構成に移行します。 実行する価値がある理由: パスワード ポリシーでは多くの場合ユーザーのアクションが必要であり、ステータスを宣言することでサーバーはポリシーが適用されているかどうかを知ることができます。 開始方法: パスワード ポリシーの構成宣言を生成し、単純なアクティブ化を使用してそれを参照し、対応する宣言ステータスの変更をリッスンします。

3. 対処方法: iPad および異なるシステム バージョンに異なるポリシー パッケージを設定します。 実行する価値がある理由: アクティベーション述語を使用すると、デバイスがポリシーが有効かどうかをローカルで判断できるようになり、サーバーは複数のステートメント セットを一度に発行できます。 開始方法: ポリシーを複数の構成に分割し、アクティブ化述語を使用してデバイス タイプまたはシステム バージョンの条件を表現します。

4. 作業内容: ユーザー ID と資格情報をアカウント構成から資産に分割します。 実行する価値がある理由: 資産は複数の構成で参照できます。ユーザー情報が更新されると、アセットのみが同期されます。 開始方法: ユーザー ID アセットとユーザー認証情報アセットを作成し、アカウント構成でそれらを識別子で参照できるようにします。

5. やるべきこと: まず、既存のプロファイルをプロファイル設定でラップします。 価値がある理由: プロファイル構成を使用すると、チームは既存のプロファイルを保持しながら、インストールとアクティベーションのプロセスを宣言型管理に移行できます。 開始方法: 既存のものを配置します.mobileconfigこれをサーバー URL に入力し、プロファイル構成を生成し、アクティブ化を使用してアクティブ化します。

関連セッション

• Apple デバイス管理の新機能 - 2021 年の Apple のデバイス管理機能の全体的な変更について説明します。
• 組織内のソフトウェア アップデートを管理する — 組織がシステム アップデート、延期ポリシー、および強制アップデートをどのように制御しているかを学びます。
• アカウント主導のユーザー登録について説明する — 宣言型管理による BYOD 導入の計画に適した iOS 15 ユーザー登録プロセスを理解します。
• アプリとブックの MDM 割り当てを改善する — アプリとブックを割り当てるときに組織で利用できる管理 API について学びます。