Web应用程序经常受到SQL注入攻击、XSS攻击、cc攻击、恶意IP攻击、网页篡改、机器扫描攻击等，这些攻击会影响应用程序的可用性，损害应用程序的安全性，消耗过多的资源，因此需要面向Web应用层的防护方案。
1. WAF部署及接入模式
WAF是Web应用防火墙的简称，支持主流Web漏洞检测和拦截、最新高危漏洞防护、虚拟补丁、防SQL注入、防cc攻击等，支持灵活的自定义防护策略。下图介绍了云平台中的WAF部署方式，使用时无须创建云主机与部署，直接通过CNAME域名解析的方式接入WAF服务，因此配置和使用起来更加简便，对后端源站所处的云平台和环境也没有限制。
在开始配置域名并接入应用前需要先在云平台中购买WAF服务，然后在域名管理中添加域名，需要配置Web应用的域名（如www.mumulab.com）及源站IP，配置完成后会生成一个CNAME域名，如abcd1234.waf.example.com。此时需要在域名DNS解析配置中将该域名（www.mumulab.com）按照CNAME类型解析到WAF分配的域名（abcd1234.waf.example.com）中，即可完成应用的接入。
图 通过CNAME域名将应用接入WAF
可以看到，将流量转发到服务器是通过指定IP来实现的，并没有限定服务器的位置，因此可以是任何一个云平台的服务器上的IP、IDC或本地服务器上的IP，只要是公网可以连通访问的IP即可。结合之前的“通过混合架构扩展本地能力”设计模式，可以将混合架构中的应用流量全部接入云平台WAF中，WAF会对请求进行拦截（Deny）或对记录（Log）进行过滤，再将流量转发至混合架构的后端服务节点，增强本地环境对Web应用层攻击的防护能力。
此种防护方式同样适用于在A云中接入WAF服务，将防护的IP指向B云中的服务器，通过多云部署安全策略和服务来增强对业务系统的安全防护能力。
WAF能够有效地应对应用层攻击，不过黑客在对业务进行DDoS攻击时，WAF无法对众多DDoS攻击进行拦截，会造成WAF防护失效，此时可在WAF之前部署DDoS防护，先拦截DDoS网络层攻击，再将网络层无法检测的攻击流量和过滤后的正常流量转发到WAF中进行检测，如下图所示。
图 WAF部署在DDoS防护之后
2. WAF中的攻击日志处理及误报处理
WAF对于各类应用层攻击有两种防护模式，拦截模式会对检测出有攻击的请求进行直接拦截，这种方式可能会出现一些误判，特别是在业务系统刚增加WAF防护时；告警模式在检测出有攻击的请求时不会进行拦截，只进行告警记录，需要增加人工判断。
图 WAF防护统计
在业务系统刚增加WAF时，为了减少误判，可先开启告警模式，无论是攻击流量还是正常流量，WAF都不会对其进行拦截，通过告警记录由人工判断哪些是严重的攻击问题，哪些是误判告警。对于误判告警可手动添加恢复，并设置后续不再将其作为风险项进行拦截。待系统运行稳定、WAF误判减少之后再开启拦截模式，此时再手动检测是否有误报情况并手动排除。
3. WAF报表及告警
WAF提供几乎实时的防护日志及统计报表，掌握当前应用请求数、攻击数、攻击IP、攻击类型等信息。图8-20展示了需要重点关注的攻击数据统计信息，提供按时间维度的攻击数量统计，可以通过对比得到当前遭受攻击的趋势；还包括遭受攻击的类型及严重程度的分类数据，高风险的攻击相比中低风险的攻击更应该受到重视；按照攻击类型分类可以自行判断其紧急程度，有的应用更关注信息泄露，有的应用更关注越权访问，根据这些统计信息可以下钻查看该类别的所有攻击记录的详细信息。
图 WAF安全报表
WAF安全报表统计用户全部域名，将在固定时间周期内的安全攻击报告发送到用户的邮箱。攻击告警统计用户全部域名，将在固定时间触发一定的攻击次数后向用户发送告警。源站状态监控（如果源站对WAF的探测IP进行处理，可能会造成误判告警）统计用户全部域名，按分钟级检测用户源站的连通性。下图所示为WAF全局告警设置。
- 安全报告：统计用户全部域名，将在固定时间周期内的安全攻击报告发送到用户的邮箱。
- 攻击告警通告：统计用户全部域名，将在固定时间触发一定的攻击次数后向用户发送告警。
- 源站状态监控：（如果源站对WAF的探测IP进行处理，可能会造成误告警）统计用户全部域名，按分钟级检测用户源站的连通性。
- 安全报告：统计用户全部域名，将在固定时间周期内的安全攻击报告发送到用户的邮箱。
- 攻击告警通告：统计用户全部域名，将在固定时间触发一定的攻击次数后向用户发送告警。
- 源站状态监控：（如果源站对WAF的探测IP进行处理，可能会造成误告警）统计用户全部域名，按分钟级检测用户源站的连通性。
图 WAF全局告警设置
4. 通过混合架构扩展安全防护能力
通过混合架构将所有流量切分到云端，通过云端安全服务进行过滤，再将正常业务流量切分到本地环境和云端环境后端进行处理，扩展本地环境的安全防护能力。云平台面向多租户提供计算、存储、安全防护等服务，相对而言遇到的各类挑战和攻击更多、更复杂，云服务商为保障平台中的用户业务安全、可靠，势必时刻投入精力来应对挑战和攻击，因此更能提供完善的安全解决方案及应对攻击和安全风险的项目经验。
私有化部署的本地环境在安全防护方面有以下痛点。
- 本地环境中无论是租用IDC还是自建服务器集群，都难以实现足够的安全防护能力。
- 本地环境安全防护设备更新换代慢，也难以应对层出不穷、升级换代的各类攻击。
- 本地数据中心除了计算资源扩展不便，安全防护能力也有限，本地环境采用硬件WAF、接入设备进行攻击检测与拦截，遇到大规模网络攻击时通过部署硬件安全服务难以及时响应。
混合架构业务还是运行在本地环境中，将所有流量切分到云端，通过云端安全服务进行过滤，再将正常业务流量切分到本地环境和云端环境后端进行处理。当遇到应用层攻击时，攻击流量也会分发到云平台，进行流量过滤后，攻击流量会被过滤阻断。在安全防护的角度上讲，云平台相当于本地环境的能力延展，即利用云平台种类丰富的安全产品、更强的防护能力和安全服务来对本地环境中的业务、资源、数据提供安全攻击拦截、安全风险识别服务，保护本地业务的安全。
5. 扩展：安全防护体系
业务暴露在互联网中，会受到很多的DDoS攻击、cc攻击、XSS攻击、SQL注入等，也经常看到有企业发生“删库跑路”事件，因此除了应对外部的安全攻击，还要防护内部的运维风险，加强工作人员的安全意识培训等。安全风险包括物理、终端、网络、应用、数据等各方面，不同行业、地区对业务的合规要求也非常多，总之一句话，有哪些安全风险就提供哪些安全防护方案。安全合规体系图如下图所示。
图 安全合规体系图
6. 扩展：安全责任共担模型
云厂商会尽力提供各种服务来保障用户业务、数据安全，并并非所有安全责任都由云厂商来承担，而是由用户和云厂商共同来承担，这就是安全责任共担模型。
云厂商有责任要保障底层云平台、提供的云资源的安全防护，而云平台中运行的业务属于用户，云平台也没有权力来访问用户运行的数据，所以这部分的安全责任由用户来承担。举个例子，云厂商好比售卖门锁的公司，提供了安全可靠、牢不可破的门锁，而用户把门钥匙随意丢弃、不注意保管，这样也不能保障大门的安全，所以大门的安全需要门锁厂商和用户共同来承担。在云平台中即便有非常可靠的安全保护措施，而用户将云主机、云数据库的密码设置的比较简单或暴露给其他人员，则会给整体的安全来带非常大的隐患。
云厂商提出安全责任共担模型并不是云厂商来推卸责任，而是云厂商和用户之间的责任界限是非常明确的，责任划分清晰。这样也有一定的好处，就是用户知道哪些安全责任需要自己来考虑，哪些安全责任是云厂商来承担的。
图 安全责任共担模型
7. 延伸思考
- 在混合架构中能通过云端WAF来防护本地环境，那能否采用朵云部署的方式来通过WAF互相进行安全防护？
8. 动手实验
- 选择一个云平台，创建WAF配置，并解析到一个Web网站中，将配置进行截图；
- 通过域名访问WAF配置中的域名，并模拟触发SQL注入，在浏览器中对拦截SQL注入的界面进行截图；
- 在WAF报表中查看触发的安全攻击信息，进行截图；
- 将操作的电脑IP地址加入到WAF黑名单中，再次访问该域名，在浏览器中查看效果并截图。