Skip to content
SolanaLink LogoSolanaLink
从 2026 年 10 月日韩两起安全事件看 Web 服务加固：一份实践指南

从 2026 年 10 月日韩两起安全事件看 Web 服务加固：一份实践指南

Tony•
图片由xAI Grok生成
6 分钟阅读
0
0 条评论
11 次浏览

从 2026 年 10 月韩国银行数据泄露和日本 IDCF 云勒索软件攻击出发，介绍 Web 服务的六层加固措施，附配置示例和验证方法。

为什么要关注这两起事件

2026 年 10 月的头十天里，韩国和日本的金融、云服务领域先后发生了两起互不相关的安全事件。在韩国，攻击者进入了多家银行和贷款机构面向互联网的业务系统，拿走了数万名客户的贷款和收入信息。在日本，IDC Frontier 的公有云 IDCF Cloud 遭到勒索软件攻击，495 家企业和地方政府的虚拟服务器停止运行，云服务商表示受影响区域的数据很难恢复。

这两起事件都不需要什么新型攻击手法。外围系统的认证被绕过，备份和生产环境放在同一个平台上，发现入侵花了几个小时甚至几天。大多数 Web 服务或多或少都有类似的问题，所以即使你不是在运营银行，这两起事件也值得仔细看一看。

本文整理三部分内容：已经公开确认的事实；攻击者普遍使用 AI 之后发生了什么变化；以及作为 Web 服务的技术负责人，我会采取哪些加固措施。每一项措施都附带配置示例和验证方法。全文基于截至 2026 年 10 月 10 日的官方公告和媒体报道，凡是攻击者自称或仅有媒体报道的内容，都会注明。

事件经过

韩国：银行和贷款机构接连被入侵

10 月 1 日，新韩银行公布，有外部人员以绕过认证的异常方式访问了其部分服务。主要目标是贷款中介在贷款申请过程中存放客户资料的平台。受影响客户约 2.5 万人（后更新为 25,727 人），泄露的数据包括贷款信息、年收入、姓名和电话号码。

随后几天里，其他机构也报告了类似事件：

机构公布的影响
Yegaram 储蓄银行约 4 万名客户，是目前单家机构规模最大的一起
新韩银行25,727 名客户
Welcome 储蓄银行最多 2,200 条法人客户记录
现代 Capital146 名房贷代理人的个人信息
KB 国民银行119 名客户
韩亚银行89 名客户
BNK 釜山银行11 名外包开发人员
友利银行、NH 农协银行遭到攻击，但已拦截，没有数据被拿走

有三点值得注意。第一，攻击者针对的是员工和贷款代理人使用的、面向互联网的业务系统，而不是管理余额和交易的核心系统。第二，发现得很慢：新韩银行用了 15 小时 26 分，韩亚银行 41 小时 44 分，KB 国民银行 67 小时 41 分。第三，监管机构指出主要弱点是认证薄弱，以及数据保留过多、访问权限过宽。10 月 4 日的紧急会议上，韩国金融委员会委员长表示不能排除攻击中使用了 AI。金融监督院把识别出的恶意 IP 地址通报给约 500 家金融机构，并要求紧急自查。

日本：IDCF Cloud 遭勒索软件攻击

10 月 7 日凌晨 3 点 40 分左右，软银子公司 IDC Frontier 检测到其公有云 IDCF Cloud 遭到未授权访问，随即将东日本区域 1 从网络中隔离，并停用了客户管理控制台。

10 月 8 日的第三份公告确认原因是勒索软件攻击。受影响的是东日本区域 1 中的 tesla、henry、pascal、joule 四个可用区，涉及 495 家企业和地方政府。这些区域里的虚拟服务器停止运行且无法重启。公司表示，这些区域中的客户数据预计难以取出或恢复，只能依靠客户自己保存的备份来恢复。其他区域没有发现入侵，但公司也要求那里的客户自行备份。入侵路径仍在调查中。

