术语定义：

  • 用户数据 User Data

    • 指用户拥有的数据，包括但不限于原始数据（用户输入的数据）、处理原始数据产生的数据（用户上线习惯、用户画像等）、系统运行产生的数据（音视频、图片、日志、事件等）。

  • 隐私数据 Privacy Data

    • 用户的机密/隐私信息以及个人的敏感数据。

    • 如：个人敏感信息包括身份证件号码、个体生物识别信息（指纹、人脸等）、银行账户、通信记录和内容、行踪轨迹、住宿信息、14周岁及以下儿童的个人信息等。

  • 数据主体 Data Subject

    • 用户数据所标识的自然人或者拥有数据的组织或个人，包括但不限于个人、用户、第三方。

  • 数据处理 Processing of Data

    • 针对用户数据进行的操作行为：如采取收集、记录、组织、构造、存储、调整、更改、检索、咨询、使用、通过传输而公开、散布或其他方式对他人公开、排列或组合、限制、删除或销毁而公开等自动化方式。

  • 生物性识别数据 Biometric Recognition Data

    • 基于特别技术处理自然人的相关身体、生理或行为特征而得出的个人数据，这种个人数据能够识别或确定自然人的独特标识，例如脸部形象或指纹数据。

规范约束

安全设计原则

最小攻击面原则

系统每增加一个功能特性就有可能会引入新的风险，通过安全开发可以减少攻击面进而达到控制系统整体风险的目的。

  • 增加了攻击条件（过滤输入）

  • 减少了可以攻击的人数（功能鉴权）

  • 删除无用功能（绝对避免）

权限最小化原则

  • 系统只授予主体必要的权限，而不要过度授权，这样就能有效地减少系统、网络、应用、数据库出错的机会。

  • 事物只拥有可以完成他们任务的最小权限，即不赋予不必要的权限。

  • 包括但不限于：用户权限和资源权限（比如可以使用的CPU、内存、网络流量和存储容量等等）。

默认安全原则

  • 在软件领域的含义就是：让默认的配置和策略尽可能的安全。如，许多场景，安全和产品体验经常会发生冲突，这时候应当选择安全优先，在安全的前提下，可以允许通过手动关闭安全配置或策略来提升产品体验。

  • 如，默认打开密码复杂度策略，但产品可能可以允许用户关闭这个策略来提升体验。

失效安全原则

  • 即业务系统能够正确安全地处理各种异常和错误，即使再访问出错时，也不至于导致信息安全受到威胁。例如，在网页访问出错时，不能输出错误日志甚至包密码等含敏感信息。

不信任第三方系统原则

  • 第三方的系统也可能会存在安全漏洞，进而被人攻击，应充分考虑到当第三方系统被攻击时，如何保障自己的业务系统的安全性。

  • 如：当我们向第三方系统查询数据时，必须对数据进行有效性验证后才可以使用（比如使用这些数据进行数据库查询或显示到用户浏览器上）

业务隔离原则

  • 不要把所有鸡蛋都放在一个篮子里。

公开设计原则

  • 私有算法不公开不一定就是安全，因为有可能泄露，如抓包、反编译、入侵服务器等，如网易云异或加密。

  • 正确地做法应该是：假设算法被破解或完全公开，同样能保证系统的安全。典型的案例诸如业界广泛使用的对称加密算法（AES）和非对称加密算法（RSA），它们的设计实现都是公开的，但是仍然是安全的。

正确地修复漏洞

  • 一旦漏洞被发现和确认，首先要找到测试它的方法和弄清产生根因，对于产生漏洞的代码，需要确认该代码是否也在其它产品或版本上使用，即需要对漏洞进行完整地排查和修复

数据与代码分离原则

  • 数据与代码分离原则广泛适用于各种由于 "注入" 而引发的安全问题的场景。如 XSS、SQL Injection、CRLF Injection、X-Path Injection 等。

不可预测性原则

  • 我们无法要求运行的系统完全没有漏洞，因此可采取让攻击失效的办法，大大提高攻击的门槛，经过实践检验，证明这个思路确实是有效的，即使无法修复code，但是如果能够使得攻击的方法无效，那么也可以算是成功的防御。

  • 不可预测原则可以巧妙地用在一些敏感数据上，该原则的的实现往往需要用到加密算法、随机数算法、哈希算法等。

木桶短板原则

  • 要首先把精力重点放在弥补安全短板上，而不是放在巩固安全优势上（虽然也很重要）。

数据保护原则

信息保密意识

保持高度信息安全和保密意识，拒绝以任何形式向未经用户授权的第三方透露用户隐私信息。

