早ければ次期メジャーOSリリースから、Appleデバイスは、強化されたTLS標準を満たしていないデバイス管理サービス、Mobile Device Management(MDM)サーバ、登録エンドポイント、またはアプリ配布インフラストラクチャへの接続を拒否するようになります。準拠していないサーバは、登録、デバイス管理、アプリ配信、ソフトウェアアップデートで利用できなくなります。
変更内容、準備ができていない場合に発生する影響、そしてフリートに影響が及ぶ前に自社環境を確認する方法をご紹介します。
Appleが求めていること
AppleによるApp Transport Security(ATS)の適用強化は、Appleデバイスが管理インフラストラクチャに対して行うすべての接続に適用されます。影響を受ける領域には、MDMおよびDeclarative Device Management(DDM)、Automated Device Enrollment(ADE)、構成プロファイルのインストール、アプリのインストール(エンタープライズ配布を含む)、ソフトウェアアップデートが含まれます。
接続を維持するには、サーバが以下のすべての要件を満たす必要があります。
- TLS 1.2以上が必須であり、TLS 1.3が推奨されます。TLS 1.0または1.1を引き続き使用しているサーバは、完全にブロックされます。
- App Transport Security(ATS)に準拠した暗号スイートのみが許可されます。具体的には、Perfect Forward Secrecy(PFS)対応の暗号スイート、つまり任意のTLS 1.3暗号スイート、またはElliptic Curve Diffie-Hellman Ephemeral(ECDHE)鍵交換を使用するTLS 1.2暗号スイートが対象です。レガシー暗号のサポートは認められません。
- ATS標準を満たす有効なサーバ証明書が必要です。RSA鍵は少なくとも2048ビット、Elliptic Curve Digital Signature Algorithm(ECDSA)鍵は少なくとも256ビット、SHA-2では最低256ビットのダイジェストが必要です。期限切れの証明書や自己署名証明書は使用できません。
- TLS 1.2接続では、Extended Master Secret(EMS)拡張が必要です。
- HTTPSのみが許可されます。接続チェーン内で平文のHTTPを使用することはできません。
これは、macOS、iOS、iPadOS、watchOS、tvOS、visionOSのすべてに適用されます。おそらく、上記すべてのオペレーティングシステムのバージョン27に適用されることになります。
準拠していない場合に発生する影響
適用開始時点で、デバイス管理インフラストラクチャ内のいずれかのサーバがこれらの要件を満たしていない場合、Appleデバイスは接続を拒否します。つまり、次のような影響が発生します。
- 登録が失敗します。新しいデバイスを管理対象として登録できなくなります。Apple Business Managerを通じたゼロタッチ導入も機能しなくなります。
- 管理操作が中断します。プロファイルのプッシュ、構成変更、ポリシー適用がデバイスに届かなくなります。
- アプリ配布が停止します。管理対象アプリをプッシュまたはアップデートできなくなります。
- ソフトウェアアップデートが失敗します。デバイスは、管理されたアップデートチャネルを通じてOSおよびセキュリティアップデートを受信できなくなります。
つまり、デバイス側から見ると、MDMが静かに本来の役割を果たさなくなります。
準拠していない可能性があるものの例
古いセルフホスト型MDMサーバ(テストやトレーニング用に作成したものなど)が要件を満たしていない可能性があることは、明らかかもしれません。
しかし、Appleデバイスの管理には多くの構成要素があります。デバイス管理スタックの中に、準拠していない要素が含まれている可能性もあります。インフラストラクチャの構成要素の例としては、次のようなものがあります。
https://server.pretendco.com/ が準拠しているからといって、https://server.pretendco.com:8443/ も準拠しているとは限らない点にご注意ください。
今回の変更において対応が必要なのは、お客様のサーバーおよびベンダーのサーバーへの接続のみです。Appleがホストするサービスを準拠した状態に保つのは、Apple側の責任となります。
とはいえ、Appleは以前から、HTTPSインターセプション(SSLインスペクション)を使用してAppleデバイスからAppleサービスへの接続を傍受しないよう推奨しています。もしお客様のネットワークでこれらの接続を傍受している場合、それらは実質的にお客様の接続となり、準拠させる責任はお客様側に生じることになります。
またAppleは、構成プロファイルのインストール中、またはDDM(宣言型デバイス管理)アセットの解決中におけるSCEPサービスへの接続は、今回の要件の対象外となることを明記しています。
準拠していない可能性のある箇所が数多く存在するおそれがあるため、今すぐ監査を開始し、それらの要素の修正やプレイス(置き換え)を行うための十分な時間を確保してください。
インフラストラクチャの監査を今すぐ行う方法
Appleの通知には、実践的な監査プロセスが記載されています。その要約は以下の通りです。
ステップ 1 — バージョン26.4以降のOS(iOS 26.4、iPadOS 26.4、macOS 26.4、watchOS 26.4、tvOS 26.4、またはvisionOS 26.4)を搭載したテストデバイスに、「Network Diagnostics(ネットワーク診断)ロギングプロファイル」をインストールします。このロギングプロファイルを適用すると、ATSレベルのログ記録が有効になり、準拠していない接続の有無を確認できるようになります。iOSまたはiPadOSデバイスで自動デバイス登録(ADE)をテストする場合は、MacのApple Configuratorを使用して、設定アシスタントのフローの最初の段階でこのプロファイルをインストールできます。
MacとADEのテストについてはどうでしょうか。実のところ、設定アシスタントで「リモートマネジメント」画面が表示される前にこのロギングプロファイルをインストールする明確な方法はありません。そのため、可能であればまずはiOSまたはiPadOSを使ってADEのテストを実施することをお勧めします。
ステップ 2 — そのデバイス上で通常の登録および管理ワークフローを実行し、すべてのインフラストラクチャのエンドポイント間で、サンプルの基準となるネットワークトラフィックを発生させます。
ステップ 3 — テストデバイスから sysdiagnose アーカイブを収集し、ログを「ATS Violation」および「ATS FCPv2.1 violation」のメッセージでフィルタリングします。ここに表示されたサーバーはすべて、対応が必要となります。
ステップ 4 — nscurl コマンドを使用して、特定のサーバーを個別に検証します。nscurl --ats-diagnostics --verbose https://[サーバーのURL] を実行すると、そのサーバーがサポートしている項目や、どの要件を満たしていないかについての詳細なレポートを取得できます。
自社運用の自ホスト型(セルフホスト)MDMを実行している場合や、古いオンプレミスの登録インフラストラクチャを使用している場合は、今すぐサーバー管理者に連絡を取り、連携を始めてください。一般的な修正対応としては、TLS構成のアップデートや、新しい鍵長(キーサイズ)またはハッシュアルゴリズムの要件を満たしていない証明書の更新などが挙げられます。
Iruをご利用なら、すでに対応済みです
Iruのすべてのインフラストラクチャは、Appleの最新のATS要件に完全に準拠しています。デバイス管理サービス側で対応していただく作業は一切ありません。お客様の登録、管理、およびアプリ配信の接続は、すでに新しい標準規格を満たしています。
レガシーなシステムや自ホスト型(セルフホスト)のデバイス管理サービスプラットフォームをご利用中のチームにとって、今はベンダーの対応力をテストする絶好のタイミングです。「サーバーはTLS 1.3に対応していますか?」「PFS(前方秘匿性)暗号スイートを使用していますか?」「最後に証明書の監査を行ったのはいつですか?」と直接確認してみてください。もし回答が曖昧な場合、Appleが今秋(北半球の秋)に新しいオペレーティングシステムの提供(スイッチ)を開始した際、デバイス登録のサービス停止(アウトプット障害)に直面する可能性があります。
なぜ、今なのでしょうか?
率直に言って、これらの要件はどれも非常に合理的かつ現実的なものです。Appleは長年にわたり、Appleプラットフォーム上のアプリに対する要件を段階的に厳格化してきました。今回新しいのは、その「対象範囲」です。単なるアプリの接続だけでなく、デバイス管理サービスや登録インフラストラクチャが明確に対象に含まれました。これはAppleが、皆様のデバイス管理チャネルを、本番環境のあらゆるHTTPSエンドポイントと同等のセキュリティ基準で扱っていることを意味します。
「社内トラフィックだから」という理由で内部インフラストラクチャのTLS環境の整備(クリンリネス)を後回しにしてきたITチームにとって、今回の変更はその前提を覆す決定的な期限となります。皆様のデバイス管理サーバーは、Appleのサーバー、そして管理対象のデバイスの両方と通信します。今後は、その双方向の通信でこの基準をクリアしなければなりません。
まずは監査を実行してください。そして、サーバーチームに要件を共有してください。もし、こうしたインフラストラクチャの保守管理を完全にスキップしたいとお考えであれば、それは完全にクラウド管理されたサービス管理プラットフォームへと移行するための十分かつ合理的な理由になります。
Iruがデバイス管理サービスのセキュリティをどのように処理しているかについて、ご質問はありますか?弊社のチームにご相談ください →