ManagedAppフレームワークの基礎知識

こんにちは シニアiOSデバイス管理 エンジニアのBob Whitemanです 今回は 新しいフレームワークを皆さんと 共有できることを嬉しく思います これは管理されたデプロイメントでアプリを より使いやすく より安全にするものです 今や 世界中の組織がオフィス、店舗、学校で Appleデバイスを使用しています 人々はそれらを使用して 学び 教え、働き、創造しています これらのデバイスで実行されているアプリが こうしたことすべてを可能にしているのです 組織管理者は デバイス管理サービスを使用して 所属する人々が成功するために必要な アプリを確実に利用できるようにしています 人々はその組織のアプリをすぐに 使いこなせるようになります しかし アプリは通常一度しか設定しないため 新しい体験に圧倒されることもあります サーバ名、ユーザー名、パスワードに加え 2ファクタ認証コードの 入力が必要な場合もあります さらに アプリの設定に進み 組織の要件に合わせて カスタマイズする必要があります 複数の手順があり 何か問題や間違いが発生した場合は まあ うまくいかないことがほとんどです ユーザーはわずらわしさから アプリの使用をあきらめるかもしれません サポートに問い合わせれば時間が無駄になり 組織のサポートコストも 増加します その組織はアプリのサポートを打ち切る ことを決定する可能性さえあります アプリデベロッパとして この体験を 改善しようとすることはできますが それには多くの労力が必要であり 本来のアプリの主要な機能とは 無関係な作業です これをシームレスな体験にするために構築する 必要があるものをすべて検討してください 組織のIDプロバイダを使用して フェデレーションを実装します 構成用のWebサイトを構築して運用し 管理者が各デバイスで 動作するアプリに必要な設定を 指定して配信できるようにする 必要があります 組織の認証局や 認証インフラストラクチャと統合して アプリが組織のサーバと 通信できるようにする必要があります 一部の組織が求めるブランド要素や カスタム機能を提供するために アプリのカスタム版を 個別に公開する必要があります もしこのような作業が 不要だとしたらどうでしょうか？ このように複雑な セットアップ体験を一掃しましょう これからは その組織、そのデバイス そのユーザーのために アプリを事前に設定できるようになります セットアッププロセスは まったく必要ありません 最初の起動からすぐに アプリを使用できます アプリの第一印象ははるかに良くなり 使用頻度も上がります ユーザーが気に入っており サポート サポートコストも最小限になるため 管理者はアプリを積極的に 展開するようになります どうすればこれを実現できるでしょうか？ ManagedAppフレームワークを ご紹介したいと思います ManagedAppフレームワークでは 管理対象アプリとそのExtensionを 自動的に構成できます アプリはこれを使用してデバイスを認証し ユーザー認証を効率化できます また このフレームワークを使用することで アプリは高いセキュリティ要件を満たす データセキュリティとアクセス制御を 実現できます

これを実現するために ManagedAppフレームワークでは 管理者が カスタムアプリ構成を指定したり パスワード、証明書、IDを プロビジョニングできます これは 他のデバイス管理テクノロジー 例えば 拡張可能なシングルサインオンや 管理対象デバイスの認証や 登録シングルサインオンと連携できます ManagedAppフレームワークでは 4種類のデータを提供できます アプリ固有の構成は 特定のアプリが サポートする任意のデータです これには アプリにとって意味のある 設定やオプションに加え 小さなアセットが含まれます 他の3つの種類は機密情報で パスワード、証明書、ID情報です ID情報には PKCS #12、SCEP ID ACME IDなどを指定できます ACME IDはハードウェアバインドの鍵や 認証に対応しています これらの種類のデータはすべて安全に保存され 管理者が指定した管理対象の アプリやExtensionにのみ提供されます ManagedAppフレームワークは iOS 18.4 iPadOS 18.4、visionOS 2.4で利用できます 宣言型デバイス管理を使用して アプリを管理するには MDMサーバが必要です サーバはアプリをインストールした瞬間 または インストール済みのアプリの管理を 引き継いだときから機能します すべてのMDM登録タイプで機能します ほとんどの種類のApp Extensionを サポートしています ただし 非常に制限された環境で実行される Extensionには対応していません 例えば キーボードExtensionでは フルアクセスが許可されていない限り ManagedAppフレームワークを 使用できません このセッションでは 開発とデプロイの ワークフローについて説明し このフレームワークが役立つ いくつかのシナリオを紹介します コードの詳細を確認した後 ベストプラクティスを紹介します どのような仕組みに なっているのでしょうか まず 管理対象のデバイスから始めます 管理者はMDMサーバを使用して 管理コマンドを送信し MDMプロトコルを使用して デバイスへのクエリを実行します

