您当前的位置: 首页 >  安全

securitypaper

暂无认证

  • 0浏览

    0关注

    219博文

    0收益

  • 0浏览

    0点赞

    0打赏

    0留言

私信
关注
热门博文

API从1.0到3.0发展过程中对信息安全带来了哪些影响

securitypaper 发布时间:2022-09-29 20:05:32 ,浏览量:0

数据安全接口

对数据要素掌控和利用能力,已成为经济增长的核心驱动力。 在数字化时代,数据是重要资产,数据的安全是网络安全乃至国家 安全和社会安定不可或缺的重要要素。在云计算、大数据、人工智 能等新兴技术的推动下,众多行业都在经历一场轰轰烈烈的数字化 转型大潮。伴随着数字化进程的发展,API 作为连接数据和应用的 重要通道,在物联网、微服务、云原生等场景都得到了非常广阔的 应用,通过 API的能力将企业的数据资源整合,即将其服务、能力 和资产打包到可重复利用的模块化软件中,让数据在不同环境中使 用,包括将其与合作伙伴及其他第三方有价值的资产结合起来。API 在数字化转型中的扮演的角色将愈发重要,通过 API进行数据交换 成为最重要的传输方式之一,也因此成为攻击者窃取数据的重点攻 击对象。

近两年来因 API 安全问题导致的数据泄漏事件频频发生, 可 以看到 API安全是一个常见但似乎又不为人熟知的挑战。行业对 API 安全的认识仍处于早期,OWASP API Security Top 10(失效的对象 级授权、失效的用户认证、过度的数据暴露、资源缺失&速率限制、 功能级别授权已损坏等)指出了 API最常见的安全风险。

本报告结合面向实战化的安全实践,通过将 API 的安全能力和 组件,嵌入到业务体系,构建自适应的内生安全机制。按照“发现”、 “检测”、“防护”、“响应”的安全模型进行 API安全体系建设, 并不断地创新与迭代,提供万物互联时代的数据交换、大规模分布 式架构、云计算、数字化改造等场景的数据安全保障

数字化转型浪潮催生 API高速发展

API(Application Programming Interface,应用程序接口)是 一种计算接口,定义了软件之间的数据交互方式、功能类型。随着互 联网的普及和发展,API从早期的软件内部调用的接口,扩展到互联 网上对外提供服务的接口。调用者通过调用 API,可以获取接口提供 的各项服务,而无须访问源码,也无须理解内部工作机制的细节。

(一) API发展历程

API服务的发展历程可以看作企业数字化过程中系统集成需求不 断变化的过程。

21 世纪初期,随着 ERP、CRM等企业内部管理系统的普及,各类 系统沉淀了海量的关联数据,基于早期的数据库和 HTTP1.0通信协议, API 在企业内部数据打通后开始崭露头角,系统集成进入 API1.0 时 代。

2007 年前后,随 Web2.0 时代到来,企业信息和资源跨出企业内部,各企业系统不再是孤立状态,系统资源和数据的整合需求也扩散 至外部,进而出现了 UDDI技术规范和基于 SOAP协议的 API接口,系 统集成步入 API2.0 时代。

2015 年后,云服务主导了企业服务市场,大型企业在内部系统集 成理顺的基础上,将企业核心资源以带有适当安全和监管措施的“API+云服务”形式向合作伙伴、客户、乃至普通大众输出。基于此, RESTful API 开始被大量应用,API服务正式步入 3.0 时代。在 API3.0 时代,客户和普通大众可以利用企业通过 API输出的资源来完成各自 的产品和服务的开发,最终延伸出庞大的价值链。 在云技术与容器技术兴起之前,单体架构一直是构建应用程序的 主流架构,然而这两种技术的兴起,为企业快速部署项目以及持续集 成带来了很大便利。伴随着容器技术与云技术的发展,微服务已成为 高速增长公司中构建应用程序的首选。

  1. 单体架构

在应用程序发展的早期,大部分软件项目是将所有的服务端功能 模块打包到单个巨石型(Monolith)应用(典型的三级架构,前端 (Web/Wap/APP)+中间业务逻辑层+数据库层。这是一种典型的 Java Spring mvc 或者 Python Django 框架的应用)中,如很多企业的 Java 应用程序打包为 war 包然后发布到 Tomcat中,其架构图如下所示:

  1. 分布式架构

