Appleデバイスの管理に関する最新情報

WWDCにようこそ！ 私Nadiaと 同僚のGrahamが macOS Venturaと iOSおよび iPadOS 16の 新たなデバイス管理機能に ついてお話します デバイス管理の世界で 職場での業務環境を 向上させたり 教育現場での 生産性を上げるために 私たちは協力して 使命を果たしています その力となるべく私たちは ツールや技術の開発に 勤しんできました macOS Venturaや iOSおよび iPadOS 16には 多くの優れた機能や 改善点がありますが 今回はその一部を 説明していきます その前に おさらいして おきたいのは 企業や教育現場について 詳しく理解するための 他のセッションについてです WWDC 2021では 宣言型デバイス管理を 紹介しましたが これはデバイス管理の 新たなパラダイムで デバイスの自立性や 積極性を高めつつ サーバーの負担を減らし 反応を向上させました 今年は新プラットフォーム サポートと 新機能でこの宣言型 デバイス管理を拡張します 画面下に表示されている セッションを 是非ご覧ください Apple Business Essentialsは デバイス管理と 24時間体制サポートおよび クラウドストレージを １つにした完璧な サブスクリプションです Apple Business Essentialsなら iPhoneや iPadや Macや Apple TVをすべて 小企業の皆さんが容易に 管理できるようになります その詳細に関しては 画面下に表示されている セッションをご覧ください 管理対象デバイスの証明は 新たなセキュリティ機能で Secure Enclaveを使って デバイスIDや ソフトウェアバージョンなど クライアントの保証を 強化しています その詳細については 画面下に出ている セッションをどうぞ 今回ここでお話する内容は Apple Configuratorでの 新機能 プラットフォーム全体での アイデンティティ技術 macOS Venturaや iOSおよび iPadOS 16での プロトコルの改良と ドキュメント提供の 画期的な改善点です Apple Configuratorから 始めましょう WWDC 2021では iPhone用の Apple Configuratorを紹介しました 教育機関や企業の方々は これにより全ての Macの デバイス登録が 自動化されたのを 非常に評価していました iPhone用Apple Configuratorは 通常チャネル外で 購入された Macを Apple School Managerや Apple Business Manager内の組織に 容易に追加できるように してくれます Macの設定アシスタントで iPhone用Configuratorを 実行して アニメーションの 上にかざすだけです Macはインターネットに接続し 当該組織へとそのまま 追加されます バージョン 1.0.1では 新しいサポートが追加され Macに既存のネットワーク接続が ある場合は それを利用しています 今回は嬉しいことに iOSおよび iPadOS 16では iPhone用Apple Configuratorで iPhoneおよび iPadも 組織へ追加することが できるようになりました Macを追加する時と 同じようにするだけです 現在のように Configuratorを実行した Macに各デバイスを USBで接続する必要が 新機能によって 無くなったわけです iOSと iPadOSでの 主な違いというのは 設定アシスタントでの スキャンの枠です iOSや iPadOSでは Wi-Fiですが macOSでは国や地域です アクティベーションロックや 携帯電話会社の アクティベーションなどが 必要なデバイスは 組織への追加の前に 手動で処理される必要があり これも Macの Configuratorの 場合と同様です iOSや iPadOS 16搭載の デバイスは 現在 App Storeで iPhone用Apple Configuratorを 使って追加する事が可能です では企業や教育機関の ID管理を 一緒に見ていきましょう ID管理は 当該業界において重要で Appleにとっても主要な 優先事項なのです ユーザーの皆さんの データの安全性を保ちつつ 組織としての密接な 体験を可能にするものです

