多據點 RADIUS 轉移：按順序排定據點、無線存取點與原則

您可以在新舊伺服器並行運作的情況下，分四個階段將多據點網路環境轉移至雲端 RADIUS，無須一次性停機切換。每個 SSID 都會列出這兩者，且每台裝置都會信任新的伺服器憑證。每個據點均在 802.1X 架構下完成切換，並附帶書面的退出測試。在 Purple 上，切換作業通常只需一個週末的時間即可完成。

多據點 RADIUS 轉移過程中，有哪些項目會變更？有哪些會保持不變？

最終狀態是由單一雲端 RADIUS 原則服務所有據點，並由身分識別決定 VLAN。RADIUS 規範於 RFC 2865，是無線基地台用來詢問伺服器裝置是否可連線的協定。伺服器會接受或拒絕該裝置，也可以傳回屬性，例如裝置落腳的網路區段 VLAN。

在安全網路上，該交換會在 802.1X 內部執行，這是基於連接埠之網路存取控制的標準。802.1X 在裝置、無線基地台與伺服器之間傳送 EAP (擴充驗證協定)。EAP-TLS 規範於 RFC 5216，使用憑證對雙方進行驗證。PEAP 則將密碼交換封裝在 TLS 隧道內。

共有四項變更：

• 每個無線基地台或控制器都會指向新的伺服器位址與共用金鑰。RADIUS 將該裝置稱為 NAS (網路存取伺服器)。
• 裝置會在 EAP 握手期間看到新的伺服器憑證。
• 原則會從 Microsoft Entra ID、Okta 或 Google Workspace 讀取群組，而非從本機目錄讀取。
• 記錄會移至新的主控台。

保持不變的項目更為重要。您可保留原本的無線基地台、SSID 名稱、VLAN ID、交換器 Trunk 連線與防火牆區域。沒有人需要變更密碼或加入新網路。

相同的做法適用於 Purple Access 上的所有三種網路。在開放網路上，許多 Captive Portal 會透過 RADIUS 授權裝置。安全網路則使用 EAP-TLS 或 PEAP。在 xPSK 網路上，RADIUS 會賦予每個裝置或住戶專屬的預先共用金鑰。本指南以安全網路為例，因為其包含最大的風險。

{"tone":"warning","title":"最棘手的風險：伺服器憑證信任","text":"使用 EAP-TLS 或 PEAP 的裝置會檢查 RADIUS 伺服器憑證，且許多裝置僅信任舊伺服器的憑證頒發機構 (CA)。請在第一個據點進行轉移前，將新的 CA 推送至每個裝置設定檔，否則這些裝置將無法加入並持續重試。"}

處理好憑證信任後，轉移的其餘部分就是設定工作與觀察期。

在階段 1 之前，必須滿足哪些條件？

在建立任何原則之前，必須先具備五個條件。如果缺少其中一項，將會在後續階段引發問題。

完整的 NAS 清冊

列出傳送請求至舊伺服器的每部裝置。這包括存取點、無線控制器、執行有線 802.1X 的交換器以及 VPN 閘道。請根據舊伺服器的 RADIUS 用戶端清單建立此清單，而非根據網路圖。若清冊中遺漏了 NAS，您就無法在階段 4 關閉舊伺服器。

逐行的原則對映

寫下舊伺服器套用的每條規則，包含其條件、結果以及傳回的屬性。典型的資料行如下所示：員工群組對映至員工 VLAN、外包商對映至受限的 VLAN、公司筆記型電腦透過憑證對映至公司 VLAN。請注意哪些屬性帶有 VLAN。RFC 3580 定義了標準集合：Tunnel-Type、Tunnel-Medium-Type 以及 Tunnel-Private-Group-ID。某些地方會改用特定廠商的屬性，您必須完全複製這些屬性。

憑證計劃

