デバイス管理はどのように機能するのでしょうか？

デバイス管理は、中央管理サーバーと、管理対象のすべての登録済みデバイスとの間に、ポリシーによって強制される永続的な通信チャネルを確立することで機能します。従業員が社用のMacBookやiPhoneの電源を入れると、そのデバイスはMDMサーバーに接続し、設定指示を受け取り、コンプライアンス状況を報告します。これらすべては、ユーザーが通常のログイン以外の操作を行うことなく行われます。

このプロセスの仕組みを理解することは重要です。なぜなら、選択するアーキテクチャによって、実際にどのようなポリシーを適用できるか、セキュリティインシデントにどれだけ迅速に対応できるか、そしてエンドユーザーにどの程度の負担がかかるかが決まるからです。本ガイドでは、基盤となるプロトコルから実際の登録ワークフローに至るまで、デバイス管理の仕組みを詳細に解説します。

MDMを支える技術アーキテクチャ

モバイルデバイス管理（MDM）は、クライアント・サーバーモデルに基づいて構築されています。MDMサーバーには、ポリシー、証明書、および設定データが格納されています。登録された各デバイスは、管理エージェントを実行するか、OSレベルに組み込まれたMDMクライアントを使用します。両者はHTTPSを介して通信し、登録時に発行されたPKI証明書を通じて身元が確認されます。

特にAppleデバイスに関しては、すべてのトランザクションに3つ目のコンポーネント、Apple Push Notification Service（APNs）が存在します。Appleは、MDMサーバーが任意のタイミングでデバイスに直接アクセスすることを許可していません。その代わりに、MDMサーバーはAPNsを介してプッシュ通知を送信し、デバイスを起動させます。 その後、デバイスはMDMサーバーへのセキュアな通信チャネルを開き、保留中のコマンドを取得して実行し、結果を報告します。このプル型モデルでは、最終的な接続は常にデバイス側から開始されるため、セキュリティ上の重要な利点があります。つまり、MDMサーバーは各デバイスへの直接的なインバウンド接続を一切必要としないのです。

一般的なMDMコマンドの流れは次のようになります：

1. 管理者がMDMコンソールでアクションをトリガーする（構成プロファイルのプッシュ、リモートワイプの実行、FileVaultステータスの照会など）

2. MDMサーバーがAPNsにプッシュペイロードを送信する

3. APNsが対象デバイスにウェイク信号を送信する

4. デバイスがHTTPS経由でMDMサーバーに直接接続する

5. デバイスが保留中のコマンドをダウンロードして実行する

6. デバイスが結果をサーバーに報告する

このアーキテクチャのため、APNsの証明書管理は省略できないメンテナンス作業となっています。APNsの証明書の有効期限が切れると、管理下のすべてのAppleデバイスにおいてMDMサーバーが機能しなくなります。

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

従来のMDMはコマンドベースです。つまり、サーバーがデバイスに何かを行うよう指示し、デバイスがそれを実行し、サーバーが確認するという流れです。これは機能しますが、大規模になるとポーリングの問題が生じます。5,000台のMacからなるフリートでは、コンプライアンス状態を確認するための絶え間ないチェックインが、大きなオーバーヘッドを生み出します。

iOS 15およびmacOS 13で導入され、その後大幅に拡張されたAppleの宣言型デバイス管理（DDM）は、このモデルを逆転させます。サーバーはコマンドを発行する代わりに、望ましい状態を宣言します。 デバイスは、その状態に自律的に到達し、維持する責任を負います。設定がずれても、デバイスはサーバーからのチェックを待たずに自ら修正を行います。

実際には、DDM経由で登録されたMacは、必要な証明書の有効期限が切れたことを検知し、再申請を行い、更新されたステータスをサーバーに報告することが可能です。これらすべてが、管理者の介入なしに実行されます。 コンプライアンスの監視において、DDMは従来のMDMのような段階的なチェックインスケジュールではなく、ほぼリアルタイムでのステータス報告を可能にします。これは、大規模なAppleデバイスを運用するITチームにとって、非常に有意義な運用上の改善となります。

