請在 macOS 26.4 上稽核 MDM 伺服器，而不是 27

Apple 針對 OS 27 TLS 變更所寫的稽核指引裡，有一句話多數管理員會一眼掠過：如果測試裝置執行的是 27 或更新版本，而您遇到連線錯誤，請改用執行 26.4 以上、但低於 27 的裝置重測，因為「不符合規範的連線會被阻擋，而這些失敗的連線可能會導致工作流程中後續的連線無法測試」。²

在新系統上測試，只會找到第一台有問題的伺服器，其餘全被掩蓋。在 27 上，不符合規範的連線直接失敗，仰賴它的工作流程隨之中斷。後續的一切根本不會執行，自然也就無從測起。而在 26.4 到 26.x 上，同樣的問題只會以警告形式浮現，跑一輪就能把所有不合規的伺服器一次攤開。

Apple 明講了兩件事：在 27 以上的版本，「不符合規範的連線會被阻擋，記錄訊息也會從警告變成錯誤」；以及應該在 26.4 以上、但低於 27 的版本上測試，「以找出所有受影響的伺服器」。²至於這些連線在舊版上是否真的會順利完成，屬於合理推論而非原文明言，但這項建議唯有在連線確實完成的前提下才說得通。若 26.4 也會阻擋連線，工作流程照樣會像在 27 上那樣被攔腰截斷。

直覺會叫人去測那個帶來變更的版本。但在這件事上，直覺只會給您一份不完整的清單，剩下的則會在正式環境裡一台一台冒出來。

TL;DR

自 iOS、iPadOS、macOS、watchOS、tvOS 與 visionOS 的 27.0 版起，部分系統程序會對涉及 MDM、宣告式裝置管理（Declarative Device Management，DDM）、自動化裝置註冊（Automated Device Enrollment）、設定描述檔安裝、App 安裝（含企業派送）與軟體更新的連線，強制執行更嚴格的 TLS 要求。¹伺服器至少必須支援 TLS 1.2，並使用符合 ATS 規範的加密套件與憑證。¹SCEP 與內容快取伺服器不在此限。²您 App 自身的網路連線不受影響。請在 26.4 到 26.x 上稽核——這些版本只把違規記成警告而不阻擋連線——搭配「網路診斷記錄描述檔」與 sysdiagnose 進行。²

實際受影響的範圍

這項變更只適用於一份特定的系統活動清單，而非一般的網路流量。¹

• 行動裝置管理（MDM）
• 宣告式裝置管理（DDM）
• 自動化裝置註冊
• 設定描述檔安裝
• App 安裝，包含企業 App 派送
• 軟體更新

有兩項豁免值得留意，因為這兩類伺服器正是管理員可能白白查上一整天的對象：安裝設定描述檔或解析 DDM 資產時對 SCEP 伺服器的連線，以及對內容快取伺服器的連線——即使是在請求 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 名稱相符，且憑證鏈能一路串到錨點憑證——該憑證須由用戶端作業系統內建，或由使用者或管理員安裝的 CA 所簽發。³

在此之上，ATS 另外要求：³

• 憑證須以至少 2048 位元的 RSA 金鑰或至少 256 位元的 ECC 金鑰簽署
• 憑證須使用摘要長度至少 256 位元的 SHA-2
• TLS 1.2 以上
• 資料傳輸須使用 AES-128 或 AES-256
• 透過 ECDHE 金鑰交換達成的完全前向保密

最後兩項很少出現在這次變更的各種摘要裡，連 Apple 為稽核所公布的違規對照表也沒列。只照著記錄檔點名的項目去修，加密演算法的選擇仍可能不合規。

在問題咬人之前先稽核

Apple 記載的程序相當具體，每一步都有它存在的理由。²

測試裝置請用 26.4 以上、低於 27 的版本。訣竅全在這裡。違規只會記成警告，連線照樣成功，工作流程也會繼續走到下一台伺服器。

先安裝「網路診斷記錄描述檔」，然後重新啟動。它必須在任何測試之前安裝，否則記錄事件不會帶上辨識不合規連線所需的細節。

