云
该标签下有 14 篇文章
三得利集团个人信息泄露（员工及合作企业员工约90,000人及其他类别）：外部云服务遭未经授权访问，姓名、电子邮件地址等外泄，应聘者和顾客应如何应对
三得利集团于2026年11月2日宣布，确认集团使用的外部云服务遭第三方未经授权访问，第三方下载的部分文件中含有个人信息。公司于10月28日检测到异常并阻断访问，10月29日确认其中含有个人信息。截至11月1日确认泄露的个人信息分为7类：集团员工及合作企业员工约90,000人的姓名和电子邮件地址；企业活动体验项目 Mar de Shine 截至2023年底登记的7,323人的电子邮件地址；三得利控股2026年应届生招聘商务部门公开选拔的7,173名应聘者的应聘者 My Page 登记信息等（姓名、电子邮件地址、电话号码等）；Suntory Beverage Solution 两部公司手机中登记的1,097人的姓名和电话号码；Monte Bussan 员工及合作企业员工324人的姓名、电子邮件地址和电话号码；Izutsu Maisen 外送订购顾客及配送员工96人的姓名和送达地点信息；三得利业务往来企业员工25人的姓名和职务。不含信用卡等支付信息。截至公告时未确认有不正当使用。公司表示正在逐一联系相关人员。本站结论：对于冒充三得利或集团公司、涉及选拔、录用、配送或业务往来的消息，不要打开链接，请通过自己打开的官方网站或公告页面上的窗口确认。
Trigger.dev 安全事件（2026年11月）：0.66% 客户的根 API 密钥和环境变量被访问，请重新生成密钥并轮换凭据
运行后台任务和 AI 智能体的平台 Trigger.dev 于2026年11月1日披露了一起安全事件，并在11月6日发布了后续报告。公司称，基础设施告警在11月1日标记出异常活动，公司判断其为恶意行为并阻断了攻击者。此次事件影响了全部客户的 0.66%。攻击者获取了部分客户环境的根 API 密钥；根密钥可完全访问环境的设置，包括其环境变量。在部分环境中，攻击者还列出了最近的运行、部署和定时任务，返回的内容包括 ID、任务名称、运行幂等键、运行状态、标签、部署元数据和错误、定时任务的外部 ID 以及运行元数据。公司称，没有发现其他客户数据、其他服务、公司自身的生产数据库或客户控制台账户被访问的证据。为保护调查和客户，公司不披露攻击途径。受影响的客户已通过邮件（11月1日和2日）和控制台横幅（时间未说明）收到通知，可能受影响的 API 密钥已被吊销。受影响的客户应重新生成 API 密钥，并轮换受影响环境中的凭据（如数据库密码和第三方 API 密钥），同时在签发服务处吊销旧凭据。公司称，没有收到影响通知的客户未受影响，Webhook 签名密钥未暴露，自托管部署未受影响。本站的看法：先查看邮件和控制台横幅；如果受影响，再按公司的指示重新生成密钥并轮换凭据。
Chainstack（区块链节点与 API 平台）生产环境遭入侵：开发者和 dApp 运营者应如何处理账户数据与节点凭据
Chainstack 在11月3日的通知中称，外部攻击者通过一个第三方组件进入了其部分基础设施：10月26日进入开发环境，10月29日进入部分生产环境，10月31日被发现并切断，调查于11月2日结束。客户账户数据库中可能暴露的信息有组织名称、账户持有人姓名、组织成员的邮箱地址和密码哈希。存放节点凭据的系统也曾被访问；公司没有证据表明凭据被读取，但将其视为已暴露。公司称其不存储支付方式详情，节点、控制台和 API 未被修改，服务持续运行。通知未给出客户数量。本站的结论：用户应更改密码，轮换节点凭据和平台 API 密钥，并替换嵌入在应用、CI 和前端中的端点。
PingCAP（TiDB Cloud）未经授权访问与数据泄露（日本最多约50,000条记录）：TiDB Cloud组织管理员应如何处理账户数据、SQL编辑器历史记录和支持工单
PingCAP表示，2026年9月9日至10月7日（美国时间）期间，未经授权的一方利用被盗凭据进入内部系统并复制数据，日本境内最多约50,000条个人记录被认定已泄露（日文公告）。公司已确认受影响的类别（因客户而异）包括：TiDB Cloud账户数据（用户名、电子邮件地址、组织和项目关联、SQL编辑器执行历史记录及错误，以及咨询信息，即支持工单）、业务和账单信息（姓名、电子邮件、公司名称、电话号码、订单、付款条款、账单设置），以及TiDB Cloud API密钥中经加密的Public Key部分。公司表示，尚未确认信用卡泄露或TiDB Cloud本身遭到未经授权的访问，且Private Key未暴露。该数字所统计的单位（人数还是记录数）并未说明。公司的英文公告还称源代码被获取。本站的结论：TiDB Cloud组织管理员应轮换API密钥，检查访问日志、成员和角色，并更改任何可能曾粘贴到SQL编辑器或支持工单中的凭据。
求职网站MyBRANDS遭未经授权访问，个人信息可能泄露（最多约13.5万个账户）：姓名、联系方式和工作经历可能外泄的求职者和企业联系人应采取的措施
iDA Co., Ltd.（日本）于2026年10月30日宣布，其求职网站MyBRANDS的服务器环境遭第三方未经授权访问，已注册的求职者和企业联系人的信息可能已泄露到外部。公司称，承包商使用的云访问密钥于10月21日至22日被第三方滥用，并于10月26日得知数据库副本存在向外部发送数据的记录。由于无法确认所发送数据的内容，公司按其持有的全部信息均在范围内的前提发出通知。截至10月30日，范围最多约13.5万个账户，包括已退出服务的人员。信息包括姓名、电子邮件地址、电话号码、个人资料（如工作经历）和登录密码（以转换后的值保存），具体因注册情况而异。公司未持有信用卡和银行账户信息，因此不包含在内。姓名、电子邮件地址、电话号码和地址是加密保存的，但公司称解密用的密钥也可能已被窃取。截至目前尚未确认有滥用（二次损害）。本站的结论：如果其他服务与MyBRANDS共用密码，请更改这些服务的密码（企业联系人还包括内部系统）；对自称招聘人员或猎头的消息，请通过官方渠道核实，而不要使用其中的链接或号码。
Northflank安全事件（2026年10月）：存储的环境变量应视为已被解密，有用户报告AI API密钥遭滥用
2026年10月30日（UTC），云部署平台Northflank在其状态页面发布了一起安全事件。11:43 UTC收到一家安全厂商的威胁告警；公司自12:02 UTC起部署补丁，13:40 UTC通知客户轮换环境变量，13:58 UTC通知客户假定所有环境变量均已被解密。到15:12 UTC，其状态页面已注明多名用户报告其AI密钥被使用，23:38 UTC又表示有用户报告平台上存储的AI API密钥遭未经授权使用。10月31日，公司为所有客户启用了审计日志，并逐个类型发布了附加组件的密钥轮换。11月2日的更新（11:09 UTC，状态为Monitoring）中，公司表示认为已在首次告警后一小时内遏制了攻击，正在运行的工作负载未受影响，也没有迹象表明工作负载或其数据被访问，攻击似乎集中在控制平面中的密钥上。独立的取证审计人员正在审查；公司吊销了访问令牌、会话、VCS集成和跨账户IAM角色（因此用户需要重新登录并重新连接集成），并承诺在调查结果确认后发布根因分析。在11月6日（10:09 UTC）的更新中，公司称已知最早的密钥解密发生在10月30日02:39至03:08 UTC，早于11:43 UTC的首次告警；漏洞在收到通知后60分钟内修补，并在两小时内通知了客户；没有发现客户工作负载或其数据被访问的证据；并已与上游服务商合作，尽可能吊销凭据。取证审查仍在进行。受影响客户的数量、攻击者如何进入以及涉及哪些AI服务商，均未披露。本站的结论是：在签发机构处吊销您存储在Northflank上的每一个密钥，然后查看每家AI服务商的用量和账单，并设置支出上限。
Zeabur 安全事件（2026 年 10 月，322 万条环境变量被读取）：哪些密钥需要轮换，用户该怎么做
2026 年 10 月 19 日，应用部署平台 Zeabur 发布了关于 10 月 14–15 日（UTC）安全事件的初步报告。公司表示，攻击者利用泄露的 Zeabur 内部凭据进入其共享集群、部分专用服务器（Dedicated Server）和内部系统，并最终在 10 月 15 日 16:10 至 16:47（UTC）之间读取了平台数据库。公司确认，3,218,965 条环境变量记录（名称和值）、321,810 个账户的数据（电子邮件、用户名、电话号码等）以及 566 个 zSend API 密钥被读取，这些 API 密钥已被吊销。公司表示，根本原因在 Zeabur 一方：长期有效的管理员凭据以明文保存，并且可以从公共互联网使用。公司要求所有用户更换存放在 Zeabur 上的所有密码和密钥，即使已在 8 月的另一起事件后更换过。Zeabur 已于 10 月 17 日宣布将于 2026 年 12 月 31 日停止服务，并于 10 月 22 日将此次事件损失索赔的截止日期定为 2026 年 11 月 30 日。本站观点：请把您曾放入 Zeabur 环境变量的每一个密钥都视为已被他人掌握，先在签发方服务处吊销，并检查 10 月 14 日以来的账单和日志。
日经（Nikkei）未经授权访问（约183万条记录）：约15万条记录中的姓名、电子邮件地址等信息外泄——用户该怎么做
2026年10月16日，日本报业出版公司 Nikkei Inc. 宣布，其用于系统开发的云服务遭到未经授权访问，截至16日，约183万条个人信息记录外泄。其中约15万条至少包含姓名、电子邮件地址、邮寄地址、电话号码或出生日期之一，这些记录中约12万条含有电子邮件地址。其余约168万条仅为无法单独识别个人的标识符。信用卡信息未包含在内。据该公司称，访问该云服务的凭据以某种方式被盗，未经授权的访问发生在10月7日凌晨至上午。公司已停用被使用的凭据，并于10月11日向日本个人信息保护委员会报告了此事。截至16日，未确认数据被滥用等二次损害，也未确认系统中断或数据篡改。公司表示，将对确认个人数据外泄的人员逐一通知。集团公司 Nikkei National Geographic 于10月22日表示，其部分服务用户的信息也包含在内。哪些服务的用户受影响、各数据项的数量，以及凭据如何被盗，均未公布。本站观点：对于自称来自 Nikkei 的邮件或电话，不要使用其中的链接或电话号码，请到官方网站确认。
Railway 环境变量可能已暴露（2026年10月，最多占全部工作区 1.85% 的工作区）：哪些密钥需要轮换，用户该怎么做
2026 年 10 月 21 日（UTC），Railway 宣布检测到存储客户环境变量的系统出现异常活动，未经授权的第三方可能访问了加密的环境变量，并对其中一部分获取了解密后的内容。根据 10 月 22 日的初步报告（按状态页面，于 10 月 23 日 16:38 UTC 公开），攻击从 10 月 20 日 13:58 UTC 持续到 10 月 22 日 03:32 UTC。攻击始于对构建基础设施的权限提升尝试；10 月 21 日，攻击者使用了 CI 环境的凭据，并解密了一部分加密环境变量。据该公司称，最多占全部工作区 1.85% 的工作区（约 100,000 个工作区）的部分环境变量可能已被泄露。公司表示没有 Railway 用户账户被访问，在最终报告发布前尚未排除源代码被访问的可能。攻击者似乎在寻找 AI 服务商的 API 密钥。Railway 建议所有用户轮换 10 月 21 日之前存储的密钥，移除数据库的公网访问，并检查 GitHub 及镜像仓库（如 Docker Hub）的审计日志。本站的结论：即使没有收到通知，也应将存放在 Railway 上的密钥视为已暴露，在来源处重新签发，并先重新部署，再吊销旧值。
什么是影子 AI？公司看不见的 AI 使用有哪些风险，组织和个人该怎么做
影子 AI 是员工把公司未批准或未管理的 AI 工具（聊天机器人、AI 浏览器扩展、编程助手、会议记录 AI、连接到工作账号的 AI 代理）用于工作，是影子 IT 的 AI 版。主要风险：输入的机密或个人信息可能被提供方保存，并视方案和设置被用于训练（个人版与企业版条款不同）；OAuth 授权和 API 密钥让第三方工具能访问邮箱和云盘；输出错误与授权许可问题；以及个人信息保护法规和审计方面的义务。只靠禁止会把使用赶到看不见的地方，因此要提供不把输入用于训练的企业版批准工具、一份简短的『哪些数据可以输入』规则、SSO 与管理控制、定期复查 OAuth 授权和扩展，以及可以先问一声的渠道。
Vercel 安全事件（2026年4月）：环境变量外泄后，开发者该做什么
2026年4月19日，Vercel 公开了部分内部系统遭到未经授权访问的事件。据 Vercel 称，一名员工使用的第三方 AI 工具被入侵，攻击者借此接管了该员工的 Google Workspace 账户，进入其 Vercel 账户和一个 Vercel 环境，枚举并解密了一小部分客户未标记为敏感的环境变量。Vercel 已直接联系受影响的客户，并确认其发布的 npm 包没有被入侵。本站的看法：一个变量是否泄露，取决于它的类别：可读（保存后还能再次显示其值）还是只写（可以覆盖，但永远不会显示）。凡是你不需要再读回的密钥，都存为只写（即现在 Vercel 中的 Secret）；员工通过 OAuth（让外部应用访问公司账户的机制）连接到公司账户的 AI 工具，要像依赖一样进行盘点。
子域名接管（悬空 DNS）：残留的 DNS 记录如何让攻击者使用你的域名
删除云资源却没删 DNS 记录，就会留下悬空记录：任何人只要用相同的 FQDN 创建资源，就能认领那个子域名。你的服务器毫发无损，正规的子域名却在提供攻击者的内容。损害不只是表面上的——应用常常把会话 Cookie 开放给通配子域名，被接管的子域名就能读取它们。而且文档明确否定了“有证书就安全”的想法。解决办法是把删除顺序写进流程和工具，而不是依赖记忆。
什么是 SSRF（服务器端请求伪造）
SSRF 是利用外部输入的 URL，让服务器去访问内部资源（内部 IP 或云元数据）的攻击。只要做了去获取 URL 的功能，就必须有目标 allowlist、内部网络阻断，以及防范重定向 / DNS 重新解析的绕过。它也是 Capital One 事故的原因。
Capital One 数据泄露事件（2019）— SSRF 如何导致 1 亿人信息外泄及防御之道
起点只是一个 SSRF。攻击由此连锁：元数据服务端点 → 权限过大的 IAM 临时密钥 → S3 整体复制，最终约 1 亿 600 万人信息外泄。每一步本可被拦下。在你的环境中，用 IMDSv2、IAM 最小权限和出站目标白名单来杜绝重演。