デバイスの登録の仕組み

登録とは、デバイスとMDMサーバーの間に信頼関係を確立するプロセスです。使用する方法によって、管理機能やユーザー体験が決まります。Appleデバイスの管理には、主に3つの登録方法があります。

Apple Business 経由の自動デバイス登録

自動デバイス登録（ADE）は、企業が所有するAppleハードウェアにおける標準的な手法です。組織がAppleまたは正規販売代理店を通じてデバイスを購入すると、それらのデバイスはApple Businessアカウントに登録されます。 Apple BusinessをMDMサーバーに連携させると、それ以降、発注書に含まれるすべてのデバイスは、ユーザーがセットアップ画面に到達する前に、アクティベーションが行われた瞬間に自動的にMDMに登録されます。

これこそが、真のゼロタッチ展開を可能にする仕組みです。新入社員が箱を開け、MacBookの電源を入れ、Wi-Fiに接続するだけで、デバイスは自動的に設定されます。必要なアプリのインストール、セキュリティポリシーの適用、社内Wi-Fiへの接続、暗号化の実施など、すべてIT部門がハードウェアに触れることなく行われます。 また、ADEによる登録は「監督モード」で行われるため、常時接続VPN、シングルアプリモード、AirDropやiCloudバックアップの制限など、最も高度な管理機能を利用できます。

BYOD向けのユーザー登録

BYOD（Bring Your Own Device）のシナリオでは、Appleは「ユーザー登録」を提供しています。これにより、ファイルシステムレベルで個人データと管理対象データを暗号技術を用いて分離します。 MDMサーバーは、業務関連のデータやアプリのみを認識・管理できます。個人の写真を照会したり、デバイス全体を初期化したり、個人用アプリの使用状況を追跡したりすることはできません。これは従業員の信頼を確保する上で重要であり、また、さまざまな法域におけるプライバシー規制への準拠においても、ますます重要になっています。

「ユーザー登録」は、IT部門の権限を意図的に制限する仕組みであり、個人所有のデバイスにおいては適切なバランスが取れています。アプリの展開、業務用アカウントの設定、および企業データの削除は可能ですが、デバイスの完全なインベントリ管理やリモートワイプは利用できません。

WebベースおよびQRコードによる登録

Apple Businessを通じて購入されていないデバイス、またはゼロタッチワークフロー以外で管理対象に追加する必要があるデバイスについては、Webベースの登録により、ユーザーがURLにアクセスして認証を行い、登録プロファイルをダウンロードすることができます。 QRコードによる登録は、共有デバイスやキオスク端末において、このプロセスをさらに簡素化します。これらの方法は、ADEと組み合わせた場合にのみ監督対象となるため、管理の深度は自動登録よりも低くなります。

ポリシーの適用と構成プロファイル

登録が完了すると、デバイスには設定プロファイル（デバイスの設定を定義するXMLペイロード）が配信されます。1つのプロファイルで、企業のWi-Fiネットワークの設定、パスコードの最低複雑度の適用、ルートCA証明書のインストール、VPNサーバーアドレスの設定などが行われる場合があります。デバイスはこれらの設定を適用し、管理対象デバイスでは、ユーザーが設定を削除したり上書きしたりできないようにします。

ポリシーの適用は、プロファイルの制限とコンプライアンスチェックの組み合わせによって行われます。制限により、ユーザーが特定の操作（FileVaultの無効化、App Store以外からのアプリのインストール、DNS設定の変更など）を行うことが防止されます。 コンプライアンスチェックは、デバイスの状態が必須パラメータと一致しているかを確認し、デバイスがコンプライアンス要件を満たさなくなった場合に自動対応をトリガーします。例えば、条件付きアクセス機能との連携により、メールへのアクセスをブロックすることが可能です。

