MDMサーバーの点検は27ではなくmacOS 26.4で

OS 27のTLS変更を点検する手順について、Appleの案内には多くの管理者が読み飛ばしてしまう一文があります。テスト用デバイスがバージョン27以降で接続エラーが発生した場合は、26.4以降かつ27より前のデバイスで再度テストせよ、というものです。理由は「準拠していない接続はブロックされ、その失敗した接続がワークフロー内の後続の接続のテストを妨げる可能性がある」からです。²

新しいOSでテストすると、壊れたサーバーが1台だけ見つかり、残りは隠れます。 27では準拠していない接続が失敗し、それに依存していたワークフローがそこで止まります。下流の処理は一切実行されないため、テストもされません。26.4から26.xまでなら同じ問題が警告として表面化するので、一度の実行で準拠していないサーバーをすべて洗い出せます。

Appleが明言していることが2つあります。1つは、バージョン27以降では「準拠していない接続はブロックされ、ログメッセージは警告ではなくエラーとして表示される」こと。もう1つは、「影響を受けるすべてのサーバーを特定する」ために、26.4以降かつ27より前でテストすべきだということです。² それ以前のバージョンで接続が実際に完了する、という部分は逐語的な記述ではなく読み取りですが、そう解釈しなければこの推奨自体が成り立ちません。26.4で接続がブロックされるのなら、27とまったく同じようにワークフローが途中で切れてしまうからです。

変更が導入されたバージョンでテストしたくなるのが人情でしょう。しかしこの件に限っては、その直感が不完全なリストを生みます。残りは本番環境で1台ずつ見つかることになります。

要点

iOS、iPadOS、macOS、watchOS、tvOS、visionOSのバージョン27.0以降、一部のシステムプロセスが、MDM、宣言型デバイス管理、自動デバイス登録、構成プロファイルのインストール、エンタープライズ配布を含むAppのインストール、ソフトウェアアップデートに関わる接続に対して、より厳格なTLS要件を適用します。¹ サーバー側はTLS 1.2以降に対応し、ATS準拠の暗号スイートと証明書を備えている必要があります。¹ SCEPサーバーとコンテンツキャッシュサーバーは対象外です。² ご自身のAppの通信は影響を受けません。点検は26.4から26.xで行ってください。このバージョン帯では違反がブロックではなく警告としてログに残ります。ネットワーク診断ロギングプロファイルとsysdiagnoseを使います。²

実際に対象となる範囲

この変更が適用されるのは特定のシステム動作のリストであり、ネットワーク通信全般ではありません。¹

• モバイルデバイス管理（MDM）
• 宣言型デバイス管理（DDM）
• 自動デバイス登録
• 構成プロファイルのインストール
• Appのインストール（エンタープライズApp配布を含む）
• ソフトウェアアップデート

対象外が2つあり、どちらも重要です。知らなければ管理者が丸一日調査に費やしかねない種類のサーバーだからです。1つは、構成プロファイルのインストール中やDDMアセットの解決中におけるSCEPサーバーへの接続。もう1つは、Appのインストールやソフトウェアアップデート用のアセットを要求する場合であっても対象外となる、コンテンツキャッシュサーバーへの接続です。²

見出しだけを見てここに辿り着いた開発者のために、はっきり書いておきます。あなたのAppのURLSession通信は対象ではありません。 話の中心はデバイス管理基盤です。App自身の通信は、iOS 9.0およびmacOS 10.11のSDKに対してリンクしたApp以降、App Transport Securityが一貫して管轄してきました。³ 27で変わったのは、一連のシステムプロセスが管理通信にも同等の要件を適用し始めたという点です。

対象プラットフォームは「企業のMac群」という言葉から想像するより広範囲です。AppleはiOS、iPadOS、macOS、watchOS、tvOS、visionOSを挙げています。² 会議室のApple TVもデザインスタジオのVision Proも、同じ基盤を通って登録されるのです。

要件を一次情報から

Appleのサポート記事には、サーバーはTLS 1.2以降に対応し、ATS準拠の暗号スイートを使用し、ATS基準を満たす有効な証明書を提示する必要がある、と書かれています。² 具体的な中身はATSのドキュメントにあり、作業の土台となるのはそちらのページです。³

