DigiCert 数据泄露事件解析：归档系统如何泄露身份证明文件，以及应对措施

这里并没有人强行破门而入。只是一个私密房间不知不觉间可以直接从街上访问，陌生人可以在前台自行登记，而权限上的漏洞让他们得以阅读存放在里面的旧文件。

今天是 2026 年 11 月 6 日，这件事在当下尤为重要，因为最知名的证书颁发机构之一 DigiCert 正在通知客户有关归档记录泄露的情况。这些记录包括业务联系人详细信息，在某些情况下还包括护照和驾照等身份证明文件。该公司自身后续工作的截止日期也是今天。

如果您是 DigiCert 的客户，有一份简短的切实可行的待办事项清单需要处理。如果您不是，这起事件仍然值得您关注，因为同样的模式几乎可能存在于任何公司：一个老旧的内部工具、一次网络变更，以及多年来无人核验的一整套假设。

本指南用通俗易懂的语言解释了发生了什么，区分了已知事实与未知情况，并深入分析了两个实操案例。在第一个案例中，一位名叫 Rohit 的安全主管负责处理客户方的应急响应。在第二个案例中，Rohit 对公司自身的一个归档系统进行了针对同类故障的测试。

开始之前的简短术语表

有些术语经常出现，因此在此用简朴的语言对它们进行说明。

• 证书颁发机构（Certificate authority）： 验证您的身份并颁发数字证书的机构，使网站和软件能够证明自身的身份。
• 身份核验（Identity verification）： 服务商在信任个人或公司之前执行的检查。这可能涉及提交文件证明。
• VPN： 一种私密、加密的连接。许多内部系统只能通过它访问。
• 多因素身份验证（Multifactor authentication，MFA）： 在密码之外还需要第二重证明（例如手机确认批准）的登录方式。
• 身份验证（Authentication）： 证明你是谁。
• 授权（Authorisation）： 在确认您的身份之后，决定允许您查看什么或执行什么操作。

请牢记最后两项。它们是这起事件的核心。

事件始末（按时间顺序）

DigiCert 的事件报告通过 Mozilla 的证书颁发机构公开合规追踪器发布。结合客户通知，整理出如下时间线：

日期	事件经过
2025 年 2 月 4 日	一次系统迁移导致原本受 VPN 限制的系统可从外部访问
2026 年 6 月	DigiCert 发现了未经授权的账户，最初认定它们无法访问客户信息
日期未说明	通过其托管安全研究计划收到的一份报告对外部账户创建提出了关切，随后进行了安全修复
2026 年 6 月 27 日至 7 月 2 日	后来确认的未经授权访问发生的时期
2026 年 10 月 19 日	进一步调查确认确实发生了针对客户记录的未经授权访问
2026 年 11 月 6 日	列出的外部暴露审计和最终账户警报审查的截止日期

请注意系统迁移与被发现之间的时间间隔。系统在 2025 年 2 月发生变更，而账户直到 2026 年 6 月才被发现。还要注意发现账户与确认它们读取了什么之间的时间间隔。这第二个时间差是整份报告中最有价值的教训之一。

三个小隐患如何演变成大问题

任何单一的故障都不能完全解释这一事件。而是三个条件同时重合。

第一，网络屏障消失了。 一个原本受 VPN 保护的系统在迁移过程中变得可从外部访问。人们通常把 VPN 视为确保内部工具安全的关键。一旦它消失，建立在它之上的一切假设都会暴露无遗。

第二，外部人员可以创建账户。 自助注册功能允许外部人员创建账户。这些账户并没有启用员工必须使用的 MFA。

第三，权限漏洞完成了最后一击。 这些新账户没有任何应用程序分配。换句话说，按理说它们本不该拥有任何权限。然而，一个授权漏洞仍然赋予了它们对归档记录的读取权限。

不妨想象一栋办公大楼。大楼原本位于一道上锁的大门之后（VPN）。一次装修拆掉了大门。前台会向任何索取的人发放访客工牌（自助注册）。这枚工牌本来不能打开任何一扇门，但某个储藏室的门锁却接受任何工牌（授权漏洞）。

