银行网点的无线网和别处不一样。它承载的不只是让客人上个网，还有员工用移动设备办理业务的场景，数据交互里可能涉及客户的身份信息和账户信息。所以这类项目的安全要求天然高一档，等保要求也明确。Portal 认证系统在这里承担的是入口那一段，但它不是孤立的一层，它嵌在一整套防护体系里。方案里如果把认证单拎出来讲，很容易和实际要求对不上。
第一层是终端准入
最外面这层决定谁的设备能进来。访客连上无线信号后弹出认证页面，未通过认证之前只能访问这个页面本身，别的都去不了。员工侧要求更严，通常只放行登记过的办公终端，新增终端要走审批。这一层和 Portal 的关系最直接，页面能不能稳定弹出、认证通过之后能不能立刻放通，都取决于认证系统和接入设备的配合是否到位。
第二层是无线传输
这层管的是信号本身会不会被截获或者被仿冒。员工网络和访客网络通常采用不同的加密方式，访客区的加密强度和员工区不同。无线侧还要能发现仿冒的接入点、信号劫持、密码破解这类行为并告警。严格说这一层主要是无线设备的能力，不是认证系统的活，但方案里必须说清分工，否则客户会以为上了认证系统就能接管无线侧的安全。
第三层是网络边界
认证通过之后能去哪里，由这一层决定。访客网络通常只允许访问外网，并且可能限制在白名单地址范围内，不允许触达银行内网和业务系统；员工网络可以访问内部业务系统，同时对外部访问做限制。实现上靠网段划分加防火墙策略。这里最容易出的问题是认证和网段没配合好：认证通过了，但用户被分到了错误的网段，或者反过来绕过认证直接进了内网。
第四层是数据存储和传输
认证过程中会接触到手机号、证件号这类敏感信息，怎么存、怎么传必须有说法。传输环节要有加密，存储环节要对敏感字段加密，认证日志和上网日志最好放在受保护的分区里，防止被随意修改或删除。这一层常常在项目后期才被提出来，但它应该在方案阶段就定好，因为它会影响日志服务器的位置和容量设计，事后补代价不小。
第五层是审计和溯源
最后一层的目标很朴素：出事能查到人。认证系统要把认证操作、管理员的配置变更、用户的上网行为都记录下来，并且能按时间、按人、按终端去查。溯源的链条通常是从终端标识到地址，再到认证账号，最后到具体的上网记录。这条链任何一环断了，追溯就停在那里，所以设计时要逐环确认能不能对上，而不是默认系统会自动串起来。
隔离要做到物理这一层
银行网点对员工和访客的分开要求比一般企业更硬，通常不是只做逻辑划分就算数，而是让访客网络和员工网络使用各自独立的无线设备，再叠加网段和防火墙策略做第二层保险。访客侧通常还会叠加营业时间的限制，非营业时段自动关闭。这样一套做下来，任何一侧出问题都不会直接波及另一侧，代价是设备投入明显增加。这笔投入要不要花，取决于网点的业务形态：只是给等候区提供上网，和员工用移动设备办理业务，两者的风险不是一个量级，方案阶段就要分开谈。
认证方式为什么不能用账号密码
在场景与认证方式的映射关系里，银行网点这一栏把账号密码直接列为不建议，推荐的双因子和基于端口的强认证。理由不复杂：网点场景涉及金融业务，账号泄露的代价太高，单因子的防护强度不够。代价是用户体验下降，员工每次接入多一步操作。这类取舍的判断标准只有一条：项目安全等级是不是最高那一档。是，就接受这个代价；不是，就不必强上。
时段和带宽也要跟着分
网点还有一个特点是有明确的营业时间。访客网络可以只在营业时段开放，非营业时段自动关闭，这既省资源也减少暴露面。带宽上也要按用户类型分开，访客拿到的份额明显小于办公用途。这类策略看起来细，但它们是把认证身份和实际资源分配连起来的那一环，没有它，认证通过之后所有人都一样，管理粒度就没了。
运维管控同样被要求
金融项目对运维操作本身也有要求：远程维护要走加密通道，不启用明文的管理协议；关键配置变更需要双人确认，避免单人误操作或者恶意篡改；管理员的操作要有审计记录。这些要求和认证系统直接相关，因为认证策略的变更会影响大批用户。实施时要把这些要求落成具体的权限配置和操作流程，而不是只写在制度文件里。
落地前该确认什么
这类项目启动前有几件事必须确认清楚：内网网段划分和安全域边界、现有安全设备的对接口径、监管和等保的具体要求、网点数量和分布、是否需要和行内已有的安全管理系统联动。这些确认完才能定方案，因为它们决定了认证系统放在哪、日志存多久、和哪些系统对接。信息不全时不要直接给结论，先列清单确认，这是这类项目最基本的纪律。