分布式架构是单体架构的并发扩展,将一个大的系统划分为多个 业务模块,业务模块分别部署在不同的服务器上,各个业务模块之间 通过接口进行数据交互。数据库也大量采用分布式数据库,如:Redis、 ES、solor 等。通过 DNS&LVS/Nginx/F5负载均衡处理器(DNS是用于 实现地理级别的负载均衡,而 Nginx&LVS&F5用于同一地点内机器级 别的负载均衡。其中 Nginx 是软件的 7 层负载均衡,LVS是内核的 4 层负载均衡,F5是硬件做 4 层负载均衡),将用户请求均衡地负载到 不同的服务器上。相对于单体架构来说,分布式架构提供了负载均衡 的能力,大大提高了系统负载能力,解决了网站高并发的需求。其架 构图如下所示:

  1. SOA架构

SOA是一个组件模型,它将应用程序的不同功能单元(称为服务) 通过这些服务之间定义良好的接口联系起来。SOA中的接口独立于实 现服务的硬件平台、编程语言,采用中立的方式进行定义,这使得构 建在各系统中的服务可以以一种统一和通用的方式进行交互。面向服 务架构,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行 分布式部署、组合和使用。SOA可以理解为:对单体架构的系统按照 实际业务,拆分成功能简单、层次清晰、可独立部署的模块,每个模 块之间相互独立,通过服务治理管理这些单独的模块进行工作。其架 构图如下所示:

  1. 微服务架构

微服务(Microservices Architecture Pattern)是由 Martin Fowler 在 2014 年提出的,将单体架构的系统应用,转化为多个可以 独立运行、独立开发、独立部署、独立维护的服务或者应用的聚合, 从而满足业务快速变化及分布式多团队并行开发的需求。如康威定律 (Conway’s Law)所言,任何组织在设计一套系统(广义概念)时,

所交付的设计方案在结构上都与该组织的通信结构保持一致,微服务 与微前端不仅仅是技术架构的变化,还包含了组织方式、沟通方式的 变化。

微服务架构,主要是中间层分解,将系统拆分成很多小应用(微 服务),微服务可以部署在不同的服务器上,也可以部署在相同的服 务器不同的容器上。当前应用产生的故障不会影响到其他应用,单应 用的负载也不会影响到其他应用,其代表框架有 Spring cloud、Dubbo 等。其架构图如下所示:

  1. Serverless 架构

Serverless 架构能够让开发者在构建应用的过程中无须关注计 算资源的获取和运维,由平台来按需分配计算资源并保证应用执行的 SLA(服务等级协议),按照调用次数进行计费,有效地节省应用成 本。其架构图如下所示:

  1. Cloud Native 云原生架构

云原生是通过构建团队、文化和技术,利用自动化和架构来管理 系统的复杂性和解放生产力。云原生(Cloud Native)的定义包含以 下三个方面:应用容器化、面向微服务架构、应用支持容器的编排调 度。其架构图如下所示:

(二) 数字化转型带来云原生的发展

随着各行业数字化转型的深入,资源弹性与简化运维的价值是企 业上云的基础,传统云服务已经远远不能适应企业的需要。

  1. 云原生赋能政企数字化转型

资源极致弹性、应用敏捷开发迭代正在发展成为云服务的新常态。 因此,“火爆”的云原生也成为互联网企业和传统政企的共同选择, 云原生不仅掀起了云计算时代一股新浪潮,也开辟出一条企业数字化 转型的最佳路径。随着云原生应用深入企业各个业务场景,跨云、跨 地域统一协同治理,保证一致应用体验等新的需求日渐突出。

  1. 云原生成为驱动业务增长的重要引擎

云计算的发展已进入成熟期,云原生作为新型基础设施支撑数字 化转型的重要支撑技术,逐渐在人工智能、大数据、边缘计算、5G等 新兴领域崭露头角,成为驱动数字基础设施的强大引擎。伴随全行业 上云的逐步深化,企业云原生化转型进程将进一步加速。

  1. 云原生是下一代云计算的技术核心