每一部分单独看起来可能都不致命。但组合在一起，就导致了文件的泄露。

身份验证不等于授权

这是最核心的教训，其适用范围远超这起事件本身。

能够登录并不能证明什么。它仅仅告诉系统该账户存在且有人持有其凭证。对于该账户是否应该能够从归档中调取护照扫描件，它什么也说明不了。

知名应用程序安全项目 OWASP 在其授权指南中清晰地区分了这两项功能。身份验证确立身份。授权决定该身份可以访问哪些资源和执行哪些操作。OWASP 建议养成三个习惯：

• 默认拒绝访问。
• 实施最小权限原则，即每个账户仅获得其真正需要的权限。
• 对每次请求都检查权限。

应用到归档系统中，这些原则意味着一个全新的账户在获得明确且合理的权限授予之前，不应获取任何客户记录。没有角色或应用程序分配时应当直接拒绝，绝不应产生后备回退权限。

客观且准确地说，这是 OWASP 指南在架构层面的延伸推论，并非关于 DigiCert 如何构建其系统的额外调查结果。

为什么最初的调查漏掉了这一点

DigiCert 于 2026 年 6 月发现了这些账户，最初断定它们无法触及客户信息。后来的调查证明事实并非如此。

这种情况非常容易发生，也值得理解。管理员打开管理界面，看到一个未分配任何角色的账户，理所当然地得出它什么也做不了的结论。但是那个界面显示的只是标签。它并不能展示当该账户请求某些内容时应用程序实际会返回什么。一个看似未分配角色的账户，仍然可能访问到访问检查机制与中央账户管理界面不同的端点。

因此，遇到非预期的账户应当提出三个问题：

1. 它的实际有效权限是什么，即它究竟能做什么？
2. 它开启了哪些会话？
3. 它实际请求了哪些资源？

在同一事件链中还有第二个教训。关闭访问途径与查明在关闭之前发生了什么，是两项各自独立的任务。DigiCert 实施了修复，但这些修复并没有立即查明记录是否已经被访问过。直到 10 月 19 日的审查才确认在 6 月 27 日至 7 月 2 日之间确实发生过访问。

每当你修复了权限漏洞，切记要回溯检查。在修复之前，这个漏洞是否已经被利用过，包括被已经存在的账户或会话所利用？

泄露了哪些内容，以及为什么身份证明文件改变了一切

泄露的信息包括姓名、商务电子邮件地址、电话号码和公司地址。某些记录还包含提交用于身份核验的文件。

DigiCert 表示目前仍在审核身份证明文件以确定受影响的人员，并将在审核完成后通知这些当事人。

对当事人而言，影响程度大不相同。工作邮箱出现在记录中的人有一套担忧；而护照扫描件也遭到泄露的人则面临着截然不同的困境。更换一个电子邮件地址要比更改护照上印制的信息容易得多。

Brandefense 的评估指出了潜在的定向身份冒用风险，包括利用与证书提供商现有业务关系的信息发送伪造消息。建议查明是哪些代表提交了核验文件，并提醒他们警惕后续的可疑请求。

这里举一个看似合理的例子（仅为假设性设想）：一封邮件或信息声称您的机构必须重新进行身份核验，以免证书服务中断。这听起来可能很有说服力，因为它可能包含准确的姓名、联系方式以及对您的供应商信息的了解。

这些属于潜在风险和合理的预防措施，并不表明不法分子已经利用本次泄露事件进行了欺诈活动。

DigiCert 表示未受影响的部分

这部分内容至关重要，值得与坏消息给予同样的关注。

DigiCert 表示其证书颁发机构服务、CertCentral 和 DigiCert ONE 均未受影响。它表示客户的登录凭证和已颁发的证书仍然安全，客户无需因本次事件更换正在生效的证书。

该公司还表示，未经授权的账户无法修改记录、批准验证或颁发证书，其审查也没有发现任何相关的证书颁发、验证或吊销活动。

