访客接入企业WiFi看起来是最简单的场景。给他一个临时账号，或者让他用手机号收个验证码，访客上网走了，项目结束。实际上操作起来会发现，这个问题没有这么简单。访客有多种类型，每种类型对WiFi的需求和限制条件都不一样；临时密码的时效怎么设、被访部门怎么通知、离场后账号怎么处理，这些细节没设计好，访客WiFi就变成了管理漏洞。

访客WiFi的三种典型场景

第一类是来公司开会或者拜访的客户。这类访客通常有明确的接待人，接待部门希望访客能快速上网，但不希望访客的设备能访问内网资源，只做互联网接入。理想的流程是访客到达前由接待人在系统里创建临时账号，访客到店后直接输入账号密码上网，不用在前台等手机验证码。这类访客的账号有效期通常按天计算，项目结束或者当天离开后自动失效。

第二类是施工单位或者驻场外包人员。这类访客的接入需求持续时间更长，可能是几周甚至几个月，而且这类访客往往需要访问部分内网资源，比如项目管理系统或者内部文件服务器。账号管理不能完全放给接待部门，需要有IT部门统一管控，权限范围要精确控制。临时密码在这里不够用，需要单独的访客账号体系，而且这类账号最好能和外包合同周期绑定，合同到期账号自动失效。

第三类是临时访客，比如合作方上门来签个字就走。这类访客的接入时间可能只有十几分钟，要求是快、简单、不需要任何提前预约。前台工作人员可能每次都要手动生成临时账号，但这种方式的问题是账号生成后没有办法追踪是谁开的、用于什么目的，审计时查不到记录。很多企业在这个环节上管理空白。

访客账号管理的核心问题

访客WiFi最大的管理挑战是账号生命周期。临时账号开出去容易，收回来难。访客离开后账号如果一直有效，就等于在企业内部网络上留了一个开放入口。现实中很多企业的访客WiFi账号是开了不收的，导致内部网络中积累了大量失效但未删除的访客账号。

解决这个问题需要从流程设计上入手，而不是完全依赖运维人员手动清理。比较好的做法是把账号有效期和接待流程绑定：访客账号由接待人负责创建，账号有效期默认与接待人预填的离场时间一致；如果没有填离场时间，则默认当天有效，第二天自动失效。接待人有责任在访客离场后主动注销账号，如果没有注销，系统自动清理。这种机制把账号管理的责任从IT部门移到了业务部门，IT只需要处理异常情况。

蓝海卓越V7系统支持访客账号生命周期管理，可以设置默认有效期、接待人通知机制、离场自动失效策略。接待人创建访客账号时会收到一条确认短信或者邮件提醒，账号即将到期时会收到续期或者确认离场的通知。如果访客没有按预期离场，系统自动冻结账号，接待人收到提醒后可以手动确认延期或者强制注销。这个机制可以把访客账号的清理工作从被动处理变成主动触发。

访客WiFi的权限边界设计

访客WiFi的权限设计原则应该是：最小权限，按需开放。访客设备不应该能访问内网的任何业务系统，只能访问互联网资源；但不同类型的访客对互联网资源的访问权限也可以有差异，比如施工单位可能需要访问外部的开发环境和测试服务器，客户访客可能只需要访问公司官网和邮件系统。

权限设计可以基于SSID做区分，也可以基于账号角色做区分。基于SSID区分的方式是在企业内部部署两个SSID。Guest-WiFi只提供互联网访问，访客接入后不能访问任何内网IP段；内部WiFi提供给有权限的员工使用。基于账号角色区分的方式是所有访客都接入同一个SSID，但系统根据账号的角色属性决定该访客可以访问哪些资源。

两种方式各有优劣。SSID区分更简单，在路由器或者AC上配置ACL就能实现，不需要认证系统参与，但访客如果连接了内部SSID的WiFi就无法管控。账号角色区分需要认证系统支持精细的权限控制，但灵活性更高，可以针对单个访客账号设置精确的访问范围，适合访客类型复杂的中大型企业。

访客入网前的身份确认不能省

访客WiFi还有一个容易忽略的环节是身份确认。访客接入WiFi之前，是否需要确认身份？这个确认指的是访客向系统证明"我是谁"，而不是系统知道"访客是谁"。很多企业的访客WiFi只要输入手机号收个验证码就能上网，没有任何身份验证环节，这意味着任何人拿着一个手机号就能接入企业网络。

对于安全要求较高的企业，可以在Portal页面加一道身份确认。访客输入手机号后，系统发送的验证码里包含一个随机码，访客需要把随机码告知接待人，接待人确认访客身份后才能输入验证码完成认证。这个流程增加了访客入网的前置确认环节，虽然多了一步，但对于有保密要求的企业来说是必要的。

对于安全要求较低的场景，也可以选择身份证后六位加房间号认证，这在酒店场景里很常见。访客输入身份证后六位加房间号，系统实时联网公安数据库核验身份，完成后才允许接入互联网。这个方式在安全性和便捷性之间取得了平衡，适合对身份确认有一定要求但又不希望流程过于复杂的场所。

访客WiFi不是小事。访客账号管理混乱、权限边界不清、身份确认缺失。这三个问题任何一个单独拿出来都可能在关键时刻变成安全事件。在选型阶段把访客场景的完整需求列清楚，比上线之后再打补丁要划算得多。