影响扩散到了构建在 IDCF Cloud 上的各种服务，其中很多是通过委托商间接使用的。10 月 9 日，JR 东日本旗下的信用卡公司 ViewCard 公布，其会员邮件系统中约 403 万个邮箱地址可能被查看或获取。JR 东日本（两项服务合计最多约 206 万）和 JR 九州（最多约 130 万）也公布了类似风险。这些都是调查范围的上限，不是确认泄露的数量。Peach Aviation 正在调查约 189 万条记录，尚未确认泄露。

备份放在哪里，结果差别很明显。Soliton Systems 报告说，放在同一平台上的备份服务器也一起无法使用。而把 Movable Type 云版备份放在 Google Cloud 的 Six Apart，在 10 月 8 日晚上之前就把全部 31 台受影响的服务器迁移到了另一家云。

社交媒体上流传着疑似攻击者发布的图片，声称加密了数百个数据存储、删除了 55 万多个快照。IDC Frontier 尚未确认这些数字。

AI 改变了什么，没有改变什么

过去半年，Anthropic、OpenAI 和 Google 的前沿模型在安全工作上变得相当强。Anthropic 表示，其未公开发布的 Claude Mythos Preview 在发现和利用软件漏洞方面，只有最顶尖的人类专家能够超过。英国 AI 安全研究所设计了一个 32 步的企业网络攻击模拟，人类专家完成大约需要 20 小时，并报告 Mythos Preview 是第一个从头到尾完成它的模型。

攻击者在使用他们能拿到的模型。Anthropic 2026 年 9 月的威胁报告显示，报告中记录的大部分网络攻击行动都让 AI 直接执行或协调攻击，而不只是回答问题。同一份报告里有一点，我认为对中小企业最重要：当强大的 AI 代理随手可用时，攻击一个不起眼目标所需的时间和人力几乎降到了零。"不值得打"已经不再是一种保护。

变化首先体现在速度上。Rapid7 发现，漏洞从公开到被列入 CISA 已知被利用漏洞目录（KEV）的中位时间，从 8.5 天缩短到了 5 天。Mandiant 的 M-Trends 2026 给出的平均利用时间是负 7 天，也就是说，漏洞常常在补丁出来之前就已经被利用。这些数字的统计口径不同，但方向一致。

也有相反的数据。VulnCheck 发现，AI 发现的漏洞中目前只有 1.3% 被实际利用，说明这些工具眼下对防守方至少同样有帮助。也没有人证明这些模型能够攻破防御完善的系统。防守方同样有了 AI 工具：OpenAI 的 Codex Security、Google 的 CodeMender 和 Anthropic 的 Project Glasswing，目标都是赶在攻击者之前发现并修复漏洞。

监管机构已经行动。5 月 22 日，日本金融厅和日本银行联名要求金融机构针对前沿 AI 带来的威胁变化采取短期应对措施。韩国金融监管机构也提到了 10 月的攻击可能使用了 AI。

我的理解是，AI 并没有制造新的弱点类型，它缩短了弱点从存在到被利用之间的时间。所以实际的目标是让防守的每个环节都更快：打补丁、检测、隔离、恢复。下面的六层就是按这个思路组织的，每一层都对应韩国或日本攻击链中的某一步。

第 1 层：缩小攻击面，把认证和授权做对

对应这次事件的哪一步。 韩国的攻击者根本不需要碰核心银行系统。他们找到旁边的一个贷款中介平台，绕过了它的认证。

常规做法为什么不够。 大多数团队会加固主登录和主应用，但管理后台、合作方门户、测试环境和旧版本 API 往往没人管。它们通常还在线上，很多还连着真实数据。

