API安全防御建设中的难点坑点汇总

81 阅读 0 评论 54 点赞

我是靠谱客的博主文艺香菇，最近开发中收集的这篇文章主要介绍API安全防御建设中的难点坑点汇总，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

(一) 场景变化带来的防护难点

云原生关注快速开发和部署，这种特性要求进行防护模式的转变，从基于边界的防护模式迁移到更接近基于资源属性和元数据的动态工作负载的防护模式，从而有效识别并保护工作负载，以满足云原生技术架构的独特属性和应用程序的规模需求，同时适应不断变化的新型安全风险。

应用架构发展的 6 个过程中，传统防护手段主要基于硬件形态部署，考虑的都是南北向的流量，而在应用技术架构高速发展的过程中，难以适应东西向、软件化、服务化的场景。

(二) 新技术、新业务带来的防护难点

API 当前主要基于 HTTP/S协议，为此传统的 Web 攻击防护手段仍能在一定程度上起到防御作用。比如攻击者针对 API接口的参数进行 SQL注入，传统的基于规则的检测手法仍然有效。考虑到 API交互数据敏感性及提供服务的敏感性，API安全防护方案应该在传统安全的基础上更加关注与数据安全、权限安全及用户行为安全。

新的安全防护模型在检测传统 Web攻击同时，还应检测与预警

API传输中的敏感数据；建立基于用户访问行为的用户画像或行为模型；检测与预警 API未认证访问、弱口令登录、未授权访问、异常访问行为等。此外，应具有基于自动化发现并可视化展示及管理 API能力，及时发现与预警僵尸、未知等异常 API，以及避免在 API设计之初由于缺乏统一规范导致后期大量 API 无法统一管理而引入的安全问题。新的安全防护模型还应具有高兼容性，在具体实践时不仅兼顾用户业务多样化，还应在不干扰业务的前提下，通过高度可自定义及自学习等手段高度融合到用户业务中。

(三) API格式的多样性、复杂性面临的防护难点

在 API业务发展历程中，协议从 HTTP1.0发展到 HTTP3.0，为了适应各种业务场景，API格式主要包含 REST、SOAP、GRPC、GraphQL、用户自定义格式等。

安全的具体实践一直与业务紧密联合，针对协议、格式的快速发展，传统防护思路难以适应协议、格式的快速变化，为此，与 API技术相适应的网络安全方案也应考虑其作为数据传输载体及服务接口的本质。

(四) 传统防护手段无法应对 API安全风险

传统业务特点

业务、应用被 Web 化，业务系统部署在可公共访问的 Web服务上，有着清晰的物理和逻辑边界；此时主要是以解决 Web应用安全为主，整体解决方案以端、网、云的纵深防护体系为主。

未来业务发展趋势

1）随着移动化、数字化业务的使用，业务层面主要以多层架构为主，新的架构设计过程如下：

第一步，结合现实情况，将系统划分成多个层次。第二步，确定层与层之间的关系，将层与层之间的交互接口梳理

出来。

第三步，将功能相近的接口划归到一个模块，确保模块高内聚，对外低耦合。

第四步，在此基础上进一步明确接口的参数列表。

为了更好地适应泛终端场景，同时为了解决交互的便利性，所有业务通信都被设计成 API化。

2）按照这套方法论来进行架构设计，最理想的情况是将业务系统分成多层。首先应该先切在业务和领域之间，即通过 API把两边解耦。交互和业务跟用户关联度高，经常随需求变化而改动，而领域和资源相对比较稳定。

3）考虑到要完成某些业务功能，系统可能需要调用外部系统协同完成，为了保证领域层相对稳定，我们需要隔绝外部系统或数据持久层变化带来的影响，因此应该切在领域和资源之间。

4）考虑到同样的一个业务可能会有多套界面，例如有 Web版、

桌面版、移动版等，为了提高重用率，隔离变更，那接下来要把交互和业务切开。

随着云应用的发展、基础设施必须满足快速、灵活的扩展，同时不影响现有业务，因此出现了微服务化、服务网格化的趋势。

传统的边界防护模型难以应对新的安全风险防护模型发生变化：传统基于边界的防护模型已不能完全满足云

原生中 API的安全需求，云原生关注快速开发和部署，这种特性要求进行防护模式的转变，从基于边界的防护模式迁移到更接近基于资源属性和元数据的动态工作负载及 API暴露面的防护模式，从而有效识别并保护工作负载，以满足云原生技术架构的独特属性和应用程序的规模需求，同时适应不断变化的新型安全风险。

防护维度发生变化：随着微服务的增多，暴露的端口和 API接口数量也急剧增加，进而扩大了攻击面，且微服务间的网络流量多为东西向流量，网络安全防护维度发生了改变。微服务通信依赖于 API，随着业务规模的增大，微服务 API数量激增，恶意的 API 操作可能会引发数据泄漏、越权访问、中间人攻击、注入攻击、拒绝服务等风险；最后，微服务治理框架采用了大量开源组件，会引入框架自身的漏洞以及开源治理的风险。

API安全防护体系变成全新的形态传统业务承载体是以网络通信和网络协议为基础，通信载体以路由、交换为主体；安全防护体系的技术基础是以网络协议为主体，以端、网、云为边界的纵深防御体系。在数据安全领域，以 API为业务载体，API等同于传统业务场景下的网络协议。

在以 API为载体的业务场景下，因为 API直通业务系统内部，因此系统的暴露面被无限放大，攻击手段也随之发生变化，因此传统的安全防护体系以及防护技术无法解决新的安全问题。

网络安全时代，攻击者以破坏为主；数据安全时代，攻击者以窃取和盗取数据为主，因此安全的可视化、行为可视化、API之间业务关系可视化、API资产可视化是需要解决的主要问题。无论是在南北向还是东西向要缩小 API暴露面、关闭攻击面，必须以上做到 4 个可视化。由于微服务和服务网格化的特点，要想解决以上问题，安全要做到和业务紧密结合，同时在部署形式上又要能够解耦。因此只能通过内生安全的形式去解决数据安全领域中的 API安全问题。