宣言型デバイス管理を取り入れる

（音楽） （音楽） 「宣言型デバイス管理を取り入れる」の セッションにようこそ 私はCyrus Daboo Device Management teamのエンジニアです 宣言型デバイス管理における新機能について お話しします WWDC21では 同僚のMelissaが 宣言型デバイス管理を紹介しました MDMプロトコルを描きなおす Appleデバイス管理の新しいパラダイムです そこで学んだ通り 宣言型デバイス管理はパワフルで デバイスを自律的かつ順向的にします デバイスは自律的で その設定変更に反応し サーバーのプロンプトなしに 管理概念を適用します またデバイスは順向的で 重要な設定変更が起こると ステータスチャンネルが非同期的に報告し サーバーのポーリングを 回避することができます ２つの重要な要素が 宣言型デバイス管理データモデルにあります 申告と状態です 申告は起動と述語構造とアセット 管理タイプを包括します 状態は項目と報告をカバーします なぜ これが重要なのか そして皆さんと 皆さんの製品を使う組織 にとってどうかお話しします このテクノロジーは 新しい複雑な管理方法をサポートし 管理デバイスのユーザー体験を向上させ ITチームが何度も繰り返す退屈な作業を緩和し デバイス自体を管理下における ドライバーにするために作られたものです デバイス管理策解決方のデベロッパーとして 宣言型は軽量で反応的な サーバーを実現できます また宣言型データモデルで 組織の構成をより綿密にマッピングでき デバイスへの変更がより直感的になります 状態報告はリッチな フィードバックチャンネルで サーバーがデバイスを より注意してモニターでき ポーリングに必要な 複雑な戦略を必要とすることなく 適切な情報をより速く信頼できる形で 提供することができます つまり 開発がよりシンプルになり 重要なところに価値を足すことができる デバイス管理機能に集中できるようになり お客様が気にいる解決策を 提供できるようになります ITチームにとっては 宣言型でデバイスの状態を予期でき 確信を持つことができます そしてサーバーへの接続を 失うような悪状況でも 組織の機密データが守られ 常に安心できることになります 状態報告でデバイスから重要な返答が得られ ネットワークのバンド幅など リソースの利用削減で 能率も向上されます 組織のユーザーにとっては デバイス管理がより素速いオンボードと 回復時間 そして組織からのよりよいサポートで 反応を得やすく より信頼できる体験になります これらの利益を念頭に プロトコル機能の将来の焦点は 宣言型デバイス管理となり 今日からでも製品に 宣言型デバイス管理を取り込むことが 非常に重要になってきます 宣言型デバイス管理の詳しいご紹介と それに必要なステップは WWDC21のセッションのビデオをご覧ください 今回のリリースの焦点は３つです 宣言型デバイス管理の範囲の拡大 状態報告の向上そして述語の向上です まず 宣言型デバイス管理の 範囲の拡大についてです 宣言型デバイス管理が紹介された時 iOSでユーザー登録時のみ サポートされていました それがMDMがサポートするどの登録タイプでも 宣言型デバイス管理が可能になりました 自動デバイス登録は 監督下のデバイスを含み プロファイル型登録 そしてプロファイルと アカウント型のユーザー登録です 宣言型デバイス管理は 共有iPadでも利用できます iOS 16では環境設定Appの MDMプロファイルに設定があります タップすると現在の設定が 表示されます また 宣言型デバイス管理は MDMがサポートする全プラットフォームで 利用できるようになりました macOS VenturaではmacOSでサポートされる すべてのMDM登録タイプで利用できます tvOS 16ではMDMデバイス登録タイプの 宣言型デバイス管理がサポートされます OSでサポートされていれば iOSで利用できる 同じ申告と状態のセットが macOSとtvOSでも利用できます macOSではMDMプロファイルの詳細ビューで 設定を確認でき 有効設定が表示されます tvOSでも同じくMDMプロファイルの詳細ビューで 設定が確認できます 最後になりますが macOSと共有iPadデバイスには MDMチャンネルが２つあります デバイスとユーザーチャンネルです デバイスチャンネルは デバイスレベルでの管理を ユーザーチャンネルはユーザーごとの 管理を実施します これらのチャンネルでの 宣言型デバイス管理の使用は チャンネルごとの有効化が必要です つまり対応するチャンネルにコマンド DeclarativeManagementを送ることになります また宣言型デバイス管理状態報告は それぞれのチャンネルに作成され 別々のモニターが必要になります それでは次の焦点である状態報告についてです まず状態報告を一覧してみます 登録済の状態項目に関しては デバイスはサーバーに 定期的な報告ができます デバイスはサーバーからの成功返答を記録し 状態の更新が信頼でき ネットワークの問題などで ミスしないようにします 状態報告はデバイスを順向化します 状態変更の観察に サーバーがデバイスを続行的に ポーリングする必要はありません iOS 15ではモデルタイプやOSバージョンなど デバイスプロパティのために いくつかの状態項目をご紹介しました このリリースでは３つの エリアで状態を拡張します パスコード 設定によるアカウント そしてMDMにインストールされたAppです まずはパスコードから iOS 15ではパスコード ポリシー設定を紹介しました ユーザーによる変更の際ポリシーの適用と パスコードの準拠に 少し遅れがありました MDMパスコードポリシープロファイルと同様です ですのでMDMサーバーが デバイスにポーリングして パスコードの準拠を決定しています しかし新しい宣言型デバイス管理の パスコード状態項目で その必要がなくなりました ２つの状態項目を追加しました Passcode.is-compliantと passcode.is-presentです ComplianceとはMDMプロファイル 及び設定で適用した全パスコードポリシーとも パスコードが適合することを意味します これらの状態項目にはブール値があり MDMクエリによって戻される 同等プロパティを反映します では典型的なサーバーの動きを見てみましょう 組織にはたいていデバイスに適応する 機密の状態があります 例えばVPNやWi-Fiプロファイルで 保護されたネットワークに アクセスが許されます 強力なパスコードポリシーがあり パスコードがポリシーに準拠している時のみ その状態がデバイスで有効化されるべきです 従来のMDMではユーザーが変更した時 サーバーがパスコードプロファイルを送って ポーリングしパスコードが準拠するのを 待たねばなりません 最初はパスコードはおそらく準拠せず Wi-Fiプロファイルは送られません 結局はユーザーがパスコードを変更し 準拠させるようにします サーバーの次のポーリングで 準拠状態への変更を察知し Wi-Fiプロファイルを送ってもいいと判断し デバイスにインストールされます 宣言型デバイス管理は パスコード準拠状態に 誘発された起動述語によって サーバーによるポールングを不要とします サーバーはパスコードポリシーと Wi-Fiプロファイルの両方を 起動と繋がるWi-Fi構成が パスコードに準拠した状態で送り出します パスコード構成は直ちに起動され 強力なパスコードポリシーを適応します 最初はパスコードは準拠しませんので predicateがfalseと評価し Wi-Fi構成は起動されません いずれユーザーがパスコードを 更新し準拠されます これにより起動の再評価が行われ predicateがtrueと評価し Wi-Fi構成が起動することになります これらすべてがサーバーの介入なしで行われ 実際 サーバーへの接続なしで 行われることも可能です 構成が起動した時サーバーはデバイスから 自動的に状態報告を受け取り 変更が起こるとそれを察知します ポーリングの必要性を避け より反応的で信頼できるデバイスの反応のため サーバーからデバイスへ ビジネス概念の移動に成功した過程です 次はアカウントの状態です iOS 15でデバイスに いろんなタイプのアカウントを インストールするための アカウント構成をご紹介しました これらはたいてい組織のアカウントで 組織のデータへのアクセスを ユーザーに与えます 問題を抱えるユーザーのサポートのため いつアカウントがインストールされ どのような状態か 管理者が知ることは非常に便利です このリリースではMailやCalendarなどに ８つの状態項目を追加します ただし 設定によってインストールされた アカウントのみ報告され 手動で作成したアカウントや MDMプロファイルによるものは含みません どの状態項目も アカウントの設定タイプに一致し メールアカウントの受信･送信状態は 別々に報告されます これらの状態項目は別タイプの JSONオブジェクトを使い それぞれに一致するタイプの状態を示します これは受信メールの状態項目と サブスクライブカレンダーの状態項目の例です Identifierキーの値は状態項目オブジェクトの 配列内のオブジェクトのユニークな識別子です この詳細は後ほど説明します declaration-identifierキーの値は アカウントをインストールした設定の 識別子プロパティ値と一致し 状態項目オブジェクトと それに関連する設定の他所参照が簡単になります この２つのキーはどのタイプの アカウント状態項目 オブジェクトにも存在します 他のキーはアカウントタイプ特有です 例えばメールサーバーのhostnameやport カレンダーサブスクリプションの calendar-URLがその例です このリリースでは新たに同タイプの１つ以上の アカウントの報告をサポートする 値が配列の状態項目が加わります これらの配列値には独特の習性があります これらの配列の項目はJSONオブジェクトで 配列内の全オブジェクトに 同じスキーマが使われます どのオブジェクトにも常に識別子キーがあり 配列内でオブジェクトの位置を示す 主キーの役を果たします それ以外のキーは 報告されている状態の基底タイプと結ばれます 将来のOSリリースでの新しいキーとの 前方互換性を保証するため サーバーは配列オブジェクトの 未知キーの受け入れが必要です 配列値の変更は性能上の理由から オブジェクト毎の条件で 常に増分的に報告されます この新機能の仕組みを 例を使って見てみましょう この例では サーバーが２つのメールアカウント設定を デバイスに送ります これらは有効でデバイスで２つのアカウントが 存在することになります サーバーがメールアカウント状態項目の 状態サブスクリプションを送ります これが起動されると アカウントの状態が集められ デバイスがサーバーに状態報告を送ります 状態報告には状態配列内の２つのアカウント状態 オブジェクトが含まれ 現在デバイスに何があるか 全体像をサーバーに与えます 各配列オブジェクトには別の識別子があります この報告を処理した後 サーバーには２つのアカウントの状態が伝わり デバイスと一致します サーバーが新しい設定を送り デバイスに新しいアカウントを作成すると 状態項目の配列値に新オブジェクトが追加され 別の状態報告がサーバーに送られます 報告されるのは新項目だけです 識別子キーの値はすでにサーバーにあるものと 一致しないため 新しいアカウントのものだと サーバーが推測します この報告を処理した後 サーバーには３つのアカウントの状態があります 最初の２つと新しい１つで 再びデバイスと一致します ユーザーがメールをトグルし アカウントの状態が変わった場合 デバイスの状態項目は 配列値内のオブジェクトが更新され 再びサーバーに状態報告が送られます 変更した項目だけが報告されます この場合 ユーザーはアカウントのノート機能を オフにしました 識別子キーの値が サーバーのものと一致するので これはすでにあるアカウントへの更新だと サーバーは推定します その結果 既存の状態項目配列オブジェクトを 新しいものに置き換えます この報告を処理した後 サーバーの３つのアカウントの状態のうち １つが変わりました アカウント設定がデバイスから取り除かれると デバイスの状態項目に 取り除きを記したオブジェクトができ 別の状態報告がサーバーに送られます 取り除かれた項目だけが報告されます 取り除きを示すため 配列項目オブジェクトには ２つしかキーがありません すでにサーバーに あるものと値が一致するidentifierキーと 値がtrueにセットされたremovedキーです これにより既存の項目を取り除き デバイスの状態を更新することができます この報告を処理した後 サーバーには２つのアカウントの状態があり デバイスの状態と一致します 状態報告に関してもう一つ 性能問題を避けるため 状態報告が送られる頻度を デバイスが限定します デバイスはサーバーに状態報告を送る前に 状態項目への変更を 最高１分の変動周期で集めます つまり 状態は素早く報告されますが 即時ではないということです 次に永久の問題である MDMのボトルネックの解決策である Appインストール状態のモニターです MDMサーバーは職場や教育現場で 必要なツールにアクセスするため しばしばデバイスにAppをインストールします サーバー側の概念には Appが無事インストール されたかどうかを要します ですのでMDMサーバーは Appのインストール状況と ユーザーが監督下のAppを取り除いていないか 監視する必要があります 現在 MDMサーバーは InstalledApplicationListか ManagedApplicationList コマンドでデバイスから Appのインストール状況を監視しています デバイスに順向的にインストール状況を サーバーに送らせれば ポーリングを避けられます そのツールが 宣言型デバイス管理状態報告です このリリースはmdm.app状態項目を追加します この値はMDMサーバーによって インストールされた 各Appを示すオブジェクトの配列です 配列が値なので先程説明した過程で 増分的に報告されます ただし報告されるのはMDMにインストールされた Appのみで監督下のデバイスでも含みます この状態報告にはインストールしたばかりの Appの状態項目も含みます identifierキーは配列項目オブジェクトの ユニークな識別子でこの場合 Appのバンドル識別子です nameキーはAppの名前です ３つのversionキーは普通のものとshort そしてexternalバージョン識別子です そしてstateキーは Appのインストール段階を示す目録です これらのキーの値はMDMの ManagedApplicationListの コマンドレスポンスに同等の項目と一致します これらの情報でサーバーは直ちに 報告されているAppとその状態を確認します ではAppインストール時の データの流れを見てみます 右側にあるのはMDMサーバーで 管理されているiOSデバイスです サーバーは既に宣言型デバイス管理を作動し MDMにインストールされた App状態項目の状態 サブスクリプションを送っています サーバーの次のステップは InstallApplicationコマンドでの Appのインストールです これはユーザー登録なので承認が必要なため デバイスがインストールコマンドを 処理するとデバイスに通知が表示されます この時点でインストールが一時停止され ユーザーの入力を待ちます デバイスはサーバーへ ステータスレポートを送信 MDMインストール済Appのレポートも AppのバンドルIDも ユーザーがインストールボタンをタップし デバイスへのインストールが始まる インストール中別のステータスレポートが送信 この時ステータスはインストール中となる Appのダウンロードが 完了しインストール中の意味 Appのインストールが完了したら 使用可能に ここで別のステータスレポートが送信 ステータスは"managed"に Appのインストール完了と管理中との意味 さて ユーザーが主導でAppを削除する場合 その地点で再びステータスレポートを送信 その場合ステータスは "managed-but-uninstalled" もうインストール状態ではない事を示す しかしデバイス上のmanagement状態は 続いている 仮にServerがー App-management状態を削除したいとします その場合コマンドRemoveApplicationを デバイスに送信 これが内部のmanagement stateを削除 もしAppは内部にあれば 同時に削除される Appオブジェクトと共に ステータスレポートを送信 Status arrayは削除済に これが新しいMDM statusアイテムの力です レスポンスを強化し インストールの信頼性を高める 必要な手順も数ステップだけ ３つ目のフォーカスは述語 activation predicatesについて振り返ります Activationsにはpredicateを含みます これで設定やー 起動時のレファレンスがデバイスに適用 PredicatesはStatusアイテムを参照 Status itemsのテストを許容する値を持つ Status itemがPredicate changesで参照時 デバイスは全アクティベーションを再確認 そしてあらゆるPredicatesも PredicatesはStringで特定される その際NSPredicateシンタックスを適用 Apple Developerサイトに該当の文書もあります より複雑なPredicate expressionsに Predicateシンタックスを拡張し作業を容易に これでStatus itemsを検知する 新しいシンタックスがStatusアイテムに名前を Predicate stringの@statusターム内に 例えばシリアル番号とStatus itemは Predicate expressionに表示 ここでも新しいシンタックスが これまでのSyntaxも動き続ける Backwards compatibilityだが推奨はしない 新しいこちらに切り替えてください どのようにPredicatesが Status item array valuesと 共に動くか見てみましょう 今話したようにStatus item valuesは アカウントのarraysです そしてMDMインストール済の app status itemsです Array上のItemに対するActivationを 判断する際便利です Activationを起動したい場合 Appが特定のbundle identifierが デバイス上にインストールし管理中の場合 NSPredicateはSUBQUERY termがある Arraysの実行に適用 NSPredicate expressionはSUBQUERYを使用 MDMインストール済のapp status itemを狙う Status itemはSUBQUERYの最初のargumentとして ２つ目はvariableを定義する Arrayのエレメントを参照する ３つ目はPredicate expression variableで特定された各エレメントをテスト SUBQUERY expressionが エレメンツのArrayへ戻る Third argumentのpredicateに合致する @count operatorがArrayのLengthに戻る Lengthにもチェックが入る それが結果としてマッチの有無を確認する Appをインストールして管理する際 SUBQUERY expressionは単体のエレメントで arrayに戻り 値をtrueに インストールしていない場合 SUBQUERY expressionは 空のarrayに戻り 値はfalseに status item array objectで keysを参照する際@key extension termが key pathsを正しく進行すべく 適用しなければならない 新しいpredicate syntaxは伸張性がある ここからはそれを新タイプのデータの為 Predicate termsへ追加する点について Serversはより直接的に コントロールする必要がある そしてPredicatesの評価も… 複雑なserver-side logicが デバイス上の単一のstate changesを読む為 変化のトリガーとして設定の大きなsetsの 同期は不要 この例は複数のユーザーを持ち 効率的なデバイス上の アサインを求める企業も こうした組織が素早く replacement devicesを提供する為に あるいはorganization data保護で 素早くデバイスをセーフモードにする為に この為にご紹介します 新しいdeclarationがサーバーに デバイス上のarbitrary propertiesを設定 直接activation predicatesで使われる これは新しいmanagement properties declarationです このdeclarationはJSON objectで構成 サーバーがkey namesを定義しています JSON objectはJSON value typeで定義 Arraysやobjectsも含みます このManagement properties declarationは ３つのpropertiesを含むNameとAge properties それにはstringとinteger valueがある そしてStringsのroles property predicateを加えたactivationです これはmanagement propertiesも参照します 最初にage propertyをテストし決定する このinteger valueが18あるいはそれ以上の場合 決定するroles propertyをテストする Grade12がproperty array valueにある場合 各Propertyは参照される @property extension termを入力 そこにproperty key nameも 複数のmanagement properties declarationsが デバイスへ送られる でもkeysは全体的にunique 複製したkeysがある場合 Propertyを参照し選択する それが予期せぬ結果へ繋がる 重複するkey namesの使用は避けて下さい ここで例を見てみましょう これは学校でのもの 学校には勿論先生がいる 学校では２層に分かれるUpperとLower 各divisionにキャンパスとWi-Fiネットワークが 先生の中にはIT管理者も 共有メールアカウントへのアクセスを求める スポーツコーチの先生もいる 試合スケジュールの為の サブスクライブ済カレンダーが必要 先生には４種類のロールが そして時には複数のロールを持つ ロールごとに設定のセットがある 先生のロール毎に それぞれアサインしたデバイスへ登録が必要 ここでは２名の先生を考えてみます １人目の先生はLower schoolで教える 同時にスポーツコーチ ２人目はUpper schoolで教え IT管理者でもある これらを従来のMDMサーバーで いかに制御するか？ 本来サーバーは各教師へアサインした デバイスを待つ デバイス設定の前に サーバーは各教師のロールを確認 そして各ロールと連携する プロファイルを判断する デバイス毎にプロファイルをインストール １台づつです 先生がロールを変更したサーバーはー 新しいロールを追加古いものを削除する これはTime-consumingで デバイス管理システムに 負担がかかる場合も 特にピーク時は 例えば新学期初日も アサインメントが完了した時 新しいmanagement properties declarationで より効果的な手段がある declarationのフルセットを事前にデバイスへ プリロードする必要がある 設定はアクティベーションに使われる 各ロールを起動するpredicatesも management properties経由で行う デバイスを教師にアサイン後サーバーは management properties declarationを送信する そこにはアクティベーション を起動する教師のロールも そしてロールの設定も この方法であればサーバーの ネットワーク負荷を抑え複雑さも軽減 device stateを変更しやすい 出は学校の例に戻りましょう サーバーがdeclarationsをプリロードする activationとconfigurationのペアで 各部署のWi-fiネットワークを設定 そしてここにactivationと configurationのペアを メールアカウントを司るIT管理者が設定 これでActivationと設定が完了 サブスクライブしたカレンダーをロードする 各Activationには部署ごとのテストも 又はroles management propertyで各部署の名前も 最初未アサインのデバイスにロードした際 全predicatesの値は”false”の為何も含まない ではアサインメントで 何が変わるか見てみましょう サーバーの仕事は… management properties declarationsです これはそれぞれにカスタマイズしたものです 最初の教師のroles propertyはLowerとSports 別の教師のroles propertyはUpperとIT Admin. これらが別々に 各デバイスへ送られる プリロード済のActivationは再検査を行う １人目の教師のデバイスに合った設定 ”LowerとSports”が登録済か 別の教師のデバイスでも合った設定か ”UpperとIT Admin”が起動済みか 多くの設定のAppの起動には １つのdeclarationだけでいい 最後に もし教師がロール変更したら 例えば２人目の教師が スポーツコーチになった場合 現在のロールに追加とします この場合management properties declarationで その教師のデバイスが更新される 新しいロール名が加わるのです デバイス上でdeclarationが更新完了したら 全activationsが再検査に この場合サブスクライブした カレンダーの設定も 新しいスポーツコーチ分が追加される この場合も１つのdeclaration changeのみ これによって… management properties declarationが… 設定のセットをデバイス上で いかに早く効率的に行うか 手順をお話ししました これで複雑なserver-side logicが デバイス上のシンプルなstate changesに 以上です 宣言型デバイス管理についてお話ししました iOS 16やtvOS 16そしてmacOS Ventura そして共有iPad等MDM enrollment他 全ての適用可能なタイプ これが宣言型デバイス管理で完全なサポートを MDMをサポートする全Apple devicesへ Passcodeやアカウント等に新しいstatus itemも そしてMDMインストール済のAppも MDMインストール済のAppが MDMの主要な問題を解決 最後にpredicate syntaxも説明しました 伸張性があり簡単に使える 新しいmanagement properties declarationも これでサーバーがcomplex business logicを デバイスへ簡単に移動する方法を提供 早速宣言型デバイス管理をあなたの製品に 追加してみて下さい あなたがデバイスでいかに再想像し 管理ソリューションを編むか楽しみです 宣言型デバイス管理を活用して あなたのフィードバックもお待ちしています ありがとう そしてWWDCの残りも楽しんで下さい ♪