具体措施。

  • 持续盘点暴露面。 用 subfinder 和 httpx 枚举子域名和存活服务，每周用 nuclei 扫描一次，再和资产清单做对比。清单上没有的东西，要么指定负责人，要么关掉。
  • 管理后台不放在公网上。 放在 Identity-Aware Proxy 或 VPN 后面，入口和客户登录分开。
  • 管理员使用防钓鱼的 MFA。 FIDO2 硬件密钥或 passkey。普通用户至少用 TOTP。新密码用 Have I Been Pwned 的 k-anonymity API 检查是否已经泄露。
  • 严格校验 JWT。 在服务端固定允许的算法，拒绝 alg: none；校验 iss、aud 和 exp。Access Token 有效期控制在 5 到 15 分钟，Refresh Token 每次使用都轮换，一旦发现旧 Token 被重放，就吊销整条链。
  • OAuth / OIDC 按规范实现。 强制 PKCE，校验 state 和 nonce，redirect_uri 完全匹配。用身份提供方的 sub 作为稳定的用户标识，不用邮箱。
  • 每个请求都检查对象归属。 改一下 URL 里的 ID 就能看到别人数据的越权漏洞（BOLA/IDOR），至今仍是实际危害最常见的缺陷之一。授权规则用 OPA 或 Casbin 之类集中管理，不要分散在各个处理函数里。

怎样验证。 在 CI 里加测试：用用户 A 的 Token 请求用户 B 的资源，结果必须全部是 403 或 404。对测试环境跑一遍 OWASP ZAP，再按 OWASP ASVS 第 2 级中认证、会话、访问控制几章逐项人工核对。

第 2 层：抵御自动化攻击

对应这次事件的哪一步。 韩国监管机构不排除攻击使用了 AI，行业数据也显示漏洞被利用得越来越快。自动化工具会快速、不停地探测大量接口。

常规做法为什么不够。 只有一个全局限流，很容易绕到阈值以下；漏洞公开几天内就被利用的情况下，每月一次的补丁周期太慢了。

具体措施。

  • 按 IP、账号、Token 三个维度限流。 登录、找回密码和导出接口的阈值要比普通查询严格得多。
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s; limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m; location /api/ { limit_req zone=api burst=20 nodelay; } location /login { limit_req zone=login burst=3; }

只按 IP 限流挡不住分布式流量，所以还要在应用层或 API 网关上按账号、按 Token 限流。

  • 前面放一层 WAF。 Cloud Armor 或 AWS WAF 的托管规则，或者开源的 ModSecurity 加 OWASP Core Rule Set。针对扫描器典型的连续 404 和异常 User-Agent，加上基于速率的规则。
  • 定好补丁时限并且守住。 例如：列入 CISA KEV 或 CVSS 9.0 以上的漏洞 48 小时内修复，7.0 以上 7 天内修复。依赖更新交给 Renovate 自动提 PR，发现已知严重漏洞时由 osv-scanner 或 Trivy 让构建失败。
  • 来不及打补丁时，先减少暴露。 用 WAF 规则做虚拟补丁、暂时关闭受影响的功能，或者把组件放到 MFA 后面，先争取时间。
  • 把 API 设计得难以批量拉取。 限制分页大小（例如 100 条），不允许通配查询，导出改成需要审批、留有审计日志的异步任务。

怎样验证。 用 k6 对登录和查询接口做压测，确认超过阈值后返回 HTTP 429。记录每个严重 CVE 从公开到修复上线的时间，每月复盘一次。

第 3 层：让数据不容易被带走

对应这次事件的哪一步。 韩国被盗的不只是姓名和电话，还有收入和贷款明细。对方如果知道你真实的贷款申请内容，打来的诈骗电话就很难分辨。日本这边，有风险的数据在邮件发送系统及其日志里，这类系统一般没人会把它当成存放客户数据的地方。

常规做法为什么不够。 很多服务什么数据都永久保存，敏感字段明文存放，应用服务器可以连接互联网上的任何地址。攻击者一旦进来，数据往外走没有任何阻碍。

