此外，该解决方案的好处还在于应用内部的东西流量不需通过外部网关层，这样可以从边缘到端点进行一站式防护。
2.4.2 Istio与WAF结合的深度防护
WAF作为抵御常见Web攻击的主流安全产品，可以有效对Web流量进行深度防护，并且随着云原生化概念的普及，国内外安全厂商的容器化WAF产品也在迅速落地，未来容器化WAF与Istio的结合将会在很大程度上提升微服务安全。
根据近期市场调研，已有几家公司有了各自的容器化WAF解决方案。以其中一款方案为例，其设计如图6所示，该方案主要运用了Envoy的过滤器机制（Filter），通过外部授权HTTP过滤器（External Authorization HTTP Filter）可以将流经业务容器的东西/南北向流量引流至WAF容器，从而阻断恶意请求，保护微服务的安全。
此方案的优势是对业务入侵较小，实现较为容易，且容器化WAF规模不会随用户业务更改而更改。但同时也有一些弊端，比如需要单独部署容器化WAF、Envoy引流模块的性能问题、引流方式对WAF处理的延迟等。
另一种解决方案是K8s WAF方案。该方案基于Istio实现，其中WAF被拆分为代理程序（Agent）和后端服务两部分，Agent程序作为Sidecar容器置于Pod的Envoy容器和业务容器间，该Sidecar的主要作用为启动一个反向代理，以便将外部请求流量代理至Pod外部的WAF后端服务中，如图7所示。该套方案的好处是无须关心外部请求如何路由至Pod，与Istio结合的理念更接近云原生化，实现了以单个服务为粒度的防护。但同时存在不足，例如，流量到达业务容器前经历了两跳，这在大规模并发场景下可能影响效率。
此外，由于Istio的数据平面为微服务应用安全防护提供了引擎，而数据平面默认采取Envoy作为Sidecar，因此Envoy自身的扩展性成为了安全厂商较为关心的问题。近些年Envoy也在不断提升着其适配性，例如Envoy提供Lua过滤器和Wasm过滤器，以便安全厂商将WAF的能力融入Envoy，从而对微服务应用进行防护。
3 无服务计算安全防护
3.1 无服务计算应用安全防护
针对Serverless应用安全访问控制，除了使用基于角色的访问控制，针对Serverless云计算模式带来的变化，还需要进行更深层次的防护，作者认为函数隔离及底层资源隔离是较为合适的防护方法。
3.1.1 函数隔离
函数间进行隔离可有效降低安全风险。一个函数即服务（Function as a Service，FaaS）应用通常由许多函数以既定的序列和逻辑组成，每个函数可以独立进行扩展、部署，但同时可能被攻破，如果安全团队没有对函数进行有效隔离，那么攻击者也可同时访问应用中的其他函数。再如随着应用设计的不断变化，这些函数更改了执行序列，从而使攻击者有机可乘并发起业务逻辑攻击，这些是FaaS产生的碎片化问题。正确的做法应当是将每个函数作为边界，使得安全控制粒度细化至函数级别，这对于创建能够长期保持安全的FaaS应用是非常必要的。
为了更好地将函数进行隔离，作者认为应当从以下4个方面进行考虑。
（1）不要过度依赖函数的调用序列，因为随着时间推移调用序列可能会改变。如果序列发生了变化，要进行相应的安全审查。
（2）每个函数都应当将任何事件输入视为不受信任的源，并同时对输入进行安全校验。
（3）开发标准化的通用安全库，并强制每个函数使用。
（4）使用FaaS平台提供的函数隔离机制，例如AWS Lambda采用亚马逊弹性计算云（Elastic Compute Cloud，EC2）模型和安全容器Firecracker模型机制进行隔离。
3.1.2 底层资源隔离
仅仅对函数层面进行访问控制是不够的，例如攻击者仍可以利用函数运行时环境的脆弱性以获取服务端的运行权限，从而进行滥用，为了预防上述场景的发生，我们应当从底层进行资源隔离，例如可通过开源安全容器Kata Container从上至下进行防护，再如可通过K8s的网络策略（Network Policy）实现由左至右的网络层面隔离。
3.2 无服务计算平台安全防护
针对无服务计算平台安全防护，可以考虑通过以下几种方式进行相应缓解。
3.2.1 使用云厂商提供的存储最佳实践
为了尽量避免用户在使用云厂商提供的Serverless平台时因不安全的错误配置造成数据泄露的风险，主流云厂商均提供了相应的存储最佳实践供各位开发者参考，例如How to secure AWS S3 Resources、Azure Storage Security Guide、Best Practices for Google Cloud Storage等。