很多公司上portal认证是被动的——出了安全事件之后要整改，或者总部发文说要做接入管控，于是IT部门开始找方案、采购、部署。这种情况下，决策往往很仓促，上线之后才发现漏了很多细节，返工成本很高。

这里整理了几个在部署企业portal认证之前应该先考虑清楚的问题，不是技术选型的问题，是业务需求层面的问题。

这套认证是管员工、访客，还是两类都管

员工和访客对portal认证的需求完全不同。员工需要的是稳定、低摩擦、每天都用的认证方式，最好和域账号打通，一次登录长期有效。访客需要的是临时快速接入，手机号或微信扫码，使用时间短，认证结束后自动回收权限。

如果两类用户混在一套SSID和同一套认证策略里，不是不行，但会产生很多管理上的麻烦。建议从一开始就分开：员工SSID走企业账号认证，访客SSID走临时认证，逻辑隔离，权限互不干扰。

公司有多个办公地点，怎么统一管

对于只有一个办公室的公司，这个问题不存在。但如果有多个园区、多个城市的分公司，认证系统的管理方式要提前规划。集中管理还是各地独立管理？员工出差到其他地点，认证账号能不能互通？

集中云控方案在这种场景下明显更合适：所有站点的认证数据汇总到统一后台，账号一处管，全国适用，出差员工不用找当地IT申请临时账号。但集中方案依赖网络质量，如果分支机构带宽差，认证请求回传总部时延高，体验会受影响，要提前评估。

认证数据需不需要和现有系统打通

很多企业有现成的身份系统：AD域、LDAP、钉钉、企业微信、飞书。portal认证如果能和这些系统打通，账号管理成本大幅下降——员工入职、离职、调岗，在HR系统操作一次，网络权限自动同步，不需要IT单独维护一套账号。

能不能打通，取决于认证系统有没有对应的接口。选型时这一点要明确问清楚，不要等采购了之后再发现接口不支持。

合规日志要留多久，存在哪里

公共网络实名制要求日志留存不少于6个月，部分行业有更严格的要求。日志存在本地还是云端，由谁负责备份，出现数据安全问题时怎么处理，这些都要在部署前确认。如果公司有数据本地化要求，云端存储方案可能不适用，要提前说清楚。

上线后谁来维护

portal认证系统不是装完就不用管的东西。账号要管理，日志要看，偶发的认证异常要排查，设备固件要更新。如果公司IT团队人手不足，或者有分支机构没有专职IT，要选运维成本低的方案，优先考虑有远程管理能力的云控系统，减少现场运维依赖。