ユーザーのサインインを 一度だけ行えば それ以降はずっと OS中でそのアイデンティティを 使い続けられるのが目標です その目標に向かい 多くのテクノロジーを 駆使していますが その中に含まれるのが macOS Venturaや iOSおよび iPadOS 16での 新機能です Federated Authenticationでは Apple Business Managerが IDプロバイダとしての Google Workspaceと 一体化しています これによりユーザーは 自分の業務用の資格情報を 管理対象Apple IDとして iOSや iPadOSや macOSでの サービスへの認証を 受けられるようになります そして Directory Syncを 使えば 以前は SCIMと 呼んでいたものですが 管理対象Apple IDアカウントを 自動で作成できます 勤務先と学校での Appleへのサインインは 管理対象Apple IDで可能です Appleへのサインインを サポートするAppなら 簡単にできます！ ユーザーがサインインできる Appをコントロールしたいなら Apple School Manager あるいは Apple Business Managerの 全ての appを許可するか 明確な許可リストに Appを追加すれば良いのです これに関しての詳細は 画面下に出ている セッションでどうぞ アイデンティ管理の 特筆すべきアップデートには OAuthサポートもあります iOSおよび iPadOS 15では アクセストークンを使った 認証メカニズムで MDMサーバーがユーザーを 認証できるようにしていました iOSおよび iPadOS 16では OAuth 2を追加して もう１つの認証メカニズムに しています OAuthを既に使用している 幅広い種類の IDプロバイダに対し MDMサーバーが サポートできるように しています またリフレッシュトークン メカニズムによりセキュリティが向上し ユーザーに認証資格を促さない サイレントリフレッシュと 組み合わせて 短命なアクセストークンの 使用を許可しています 既存のアカウント駆動型の ユーザー登録フローも OAuthで使用できますが この新機能と合わせて 使われれば さらに素晴らしいユーザー体験を 提供できます 名付けて Enrollment Single Sign-on または Enrollment SSOです この新しくてスピーディーな メソッドで個人デバイスは MDM登録が完了できて 組織のAppやWebサイトに アクセスするには 一度の認証を 行うだけでいいのです その土台になっているのは 既存のテクノロジーです iOS 13では組織のAppや Webサイトのための SSOを設定する新しい方法として 拡張SSOを導入しました そして iOSおよび iPadOS 15では アカウント駆動型の ユーザー登録を導入し 設定でEメールアドレスを 入力するだけで ユーザーは MDMへの登録が 可能になりました 登録をさらに容易にするために この２つのテクノロジーを 組み合わせたのは BYOD方式が今後の展開で 重要な役目を果たすと 考えるからです ユーザーはまず設定で Eメールアドレスを入力します 次に App Storeから Appを ダウンロードするよう 指示されます このAppには Enrollment Single Sign-on 拡張機能が含まれ 認証ステップを行う ネイティブUIを提供します これは Appベースの モデルなので 認証テクノロジーを自由に 選んで使えます ユーザーとしては サインインは一度きりです 再びサインインしなくても Appが自動的に サインインを行い 登録フローへと導きます Enrollment Single Sign-onを 有効にするには 主に４つの条件が要求されます まずは Appのデベロッパが Appをアップデートし 登録 SSOをサポートする事です 次に MDMベンダーが IDプロバイダと MDMプロトコルクライアント認証を 活用する事です そして管理者は Apple School Managerか Apple Business Managerで 管理対象Apple IDsを設定し 最後は認証レスポンスヘッダーの JSONドキュメントに URLを戻すように MDMサーバーの設定を 行います この機能の内容と その条件を見たので 今度はその詳細について 掘り下げていきましょう サーバーから初期の チャレンジ認証を受けると Enrollment Single Sign-onが 入手可能であり それを使うべきだと表示する HTTPヘッダーが現れます そのヘッダーの値は JSONドキュメントの ダウンロードに クライアントが使用するURLです JSONドキュメントは クライアントが登録を続けるのに 必要なすべての詳細を 含んでいます iTunesStoreID キーの値は 登録時に使われる Enrollment Single Sign-on Appを 示していなければなりません AssociatedDomains キーは ApplicationAttributesで 入手可能なのと同じキーで これもここで設定可能です そして ConfigurationProfileは 少なくとも１つの Extensible SSOペイロードを含み 必要ならば証明書ペイロードを 含むような Base64EncodedProfileで なければなりません 一般のお客様に この機能が届くのは 後に iOSおよび iPadOS 16が 登場する時になります この機能をサポートする Appの開発に 興味をお持ちなら Apple Developer Programを通して 新しい資格の申請を する事が必要です ですが 今は テストモードを使って 開発を始められます これは Enrollment Single Sign-onの特別版で App Storeでの登場前に Appをテストする事を 可能にしてくれます テストモードで開始するには 設定の Developerセクションに行き Enrollment Single Sign-on テストモードを有効化します 次に 新しいHTTPヘッダーと 対応する JSONドキュメントで 認証レスポンスを 設定する事が必要です そして VPNと Device Managementで 登録プロセスを始めます 登録時には Single Sign-on Appの インストールを促されます Xcodeや TestFlightや Enterpriseでも 入手可能などのメソッドでも インストールが可能です その後は設定に戻り 登録を完了します テストモードを使うには レスポンス用の別のヘッダーと 修正された JSONドキュメントが 必要になります テストモードの JSONドキュメントの 例がこちらです ご覧のように iTunesStoreID キーが AppIDs キーに 置き換わっていて このキーの値は登録に使う App IDの文字列の 配列になっています 他はすべて同じです 次は Single Sign-on 拡張機能を見てみましょう 2019年に Single Sign-On 拡張機能を iOS 13と macOS Catalinaに 追加したことにより IDプロバイダは ユーザーのすべての Appと Webサイトに SSO認証を 使えるようになりました SSO拡張機能を 使用すると デバイスの解除後に ユーザーは 拡張機能へのサインインを 促されて 証明書を２度 入力することになります 組織がビルトインのKerberosも 使用す場合 再度サインインが 必要かもしれません 多くの場合これらは 同一の証明書です 今回 macOS Venturaで 導入されるのは Platform Single Sign-On または Platform SSOで ログイン時に一度 ユーザーがサインインすれば 自動的に AppやWebサイトに サインインしてくれます Platform SSOは ログイン時からのトークンを サードパーティの SSO 拡張機能に提供し ビルトインの Kerberos 拡張機能とも協働します ローカルアカウントのパスワードで 最初にログイン認証すると デバイスの FileVaultの 暗号化も解除します これによりユーザーは オフライン時や キャプティブネットワークでも ログインができるのです 以降は アイデンティ プロバイダの パスワードを使って 解除が可能です さらには Platform SSOは パスワードの使用や Secure Enclave に支えられたキーでの IDプロバイダとの 認証をサポートします 認証メソッドがどれであれ SSOトークンはアイデンティ プロバイダから取得され キーチェーンに保管され SSO拡張機能が入手できる ようにします Kerberos TGTも取得され 資格情報キャッシュに インポートされ 任意でKerberos拡張機能と 共有される事も可能です IDプロバイダの パスワードが変更された場合 Platform SSOはロック解除時に 新規パスワードを検証します Platform SSOは完全に 統合されたプロトコルで OAuthと OpenIDを使って 構築されていて 認証には Webビューを使いません Platform SSOは ADバインディングと モバイルアカウントに 取って代わります ですが直接ディレクトリ サービスを使ったり ロック解除を試みるごとに IDプロバイダに チェックはしません IDプロバイダを呼び出すのは ユーザーがロック解除時に 新パスワードを使おうとしたり SSOトークンを取得しようと した時のみです Platform SSOは IDプロバイダのリスポンスを元に Macへのログインを 妨げる事もしません そのような場合は MDMや 代替ストラテジーを使って アクセスを無効にします この機能を利用するには IDプロバイダは SSOプロトコルを実装して SSO拡張機能をアップデートし 管理対象デバイスの 新しいキーのサポートのために 拡張可能な SSOプロファイルを 確実に更新しておきましょう 実装についての詳細は 画面下に出ている ガイドをご覧ください これまでの内容をまとめると Google Workspaceや Enrollment SSOや OAuthサポートや Platform SSOと統合して サインインの簡略化実現に 貢献したわけです ID管理は絶え間なく 進化するテクノロジーで 私たちはまだまだ 入り口に立っているわけです macOS Venturaでは OSアップデートから登録や セキュリティまで 色々と強化されています ソフトウェアのアップデートから 始めていきましょう macOS Montereyでは管理対象の ソフトウェアアップデートに 根本的な変更を導入しました 同僚のLucyが 画面下に出ている セッションでこの事を 説明しましたが ここでは OSアップデートを ３つに分けて考えます テスト デプロイ そして実施です 今年はさらに集中して 追加を行ったのが デプロイと実施です これまでは Power Nap モードの時には OSアップデートコマンドはどれも NotNowを戻してきました OSアップデートのプロセスを 着実かつ頑強にするために たとえスリープや Power Napモードでも ScheduleOSUpdateや OSUpdateStatusや AvailableOSUpdateの コマンドをデバイスが 認識し応答します 時には管理者が できるだけ早く OSアップデートを 行いたい場合があるので “priority”と呼ばれる 新しいキーが ScheduleOSUpdateコマンドで 送られるようになりました Highか Lowの 文字列値を受け入れ 要求されたアップデートの ダウンロードや 準備のためのスケジュール 優先度をコントロールします 優先度高の コマンドを送れば システム設定でユーザー 本人がアップデートを 要求したように 扱われます このキーはOSのマイナー アップデートにのみサポートされます macOS 12.3では OSUpdateStatusコマンドによって ログやレポーティングが管理の視点から さらに見やすいものとなりました DeferralsRemainingは ユーザーにアップデートを 促す通知がいくつ 残っているか示しています MaxDeferralsはユーザーが OSアップデートを延期できる 合計回数を示しています NextScheduledInstallは OSが次のアップデートを 試みる日付です そして PastNotificationsは 通知がユーザーに 掲示された正確な 日時を示しています OSUpdateStatusコマンドへの これらのアップデートで 管理者はユーザーの コンプライアンスについて より正確に把握できます macOS Venturaと iOSおよび iPadOS 16は 新メカニズムを導入し 重要なセキュリティ修正を ユーザーに素早く届けます ファームウェアを 変更することはなく ユーザーは必要であれば 緊急セキュリティ対応を 削除できます このために導入するのは ２つの主要な制限キーです allowRapidSecurity ResponseInstallationは この新セキュリティレスポンス メカニズムを無効にし allowRapidSecurity ResponseRemovalは エンドユーザーが 緊急セキュリティ対応を 削除できないようにします 今度は 登録における 変さらについて少し見ましょう 自動デバイス登録は 組織のMDMソリューション内で デバイスの 開封や有効化や登録を スムーズにします 今後のリリースでは Macの削除や復元の後には Apple School Managerや Apple Business Managerで 組織に登録されたデバイスの 設定アシスタントを使うには インターネット接続が 必要になります Macが初めて設定され ネットワークに繋がれば Macは組織が所有していると 認識されます 例えば その後にMDMが 「すべてのコンテンツと設定を消去」 を開始したり デバイスが Configuratorで 復元されたりすれば ネットワークは つまり デバイス登録も 設定アシスタントでは 迂回されません 今後 AppleSeed for ITから タイミングについてのお知らせが あります プロファイルコマンドラインツールは 長年に渡って MDMの展開や移行や レポーティングにおいて 管理者ツールキットの 定番でしたが macOS Ventura用に アップデートを施しました プロファイルツールはまず macOSのレート制限を 実施します これは組織所有の 登録タイプのみが対象で showや renewや validateの コマンドへのレート制限です 各コマンドがサーバーから 要求される上限は １日に10回で その回数を越えた場合は キャッシュされた情報として 結果が戻ってきます 10回中の１回を 使いたくない場合は showコマンドには新たな オプションのフラグがあり キャッシュされた情報を 戻せます 詳細に関しては プロファイルマニュアルページで ご覧いただけます macOSをリリースする毎に これまでずっと ユーザー保護機能を 向上し続けてきました 今回のセキュリティ変更の 要点を紹介します iOS 10.3ではデフォルトの TLSトラストポリシーに 証明書ペイロードの 変更を加えて ユーザーの保護全般を 実施しました 今回はそれを macOSに適用することでー 手動でインストールされた 証明書ペイロードは キーチェーンアクセスを使って ユーザーが承諾しない限り TLS目的では信用されなく なるということです 証明書が MDMプロファイルに 埋め込まれていれば 今後も証明書を完全に 信頼し続けますが インタラクティブな 証明書のインストールを含む ワークフローはすべて 必ずアップデートしておきましょう 次は macOSの“Allow accessories to connect”で 身近なアクセスからの 攻撃からの保護を行います Appleシリコンをサポートする ポータブルMacでは 初期設定でユーザーに 新規サンダーボルトや USBアクセサリの接続を 解除時であっても 許可するか聞きます 承認されたアクセサリは ロックされた Macに ３日まで接続できます ロックされた Macに未知の アクセサリを繋げば Macのロック解除を 促されます MDMの観点から見れば 一括でのプロビジョニングや テスト施行などの ワークフローに 影響を与える可能性があります その対策として iOSおよび iPadOSと同様の 制限を macOSに対しても 利用しています 既存の allowUSBRestricted Mode制限によって 有線アクセサリは いつでも制限なく 接続できるようになっています またユーザーの同意の 要求を迂回できるよう 承認してくれます 注意したいのは これによりユーザーのシステムは 本質的に危険が増しますので 正当な業務上の要望が 無い限り この制限を使用するのは やめておきましょう その他の制限や ペイロード変更については 例としては 新しい allowUniversalControlや UIConfiguration ProfileInstallationですが ドキュメントを 必ずご覧ください 以上が macOS Venturaに 導入される 画期的変更のお話でした 今度はGrahamに iOSでのお話をお願いします ありがとう Nadia！ 今日は皆さんに iOSおよび iPadOS 16の デバイス管理に関する 数々の素晴らしい新機能を ご紹介します デバイスでのネットワーク トラフィック管理は データ保護の強化において 非常に重要だと言えます Appleデバイスでの トラフィック管理には 主に３つの方法があります VPNと DNSプロキシと Webコンテンツフィルタです 長年の間 AppごとのVPNを 提供してきましたが… 実際 ユーザー登録した デバイスでは MDMで使える VPNは このタイプのみです iOSおよび iPadOS 16では Appごとでの提供を拡大し DNSプロキシや Webコンテンツ フィルタも含まれるようになります これらの機能はすべての 登録タイプで利用可能ですが 特に有用だと考えるのは ユーザー登録で BYODにおける ppトラフィックの安全性を 組織が確認できる 最初の機会だからです これらの新機能の設定には ２段階のプロセスがあり AppごとのVPNの場合と 非常に類似しています その方法を簡単に 見ていきましょう まずは各ペイロードに 新規のキー値ペアを 与える必要があります Web Content Filter ペイロードでは ContentFilterUUIDで DNSプロキシには DNSProxyUUIDです これらのキーには 注意する点があります これらのキーの値は 任意の文字列になっていて キーがペイロードに 追加される時は MDM経由のみでしか インストールできません これらの新機能を使うには Appの設定が必要です InstallApplication コマンドか または Settingsコマンドを使って Appごとの機能を使う Appの属性に対して 同じUUIDを追加します ここの例では 両方のキーを含んでいますが どちらか１つだけを 含むこともできます 追加の詳細をいくつか 挙げておきましょう Appデベロッパは新たに 何か行う必要はありません 既存の DNSプロキシや Webコンテンツフィルタ Appが 問題なく使えます また 複数の DNSプロキシを 所有できますが システムごととAppごとを 混在させることはできません そして Webコンテンツ フィルタでは 最大７つの Appごとのフィルタと １つのシステムごとのフィルタが 所有できます 次は eSIM管理について お話します eSIMは世界中のキャリアで 新しい基準となり ここ２年ほど当社は eSIM管理をさらに 簡易化するために 数多くの MDM機能を 追加してきました MDMベンダーが これらの新機能を併せて いかに体験改善ができるか 少しお話して いきたいと思います eSIMを使用する 組織とお話を伺うと 主なタスクの中には 新規デバイスの プロビジョニングや キャリア間での デバイスの移動や 複数キャリアや 旅行でのローミングなどの 要件を持つユーザーの サポートがありました これらの目標を 達成するために 登録デバイスから データをクエリして それをキャリアに提供する 必要があります また デバイスに eSIMをインストールする 能力が必要です まずはデバイスのクエリと キャリアのデータ要求について 見ていきましょう DeviceInformation クエリなら デバイスからの データ収集は簡単です iOS 12では ServiceSubscriptionsキーで iPhoneや iPadの通信関係の すべてのデータを 簡単に収集できるように なりました これらのレスポンスから 便利な点が見て取れますね ServiceSubscriptionsで ２つのアイテムを戻すデバイスは ２つのアクティブな モバイル通信プランをサポートします レスポンスに EIDがあれば それは eSIMです iPhone 13や iPhone SE （第３世代）などの新デバイスは ２つのアクティブキャリア eSIMプロファイルをサポートし ServiceSubscriptionsの レスポンスに eSIMを１つ以上戻す 可能性があります EIDはデバイスごとに 固有のものです iOSおよび iPadOS 16から ServiceSubscriptions レスポンスでも現れる データを戻す otherDevice Informationクエリは 非奨励となり 今後の OSバージョンで 再登場することはありません デバイスからのデータ収集 方法は分かったので それをキャリアに渡すために 何が必要かを見ましょう 通常 デバイスに eSIMを設定するには ４つのデータが必要です IMEIと EIDと シリアル番号と電話番号です これらすべてのデータを含む レポートを作成する 能力を管理者に与えれば eSIMの起動および実行は 非常に容易になります これらをすべて併せて 実際に見ていきましょう まず MDMサーバーが ServiceSubscriptionsクエリで デバイスから必要データを 収集します 次に管理者がそのデータを キャリアに送ります 最後にキャリアが デバイスの eSIMを eSIMサーバーで プロビジョニングします 今度は デバイスに インストールされた eSIMを見ていきます キャリアはクライアントに サーバーURLを提供し そこでデバイスは Refresh CellularPlansコマンドで eSIMを取得します サーバーは RefreshCellularPlansPlans コマンドをデバイスに送り これがキャリアのeSIM サーバーを始動し eSIMが入手可能か チェックします 可能ならユーザーの インタラクションも必要なく 自動でダウンロードおよび イントールします MDMサーバーは Service Subscriptionsクエリで 空でない電話番号が 戻された場合は eSIMのインストールに 成功したと確認します 覚えておきたい点を いくつか確認しましょう eSIMのインストールは １回限りの操作で 将来同じデバイスへの eSIMの インストールを要求すると キャリアは新しいeSIMの プロビジョニングが必要です ユーザーが誤って eSIMを削除するのを 防ぐために allowESIMModificationの 制限を使いましょう その制限が インストールされた場合は RefreshCellularPlansコマンドで eSIMがインストールできます そして MDMは デバイス削除の時点で eSIMも削除する 可能性があります それを避けるために EraseDeviceコマンド送信時は 必ずPreserveDataPlan キーをTrueに設定しましょう この情報で eSIMの管理や デプロイの方法が 明確になれば幸いです 次は共有iPadに対する アップデートのお話です 共有iPadは教育やビジネスで 非常に有益に １対多の環境で iPadを 使える方法であり ユーザーの個人体験は きちんと確保されます 今年のわずかな変更で 共有iPadはさらに 便利になります まず ManagedAppleID DefaultDomainsを SharedDeviceConfiguration Settingsコマンドに追加しました このコマンドでユーザーの 管理対象Apple ID入力が 簡単になります ユーザーが管理対象Apple IDの入力を始めると ドメイン名の タイピング候補が 自動的に現れ ユーザーは タップするだけです Settingsコマンドはどんな サイズのリストも受け入れますが ユーザーには３つだけが 表示されます 次に話すのは リモート認証の要求に 関する変更です 現在 共有iPadでは だいたい７日ごとに リモート認証を要求します iPadOS 16では 共有iPadは 既存のユーザーに対して ローカル認証のみを行います 管理者がリモート認証を 実施したい場合には OnlineAuthentication GracePeriodキーを SharedDeviceConfiguration Settingsコマンドに設定 することができます このキーは リモート認証間の日数を 表す整数値になっていて ゼロ値は全てのログインに リモート認証を 要求することになります ManagedAppleID DefaultDomainsも OnlineAuthentication GracePeriod値も DeviceInformation クエリから取得可能です 最後は 共有iPadの クォータに関する説明です 共有iPadのクォータ管理には SharedDeviceConfiguration コマンドが１番です クォータの設定には ２つのキーが使えます QuotaSizeと ResidentUsersです どちらのキーを使っても 結局 OSはストレージ クォータを計算します では例を見てみましょう このiPadにはユーザーデータ用に 35GBのフリースペースがあります SharedDeviceConfiguration Settingsコマンドを送って ResidentUsersを３に設定 するようデバイスに求めれば 各ユーザーのクォータは 11.67GBだと計算します あるいはデバイスに 10GBのクォータサイズを 要求すれば 各ユーザーは10GBの クォータを与えられます デバイスの既存ユーザーが ３人の場合に ４人目がログインを 試みれば 既存ユーザーの１人のデータを デバイスから排除して 新規ユーザーのスペースを 作ろうとします クォータサイズの例では ５GBのフリースペースが 残っていますが ４人目のユーザーに対し 要件を満たさないため やはり１人のユーザーが が削除されます 今から見る 別のシナリオでは クォータを変更せずに デバイスの ユーザー数を調整する 方法が示されています シナリオでは元々 35GBのフリースペースが 残っていました どうやらiPadの 全スペースのうち 25GBがAppやBooksに 占められているようです 少し調べると このデバイスのAppには 使わなくなったものが あると分かりました Appライブラリを整理し フリースペースがさらに 10GB増えたので… つまり4人目のユーザーが ログインした場合 別のユーザーを削除する 必要がなくなりました！ またご存知とは思いますが iOS 13.4から キャッシュされたユーザーが デバイスにいない限り クォータサイズはいつでも 調整が可能です これらの点を覚えておけば 共有iPadのデプロイは 最高の状態で行えるでしょう MDMプロトコルおよび 挙動の変更を伴う iOSおよび iPadOSの アップデートをまとめます Appleデバイス標準内蔵の アクセシビリティ機能で デバイスの持つすべてを 誰にでも体験してもらえます 従来は 個々のユーザーが アクセシビリティ設定を 有効にする必要がありました ですが iOSおよび iPadOS 16では アクセシビリティ設定の多くを MDMが管理できるようにする 機能を追加してあります 機能の例はテキストサイズや VoiceOverやズーム機能 タッチ調整や ボールドテキスト 視差効果を減らすや コントラストを上げる そして 透明度を下げる です このようなオプションを 利用することで 管理者は学校やレストランや 病院でのデバイスを全ユーザーに アクセス可能にできるでしょう このような設定には ロックはかからないので ユーザーは独自の好みで 自由に変更することができます MDMサーバーも DeviceInformationクエリで これらの設定のクエリが 可能になっています 次は iOSおよび iPadOS 16から 始まりますが 自動デバイス登録中で AwaitDeviceConfiguredの 状態にあっても Appの インストールが可能になります ですが覚えておきたいのは この段階では恐らく App Storeには誰も サインインしていないので デバイスベースのAppライセンスを 使うといいでしょう セットアップで監視されていない デバイスはホームスクリーンに 到達するまで NotNowを 戻してきます この機能を使えば デバイスにはユーザーが 設定アシスタントを 終了するまでに必要な すべてが揃います デバイスのセキュリティを 改善し続けているため 最初の解除前には ある種のデータタイプが アクセス不可になります それゆえ CertificateList クエリは 最初のロック解除までは NotNowを戻し始めます ユーザーがデバイスを ロック解除したら デバイスの再起動まで クエリは普通に応答します MDMデベロッパは サーバーがNotNowを クエリの応答として 対応できるようにしてください そして Apple TVも アップデートされました tvOS 16からは Apple TVを削除した場合… 設定からの削除でも MDM経由の削除でも… リモコンはペアリング されたままになります Auto Advanceと合わせれば Apple TVはいつでも リフレッシュされて 使用可能になります 今日お話した全ての 内容に加えて 変更点は色々ありますので developer.apple.comの ドキュメントでどうぞ ドキュメントと言えば 前回の WWDCで MDMドキュメントに 新たな改善を加えました この変更で ドキュメントは さらに正確で最新に なりましたが 特定の OSリリースでの 変更を強調する 機能もついたわけです このドキュメントは 非常に好評で さらに嬉しいことに このドキュメントを 支えるソースコードが Appleの GitHubページで 新デバイス管理プロジェクトの MIT Open Source Licenseの下で 一般入手可能になっています どんな内容なのか 見てみましょう ２つのフォルダがあり １つはＭＤＭ ドキュメントの全内容 もう１つは新しい 宣言型デバイス管理 ドキュメントで READMEファイルと ライセンス情報もあります MDMフォルダの中に 入っているフォルダは checkinと commandsと profilesです 宣言型管理の方には declarationsと protocolと statusファイルです これらのファイルの 中身を見る前に 各コマンドやプロファイルや 宣言の YAMLファイルがあります これらのファイルに役立つ いくつかのアイテムについて 焦点を当てていきます まずはペイロードキーです これは MDMコマンドの リクエストタイプを示します この例では ProfileListで デバイスにインストールされた 全プロファイルのリストを 戻してきます 次は supportedOSキーで プラットフォームに特化した 情報を与え 例えば OSやバージョンの サポートの他に 監督を必要とするかだとか ユーザー登録で十分かなども 教えてくれます ここでは iOS 4で導入された ProfileListキーです ペイロードキーは クエリが提供する 追加の機能に関する 情報を与えてくれます 各サブキーに含まれ得る追加の supportedOSキーは 上にあるペイロードの値を 無効にします ProfileListクエリは iOS 4での導入ですが ManagedOnly機能は iOS 13で初導入です 他の情報はすべて 以前と同じままで 監督も必要なく ユーザー登録で クエリが使えます ProfileListクエリの場合 MDMサーバーに 応答を戻します レスポンスキーが 情報の詳細を示します ここではインストールされた 各プロファイルを 記述する辞書の配列が 出ると予測されます その辞書の中には PayloadUUIDや PayloadIdentifier などを含む キー値のペアがあります これはほんの一例で スキーマや リポジトリの構造の 総合的な情報に関しては READMEをご覧ください その詳細を少し 見てみましょう データのパブリッシュは iOS 15と macOS Montereyの 初期リリースに遡ります 以来 新リリースや シードがある毎に 新ブランチを出し続け つまり iOS 16と macOS Venturaの ドキュメントも 今すぐ ここで ご覧になれるわけです この新しいデータ内の 多くのユースケースを参考に 新ツールや興味深い統合を ぜひ生み出してください！ データを利用される際は フィードバックアシスタントで 状況をお知らせください 今日は盛りだくさんでしたね もう一度おさらいしましょう iPhone用Apple Configuratorは iPadにも追加され 組織にとっては デバイスの管理やデプロイが より簡単になります IDの面では Google Workspaceの統合と Enrollment SSOや Platform SSOで より一貫性のある 認証が可能になります Nadiaが言ったように macOS Venturaは より多くの情報を 提供してくれるため 組織のソフトウェアアップデート 管理が容易になります Macの削除や復元後における 設定アシスタントで ネットワーク接続を 要求することにより 自動デバイス登録は 性能アップです 最後は デプロイに影響する 重要なセキュリティ変更を お伝えしました iOSおよび iPadOS 16では DNSプロキシと Webコンテンツ フィルタは Appごとで管理可能です iPhoneやiPadでのeSIM 管理のツールも見ましたね 共有iPadへの機能強化や MDMプロトコルの変更に ついてもお話し 設定アシスタント中の Appインストール機能もありました 新しい 機械が読み取れる ドキュメントを ぜひ 新ツール作成や統合に 役立ててください 本日は ありがとうございました 残りの WWDCも お楽しみください！