具体措施。

  • 少存数据。 给每个字段定好用途和保留期限，到期自动删除，邮件日志和发送队列也包括在内。这次受影响的服务商中，就有一家在设计上让存储的邮件数据 14 天后自动删除。
  • 在应用层加密敏感字段。 收入、证件号这类字段用信封加密：由 KMS 中的密钥加密按记录或按表生成的数据密钥。这样即使是数据库管理员，或者拿到数据库导出文件的人，看到的也只是密文。
  • 限制出站流量。 Cloud Run 的出站流量走 VPC，并在防火墙里只放行已知目的地；Kubernetes 从默认拒绝出站的 NetworkPolicy 开始；数据库服务器完全不允许主动向外连接。
  • 埋设诱饵。 在数据库里放几条假客户记录，一旦被读取就告警；用 Thinkst 开源的 Canarytokens 在代码仓库和环境变量里放几个假的云密钥，有人使用就会触发通知。对小团队来说，这是成本最低的入侵检测。

怎样验证。 在应用服务器上对任意外部地址执行 curl，应当失败。用测试账号读取一条诱饵记录，确认几分钟内收到告警。

第 4 层：以小时而不是以天来发现入侵

对应这次事件的哪一步。 韩国三家大银行发现被入侵花了 15 到 68 小时。对拿着自动化工具的攻击者来说，这段时间太长了。

常规做法为什么不够。 日志是有，但散落在各处；告警没有明确的负责人；现有的告警阈值又设得太松，久而久之没人再看。

具体措施。

  • 把该收的日志收到一处。 WAF、应用访问日志、认证事件、数据库审计日志（PostgreSQL 用 pgaudit）、云审计日志（GCP 的 Cloud Audit Logs、AWS 的 CloudTrail）。开源方案可以用 Wazuh 或 OpenSearch Security Analytics。
  • 防止被监控的人删日志。 云审计日志通过组织级 sink 写入另一个项目中锁定了保留期的 bucket，这样即使生产环境的管理员账号被攻破，也删不掉日志。
  • 从少量、对应真实攻击步骤的规则开始。 一开始有下面六条就够了：
告警触发条件示例对应的攻击阶段
异常管理员登录新国家或新 ASN、非工作时间绕过认证后的横向移动
连续失败后成功5 分钟内失败 20 次以上后登录成功撞库
批量读取单个账号 1 小时内读取超过 1,000 条客户记录数据收集
新增高权限授予 owner/admin 角色，或新建管理员账号持久化
出站流量突增出站流量超过基线 3 倍数据外传
破坏性操作批量删除快照、禁用 KMS 密钥勒索加密前的准备

阈值取决于你的流量。先设得严一点，再根据头两周实际触发的情况调整。

  • 定一个目标。 平均发现时间（MTTD）控制在 1 小时以内，每条告警都要有明确的负责人和写好的第一步处置。

怎样验证。 每季度在测试环境里跑几项 Atomic Red Team 的攻击技术，确认每一项都能触发告警。一条在测试中从没触发过的规则，不能指望它在真实攻击中起作用。

第 5 层：备份要比云服务商活得久

对应这次事件的哪一步。 这是 IDCF 事件最主要的教训。云服务商自己说四个可用区的数据预计回不来，只能用客户自己保存的备份恢复。把备份放在同一平台上的公司，备份也一起没了；备份放在另一家云的公司，大约一天就恢复了服务。

常规做法为什么不够。 同一账号、同一区域、同一管理员权限下的快照用起来方便，但它们并不独立。谁控制了平台或管理员账号，谁就同时控制了快照。

具体措施。

  • 遵循 3-2-1-1-0 原则。 3 份副本、2 种存储介质、1 份异地、1 份不可篡改或离线、恢复验证 0 错误。
  • 用另一家云、另一个账号。 生产在 GCP，备份就写到单独的 AWS 账号，反过来也一样。写入备份的凭证不能有删除权限，也不能属于管理生产环境的人。
  • 让备份不可篡改。 保留策略一旦锁定，在期限结束之前，连管理员也删不掉。
1# GCS：设置 30 天保留期并锁定（锁定后无法撤销） 2gcloud storage buckets create gs://example-backup \ 3 --location=asia-northeast1 --retention-period=30d 4gcloud storage buckets update gs://example-backup --lock-retention-period 5 6# S3：合规模式的 Object Lock，30 天 7aws s3api create-bucket --bucket example-backup \ 8 --object-lock-enabled-for-bucket \ 9 --create-bucket-configuration LocationConstraint=ap-northeast-1 10aws s3api put-object-lock-configuration --bucket example-backup \ 11 --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