数据分级原则

不同数据有不同的敏感程度和访问密级，如果对所有数据都采用高密级的保护，会影响实际运作的效率，同时也是对资源的浪费，因此需要建立一套数据的分级保护原则，针对不同级别的数据采用不同的保护措施。根据数据的敏感程度和访问密级，对数据密级划分为4个等级：

  • 公开（不会产生任何影响）

    • 公开信息，比如公钥、域名、连接等公开信息，这些信息通常不设置访问门槛。

  • 敏感（易引起用户反感的数据）

    • 联系方式信息：如手机号码、电话号码、电子邮箱、通讯地址。

    • 证件号码：如身份证、驾驶证、护照号码。

    • 建模后的生物性识别数据：如人脸数据、指纹数据。

    • 位置与轨迹：如地理位置、出行记录、运动轨迹。

    • 14周岁及以下儿童的相关信息。

  • 秘密（一般的秘密信息，泄露会影响数据主体的利益）

    • 密码密钥类：如登录密码、支付密码、密钥信息。

    • 具有关联性质的个人原始信息，比如姓名+身份证号码+人脸共存。

  • 机密（泄露会使数据主体的利益遭受严重的损害）

    • 如用户的商绝密信息、商业机密、服务器私钥。

合法性、合理原则

  • 数据处理要有合法基础，如数据主体的同意、履行与数据主体之间的合同或执行数据主体所要求的合同所必须、公共利益等。

  • 在处理数据前，必须向数据主体说明数据处理的种类、目的、方式、范围、存储期限、是否转移至第三方等，并征求其授权同意。

  • 数据处理的目的必须要满足合法、正当、必要、明确的要求，不能进行与这些目的不一致的处理。 ==== 主体参与原则

数据主体具有知情权、访问权、纠正权、删除权（被遗忘权）、限制处理权、可携带权、拒绝权、不受自动化处理约束等权利。应尽多的将支持个人数据主体行使上述权利的功能包括进去。

最小化原则

只处理满足数据主体授权同意的目的所需的最少的数据类型和数量，不能收集用户授权同意范围之外的数据。

安全性原则

  • 在数据的生命周期内必须有足够的安全机制，确保数据的完整性、保密性和可用性。防止未经授权的访问、销毁、使用、修改和不当披露。

  • 须在用户信息或主界面中提供隐私声明，描述本软件涉及所有用户数据类型、目的、处理方式、留存期、风险或建议。

  • 用户数据的处理过程要进行清晰、完整的记录，做到数据处理过程可追溯、可问责。

认证与鉴权

认证方式

  • 基于知道的（口令认证）：如账号密码认证；实现简单、使用简单、用户接受度最高、安全性最低。

  • 基于拥有的（硬件认证、第三方认证）：如智能卡、身份识别卡、SIM认证（短信）、邮箱认证；实现较简单、使用较简单、用户接受度较高、安全性较高。

  • 基于固有的（生物信息认证）：如指纹、人脸或虹膜；实现有一定难度、使用较简单、用户接受度较低、安全性高。

  • 基于关系的（）：如指纹、人脸或虹膜；实现有一定难度、使用较简单、用户接受度较低、安全性高。

认证要求

  • 身份认证的判断处理逻辑应在服务端进行。

  • 禁止通过比较密码本身来鉴别身份，要通过比较密码的摘要来鉴别身份，防止基于对比时间的破解、减少密码明文的传输。

  • 需要有复杂度要求，禁止使用弱密码、风险密码等。

  • 需要有防暴力破解能力，避免暴力破解。

  • 按应用场景确定密码过期策略：保证账号密码定期更换。

访问控制

  • 根据应用场景提供对应的鉴权机制，依据安全策略控制用户对数据的访问。

  • 最小权限原则，仅仅授予对应角色所需的最小/最少权限，并在它们之间形成互相制约的关系。

  • 对操作敏感数据功能做一定的标识与限制。

数据安全

网络安全

  • 应采用密码安全技术或其他手段保证传输数据的完整性、保密性和抗抵赖。

  • 传输认证类信息时，应采用安全技术措施处理后再进行传输，比如仅传输原数据的摘要。

  • 公网环境使用安全的传输通信协议，如：HTTPS、TLS、DTLS等，尽量避免使用不安全的传输通信协议，比如FTP、SNMPv2。

  • 禁止使用不安全的传输通信协议、加密方案。如需版本兼容，默认不兼容，充分告知用户使用不安全传输通信协议的风险，用户知晓并确认后开启。