決定由哪一個憑證授權單位 (CA) 發行新的伺服器憑證。在受控裝置上，請在進行任何站台轉移之前，透過 Microsoft Intune、Jamf 或您的行動裝置管理 (MDM) 平台推播該 CA。對於 EAP-TLS，新伺服器也必須信任發行您裝置憑證的 CA。

新伺服器可讀取的身分驗證來源

連線您的身分提供者，並確認原則對映中的每個群組都存在於該處。若某個群組僅存在於舊伺服器上，請先在身分提供者中重新建立該群組。

可達性、負責人與變更時間窗

每個站台都需要通往雲端伺服器的網路路徑，並使用 Purple 新增設定說明文件中的位址與連接埠。為每個站台指定一名負責人，並與站台經理議定變更時間窗。在轉移任何項目之前，請先寫下復原觸發條件。

{"title":"多站點 RADIUS 轉移檢核表","groups":[{"heading":"階段 1 之前","items":[{"text":"匯出舊伺服器的 RADIUS 客戶端清單，並與 NAS 清冊進行對帳","why":"遺漏的 NAS 會阻礙停用流程"},{"text":"對照對映每條原則規則：條件、結果與傳回的屬性"},{"text":"確認每個原則群組皆已存在於 Microsoft Entra ID、Okta 或 Google Workspace 中"},{"text":"透過 MDM 將新伺服器的 CA 推送至受控裝置"},{"text":"在各站點開啟 Purple 入門文件指定的網路路徑"},{"text":"指定各站點的負責人與變更時間視窗，並以書面形式確認回滾觸發條件"}]},{"heading":"階段 1：建置","items":[{"text":"凍結舊伺服器上的原則變更"},{"text":"在新伺服器上重新建立每個原則資料列"},{"text":"針對兩台伺服器測試每個資料列中的一個身分，並核對回應是否一致"}]},{"heading":"階段 2 與 3：試行與分批進行","items":[{"text":"在切換前記錄每個站點的基準拒絕率"},{"text":"在每個 SSID 上將新伺服器與舊伺服器並列新增"},{"text":"確認每種裝置類型皆已在新伺服器上成功驗證"},{"text":"在進入下一批次前，每個批次需維持一整個完整的業務週期"}]},{"heading":"階段 4：停用","items":[{"text":"從每個 SSID 和 NAS 中移除舊伺服器"},{"text":"確認在議定的觀察期內，舊伺服器的請求數為零"},{"text":"根據貴單位的保留政策匯出並保留舊伺服器日誌"},{"text":"廢止與舊伺服器共用的共用金鑰 (shared secrets)"},{"text":"更新維運手冊 (runbook)，並歸檔每個站點的退場測試記錄"}]}],"download":{"filename":"radius-migration-checklist.csv"}}

依序劃分的 4 個階段為何？

本計畫分為四個階段。每個階段均以可通過或失敗的退場測試做為結束。在測試通過之前，任何項目都不會推進到下一階段，這能幫助您避免一次性切換 (big-bang cutover) 的風險。

{"kind":"timeline","direction":"lr","caption":"具代表性的 40 個據點架構：四個階段，每階段皆以結束測試完結","alt":"時間軸顯示在大約 12 週內進行準備，接著是第 1 階段建置、第 2 階段試點、第 3 階段分批推廣及第 4 階段停用。","nodes":[{"id":"p0","label":"第 1 階段之前","sub":"資產清單、策略地圖、CA 推送、身分來源","tone":"neutral","when":"第 1-2 週"},{"id":"p1","label":"第 1 階段：建置與鏡像","sub":"策略於雲端 RADIUS 重建，實驗室回應符合","tone":"brand","when":"第 3 週"},{"id":"p2","label":"第 2 階段：試點據點","sub":"單一據點，舊伺服器保留為備用","tone":"brand","when":"第 4-5 週"},{"id":"p3","label":"第 3 階段：分批推廣","sub":"5 個，接著 10 個，然後是其餘 24 個據點","tone":"brand","when":"第 6-10 週"},{"id":"p4","label":"第 4 階段：正式停用","sub":"舊伺服器零請求，然後關閉","tone":"success","when":"第 11-12 週"}],"edges":[{"from":"p0","to":"p1","label":"已符合先決條件"},{"from":"p1","to":"p2","label":"實驗室回應符合"},{"from":"p2","to":"p3","label":"試點結束測試"},{"from":"p3","to":"p4","label":"所有據點完成切換"}]}

