安全开发生命周期管理

隐私保护框架

        该隐私保护框架从组织管理、产品全流程、IT 工具支撑、原则指导四个维度，构建了完整的隐私保护闭环体系，实现了从 “战略目标” 到 “落地执行” 的全链条隐私保护，确保产品在全生命周期中符合隐私合规要求。具体内容如下：

1. 顶层基础：隐私保护合规目标管理及组织准备

        作为体系的 “保障层”，聚焦目标落地与人员能力建设：

• 隐私风险控制目标：明确产品的 “隐私合规要求” 和 “功能需求”，并将 “隐私风险控制目标” 纳入正式资源管理（如资源审批、验收），确保目标有资源支撑。

• 组织及人员能力：清晰划分 “角色与职责”（明确各岗位在隐私保护中的分工），通过 “人员培训” 提升团队执行隐私保护工作的能力。

2. 核心流程：全生命周期嵌入隐私保护（PbD 理念）

        以 **“Privacy by Design（隐私设计）”为核心，将隐私保护嵌入产品全生命周期（需求→设计→开发→验证→发布→维护）**，各阶段针对性开展工作：

• 需求管理：开展 “需求隐私合规性分析”“隐私市场准入 / 认证分析”“隐私风险评估”，从源头把控隐私需求的合规性。

• 设计阶段：进行 “隐私风险评估”，遵循 “隐私保护原则”，制定 “隐私保护设计规范”，并开发 “隐私保护资料”（为后续开发提供依据）。

• 开发阶段：严格遵循 “编码规范”，将设计层面的隐私保护逻辑转化为代码。

• 验证阶段：通过 “隐私安全测试 checklist（清单式测试）”，验证产品隐私保护能力是否达标。

• 发布阶段：开展 “CSL 隐私审核”，确保产品发布前符合隐私要求。

• 生命周期（研发维护）：及时处理 “隐私问题”，保障产品运维阶段的隐私风险可控。

3. 技术赋能：IT 化支撑工具

        通过专业平台与工具，为隐私保护提供技术赋能：

• 审核类工具：如 “CSL 安全审核平台”“发布阶段的 CSL 隐私审核”。

• 检测类工具：如 “移动应用个人信息检测平台”（聚焦移动应用场景的个人信息检测）。

• 隐私管理工具：如 “OneTrust”（行业通用的隐私合规管理工具，支持隐私影响评估、合规流程管理等）。

• 沟通与评估工具：如 “CSL 公众号 / 公共邮箱”（信息传递渠道）、“PIA 问卷工具”（开展隐私影响评估，分析产品隐私风险）。

4. 底层准则：隐私保护原则

        为所有隐私工作提供价值观与规则指导，涵盖隐私保护核心原则：包括合法正当透明、目的限制、数据最小化、准确性、存储最小化、完整性与保密性、可归责等（与 GDPR 等全球隐私法规的核心原则一致），是隐私保护工作的基本遵循。

安全开发生命周期管理

需求阶段（BIA/PIA）

一、数据范围定义

        明确需纳入隐私保护与合规管理的数据类型，覆盖：

1. 用户数据（如账号信息、行为数据等）

2. 业务数据（如交易记录、运营数据等）

3. 员工数据（如员工个人信息、权限关联数据等）

4. 设备及标识类数据（如设备 SN、IP 地址、MAC 地址、IMEI 码、地理位置信息等）

二、数据分类与分级管理

• （一）数据分类规则：根据敏感度与隐私风险，划分为两类核心数据：

  • 个人数据：可直接 / 间接识别个人身份的基础信息（如姓名、电话号码、邮箱地址等）。

  • 敏感数据：涉及高隐私风险的信息（如身份证号、信用卡信息、密码、通讯录、精准位置信息等）。

• （二）分级保护措施：对敏感数据实施强化保护：

  • 存储要求：敏感数据需通过加密技术（如对称加密、非对称加密）进行存储。

三、数据生命周期与规模管理

• （一）数据规模盘点：明确核心数据的规模指标，包括：

1. 系统登录账号总量

2. 权限节点（功能 / 数据权限点）数量

3. 用户量级（是否突破 10 万等关键规模阈值）

• （二）数据有效期管理：定义用户数据的保留规则：

  • 明确用户数据的保留有效期（需结合业务必要性、法规要求的期限综合制定）。

四、数据使用与流转安全规范

        覆盖数据 “传输、存储、导出、访问、销毁” 全流程：

1. 传输安全：数据传输需采用加密协议（如 HTTPS），防止传输过程中被窃取 / 篡改。

2. 存储安全：敏感数据强制加密存储；非敏感数据按需选择存储策略。

3. 导出规范：数据导出时必须进行脱敏处理（如隐藏部分字段、替换敏感内容）。