管理者がアプリを管理し 通常 これによりアプリがインストールされます アプリの管理の一環として 管理者は アプリとExtensionで 利用できるようにする構成情報や シークレットをデバイスに指定します

アプリが起動すると ManagedAppフレームワークに対して 構成情報とシークレットの取得を要求し フレームワークはそのコピーを アプリに提供します アプリは構成をただちに適用し 必要に応じてシークレットを使用します その後はいつでも 管理者は構成情報や シークレットを更新できます そのときアプリが実行中であれば フレームワークはアプリに通知し アプリはただちにアップデートを適用します しかし その前に アプリデベロッパであるあなたが アプリを作成する必要があります 構成情報を読み取るデコーダを作成し 構成を適用してシークレットを 利用するコードを作成します 次に アプリの構成方法を管理者に示す 仕様書を記述して公開します この仕様書では アプリが その構成でサポートするキーと値 それらが制御する内容 アプリが想定するシークレットと その使用方法を詳しく記述します これが このフレームワークに とても期待している理由です この構成情報を指定するのは Appleや プロトコルやMDMサーバではありません そうしてしまうと すべてのアプリで 汎用的になりすぎてあまり役に立ちません そうではなく アプリの構成方法を 指定するのはアプリデベロッパの皆さんです これにより 様々な新しいチャンスが生まれます 皆さんは自分のアプリのことを 誰よりもご存知です アプリを構成するための最も強力で 実用的で革新的な方法を提供でき それにより 組織向けにアプリの性能を 最大限に引き出すことができます ManagedAppフレームワークは ソリューションではありません これは 皆さんがソリューションを 簡単に構築できるプラットフォームです それを念頭に置いて いくつかのシナリオで ManagedAppフレームワークが 特に便利である点をご紹介します このフレームワークを活用できる シナリオは数多くあります サードパーティのブラウザに 認証情報を安全に提供したり ユーザーの役割に応じて 社内アプリをカスタマイズしたり Safari Extensionを構成したり デバイス管理サービスと管理対象アプリ間の 通信をセキュリティで保護することもできます これらのシナリオのうち 3つについてさらに 詳しく説明します 最初はライセンス管理です アプリデベロッパはアプリサーバが リクエストを適切なユーザーに紐づける 手段を必要とすることが よくあります その一般的な解決策が ライセンストークンです 組織がサーバの使用ライセンスを 取得すると デベロッパは その組織に固有の ライセンストークンを発行します 管理者はMDMを使用して そのライセンストークンを 組織で使用されるアプリの すべてのインスタンスに配布します その後 アプリがサーバに リクエストを行うときには リクエストにライセンス トークンが含まれます これにより サーバはそのリクエストを 正しい組織に紐づけることができます これにより セキュリティ上の懸念が生じます 組織はトークンの保存および配布時に このトークンを保護する必要があります 組織外の人物がライセンストークンを 入手した場合 その人物はサーバを利用でき 組織がその費用を支払います デベロッパや管理者は ManagedAppの構成機能を使用して このトークンを 管理対象デバイスに配布できます ただし ManagedAppフレームワークは 抽出や改ざんから構成を保護するように 設計されています さらに重要なことは ManagedAppフレームワークが ライセンストークンよりも優れた選択肢である ライセンスキーを提供できることです ManagedAppフレームワークでは ライセンス管理の目的で トークンよりも安全な暗号化されたIDを プロビジョニングできます 管理者はデバイスで暗号化されたIDを プロビジョニングする際 組織やアプリデベロッパによって 発行された証明書を使用します 秘密鍵はデバイス上で生成され そこから移動することはありません アーキテクチャ全体でトークンを 送信する方式よりも安全です 以前のManagedAppの構成機能では ライセンスキーはサポートされていません ManagedAppフレームワークは より安全で IDをサポートするほか App Extensionにも対応しています アプリでこの構成機能を使用するには ManagedAppに移行してください 次に VPN Extensionを調べてみましょう ManagedAppフレームワークは VPN Extensionとして特に便利です VPNサーバには 強力な認証が必要です これにより デバイスが組織の一部であり ネットワークへの接続が 許可されていることを保証します このアーキテクチャは 前のシナリオと 非常によく似ています ただし IDはアプリではなく VPN Extensionに提供されます ManagedAppフレームワークは Appleがサポートする 最も強力な認証情報を提供できます 管理者は 管理対象デバイスの認証を 使用して認証済みの ハードウェアにバインドされた鍵を そのデバイスにプロビジョニングします ManagedAppフレームワークはその情報を VPN Extension（当該Extensionのみ）に 直接提供します そのIDを使用して VPNサーバに対して認証します これにより VPN管理者が懸念する 潜在的な脅威の多くを阻止できます 最後のシナリオはIDプロバイダです IDプロバイダーは拡張可能なシングル サインオンを使用して アプリやWebサイトの 連携済みアカウントへの サインインを容易にします また アカウントベースの登録方式では 連携済みAppleアカウントでも機能します 各IDプロバイダは 通常は手動で 入力される認証情報を使用する 独自の認証プロトコルを 設計しています ManagedAppフレームワークを 使用することで IDプロバイダは 他の多くの種類の認証手段も 統合できるようになりました 例えば デバイスを認証するための ハードウェアにバインドされたIDが 許可されたデバイスでのサインインを 確認する目的で使用される場合があります 新規アカウントの場合 これは 初回認証用の初期一時パスワードの 可能性もあります これは サインインを組織に紐づける トークンやIDである可能性もあります 実際 これはIDプロバイダが必要とする どんな種類のシークレットでもかまいません ManagedAppフレームワークは これらすべてをサポートしています IDプロバイダが登録シングルサインオンを サポートしている場合 登録中も構成情報とシークレットを 利用できます ManagedAppフレームワークが いかに多くの方法で 管理対象アプリを強化できるか 理解していただけたら幸いです いよいよアプリに実装する方法を 確認するときが来ました ManagedAppフレームワークのAPIは 構成情報とアプリのシークレットを できるだけ簡単かつ安全に 提供することに重点を置いています このフレームワークには それぞれが各データ型に対応する 4つの独立したクラスがあります これらの最初の3つは アプリが必要とする 組み込みデータ型を正確に提供します パスワードを含む文字列 SecCertificate、SecIdentityです 4つ目は少し異なります ManagedApp構成プロバイダが アプリ固有の構成を提供します このための組み込み型はありません これは アプリに必要な任意のデータ型です アプリデベロッパはこのデータの 構造を定義する必要があります まず 構成を使用した例を1つ紹介し 次に IDを使用した別の例をお見せします 最後に アプリの仕様の 公開について説明します

