多站点 RADIUS 迁移：确定站点、接入点和策略的转换顺序

您可以在四个阶段内将多站点资产迁移到云端 RADIUS，无需停机切换（flag day），新旧服务器可并行运行。每个 SSID 都会列出这两者，且每台设备都会信任新的服务器证书。每个站点都在包含书面退出测试的 IEEE 802.1X 规范下进行切换。在 Purple 上，切换本身通常只需要一个周末的时间。

在多站点 RADIUS 迁移中，哪些会改变，哪些会保持不变？

最终状态是一套为每个站点提供服务的云 RADIUS 策略，由身份信息来决定 VLAN。定义于 RFC 2865 的 RADIUS 是您的接入点用于询问服务器某台设备是否可以接入的协议。服务器负责接受或拒绝该设备，还可以返回相关属性，例如设备接入的网络段（VLAN）。

在安全网络中，该交互在 IEEE 802.1X（基于端口的网络访问控制标准）内部运行。802.1X 在设备、接入点和服务器之间传输 EAP（扩展身份验证协议）。定义于 RFC 5216 的 EAP-TLS 使用证书对双方进行身份验证。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":"废除与旧服务器一起使用的共享密钥"},{"text":"更新运维手册并归档每个站点的退出测试记录"}]}],"download":{"filename":"radius-migration-checklist.csv"}}

顺序排列的 4 个阶段是什么？

该计划分为四个阶段。每个阶段都以可通过或失败的退出测试结束。在测试通过之前，任何项目都不能进入下一阶段，这就是避免“一次性”硬切换破坏业务的方法。

{"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 完全一致，以便交换机和防火墙配置无需任何变更。

在实验室中测试每一行。使用 wpa_supplicant 项目中的工具 eapol_test。它会向 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 家酒店集团为例。它针对总部本地的 RADIUS 服务器使用 PEAP。每个请求都会跨越 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 实验室测试。

如何确定迁移已完成？

当证据表明迁移已完成时，迁移才算完成，而不是在最后一个星点迁移时。以下五个测试标志着迁移结束：

1. 旧服务器在约定的静默期内记录的请求数为零。
2. 资产清单中的每个 NAS 都出现在新服务器的日志中。
3. 真实设备已测试了每条策略行，并落在了预期的 VLAN 上。
4. 拒绝率等于或低于您在阶段 2 之前记录的基线。
5. 旧服务器已关闭，其日志已保留，其密钥已作废，且操作手册已更新。

为每个星点保留一份单页记录，包含日期、退出测试结果和任何回滚情况。这些记录与新的身份验证日志一起，构成您符合 ISO 27001 访问控制和 PCI-DSS 日志记录控制的证据。它们还可作为下一个审计周期的变更控制证据。

现场常见故障模式

仅信任旧证书的设备

这是最常见的故障。未管理的 PEAP 设备可能会提示接受新证书或直接拒绝。一些托管的配置文件既固定了 CA，也固定了服务器名称。在试点之前请检查这两项。

未在清单中列出的 NAS

在 WiFi 迁移完成很久之后，那些被遗忘的控制器、有线 802.1X 交换机和 VPN 网关仍会让旧服务器保持忙碌状态。阶段 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 网络。其 安全网络 支持此迁移过程。它提供云端 RADIUS、EAP-TLS 以及来自 Microsoft Entra ID、Okta 或 Google Workspace 的身份验证。它还支持 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 是否需要新的 AP 接入点？

不需要。云端 RADIUS 更改的是 AP 接入点查询的服务器，而不是 AP 接入点本身。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 推送到受管设备。EAP-TLS 设备将保留其现有的客户端证书，前提是新服务器信任颁发这些证书的 CA。不受管的 PEAP 设备属于例外情况，因为某些设备会提示一次以接受新证书。在其站点迁移前，请向这些员工发送简短通知。

迁移是否会影响我们的 ISO 27001 或 PCI DSS 凭证？

这改变了证据的来源，因此需要从一开始就做好规划。认证日志、策略定义和变更记录都将迁移到新平台。请根据您的保留策略保留旧服务器的日志，并归档每个站点的退出测试记录。Purple 拥有 ISO 27001 认证，可为您的审计人员提供平台侧的合规证据。您自己的控制措施仍需要各自的证据支持。

这对于管理多个客户环境的 MSP 有何不同？

阶段是相同的。不同之处在于各客户环境之间的隔离。MSP 对每个客户环境执行相同的四个阶段，但在共享平台上，每个环境都需要独立的策略、身份源和日志。推进批次通常遵循合同边界而非控制台模板。我们关于 针对 MSP 的多租户 RADIUS 指南 涵盖了如何在迁移期间和迁移后保持每个客户环境相互独立。