因此，客户目前的当务之急是关注泄露的信息及相关的涉事人员。根据该公司的声明，本次事件并不需要仓促更换证书。

思考这一问题有一个很有用的角度。数据泄露的影响包含不同维度：

• 机密性（Confidentiality） 关注信息是否遭到了泄露。
• 完整性（Integrity） 关注记录或流程是否遭到了篡改。

对写入访问的限制可以保护完整性，但仍可能导致敏感信息暴露。只读访问听起来可能无害，但 OWASP 将未经授权的读取列为失效的访问控制（broken access control）的潜在后果之一，其严重性取决于资源的敏感程度。当读取权限触及个人记录时，“只读”根本算不上任何安慰。

DigiCert 做出了哪些变更

事件报告列出了以下整改措施：

• 禁用自助注册。
• 采用专用端点（Private endpoints）。
• 为业务系统用户重置密码。
• 增加额外的监控。
• 开展权限审查。

外部暴露审计和最终账户警报审查被列为正在进行中，截止日期为 2026 年 11 月 6 日。

更深层次的架构要点与 NIST 的零信任架构（Zero Trust Architecture）指南不谋而合。NIST 指出，系统或账户不应仅凭其网络位置或归属权就获得隐式信任。保护工作应当以资源和明确的访问决策为中心。

这给每个机构都带来了一个简单却略显刺痛的测试：

如果防火墙规则、路由变更或系统迁移出乎意料地使该应用程序变为可达状态，它是否仍然会拒绝未经授权的请求？

网络限制仍然有用，只是它们不应该成为唯一把门关紧的手段。

我们目前仍未知晓的信息

客观诚实的报道意味着也应当列出信息缺口。

• 公开披露的信息中没有给出受影响的个人、机构或身份证明文件的总数。
• Cybersixt 的独立报道指出，该账户的操作者尚未被公开确认。
• 在缺乏这些具体数字的情况下，像“归档数据的一小部分”这样的描述，无法告诉我们究竟有多少人需要支持，也无法说明每个人信息泄露的敏感程度。

对任何声称事件规模的新闻标题都要保持谨慎。目前该数字尚未公开。

实操案例 1：Rohit 在客户方的应急响应

现在让我们来看一家虚构的公司。Acme 是一家从中介/服务商处采购证书的中型企业。其安全主管 Rohit 在一个周五早晨收到了这一消息。下文所述均为情景设想，包括所有名称和地址。

步骤 1：不要先从证书入手

Rohit 的第一反应是检查证书，但服务商的声明表示正在生效的证书无需更换。仓促更换证书会增加风险和工作量，却无法解决真正的担忧。Rohit 写下了当天的核心问题：我们公司有哪些人员的信息被泄露了？

步骤 2：建立人员名单

Rohit 询问证书管理团队有谁曾代表 Acme 与该服务商打过交道。已离职的员工也算在内，因为归档系统中仍记录着很久以前离职的人员。

该名单很简单，针对每个人回答了三个问题：

Name         Role              Gave contact details   Gave identity document
A. Sample    Network engineer  yes                    unknown
B. Sample    Finance manager   yes                    yes (from old emails)
C. Sample    Former employee   yes                    unknown

“unknown”（未知）这个词既坦诚又实用。它构成了下一组要解决的问题。

步骤 3：向供应商提出精准具体的问题

含糊不清的邮件只能得到含糊的答复。Rohit 通过既定的大客户联络人发送了以下问题：

1. 涉及我们的哪些人员以及哪些文件？
2. 有什么证据能够证实它们曾被访问过？
3. 你们预计还会发送进一步的个人通知吗？

随后 Rohit 记录下每个答复及其日期，以便团队日后能够明确在何时获知了哪些信息。

步骤 4：引入隐私合规与人力资源部门

关于证书的技术保证不应掩盖员工的需求。Rohit 召集了证书团队以及安全与隐私合规部门的同事。对于名单上的人来说，这个问题关乎切身利益：“我的护照在里面吗？”一旦有了结果，他们理应得到直接的答复；而在此之前，也应明确告知“我们目前尚不知情”。