存储安全

  • 应采用密码安全技术或其他有效措施保证存储的数据的完整性、保密性和抗抵赖。

  • 若需存储敏感信息的原始信息和处理后数据时，原始信息与处理后的数据分开存储。

  • 采用密钥分级保护管理机制（如下图所示），至少实现2级保护机制。密钥部件至少由2部分构成，且至少有1部分在部署时随机生成。

  • 禁止密钥硬编码写死在代码中。

UI去敏感化

  • 展示层默认显示时脱敏后的敏感信息，以降低在展示环节的泄露风险，如手机号、银行卡号、身份证号码中间几位用 * 号代替。

  • 输入密码等敏感信息时，需脱敏处理，如使用 * 号替代输入的信息，且禁止拷贝。

  • 根据场景对用户数据去标识化处理，并与用户信息存储分离。

日志审计

日志审计是对数据访问活动的跟踪记录，从而实现对用户访问行为的主动监控，生成审计所需的信息，失败各类异常时间。

  • 数据活动包括但不限于用户登录、权限设置、数据查询、数据导出、敏感数据访问等。

  • 日志记录内容包括但不限于操作人、操作时间、操作动作、操作途径、操作对象和操作结果。

  • 确保日志审计信息无法删除、修改和覆盖。

  • 日志数据安全存储，利用密码技术保护避免非法查看及篡改。

其他

  • 鼓励用户选择复杂的密码，警告用户不要各处使用相同密码

  • 不要泄露用户的敏感信息

  • 能够侦测登录异常、恶意尝试，即使制止

  • 要派人潜伏到安全行业里，或者聘安全顾问，别等到门户网站报道了才知道密码大规模泄露

  • 能够使密码失效（锁定账户），或者周期性提醒修改密码

  • 提前规划密码算法升级的办法

密码强弱规则

密码输入分为数字，小写字母，大写字母，特殊符号4类，等级分为4个等级，具体如下：

  1. 风险密码

    • 密码长度小于8位，或者只包含4类字符中的任意一类，或者密码与用户名一样，或者密码是用户名的倒写。

  2. 弱密码

    • 包含两类字符，且组合为（数字+小写字母）或（数字+大写字母），且长度大于等于8位。

  3. 中密码

    • 包含两类字符，且组合不能为（数字+小写字母）和（数字+大写字母），且长度大于等于8位。

  4. 强密码

    • 包含三类字符及以上，且长度大于等于8位。

JavaScript 判断密钥强度
    function getPwdRank(username, userPassword) {
        var iRank = 0;
        userPassword.match(/[a-z]/g) && iRank++;
        userPassword.match(/[A-Z]/g) && iRank++;
        userPassword.match(/[0-9]/g) && iRank++;
        userPassword.match(/[^a-zA-Z0-9]/g) && iRank++;
        iRank = (iRank > 3 ? 3 : iRank);
        if (userPassword.length < 8 || iRank === 1 || userPassword === username || userPassword === username.split("").reverse().join("")) {
            iRank = 0;
        }
        if (iRank === 2) {
           if ((userPassword.match(/[0-9]/g) && userPassword.match(/[a-z]/g)) || (userPassword.match(/[0-9]/g) && userPassword.match(/[A-Z]/g))) {
             iRank = 1;
           }
        }
        return iRank;
    }

密码相关功能设计

  • 支持设置用户密码最低强度限制：弱密码、中密码和强密码，默认是中密码。

  • 其他安全性设计：用户激活机制，密码过期时间机制

  • 记住密码/自动登录设计

    • 禁止客户端本地保存密码，容易泄露。

    • 应通过向服务端请求自动登录的票据，客户端保存此票据。下次登录时，用该票据作为请求自动登录。

      • 客户端根据登录成功后获取的TGC向CMS申请令牌。

      • 自动登录票据应该与登录客户端的MAC地址、IP地址关联绑定，同时设置该自动登录票据的失效时间。

五类安全服务 [1]

认证（鉴别）服务：在网络交互过程中，对收发双方的身份及数据来源进行验证。 访问控制服务：防止未授权用户非法访问资源，包括用户身份认证和用户权限确认。 数据保密性服务：防止数据在传输过程中被破解、泄露。 数据完整性服务：防止数据在传输过程中被篡改。 抗否认性服务：也称为抗抵赖服务或确认服务。防止发送方与接收方双方在执行各自操作后，否认各自所做的操作。