4. 访问权限：严格遵循 “最小必要权限” 原则，仅向必要人员授权数据查看权限。

5. 销毁机制：明确数据销毁规则（如异地备份数据、报表库数据的销毁条件与流程）。

五、第三方合作合规要求

        确保第三方合作过程中的数据安全与合规性：

1. 资质要求：第三方需具备合规资质（如通过 ISO 27001 信息安全管理体系认证、SOC 2 审计等）。

2. 数据共享：明确公司内部之间的数据共享范围、目的及安全保障措施。

3. 产品与人员：第三方产品需同时满足 “开源合规” 与 “安全标准”；对公司内部及第三方相关人员开展安全背景调查。

六、隐私设计规范（以手机 App 为例）

        产品设计阶段需嵌入 “隐私保护前置” 理念（Privacy by Design）：

1. 透明性：向用户透明披露 “数据收集的原因、方式、频次”。

2. 用户选择权：隐私相关选择框（如权限申请、数据收集开关）默认状态宜为 “不选中”，由用户主动选择授权。

3. 最小必要原则：数据收集坚持 “最小化、必要性”，仅收集业务必需的最少数据。

4. 文档化：编制《隐私设计文档（PDD）》，完整记录产品隐私设计逻辑与落地措施。

设计阶段-安全架构

一、部署架构安全要求

        核心原则：网络隔离与端口管控，降低外部攻击风险

1. 私有云部署：后台管理系统与业务操作 portal（门户）需物理 / 逻辑分离，避免权限交叉与攻击面集中。

2. 公有云部署：严格限制端口开放，禁止暴露高风险端口（如 22 端口：SSH 远程登录、6379 端口：Redis 服务、3306 端口：MySQL 数据库），仅开放业务必需端口（如 80/443）。

二、权限管理体系规范

        核心原则：权限分离与最小范围，杜绝越权操作风险

1. 权限隔离：系统管理员（负责系统配置、维护）与业务操作权限（如修改商品价格、审批业务单据）完全分离，禁止 “管理员 + 业务操作” 的复合权限。

2. 范围控制：严格限制拥有管理员权限的人员数量，仅授权给必要的运维 / 技术人员，避免权限滥用。

三、开源组件使用禁忌

        核心原则：规避协议合规风险与代码产权问题

1. 协议限制：

   • 禁止自有商业代码与 GPL 协议开源代码 “一同运行”（避免自有代码因 GPL “传染性” 被迫开源）；

   • 禁止使用 AGPL、SSPL 协议的开源组件提供 PaaS（平台即服务）服务（此类协议对服务端代码开源要求严苛，易触发合规风险）。

2. 架构适配：若基于 Android 开源架构开发，需遵循 Android 开源协议（Apache License 2.0），确保合规使用。

四、加密算法选用标准

        核心原则：淘汰弱算法，优先高安全算法

• 禁止使用的弱算法：MD5（哈希算法，碰撞风险高）、SHA1（哈希算法，安全性不足）、DES（对称加密，密钥长度过短）。

• 推荐安全算法采用-前端哈希 + 后端二次加密方式：

  • 前端哈希（传输层保护）：用户输入敏感信息（如密码、支付密码）时，前端先通过哈希算法（推荐：SHA-256、SHA-3，或带随机盐的轻量哈希）对明文进行 “单向不可逆转换”，再将哈希值传输至服务端。

    → 价值：避免明文在网络传输中被窃听 / 中间人篡改（即使传输被拦截，获取的是无意义的哈希值，无法逆向出明文）。

  • 后端二次加密（存储层强化）：服务端接收前端哈希值后，再通过更复杂的加密 / 哈希增强手段处理（推荐：Argon2、bcrypt、PBKDF2 等 “抗暴力破解” 的密钥派生算法，或结合动态盐的二次哈希，甚至非对称加密的 “私钥签名”）。

    → 价值：即使数据库被非法访问（拖库），存储的是 “二次处理后的密文 / 哈希”，而非前端直接传输的哈希，大幅提升暴力破解、彩虹表攻击的难度。

• 算法特性补充：

  • 哈希算法：单向不可逆（仅加密，无法解密，适合存储密码）；

  • 对称加密：加密 / 解密使用相同密钥（适合批量数据加密，如文件加密）；

  • 非对称加密：使用公私钥对（公钥加密 / 私钥解密、私钥签名 / 公钥验签，适合身份认证、敏感信息传输）。

设计阶段-认证/授权/日志/审计

一、密码安全策略

• 密码复杂度要求：

  • 长度≥8 位，需包含大写字母、小写字母、数字、特殊字符中的至少 3 种；

  • 不可包含用户名。

• 加密与存储规范：

  • 密码需在前端加密后再传输至后端；

  • 后端存储时需使用专有哈希算法（推荐 Argon2，次选 scrypt、bcrypt、PBKDF2）加密。