{"caption":"多據點 RADIUS 遷移的階段計畫","asOf":"2026-06-10","columns":[{"key":"phase","label":"階段"},{"key":"scope","label":"範圍"},{"key":"owner","label":"負責人"},{"key":"exit","label":"結束測試"}],"rows":[["第 1 階段之前","NAS 資產清單、策略地圖、CA 推送、身分來源、據點路徑","IT 經理與身分及存取權限負責人","列出每個 NAS、身分提供者中的每個策略群組、受管裝置上的新 CA"],["第 1 階段：建置","策略於雲端 RADIUS 重建，無即時流量","身分及存取權限負責人","每列一個測試身分從新舊伺服器取得相同的回應與 VLAN"],["第 2 階段：試點","一個具代表性的據點，新伺服器為主，舊伺服器為備用","網路架構師","一個業務週期內無未解釋的拒絕，且在新伺服器上看到每種裝置類型"],["第 3 階段：分批推廣","其餘據點按控制台範本分組，逐步擴大分批推廣","網路架構師與據點負責人","每批次在下一批開始前皆通過試點結束測試"],["第 4 階段：正式停用","從每個 SSID 與 NAS 移除舊伺服器","IT 經理","觀察期內舊伺服器零請求，保留日誌，停用金鑰/密碼"]],"footnote":"負責人為角色而非特定人員。請將觀察期設定為至少一個重新驗證週期加上一個工作週。","download":{"filename":"radius-migration-phase-plan.csv"}}

每個階段內部會發生什麼事？

第 1 階段：建置與鏡像策略

在任何即時請求到達新伺服器之前，先在新伺服器上重建策略地圖。連接身分提供者，然後重新建立每一列及其條件、結果和回傳屬性。保持 VLAN ID 完全相同，如此便無需變更交換器與防火牆設定。

在實驗室中測試每一行。請使用 eapol_test，這是來自 wpa_supplicant 專案的工具。它會向 RADIUS 伺服器傳送真實的 EAP 交換並列印回覆。針對兩台伺服器執行每一行的身分驗證，並比較回覆。結束測試的標準是每一行皆符合，且具有相同的接受或拒絕結果以及相同的 VLAN。

階段 2：針對單一據點進行試行

挑選一個能代表整個企業的據點，而不是最簡單的據點。它應該包含您運作的每個裝置類別，包括較為複雜的裝置。請考量手持式掃描器、透過 WiFi 連線的支付終端機以及較舊的筆記型電腦。您還需要據點內有能在收到要求時測試裝置的人員。

在舊伺服器旁新增新伺服器，對其進行測試，然後將新伺服器設為主伺服器。保持此狀態一個完整的業務週期。對於飯店來說，這意味著一週的輪班週期。對於辦公室來說，這意味著一週的週一早晨登入。當滿足以下兩點時，即表示試行通過。第一，每個裝置類別都已在新伺服器上完成驗證。第二，拒絕率不高於您的基準。

階段 3：分波段遷移整個企業

隨著先前波段的通過，讓後續每個波段的規模都大於上一個波段。擁有 40 個據點的企業可以先遷移 1 個試行據點，然後是 5 個，接著是 10 個，最後是剩餘的 24 個。按主控台範本或群組對每個波段進行分組，以便一次變更就能套用到其中的每個據點。Meraki 設定範本、Juniper Mist WLAN 範本和 HPE Aruba Central 群組都適合這種做法。

請在據點員工在場時進行切換，而不是在凌晨 3 點。直到早晨才有人測試的變更，就等於您未曾測試過的變更。避免將其他網路變更併入同一個變更窗口。

