ERP账号被盗：本地部署与云端谁更危险

开篇：一句话结论

行业里有个几乎没人质疑的默认动作：觉得系统不安全，就把它搬到云上去，交给服务商管。这个动作本身没错，但它掩盖了一个事实——绝大多数 ERP 账号失守，不是服务器被攻破，是口令被人拿到了。位置不是护身符，凭据和权限才是薄弱环节。所以本文不比较「本地和云端哪个更安全」，而是把责任拆开：谁管账号、谁管补丁、谁管网络边界。这三项落在谁身上，风险就由谁扛。下面给一张责任划分表、四条判断线、六条能当天配上去的账号防护动作，以及出事之后的三步止损。

一、责任划分：同一个账号，两种部署下的不同归属

先把话说具体。同样是「一个能导出客户名单的账号」，在两种部署形态下，管它的人完全不同。

这张表读一遍就能明白：云端不是把风险消灭了，是把风险里的几行搬到了别人名下。搬过去的那几行确实有人管，留下来的那几行——账号、口令、导出权限——无论哪种形态都在你自己手里。

据境外公开报道，2026 年 10 月 7 日，日本云服务商 IDC Frontier（软银旗下）遭勒索攻击，约 7 分钟之内就在「东日本区域 1」横向扩散，495 家客户组织失去对其虚拟服务器、网站与数据的访问；服务商次日告知客户，受影响区域的数据恢复困难，建议在独立环境中重建并恢复自己的备份。另据公开报道，勒索与数据窃取团伙 ShinyHunters 在 2024 至 2026 年集中攻击 SaaS 聚合点，常通过窃取的凭据、以及未强制多因素认证的账号批量导出数据。

两个案例讲的是同一件事：批量导出靠的是凭据，恢复靠的是自己的副本。这两件事都不取决于机房在哪。

本地部署这一侧的形态整理，放在本地部署这一侧的整理里。

二、什么情况哪种更危险：四条判断线

1. 看账号归谁管

共用账号是最典型的高危配置。一个「业务部」账号五个人用，出事之后你连是谁操作的都查不出来，因为日志里只有一个账号名。

判断方法很直接：把系统里的账号清单和在职名单对一遍，能对上的算合格，对不上的——多出来的、名字对不上的、离职三个月还在的——每一个都是一条敞开的路径。

还有一个几乎不花钱的动作：把账号的显示名统一改成「姓名加岗位」的格式。共用账号一眼就能认出来，因为它没有姓名。这动作不用改任何系统配置，只改录入习惯，效果却很明显。

2. 看补丁谁在打

云端部署下，系统补丁由平台承担，这一项基本不用管。本地部署下，Windows 补丁、ERP 版本补丁、数据库补丁三样都在你自己身上。

真实情况是多数公司半年不打一次。补丁这件事不需要复杂流程，按月固定一个晚上打完重启即可，难的是「固定」两个字。

3. 看网络边界开在哪

本地部署最常见的配置错误，是图省事把远程桌面直接暴露在公网上，端口对全网开放，口令还只有八位。这种配置下，账号被盗不是运气问题，是时间问题。

正确的做法是关掉公网直连，走 VPN 或者把访问来源限制在固定的几个 IP 上。边界收窄一道，攻击面就小一大截。

4. 看出事之后谁能先动手

云端出事，第一反应是找服务商；本地出事，第一反应只能靠自己。这一条是本地部署真正的代价：控制权回到你手里，响应速度的责任也一起回来了。

如果公司里没有一个能在半小时内停用账号、拉出导出日志的人，那么本地部署对你来说反而更危险。

内部那一侧的风险与外盗同源，都是「谁拿着钥匙」的问题，防控做法写在这篇里：内部人那侧的防控。

三、六条能当天配上去的账号防护

不依赖部署形态，今天就能做：

• 一人一号，禁用共用账号：账号清单与在职名单每月对一次，多出来的立刻停用。
• 口令长度 12 位以上，90 天强制更换一次，且不允许与邮箱、网盘的口令相同。
• 连续失败 5 次锁定账号，锁定时长设为 30 分钟，防止在线爆破。
• 开启多因素认证：这一条堵的是「口令泄露就等于账号失守」这条链路。
• 导出权限收口：能导出客户名单与成本价的账号控制在两人以内，每次导出写日志。
• 网络入口不对公网开放：远程桌面关掉公网直连，改走 VPN 或来源 IP 白名单。

前三条属于口令层面，后三条属于凭据与边界层面。六条里有五条不需要花钱，只需要有人去配。