步骤 5：在攻击者找上门之前提醒相关人员

Rohit 给名单上的每个人发送了一份简要通知：

You may be contacted about our certificate provider.
Do not upload identity documents, click links or confirm details
because of a message, even one that uses accurate names.
Report it to [email protected]. We will verify it through a
known contact.

这是整个应急响应过程中最关键的以人为本的步骤。任何要求上传替换身份证明文件的指示，都应通过已知的联络人或经过身份验证的服务进行独立核实。

步骤 6：执行常规安全清理，并进行准确标记

Rohit 在服务商的门户网站上审查了账户的用户和 API keys，移除了前员工的访问权限。这是常规的安全清理措施。不应将其描述为应对凭证泄露的举措，因为服务商表示这些凭证依然安全。准确的措辞能防止公司内部产生谣言。

步骤 7：保持事件处于开启状态

服务商仍在审核身份证明文件，因此该事件保持开启状态。Rohit 安排了每周一次的核查，只有当供应商的通知发送完毕且名单上的每个人都收到答复时，才会将其结案。

实战示例 2：Rohit 测试 Acme 自己的归档系统

接下来是一个更有价值的问题：这种情况会发生在我们身上吗？Rohit 选择了一个旧的内部工具， archive.example.com，该工具存放着扫描后的供应商合同。员工通过 VPN 访问它。大家都以为它是安全的。请仅在您拥有所有权或获得测试许可的系统上运行此类测试。

步骤 1：列出保存的内容及其原因

在进行任何测试之前，Rohit 针对这些文件回答了四个问题：

• 为什么要收集它们？
• 副本保存在哪里？
• 谁可以检索获取它们？
• 如何监控访问情况？

第一个问题通常能带来最快的突破。如果没人能解释为什么还要保留某份扫描文件，这就值得向隐私合规团队提出。

步骤 2：找出创建账户的所有途径

Rohit 寻找注册页面、邀请链接和单点登录设置。在老旧软件中，自主注册功能可能会被遗忘多年。Rohit 还确认了相同的 MFA 规则是否适用于所有账户，包括非员工创建的账户。

步骤 3：假定网络屏障已经失效

在经过批准的测试环境中，Rohit 从一条绕过 VPN 路径的测试网络直接尝试访问该应用程序。随后，Rohit 使用一个完全没有分配角色的新账户请求了一条记录：

curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Authorization: Bearer REPLACE_WITH_TEST_TOKEN" \
  https://archive.example.com/api/documents/1001

Rohit 希望得到的答复是 401 或 403，意味着请求已被拒绝。而 200 则意味着该账户获取到了文件，即使该账户在管理界面上显示为“无权限”，这也是一个安全发现项。

步骤 4：测试每一扇门，而不仅仅是正门

不同页面之间的权限检查可能存在差异，因此 Rohit 在搜索、导出、下载以及 API 端点上重复了该请求。Web 界面可能会隐藏某个按钮，但背后的服务器却仍会作出响应。测试必须始终向服务器发起请求。

步骤 5：默认实施拒绝

Rohit 要求开发人员确认逻辑结构符合这种形式。这只是默认拒绝（deny-by-default）的一个简单示意，并非任何实际产品的代码：

def can_read(user, document):
    if user is None:
        return False
    # No explicit grant means no access. There is no fallback.
    return document.id in user.explicit_grants

关键在于缺少了什么。代码中不存在“otherwise allow”分支，未分配任何权限的账户最终获取不到任何记录。

步骤 6：关注关键告警信号

Rohit 为新创建的外部账户以及在创建后不久便读取大量文件的任何账户添加了告警。只有当有人跟进核查该账户实际执行了哪些操作时，针对新账户的告警才真正有用。

步骤 7：将系统迁移加入检查清单

最后，Rohit 调整了迁移审查机制。以前审查时会问：“迁移后系统能正常工作吗？”现在它还会问：“有哪些以前无法访问的内容现在可以访问了，这些服务的表现又是怎样的？”关于谁能够访问某个系统的假设往往比作为其基础的基础设施存在得更久，而在较旧的业务工具中最容易出现这种情况。

