基本安全要求（Annex I 第I部分）
概述
CRA Annex I 第I部分定义了每个含数字元素产品必须满足的13项基本网络安全要求。本页面为每项要求提供详细的实施指南。
法律依据
Annex I 第I部分 CRA： 基本网络安全要求。含数字元素产品的设计、开发和生产应确保其具备适当的网络安全水平，并考虑相关风险。
第1项 — 适当的网络安全水平
要求： 产品的设计、开发和生产应确保其基于风险实现适当的网络安全水平。
BAUER GROUP 的实施方式：
- 安全设计 (Security by Design)：从设计阶段开始制定安全要求
- 每个架构决策前进行威胁建模 (Threat Modeling)
- 每个产品的风险评估（模板）
- 多层安全（纵深防御, Defense in Depth）
证据： 风险评估、安全架构文档、测试结果
第2项 — 无已知可利用漏洞
要求： 产品交付时不得存在已知可利用漏洞。
BAUER GROUP 的实施方式：
- 自动化 CVE 监控（每日）
- 多引擎安全扫描（Trivy、Grype、Snyk）
- Dependabot 自动依赖项更新
- 发布前安全门禁：存在已知 Critical/High CVE 时不发布
证据： CVE 扫描报告、依赖项审计日志、发布门禁结果
第3项 — 机密性、完整性和可用性保护
第3.1项 — 机密性保护
要求： 保护存储、传输或以其他方式处理的数据的机密性。
实施方式：
- 传输中的数据： 所有网络连接使用 TLS 1.2+，服务间通信使用 mTLS
- 静态数据： 敏感数据使用 AES-256 加密
- 密钥管理： 硬件支持（HSM/KMS）或 Vault
- 访问控制： 最小权限原则、RBAC/ABAC
证据： 加密清单、加密配置、访问控制列表
第3.2项 — 完整性保护
要求： 保护存储、传输或以其他方式处理的数据、命令、程序和配置的完整性。
实施方式：
- 制品签名： 容器和二进制文件采用 Cosign（签名）
- SBOM 完整性： 每个发布版本的签名 SBOM
- 代码完整性： 签名的 Git 提交、受保护分支
- 数据完整性： 校验和、数字签名
- 配置完整性： 基础设施即代码 (Infrastructure as Code)、GitOps
证据： 签名日志、校验和验证、Git 审计跟踪
第3.3项 — 可用性保护
要求： 保护基本功能的可用性，包括在受到攻击时（例如 DDoS）。
实施方式：
- 冗余系统和故障转移
- 速率限制和 DDoS 防护
- 资源匮乏时的优雅降级 (Graceful Degradation)
- 备份和恢复程序
- 监控和告警
证据： 架构图、灾难恢复 (DR) 计划、负载测试结果
第4项 — 安全默认配置
要求： 产品应以安全的默认配置交付，包括将产品重置为初始状态的能力。
实施方式：
- 默认安全 (Security-by-Default)： 禁用所有不必要的服务
- 无默认密码： 安装向导强制设置个人凭据
- 限制性默认值： 防火墙规则、权限、端口
- 出厂重置： 能够重置为安全的默认配置
- 文档： 用户文档中描述安全配置
证据： 默认配置文件、安装流程文档
第5项 — 未授权访问防护
要求： 通过适当的控制机制（身份认证、身份管理、访问控制）保护产品免受未授权访问。
实施方式：
- 身份认证： 尽可能采用多因素认证 (MFA)
- 授权： 采用最小权限原则的 RBAC
- 会话管理： 安全令牌、超时、失效
- API 安全： API 密钥、OAuth 2.0、速率限制
- 暴力破解防护： 账户锁定、CAPTCHA
证据： 认证架构、权限矩阵、渗透测试报告
第6项 — 最小攻击面
要求： 最小化攻击面，包括外部接口。
实施方式：
- 最小容器： Alpine/Distroless 基础镜像
- 最小服务： 仅开放必需的端口和服务
- 最小依赖： 定期清理（依赖策略）
- 最小权限： 非root容器、受限能力
- 网络分段： 零信任 (Zero-Trust) 架构
证据： 容器扫描报告、端口清单、依赖项审计
第7项 — 存储数据的机密性
要求： 保护存储、传输或以其他方式处理的数据（包括个人数据）的机密性。
实施方式：
- 所有持久化数据库加密（AES-256）
- 加密备份
- 安全密钥轮换
- 数据分类（公开、内部、机密、严格机密）
- 不再需要的数据的删除机制
证据： 加密清单、密钥轮换日志、数据分类方案
第8项 — 存储数据的完整性
要求： 保护存储数据和命令的完整性，防止被篡改。
实施方式：
- 关键数据的完整性校验和
- 审计日志采用一次写入多次读取 (WORM)
- 配置数据的数字签名
- 数据库完整性检查
- 篡改检测机制
证据： 完整性检查日志、审计日志配置
第9项 — 数据最小化 (Data Minimization)
要求： 仅处理产品预期用途所必需的数据（个人数据或其他数据）。
实施方式：
- 隐私设计 (Privacy by Design)：仅收集必要数据
- 每个产品的数据最小化策略
- 保留期限到期后自动删除
- 未经明确同意不进行跟踪/遥测
- 尽可能采用假名化处理
证据： 每个产品的数据目录、数据流图、删除方案
第10项 — 基本功能的可用性
要求： 即使在个别组件发生故障时，产品的基本功能也必须保持可用。
实施方式：
- 识别每个产品的基本功能
- 关键组件的故障转移机制
- 适当情况下的离线能力
- 优雅降级 (Graceful Degradation) 而非完全故障
- 恢复程序已文档化
证据： 关键性分析、故障转移测试、恢复时间目标 (Recovery Time Objectives)
第11项 — 不利影响最小化
要求： 在发生安全事件时，最小化对其他设备和网络可用性的不利影响。
实施方式：
- 网络隔离（分段、VLAN）
- 资源限制（CPU、内存、带宽限制）
- 微服务的断路器模式 (Circuit Breaker Pattern)
- 异常时自动隔离
- 事件遏制程序（应急手册）
证据： 网络分段计划、资源限制、遏制程序
第12项 — 安全相关信息
要求： 收集和提供安全相关信息，包括日志记录和监控。
实施方式：
- 集中式日志记录（安全事件、认证、授权）
- 安全相关操作的审计跟踪
- 监控和告警（SIEM 集成）
- 日志保留：至少12个月
- 日志的防篡改保护
证据： 日志配置、SIEM 仪表板、日志保留策略
第13项 — 安全更新能力
要求： 能够安全地更新产品，包括自动通知可用更新。
实施方式：
证据： 更新架构、签名验证、回滚测试
合规矩阵
| 编号 | 要求 | 实施状态 | 证据位置 |
|---|---|---|---|
| 1 | 适当的网络安全水平 | ✅ | 风险评估、架构 |
| 2 | 无已知漏洞 | ✅ | CVE 监控、扫描报告 |
| 3.1 | 机密性保护 | ✅ | 加密清单 |
| 3.2 | 完整性保护 | ✅ | 签名日志 |
| 3.3 | 可用性保护 | ⚠️ | 产品特定 |
| 4 | 安全默认配置 | ✅ | 默认配置 |
| 5 | 未授权访问防护 | ✅ | 认证架构 |
| 6 | 最小攻击面 | ✅ | 容器扫描 |
| 7 | 存储数据的机密性 | ✅ | 加密清单 |
| 8 | 存储数据的完整性 | ✅ | 完整性日志 |
| 9 | 数据最小化 | ✅ | 数据目录 |
| 10 | 基本功能的可用性 | ⚠️ | 产品特定 |
| 11 | 不利影响最小化 | ✅ | 分段计划 |
| 12 | 安全相关信息 | ✅ | 日志配置 |
| 13 | 安全更新能力 | ✅ | 更新架构 |