API技术的出现使前端界面与后端服务器的数据交互更加便捷，因此被开发者广泛使用。伴随着API使用的指数级增长，其潜在的数据安全与个人信息泄露风险，也成为了企业亟需解决的问题。所以，在云原生时代下，守护好企业API通信至关重要。
API的安全风险
API的攻击面主要有以下几点：
1. 传统WEB攻击：API承担了WEB应用前后端的通信，API出现RCE、SQL注入等WEB漏洞属于常态。
2. API协议攻击：API除了plain HTTP、REST等可复用传统安全能力的协议之外，仍有诸多协议标准，如GRPC、Dubbo、GraphQL等，其攻击面、漏洞测试方式与入侵检测方式，与传统WEB安全有着明显差异。在复杂业务架构中，WEB HTTP API只是冰山一角，这些新兴的API通信标准在后端占比越来越重。
3. 数据安全：API承载了应用各组件间数据的流动。在数据安全领域，我们需要关注API携带了哪些敏感数据、对谁开放、对方如何使用这些数据等问题。企业被爆出数据泄露事件屡见不鲜，除了数据库被攻陷之外，其中很大部分是导致携带敏感数据的API鉴权出问题，导致外部攻击者通过不断访问API拖取敏感数据。
4. 业务安全：从API视角解决爬虫、撞库、刷单、薅羊毛等业务安全问题，尤其是2C端app的API管控。
使用WAF/防火墙做自动化API防护？
使用WAF保护API的问题有很多，一个核心原因是WAF要求高性能串行，这就导致了绝大部分WAF的防御逻辑是基于单个会话阻断明确的攻击特征。即使现在一些WAF使用了语义分析、上下文分析甚至机器学习，这些要么是算法过于简单而无法解决长时间窗口的行为分析，要么是企业承担了极大的计算成本去换计算效率。
这就是所谓串行设备“性能”与“智能”的冲突。
大数据分析+旁路阻断——API安全防护的终局
在实际业务中，一次Web端的HTTP调用，后端可能是几十上百次API调用，这意味着API串行设备所要求的延时更小。在更加苛刻的条件下，在串行设备中内置复杂的计算逻辑不现实，而简单的单包分析又解决不了API的异常调用、爬数据、拖数据问题。
在我们的解决方案中，我们让串行设备(API网关)中仅保留简单粗暴的过滤模式，而通过旁路实时计算平台来承载更多的复杂计算任务。
在旁路大数据分析平台中，模型可以基于历史行为与当前一段时间内的多次请求，动态判定出数据泄露行为，并将攻击源IP和API路径下发给API网关，从而完成旁路阻断。
除此之外，我们可以在控制层的运维平台，通过逻辑编排(触发器-逻辑判断条件-下发策略)的方式来管理我们的旁路阻断逻辑，同时通过插件的方式赋予API网关阻断能力，达到和实时计算平台的联动。
云原生环境下的API攻击面
云原生环境是一个完全API化的场景，API几乎承载了所有的服务间调用，需要关注以下攻击面：
1. 基础设施层API安全（容器集群、VM底层的组件通信）
2. 应用层API安全（应用代码业务逻辑涉及的API）
3. SaaS化云产品API（云数据库、中间件、消息服务、云计算平台等）
4. 云平台运维与管控API（云平台管理员的人为操作与机器操作）
在绝大多数云平台中，3和4已经具备了完善的日志供安全场景分析。我们需要关注的是应用本身逻辑与基础设施的复杂性导致的安全问题。在容器集群中，资源模型和网络模型与传统IDC大相径庭，一个典型的问题是容器集群的东西向流量审计。
容器集群南北向API防护方案
容器集群/微服务东西向API通信防护方案
东西向流量管控是容器安全厂商在完成了基础的镜像安全、运行时安全之后的下一站。
仅在Ingress层做管控，难以捕获东西向流量，容器集群的东西向最细粒度为Pod级别，当两个Pod在同一个Node（linux服务器）之中时，其内部东西向通信难以通过统一接入层来管控。
目前业内主流方法有两种：
1. 借助EDR的主机Agent在Node内核层基于EBPF做包过滤(Calico、一些容器安全厂商)，其弱点是只能进行四层的管控，七层的报文还原及审计开销大。
2. 将7层网关以Sidecar container的模式下发到每个Pod(Istio+envoy)。其中云原生API网关envoy承担七层流量代理作用，而Istio做上层控制及策略下发。目前主流的API网关厂商如APISIX也纷纷投入Mesh化的Pod级别Proxy研发。
在实际生产环境中，我们倾向于第二种方案，针对原生Istio+API网关(proxy)的架构，我们同样可以基于API网关插件的方式来完成7层流量的采集与阻断。
从“戴口罩”到“打疫苗”
在复杂的云平台架构下，有效的安全方案具有强烈的侵入性，“先做业务再做安全”的思路会导致后期安全项目落地成本极高。我们注意到，目前企业针对传统应用架构的安全防护手段多为“添加防护层”的方式。而云原生架构下的安全强调“内生”，即在应用架构设计之初就考虑安全设计，安全管理者需要潜入IaaS的世界，通过“打疫苗”的方式尽可能缩减未来可能出现的安全风险。
API技术的出现使前端界面与后端服务器的数据交互更加便捷，因此被开发者广泛使用。伴随着API使用的指数级增长，其潜在的数据安全与个人信息泄露风险，也成为了企业亟需解决的问题。所以，在云原生时代下，守护好企业API通信至关重要。
API的安全风险
API的攻击面主要有以下几点：
1. 传统WEB攻击：API承担了WEB应用前后端的通信，API出现RCE、SQL注入等WEB漏洞属于常态。
2. API协议攻击：API除了plain HTTP、REST等可复用传统安全能力的协议之外，仍有诸多协议标准，如GRPC、Dubbo、GraphQL等，其攻击面、漏洞测试方式与入侵检测方式，与传统WEB安全有着明显差异。在复杂业务架构中，WEB HTTP API只是冰山一角，这些新兴的API通信标准在后端占比越来越重。
3. 数据安全：API承载了应用各组件间数据的流动。在数据安全领域，我们需要关注API携带了哪些敏感数据、对谁开放、对方如何使用这些数据等问题。企业被爆出数据泄露事件屡见不鲜，除了数据库被攻陷之外，其中很大部分是导致携带敏感数据的API鉴权出问题，导致外部攻击者通过不断访问API拖取敏感数据。
4. 业务安全：从API视角解决爬虫、撞库、刷单、薅羊毛等业务安全问题，尤其是2C端app的API管控。
使用WAF/防火墙做自动化API防护？
使用WAF保护API的问题有很多，一个核心原因是WAF要求高性能串行，这就导致了绝大部分WAF的防御逻辑是基于单个会话阻断明确的攻击特征。即使现在一些WAF使用了语义分析、上下文分析甚至机器学习，这些要么是算法过于简单而无法解决长时间窗口的行为分析，要么是企业承担了极大的计算成本去换计算效率。
这就是所谓串行设备“性能”与“智能”的冲突。
大数据分析+旁路阻断——API安全防护的终局
在实际业务中，一次Web端的HTTP调用，后端可能是几十上百次API调用，这意味着API串行设备所要求的延时更小。在更加苛刻的条件下，在串行设备中内置复杂的计算逻辑不现实，而简单的单包分析又解决不了API的异常调用、爬数据、拖数据问题。
在我们的解决方案中，我们让串行设备(API网关)中仅保留简单粗暴的过滤模式，而通过旁路实时计算平台来承载更多的复杂计算任务。
在旁路大数据分析平台中，模型可以基于历史行为与当前一段时间内的多次请求，动态判定出数据泄露行为，并将攻击源IP和API路径下发给API网关，从而完成旁路阻断。
除此之外，我们可以在控制层的运维平台，通过逻辑编排(触发器-逻辑判断条件-下发策略)的方式来管理我们的旁路阻断逻辑，同时通过插件的方式赋予API网关阻断能力，达到和实时计算平台的联动。
云原生环境下的API攻击面
云原生环境是一个完全API化的场景，API几乎承载了所有的服务间调用，需要关注以下攻击面：
1. 基础设施层API安全（容器集群、VM底层的组件通信）
2. 应用层API安全（应用代码业务逻辑涉及的API）
3. SaaS化云产品API（云数据库、中间件、消息服务、云计算平台等）
4. 云平台运维与管控API（云平台管理员的人为操作与机器操作）
在绝大多数云平台中，3和4已经具备了完善的日志供安全场景分析。我们需要关注的是应用本身逻辑与基础设施的复杂性导致的安全问题。在容器集群中，资源模型和网络模型与传统IDC大相径庭，一个典型的问题是容器集群的东西向流量审计。
容器集群南北向API防护方案
容器集群/微服务东西向API通信防护方案
东西向流量管控是容器安全厂商在完成了基础的镜像安全、运行时安全之后的下一站。
仅在Ingress层做管控，难以捕获东西向流量，容器集群的东西向最细粒度为Pod级别，当两个Pod在同一个Node（linux服务器）之中时，其内部东西向通信难以通过统一接入层来管控。
目前业内主流方法有两种：
1. 借助EDR的主机Agent在Node内核层基于EBPF做包过滤(Calico、一些容器安全厂商)，其弱点是只能进行四层的管控，七层的报文还原及审计开销大。
2. 将7层网关以Sidecar container的模式下发到每个Pod(Istio+envoy)。其中云原生API网关envoy承担七层流量代理作用，而Istio做上层控制及策略下发。目前主流的API网关厂商如APISIX也纷纷投入Mesh化的Pod级别Proxy研发。
在实际生产环境中，我们倾向于第二种方案，针对原生Istio+API网关(proxy)的架构，我们同样可以基于API网关插件的方式来完成7层流量的采集与阻断。
从“戴口罩”到“打疫苗”
在复杂的云平台架构下，有效的安全方案具有强烈的侵入性，“先做业务再做安全”的思路会导致后期安全项目落地成本极高。我们注意到，目前企业针对传统应用架构的安全防护手段多为“添加防护层”的方式。而云原生架构下的安全强调“内生”，即在应用架构设计之初就考虑安全设计，安全管理者需要潜入IaaS的世界，通过“打疫苗”的方式尽可能缩减未来可能出现的安全风险。