確立されたセキュリティベースラインの達成を目指すITチームにとって、macOS向けのCISベンチマークやモバイルデバイス管理に関するNIST SP 800-124ガイドラインは、いずれもMDMプロファイルを通じて適用可能な設定に直接対応しています。 SOC 2 または HIPAA のコンプライアンスを追求する組織にとっては、ディスク暗号化、画面ロック、監査ログなど、多くの必須制御が具体的な MDM プロファイル設定に反映されていることがわかります。

アプリケーションの管理と展開

デバイス管理は、アプリのライフサイクル全体を扱います。管理対象アプリの場合、MDMサーバーはユーザーの操作を必要とせずに、アプリケーションのインストール、更新、および削除を自動的に実行できます。Apple Businessボリュームライセンスを通じて購入されたアプリは、個人のApple IDではなくデバイスに割り当てることができます。これにより、従業員が退職してもアプリのライセンスは組織に残ります。

アプリケーション管理には、以下の機能も含まれます：

• 管理対象アプリの設定：インストール時にアプリ設定（サーバーURL、認証トークン、機能フラグ）をアプリに直接プッシュすることで、ユーザーが空のセットアップ画面ではなく、完全に設定済みのツールを起動できるようにします
• アプリの許可リストおよびブロックリスト：管理対象デバイスにインストール可能なアプリを定義します
• 必須アプリ：アプリを「必須」としてマークすると、登録時、または後でポリシーに追加された際に自動的にインストールされます
• 更新管理：ユーザーによる手動更新に依存するのではなく、メンテナンス時間帯内にOSおよびアプリの更新をスケジュールまたは強制的に実行します

セキュリティ制御：暗号化、コンプライアンス、およびリモート対応

デバイス管理とセキュリティは、ますます切り離せない関係になっています。管理レイヤーは、セキュリティチームが必要とする技術的な制御を実施する場です。Apple デバイス群の場合、これには以下が含まれます：

• FileVaultの適用：ディスクの暗号化を必須とし、MDMサーバーへの復旧キーの預託を義務付けることで、ユーザーが不在の場合でもIT部門がデバイスを復旧できるようにします
• アクティベーションロックの管理：デバイスの盗難により、企業のハードウェアが永久に使用不能になるのを防ぎます
• リモートワイプおよびロック：紛失報告を受けてから数秒以内に、リモートでデバイスの完全ワイプまたはパスコードロックを実行
• 証明書のライフサイクル管理：ユーザーの関与なしに、証明書の展開、ローテーション、失効処理を行う
• コンプライアンス監視：OSのバージョン、セキュリティパッチの状態、ファイアウォールの状態、SIPの状態、Gatekeeperの設定を継続的に検証します

ここで重要なのが、ゼロトラストアーキテクチャとの関連性です。ゼロトラストでは、デバイスはその状態が確認されるまで、すべて信頼できないものとみなされます。デバイス管理は、その状態データを生成・検証する仕組みです。従業員が企業のアプリケーションに認証を行う際、IDプロバイダーは認証情報だけでなく、MDMプラットフォームから取得したデバイスの健全性シグナルも確認します。 OSが最新版ではなく、FileVaultが無効になっているデバイスは、このチェックに失敗し、有効な認証情報を持っていてもリソースへのアクセスがブロックされます。

企業所有デバイスとBYOD：状況に応じた異なるモデル

導入する管理モデルは、デバイスの所有権とユースケースに大きく依存します：

両方のユーザー層を抱える組織にとっては、両方の登録タイプを適切に処理できる単一のMDMプラットフォームが重要です。企業所有デバイスとBYODデバイスで別々のツールを使用したり、手動プロセスを採用したりすると、資産管理の死角が生じ、ポリシーの適用に一貫性が失われます。

デバイス管理と広範なITスタックとの連携

MDMは孤立して動作するものではありません。最新のデバイス管理プラットフォームは、以下のサービスと連携します：

• IDプロバイダー（Okta、Microsoft Entra ID、Google Workspace）：ユーザーおよびグループデータを同期し、手動での割り当てではなくディレクトリのメンバーシップに基づいてデバイスポリシーが適用されるようにします
• SIEMおよびロギングプラットフォーム：セキュリティ監視のために、デバイスのテレメトリデータやコンプライアンス関連イベントをエクスポートします
• チケット管理システム：人事システムによってトリガーされるプロビジョニングおよびデプロビジョニングのワークフローを自動化
• エンドポイントセキュリティツール：デバイスの健全性シグナルをEDRプラットフォームと共有し、脅威の検出と対応を連携させる