まずは Landmarksアプリから始めましょう 教室で使いやすいように アプリを 構成可能な仕組みにします 最初のステップは 管理者が構成できる 項目を決定することです これは Landmarksアプリの コレクションビューです 管理者が新しいコレクションを 構成できるようにしましょう これにより 教師は 今後の地理の授業で 生徒が使用する ランドマークを収集できます

コードでは 管理者がアプリの インスタンスに対して構成した すべての内容を表す構造体を 作成することから始めます これには 管理対象コレクションの 読み取り専用プロパティがあります プロパティの型は省略可能です これは アプリが管理対象ではない 可能性があるためです または 管理者が構成を 適用していない場合や あるいは 構成を適用していても 管理対象コレクションが 含まれていない可能性もあります 構成のプロパティの ほとんどは省略可能であるか デフォルト値を指定します

ManagedAppフレームワークが MDMサーバから構成情報を 受信するとき 通信時の形式を デコードする必要があります そのため この構造体を Decodableに準拠させます また コレクション用に CodingKeyを指定します ランドマークコレクションクラスを Decodableに準拠させたら ここで処理を終えてもかまいません コンパイラが構成クラス用の イニシャライザを 自動生成するからです ただし ほとんどのアプリには カスタム検証規則が必要になります そのため ここでは明示的な イニシャライザを記述します これで構成クラスの定義は完了です では アプリはどのようにして この構成情報を受け取るのでしょうか？ このAPIはSwiftの並行処理を使用するため Taskを作成することから始めます Task内でManagedAppフレームワークの ManagedAppConfigurationProvider クラスを使用します configurationsメソッドは 非同期シーケンスを使って 構成情報を提供します configurationsメソッドに 渡すパラメータは 構成用の構造体の型です 構成情報の受信を開始するには for awaitループを使用します この非同期シーケンスは 構成用の型のオプショナル値を返します したがって このコードでは configの型は LandmarksManagedConfigオプショナルです これらの要素がどのように連携するかを デバイスで発生するイベントの 流れに沿って見ていきましょう まず 管理者はエンコードされた 構成情報を作成し それをデバイスに送信します デバイスはこの情報を保存します 次に アプリがfor awaitループを使用して 非同期シーケンスの処理を開始すると デバイスはエンコード済みの構成情報の コピーをデコーダメソッドに渡します これにより アプリが必要とする プロパティが含まれた 構成用の構造体の インスタンスが生成されます 最後に そのインスタンスが 非同期シーケンスに渡されます その後いつでも 管理者が更新した構成情報を 送信すると その処理が自動的に繰り返されます アプリが管理対象ではない場合や 管理者が構成情報を 指定していなかった場合や デコードが失敗した場合は シーケンスはnilを返します つまり アプリ側でこれらの状態を 意識する必要はありません このシーケンスが 値またはnilを返す場合 それがアプリの現在の 管理構成です したがって for awaitループの本体で行う 必要があるのは 構成から取得した値を モデルデータの管理対象コレクション プロパティにコピーすることだけです 構成はいつでも更新される 可能性があるため for awaitループには 終了条件がありません ただし 無限ループでもリソースを 浪費しているわけではありません for awaitループの本体は 値が生成された場合にのみ実行されます このタスクはどこで開始すればよいでしょうか これはアプリ内の どこに配置してもかまいません 通常は アプリの起動パスの早い段階で メソッドで実行されます Landmarksアプリの場合 これをModel Dataの Load Collectionsメソッドに組み込みます コレクションは アプリの起動直後に 読み込まれます 管理対象コレクションをビューに 追加すれば これで完了です その結果がこちらです Collectionsビューに Managed Collectionセクションが追加され 管理者が構成したタイトルと ランドマークが表示されています ここでおまけを1つ すでに記述したコードだけで 更新にも対応できるのです 管理者が構成を変更すると ビューが自動的に更新され 新しいランドマークが表示されます 次は IDを使用する例に 移りましょう 例えば 管理者がさらに多くのランドマークを 追加できるようにしたいとします アプリにアセットサーバから ランドマークをダウンロードさせます 管理者には アセットがホストされている URLを指定できるようにします これにより 管理者は 必要な場所で 柔軟にアセットを ホストできるようになります アセットのURLを 先ほど作成した構成に 簡単に追加できます また アプリがアセットサーバに 接続する際に相互TLSを使用して 自身を認証するためのIDを 管理者がプロビジョニング できるようにします フレームワーク内の3つのシークレット プロバイダは同じパターンを使用します 各シークレットには文字列識別子があります この識別子でシークレットを参照する メソッドが用意されています アプリがサポートする識別子は デベロッパが選択できます ほとんどの場合 識別子はハードコーディングできます 使用可能なシークレットが変更されたときに アプリに通知する場合は AsyncSequenceを使用できます このシーケンスは 現在プロビジョニング されている その種類のシークレットの すべての識別子の配列を返します AsyncSequenceは アプリが識別子の 動的リストをサポートしている場合にも 便利です ただし Landmarksアプリが アセットをダウンロードする場合 それほど複雑にする必要はないため ハードコードされた識別子を使用します アプリはURLセッションを使用して リクエストを実行します 相互TLSを実装する際 関連するコードのほとんどは定型文です 私たちが関心を持っているのは ID情報を取得することのみで それは中ほどの この数行です ManagedAppのIDプロバイダと ハードコードされた 識別子を使用して セキュリティIDを参照します 管理者がIDを提供しなかった場合 チャレンジはキャンセルされます これで完了です わずか数行のコードで アプリで必要なIDを取得できました 鍵のプロパティや 証明書署名要求を処理する 必要はありませんでした また IDのプロビジョニングに 関連する他の作業も不要でした 管理者がプロビジョニングした IDをそのまま使用しただけです 最後のタスクは 仕様書を公開することです これにより 管理者がLandmarksアプリを 構成する方法を説明します 構成情報の形式を文書化します これを行う簡単な方法は 例を示すことです これは構成情報のエンコードされた 形式の例です 構成情報の通信時の形式は プロパティリストです 仕様書では ランドマークIDの 有効な値のリストなど 詳細を文書化する必要があります デコーダがカスタム検証を 実装している場合は 生成される可能性のある エラーコードも文書化し 管理者が自分で作成した構成情報の 問題を特定して対処できるようにします アプリがサポートする シークレット識別子も文書化します Landmarksアプリの場合 これは先ほど 使用したハードコードされた識別子です それがアセットのダウンロードに 使用されることを文書化し これは Landmarkアセットの 想定される形式を文書化するのに 適した場所です このような情報は 通常 文書 またはWebサイトの形式で公開し 管理者がアクセス できるようにします これで完了です アプリを開発する際に留意すべき ベストプラクティスがいくつかあります 構成情報は 大容量のデータ転送には 適していません メガバイトではなく キロバイト単位をイメージしてください 代わりに アプリでサーバからデータを ダウンロードし URLを 構成情報で指定します 先ほどのLandmarksアプリの方法と同様です シークレットは 必要以上に 保持しないようにします 必要なときに その都度参照してください これは安全なプログラミングの ベストプラクティスであるだけでなく アプリで常に最新の シークレットを使用して 管理者が情報を更新した場合に対処できます 構成情報を設計する際は アプリが管理対象かどうかの単一の スイッチだけで アプリの複数の動作を 変更しないでください 代わりに個別の 構成オプションを用意し それぞれでアプリの挙動の一部を 制御するようにします これにより 管理者に最大限の 柔軟性を提供できます 前方互換性と後方互換性を 考慮しましょう アプリの新しいバージョンを リリースするときに 構成情報のオプションを 追加、変更、削除する可能性があります 異なるバージョンのアプリに 管理者が異なる構成を 提供するのは困難です これを回避するには デコーダで 以前の構成を処理できることや 認識できない新しい鍵を 無視することを確認します これにより 管理者は1つの 構成情報をすべてのデバイスに 一括して提供することができます アプリで現在 以前のManaged App Configurationの機能を使用している場合 今こそ 新しい機能への移行を 検討するべきです この移行期間中に アプリは両方の機能をサポートでき ManagedAppフレームワークの 構成が優先されます これにより 管理者は ManagedAppフレームワークに 円滑に移行できます 審査のためにアプリを提出する際 審査担当者はアプリの機能を 実際に試して確認します これらの機能の一部が アプリが管理対象であり 構成やシークレットが 適用されている場合にのみ アクセスできるときは 審査担当者が アプリを審査できない可能性があります これに対処するには いくつかの方法があります アプリにデモモードを追加して 構成が適用されているかのように 機能を体験できるようにします これはユーザーにアプリの デモを行う場合にも役立ちます これらの機能を示すアプリの ビデオを録画する方法もあります ビデオは App Store Connectの で提出できます また 審査担当者が適切に アプリを構成できるように デバイス管理サービスにデバイスを 登録するための手順や認証情報も 用意しておく必要があります 何よりも重要なのは 創造的であることです ManagedAppフレームワークを使用することで アプリが容易に使えるようになり すべてのユーザーがワクワク できるようにしてみましょう お客様が何を望んでいるか 話を聞いてみてください フレームワークを採用しManaged App Configurationからの移行を進めてください フレームワークに関する ご意見・ご感想もお待ちしています デバイス管理の詳細については 「What’s new in managing Apple devices」 セッションをご覧ください ありがとうございました WWDCをお楽しみください