階段 4：停用舊伺服器

從資產清單中的每個 SSID 和每個 NAS 中移除舊伺服器，然後觀察其記錄檔。請求數應降至零。任何仍然收到的請求都來自您遺漏的 NAS。保持無流量狀態至少一個重新驗證週期加上一個工作週。然後根據您的保留政策匯出記錄檔，關閉伺服器並廢除其共用金鑰。

實際演練案例：使用 Cisco Meraki 的 40 家飯店集團

以一家在 Cisco Meraki 上運作員工 WiFi 的 40 家飯店集團為例。它使用 PEAP 來對抗總部的地端 RADIUS 伺服器。每個請求都會跨越廣域網路 (WAN) 傳送到一棟建築物，因此總部服務中斷會導致每家飯店的員工 WiFi 斷線。

該集團在第一週透過其 MDM 推送新的 CA。它在雲端 RADIUS 上針對 Microsoft Entra ID 重建了五個策略行，然後在一家擁有 120 條客房的城市飯店進行試行。隨後分別進行 5 家、10 家和 24 家飯店的波段遷移，每個波段都是一個 Meraki 設定範本。有一家飯店在某個下午復原了變更，因為房務管理的平板電腦僅信任舊的 CA。一週後，該飯店再次進行遷移。

結果：

• 所有 40 家飯店在六個變更窗口內完成遷移。
• 一個據點復原過一次變更。
• 總部不再處於驗證路徑中。

舊版與新版 RADIUS 伺服器如何並存運作？

平行運作取決於存取點如何進行故障移轉。NAS 會將每個請求傳送至其清單中的第一台伺服器。只有當第一台伺服器未在逾時時間內回應時，它才會嘗試下一台伺服器。

Access-Reject 會被視為已回應而非失敗，因此 NAS 不會在其他地方重試該請求。這會帶來兩個後果：

• 兩台伺服器必須提供相同的回應。 若回應不同，裝置的使用體驗將取決於剛好由哪台伺服器回應。
• 平行運作是安全網，而非測試。 請在階段 1 及試點階段測試原則。切勿透過等待觀察故障移轉的運作狀況來進行測試。

在第一個站台轉移前檢查逾時設定。雲端伺服器比您機房內的伺服器距離更遠。請比較每個站台的 NAS 逾時與重試設定及其往返時間。若設定過於緊湊，請求將無故故障移轉至舊伺服器，從而隱藏問題。請在進行驗證的同時，將 RADIUS 會計記錄轉移至新伺服器，使連線階段記錄集中存放在同一處。

各站台的轉移切換僅需對調這兩台伺服器的順序。這些步驟適用於每個站台，廠商之間的差異如步驟 2 所示。

{"title":"在無指定過渡日的情況下完成單一站點切換","steps":[{"title":"確認站點已準備就緒","body":"對照轉移檢查清單檢查站點：已列出 NAS、受控裝置上已安裝新 CA、連至 Purple 的路徑已開啟、站點負責人在場。","check":"該站點的所有前置條件皆已勾選。"},{"title":"在舊伺服器旁新增新伺服器","body":"使用 Purple 為該站點發行的共用金鑰，將 Purple 雲端 RADIUS 新增至 SSID 的 RADIUS 伺服器清單中。暫時將舊伺服器保留為第一順位。","check":"控制台顯示 SSID 對應這兩台伺服器。","variants":[{"label":"Meraki","body":"在 Meraki Dashboard 的 SSID 存取控制設定中新增伺服器，最好是在設定範本中新增。"},{"label":"Aruba","body":"在 HPE Aruba Central 中，將伺服器新增至 WLAN 所使用的驗證伺服器群組。"},{"label":"Ruckus","body":"將伺服器新增至 WLAN 所使用的 AAA 伺服器設定檔中，作為次要伺服器。"},{"label":"Mist","body":"在 Juniper Mist 入口網站中，將伺服器新增至 WLAN 的 RADIUS 驗證伺服器中，最好是在 WLAN 範本中新增。"},{"label":"UniFi","body":"在 UniFi Network 應用程式中，將伺服器新增至指派給 WiFi 網路的 RADIUS 設定檔。"}]},{"title":"在更換前進行測試","body":"從註冊為 RADIUS 用戶端的測試主機，向新伺服器傳送每個策略列的一個身分識別。","code":{"lang":"bash","text":"eapol_test -c eap-tls.conf -a <purple-radius-address> -p 1812 -s <shared-secret>"},"check":"每個身分識別都會依照策略對映獲得 Access-Accept 或 Access-Reject，並帶有預期的 VLAN。"},{"title":"對調順序","body":"將新伺服器設為主要伺服器，並保留舊伺服器作為次要伺服器。這即是正式切換。","check":"新伺服器記錄檔顯示來自該站點每個基地台的請求。"},{"title":"維持一個業務週期","body":"將拒絕率與您的基準線進行比較，並確認每個裝置類別皆已通過驗證。","check":"沒有無法解釋的拒絕，且站點通過了退出測試。"}]}