MDMプラットフォームによって、統合の深度は大きく異なります。IDプロバイダーへの接続にカスタムAPIやミドルウェアを必要とするものもあれば、リアルタイムで同期を行うネイティブコネクタを提供するものもあります。

Iruのデバイス管理へのアプローチ

Iruは「Appleファースト」のプラットフォームとして構築されています。つまり、MDMプロトコルの実装は、マルチOSツールから流用したものではなく、ネイティブに実装されています。Appleが新しいOSをリリースした際、Iruはベンダーの認証プロセスを経てプラットフォームの更新が行われるまで数週間待つことなく、リリース初日から新しい管理APIをサポートします。

中核となるアーキテクチャは、MDMとエンドポイント検出・対応（EDR）レイヤーを単一のエージェントに統合したものです。 Appleデバイスを運用する組織の多くは、MDMとEDRツールを別々に導入しており、両者の間でデータが直接共有されないため、インシデント発生時には手動での相関分析が必要となります。Iruはこれらのシグナルをネイティブに連携させます。つまり、コンプライアンス違反が検出されたデバイスは、人間が関連性を特定するのを待つことなく、セキュリティアラートと条件付きアクセスブロックを同時にトリガーすることができます。

ゼロタッチ展開については、IruのApple Business統合機能が、大規模なADEワークフローを処理します。 新しいデバイスは従業員の自宅やオフィスに直接配送され、Wi-Fiに接続されると自動的に登録され、ユーザーがmacOSセットアップアシスタントを完了する前に完全に構成されます。MDMサーバーは、デバイスレベルでの管理者の介入なしに、登録証明書、APNs通信、プロファイル配信を管理します。

また、Iruは宣言型デバイス管理（Declarative Device Management）をネイティブにサポートしているため、最新のOSバージョンを実行するAppleデバイス群は、新しいハードウェアに後付けされたレガシーなポーリング方式ではなく、Appleがプロトコルに組み込んだ自律的なコンプライアンス機能を活用できます。

CISベンチマークおよびSOC 2コントロールにマッピングされた事前構築済みのコンプライアンステンプレートにより、正当性を立証可能なベースラインの設定にかかる時間を数週間から数時間に短縮できます。監査人に対してコンプライアンスを証明する必要があるITチームにとって、適用されたすべてのコントロールは、デバイスレベルの監査証跡として記録されます。

自社のデバイス群に適したデバイス管理プラットフォームの選定

デバイス管理は、確立されたプロトコルスタックを通じて技術的なレベルで機能します。プラットフォーム間の違いは、実装の深さ、エコシステムとの適合性、そして基本的なMDMコマンドを超える機能にあると言えます。

Apple端末が多数を占める、あるいはApple端末のみの環境では、macOSやiOSを二次的な対象として扱うマルチプラットフォームツールと比較して、専用に設計されたApple MDMプラットフォームの方が、OSサポートの迅速化、DDMの導入促進、Apple Businessとの緊密な連携を実現します。

展開を構築する際は、確立されたデバイス管理のベストプラクティスに従ってください。全デバイスへの展開を開始する前に、テスト済みの登録ワークフローから始め、最初のデバイスを登録する前に、公認のベンチマーク（CISやNIST）に基づいたコンプライアンスポリシーを定義し、必要になる前にコンプライアンス違反デバイスのエスカレーション手順を策定しておきましょう。

Iruは、管理されていないAppleデバイス群を引き継いだITチームや、他のMDMプラットフォームから移行するITチーム向けに設計された、体系的な導入プロセスを提供しています。Mac、iPhone、またはiPadのデバイス群向けのデバイス管理オプションを検討されている場合は、IruがAppleデバイスの管理をエンドツーエンドでどのように handling しているかをご覧ください。