宣言型デバイス管理について

♪

宣言型デバイス管理の実現 Enterprise & Education Technologies チームの ソフトウェアエンジニア Melissa Nierleです Appleでは 企業パートナーや教育機関が チームメンバーや学生をつなぐために 必要なツールを提供するために 最高のデバイス管理機能の開発に 常に取り組んでいます これらの管理機能を支えるのは MDMプロトコルです このプロトコルは iOS macOS tvOSの中でも 直接提供されている定評があり 多様されている ソリューションで モバイルデバイス管理の標準となっています 毎年 機能を追加する一方で デバイス管理の目標に照らして プロトコルを評価し MDMソリューションの 開発者 管理者 ユーザーの ダイナミックなニーズに合わせて 進化させています 今日 私たちのMDMプロトコルは 命令型と反応型のプロトコルと言えます 各管理ワークフローには時間がかかり デバイスとサーバー間で複数の ラウンドトリップが発生します また 組織全体で多数のデバイスを管理する場合 パフォーマンスの問題は 更に深刻になります これは プロトコルが可能な限りパフォーマンスと スケーラビリティを確保したい例です また 最適なプロトコルの パフォーマンスとスケーラビリティ を実現するために 私たちはMDM プロトコル自体を再構築しました 未来のデバイス管理は宣言型管理です 宣言型管理とはデバイスにポリシー管理をもたらす プロトコルの変革的なアップデートです 宣言型管理ではデバイスが自律的かつ 積極的に 行動できるようになり サーバーは軽量で反応性が高く 常にポーリングすることなく 更新情報を受信可能になりました 自律的なデバイスは自身の状態の変化に反応し サーバーからの指示なしに 管理ロジックを適用します 一方 プロアクティブなデバイスは 重要な状態変化が発生したときに 非同期的にサーバーに報告する ステータスチャンネルを持っており サーバーがデバイスを ポーリングする必要がありません デバイスが自律的かつプロアクティブになることは 宣言型管理の基本であり パフォーマンスとスケーラビリティ の向上につながります そして何よりこれは新しいパラダイムですが 新しいプロトコルではありません この新しい宣言型機能を iOSデバイスから始まる 既存のMDMプロトコルにそのまま組み込んでいます ここでは この新しい宣言型パラダイムを支える データモデルについて深く掘り下げて説明します その後 MDMとの統合について説明します 具体的な例を挙げて どのように始めればよいかを学びます まずは宣言型データモデルについて説明します 宣言型データモデルには3つの支柱があります サーバーが定義してデバイスに 送信するペイロードである「宣言」 「ステータスチャンネル 」これは デバイスがそれ自体に関する 新しい情報をサーバーに積極的に更新するための 新しい通信チャンネルです そして「拡張性」 Appleが宣言型管理に新機能を導入した際に デバイスとサーバーがシームレスに 対応できるようにします この3つの支柱を理解することで 宣言型管理をMDMソリューションに 取り入れる準備ができます まず 宣言について説明します 宣言とは アカウント 設定 制限など 組織がデバイスに適用したい ポリシーを表すものです 宣言は すべてのユーザーに共通するポリシーと 1人のユーザーやデバイスに固有のポリシーの両方を 作成することができます 宣言の構成を見てみましょう 宣言のデータ表現はプロファイルと似ており 宣言はキーのセットと 値の標準的な型を備えた ディクショナリでもあります ただし 宣言は ネットワークで 送信されるときにはリストではなく JSONオブジェクトとしてシリアライズされます すべての宣言には3つの必須プロパティがあります 型 識別子 サーバートークンです 型は 設定がどのポリシーを表すかを定義します 識別子キーはデバイスに送信された すべての宣言のセットの中で 宣言を一意に識別する値を持ちます 通常 これは文字列で表されるUUIDです デバイスはサーバーと宣言を同期する際に この値が使用されます ServerTokenキーは 識別子キーに基づいて 宣言の ユニークな改訂を表します このキーは宣言をサーバーと同期する際にも 使用されます 値は 改訂ごとに異なる文字列です この例のように 単純なカウンターや UUID文字列である 可能性もあります ペイロードは宣言のデータ固有の部分で 宣言の種類に応じた キーと値を含みます プロファイルのペイロードと同様に キーには必須のものと オプションのものがあります 値は 文字列 数値 ブーリアン 配列 またはディクショナリで 1から10までの数字のように範囲が制限されていたり 文字列列挙のように特定の値のセット 制限されていることがあります 宣言には コンフィグレーション アセット アクティベーション マネジメントの4つのタイプがあります 宣言の最初のタイプはコンフィグレーションです コンフィグレーションは アカウント 設定 制限など デバイスに適用されるポリシーを表します コンフィグレーションは MDMの プロファイルペイロードに似ています ここでは デバイスのパスコードに制限を適用する コンフィグレーション宣言の例を示します すべての宣言に必要な標準キー （型 識別子ServerToken）が 存在しています 型の値はこの宣言が パスコード設定型であることを示しています ペイロードキーには設定のための パスコードポリシーデータが 含まれます 次のタイプは アセットです アセットはコンフィグレーションに必要な 補助的なデータへの参照を表します これは 大容量データの 共有アイテムである場合もあれば パーソナライズされたものである場合もあります 大容量データの場合アセット宣言には デバイスがサーバーから実際のアセットデータを 取得するために使用するURLが含まれています このサーバーはMDMサーバーの場合もあれば 別のコンテンツ配信ネットワーク サーバーの場合もあります 別のコンテンツ配信ネットワーク からアセットを配信することで 大きなネットワーク帯域幅をサポートする負担を それに適したサービスに移すことができます アセットは名前 Eメールアドレス アカウントのパスワード証明書など ユーザー固有のデータを 表すために使用することもできます これにより ユーザーごとに カスタマイズされたデータを コンフィグレーションから外し より小さな専用のアセットタイプの 宣言に移すことができます アセットはコンフィグレーションと 1対多の関係にあります 例えば1つのクレデンシャルアセットを 複数のアカウント設定から参照することができるため 各アカウント設定に同じユーザー情報を 複製する必要がありません また ユーザーのクレデンシャルを 更新する必要がある場合 そのアセットのみを更新する必要があります そのアセットを参照している 全てのコンフィグレーションは変更されず デバイスはそれに応じてポリシーを更新します このように 一度に多くの コンフィグレーションに対して 増分的な更新を行うことができれば デバイス管理システムの全体的な 応答性を向上させることができます それでは アセット宣言の コンフィグレーションを見ましょう ここでは ユーザーの連絡先である ユーザーアイデンティティを定義する アセット宣言の例を示します 必要とされる3つの標準キーが存在し 型の値がこれを ユーザーIDのアセット宣言として定義しています ペイロードキーにはこのアセットの ユーザーIDプロパティが含まれています 宣言の次のタイプはアクティベーションです アクティベーションは デバイスが アトミックに適用する コンフィグレーションのセットを表します つまり セット内のすべての設定と 参照されているアセットが 全て適用されるためには有効でなければなりません 無効なものがあればアクティベーションは 関連するポリシーの適用に失敗します ここに 2つのコンフィグレーションを含む シンプルなアクティベーションの例があります 3つの必要な宣言キーが存在し ペイロードにはアクティベーション によってアトミックに適用される コンフィグレーションのセットが含まれています コンフィグレーションはその 識別子キーによって参照されます アクティベーションと コンフィグレーションの間には 多対多の関係が存在します アクティベーションは 複数の コンフィグレーションを 参照することができコンフィグレーションは 複数のアクティベーションが参照することができます この多対多の関係により 複雑なビジネスロジックを デバイスが自律的に処理できるようになります アクティベーションに デバイス上でアクティベーション 状態が有効か無効かを決定する 述語を含めることができます デバイスは 述語が真と評価された場合にのみ アクティベーションが参照する構成を処理します 例えば ある述語は 特定のアクティベーションが iPadなどの特定のデバイスタイプでのみ 有効であることを宣言することができます その他の例としては特定のバージョンのOSにのみ 適用されるポリシーを設定することができます これにより サーバーはあらゆるデバイスに対する すべての宣言を送信し デバイス自体がどの宣言を 適用するかを決定することができ デバイスの自律性がさらに高まります デバイスの状態が変化するとサーバーの介入なしに アクティベーション述語が再評価されます 新しいデバイスの状態に関連した ポリシーが適用され 古くなったポリシーは削除されます ここでは デバイスは ますますプロアクティブになります 述語がない場合 デバイスは常に アクティベーションで参照される コンフィグレーションを処理します 先ほどのアクティベーションの例ですが ここでは述語があり このアクティベーションは デバイスがiPadの場合にのみ ポリシーを適用すべきであることを 示しています 宣言の最後のタイプはマネジメント宣言です マネジメント宣言は 全体的な管理状態をデバイスに 伝えるために使用されます これには 組織の詳細を記述した宣言と サーバーの機能を記述した宣言が 含まれています これらの宣言は デバイスに静的な情報を伝えるのに役立ちます 以上 デバイスに組織のポリシーを適用するための 4種類の宣言をご紹介しました 新しい宣言型管理データモデルの 2本目の支柱は ステータスチャンネルです 宣言の仕組みを考えると 宣言されたデバイスの状態はある時点での 実際のデバイスの状態とは 一致しない可能性があります 例えばユーザーの操作を必要とする宣言は その操作が行われるまで適用されません 例えば パスコードポリシーでは ユーザーがデバイスに ポリシーに準拠した新しいパスコードを 作成するためにアクションを 起こさなければなりません このデバイスの状態遷移に可視性を持たせるために ステータスチャンネルを作成しました デバイスの状態の更新はステータスレポートとして サーバーに送信されます サーバーは 特定のステータス 項目をサブスクライブでき 気になる変化のアップデートだけを 受け取ることができます ステータス項目は 期間で区切られた文字列トークンで 構成されるキーパスによって識別されます ステータス項目は 先程のアクティベーション述語の 例で示したように アクティベーション述語の式として 使用することができます サーバーはステータス サブスクリプション構成を使用して 特定のステータス項目をサブスクライブします この構成を受け取ると デバイスはサブスクライブされた ステータス項目の初期ステータスレポートを送信し サブスクライブされた項目が 変更された場合にはレポートを送信します ステータスレポートはインクリメンタルなので 変更された項目のみがレポートされます 宣言のステータスは それが適用されているかどうかに関わらず 変更されると常にサーバーに報告され サーバーがサブスクライブする必要はありません 特定のステータス項目の更新を サブスクライブする構成を見てみましょう この構成ではデバイスのOSバージョン タイプ モデルを表す3つのステータス項目を サブスクライブします この構成がデバイス上でアクティブになると 新たにサブスクライブしたステータス項目ごとに 最初のステータスレポートが送信されます ステータス項目は 対応するキーパスの 段階的なコンポーネントによって ネストされたJSONオブジェクトとして表されます この場合 デバイスはiOS 14.5上にあると報告します ユーザーがソフトウェアを最新の iOSバージョンに更新すると デバイスはオペレーティングシステムの バージョン項目のステータス変更を報告します これでサーバーはデバイスがiOS 15に アップグレードされたことを検出します 宣言型データモデルの3つ目の支柱は 「拡張性」です Apple製品のライフサイクルが長いことを考えると 特にソフトウェアのアップデートや 新しいハードウェアモデルのリリースに合わせて MDMソリューションの異なるバージョンと Appleデバイスとの間の 互換性を維持することが不可欠です 宣言型管理ではデバイスとサーバーの両方が サポートされている機能を互いに アドバタイズします ソフトウェアのバージョンや ハードウェアの依存性を ハードコーディングすることなく それぞれが新機能の 利用開始時期を知ることができます サーバーとクライアントの双方が アドバタイズする機能には プロトコルのマイナーアップデート とメジャーアップデートの 両方に対応するサポート機能の リストが含まれています クライアントはサポートされている ペイロードをアドバタイズします このペイロードには クライアント がサポートしている宣言と ステータス項目の全セットが記載されています サーバーの機能は管理宣言を介して デバイスに送信されます サーバーがアップグレードされると 他のタイプの宣言と同様に 新機能がすべてデバイスに同期されます デバイスはすぐに サーバーの新機能を利用することができます クライアントの能力はそれが変更されるたびに 特定のステータス項目として サーバーに送信されます これにより サーバーはデバイスの新しい機能やペイロードを すぐに利用することができます 宣言型データモデルに拡張性を持たせることで 宣言型管理は 現在および将来の宣言型管理が確実に構築されます データモデルを理解した後は MDMプロトコルに宣言型管理機能がどのように シームレスに統合されているかを見ていきましょう 既存のMDMベンダーは今日から宣言型管理機能を 使用することができます 宣言型管理は MDMプロトコルに統合されており 登録・解除プロセスの管理や HTTPトランスポート デバイスとユーザーの 承認の処理に利用されています 既存の成熟したMDM製品は 新しいプロトコルや サーバーインフラを採用するような 破壊的な変更を行うことなく宣言型管理に スムーズに移行することができます 宣言とステータスチャンネルは 既に使用されているMDMのコマンドやプロファイルと 拡張可能な方法で共存します これによりすべてのMDMワーク フローを一度に更新することなく 宣言型管理のさまざまな機能を 徐々に採用することができます 例えば サーバーはステータス サブスクリプションのみを 実装することを選択でき 宣言型管理のすべてを採用することなく MDMプロトコルにステータス チャンネルを効果的に追加できます デバイスがMDMから解除されると すべての宣言が削除され それに応じて デバイスの状態が調整されます 重要なのは 宣言型管理が 既存のMDMの動作に全く影響を与えないことです 実際には 宣言型管理はアクティベーションのための MDMコマンドと 同期および ステータスレポートのための MDMチェックイン要求を使用して 既存のMDM動作を活用します 次にそれぞれを拡大して見てみましょう MDMにはDeclarativeManagement コマンドが追加されています このコマンドには2つの目的があります まず デバイスの宣言型管理機能を 有効にします 一度オンにした宣言型管理を オフにすることはできませんのでご注意ください しかし サーバーはすべての宣言を削除して 宣言型管理を効果的に無効にすることができます 次に コマンドには 必要に応じて 同期フローを開始するための同期トークンを含む ペイロードを含めることができます また デバイスが宣言を同期する際や サーバーにステータスレポートを 送信する際に使用される 新しい宣言型管理チェックイン リクエストタイプもあります これは 新しいCheckInリクエストタイプの例です MessageTypeキーには新しい DeclarativeManagementの値が設定されています endpointキーには クライアントがサーバーから 宣言マニフェストデータを 取得するリクエストを行っている ことを示す値が設定されています 今回のステータスレポートのように base64EncodedDataを含むリクエストもあります 宣言を同期させるためにチェックインリクエストを 使用するとサーバーからの応答があります 応答には サーバーが定義した すべての宣言の識別子と サーバートークンのプロパティを 列挙したマニフェストと デバイスが適用するための単一の宣言の 2種類があります 宣言型管理を有効にし 宣言をチェックインリクエストと 同期させる方法を学んだところで ポリシーをプロファイルから 宣言に徐々に移行させる 方法について説明します 宣言タイプにはプロファイルを構成として 送信およびインストールするための 特別なタイプがあります これにより MDMプロファイルの フルスイートを利用して プロファイルベースの ポリシーロジックをデバイスに 移行することで 宣言型管理を すぐに活用することができます ここでは プロファイルの設定例をご紹介します プロファイルはURLで参照されます この構成が有効になると プロファイルがURLから取得され デバイスにインストールされます iOS 15のベータ版では宣言型管理を簡単に 導入できるように このような ステップを踏んでいます それでは 宣言型管理とサーバーとの やり取りの例を見てみましょう まず 宣言型管理を有効にします これは デバイスがすでにMDMに 登録されている状態から始まります サーバーはデバイスにプッシュ通知を送信します デバイスは通常の方法でプッシュ通知に応答し ステータスをアイドルに設定した ServerURLエンドポイントリクエストを送信します サーバーはDeclarativeManagement コマンドで応答します コマンドを受信したデバイスは 宣言型管理を有効にします DeclarativeManagementコマンドを処理した後 デバイスはAcknowledged ステータスをサーバーに返信します その後 サーバーにそれ以上のコマンドが無い場合は 空の応答を返します その後 デバイスは宣言型管理の 同期処理を開始します 次にそれを見てみましょう デバイスはまずエンドポイントキー をdeclaration-itemsに 設定したCheckInリクエストを送信します サーバーは 宣言のメタデータを含む マニフェストで応答します デバイスは マニフェスト内の項目を 以前にサーバーから受信した 一連の宣言と比較します この比較により デバイスはどの宣言が新しく どの宣言が変更されどの宣言が削除されたかを 知ることができます 新規または変更された宣言ごとにデバイスは CheckInリクエストを送信します 子のリクエストのEndPointキーには 宣言リソースを一意に識別する パスが設定されています サーバーはその宣言を表すJSONオブジェクトで 応答します 全ての宣言がサーバーから取得されると デバイスは この更新された宣言の状態で表される ポリシー変更の適用を開始します ポリシーの変更が適用されると デバイスは　対応する更新された ステータス項目を含むステータスレポートを サーバーに送信します 手始めに iOS 15で出荷されているものを見てみましょう 宣言型管理機能は iOS 15およびiPadOS 15を 搭載したデバイスでサポートされます また MDM登録タイプがiOS 15で導入された 新しいオンボーディングフロー またはiOS 13のフローである ユーザー登録の場合にのみ利用できます 設定についてはMDMのアカウントおよび パスコードプロファイルのペイロードのセットと 同様のアカウントおよびパスコード設定があります また プロファイル構成もサポートしており MDMがサポートするプロファイル のフルスイートを宣言的に デバイスにインストールすることができます また ステータスサブスクリプションの設定も可能で サーバーが受信したい特定のステータス項目の 更新を宣言するために 使用されます 現在1種類のアクティベーションが用意されています このシンプルなアクティベーションは アトミックに適用する必要のある 設定のリストを定義し オプションの述語を含むことができます アセット宣言については2つのタイプがあります ユーザーの連絡先情報を表す ユーザーアイデンティティアセット とユーザーアカウントの ユーザーIDとパスワードを含む ユーザークレデンシャルアセットです 管理宣言については「組織の詳細」と 「サーバーの機能」の2種類をサポートしています 次に 現在利用可能なステータス項目を紹介します 宣言ごとにステータス項目が容易されており 端末からサーバーに自動送信されています また 機器のハードウェアモデルやOSの詳細など 機器の基本的なプロパティをカバーする ステータス項目も 用意しています これらの宣言やステータス項目の詳細については Appleのデバイス管理開発者向け ドキュメントをご覧ください 今日は 宣言型管理の新しいパラダイムと その機能について説明し 宣言型管理がいかにしてデバイスを より自律的でプロアクティブな ものにするかを学びました また 宣言型管理をMDMソリューションに 統合する方法についても学びました 宣言型管理がどのように機能するかを 示す例を見て宣言型管理が今日にでも 使用開始できる準備ができていることを 確認しました 皆さんが宣言型管理を使って どのようにMDMソリューションを 刷新するのか 楽しみにしています ご参加ありがとうございました素晴らしいWWDCを ♪