• 密码生命周期管理：

  • 初始密码：不建议直接发送给用户，应提供限时（≤24 小时）的 “设置密码链接”，用户首次登录必须修改；

  • 密码重置：重置通知中不得包含密码，仅提供限时（≤24 小时）的 “设置新密码链接”，新密码不可为最近 3 次使用过的密码；

  • 自主修改：用户修改自身密码时，需验证原密码；

  • 到期提醒：ToB 类应用中，密码需 90 天到期强制修改，到期前 3-4 次提前提醒。

• 链接安全优化：

  • 不建议使用含明文参数的重置链接（如resetpwd?user=admin&pwd=admin）；

  • 推荐使用加密唯一标识关联用户（如resetpwd?id=GUID，后台通过 GUID 绑定待重置用户）；

  • 修改密码链接（如changepwd?user=admin）仅含用户名而无身份验证机制存在风险，需补充身份校验（如原密码验证、验证码等）。

二、账号与 IP 安全控制

• 登录安全防护：

  • 登录失败时，提示需模糊化（如 “账号或密码错误，或无登录权限”），避免泄露账号是否存在；

  • 连续输错密码达阈值（默认 5 次，可配置）后，账号锁定特定时间（默认 30 分钟，可配置），自动解冻；

  • 冻结状态的账号不可发起密码重置。

• 长期未活跃处理：

  • 超过 180 天未登录的用户账号自动冻结，需手动操作解冻。

• 验证码与 IP 限制：

  • 登录、密码重置、密码修改、短信发送等场景需强制验证验证码，且验证码单次有效；

  • 同一 IP 短时间内（默认 1 分钟）登录失败达阈值（默认 10 次，可配置），该 IP 冻结特定时间（默认 20 分钟，可配置）。

• 增强身份认证：

  • 建议增加双重身份认证（如用户名密码 + 手机验证码、动态口令、邮箱验证等）；

  • 页面长时间无操作（默认 1 小时）强制退出，同时后台立即使 session、token 失效。

三、授权与数据私密性管控

• 权限最小化原则：

  • 用户仅授予完成工作必需的权限；

  • 系统管理员不得拥有业务操作权限（如修改价格、审批业务单据等）。

• API 与数据访问安全：

  • API 访问需严格控制数据权限，防止通过修改参数遍历后台数据或请求异常数据；

  • 示例优化：

    • 风险场景：前端直接传参（如a.example.com/api/user?id=xxx）且无 token 验证，易导致 id 被遍历；

    • 安全方案：前端不传用户标识，后端从 token 中解析用户 ID 后调用接口（如 b 服务），返回时对敏感信息（如手机号）脱敏展示；

    • 接口层需增加数据完整性与防伪造校验，避免参数被篡改或遍历。

• 数据脱敏与隔离：

  • 查询结果或导出数据中涉及敏感信息的，需按业务需求部分脱敏（如用****替换中间字符）；

  • 需联系用户时（如上门服务），建议使用虚拟电话号码隐藏真实信息；

  • 多租户场景下，不同租户的数据需严格隔离，互不可访问。

四、日志与审计规范

• 日志记录范围：

  • 敏感操作需记录用户 ID、时间、事件类型、访问资源、请求参数（Get/Post）等详细信息，日志保留期至少 6 个月；

  • 需记录的关键操作包括：登录成功 / 失败、注销；密码修改、账号状态变更（冻结、解锁、禁用、启用）；用户角色与权限修改；越权及异常请求；重要业务操作（如财务账单、审批流程等）；重要配置变更及系统运维、故障日志。

• 日志安全要求：

  • 日志中不得包含密码等敏感信息；

  • 日志文件的访问需严格控制权限，仅限授权人员查看。

开发阶段：安全编码规范

• 配置与代码分离：禁止在代码中硬编码配置信息（如密钥、数据库账号、接口地址等），建议通过独立配置中心（如 Apollo）统一管理配置，实现配置动态更新与权限管控。

• 文件上传安全控制

  涉及文件上传功能时，需执行：

  • 严格的文件格式校验（避免恶意文件上传）；

  • 上传文件的执行权限判断（禁止赋予可执行权限）；

  • 上传文件存储路径隔离，禁止保存到程序代码所在目录，防止覆盖或篡改业务代码。

• 代码漏洞扫描与修复：开发过程中需通过代码扫描工具（如 SonarQube）检测漏洞，对扫描出的安全风险（如未过滤的输入、不安全的函数调用）需及时修复，确保代码合入前满足安全标准。

• 跨域访问安全限制：实现跨域功能时，必须明确指定允许跨域的源域名（Access-Control-Allow-Origin），禁止配置为 “允许所有域名”（如*），减少跨域攻击风险。