OSI 八大安全机制 [2]

  1. 加密

    • 常用的加密算法有对称加密算法（例如DES/AES/SM4等算法）和非对称加密算法（如RSA/ECC/SM2等算法）。

  2. 认证/数字签名

    • 数字签名是认证（鉴别）服务最核心的技术。常用的签名算法有RSA算法、ECDSA算法、SM2算法等等

  3. 访问控制

    • 通过用户角色、用户组等规则进行验证，一般的应用常使用基于用户角色的访问控制方式。

  4. 数据完整性

    • 通常可以使用单向加密算法对数据加密，生成唯一验证码，用以校验数据完整性。常用的加密算法有MD5和SHA

  5. 业务流填充

    • 在数据传输过程中传输随机数的方式，混淆真实的数据，加大数据破解的难度，提高数据的保密性。

  6. 网络隔离

    • 避免使用不安全网络进行数据交互，如网关来隔离公网直接访问微服务。

  7. 公证

    • 公证机制对应抗否认性服务。公证机制的作用在于解决收发双方的纠纷问题，确保两方利益不受损害。类似于显示生活中，合同双方签署合同的同时，需要将合同的第三份交由第三方公证机构进行公证。

加密算法的使用

对称加密算法使用

  • 常用算法：AES、SM4（类AES）

  • AES标准有一些要素：密钥、加密模式、向量、填充模式等。(标准本身是公开的)

关键点：位数足够（至少128位，推荐256位），保护密钥，针对不同特性的明文选用合适的加密模式。

模式选型说明

  • ECB

    • 适用：分组少（字符长度小于32，两个分组以下），且数据本身随机性较好

    • 避免：分组较多（>32个字符，>2个分组），部分格式固定

  • CBC

    • 适用：分组一般（10个分组以下），第一个分组随机性较好

    • 避免：分组较多（>10个分组），第一个分组格式固定

密码(口令)加解密

密码（口令）包括登录密码、中间件（数据库、消息队列、缓存服务）访问密码等，使用AES对称加密算法对密码（口令）加密存储和传输。

特点：长度在8~32字节，在AES中，最多2个分组，且密码本身具有随机性，因此可以使用ECB模式，更推荐使用CBC模式。

私钥证书加解密

服务实现https协议，需要私钥证书，私钥证书需要加密保存。

特点：私钥证书的格式是公开的，而且头尾带有固定标识，如PEM格式的私钥：

—–BEGIN RSA PRIVATE KEY—–
MIICJjCCAdCgAwIBAgIBITANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCVVMx
...
1p8h5vkHVbMu1frD1UgGnPlOO/K7Ig/KrsU=
—–END RSA PRIVATE KEY—–

在AES加密过程中会产生多个分组，考虑到证书文件中有明显的固定标识，因此禁止使用 ECB 模式对私钥证书加解密（已知明文攻击，破解密钥），推荐使用 GCM 模式。

长段数据加解密

如：图片、语音、视频等。

  • 这些数据往往超过1024字节，分组较多，因此禁止使用 ECB 模式，推荐使用 GCM 模式。

  • 由于这类文件自身较大，数据量大时不方便更换密钥，因此推荐定义加密头来表示，包含加密标识和标识对应的解析策略。

  • 加密头示例：

    • 加密标记：固定 x 字节，对应一类加密算法、策略，下面以带向量的对称加密策略为例定义请求头剩余部分。

    • 密钥密文长度：1字节，保存密钥密文的长度，单位字节

    • 密钥密文：n字节

    • 向量长度：1字节，保存向量的长度，单位字节

    • 向量：n字节

非对称加密算法使用

  • 常用算法：RSA、ECC（SM2）

  • AES标准有一些要素：公钥、私钥。公钥可以向外部公开，私钥必须妥善保管。

关键点：位数足够（RSA至少1024位，推荐2048位，ECC至少192推荐192），私钥必须妥善保管。由于性能较差尽量加密少量数据，加密大量数据时，生成临时密钥，只加密临时密钥，然后再通过对称加密进行加解密。

编码传输

在网络传输过程中，为了使得数据不乱码，故需要先编码，再传输，再解码。可以选择以下两种方式

  • 16 进制编码

    • 编码速度相对较快，编码后文本较长

  • 64 进制编码

    • 编码速度相对较慢，编码后文本较短

注意：

  • 编码后的数据一定会使得编码后的数据比原文本更长，占用更多的网络带宽，编码解码仅是为了更好地兼容性。

  • 为了性能，不同场景有更合适的编码选择；但处于简化系统的目的，推荐在一个系统内统一使用一种编码方式。

1. OSI五类安全服务和八大安全机制, https://blog.csdn.net/algzjh/article/details/62216040
2. OSI五类安全服务和八大安全机制, https://blog.csdn.net/algzjh/article/details/62216040