企业官网建设流程全解析

1. 零信任与无边界网络架构

1.1. 内部员工也并不是完全值得信任的，内网也不是值得信任的安全域

• 1.1.1. 过去我们认为内部员工是可信任的，但实际并非如此，内部原因造成的数据泄露已频频出现

• 1.1.2. 过去我们认为内部网络都是可信任的，但黑客只要找到一个入口，就能在内网漫游

1.2. 不信任企业内部和外部的任何人/系统/设备，需基于身份认证和授权，执行以身份为中心的访问控制和资产保护

1.3. 无边界网络

• 1.3.1. 安全域就是用路由表、交换机ACL、防火墙所包围起来的一个逻辑上的网络区域

• 1.3.2. 所谓边界，就是指一个安全域跟另一个安全域的边界，具体来说，就是用路由表、交换机ACL、防火墙进行控制的分界线

• 1.3.3. 零信任架构以身份为中心，员工能否访问相应的业务，不是取决于他所接入的网络是否为公司办公网络，而是他的身份是否具有访问对应业务的权限

• 1.3.4. 办公场地的网络就变为无边界无特权的办公网络，员工访问生产网络，可以直接通过外网访问，即使员工位于办公建筑内

• 1.3.5. 对于生产网络，由于采用了统一的接入网关（对Google来说，就是GFE, Google Front-End）​，不再需要专门的防火墙

• 1.3.5.1. 网关后面的服务器只需要配置内网地址（不配置外网地址）​，天然就无法直接对外网提供服务，而只能被接入网关所接管

• 1.3.6. 在无边界网络的架构设计中，使用统一接入网关取代边界防火墙，可让员工或用户随时随地安全接入

1.4. 对人的身份认证

• 1.4.1. 不能信任企业内部和外部的任何人，首先就需要身份认证，确认访问者的身份

• 1.4.2. 实现身份认证依靠的是企业的SSO系统，为了确保身份的安全性，SSO的认证机制需要具备防止钓鱼攻击的能力

• 1.4.3. 如果采用静态口令，则口令的泄露就会导致身份被冒用

• 1.4.4. 企业在内网较多采用动态口令机制（TOTP）​

• 1.4.5. 如果在外网使用TOTP，仍有可能遭受实时的钓鱼攻击（动态口令通常在30秒或60秒内有效）​

• 1.4.6. 企业的SSO系统就需要改用更安全的双因子身份认证机制，推荐U2F​

• 1.4.7. Universal 2nd Factor，通用双因子身份认证，是由Google和Yubico共同推出的开放认证标准

1.5. 对设备的身份认证

• 1.5.1. 不能信任企业内部和外部的任何设备，就需要对设备进行认证和接入控制

• 1.5.2. 对设备的认证主要采用数字证书，设备的数字证书存储在硬件或软件的TPM（可信平台模块）​，或操作系统证书管理器中

1.6. 最小授权原则

• 1.6.1. 采用最小权限原则，在应用层赋予用户完成特定工作所需的最小权限

• 1.6.2. 授权机制通过IAM（身份与访问管理）进行，整合了SSO认证、授权、审计几大功能

• 1.6.3. 授权可以基于角色授权​，也可以基于属性进行授权

1.7. 设备准入控制

• 1.7.1. 终端设备，也就是员工办公使用到的电脑、笔记本电脑、手机等终端

• 1.7.2. 只允许公司配发的电脑注册登记

• 1.7.3. 只允许可信任终端接入办公网络，否则接入修复区

• 1.7.4. 对生产网络中的服务器来说，Google采用了基于定制安全芯片的信任链传递机制，其中安全芯片作为信任链的根，依次对BIOS、BootLoader、操作系统内核进行签名，确保它们未被篡改，也就是说操作系统是可信的

• 1.7.5. 如果是没有安全芯片的设备，就可以视为外来设备，拒绝接入网络

• 1.7.6. 信任机制不一定非得来自硬件芯片，在硬件条件不具备的情况下，适当降级，采取软件的手段，如导入操作系统的自颁发证书、自定义安全组件、服务器设备MAC登记等，都可以用于生产网络中设备的准入控制

1.8. 应用访问控制

• 1.8.1. 通过应用网关接管后端所有应用、资源、服务器的访问流量，只有先在应用网关系统中登记才能对外提供服务

• 1.8.2. 只有通过身份认证与终端可信的用户才可以访问隐藏在应用访问网关之后的业务服务

• 1.8.3. Google的应用网关，首先实现了Web的代理（称为GFE, Google Front-End）​，提供Web反向代理、负载均衡、TLS终止等功能；后又进行了扩展，支持了SSH等非Web的协议，统称为访问网关（Access Proxy）​