真要排优先级，先做两条：口令长度、网络入口。前者挡撞库，后者挡扫描，覆盖面最大。剩下四条按季度补上，一个季度配两条，半年就能配齐。

备份副本这一层不在本文展开，完整步骤写在这篇里：备份与恢复的具体步骤。等保流程走到哪一步、数据分类分级怎么落地，等保要做到哪一步那篇给了能执行的口径。

四、出事之后的三步止损

第一步，断。停用被盗账号，强制全员改口令，同时检查账号清单里有没有新增的陌生账号——攻击者留下后门账号是很常见的动作。

第二步，查。拉导出日志，重点看两处：非工作时段的批量导出、单账号一次导出的记录条数异常。确认导出范围与去向，才能判断影响面。

第三步，收。通知受影响的客户并内部通报，同时从一份确认可用的副本恢复。客户名单外泄这件事，主动说比被客户先发现好处理得多。

三步的顺序不能颠倒。先断后查，先查后说——没有范围就急着通知，反而会放大误伤。

还有一步要在事后一周内补上：把这次的入口复盘成一条具体改动，比如关掉远程桌面的公网直连、把共用账号拆成一人一号。不复盘，同一条路径三个月后还会被再走一次。

五、控制权与责任一起回到本地

落到产品这一侧，相关的只有三处。一是账号与权限都在你自己的环境里，调整不需要向第三方申请：太帅ERP 的资料与权限模块支持角色精细授权，60+ 权限点可以逐项配，谁能看成本价、谁能导出客户名单是配出来的，不是默认全开。二是审批流可视化配置，改价、删除这类动作可以卡一道审批，等于给高权限操作加了一道门槛。三是财务管理有日结快照，配合每天一次的副本，能把某一天的状态单独留下来。

话说透一点：本地部署把控制权交回你手里，同时也把「出事后谁负责」交回你手里。云端出事，至少还有服务商的安全团队在另一侧响应；本地出事，从发现到处置到恢复，节奏完全由你自己的流程决定。所以本地部署适合愿意为控制权承担运维责任的公司，不适合以为放在自己机器上就自动安全的公司。前者把六条做成习惯，后者只是换了一个没人管的地方放数据。

局限也要讲明白。太帅ERP 是跑在单台 Windows 电脑上的程序，手机端没有原生应用；遇到安全问题主要靠远程指导，没有大厂那种随时响应的安全团队；副本由用户自己安排，软件不会自动帮你把备份挪到别处。多因素认证这类能力是否具备，以产品的实际配置与供应商的正式说明为准，本文不做超出产品事实的表述。

FAQ

口令 12 位加 90 天一换，会不会太麻烦？

比出事之后的麻烦小得多。口令这条链路的攻击成本几乎为零——攻击者拿到的是别人网站泄露的口令库，撞库是自动跑的。长度和更换周期挡的是这一层。

开了多因素认证，还需要收导出权限吗？

需要。多因素认证堵的是「拿到口令就能进来」，权限收口堵的是「进来了能带走多少」。两道门，缺一道都不完整。

导出日志开了，多久查一次？

账号少于二十人的公司，每季度抽查一次即可。重点看两处：非工作时段的操作、单次导出的记录条数。其余时间靠异常告警兜底。

准备从云端迁回本地，账号这块要提前做什么？

先把现有账号清单、权限分组、导出记录导出一份存档，再停用旧系统账号。迁回过程中的数据导出与迁移清单，这篇给了可执行的步骤：迁回本地的导出清单。

导出日志要留多久？

建议不少于 180 天。存储成本很低，麻烦的是一开始没设留存期。很多攻击是在事发几个月之后才被发现的，那时候日志如果已经被覆盖，连范围都查不出来。

结尾

不做的代价，比做错更大。这里说的「不做」，是指把「搬上云就安全了」当成终点。口令长度、失败锁定、多因素认证、网络入口、导出权限、日志抽查——这六件事没有一个依赖预算，依赖的是有没有人把它们配上去。配完之前，换什么部署形态都只是在换风险归属，不是在减风险。

先断后查，顺序别颠倒

一张责任表、六条防护动作、三步止损——做完这套，账号这件事就有了抓手。完整口径写在了配套的「为什么 IC 贸易公司的数据应该留在自己电脑里」那篇里：数据留在本地之后，权限怎么配、副本怎么安排、什么叫能随时拿回。安全不靠位置，靠谁每天在做那几件小事。

主 CTA：继续读：为什么IC贸易公司的数据应该留在自己电脑里 次 CTA：继续读：SaaS的三个隐性风险：涨价、停服与数据导出