Apple MDM に VPN は必要か？三つのアクセス要件と一つの答え
Apple MDM は APNs とデバイス起点の HTTPS で動作し、LAN トンネルは使いません。VPN を追加する前に、管理、画面共有、プライベートアプリへのアクセスを分けて考えてください。
Apple デバイスの管理に暗号化が必要かどうかはめったに問われません、必要だからです。本当の問いは、Mac や iPad を管理できるようにする前に汎用の VPN が要るのか、ということで、インターネット経由で管理するほとんどの導入では答えは「いいえ」です。Apple はデバイスが独自のタイミングで管理サービスに到達することを許し、重要な通信はデスクトップセッションではなく署名付きのコマンド経路です。それがうまくいくかどうかは三つの条件で決まり、外から見るとどれもリモートアクセスに見えるため、混同しやすいのです。
伝送手段を選ぶ前に要件を名づける
管理コマンドと構成プロファイルが一つの要件、対話的な画面共有が二つ目、社内のプライベートアプリへの到達が三つ目です。所有者も認証も異なり、許容できる露出も大きく違うことがよくあります。これらを一つにまとめると、誰も説明できない公開ポート一覧が残ります。
三つの要件は同じ伝送手段を共有しません：
| Need | What actually carries it |
|---|---|
| Management commands and profiles | The enrolled device pulls from a service it can reach; APNs only wakes it |
| Interactive screen sharing | A remote-support tool or private desktop path with its own authentication |
| Private application access | That application's permitted network path, which may well be a VPN |
混乱はたいてい古いサーバーチェックリストから始まります。過去の OS X Server の文書は長いポート一覧を示しており、管理サービスがそのどこかにあるという理由で、誰かが境界ですべてを転送してしまいます。それは管理アーキテクチャではなく、公開しようとしていた制御面をはるかに超えて露出面を広げます。
プッシュ通知が実際にしていること
Apple が文書化している流れでは、管理サーバーが APNs 通知を送り、処理が待っていることをデバイスに伝えます。デバイスはその後、管理サーバーへの接続を開いて自分のコマンドを要求します。プッシュは玄関の呼び鈴であり、トンネルではありません、任意のペイロードも、リモートデスクトップセッションも、他のアプリの通信も運びません。
したがってデバイスは、目的のサービスに登録され、想定されたエンドポイントを信頼し、管理サービスと、その流れが依存する Apple のサービスとの両方に到達できる必要があります。 Apple のネットワーク準備ガイダンスにはそれらの依存関係が列挙されており、流れの中で交渉できる部分ではありません。社内ネットワークの中だけに存在する管理サーバーにも、デバイスが実際に使える対応済みの経路が必要です。 MDM と呼んでも、到達できないエンドポイントが到達可能になるわけではありません。
許可する経路を明示してください、途中にあるプロキシや TLS 検査の方針も含みます。想定された証明書チェーンを壊す検査装置は、登録の失敗とまったく同じに見えます。
VPN が誤った答えになる場合
管理サービスが適切な証明書でインターネットに公開され、すべての接続をデバイスが開始するなら、VPN は制御を増やさずに中継を一つ増やすだけです。デバイスはすでに登録 ID で認証しており、サーバーはすでに受け入れるコマンドを決めています。その手前にトンネルを置いても変わるのはネットワーク経路で、信頼の判断ではありません。
同じ制御面は VPN プロファイル自体も配信できます。この順序が重要です：管理された VPN 構成は、ただのもう一つのペイロードとして届くので、デバイスは、それを作るプロファイルを受け取る前にトンネルが存在している必要はありません。
VPN が正しい答えになる場合
管理エンドポイントをインターネットから到達可能にすべきでない構成もあります、それは勇気の不足ではなく、正当な設計です。規制の厳しい環境、小規模な社内 IT チーム、他の管理インターフェースも抱えるサーバーは、しばしばそこに落ち着きます。その場合、管理サービスの手前に保護されたアクセス経路を置くのは意図的なアーキテクチャであり、回避策ではありません。
画面共有とプライベートアプリへのアクセスも、通常は線のこちら側に属します。どちらもコマンド経路よりはるかに多くを露出し、どちらも登録 ID に便乗するのではなく独自の認証を持つべきです。
復旧を壊すブートストラップの罠
私が設計で備えるべき失敗はこれです：管理サービスへの唯一の経路が VPN を通り、そのデバイス上の VPN プロファイルや資格情報が期限切れになっています。デバイスは代替コマンドを取りにサーバーへ到達できず、サーバーは上がらないトンネル越しに何も押し出せません。復旧は、何百マイルも離れているかもしれない利用者に依存します。
復旧用に第二の独立した経路を用意してください、帯域外の管理経路、ローカル管理者、トンネルなしでも到達できる管理サービスのいずれかです。すべてが動いているうちに試してください、インシデントの最中にきれいな試験はできません。
次に、各経路が三つの要件のどれに応えるのかを書き出し、どれにも応えないポート転送を削除してください。汎用トンネルなしで管理でき、しかもトンネルが壊れたときに修復できる構成こそ、設計する価値のある結果です。