锁定设置请先在一个用完即弃的 bucket 上试。锁定后的保留期不能缩短，到期前的存储费用都要照付。

  • 数据库持续备份。 PostgreSQL 可以用 WAL-G 或 pgBackRest 持续归档到另一家云，支持按时间点恢复。再每天做一次逻辑导出，作为第二份更简单的副本。
  • 不只要能恢复，还要能重建。 基础设施用 Terraform 管理；容器镜像按 digest 再推一份到第二个镜像仓库；Secret 加密导出后离线保存。DNS 放在独立的服务商，TTL 设短一些（例如 300 秒），需要时能快速切换流量。
  • 在别处准备一个状态页。 主站停了，也能通过另一台主机上的静态页面告诉客户发生了什么。

怎样验证。 每季度在另一家云上从零恢复一次。自动校验行数和校验和，记下实际花了多长时间（真实的 RTO）和丢了多少数据（真实的 RPO）。从没恢复过的备份只是一个假设，不是备份。

给自建 VMware 的团队补充一句：IDC Frontier 尚未公布攻击者的入侵途径，所以下面是针对虚拟化平台的一般建议，不是对这次事件的结论。把 vCenter 和 ESXi 的管理网络隔离开，启用 lockdown 模式，关闭主机上的 SSH，并在 vCenter 前面加上 MFA。

第 6 层：守住管理面和供应链

对应这次事件的哪一步。 一家云服务商出事，波及 495 家直接客户，以及构建在它们之上的大量服务，其中包括一家信用卡公司的会员邮件。在韩国，一个中介平台成了进入银行客户数据的入口。你的风险范围包括你的供应商，以及供应商的供应商。

常规做法为什么不够。 长期有效的访问密钥留在 CI 系统和笔记本电脑上；一个管理员角色既能删生产也能删备份；没有人手里有一份清单，写明哪些 SaaS 存着客户数据。

具体措施。

  • 去掉长期云密钥。 CI 通过 OIDC 获取短期凭证，例如从 GitHub Actions 连到 AWS 或 GCP。GCP 上启用组织策略 iam.disableServiceAccountKeyCreation。
  • 给破坏性操作加护栏。 在 AWS 上，可以用服务控制策略（SCP）禁止除 break-glass 角色之外的所有人删除 bucket、快照和 KMS 密钥：
1{ 2 "Version": "2012-10-17", 3 "Statement": [{ 4 "Sid": "DenyDestructiveExceptBreakGlass", 5 "Effect": "Deny", 6 "Action": ["s3:DeleteBucket", "ec2:DeleteSnapshot", "kms:ScheduleKeyDeletion"], 7 "Resource": "*", 8 "Condition": { 9 "ArnNotLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/BreakGlass" } 10 } 11 }] 12}

break-glass 账号的硬件密钥离线保管，这个角色只要被使用就发出告警。

  • 清楚自己在运行什么。 用 syft 生成 SBOM，用 cosign 给容器镜像签名，GitHub Actions 按 commit 哈希固定版本而不是用标签。第三方脚本加上 Subresource Integrity，用 Content Security Policy 限制脚本来源。
  • 准备供应商清单和供应商出事时的处置流程。 列出所有存有个人数据的 SaaS、与之连接的 API 密钥，以及你发给它们的数据，只传对方真正需要的部分。供应商一旦公布安全事件，先轮换密钥、暂停集成，再评估影响。这次 IDCF 事件中，监控服务 Mackerel 就是这么做的，作为预防措施暂停了与 IDCF 的连携。
  • 防止别人冒用你的名义发邮件。 数据泄露之后，最常见的二次攻击是冒充受害企业的钓鱼邮件。配置好 SPF 和 DKIM，再把 DMARC 推进到 p=reject：