测试阶段：环境与数据安全规范

• 测试环境数据安全

  • 禁止直接将生产环境数据导入测试环境，所有测试数据需经过脱敏处理（如隐藏手机号、身份证号等敏感信息），避免真实数据泄露；

  • 测试环境若需临时开放外网访问用于调试，调试完成后需立即关闭外网访问权限，防止测试环境配置（如 API 密钥、账号密码）泄露。

• 安全测试执行要求

  测试阶段需针对性开展安全测试，核心案例包括：

  • 功能安全测试：模拟常见攻击场景验证防护能力，如用' or '1=1测试 SQL 注入漏洞、用alert("xss")测试 XSS（跨站脚本）漏洞；

  • 权限安全测试：验证权限隔离有效性 —— 用不同权限账号（如高权限管理员、低权限普通用户）分别登录，将高权限账号可访问的 URL / 接口，在低权限账号环境中尝试访问，确认是否存在越权问题。

• 运行账号权限控制

        程序部署与运行阶段，需遵循 “最小权限原则” 配置账号：

• Web 服务启动账号：禁止使用 root（Linux）等超级账号，需创建专用的低权限账号启动服务；

• 数据库访问账号：禁止使用 root（MySQL）、sa（SQL Server）等超级账号，需为程序分配仅含 “必要操作权限” 的专用账号（如仅授权 SELECT/INSERT/UPDATE 特定表，禁止 DROP/ALTER 等高危操作）。

上线阶段：安全终审（FSR）

• 隐私合规审核:需完成隐私合规文件的法务审核，审核通过后，向用户提供合规的隐私政策链接，确保隐私相关内容符合法律法规及公司要求。

• 安全配置落地:提前完成基础安全配置，所有配置需符合公司安全标准，包括：

  • 网络安全：部署并配置防火墙；

  • 传输安全：配置 HTTPS 证书，启用 HSTS（HTTP Strict Transport Security）；

  • 前端防护：完成 XSS（跨站脚本）防护、CSP（内容安全策略）配置；

  • 嵌入限制：合理设置 Iframe 内嵌权限，防止未授权内嵌风险。

• 基础环境安全:系统依赖的基础镜像或操作系统（OS）层，需排查并确保无高危安全漏洞，避免底层环境引入安全风险。

• 代码与开源软件安全

  • 源码安全：通过源码扫描工具检测后，需修复所有高危漏洞；中危漏洞若暂未修复，必须制定明确的修复计划；

  • 开源合规与安全：使用的开源软件需满足两点：① 无 GPL 协议代码（避免合规风险）；② 无高危安全漏洞。

• 渗透测试漏洞修复:完成渗透测试后，需全部修复测试发现的漏洞，无论高危、中危等级，均需处理完毕，确保无未修复漏洞遗留。

• 架构安全审核:需经过架构组的安全 Review，审核通过后方可满足上线条件；审核核心要求：系统不得存在 P1 级高危漏洞，整体架构符合安全设计标准。

运维阶段：持续保障

• 定期安全 Review（每半年一次）:除常规审查隐私合规、OS 基线配置、源码安全、渗透测试结果外，需重点补充以下审查内容，确保全链路安全可控：

  • 账号与权限审查：核查数据库账号清单（清理冗余账号）、系统管理员权限清单（避免超范围授权）；

  • 日志审计：审查敏感操作日志、用户登录日志、DBA（数据库管理员）数据修改日志（追溯异常操作）；

  • 证书管理：检查 HTTPS 证书有效期，提前规划到期更新，避免证书过期导致服务不可用或安全风险。

• 全层级安全补丁升级:定期对系统各层级组件进行漏洞扫描，及时完成版本更新与安全补丁部署，覆盖范围包括：

  • 底层环境：操作系统（OS）层；

  • 中间件与基础组件：Redis、PHP、Java 等运行时组件；

  • 数据库层：MySQL、TiDB 等数据库系统。

• 源码持续扫描（含线上改动）:不仅需对常规源码进行定期扫描，针对线上 Bug 修复后改动的源码，也必须纳入定期扫描范围，避免修复 Bug 时引入新的安全漏洞，确保代码安全状态持续达标。

• 漏洞与数据泄露应急处理

  • 漏洞快速修复：

    • 针对黑客攻击、白帽子（安全研究者）上报的漏洞，需立即启动应急响应；

    • 企业漏洞响应平台上标记的高危漏洞，需在 7 天内完成修复；

  • 数据泄露核查：

    • 若因各类原因（如配置失误、攻击等）导致用户密码、AppKey 泄露，或用户数据、工单数据泄露，需第一时间开展全面核查，定位泄露范围并采取补救措施（如重置密码、更换密钥、加固数据访问权限）。