如何復原站點或批次過渡？

復原即是反向進行切換：您只需再次將舊伺服器放回第一順位。上述每個控制台中，這都只是一項設定變更。這唯有在舊伺服器仍在運作、未經變更且其共用金鑰保持完好的情況下才有效。這就是為什麼停用舊伺服器會放在最後一步，也是為什麼您要在第 1 階段開始時凍結舊伺服器上的策略。

在開始前先取得觸發復原條件的共識。常見的觸發條件包含：

• 無法連線且無法在當天修復的裝置類別。
• 與策略對映不同的 VLAN 指派。
• 在變更時間視窗內無法解釋、高於基準線的拒絕率。

{"title":"進行、暫緩或復原階段部署","start":"q1","nodes":[{"id":"q1","question":"是否有任何裝置類型在新伺服器上驗證失敗，但舊伺服器可正常通過？","help":"將依裝置類型分類的拒絕記錄，與切換前記錄的基準進行比較。","options":[{"label":"是","to":"q2"},{"label":"否","to":"q3"}]},{"id":"q2","question":"失敗是否僅限於單一裝置類型，且已有明確的解決方案？","help":"單一設定檔中缺少 CA 屬於已知可修正問題。多個類型的拒絕則否。","options":[{"label":"是","to":"o2"},{"label":"否","to":"o3"}]},{"id":"q3","question":"在該階段的所有據點中，每個測試身分是否都存取至預期的 VLAN？","options":[{"label":"是","to":"q4"},{"label":"否","to":"o3"}]},{"id":"q4","question":"該部署階段是否已運作完整個業務週期，且未出現未知的拒絕記錄？","options":[{"label":"是","to":"o1"},{"label":"否","to":"o2"}]},{"id":"o1","outcome":"進行：開始下一階段","detail":"記錄每個據點的結束測試結果，並排定下一個階段。","link":"[跨據點統一策略](guide:cloud-radius-multi-site)"},{"id":"o2","outcome":"暫緩：修復後重新測試","detail":"僅在受影響的 SSID 上將舊伺服器設為首選，修復設定檔或規則，然後重新執行結束測試。"},{"id":"o3","outcome":"復原該部署階段","detail":"在該階段的每個 SSID 上將舊伺服器設為首選，擷取兩台伺服器的日誌，並在再次嘗試前找出原因。","link":"[當 RADIUS 無法連線時](guide:radius-server-down-wifi)"}]}

執行任何復原後，請匯出兩台伺服器在失敗時間區段內的日誌。找出原因並在新策略中修復。接著在據點再次進行遷移前，針對受影響的列重新執行第一階段的實驗室測試。

如何確認遷移已完成？

當佐證資料證實遷移完成時，才算真正結束，而非最後一個據點完成遷移時。由五項測試來確認：