まず、デフォルトのサーバー信頼性評価に合格することが前提です。署名が壊れていないこと、有効期限が切れていないこと、名前がサーバーのDNS名と一致すること、そしてクライアントOSに同梱されているか、ユーザーまたは管理者がインストールしたCAが発行したアンカー証明書までチェーンが繋がっていること。³

その上でATSが追加する要件は次のとおりです。³

• 証明書の署名鍵は2048ビット以上のRSA鍵、または256ビット以上のECC鍵
• 証明書はダイジェスト長256ビット以上のSHA-2を使用
• TLS 1.2以降
• データ交換はAES-128またはAES-256を使用
• ECDHE鍵交換による前方秘匿性（PFS）

最後の2項目は、この変更の要約で触れられることがまずありません。Appleが点検用に公開している違反一覧の表にも登場しないのです。ログに名指しされたものだけを直した管理者は、暗号スイートの選択という点で依然として非準拠のままかもしれません。

痛い目に遭う前に点検する

Appleが文書化している手順は具体的で、各ステップにはそれぞれ理由があります。²

テスト用デバイスは26.4以降、27より前を使う。 ここが肝心なところです。違反は警告としてログに残り、接続は成功し、ワークフローは次のサーバーへ進みます。

ネットワーク診断ロギングプロファイルをインストールし、再起動する。 テストを始める前に必ずインストールしてください。そうしないと、非準拠の接続を特定するのに必要な詳細情報がログイベントに含まれません。

iPhoneまたはiPadで自動デバイス登録を扱う場合は、Mac用Apple Configuratorを使う。 デバイスが設定アシスタントの「デバイス管理」画面に到達する前にプロファイルをインストールするためです。登録の通信は初期段階で発生するので、後からインストールしたプロファイルでは取り逃がします。

普段どおりのワークフローを実行する。 デバイスを登録し、Appとプロファイルをインストールし、自社サーバーと通信するものを一通り動かします。狙いは、影響を受ける可能性のあるすべてのサーバーに向けて通信を発生させることです。

sysdiagnoseを取得し、 Macへ移してアーカイブを展開し、そのトップレベルディレクトリからログを絞り込みます。

log show --archive system_logs.logarchive --info \
  -P "p=appstoreagent|appstored|managedappdistributionagent|managedappdistributiond|ManagedClient|ManagedClientAgent|mdmclient|mdmd|mdmuserd|MuseBuddyApp|NanoSettings|Preferences|profiled|profiles|RemoteManagementAgent|remotemanagementd|Setup|'Setup Assistant'|'System Settings'|teslad|TVSettings|TVSetup|XPCAcmeService AND s=com.apple.network AND m:'ATS Violation'|'ATS FCPv2.1 violation'"

各イベントには、ドメイン、接続を行ったプロセス、そして違反した制約を示す警告が含まれます。1つの接続が複数の要件を満たさない場合、警告が複数出力されることもあります。²

デバイスではなく、構成を網羅する。 Appleが挙げている軸はそのまま真似する価値があります。環境（本番、ステージング、テスト）、デバイスの種類、役割（ユーザーグループ、キオスク、共有デバイス）、登録の種類（自動デバイス登録、アカウント主導、プロファイル主導、共有iPad）。² 構成が違えば到達するサーバーも違うので、ある構成の点検結果が綺麗でも、別の構成については何も語りません。

watchOSはこの方法では点検できません。 ネットワーク通信の大半がプロセス外で行われるため、logコマンドが機能しないのです。iOSでテストすればApple Watchの接続についても十分なカバレッジが得られる可能性が高い、というのがAppleの案内です。²

違反を読み解く

Appleは失敗を2つの種類に分けています。準拠しているように見えるサーバーが引っかかるのは、後者のほうです。

一般的なATSポリシー違反。Warning [ATS violation]としてログに記録されます。²

この表には有用な例外が1つ紛れています。信頼性評価に失敗した証明書が自動登録プロファイルのアンカー証明書に含まれている場合、対処は不要です。²

FCP v2.1違反。Warning [ATS FCPv2.1 violation]としてログに記録されます。²

この最後の行に驚かされる人が多いはずです。 見出しに掲げられた要件は満たしている、つまり最新の暗号スイートと有効な証明書でTLS 1.2をネゴシエートしているサーバーであっても、失敗しうるのです。TLS向けのFunctional Packageが、それに加えてextended master secret拡張を要求するからです。Appleが示す対処法は、TLS 1.3へ移行すること、少なくともTLS 1.2でEMSをネゴシエートするよう設定することです。²