在传统应用架构下,网络流量大多是南北走向,但是到了云原生 平台时代,东西向流量占比越来越多,这对整个数据的传输、存储和 计算产生非常大的压力。为了让数据移动得更快,存储得更多,适应 更广泛,这就要求我们需要更快速地步入云原生时代。

目前 CNCF(云原生计算基金会)对云原生的定义为:

“云原生技术有利于各组织在公有云、私有云和混合云等新型动 态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容 器、服务网格、微服务、不可变基础设施和声明式 API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。

结合可靠的自动化手段,云原生技术使工程师能够轻松地对系统做出 频繁和可预测的重大变更”。

(三) API成为资源连接利器

Google Cloud 的研究显示:为应对 2020 年的新冠疫情对企业带 来的连锁效应,近 3/4 的企业持续投入数字化转型。这些企业当中, 有 2/3 正在增加投资或完全改变战略,想成为领先的数字型公司。

  1. API是云原生架构的技术核心之一

在微服务架构下,各个应用都被极尽可能的细分,因此它们彼此 间更需要 API来进行数据交互,API数量出现爆发式的增长。应用微 服务化开发,服务之间使用标准的 API接口进行通信。松耦合架构会 减轻因需求变更导致的系统迭代成本,为多团队并行开发提供基础, 并加快交付速度。

  1. 数字化转型依赖 API整合能力

数字化转型依赖于企业的整合能力,即将其服务、能力和资产打 包到可重复利用的模块化软件中。每个企业都在其系统中储存了有价 值的数据,然而要利用好这些价值,就要通过 API的能力打破数据孤 岛,让数据在不同环境中使用,包括将其与合作伙伴及其他第三方有 价值的资产结合起来。

即使一些系统从未设计互通能力,API也能让开发人员轻松访问 并组合不同系统中的数字资产,从而更好地实现整体协同。API是软 件和软件之间进行“对话”的最基本形式,如果将开发人员的经验融入 API的设计中,它们将变得非常强大,从而使开发人员能重复使用 数据和系统功能来开发新的应用程序。

3. API成为企业发展的战略需求

越来越多的公司都在寻找一种相对经济的方式使自身的 API 发 挥更多的价值,希望它能拓宽自己的技术和服务生态系统。另一方面, 企业也会寻找一些由别人开发的 API 来满足自己非核心的业务需求。

API近年来已经成为企业资源互相联结的利器,企业提供标准化 的 API 给多个外部使用单位(第三方);一个外部单位可以组合多个 API来丰富服务内容。这些开放标准的 API加速伙伴整合以及客户触 及率,衍生出 API生态系统。

在 IDC发布的 2018 中国 ICT市场预测指出:“到 2021 年,在超 过一半的全球 2000 强企业中,平均 1/3 的数字化服务交互都将来自

API开放生态系统,增长势头远超过其自己的客户交互能力。开放的 API生态系统是企业数字化平台开放重构的关键。”

(四) API成为政企数字化转型的核心能力

  1. API是一种核心能力

API可以被外部软件技术人员理解、使用;可以被互联网、移动 端、浏览器通过软件调用;企业各种资产、数据、服务、能力都可以通过 API对外开放。

在未来的数据化时代,API开放的程度,代表着一个企业的数字 化建设程度。API是系统将自身核心能力对外提供的重要方式,良好 的 API设计不仅让外部更易用,也能帮助理清系统边界;同时也是一 个公司技术水平直接的外部体现,也能更好地展现专业性。

  1. API化是一种必然的趋势

随着无服务器应用程序的兴起,后端功能越来越多地依赖 API, 而不是 Web服务器。随着向云计算的加速过渡,API在集成和促进云 迁移方面扮演着更为关键的角色,尤其是第三方 API,在这方面仍处 于起步阶段。

  1. API是企业的核心数字资产

据统计,截至目前,全球有 2000 万以上的开发者、超过百亿的 API。所有的应用程序,均需要通过 API 进行数据通信。在未来,一 切皆是软件,一切数据都可以通过 API获得,因此 API是所有数据交 互的关口。同时 API也是企业核心的数字资产,是企业数据、服务输 出和获取的唯一渠道。

参考资料

信通院 应用程序接口-API数据安全研究报告-2020年

关注
打赏
1665727082
查看更多评论
立即登录/注册

微信扫码登录

0.0364s