WWDC Quick Look 💓 By SwiftGGTeam
Explore advances in declarative device management

Explore advances in declarative device management

元の動画を見る

ハイライト

iOS 17、iPadOS 17、macOS Sonoma では、Apple は宣言型デバイス管理(Declarative Device Management)を新プロトコル機能の唯一の基盤とし、ソフトウェアアップデート管理、アプリ管理、システムサービス制限、証明書インストール、プロファイル移行などを追加しました。デバイスが自律的に管理ポリシーを実行し、サーバーポーリングなしで非同期に状態を報告できます。


主要内容

課題:大規模 fleet を従来の MDM で管理する際の痛点

企業の IT 管理者が数千台の Apple デバイスを管理する際、いくつかの核心的な課題に直面します:

  1. サーバーポーリングのオーバーヘッド:従来の MDM はサーバーがデバイスの状態を常にポーリングする必要があり、デバイス数に比例してサーバー負荷が増大する
  2. ソフトウェアアップデートの強制が困難:管理者はデバイスがタイムリーにシステムアップデートをインストールすることを保証する必要があるが、既存の MDM コマンド方式ではフィードバックが遅れ、更新が実際に完了したか確認できない
  3. 状態同期の遅延:FileVault の状態や証明書のインストール状況など、デバイス上の重要な情報をリアルタイムで把握できない

大規模組織ではこれらの問題が重なり、管理コストはデバイス数に比例して増加します。

Apple のアプローチ:宣言型デバイス管理

宣言型デバイス管理(DDM)は WWDC21 で初登場し、WWDC22 で基盤機能が強化され、WWDC23 では新プロトコル機能の重心が完全に DDM に移行しました。核心は、サーバーがデバイスに「宣言」(Declaration)を配信し、デバイスが自律的に評価・実行し、完了後に非同期で状態を報告するという考え方です。

デバイスはサーバーコマンドを待たず、事前設定されたポリシーに基づいて能動的に行動します。サーバーもポーリング不要で、状態レポートを受動的に受け取るだけです。

WWDC23 で追加された 5 つの主要管理領域:

  • ソフトウェアアップデート管理:設定で更新動作を定義し、デバイスが能動的に実行して進捗を報告
  • アプリ管理:エンタープライズアプリのインストール、設定、監視
  • システムサービス制限:システムサービスの制限とバックグラウンドタスクの監視
  • 証明書と ID 資格情報のインストール:デバイスに必要なセキュリティ資格情報を自動展開
  • プロファイル移行の簡素化:従来の MDM プロファイルから DDM への移行をスムーズに

詳細