ここには整理しておきたい細かい点があります。ATSのFCP v2.1準拠モードは、NSRequiresNIAPTLSPackageVersionによってAppが任意で有効化するものであり、規制環境向けに存在しています。³ この有効化が制御するのは、あなたのAppのクライアント側の挙動です。OS 27のシステムプロセスとは無関係で、そちらはあなたのAppが何を有効化していようがいまいが、FCP v2.1のチェックをあなたのサーバーに対して適用します。

27で何が変わるか

バージョン27以降では、準拠していない接続はブロックされ、ログメッセージは警告ではなくエラーとして表示されます。²

Appleは、いくつかの警告には直接対応するエラーが存在しないこと、そして暗号スイート、TLSバージョン、署名アルゴリズムの問題については、クライアント側の正確なエラーが「サーバーがその状態をどう扱うかによって変わる可能性がある」ことを注記しています。² 警告からエラーへの綺麗な対応表を期待してはいけません。

Appleが文書化している具体的なエラーは1つだけで、これはブロックされた平文HTTPに関するものです。リダイレクト先がhttp://のURLになる場合も含みます。²

Task . finished with error [-1022] Error Domain=NSURLErrorDomain Code=-1022
"The resource could not be loaded because the App Transport Security policy
requires the use of a secure connection."

対処後に個別のサーバーを検証するなら、nscurlが使えます。ATS例外のさまざまな組み合わせで接続を試み、どの要件で失敗しているのかを絞り込めるので、sysdiagnoseを一巡させる必要がありません。³

対処の実際

点検によってドメインと違反の一覧ができあがります。それをサーバーの変更に落とし込む作業は、3つのケースに分かれます。

可能な範囲でTLS 1.3へ移行する。 そうすれば複数種類の違反が一度に解消され、1つずつ潰していく必要がなくなります。TLS 1.3の暗号スイートはすべて前方秘匿性を備えているため、PFS非対応の暗号スイートに関する警告は起こりえません。extended master secretの要件はTLS 1.2固有のものなので、適用対象から外れます。署名アルゴリズムのネゴシエーションも設計上より厳格です。Apple自身の対処法の欄にも、可能な限りTLS 1.3をネゴシエートするようサーバーを更新し、TLS 1.2を最低ラインとせよ、と書かれています。²

TLS 1.2から動けない場合は、3つの設定がほぼすべてを担います。 まずextended master secret拡張を有効にすること。これが、他は今風の構成なのに引っかかる可能性が最も高い違反です。次に暗号スイートのリストを、ECDHE鍵交換とAES-128またはAES-256の組み合わせに絞ること。これでPFSの要件と共通鍵暗号の要件を同時に満たせます。³ そしてrsa_pkcs15_sha1署名アルゴリズムを、サーバーの優先順位リストから取り除くことです。

「動けない」状況は思っているより一般的です。TLSを終端するロードバランサー、サポート契約下のハードウェアアプライアンス、組み込みの管理コントローラー。どれもが、一見すると今風の環境が古いものをネゴシエートしてしまう原因になりえます。

証明書の問題には、それ自体のリードタイムが必要です。 2048ビット未満のRSA、256ビット未満のECDSA、SHA-256より弱いハッシュのリーフ証明書。いずれも設定変更ではなく再発行が必要です。つまりCAへの申請、変更作業の枠取り、チェーンの管理者との調整が発生します。デフォルトの信頼性評価はアンカーまでチェーン全体をたどるので、中間証明書も確認してください。³

作業を減らせる例外が1つあります。信頼性評価に失敗した証明書が自動登録プロファイルのアンカー証明書に含まれている場合、対処は不要だとAppleは述べています。² チケットを起票する前に、まずそこを確認しましょう。

修正の検証は、点検全体を再実行するのではなく1件ずつ行う。 nscurlはATS例外のさまざまな組み合わせで単一のサーバーへ接続するので、どの要件がまだ失敗しているのかを正確に絞り込めます。³ ベンダーの再デプロイ待ちをしているときに、修正のたびにsysdiagnoseを取り直していては、確認のテンポが悪すぎます。

リードタイムが効いてくる理由

サーバー構成の更新には「特に外部ベンダーが保守するサーバーの場合、かなりの時間を要する可能性がある」と、Appleは率直に述べています。²

