# 为什么只靠账号密码的远程接入，已经挡不住一次撞库
去年有一家做外贸的公司，被人在凌晨三点登进了财务系统。
事后复盘发现，攻击者用的账号和密码是真实的，不是破解出来的，是从一个第三方网站泄露的库里撞出来的。那位财务经理有个习惯，好几个系统都用同一个密码，包括这个财务系统。
企业不是没做防护。他们买了防火墙，做了网段隔离，财务系统只能从内网或远程接入进来。问题在于，那道门验的只有一件事：你知道不知道密码。
一、撞库盯的不是你的系统，是人的习惯
所谓撞库，指的是拿别处泄露的账号密码组合，批量去试别的系统，赌的是同一个人在不同地方用同一套凭据。
这件事之所以有效，原因很朴素：一个人要记的密码太多了。办公系统、财务系统、邮箱、几个外部平台、还有各种需要注册才能用的工具。多数人的应对方式是复用，或者做一个很小的变形，比如后面加个年份。
对攻击者来说，这意味着拿到一个库，就能覆盖一大片目标。他们不需要知道你是哪家公司，只需要批量试。
密码本身没有变弱，是"密码作为单一凭证"这件事变弱了。一个能被复用、能被猜到、能在钓鱼页面上被输入进去的字符串，承担不了完整的身份证明责任。
二、远程接入把这件事放大了多少
内网时代，撞库的成功率天然受限，因为攻击者得先进到网络里。远程接入把这个前提去掉了——只要能访问到登录页，就能开始试。
这里有个容易被忽略的细节：**暴露在公网的登录入口，是被自动化工具持续扫描的**。不是有人专门盯上你，是扫描器在批量找有登录框的地方，找到之后扔字典进去。整个过程不需要人参与。
所以判断风险时，不该问"我们会不会被盯上"，而该假设"我们已经在被扫"。差别在于前一个问题让人倾向于认为自己是例外，后一个问题直接指向该补什么。
三、双因素认证到底加了一道什么
双因素认证指的是在密码之外，再要求一样东西来证明身份。常见的几类：
· **手机上的动态口令**，定时刷新，和服务器对时间
· **硬件介质**，插上电脑才能完成认证，私钥不出介质
· **生物特征**，指纹或掌纹，通常配合前两者使用
关键不在于用哪一种，而在于这道关卡**不依赖"你说出的一个秘密"**。撞库能成功，是因为密码是可以被搬运的信息；而动态口令是一次性的，硬件介质里的私钥从来不离开设备，这两样都搬不走。
一个建议是：远程接入这类暴露面，优先上双因素，而不是先加长密码复杂度。密码复杂度只是把猜中的概率压低一点，双因素是把"知道密码就能进"这个前提直接取消。
四、三种介质怎么选，不用纠结太久
选型时容易被"哪种更安全"这个问题困住，实际决策里更该问的是"这个岗位上的人，能不能接受这种使用方式"。
**动态口令适合覆盖面最大的场景。** 手机人人都有，不需要额外发硬件，部署成本最低。缺点是它依赖一台设备，手机丢失、换号、时间不同步都会带来支持工作量。所以这类方案真正考验的不是认证能力，而是运维支持流程——补发、解绑、临时码这几件事要有一份写清楚的处理办法。
**硬件介质适合安全要求高、人员相对固定的场景。** 私钥在介质内部生成、不导出，认证时是介质在做运算，不是在传一个密码。它的成本不只是采购价，还包括发放、挂失、补办这一套管理动作。人员流动大的岗位用这类介质，管理成本会明显上升。
**生物特征适合作为前两者的补充，而不是替代。** 指纹、掌纹这类方式解决了"介质忘带"和"密码记不住"的问题，但它通常要和账号绑定使用，很少单独作为身份凭证。实际部署里常见的是"密码 + 指纹"或"介质 + 指纹"的组合。
一个常见的落地做法是分层：普通员工用动态口令，运维和财务用硬件介质，特定岗位叠加生物识别。分层的目的不是省钱，是因为不同岗位的暴露面和接受度确实不一样，用一套方案硬套所有人，最后往往是在低要求岗位上加负担、在高要求岗位留下缺口。
安当SLA 支持把这几种方式统一到一套认证服务里，好处是策略可以按人、按系统、按场景分别配置，而不是每个业务系统各配一套。多系统环境里这一点很实际——否则同一家公司会出现三套不同的双因素流程，员工每天要在三种体验之间切换。
五、落地时最容易踩的三个坑
**第一个坑：只给管理员上，普通账号不上。** 攻击者恰恰更愿意挑普通账号，因为防护弱、权限够用、不容易引起注意。财务、人事、运维这三类账号应当是第一批。
**第二个坑：把所有认证都串成一条链，断了就全断。** 认证服务本身要有冗余，且要能降级——不是降级成"不用认证"，而是降级成备用通道，同时把这个动作记进日志并告警。
**第三个坑：上了双因素就当结束了。** 双因素解决的是"这个人是不是他声称的人"，不解决"这个人该不该有这些权限"。认证和授权是两件事，前者做完只是把人认准了。
六、怎么验证它真的生效
不用等出事。可以自己验一遍：找一个普通员工账号，在不告知的情况下尝试用错误密码连登若干次，看系统会不会在若干次之后锁定或告警；再试一次正确密码但缺少第二因素，看能不能进。
这两件事如果都按预期拦住了，说明链路是通的。如果第二件放行了，说明双因素只配在了界面上，没有配在认证流程里——这种情况在集成过多个系统的环境里很常见。
验证的时候还要多看一项：**失败之后会发生什么**。好的实现会在连续失败若干次后锁定账号并告警，而不是无限次让人试。差别在于前者能挡住自动化字典攻击，后者只是让攻击者多跑一会儿。
另外建议在上线前留一个"逃生口"的预案：认证服务本身故障时，业务怎么继续。这个预案不能是"临时关闭双因素"，那等于把门敞开；合理的做法是保留一条受监控的备用通道，只对特定角色开放，并且每一次使用都产生告警。这条通道平时不用，但必须演练过一次——没演练过的预案，出事时基本等于没有。
七、远程接入这件事的判断顺序
把上面几节收一下，顺序大致是：
1. 先清点暴露面：哪些系统能从外网访问，哪些必须暴露，哪些可以不暴露
2. 再给暴露面加第二因素，优先财务、人事、运维
3. 然后是权限收敛：认证解决"是不是他"，授权解决"他能做什么"
4. 最后是审计：登录成功、失败、异地、异常时段，这些要能被查到
安当SLA 在这条链上承担的是第二环：把动态口令、硬件介质、生物识别几种方式统一到一套认证服务里，让同一套策略能覆盖多个业务系统，而不是每个系统各配一套。实际部署时常见的做法是先在远程接入和财务系统上跑通，再逐步扩到其他系统——因为这个顺序下，出问题的影响面最小，也最容易验证。
回到开头那家外贸公司。他们后来做的事并不复杂：给远程接入加了动态口令，把财务系统的密码全部重置并禁止复用，加了一条异地登录告警。真正起作用的不是哪一件产品，而是他们终于承认了一件事——密码能证明你知道某个字符串，证明不了你是你。
