企业官网建设流程全解析

1. 强化产品安全

1.1. 网络部署架构

• 1.1.1. 产品在发布或部署时，一个良好的网络安全域、接入基础设施及访问控制策略，可以为产品提供额外的安全防御能力，降低产品面临的各种风险

• 1.1.2. 推荐采用无边界网络以及分布式的统一接入应用网关、尽可能少的安全域划分以及尽可能少的防火墙使用

• 1.1.3. 针对互联网数据中心（IDC）​，原则上建议大部分服务器都不配置外网网卡，而是通过统一接入应用网关反向代理，防止误将高危服务开放到互联网

• 1.1.3.1. 反向代理，是相对于正向代理而言的

• 1.1.3.2. 正向代理需要知道目标所在地址并“路由”过去，而反向代理不需要知道目标地址，可用于隐藏目标并提升安全性

• 1.1.4. 合适的网络分区可以让业务选择最合适的网络部署区域，比如敏感数据存放于生产网络敏感区，业务服务器只使用内网IP地址，通过接入网关对外服务

• 1.1.4.1. 接入网关可以跟安全防御基础设施（如WAF）集成，为产品提供安全防御能力

• 1.1.4.2. 应用网关解密的HTTPS流量也可以作为安全防御以及流量审计的输入

• 1.1.5. 业务服务器不直接对外提供服务，避免了高危服务直接对外开放的风险

1.2. 主机层安全

• 1.2.1. 在IDC（互联网数据中心）模式下，服务器通过双网卡机制同时连接内网和外网，但这种模式带来了一个非常严重的问题，那就是经常有业务会误将高危服务（如数据库、缓存等）直接开放到外网去了

• 1.2.2. 各种网络服务的默认配置是监听所有网卡的，并没有按照最小化的监听范围进行配置

• 1.2.3. 按照默认设置，只要服务一启动，就会向互联网开放

• 1.2.4. 由于高危服务直接对外带来的高风险性，通常还会将高危服务直接对外定性为违规行为，并对实施人员加以处罚

• 1.2.5. 这种机制依赖众多的部署人员的安全意识，特别是很多公司并未实施开发、运维人员的职责分离，参与部署发布的人员数量众多

• 1.2.5.1. 往往需要强化宣传教育（​“关闭不必要的服务/端口，尽量只对外暴露Web端口，避免高危服务对外开放”​）​，安排专人去发现误开高危服务到外网的情况，并推动修复，从而导致投入的人力成本很高

• 1.2.5.2. 开发、运维人员的职责分离，就是开发、运维职责由不同的人员或团队担任，开发人员不管部署发布，运维人员才能在生产环境部署发布

• 1.2.6. 高危服务开放外网加上弱口令，成为黑客进入企业内网的重要方式

• 1.2.7. 利用统一接入网关，就可以默认收回业务服务器的外网权限，正常情况下，业务服务器不再配置外网网卡，不再分配外网IP地址，也就不存在误开高危服务到外网的情况了

• 1.2.8. 如果一项政策，需要非特定的任何员工遵从，那么一定会有员工不遵从

• 1.2.8.1. 接入网关的方案可以让员工不再拥有犯错的机会

• 1.2.9. 统一接入网关充当了所有业务的前置反向代理，只有配置之后才能对外开放，而所有的高危服务默认都不会在网关上配置，保障了高危服务仅在内网开放，极大地降低了攻击面

• 1.2.10. 统一接入网关可以添加安全特性，比如集成WAF（Web应用防火墙）​，拦截入侵动作

• 1.2.11. 高危服务所使用的开源组件漏洞，也是黑客进入企业内网的重要方式

• 1.2.11.1. 使用来源可信、版本安全、经过评估的开源组件

• 1.2.11.2. 建设企业内部的组件源，且内部源的组件经过过滤

• 1.2.11.3. 业务在使用时，就不会下载到已知的高风险组件或恶意组件

• 1.2.12. 推荐将通用组件云化，并构建自动化运维能力，通过浏览器来执行日常运维操作，而不是直接登录到服务器

• 1.2.12.1. 通用组件云化，也就是常见的通用组件如Web服务器、数据服务等，采用云服务加上自动分配的模式，让业务不用自行安装，动动鼠标就可以申请使用，而不是每个业务都自行安装配置

• 1.2.12.2. 在提高效率的同时，也可以统一执行安全加固

• 1.2.13. 为了最大限度地降低主机层所面临的入侵风险，部署HIDS（基于主机的入侵检测系统）​，检测恶意文件、暴力破解等恶意行为，还可以基于彩虹表机制预先检测弱口令（即预先计算常见弱口令的散列值，并与系统中存储的散列值进行比对，以发现风险）​

1.3. 应用层安全

• 1.3.1. 在身份认证方面，所有非公开的Web应用都应具备身份认证机制

• 1.3.1.1. SSO单点登录系统

• 1.3.1.2. 在SSO的具体实现上，推荐不上传用户的原始口令，而是使用前端慢速加盐散列，强化口令隐私保护与防撞库能力