宣言型ソフトウェアアップデート管理(03:33

従来の MDM では、管理者がコマンドでアップデートをインストールし、ポーリングでフィードバックを取得します。大規模 fleet では非効率です。

DDM のソフトウェアアップデート管理は設定(Configuration)で動作を定義し、デバイスが自律的に実行します:

{
  "Type": "com.apple.configuration.softwareupdate.enforcement.specific",
  "Identifier": "com.example.softwareupdate.ios17",
  "ServerToken": "abc123",
  "Payload": {
    "TargetOSVersion": "17.0",
    "TargetBuildVersion": "21A329",
    "DetailsURL": "https://example.com/update-info",
    "TargetLocalDateTime": "2023-10-01T10:00:00"
  }
}

キーポイント:

  • TargetOSVersion はターゲットのシステムバージョンを指定
  • TargetBuildVersion はビルド番号まで指定し、誤った seed や GM バージョンのインストールを防ぐ
  • TargetLocalDateTime は強制アップデートの期限を設定。それまではユーザーが自主的に選択可能
  • DetailsURL は組織内のアップデート説明ページを指す
  • デバイスが能動的にアップデートを実行し、非同期状態レポートでサーバーに進捗を通知

Predicates によるアップデート順序の制御(06:00

DDM は Predicates で複雑なアップデートロジックを実現できます。例えば、特定の順序でデバイスをアップグレードする制御が可能です:

{
  "Type": "com.apple.configuration.softwareupdate.enforcement.specific",
  "Identifier": "com.example.softwareupdate.critical",
  "ServerToken": "def456",
  "Payload": {
    "TargetOSVersion": "17.0",
    "Predicate": "device.model.family == 'iPhone' AND device.os.version >= '16.5'"
  }
}

キーポイント:

  • Predicate は宣言型構文で条件を記述
  • デバイスモデル、現在の OS バージョン、Rapid Security Response の利用可否などを条件にできる
  • デバイスが Predicate を自律的に評価し、条件を満たした場合のみアップデートを実行
  • デバイスタイプごとに異なるアップデートポリシーを設定可能

非同期状態レポート(06:14

DDM の核心的な利点の一つは非同期状態レポートです。状態が変化するとデバイスがサーバーへ能動的にプッシュします:

{
  "StatusItems": [
    {
      "Path": "softwareupdate.download",
      "Value": {
        "download-progress": 0.75,
        "download-state": "downloading"
      }
    },
    {
      "Path": "softwareupdate.install",
      "Value": {
        "install-state": "pending",
        "deadline": "2023-10-01T10:00:00"
      }
    }
  ]
}

キーポイント:

  • 状態レポートには download-progressdownload-stateinstall-state などのフィールドが含まれる
  • 管理者は各デバイスのアップデート進捗をリアルタイムで確認できる
  • サーバーポーリングが不要になり、ネットワークオーバーヘッドが大幅に削減
  • 状態レポートはデバイス起点。オフライン時も接続復帰後に送信される

FileVault 状態レポート(03:45

macOS の FileVault ディスク暗号化状態を DDM で非同期報告できるようになりました:

{
  "StatusItems": [
    {
      "Path": "security.filevault",
      "Value": {
        "enabled": true,
        "personal-recovery-key-escrowed": true,
        "institutional-recovery-key-present": false
      }
    }
  ]
}

キーポイント:

  • enabled は FileVault が有効かどうかを示す
  • personal-recovery-key-escrowed は個人回復キーがサーバーにエスクローされているかを示す
  • 管理者は各デバイスを手動確認せずにコンプライアンスを確認できる

プロファイル移行の簡素化(03:54

従来の MDM プロファイルから DDM への移行時、WWDC23 では移行をスムーズにする新しい動作が導入されました。DDM 宣言を受信したデバイスは、既存プロファイルとの競合を自動処理でき、管理者の手動介入を減らせます。


重要ポイント

  1. MDM 製品に DDM サポートを追加する:MDM ソリューションを開発・保守しているなら、ソフトウェアアップデート管理をコマンド型から宣言型へ移行する。価値:Apple は今後の新プロトコル機能は DDM のみで提供すると明言しており、DDM 非対応の製品は徐々に遅れを取る。始め方:GitHub で公開されている Device Management Client Schema を読み、com.apple.configuration.softwareupdate.enforcement.specific 宣言タイプを実装する

  2. ソフトウェアアップデートコンプライアンスダッシュボードを構築する:DDM の非同期状態レポートで、fleet 内の各デバイスのアップデート進捗をリアルタイム表示するダッシュボードを作る。価値:従来の MDM はポーリングが必要で状態に遅延があるが、DDM の状態レポートはリアルタイムで、より迅速な対応が可能。始め方:MDM サーバー側で状態レポート受信エンドポイントを実装し、softwareupdate.downloadsoftwareupdate.install パスの状態項目を解析、WebSocket でフロントエンドダッシュボードへプッシュ

  3. 段階的ローリングアップデート戦略を実装する:Predicates でアップデート順序を制御し、テストグループのデバイスを先にアップグレードして互換性を検証後、本番環境へ展開。価値:大規模 fleet の同時更新はリスクが高く、段階的展開で障害の影響範囲を縮小できる。始め方:デバイス名に “test” を含むデバイスにマッチする Predicate と全デバイスにマッチする Predicate を定義し、異なる TargetLocalDateTime 期限を設定

  4. FileVault コンプライアンスチェックを自動化する:FileVault 状態レポートで、FileVault 未設定や回復キー未エスクローのデバイスを自動フラグ付け。価値:セキュリティコンプライアンスは企業の硬性要件だが、手動チェックは非効率で見落としが起きやすい。始め方:MDM サーバーで security.filevault 状態レポートを購読し、enabled が false または personal-recovery-key-escrowed が false の場合に自動アラートまたは FileVault 設定の再配信をトリガー


関連セッション

コメント

GitHub Issues · utterances