给安全负责人的更广泛启示

归档系统往往显得枯燥无味，因此受到的关注往往不如线上运行系统。但其中的数据通常更陈旧、审核更少，却同样敏感。归档系统运行可见性的降低，绝不应削弱对其所含信息的防护力度。

审视一份验证文件的整个生命周期，从收集直至删除。明确为什么要收集它、副本保存在何处、谁可以检索它以及如何监控访问。在系统迁移迫使你面对这些问题之前，就先提出并解决它们。

结论

DigiCert 事件并非关于证书被伪造的故事。根据该公司的说明，证书业务运营始终保持安全。这是一个关于系统变得对外可达、本不应看到任何内容的账户、以及触及敏感记录的读取权限的故事。如果您是客户，请查明哪些人员受到影响并提醒他们，并通过已知渠道核实每一个意料之外的请求。如果您是其他人，请在假定网络屏障已经失效的前提下测试您的归档系统，因为有朝一日的系统迁移可能会让这种情况成为现实。

优势

• 客户拥有清晰、实用的应对步骤，无需更换有效证书。
• 公开的事件报告为每个团队提供了一个可供借鉴的真实案例。
• 此处介绍的测试成本低廉，且适用于任何旧的内部工具。
• 审查存储的文件可以通过清除不再需要的数据来降低未来的风险。
• 将授权视为独立的控制措施，即使在网络配置发生变化时也能保护系统安全。

劣势

• 在文件审查仍在继续期间，受影响的人员可能需要等待答复。
• 缺乏公开的具体数字，因此目前尚无法评估真实的影响规模。
• 审查陈旧的归档需要耗费时间，而且较旧的工具往往缺乏完善的文档。
• 针对每个端点进行权限测试需要专业技能以及经过批准的测试环境。
• 在事实尚未查清时提醒员工可能会引发担忧焦虑。

注意事项

本文仅供教育参考，基于撰写本文时公开的报道，因此随着调查的深入，具体细节可能会有所变化。Acme、Rohit、示例员工、地址、token 以及代码均为虚构占位符，必须替换为您自己的实际值。请仅测试您拥有所有权或获得授权测试的系统，并在采信相关说法之前，对照 DigiCert 自身的公告以及您的法律或隐私顾问的意见进行核实。

常见问题解答

• DigiCert 数据泄露事件中发生了什么？ — 2025 年 2 月 4 日的一次系统迁移导致一个受 VPN 限制的系统暴露于外部网络，外部人员可以自行注册账户，而一处授权缺陷使这些账户获得了对归档记录的读取权限。
• 泄露了哪些数据？ — 姓名、商务电子邮件地址、电话号码和商业地址，以及部分记录中的身份证明文件，例如护照和驾驶执照。
• 我需要更换我的 DigiCert 证书吗？ — DigiCert 表示，客户无需因该事件更换有效证书，已签发的证书和登录凭证依然安全。
• CertCentral 和 DigiCert ONE 是否受到影响？ — DigiCert 表示其证书颁发机构服务、CertCentral 和 DigiCert ONE 均未受影响，其审查未发现任何相关的签发、验证或吊销活动。
• 有多少人受到影响？ — 公开披露中未给出涉及人员、组织或身份证明文件的总数，DigiCert 表示目前仍在审核身份证明文件。
• 受影响的客户现在应该做什么？ — 确定是谁提供了信息，检查是否提交了身份证明文件，并通过既定渠道核实意料之外的消息。
• 身份认证与授权之间有什么区别？ — 身份认证证明你是谁，而授权则决定你可以访问什么，因此仅凭成功登录绝不能解锁敏感记录。
• 我该如何针对这个问题测试自己的归档系统？ — 在获得授权的测试中，创建一个没有任何角色的账户，并直接从每个端点请求记录；任何非拒绝的响应都构成一个安全发现项。

标签

#DigiCert #DataBreach #IdentityDocuments #AccessControl #Authorisation #IncidentResponse #ZeroTrust #OWASP #PrivacyRisk #CyberSecurity