管理対象デバイス構成証明を使用すると、企業は Apple デバイスのセキュリティを検証し、企業ネットワークを保護できます。使用方法は次のとおりです。
セキュリティの背景
相互接続された世界では、デバイス ID の問題がオンライン セキュリティにおいて重要な役割を果たします。従来のセキュリティ モデルでは、境界防御さらに、デバイスの検証を試み、悪意のあるデバイスをブロックするファイアウォールも備えています。
境界防御の背後にある考え方は、ネットワーク (またはネットワークの一部) が外部からネットワークに侵入できる可能性のあるすべてのポイントでセキュリティが確保されるということです。
仮想プライベート ネットワーク (VPN) を介して境界を確立することもできます。VPN では、外部ユーザーが単一のデバイスまたはゲートウェイ (厳重に保護されている) を介して接続することのみが許可されます。
境界防御は、外部の攻撃者を寄せ付けず、内部ネットワークに侵入させないように設計されています。しかし、現代のモバイル時代では、デバイスはモバイルであり、ある場所から別の場所に移動するため、境界防御はもはや目的を果たしません。
今日のデバイスは小型化されており、隠すことができます。訪問者や従業員によっても、組織の境界防御の内側に簡単に持ち込まれる可能性があります。
これらの要因により、境界防御を使用して悪意のあるモバイル デバイスを検証および追跡する試みは無駄になります。
代わりに、ゼロトラストセキュリティモデルが使用されるようになりました。ゼロトラストの背後にある考え方は次のとおりです。すべてのデバイスまたはユーザーは検証されるまで疑わしい(「決して信頼しないでください、常に検証してください」)。
ゼロ トラストの中心的な理念の 1 つは、境界モデルを次のいずれかに置き換えることです。デバイスからリソースへの直接検証。
このモデルでは、ネットワーク上でアクセスされる各リソースがクライアント デバイスを直接検証し、デバイスがリソースへのアクセスを許可されていることを確認します。デバイスが検証されていない場合 (またはユーザーが認証されていない場合)、アクセスは拒否されます。
さらに、クラウド リソースの普及により、多くの組織リソースが分散され、セキュリティ境界の外側に配置されるようになりました。
ほんの数例を挙げると、直接サービス拒否 (DDoS)、中間者攻撃、ランサムウェアなどの外部境界の脅威は依然として存在します。
しかし、この種の攻撃ベクトルは通常、大規模な組織、ギャング、または国家の主体によって実行されます。そのため、異なるセキュリティ モデルが必要になります。
セキュリティと管理対象デバイス
Apple は、複数のリソースが関与する検証および信頼スキームを使用して、モバイル デバイスのセキュリティの問題を解決しています。
これには、Apple デバイスの Secure Enclave (Apple T2 チップを含む可能性がある新しい Apple デバイス上の領域、または専用の安全な領域) が含まれます。セキュア エンクレーブはハードウェア暗号化を使用し、各デバイスに関連付けられた安全な秘密キーを生成する機能も備えています。
Apple と組織がデバイスを保護するもう 1 つの方法は、モバイル デバイス管理 (MDM) サーバーを使用することです。
自動証明書管理環境 (ACME) サーバーも使用できます。ノンス(「Number-Once」または 1 回限りの安全な乱数)、および暗号化。
Apple が社内で提供するデバイス認証サーバー(DAS)。これには、既知のリリース済みおよび購入済みのすべての Apple デバイス、シリアル番号、デバイスの Secure Enclave の詳細のリストが含まれています。
Apple DAS は、ネットワークと通信しようとしているとされる Apple デバイスが実際にそのデバイスであることを Apple が検証できることを保証します。
これらのコンポーネントを組み合わせて使用すると、組織またはリソースが Apple デバイスが本物であることを確認できます。このプロセスは次のように知られています管理対象デバイスの構成証明(MDA)。
MDA用語
セキュリティは複雑なトピックであるため、ここで MDA のすべての側面を説明することはできません。いくつかの重要な概念についてのみ触れます。
その前に、MDA およびコンピュータ セキュリティ一般で使用される用語を少し説明します。
- 管理対象デバイス構成証明 - Apple デバイスをアサートおよび検証するプロセス
- MDM サーバー - Apple デバイスを管理する組織または Apple によって管理されるサーバー
- 暗号キー - ネットワーク上で安全な情報交換に使用される一意のエンコードされた番号
- PKI - 公開鍵インフラストラクチャ - セキュリティ目的で暗号鍵を管理するソフトウェア
- ACME - 証明書情報の交換を自動化するために使用される自動証明書管理環境プロトコル
- ACME サーバー - Apple デバイスを管理する組織または Apple によって管理される PKI 証明書サーバー
- ナンス - 暗号化において、ネットワーク通信の識別子として使用される 1 回限りの一意の (通常はランダムな) 数値。
- 境界 - 内部での不正な通信が許可されない、組織またはコンピュータを取り囲むネットワーク セキュリティ
- 脅威アクター - ネットワークまたはコンピューティング デバイスに対して攻撃を実行しようとする個人またはグループ
- 攻撃対象領域 - 脅威アクターがネットワークやデバイスに侵入または侵害する方法
- クライアント - ネットワーク、デバイス、またはコンピュータに接続しようとしているリモート コンピュータ
- 信頼評価 - 接続デバイスまたはユーザーの身元を確認するプロセス
- ポスチャ - コンピュータ セキュリティにおいて、信頼性の評価に役立つ、デバイスまたはユーザーに関する 1 つ以上の情報を含むプロファイル。
- UDID - デバイスを識別する固有のデバイス番号
- 証明書 - デバイス (通常はサーバー) に関する ID および検証情報を提供するためにネットワーク上で交換される暗号化されたファイル
- アテステーション - 事実の宣言。これが検証されると、ネットワークはデバイスまたはユーザーを信頼できるようになります。
ACME プロトコルは、インターネットセキュリティ研究会人気の Let's Encrypt サービスで使用されています。
ACME プロトコルは、HTTPS 経由で JSON 形式のテキストを使用し、IETF RFC 8555 で定義されています。ACME を使用すると、コンピュータは暗号化された証明書の交換を自動化し、安全な通信を高速化できます。
Apple のサーバーと MDM サーバーは、デバイス認証プロセスで ACME サーバーと通信するか、ACME サーバーを使用します。
ソフトウェアでは、証明書は暗号的に署名された事実です。署名がデバイスとともに検証されると、その証明書は信頼されます。法的な例えを使用して、証明書を、事実を述べる検証済みの署名済み宣誓供述書と考えてください。
組織サーバーは、接続デバイスを信頼するために必要なデバイス認証の量を決定できます。 Apple デバイスの場合、証明書にはデバイス ID、プロパティ、およびオプションで証明書、プロファイル、ユーザー ID などのその他の情報を含めることができます。
Apple Device Attestation を使用すると、これらの事実を受信して信頼することで Apple デバイスを検証できます。
デバイスの接続と検証
Apple デバイスがネットワークに接続すると、ネットワーク上のリソース サーバーがデバイスの検証を要求できます。
このプロセス中、接続デバイスは既存の MDM サーバーに接続するように要求され、これにより Apple のデバイス認証サーバーがトリガーされ、デバイスの Secure Enclave を使用してデバイスが検証されます。
最新の Apple デバイスにはそれぞれ独自のオンボード Secure Enclave (ハードウェア暗号化情報が含まれます) があります。 Secure Enclave がデバイスを検証すると、Apple の認証サーバーは、デバイスが有効であることを示す応答を MDM または組織のリソース サーバーに送信します。
検証が失敗した場合、デバイスは要求された組織リソースへのアクセスを拒否されます。 Apple はこのデバイス情報を Trust Foundation と呼びます。これには以下が含まれる場合があります。
- セキュアエンクレーブ
- Apple 認証サーバー
- 製造記録（シリアル番号を含む）
- オペレーティング システム カタログ
MDM サーバーはDeviceInformationApple デバイスにコマンドを送信してデバイス情報を要求します。
デバイスの証明書が MDM サーバーに返されると、その有効性が評価されます。デバイス構成証明は、要求されたプロパティを持つ有効な Apple デバイスが実際に存在することを MDM サーバーに対して宣言します。
ACME サーバーを使用する場合は、ACME ペイロードも追加できます。 ACME ペイロードはデバイスの ACME 構成証明で使用でき、証明書を使用してデバイスを検証するのにさらに役立ちます。
ACME ペイロードは RSA または ECSECPrimeRandom 暗号化をサポートしますが、256 ビットまたは 384 ビットである必要があります。
ACME は、ネットワーク機器で使用される Simple Certificate Enrollment Protocol (SCEP) に似ています。ほとんどの ACME サーバー証明書には、検証対象の情報が特定の接続デバイスに関連付けられていることを確認するために、ハードウェアにバインドされたキーが必要です。
ACME 構成証明が要求された場合、ACME サーバーは、組織の残りのサーバーが信頼できる新しい証明書を構成して発行します。
ACME 認証ステップは通常、物理デバイスの認証が完了した後にのみ実行されることに注意してください。 ACME サーバーが発行する証明書は、Apple デバイス自体によって生成された一意の一時的なワンタイム秘密キーに基づいています。
デバイスとサーバー間のキー交換。
デバイスの接続方法に応じて、ACME ペイロードを検証できる追加の方法があります。これらには以下が含まれますサファリID、ケルベロス、Wi-Fi の PayloadCertificateUUID、VPN の PayloadCertificateUUID。
現在、デバイス認証拡張機能ACME プロトコルに含めるために IETF によって検討されています。
各証明書はオプションで一意のノンス、または乱数を通信中に使用して、古いセキュリティ情報が二度使用されないようにします。
これにより、偽造された証明書を介してデバイスになりすます中間者攻撃が発生することがなくなります。
悪意のあるデバイスがデバイスになりすますためにデバイスの Apple プロパティについて嘘をついた場合、Apple の認証サーバーはそれを拒否し、デバイスの検証は失敗します。
これらの信頼できる詳細を組み合わせて使用することで、Apple デバイスになりすますことは事実上不可能になります。複数の証明書が交換される可能性があり、認証チェーン。
デバイスの信頼性評価中に、各サーバーはデバイスとユーザーのセキュリティを考慮します。姿勢、または詳細には次のものが含まれます。
- ユーザーID
- デバイスのアイデンティティ
- 位置
- 接続性
- 時間
- デバイス管理
サーバーアーキテクチャ
レート制限
デバイス認証では、電力などのデバイス上の大量のリソースが使用されます。そのため、Apple はデバイス認証を要求できる回数と頻度を制限しています。
一般に、DeviceInformation, Apple が許可するリクエストは 7 日ごとに 1 回のみです。
認証で新しいノンスを使用すると、新しい認証が要求されていることを示しますが、ノンスを省略すると、デバイスの以前の認証が使用できることを示します。
Apple は、構成証明 nonce のキーを次のように定義します。DeviceAttestationNonce。
これらの理由から、サーバーまたはネットワーク デバイスは、できるだけ早く新しい証明書を要求すべきではありません。むしろ、デバイスのプロパティが変更された場合、または特定の期間が経過した場合にのみ要求してください。
失敗した認証への対応
Apple は、デバイス認証が失敗した理由を知る信頼できる方法はなく、失敗したということだけを述べています。
ただし、デバイス認証が失敗した場合、ネットワークまたはサーバーは最悪の事態を想定すべきではありません。失敗は正当なものである可能性があり、必ずしも攻撃を示すものではありません。
追加のリソース
もちろん、上記の説明は大幅に簡略化したものです。 Apple Device Attestation の詳細をすべて理解するには、Apple の WWDC '22 セッションを必ずチェックしてください。管理対象デバイス証明書の検出。
認証プロセスは実際にはかなり複雑で、完全に理解するにはある程度の勉強が必要です。
Appleには次のタイトルのページがありますApple デバイスの管理対象デバイス認証Apple プラットフォーム導入ガイドを参照してください。
WWDC '22 と '23 の 2 つのセッションもチェックしてください。Apple デバイスの管理の新機能。 Apple はまた、近年、いくつかの WWDC セッションを開催しています。デバイス管理一般的に。
Apple PKI リソースと証明書については、次を参照してください。アップル PKI。
Apple Managed Device Attestation を使用すると、ネットワーク上の組織の Apple デバイスのセキュリティを大幅に向上させることができます。
リソースへのアクセスを許可する前にデバイスを検証できるため、脅威アクターが Apple デバイスを攻撃ベクトルとして使用する可能性が大幅に減少します。
