企业官网建设流程全解析

1. 数据安全标准

1.1. 算法与协议标准

• 1.1.1. 在安全的工程实践中，​“不要自行设计加密算法”已是大家的共识，使用经过实践检验的、成熟的加密算法是最佳的选择

• 1.1.2. 让学术上的事情归学术、工程上的事情归工程，加密算法涉及大量理论与学术研究成果，理应由学术圈的专家来设计

• 1.1.3. 选用的算法需要保持与时俱进并需要具备适度的超前性

• 1.1.4. 对称加密算法

• 1.1.4.1. 除非法律法规或监管层面有单独的规定（例如国内金融行业有使用SM示例加密算法的要求）​，推荐默认选用AES（Advanced Encryption Standard）加密算法

• 1.1.4.2. AES支持的三种密钥长度目前均是安全的，推荐首选256位

• 1.1.4.3. 除非清楚地知道各种模式的区别，否则推荐选用GCM模式（Galois/Counter Mode）

1.1.4.3.1. 如果不知道选用什么模式，那就选GCM模式，除非你清楚知道各模式的区别

• 1.1.4.4. GCM

1.1.4.4.1. 是在加密算法中采用的一种计数器模式，带有GMAC消息认证码

1.1.4.4.2. AES的GCM模式属于AEAD（Authenticated Encryption with Associated Data）算法，同时实现了加密、认证和完整性保障功能

1.1.4.4.3. 其他不带认证码的模式无法实现消息的认证，这是源于一个密码学的常识

1.1.4.4.3.1. 加密不是认证，一般的加密解密过程可以理解为多轮转换或洗牌，就算密文被篡改，也是可以被解密的，只是解密出来的数据是乱码

1.1.4.4.4. 在GCM模式出现之前，AES对称加密只是确保了消息的保密性，加密后的消息即使被篡改了，通常也可以被解密，只是解密出来的结果是乱码，并不能确认消息的发送者以及消息的完整性

• 1.1.4.5. 使用场景

1.1.4.5.1. 数据存储加密

1.1.4.5.2. 后台节点间、客户端到服务器之间的认证加密（同时实现身份认证、传输加密）​

• 1.1.5. 非对称加密算法

• 1.1.5.1. 如果选用RSA，首选RSA 2048

• 1.1.5.2. 如果选用ECC，首选ECC 224

• 1.1.5.3. 场景

1.1.5.3.1. 协商/交换对称加密密钥

1.1.5.3.2. 身份认证

1.1.5.3.3. 数字签名（即使用私钥加密待传输的内容）​

• 1.1.6. 单向散列

• 1.1.6.1. 常规的单向散列，如SHA256、SHA384、SHA512、SHA-3等，*首选SHA256

• 1.1.6.2. 慢速散列，如bcrypt、scrypt、PBKDF2等，如果选用PBKDF2，*推荐配合HMAC-SHA256使用

• 1.1.6.3. 推荐的做法

1.1.6.3.1. 用户侧不传递原始口令，在用户侧使用任何一种慢速加盐散列处理后再发送给服务器侧

1.1.6.3.2. 服务器侧收到用户侧发送过来的慢速加盐散列结果，推荐选用SHA256加盐散列继续处理

1.1.6.3.3. 无论使用哪一种散列算法，都需要加盐

• 1.1.7. 消息认证

• 1.1.7.1. 推荐使用HMAC-SHA256

• 1.1.7.2. 身份认证：确定消息是谁发的

1.1.7.2.1. 对约定的消息进行运算，比如请求的参数以及当前时间戳

• 1.1.7.3. 完整性保障：确定消息没有被修改

1.1.7.3.1. HMAC运算结果不包含消息内容，通常和明文消息一起发送，不能保障消息的保密性

• 1.1.8. 密码学安全的伪随机数生成器

• 1.1.8.1. 在无外部输入的情况下，计算机本身无法产生真正随机的随机数，最多只能产生密码学安全的伪随机数，即*CSPRNG（Cryptographically Secure Pseudo-Random Number Generator，密码学安全的伪随机数生成器）​

• 1.1.9. 传输协议

• 1.1.9.1. 推荐首选TLS 1.2及以上版本，新业务推荐直接使用TLS 1.3或以上版本

• 1.1.9.2. 完全不要使用SSL 1.0、SSL 2.0、SSL 3.0等版本

• 1.1.9.3. TLS 1.0也不安全（已被发现漏洞）​，不推荐使用

• 1.1.9.4. 使用TLS 1.0的网站也不符合PCI-DSS（支付卡行业数据安全标准）要求，支付类网站需要禁用