• 1.8.4. Google的访问网关支持Web业务和非Web业务，其中支持Web业务的部分为GFE

1.9. 无边界网络减少了防火墙的部署和使用

• 1.9.1. 统一接入和访问控制，让内部服务隐藏在网关后面，只使用内部地址，构建了安全的虚拟边界

• 1.9.2. 少量的防火墙仅用于强化对后台核心数据的访问控制，例如保护数据库等存储基础设施，以及满足合规要求

• 1.9.3. 不使用VPN，员工在外也可以像在办公室一样访问办公业务，极大地提升了员工办公体验

2. 统一HTTPS接入与安全防御

2.1. 开源的应用网关Janusec Application Gateway

2.2. Janusec是基于Golang打造的应用安全网关，具备WAF（Web应用防火墙）功能及组合策略配置，支持HTTP2和HTTPS（符合PCI-DSS认证要求）​，无需在目标服务器部署组件（Agent）​，私钥加密存储在数据库，提供负载均衡和统一的Web化管理入口

2.3. 应用网关

• 2.3.1. 采用统一的HTTPS接入（TLS加密通信）​，统一管理证书和私钥

• 2.3.2. 应用网关的核心功能是反向代理（Reverse Proxy）​，用于统一接入，反向代理到后端真实的Web业务，避免直接路由到生产环境

• 2.3.3. 反向代理即转发用户请求到内部真实服务器（使用内部地址）并将结果返回给用户，对用户隐藏内部地址

• 2.3.4. 网关到业务的部分对用户而言是看不见的

• 2.3.5. 应用网关作为统一接入的基础设施，需要具备HTTPS支持，特别是当前HTTPS已基本普及的情况下，如果不启用HTTPS，则用户的访问很容易被第三方劫持，用于加塞广告等行为

2.4. 安全防护

• 2.4.1. 网关内置Web应用防火墙、CC防护

• 2.4.2. 内置WAF使用Google RE2正则引擎，可拦截典型的Web漏洞如SQL注入、XSS（跨站脚本）​、敏感信息泄露、WebShell上传或连接动作、路径遍历等

• 2.4.3. 在CC防御方面，基于访问频率和访问统计，对同一来源，在设定的单位时间内，访问次数超过设定的阈值，就触发拦截或出验证码等机制

2.5. 数据保护

• 2.5.1. 对私钥采取加密措施

• 2.5.2. 各大主流Web服务器在配置证书的时候，均使用文件形式的证书及私钥文件，在配置文件中设置两个证书文件的路径

• 2.5.3. Janusec把证书统一管理起来，采用AES256加密保护私钥，不再将证书文件、私钥文件直接明文存放在服务器某个目录下，可有效防止黑客窃取私钥

• 2.5.4. 可以让网关管理人员统一申请和配置证书，这样业务团队的人员不用接触证书文件就可以自助启用HTTPS

2.6. 前端负载均衡与后端负载均衡

• 2.6.1. Janusec支持多网关节点部署作为前端的负载均衡，可通过DNS或GSLB（Global Server Load Balance，全局负载均衡）的DNS调度，将不同地域的请求引导到不同的网关节点

• 2.6.2. 当后端业务存在多台服务器时，也会随机选择后端服务器进行负载均衡

2.7. Web化后台管理

• 2.7.1. 后台管理模块采用Angular 5（或以上版本）开发，在其身份认证环节，采用了前端慢速加盐散列运算，不传输原始口令，后端在前端散列结果的基础上继续执行加盐散列操作，有效避免了口令泄露、撞库等风险

2.8. 多检查点

• 2.8.1. WAF模块对同一个请求，可以在从请求到响应的过程中设置多个检查点，组合检测

• 2.8.2. 某一条规则在请求（Request）中设置了检查点，同时还可以在该请求的其他位置或响应（Response）中设置检查点

2.9. 恶意域名指向拦截

• 2.9.1. 网关拦截未登记域名

• 2.9.2. 当非法域名指向过来的时候，应该拒绝响应，Janusec只响应已登记的域名，未登记的域名会拒绝访问

2.10. HTTPS证书质量

• 2.10.1. 不是所有的HTTPS配置出来都是安全的，错误的配置、算法的选用均有可能让你的业务踩坑，如SSL 1.0, SSL 2.0, SSL 3.0以及TLS 1.0均已出现漏洞

• 2.10.2. 网关默认就需要启用安全保障

• 2.10.3. Janusec针对HTTPS证书质量，默认已按最佳实践设置

2.11. 任意后端Web服务器适配

• 2.11.1. WAF模块不需要在被保护的目标服务器上安装任何组件或私有Agent，后端业务可使用任何类型的Web服务器（包括但不限于Apache、Nginx、IIS、NodeJS、Resin等）​