1. 舊伺服器在協定的觀察期內，記錄到的請求數為零。
2. 清單中的每一個 NAS 都出現在新伺服器的日誌中。
3. 真實裝置已測試了每一條策略列，並成功存取至預期的 VLAN。
4. 拒絕率等於或低於在第二階段前記錄的基準。
5. 舊伺服器已關閉、日誌已留存、金鑰已廢止，且維運手冊已更新。

請為每個據點保留一份單頁記錄，包含日期、結束測試結果及任何復原情況。這些記錄與新的身份驗證日誌一起，將作為 ISO 27001 存取控制與 PCI-DSS 日誌稽核控制的佐證。它們也能在下一個稽核週期中作為變更控制的憑據。

實務中常見的失敗模式

僅信任舊憑證的裝置

這是最常見的失敗原因。未管理的 PEAP 裝置可能會提示需要新憑證，或直接拒絕新憑證。部分受管理的設定檔除了 CA 之外，還會指定伺服器名稱。在先導測試前，請務必確認這兩者。

未列在清單中的 NAS

遺留的控制器、有線 802.1X 交換器和 VPN 閘道會在 WiFi 移轉完成後很久，繼續讓舊伺服器保持忙碌。階段 4 的觀察期就是抓出這些問題的關鍵時機。

存在於舊伺服器上的原則

本地群組、硬編碼的 MAC 清單和時間段規則通常僅存在於舊伺服器上。如果這些規則未包含在原則對映中，會在切換時消失。

共用金鑰與屬性不符

打錯金鑰在某些主控台上會靜默失敗。按名稱而非按 ID 回傳的 VLAN 可能會將裝置放置到預設 VLAN。這兩種情況都應該在階段 1 測試中出現，且您應在試行階段再次檢查。

針對建築物內伺服器調整的逾時設定

NAS 上過緊的逾時設定會導致虛假的故障轉移至舊伺服器。在移除舊伺服器之前，一切看起來都運作正常。

實作情境：擁有兩種主控台的 120 家門市零售商

以一家擁有 120 家門市的零售商為例，舊門市使用 HPE Aruba，新門市使用 Juniper Mist。門市手持設備和筆記型電腦針對一對本地 RADIUS 伺服器使用 EAP-TLS。試行和分批推廣進展順利，按 Aruba Central 群組和 Mist WLAN 範本進行分組。

在階段 4 中，即使每個 SSID 都已移轉，舊伺服器仍會繼續記錄來自三個位址的請求。其中兩個是門市資產之外的物流中心控制器。第三個是總部筆記型電腦的 VPN 閘道。團隊將這三個位址全部新增至清單中，在一個額外維護視窗中進行移轉，並重新開始觀察期。退役工作延後兩週完成，但所有門市均未發生任何中斷。

Purple 的定位

Purple Access 在單一平台上利用您現有的存取點，運行開放、安全與 xPSK 網路。安全網路 可承載此移轉。它提供來自 Microsoft Entra ID、Okta 或 Google Workspace 的雲端 RADIUS、EAP-TLS 與身分驗證。它還支援 Passpoint（也稱為 Hotspot 2.0），允許裝置憑藉憑證自動加入安全網路。Purple 獨立於硬體之外，因此單一原則即可為以下平台上的站點提供服務：

• Cisco Meraki
• HPE Aruba
• Ruckus
• Juniper Mist
• Ubiquiti UniFi
• Cambium
• Extreme Networks
• Fortinet

這意味著混合型資產可以按照單一計劃進行移轉。

Purple 運行著全球最大的雲端 RADIUS。它附帶 99.9% RADIUS 正常運行時間 SLA，運行於達到 99.999% 正常運行時間的平台上。由於 Purple 端是在階段 2 開始前建置完成的，因此每個站點的切換通常只需週末的時間即可完成。分階段推進旨在管理您現有資產中的風險，而非我們平台上的風險。