• 1.1.9.5. TLS 1.1虽未发现明显漏洞，但各方面已被TLS 1.2超越，不推荐使用，PCI-DSS也强烈建议弃用TLS1.1

1.2. 口令标准

• 1.2.1. 服务侧静态口令标准

• 1.2.1.1. 能够与SSO集成的场景，均应使用SSO身份认证，并配合动态口令或双因子认证，验证员工的身份

• 1.2.1.2. 不得使用默认初始口令

• 1.2.1.3. 不得使用通用口令（即一个口令在多处使用）​

• 1.2.1.4. 口令长度不小于14位

• 1.2.1.5. 口令应包含大写字母、小写字母、数字、符号

• 1.2.2. 员工口令标准

• 1.2.2.1. 首选使用SSO

• 1.2.2.2. 如果业务无法与SSO集成

1.2.2.2.1. 口令长度不小于10位

1.2.2.2.2. 口令应包含大写字母、小写字母、数字、符号中的三种

• 1.2.3. 用户口令标准

• 1.2.3.1. 口令长度不小于8位

• 1.2.3.2. 口令应包含大写字母、小写字母、数字、符号中的三种

• 1.2.3.3. 建议不上传用户的原始口令，先在用户侧执行慢速加盐散列处理后再上传

• 1.2.3.4. 用户口令可通过检测并展示口令强度、提示的方式，告知用户风险，因为涉及用户体验的问题，是否采用强制策略需要权衡

1.3. 产品与组件标准

• 1.3.1. 对安全团队来说，通常需要对常用的组件制定配置（或加固）规范、加固脚本，如果需要适配这么多的组合，也是不切实际的

• 1.3.2. 可以提供更好的技术支持

• 1.3.3. 可以更好地跟企业内部的安全产品适配，获得安全防御或告警的能力

• 1.3.4. 使用量少，企业内部的专业技术支持力量不会专门为其提供技术支持

• 1.3.5. 安全检测能力可能覆盖不到，在发生入侵事件时不能发出告警，最终损害的还是业务自身的利益

• 1.3.6. 操作系统标准

• 1.3.6.1. 服务器侧：推荐选一到两种操作系统并确定主版本，并将安全防御或检测能力植入系统，如安全加固配置、HIDS安全组件等

• 1.3.6.2. 用户侧：推荐选用大家都比较熟悉的系统并确定主版本，并实施安全政策相关的配置，如入域或将原身份认证模块替换为SSO认证模块、组策略、网络准入控制等

• 1.3.7. Web服务器标准

• 1.3.7.1. 推荐约定使用少量几种Web服务器组件并确定主版本

• 1.3.8. 数据库标准

• 1.3.8.1. 推荐约定使用少量几种数据库组件并确定主版本

• 1.3.9. 容器基础镜像

• 1.3.9.1. 目前用得最多的容器是Docker，与虚拟机相比，Docker性能更好，在同样的硬件环境下，可运行的容器数量远远多于可运行的虚拟机的数量，支持快速批量部署，但隔离性要弱于虚拟机

• 1.3.10. 用户侧标准

• 1.3.10.1. 使用指定的防病毒软件

• 1.3.10.2. 配置指定的补丁更新地址

• 1.3.10.3. 入域或将原身份认证模块替换为SSO身份认证模块

• 1.3.10.4. 安装/使用指定的网络准入控制与策略检查客户端软件

• 1.3.10.5. 员工电脑是大家的生产力工具，使用得最多，也最容易出现各种问题

• 1.3.10.6. 使用统一的环境，将有助于IT技术支持人员快速定位及解决问题

• 1.3.11. 限制使用的服务

• 1.3.11.1. FTP的使用还会给防火墙管理带来麻烦，因为涉及多个端口的开放，而能够真正弄明白FTP各种模式（主动模式和被动模式）以及所需要开放的端口的人员不多，带来的沟通和管理成本也很高，强烈建议禁用

• 1.3.12. 例外场景

• 1.3.12.1. 在登记备案系统中登记

• 1.3.12.2. 安全团队介入，提供专业的风险评估与加固意见，实施加固措施

• 1.3.12.3. 更新产品标准，与时俱进

• 1.3.13. 数据脱敏标准

• 1.3.13.1. 数据脱敏，即按照一定的规则对数据进行变形、隐藏或部分隐藏处理，让处理后的数据不会泄露原始的敏感数据，实现对敏感数据的保护