若要在 iPhone 或 iPad 上測試自動化裝置註冊，請使用 Apple Configurator for Mac，在裝置抵達「設定輔助程式」的「裝置管理」畫面之前把描述檔裝上去。註冊流量發生得很早，事後才安裝的描述檔根本錄不到。

跑一遍平常的工作流程。註冊裝置、安裝 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'"

每一筆事件都會帶有 Domain、發出該連線的 Process，以及點名違反了哪項限制的 Warning。若同一台伺服器同時不符多項要求，單一連線也可能吐出好幾則警告。²

要涵蓋的是組態，而不只是裝置。Apple 列出的面向值得原樣照抄：環境（正式、預備、測試）、裝置類型、角色（使用者群組、單一用途裝置（kiosk）、共用裝置），以及註冊方式（自動化裝置註冊、帳號驅動、描述檔驅動、共享的 iPad）。²不同組態會連到不同伺服器，某一種組態稽核乾淨，對另一種毫無參考價值。

watchOS 沒辦法用這種方式稽核。它多數的網路行為發生在程序之外，log 指令派不上用場。Apple 的說法是：在 iOS 上測試，對 Apple Watch 的連線大致就已足夠涵蓋。²

解讀違規訊息

Apple 把失敗分成兩類，而看似合規的伺服器，栽的多半是第二類。

一般 ATS 政策違規，記錄為 Warning [ATS violation]：²

表中藏著一項好用的豁免：若未通過信任評估的憑證屬於自動註冊描述檔的錨點憑證之一，就不需要任何修補。²

FCP v2.1 違規，記錄為 Warning [ATS FCPv2.1 violation]：²

最後一列才是會讓人意外的那一項。一台伺服器可以滿足檯面上的要求——以現代加密套件與有效憑證協商 TLS 1.2——卻依然失敗，因為 Functional Package for TLS 額外要求 extended master secret 這項延伸功能。Apple 給的修補方式是改用 TLS 1.3，最起碼也要把 TLS 1.2 設定成會協商 EMS。²

這裡有個容易混淆的細節值得釐清。對 App 而言，ATS 的 FCP v2.1 合規模式是選擇性啟用的，透過 NSRequiresNIAPTLSPackageVersion 開啟，主要是為受監管環境準備的。³這個開關管的是您 App 自身的用戶端行為，與 OS 27 的系統程序無關——無論您有沒有任何 App 啟用過它，那些程序都會對您的伺服器套用 FCP v2.1 檢查。

到了 27 有什麼不同

在 27 以上的版本，不符合規範的連線會被阻擋，記錄訊息也會以錯誤而非警告的形式出現。²

Apple 指出，有幾則警告並沒有直接對應的錯誤；而在加密套件、TLS 版本與簽章演算法的問題上，用戶端實際收到什麼錯誤「可能取決於伺服器如何處理該狀態」。²別指望警告與錯誤之間存在乾淨的一對一對照。

Apple 唯一明確記載的錯誤，涵蓋被阻擋的明文 HTTP，包括最後落在 http:// 網址的重新導向：²

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 流程。³

修補工作實際上要做什麼

稽核會產出一份網域與違規項目的清單。要把它轉成伺服器端的實際調整，可分成三種情況。

能升到 TLS 1.3 就升。這一步能一次解掉好幾類違規，而不是逐項慢慢修。TLS 1.3 的每一套加密套件都提供完全前向保密，因此不具前向保密的加密套件警告根本不會出現。extended master secret 的要求只針對 TLS 1.2，升級後自然不再適用。簽章演算法的協商在設計上也更嚴格。Apple 自己的修補建議欄就寫著：盡可能讓伺服器協商 TLS 1.3，TLS 1.2 是下限。²

如果被綁死在 TLS 1.2，有三項設定扛下大部分工作。開啟 extended master secret 延伸功能，這是最容易讓一套原本看來現代的組態措手不及的違規。把加密套件清單限縮到 ECDHE 金鑰交換搭配 AES-128 或 AES-256，一舉同時滿足前向保密與對稱加密兩項要求。³並從伺服器的偏好順序中移除所有 rsa_pkcs15_sha1 簽章演算法。