この一文こそが、27が広く配布されてからではなく今すぐ点検を実行すべき理由です。対象となるサーバーは、往々にして自社のものではありません。MDMベンダーのエンドポイント、ソフトウェア配布パートナー、登録の前段に立つIDプロバイダー。TLS 1.2のエンドポイントでEMSを有効にするのに四半期かかるとベンダーから聞かされるのが10月なのか8月なのかでは、問題の性質がまるで違います。

点検からは、ドメインと、そこへ到達したプロセスの一覧が得られます。ベンダーに送るのはこの一覧であり、優先度を上げてもらえるかどうかは、その具体性にかかっています。「御社のサーバーがAppleの新要件を満たしていません」は後回しにされやすいものです。「このドメインの御社エンドポイントがextended master secretなしでTLS 1.2をネゴシエートしており、OS 27はこれを登録通信に対してブロックします」は、そうはいきません。

これは今回のリリースの他の変更と同じ形をしています。macOS 27はチーム外のコンテナアクセスを、確認を求めずに拒否するようになりました。そしてメニュー項目の画像は、どのSDKに対してリンクしたかに左右されるようになりました。いずれの場合も、プラットフォームが合図を取り除くか、デフォルトを厳しくしており、障害は別の何かの顔をしてやってきます。今回その「別の何か」は、応答が返ってこない登録処理です。

押さえておくべきこと

IT管理者向け: - 点検は26.4から26.xで行うこと。27でのテストは最初の失敗をブロックし、同じワークフロー内の下流をすべて隠してしまいます。 - テスト前にネットワーク診断ロギングプロファイルをインストールし、デバイスを再起動すること。さもないとログからサーバーを特定できません。 - デバイスではなく構成を網羅すること。環境、デバイスの種類、役割、登録の種類は、それぞれ異なるサーバーに到達します。 - ベンダーにはドメイン、プロセス、具体的な違反内容を送ること。外部サーバーのリードタイムこそが最大の制約になります。

MDM・デバイス管理の開発者向け: - SCEPサーバーとコンテンツキャッシュサーバーは対象外です。点検の労力をそこに割かないこと。 - ATS FCPv2.1違反は一般的なATSポリシー違反とは別物であり、なかでもEMSなしのTLS 1.2が最も見落とされやすい項目です。 - watchOSではlogコマンドが機能しません。Watchの接続はiOSでのテストで代替してください。

この件の見出しを目にしたすべての人へ: - 変わったのは、あなたのApp自身のURLSession通信ではありません。管理、登録、インストール、アップデートの通信を扱うシステムプロセスの話です。

よくある質問

自分のAppのネットワークリクエストに影響しますか？

しません。この変更が適用されるのは、MDM、DDM、自動デバイス登録、構成プロファイルのインストール、Appのインストール、ソフトウェアアップデートに関わるシステムプロセスです。¹ Appの通信については、iOS 9.0およびmacOS 10.11のSDK以降、App Transport Securityが別枠で管轄してきました。³

なぜ古いOSバージョンで点検するのですか？

27では失敗がブロックされるからです。Appleは、準拠していない接続はブロックされ「その失敗した接続がワークフロー内の後続の接続のテストを妨げる可能性がある」と述べたうえで、影響を受けるすべてのサーバーを特定するために26.4以降かつ27より前でテストするよう推奨しています。² それらのバージョンでは、接続は成功したまま違反が警告としてログに残ります。

対象外のサーバーはどれですか？

構成プロファイルのインストール中やDDMアセットの解決中におけるSCEPサーバー、そしてAppのインストールやソフトウェアアップデートに関連するアセットを要求する場合であってもコンテンツキャッシュサーバーです。²

有効な証明書でTLS 1.2を使っています。それでも失敗しますか？

します。FCP v2.1のチェックには、extended master secret拡張なしでネゴシエートされたTLS 1.2、ClientHelloで提示されていないアルゴリズムで署名された証明書、そしてrsa_pkcs15_sha1署名アルゴリズムが含まれます。² またATSはAES-128またはAES-256と、ECDHEによる前方秘匿性も要求します。³

AppでNIAP準拠を有効にすると、この挙動は変わりますか？

変わりません。この2つは混同しやすいので注意してください。NSRequiresNIAPTLSPackageVersionは、規制環境向けのより厳格なFCPモードに、あなたのApp自身のクライアント挙動を組み入れるものです。³ OS 27のシステムプロセスは、それとは独立に、管理通信へ自らの要件を適用します。

出典