• 1.3.1.3. 在具备应用网关的条件下，可以让应用网关自身集成SSO单点登录系统，这样就可以不依赖于各业务自身跟SSO的集成

• 1.3.1.4. 可以在接入网关上为其中的部分业务启用单独的超时退出机制，防止登录凭据被黑客窃取后用于登录敏感业务

• 1.3.2. 在授权方面，首选在业务自身做好权限最小化控制，以及合理的职责分离，防止出现越权操作风险

• 1.3.2.1. 如果无法用属性来识别，比如员工A访问某应用的普通权限，可以基于角色进行授权，需要将员工A纳入普通用户角色，或者在授权表中添加一项授权记录

• 1.3.2.2. 对于不直接面向用户的内部业务，也可以构建独立于业务之外的权限管理系统，简化业务的权限管理

• 1.3.2.3. 访问控制方面，通常需要应用接口具备防止批量拉取的监控、告警或阻断能力，但在各应用本身实现却不太现实，这一需求可以跟防止CC攻击结合起来，在接入网关集成的WAF上统一配置，或者在API网关上统一配置

• 1.3.2.4. 针对上传WebShell的控制，除了在应用本身限定上传文件类型之外，还可以借助WAF等防御基础设施，检测上传的内容

• 1.3.2.5. 在服务器的安全配置上，应配置用户上传目录仅限静态解析（如Nginx）而不是传递给应用服务器（PHP/Java等）​

• 1.3.2.6. 审计方面，可通过应用层接口，将敏感业务的操作日志实时上传到业务外的日志系统，且无法从业务自身删除

1.3.2.6.1. 业务本身并不持有或使用日志系统的数据库账号

1.4. 数据层安全

• 1.4.1. 数据层，建议将数据库视为“应当统一管理的基础设施”​，尽量封装为数据服务，构建数据中台

• 1.4.2. 在对数据进行保护时，经常使用到加密存储、加密传输、脱敏等概念

• 1.4.3. 先看加密存储，如果加密只在应用自身来完成，那么黑客入侵后有可能获取到解密的密钥，从而导致数据泄露并可被解密

• 1.4.3.1. 为了强化密钥安全，我们可以借助KMS（密钥管理系统）来实现加密解密操作

• 1.4.4. 在加密传输方面，首选使用全站HTTPS（就是所有的业务全部启用HTTPS传输）​

• 1.4.5. 在证书保护方面，由于各业务自行采购、配置数字证书，首先就会遇到重复采购的问题

• 1.4.5.1. 除非是具备统一的运维团队，统一管理运维操作以及证书采购，否则就会遇到重复采购数字证书的问题

• 1.4.6. 数字证书应该在统一的接入网关这里集中管理，并可将网关作为TLS End（即HTTPS的终止点）​，以便针对私钥执行特别的加密保护

• 1.4.6.1. 在统一启用全站HTTPS的同时，防止私钥泄露

• 1.4.6.2. 在接入网关上，可以启用安全传输质量保障，默认就使用满足合规要求的TLS传输协议，禁用SSL 1.0～SSL 3.0和TLS1.0～TLS 1.1，而直接使用TLS 1.2及以上版本，以及启用加密算法限制，默认只允许使用安全的加密算法

• 1.4.6.3. 业务上线的时候，如果当前网关已经具备了适用于其域名的证书（典型的场景是已经采购了通配型证书）​，就可以不用采购新证书，直接选择已有的数字证书即可

• 1.4.7. 脱敏方面，一方面可以在应用自身完成脱敏，另一方面，也可以借助外部基础设施的能力执行脱敏，这就需要使用到API网关了

• 1.4.7.1. 每一个数据服务在接入API网关的时候，采用定制化脱敏策略，并按照脱敏标准进行脱敏

2. 隐私保护领域

2.1. 不能直接对第三方提供包含用户个人隐私的数据集，如业务必需，应确保用户知情，尽到告知义务（个人信息被收集和处理的目的、使用的业务及产品范围、存储期限、用户权利等）并获取用户有效同意

2.2. 不采用一揽子式同意及隐私政策，即不能采用这种模式：只要用户勾选一个同意选项，就视为用户同意该公司的任意产品/服务均可以收集和处理个人数据

2.3. 不要替用户默认勾选同意选项

2.4. 可以构建增强隐私保护的基础设施，如K-匿名、差分隐私等基础设施服务，这部分可称之为隐私增强技术

2.5. 当业务不得不需要以数据集的方式对外提供时，先经过K-匿名处理后，再提供

2.6. 当涉及个人隐私的数据统计接口需要对其他业务或外部开放，对统计结果执行差分隐私保护，添加噪声后再对外提供

3. 物理和环境层的安全基础设施

3.1. 通常不由安全团队负责，而往往是由行政、物业等部门负责

3.2. 门禁以及出入登记

3.3. 监控摄像

3.4. 红外告警