• 1.3.13.2. 脱敏标准只是一种约定，让企业内的不同业务都采用同一标准进行脱敏，避免使用不同的脱敏标准，因为黑客可能利用不同业务的漏洞拼凑出完整的明文信息

• 1.3.14. 漏洞定级标准

• 1.3.14.1. 对不同的漏洞按照定级进行排序，可以决定处置的优先级

• 1.3.14.2. 五级：严重、高危、中危、低危、可接受

• 1.3.14.3. 三级：高危、中危、低危

2. 数据安全技术规范

2.1. 数据安全技术规范，用于指导或规范业务的安全架构设计、开发实现、部署实施、运维实践等目的

2.2. 安全架构设计规范，从架构方案上保障产品的方案设计符合业界最佳实践

2.3. 安全开发规范，从编码上保障产品的各项安全要素得以落地

2.4. 安全运维规范，规范产品发布流程（如上线扫描、配置库登记、环境要求、加固与防御措施等）​，以及上线后的运维要求等

2.5. 安全配置规范，针对具体操作系统或具体中间件的加固规范

2.6. 安全架构设计规范

• 2.6.1. 身份认证与敏感业务超时管理

• 2.6.1.1. 对于To C业务，如涉及访问UGC数据（用户创建的内容）​，后台数据访问层访问数据时的身份认证应首选使用用户身份认证通过的凭据，采用基于用户的身份认证，而不是基于后台间的身份认证

• 2.6.1.2. 在应用自身实现，需要业务的开发人员基于SSO接入标准进行相应的开发

• 2.6.1.3. 在接入网关上统一实现，这种方式不需要业务投入额外的开发即可通过网关配置实现，超时参数直接在接入网关上进行配置

2.6.1.3.1. 让业务聚焦在业务实现上，共性的问题交给基础设施来完成

• 2.6.2. 最小化授权

• 2.6.2.1. 应用系统应按最小化授权设计，并在访问业务时验证权限，防止权限不足、权限过期、平行越权、垂直越权等风险

• 2.6.2.2. 在应用内建立授权模块，可以做到精细化的权限控制

• 2.6.2.3. 可使用外部权限管理系统，但适用场景有限，通常用于内部业务

• 2.6.3. 访问控制

• 2.6.3.1. 防止敏感数据被批量查询，应用接口不能信任企业内部和外部的任何人/系统，需基于身份认证和授权，执行以身份为中心的访问控制

• 2.6.3.2. 可以通过频率和总量控制缓解，也可以通过监控告警和审计，识别数据泄露（但属于事后措施）这两种方式都没有从根本上解决问题

• 2.6.4. 审计

• 2.6.4.1. When：时间

• 2.6.4.2. Where：用户IP地址

• 2.6.4.3. Who：用户ID（用户名）​

• 2.6.4.4. What：操作和操作对象

• 2.6.4.5. 日志管理系统是多个应用系统共用，通过应用层接口接收日志，而不是直接开放数据库端口（防止日志被外部篡改或删除）​

• 2.6.4.6. 应用系统不需要持有日志管理系统的数据库账号

• 2.6.5. 资产保护

• 2.6.5.1. 敏感个人信息以及涉及个人隐私的数据、UGC（User Generated Content，用户生产内容）数据、口令、加解密密钥、私钥，需要加密存储

• 2.6.5.2. 网应采用全站HTTPS，覆盖所有业务；内网敏感数据传输、后台管理等业务，也应实施HTTPS或其他加密传输机制（如加密的RPC）​

2.7. 安全开发规范

• 2.7.1. 不能信任外部传入的任何参数

• 2.7.2. 防止无意中的内部信息泄露

• 2.7.3. 避免使用高危功能

• 2.7.4. 防止SQL注入

• 2.7.5. 防止XSS

• 2.7.6. 防止路径遍历

• 2.7.7. 防止SSRF

• 2.7.8. 防止缓冲区溢出

• 2.7.9. 隐藏内部信息

• 2.7.10. 禁止高危功能

• 2.7.10.1. 在Web应用中提供任意操作系统命令执行功能（类似WebShell）​

• 2.7.10.2. 在Web应用中提供任意SQL执行功能

• 2.7.10.3. 在Web应用中提供实时的代码编译功能

• 2.7.10.4. 在Web应用中提供实时的代码编译功能

2.8. 安全运维规范

• 2.8.1. 安全运维规范

• 2.8.1.1. 业务在发布前，需要满足一定的条件，称为发布条件或准入条件

• 2.8.1.2. 发布审核

