安全事件响应计划
QR Branding API — GDPR 第 33–34 条
| 项目 | 内容 |
|---|---|
| 数据控制者 | QR Branding (Quartzon) |
| 日期 | 2026-03-08 |
| 版本 | 1.0 |
| 下次审查 | 2026-09-08 |
1. 目标
建立一套结构化的程序，用于检测、应对和通知影响个人数据的安全违规事件，以符合 GDPR 第 33 条（向监管机构通知）和第 34 条（向数据主体告知）的要求。
2. 定义
| 术语 | 定义 |
|---|---|
| 个人数据泄露 | 导致个人数据意外或非法地被破坏、丢失、篡改，或未经授权被披露的安全违规（GDPR 第 4 条第 12 款） |
| 安全事件 | 任何损害系统保密性、完整性或可用性的事件，无论是否涉及个人数据 |
| 零时刻（T0） | 检测到或获知事件的时刻 |
3. 事件分级
1 级：严重（个人数据泄露）
- 包含个人数据（vCard、电子邮箱、电话号码）的二维码内容外泄
- 用户的 AI 提示词外泄
- API 密钥（RapidAPI、LLM 提供商）泄露
- 未经授权访问含用户数据的 Application Insights
- 供应链被攻破（恶意 NuGet 依赖）
2 级：高（未确认涉及个人数据的安全事件）
- 漏洞被成功利用（SSRF、注入等）
- 持续性拒绝服务
- CI/CD 流水线（GitHub Actions）被攻破
- 未经授权访问 Azure App Settings 或机密信息
- LLM 提供商行为异常（响应中包含其他用户的数据）
3 级：中（已遏制的事件）
- 速率限制检测并拦截的攻击尝试
- 检测到漏洞扫描
- 依赖项存在已公开的 CVE（未确认被利用）
- 资源滥用导致的服务降级
4 级：低（信息性事件）
- 认证失败尝试
- 正常触发速率限制
- 性能告警（冷启动、超时）
4. 响应程序
阶段 1：检测与分诊（T0 → T0+1h）
| 步骤 | 操作 | 负责人 |
|---|---|---|
| 1.1 | 确定告警来源（Application Insights、GitHub Security Advisories、用户报告、监控） | 技术团队 |
| 1.2 | 按级别对事件进行分级（第 3 节） | 技术团队 |
| 1.3 | 记录检测到了什么、何时、如何检测到，以及估计的影响范围 | 技术团队 |
| 1.4 | 如为 1 级或 2 级：立即上报数据保护负责人 | 技术团队 |
阶段 2：遏制（T0+1h → T0+4h）
| 步骤 | 操作 |
|---|---|
| 2.1 | 根据事件类型进行即时遏制： |
| - API 密钥泄露 → 立即在 Azure App Settings 和提供商处轮换密钥 | |
| - 漏洞被利用 → 部署热修复或禁用受影响的端点 | |
| - SSRF/注入 → 在验证环节拦截攻击模式 | |
| - CI/CD 被攻破 → 吊销 GitHub 令牌，审计近期提交 | |
| 2.2 | 保全证据（Application Insights 日志、配置快照） |
| 2.3 | 确认遏制措施有效 |
| 2.4 | 评估个人数据是否受到影响 → 判断是否构成 GDPR 意义上的泄露 |
阶段 3：GDPR 通知（如适用）
第 33 条：向监管机构通知（T0 起 72 小时内）
仅当泄露对个人的权利和自由构成风险时才需要通知。
通知内容：
- 泄露的性质（涉及哪些数据、受影响数据主体的估计人数）
- 数据控制者的联系方式
- 泄露可能造成的后果
- 已采取或拟采取的应对措施
无需通知的情形：
- 不涉及数据外泄的可用性事件（DoS）
- 已成功拦截的攻击尝试
- 只影响非个人数据（配置、代码）的事件
QR Branding 的情况： 由于本服务是无状态的且不存储个人数据，大多数事件不构成个人数据泄露。可能的例外包括：
- 包含请求元数据的 Application Insights 日志外泄
- 传输中的流量被截获（使用 TLS，可能性较低）
- LLM 提供商行为异常，导致其他用户的提示词外泄
第 34 条：向数据主体告知
仅当泄露对权利和自由构成高风险时才需要。
以下情况无需告知：
- 数据已加密或匿名化
- 已采取措施确保风险不再可能发生
- 需要付出不成比例的努力（此时改为公开告知）
阶段 4：根除与恢复（T0+4h → T0+48h）
| 步骤 | 操作 |
|---|---|
| 4.1 | 找出并消除根本原因 |
| 4.2 | 应用永久性补丁或修复 |
| 4.3 | 运行回归测试 |
| 4.4 | 通过 CI/CD（GitHub Actions → Azure）部署到生产环境 |
| 4.5 | 确认修复在生产环境中有效 |
| 4.6 | 修复后 48–72 小时内密切监控 |
阶段 5：事后处理（T0+48h → T0+2 周）
| 步骤 | 操作 |
|---|---|
| 5.1 | 完整记录事件（时间线、影响、响应） |
| 5.2 | 进行根本原因分析（RCA） |
| 5.3 | 确定预防性改进措施 |
| 5.4 | 如果事件揭示了此前未考虑的风险，更新 DPIA |
| 5.5 | 如果发现程序中存在漏洞，更新本计划 |
| 5.6 | 分享经验教训（不含敏感数据） |
5. 事件登记（第 33 条第 5 款）
无论是否需要向监管机构通知，所有事件都必须登记。登记内容必须包括：
| 字段 | 说明 |
|---|---|
| 事件 ID | 唯一标识符（INC-YYYY-NNN） |
| 检测日期/时间 | T0 |
| 遏制日期/时间 | 阶段 2 结束时 |
| 分级 | 1–4 级 |
| 描述 | 发生了什么 |
| 受影响的数据 | 涉及的个人数据类别（如适用） |
| 受影响的数据主体 | 估计人数 |
| 根本原因 | RCA 结果 |
| 已采取的措施 | 遏制和补救行动 |
| 向监管机构通知 | 是/否、日期、编号 |
| 向数据主体告知 | 是/否、日期、渠道 |
| 处理结果 | 最终状态和结案日期 |
6. 主要联系人
| 角色 | 联系方式 |
|---|---|
| 技术负责人 | QR Branding 团队 |
| 隐私/DPO | support@qr-branding.com |
| RapidAPI Platform | RapidAPI 支持 |
| Microsoft Azure Support | Azure 门户 |
监管机构（参考）
| 国家/地区 | 机构 | 网站 |
|---|---|---|
| 西班牙 | AEPD | aepd.es |
| 欧盟（通用） | EDPB | edpb.europa.eu |
7. 演练
每年至少进行一次事件响应演练，以便：
- 验证程序是否有效
- 测量响应时间
- 发现能力或沟通方面的不足
- 让团队熟悉流程
本文件生成于 2026-03-08。下次计划审查：2026-09-08。