iPSK ind：企业综合指南

欢迎阅读 Purple 技术简报。今天我们将介绍 iPSK ind（即针对个人设备的个人预共享密钥），以及为什么它已成为在大型托管 WiFi 部署中，物业开发商、建设出租（build-to-rent）运营商和多住户单元（MDU）业主首选的身份验证标准。 如果您正在管理住宅区、学生公寓或混合用途物业的 WiFi，您几乎肯定遇到过同样的瓶颈。您的住户期望获得与在家中相同的 WiFi 体验：简单、可靠且具有私密性。但您的网络团队需要单点访问控制、安全隔离，以及在租约结束时立即撤销访问权限的能力。传统方案会迫使您只能两者择其一。而 iPSK ind 则完全消除了这种妥协。 首先让我为您介绍一下背景。大多数组织多年来一直使用的两种成熟 WiFi 身份验证模型。 第一种是 WPA2 个人版（WPA2-Personal）- 也就是大多数人所说的共享密码。网络上的每个人都使用相同的密码。它很简单，适用于每台设备，并且只需要极少的基础架构。问题是它存在单点故障风险。如果一个住户分享了他们的密码，或者一台设备被攻破，整个网络就会暴露。而且，如果您需要撤销某个人的访问权限（例如已搬走的租户），您必须为所有人更改密码。在一个拥有两百套公寓的住宅区中，这根本无法管理。 第二种模型是 WPA2 或 WPA3 企业版，它使用 IEEE 802.1X 身份验证框架。在这种模式下，每个用户都使用各自的凭据（通常是用户名和密码或数字证书）进行身份验证，并通过 RADIUS 服务器进行验证。它高度安全，能提供细粒度的单用户访问控制，是企业托管设备的黄金标准。但它在住宅和酒店环境中有一个致命的弱点：复杂性。在每台设备上设置公钥基础结构、管理证书以及配置客户端是一项重大工程。而且至关重要的一点是，许多设备根本无法做到这一点。游戏机、智能电视、物联网传感器、Chromecast、Amazon Echo 设备 - 这些无界面的设备没有机制来处理基于证书的身份验证。在建设出租项目中，对于住户很大一部分设备而言，802.1X 根本无法运行。 这就是 iPSK ind 的用武之地。其核心概念非常优雅。每个住户或设备都会收到自己唯一的预共享密钥，但他们都连接到同一个 SSID - 相同的网络名称。从住户的角度来看，这感觉就像连接到家庭 WiFi 网络一样。他们输入密码，然后就上线了。从网络的角度来看，每个连接都是单独识别、单独加密且单独控制的。您既能获得共享密码模型的简单性，又能获得企业级访问控制的细粒度。现在让我为您介绍一下技术架构，因为理解这一点是正确部署的关键。 当设备尝试连接到启用 iPSK 的 SSID 时，无线局域网控制器（即 WLC）会拦截连接尝试，并将设备的 MAC 地址转发给 RADIUS 服务器。这就是智能所在。RADIUS 服务器在其身份存储中查找该 MAC 地址，并返回一个 Access-Accept 响应。至关重要的是，该响应中嵌入了分配给该特定设备或居民的唯一预共享密钥。WLC 接收此密码，并使用它来验证设备在 WPA2 四步握手期间提供的密钥。如果匹配，则该设备通过身份验证。 对于物业运营商来说，这种架构真正实用的地方在于与该身份验证同时发生的事情。RADIUS 响应还可以携带 VLAN 分配、带宽策略和访问控制属性。因此，设备不仅可以获得自己唯一的加密密钥，还可以自动放置在正确的网络段中。居民在 VLAN 10，物联网设备在 VLAN 20，员工和维护人员在 VLAN 30。所有这些都来自同一个 SSID，并且全部集中管理。 主要的硬件厂商都实现了自己版本的这种技术。Cisco Meraki 称之为 iPSK。HPE Aruba 称之为 MPSK。Ruckus 称之为 DPSK - 动态 PSK。Juniper Mist、Ubiquiti UniFi、Cambium、Extreme Networks 和 Fortinet 都支持等效的实现。它们背后的基本原理是完全相同的。 iPSK 还有一个特别适用于多租户部署的功能，那就是私有区域网络概念。iPSK 实现了居民之间的第 2 层隔离。尽管数百台设备共享相同的物理基础设施和相同的 SSID，但每个居民的流量在密码学上都与所有其他居民的流量相隔离。在启用 mDNS 反射的情况下，居民仍然可以发现并使用他们自己的设备 - 投屏到他们的 Chromecast，打印到他们的便携式打印机 - 而没有任何邻居看到或访问这些设备的风险。这就是高端长租公寓开发项目中的居民所期望的如家般的体验，在共享基础设施上得以实现。 让我继续介绍实施，特别是我们在部署中最常遇到的陷阱。 最常见的错误是将 iPSK 纯粹视为一个技术项目，而不是一个运营项目。技术本身的配置相对简单：WLC 上的 MAC 地址查找，具有适当属性值对的 RADIUS 服务器，以及 VLAN 策略。更难的问题是密钥生命周期管理。密钥如何分发？如何分发给居民？以及至关重要的是，租约结束时如何注销这些密钥？ 对这三个问题的回答都应该是自动化。在建房出租（build-to-rent）开发项目中，与您的物业管理系统集成意味着在确认租约时自动生成密钥，并在迁出日自动撤销。在学生公寓楼中，与您的学生信息系统集成意味着在注册时分配密钥，并在学年结束时自动失效。Purple 的平台提供了这个编排层，它介于您的身份提供商（无论是 Microsoft Entra ID、Okta 还是 Google Workspace）与您的 RADIUS 基础设施之间，从而在无需人工干预的情况下实现完整密钥生命周期的自动化。 第二个陷阱是 RADIUS 服务器的弹性。您的 iPSK 部署的可靠性完全取决于您的 RADIUS 基础设施。如果 RADIUS 服务器不可用，则新设备将无法进行身份验证。设计时应考虑冗余 - 采用主、备 RADIUS 服务器，并在 WLC 上进行适当的故障转移配置。对于大型开发项目，建议考虑使用保证在线时间 SLA 的云托管 RADIUS 服务，而不是本地服务器。 第三：在正式启用前测试您的 IoT 设备群。大多数 IoT 设备都能与 iPSK 完美协作，但一些较旧的设备在处理 WPA2 四次握手时存在一些奇特问题。部署前的兼容性测试，特别是针对任何定制或遗留硬件的测试，将为您在调试期间节省大量的精力。 现在，让我来解答一些我最常被问到的问题。 iPSK 是否支持 WPA3？支持，但有一些限制。WPA3-SAE 改变了握手机制，这会影响 iPSK 密钥的验证方式。大多数现代控制器在 WPA2 和 WPA3 过渡模式下支持 iPSK，这提供了向后兼容性。Cisco Meraki 的不带 RADIUS 的 IPSK 功能目前不支持 WPA3 加密 - 您需要使用基于 RADIUS 的版本才能实现 WPA3 兼容性。 单个 SSID 可以支持多少个唯一的密钥？这取决于控制器。Cisco Meraki 在固件 MR 30.1 及更高版本上，每个 SSID 最多支持五千个 iPSK。在实际应用中，限制因素通常是您的 RADIUS 服务器的数据库容量和查询性能，而不是无线控制器本身。 iPSK 符合 GDPR 要求吗？iPSK 本身是一种网络身份验证机制，而不是数据收集工具。GDPR 合规性问题与您如何存储和处理与每个密钥相关联的身份数据（居民姓名、租约详情和设备信息）有关。这些数据需要按照 GDPR 第 5 条的原则进行处理。Purple 已通过 ISO 27001 认证，符合 GDPR 和 CCPA，并且是 B Corp 认证企业，因此平台级的数据处理已得到保障。 iPSK 可以替代 Captive Portal 吗？在大多数住宅部署中，是的。使用 iPSK ind，身份是在密钥配置阶段确立的，此时居民甚至还没有连接。密钥本身就是凭证。您仍然需要服务条款接受工作流，但这发生在入网注册阶段，而不是每次连接时。这消除了住宅 WiFi 中最大的单一痛点。 总之，iPSK ind 为每位居民和设备提供独立的加密密钥、基于 VLAN 的流量分段、居民之间的二层隔离以及自动化的密钥生命周期管理 - 所有这些都基于单一 SSID 并在硬件无关的基础设施上实现。当您拥有包含物联网和无屏幕设备的混合设备群、需要独立访问控制而又不想引入 802.1X 的复杂性，以及当居民体验是您项目的差异化优势时，它是正确的选择。 在部署中需要做对的三件事：从第一天起就实现密钥生命周期管理自动化、针对 RADIUS 冗余进行设计，并在您的入网流程中解决 MAC 地址随机化问题。 如果您想了解 Purple 如何在建设租用（build-to-rent）和多户住宅项目中部署 iPSK ind，purple.ai 上的实施指南提供了详细的架构图和针对特定厂商的配置参考。如果您需要对您的特定环境进行技术评估，我们的网络架构师可为您提供无义务咨询。 感谢收听。以上就是本期 Purple 技术简报。