_dmarc.example.jp. TXT "v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.jp"

一边看汇总报告，一边从 p=none 逐步改到 p=quarantine，再到 p=reject，就不会误拦自己的正常邮件。

怎样验证。 每月跑一次开源的云配置审计工具，例如 Prowler 或 ScoutSuite。用普通管理员角色尝试删除一个快照，确认操作被拒绝。

事件发生后的最初几小时

IDC Frontier 的第一步是把受影响的区域从网络中断开，并停掉管理控制台。这样限制了扩散，但客户也因此无法操作自己的服务器。这类取舍应该在事前想清楚，而不是事发时才决定。先准备一页纸的处置手册，写清下面几步就够了：

  1. 先定谁来拍板。 指定一个有权下令停机的人，以及他联系不上时的替补。在什么条件下停止服务，也要事先写下来。
  2. 隔离。 把受影响的系统从网络中断开，注销活跃会话，停用被攻破的账号。优先隔离，而不是删除。
  3. 重建之前先保全证据。 做磁盘快照，把日志导出到单独的日志账号，记录下每一步操作的时间。先重建的话，用来查找入侵途径的信息就没了。
  4. 按固定顺序轮换凭证。 先是云管理员账号和 CI 凭证，然后是数据库和 API 密钥，最后是应用的各类 Secret。被攻破的系统能读到的东西，一律当作已经泄露。
  5. 尽早、直白地告知相关方。 包括客户、供应商，以及按规定需要报告的监管机构。在日本，根据《个人信息保护法》，符合条件的泄露需要向个人信息保护委员会报告：速报要尽快提交（指南中大致是 3 到 5 天以内），确报在 30 天以内，因恶意行为导致的泄露为 60 天以内。请以委员会最新的指南为准，本文不构成法律意见。
  6. 用确认干净的备份恢复到干净的环境。 重新接入互联网之前，先把入侵途径堵上。

给经营者的一页摘要

如果你不是技术人员，可以拿下面十个问题去问自己的团队或外包商。

时间要问的问题
本周我们有没有一份清单，列出所有暴露在互联网上的系统，包括管理后台和合作方网站？
本周所有管理员账号是否都使用了防钓鱼的 MFA？
本周是否至少有一份备份存放在主云之外、连我们自己的管理员也删不掉的地方？
本周是否配置了 DMARC，防止别人以我们的名义发邮件？
一个月内是否清楚哪些供应商持有我们客户的数据，以及它们出事后必须多快通知我们？
一个月内不再需要的数据（包括邮件日志）是否会被删除？
一个月内如果有人大量导出客户数据，我们能否在一小时内发现？
一个月内是否在另一个环境里从备份恢复过？花了多长时间？
设计层面严重漏洞多快能修复？由谁跟踪？
设计层面发生事件时，谁有权、在什么条件下下令停止服务？

结语

这两起事件都不特殊：认证薄弱的侧门、和生产环境放在同一平台上的备份、来得太晚的告警。变的是这些弱点被发现和被利用的速度。应对的办法不是买一个新产品，而是把基本功做得更快，并且确认它们真的有效。

等 IDC Frontier 和韩国监管机构公布更多细节，尤其是攻击者的入侵途径之后，我会更新本文。

关于作者：蔡晓华（Tony Cai）是东京ソラナリンク株式会社（SolanaLink Co., Ltd.）的创始人兼代表董事，有 20 多年软件开发经验，主要方向是分布式系统，曾在上海担任技术负责人和 CTO。SolanaLink 从事云系统、Web 与移动服务以及 AI 代理集成的开发和运维。如果你希望有人帮你检查云架构或备份设计，可以通过 solanalink.jp 联系我们。

信源

均于 2026 年 10 月 10 日查阅。

韩国

日本

AI 与威胁态势

评论

评论 (0)

#Security#AI#Infrastructure
返回新闻与博客
从 2026 年 10 月日韩两起安全事件看 Web 服务加固：一份实践指南 — SolanaLink Blog