2.8.1.2.1. 在强流程组织内，通常需要事先经过审核才能发布；而在弱流程组织内，通常没有该环节

• 2.8.1.3. 经过安全扫描或检测，确保不含高危漏洞

• 2.8.2. 基础数据登记

• 2.8.2.1. 最基本的信息如IP、域名、操作系统、端口等，需要在配置管理数据库（CMDB）中登记，这些数据将作为安全工作的数据源输入

• 2.8.3. 系统及组件安装

• 2.8.3.1. 所使用的操作系统及组件，需要从产品与组件标准清单中选取，且需要从内部源获取并安装

• 2.8.3.2. 不能任意安装清单之外的产品，也不能从不明来源的地方下载

• 2.8.3.3. 不能任意安装清单之外的产品，也不能从不明来源的地方下载

• 2.8.4. 安全加固

• 2.8.4.1. 后台管理入口只对员工开放

• 2.8.4.2. 后台管理账号尽量跟SSO账号绑定，避免自建账号体系

• 2.8.4.3. 除了已登记的服务及端口保持开放，其他服务监听一律关闭

• 2.8.4.4. 操作系统及各组件，按照已发布的配置规范执行加固

• 2.8.5. 安全防护

• 2.8.5.1. 启用安全防护能力，包括但不限于抗DDoS、HIDS、WAF等

• 2.8.6. 事件响应

• 2.8.6.1. 在发现高危风险、入侵事件、漏洞报告等情况下，应基于应急响应流程指引，启动应急响应，消除风险

2.9. 安全配置规范

• 2.9.1. 安全配置规范用来指导业务对常用的操作系统和常用组件进行加固，防止默认或错误的配置引入风险

• 2.9.2. 常见的风险有：弱口令、误将高危服务端口直接对外网开放、使用含有高危漏洞的开源组件等

• 2.9.3. 身份认证

• 2.9.3.1. 消除无认证机制的数据服务，需要为默认无口令的服务设置符合口令标准要求的口令

• 2.9.4. 授权

• 2.9.4.1. 仅授予各账号完成工作所需的最小权限

• 2.9.5. 访问控制

• 2.9.5.1. 作为降低攻击面的重要举措，服务器应当关闭不必要的监听服务，并限制服务开放范围

• 2.9.5.2. 为了缓解暴力破解行为，操作系统还可以配置登录次数与锁定限制等

• 2.9.6. 审计

• 2.9.6.1. 启用操作系统、组件、应用的审计功能，记录相关操作日志，可用于在出现安全事件后，进行追踪定位

• 2.9.7. 资产保护

• 2.9.7.1. 需要保护主机计算资源的完整性，不受病毒、木马、蠕虫的破

• 2.9.7.2. 针对Windows服务器来说，需要更新补丁以消除潜在的系统漏洞以及安装防病毒软件

• 2.9.7.3. 对Linux服务器来说，也需要具备病毒发现能力

3. 外部合规认证与测评

3.1. 等级保护认证测评，来自对《关键信息基础设施安全保护条例》的合规遵从，适用于关键信息基础设施

3.2. GDPR法律合规，适用于向欧盟用户提供服务的业务

3.3. PCI-DSS（Payment Card Industry Data Security Standard，支付卡行业数据安全标准）​，来自合同义务，适用于所有涉及支付卡处理的实体

3.4. 认证测评的结果，反过来，又可以作为政策文件体系的输入，用于完善政策文件体系、安全基础设施等

3.5. CII与等级保护

3.6. PCI-DSS

• 3.6.1. 不属于法律*，但只要涉及支付卡处理，就需要履行合同义务，执行PCI-DSS合规，这也对云计算服务提供商提出了挑战

• 3.6.2. 如果不能满足PCI-DSS合规要求，就不能向支付行业的客户提供云计算服务

3.7. CSA STAR

• 3.7.1. 云安全国际认证（CSA-STAR）​，以ISO/IEC 27001认证为基础，结合云端安全控制矩阵CCM（Cloud Control Matrix)的要求，运用BSI（British Standards Institution，英国标准协会）提供的成熟度模型和评估方法，为提供和使用云计算的组织

3.8. ISO 27001

• 3.8.1. 不属于强制性认证

3.9. ISO 29151

• 3.9.1. 不属于强制性认证，且有关个人数据保护的业界最佳实践框架还有很多

3.10. ISO 27018

• 3.10.1. 用于保护云上个人可识别信息（Personally Identif iable Information, PII）​，主要包括：制定专门针对云端隐私保护的条款，以及提供针对云上个人数据的安全控制措施