被綁死的情況比聽起來常見。負責終結 TLS 的負載平衡器、還在支援合約內的硬體設備、嵌入式的管理控制器——任何一項都可能讓一個外觀現代的環境協商出老舊的結果。

憑證問題需要自己的準備期。RSA 低於 2048 位元、ECDSA 低於 256 位元，以及以弱於 SHA-256 的演算法雜湊的葉憑證，都得重新簽發，改設定沒有用。這代表要向 CA 申請、安排變更時段，還得跟憑證鏈的負責人協調。中繼憑證也要一併檢查，因為預設信任評估會沿著整條鏈一路走到錨點。³

有一項豁免能省下工夫：若未通過信任評估的憑證屬於自動註冊描述檔的錨點憑證，Apple 明言不需要修補。²開工單之前先確認這一點。

逐項驗證每次修補，不要每次都重跑整輪稽核。nscurl 會以不同的 ATS 例外組合連向單一伺服器，精準指出還有哪項要求沒過。³每改一次就跑一輪完整的 sysdiagnose，在等廠商重新部署時是條慢得折磨人的迴圈。

為什麼準備期如此關鍵

Apple 直言，更新伺服器組態「可能需要相當長的時間，對外部廠商維護的伺服器尤其如此」。²

這句話就是現在就該稽核、而不是等 27 全面推送才動手的理由。受影響的伺服器往往不是您的。MDM 廠商的端點、軟體派送夥伴、擋在註冊流程前面的身分提供者，都在其中。十月才發現某家廠商要花一整季才能在他們的 TLS 1.2 端點上啟用 EMS，跟八月就發現，是完全不同層級的問題。

稽核會產出一份網域清單，以及連向它們的程序。這份清單就是您要寄給廠商的東西，而它的具體程度，決定了對方會不會把它排到前面。「貴公司的伺服器不符合 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 指令無法運作。Apple Watch 的連線請透過 iOS 測試來涵蓋。

給所有只讀到標題的人： - 改變的不是您 App 自身的 URLSession 流量。這項變更適用於處理管理、註冊、安裝與更新流量的系統程序。

常見問題

這會影響我 App 的網路請求嗎？

不會。這項變更適用於涉及 MDM、DDM、自動化裝置註冊、設定描述檔安裝、App 安裝與軟體更新的系統程序。¹自 iOS 9.0 與 macOS 10.11 的 SDK 起，App 的網路連線就一直由 App Transport Security 另行管轄。³

為什麼要在較舊的系統版本上稽核？

因為在 27 上，失敗會直接被阻擋。Apple 說明不符合規範的連線會被阻擋，且「這些失敗的連線可能會導致工作流程中後續的連線無法測試」，並建議在 26.4 以上、低於 27 的版本上測試，以找出所有受影響的伺服器。²在那些版本上，違規只會記成警告，連線仍會成功。

哪些伺服器不在範圍內？

安裝設定描述檔或解析 DDM 資產時所連的 SCEP 伺服器，以及內容快取伺服器——即使是在請求 App 安裝或軟體更新的相關資產時也一樣。²

我的伺服器跑 TLS 1.2 且憑證有效，還是可能失敗嗎？

會。FCP v2.1 的檢查包含：協商 TLS 1.2 卻未帶 extended master secret 延伸功能、憑證以 ClientHello 中未宣告的演算法簽署，以及 rsa_pkcs15_sha1 簽章演算法。²ATS 另外還要求 AES-128 或 AES-256，以及透過 ECDHE 達成的完全前向保密。³

在我的 App 裡啟用 NIAP 合規模式會改變這件事嗎？

不會，而且這兩件事很容易混為一談。NSRequiresNIAPTLSPackageVersion 是讓您 App 自身的用戶端行為進入更嚴格的 FCP 模式，供受監管環境使用。³OS 27 的系統程序則是獨立地對管理流量套用它們自己的要求。

資料來源