
管理対象デバイスの認証を導入する
管理対象デバイスの認証は、管理対象デバイスを保護するための強力なテクノロジーで、デバイスプロパティの難読化、キーの抽出、なりすましなど、さまざまな種類の攻撃の阻止に役立ちます。管理対象デバイスの認証は、次の2つのテクノロジーで構成されています:
デバイス情報の認証は、デバイス管理サービスの
DeviceInformationクエリに応答して、管理対象デバイスの認証済みプロパティを提供します。これにより、デバイス管理サービスに、デバイスのセキュリティとコンプライアンスに関する重要な情報が提供されます。ACME認証は、依拠当事者に対してデバイスの身元を証明し、ハードウェアにバインドされた識別子をデバイスにプロビジョニングします。クライアントは、ACMEサーバから証明書を要求する際に、同じ認証済みプロパティを提供します。
この2つのテクノロジーは、Appleデバイスに基づいてゼロトラストアーキテクチャを作成するための強力な構成要素です。管理対象デバイスに基づいて構築された導入モデルが認証を適切に組み込んでいる組織のみが、セキュリティ上の利点を得られることに注意してください。このページでは、利用可能ないくつかの導入モデルを説明しています。
コンポーネント
管理対象デバイスの認証に基づく導入モデルには以下のコンポーネントが必要です:
デバイス: 管理対象となるデバイス(iPhone、iPad、Mac、Apple TV、またはApple Vision Pro)。
デバイス管理サービス: デバイス管理プロトコルを使用してデバイスを管理するサービス。
ACMEサーバ: デバイスにクライアント証明書を発行するサーバ。
依拠当事者: IDの証明書を使用する当事者。Webサーバ、VPNサーバ、署名付きメールメッセージの受信者などが含まれます。デバイス管理サービスは依拠当事者としても動作します。
導入モデル
ここでは3つの導入モデルについて説明します。あとのものほど柔軟性が増しますが、インフラストラクチャ要件および統合で要求されるものも増大します:
デバイス管理チャンネルを保護する: このモデルは、デバイスおよびデバイス管理サービス間の通信を堅牢化します。デバイス管理サービスはどのデバイスを管理しているかを確実に認識でき、デバイスが組織のポリシーに準拠していることの強力な証拠を提供します。
ACMEサーバが主導する認可: 認証局がデバイスの認証と認可を制御します。依拠当事者は、証明書が有効であるかどうか、信頼できる認証局から発行されていることを評価するだけです。
差異化された認可: ACMEサーバが認証を担当し、認証に基づいて依拠当事者が認可を実行します。各依拠当事者が独自の差異化された認可を意思決定できます。
デバイス管理チャンネルを保護する導入モデル
このデバイス管理プロトコルは、デバイス自身がクライアントIDを使用してデバイス管理サービスから認証されることを要求します。このIDはデバイス登録時にプロビジョニングされます。この導入モデルでは、クライアントIDのプロビジョニングでACME認証が使用されます。デバイス管理サービスには、各受信接続が登録されている正当なAppleデバイスそのものから開始されているという非常に強い保証が提供されます。登録がユーザ登録でないときでも、デバイス管理サービスにはデバイスのシリアル番号およびUDIDが非常に強い証拠として提供されます。
この導入モデルでは、デバイス管理サービスから認証されるために、管理対象デバイスによってのみ発行されたIDが使用されます。これは、デバイス管理サービスが依拠当事者でもあり、通常は証明書を発行するインスタンスであることを意味します。

この導入モデルを使用するために、デバイスにACMEペイロードを含む登録プロファイルを提供することで、登録時にIDがプロビジョニングされます(ただし、最初に管理対象デバイスの認証を使用しなかった既存の登録を「アップグレード」することはできます)。デバイスは、提供された情報を使ってデバイス管理サービスのACMEコンポーネントに問い合わせ、証明書を要求します。 カスタムルールを使用することもできますが、通常は以下の場合に証明書が発行されます:
デバイスが事前に既知である。例えば、Apple School ManagerまたはApple Business Managerに登録されている。
デバイスがユーザによって認証された登録に関連付けられている。
デバイス管理サービスは、デバイスが登録されたあと、デバイスが組織の要件を満たすまで、デバイス情報認証を使用して認証済み動的プロパティ(オペレーティングシステムバージョンやFileVaultステータスなど)を照会することでアプリ、構成、およびアカウントを保留できます。
関連する変更が発生したときは、同じアプローチを使用して新しい認証を要求できます。
このシナリオのより複雑な設定では、デバイス管理サービスの外部のACMEサーバが必要です。これには、デバイスと登録認証ステータスに関する情報を取得するためにACMEとデバイス管理サービスを統合するか、デバイス管理サービスが信頼評価を実行するために認証からの永続情報を含む証明書を発行する必要があります。
ACMEサーバが主導する認可導入モデル
この導入モデルでは、デバイスの認可は発行された証明書が信頼できるかどうかにのみ基づきます。ACMEサーバは、ACMEフロー中に証明書を発行するかどうかを判断します。その判断が認証証明書に入っていない情報を必要とする場合は、ACMEサーバが収集する必要があります。ACMEサーバは、信頼評価が合格し、デバイスが組織によって定義された条件を満たしている場合にのみ、証明書を発行します。
例えば、認可済みデバイスがデバイス管理サービスに登録されていることを組織が要求する場合は、ACMEとデバイス管理サービスの接続が必要です。

この導入モデルは、同じ認可条件を使用する依拠当事者が多いときに最適です。ACMEサーバが信頼評価を実行したあとは、依拠当事者が実行する必要があるのはアクセスを検証するための標準証明書検証と信頼評価だけです。
注記: セキュリティ要件によっては、認可を失ったデバイスを導入モデルがどのように扱うか(証明書有効期限を調整する、依拠当事者が失効をチェックするなど)を検討することをおすすめします。
差異化された認可導入モデル
この導入モデルでは、ACMEサーバがデバイスを認証する証明書の発行のみを担当します。依拠当事者は、デバイスのID証明書を評価するたびに認可を判断し、独自の、個別の認可ルールを適用します。
ACMEサーバは、依拠当事者がデバイスを識別および認可するために必要なステートレス情報(例えば、認証証明書でACMEサーバが受信したデータ)を発行済み証明書に含めます。

依拠当事者は、デバイスが接続するときに、発行済み証明書の信頼を確認するだけでなく、デバイス管理サービスに動的プロパティを照会することもできます。これにより、最新の情報に基づいて認可を判断することができ、認可解除および再認可イベントにも対応できます。組織の要件と依拠当事者の重要度に応じて、接続イベントの繰り返しに対処し、認可の判断を高速化するために、認可の判断を定義した期間キャッシュすることもできます。