{"items":[{"value":"80,000+","label":"實體場域","note":"Purple 內部資料"},{"value":"90","label":"個國家"},{"value":"99.9%","label":"RADIUS 正常運行時間 SLA","note":"運行於達到 99.999% 的平台上"}]}

{"tone":"proof","title":"分行規模的員工 WiFi","text":"JPMorgan 在 5,000 家分行中使用 Purple 運行員工 WiFi。"}

如需詳細產品資訊，請參閱 Purple Access 上的雲端 RADIUS；如需更廣泛的控制措施集，請參閱 企業 WiFi 安全性指南。訪客行銷功能位於 Engage，DNS 過濾功能則位於 Shield。兩者在 RADIUS 移轉期間均不會有所變動。

常見問題

多案場 RADIUS 移轉需要多久時間？

整體全區預計需要數週，每個案場則需一個週末。在 Purple 上，每個案場的切換作業通常可在週末完成。整體全區需要較長時間，是因為每一波移轉都需要維持一個業務週期，才會開始下一波。以包含 40 個案場的示範全區為例，從盤點到停用大約需要 12 週。大部分時間都花在準備和維持期間，而非變更作業本身。

移轉至雲端 RADIUS 需要新的基地台嗎？

不需要。雲端 RADIUS 變更的是基地台查詢的伺服器，而非基地台本身。Purple 適用於 Cisco Meraki、HPE Aruba、Ruckus、Juniper Mist、Ubiquiti UniFi、Cambium、Extreme 及 Fortinet。您只需在現有的主控台中，將新伺服器新增至每個 SSID 的 RADIUS 伺服器清單即可。您的 SSID、VLAN ID 和交換器設定皆保持原樣。

我該如何評估多個案場的雲端 RADIUS 成本？

請根據兩個數字進行評估：案場數量與身分數量。計算需要進行驗證的每個案場，以及加入的每個身分，包含 EAP-TLS 上的裝置。接著將其與舊伺服器的完整成本進行比較：硬體、授權、修補程式套用、高可用性以及連至總部的 WAN 路徑。我們的 評估每個案場的雲端 RADIUS 成本指南 將引導您完成計算。

移轉後我可以保留舊的 RADIUS 伺服器作為後備嗎？

請在平行運作期間保留它，之後即可關閉。當它被列為備用伺服器時，可涵蓋仍處於移轉波次中之案場的超時狀況。在第 4 階段之後，保留舊策略凍結副本的伺服器會成為一種風險，因為它提供的任何回應都是使用過期的規則。從那時起，復原能力將來自 99.9% 的 RADIUS 服務水準協定 (SLA) 以及 服務中斷復原計畫。

員工是否必須重新註冊其裝置？

如果在切換前已信任新的伺服器憑證，則不需要。請在建置階段透過 MDM 將新的 CA 推送至受管理裝置。只要新的伺服器信任簽發凭證的 CA，EAP-TLS 裝置就會保留其現有的用戶端憑證。未管理的 PEAP 裝置則是例外，因為部分裝置會提示一次接受新憑證。請在這些員工的案場移轉前向他們傳送簡短通知。

移轉是否會影響我們的 ISO 27001 或 PCI DSS 證明？

這會改變您佐證資料的來源，因此請從一開始就做好規劃。驗證日誌、原則定義與變更記錄都會轉移至新平台。請根據貴單位的保留政策保留舊伺服器的日誌，並歸檔每個站點的退場測試記錄。Purple 擁有 ISO 27001 認證，可為您的稽核人員提供平台端的佐證資料。而您自身的控制措施仍需要提供各自的佐證資料。

這對於管理多個客戶環境的 MSP 有何不同？

階段流程是相同的。不同之處在於客戶環境之間的隔離。MSP 對每個客戶環境執行相同的四個階段，但每個環境都需要在共用平台上擁有獨立的原則、身分來源與日誌。批次推進通常遵循合約邊界，而非控制台範本。我們針對 MSP 多租戶 RADIUS 指南 的內容，涵蓋了如何在轉移期間及轉移後保持每個客戶環境相互獨立。