工业和信息部网站备案,表格网站怎么做,wordpress 表情,广州花都区网站建设在应用程序开发过程中#xff0c;API是一个会被经常提及的东西#xff0c;它的全称是Application Programming Interface#xff08;应用程序接口#xff09;#xff0c;一般指的是Web API#xff0c;即#xff1a;采用HTTP通信协议的API或者是Web应用程序对外提供的API… 在应用程序开发过程中API是一个会被经常提及的东西它的全称是Application Programming Interface应用程序接口一般指的是Web API即采用HTTP通信协议的API或者是Web应用程序对外提供的API。
API从狭义上可以理解为是一种服务能力调用方可以利用API很便捷的得到一组相关数据但却不需要理解其内部的工作机制。
而在大型的软件系统中API还可以作为不同应用程序之间的一种契约通过它可以将应用程序进行组装从而实现业务逻辑更为复杂的功能。
所以API的设计将变得至关重要合理规范化的设计不但能够降低应用程序集成成本提升软件系统开发效能还能够增加API的可读性有助于API的管理维护。
通常API设计思路会遵循如下几点
设计风格统一设计理念适配应用架构设计提升开放性能力封装对能力进行封装而不是对数据库操作进行封装单一职责尽量做一件事情通过能力原子化提升复用性版本控制确保所有变化不能影响原有调用方的正常运行命名规范合理命名访问地址以及参数用于降低理解成本 至今在软件开发领域中API所能带来的价值已经显而易见甚至它是驱动创新的基本要素但要知道世界上任何事物都有两面性API也不例外。
在互联网的世界里“安全”和“开放”是一个永恒的话题但“开放创新”的前提必然是“安全可控”也就是说没有安全的API创新是不可能的。
那些不安全的API势必将成为攻击者的主要目标他们不但可以从中窃取高价值的数据还能破坏应用程序的正常运作。由此可见API的设计中应当更加注重安全性。 什么是不安全的API
先来介绍一下OWASP这个组织全称是Open Web Application Security Project它是一个开源的全球性安全组织致力于应用软件的安全研究。
它的使命是使应用软件更加安全使企业和组织能够对应用安全风险做出更清晰的决策同时推动安全标准、安全测试工具、安全指导手册等应用安全技术的发展。
在OWASP的众多项目中可以发现有一个有关于API的安全项目它不同于更广泛的Web应用程序安全项目API安全项目更专注于理解和减轻与API相关的独特漏洞和安全风险。 OWASP在2019年颁布了API安全TOP10的第一版其中列出了常见的API安全风险如下是API安全TOP10的中文翻译概览。 它的主要读者对象可以是开发人员、架构师管理人员甚至是企业或组织当你读完第一遍时不知会有怎样的感觉如果没有感觉那就请你再读一遍。 TOP10的安全风险排名采用了风险评级方法分别从可利用性、弱点普遍性、弱点可检测性、技术影响4个方面进行评级有兴趣的同学可以在OWASP官网查阅到API安全TOP10中每一项评级结果及内容说明。 但请注意这个风险评估方法并不会考虑威胁来源的可能性以及实际的业务影响它仅用于企业内部根据自身情况来评估接受多少应用程序以及API引入的安全风险。 API安全风险的治理思路 在充分了解API安全设计的重要性以及API安全风险所带来的影响范围后你必定会反问道是否有快速增强API安全设计的捷径。 很显然世界上就从来没有捷径但OWASP提供了一套较为完整的治理思路包括教育、安全要求、安全架构、标准的安全控件、软件安全开发生命周期五个方面同时还配套提供大量免费的资源来全面治理API安全风险。 看到这里估计你会意识到API安全风险治理将是一个复杂工程如果你的企业中没有一些同时擅长应用和安全技术能力的人恐怕这项工作将会很难推动即便是有其工作量和难度也非比寻常。 当面对复杂问题时采用分而治之的办法是一种比较高效的方法。换言之可以考虑将API安全风险治理这个复杂问题拆分为若干个子问题然后再根据当下的资源及能力逐一攻克。 那么就拿API安全TOP10来看可以考虑优先选择某一条进行治理。它可以是企业内部评估安全风险较大的一条或者也可以直接参考API安全TOP10的排名比如TOP10的第一条我想这可能是大部分企业最优先治理的一条。 另外在API安全风险治理的探索过程中还需要不断寻求规律及沉淀经验以及求证治理方法的合理性及有效性从而逐渐形成适用于企业自身的治理方法论及API安全架构与设计规范。
不过仅一份API安全架构与设计规范并不能起到根治的效果企业内部还得配套制定API安全管控流程开发API安全风险识别工具才行俗称API安全风险治理三板斧。
API安全架构的设计思路
API安全架构与设计规范可以通过定期宣导和培训进行传播但实际效果并不会特别乐观。主要的问题根源还是在于有些开发人员较为缺乏API安全开发的意识。
他们甚至连花费10分钟的时间来阅读API安全架构与设计规范都不乐意何况是让他们能够主动去改善而在庞大的应用架构中还存在着成千上万个应用程序或API想要所有的开发人员都能在安全意识上自驱更是难上加难。
那么是否有一种API架构设计能够尽可能减少对开发人员的依赖性但又能起到部分API的安全访问能力。引入API网关可能是一个不错的选择即所有应用程序的API都将通过API网关对外进行暴露特别是那些暴露至公网的API。 为了便于读者快速理解绘制了这张API架构示意图。总体结构从内到外共分为三个部分分别是API资产池、API网关、API调用方。接下来就分别对它们进行简单介绍。 API资产池
可以理解为相关性紧密的API集合相关性可以根据业务领域、组织架构或其他等维度进行识别。而将API资产化纯粹是为了凸显它的价值性。 API调用方
可以理解为API的服务对象或者为调用API的用户或应用程序服务对象基本可以分为合作机构、外部用户、内部用户、内部应用四种类型。 API网关
可以理解为用于连接API资产池与API调用方的通道它将作为API对外进行暴露的唯一入口而面向不同的API调用方可以设计不同场景的API网关。
综上笔者将这种API架构称之为“护城河”架构将API网关比喻为“护城河”除API资产池内部互访及特殊场景下其余API访问必须经过“护城河”且大部分情况下“护城河”仅对持有通行证的用户或应用程序放行。
注特殊场景可能为应用程序对内暴露的部分管理功能例如指标监控、健康检查等。
而不同场景的API网关对API调用方的安全要求等级也会不同通常对外网的安全要求会比内网要高。最终可以形成如下这张API资产访问清单。
服务对象使用环境网关场景安全要求合作机构外网2B-API高外部用户外网2C-API高内部用户外网/内网2G-API中内部应用内网2S-API中
通过这种API架构设计可以将安全访问控制能力从应用程序中剥离至API网关一方面可以让应用程序更专注于实现业务服务能力另一方面可以对API访问入口进行集中收口规避因开发人员安全意识不足而注入的访问控制安全问题。 API安全治理的实践思路
用过API网关的同学都知道它的核心能力主要是流量路由转发及分流。所以缺省情况下它并不会启用安全控制能力因此你需要根据实际使用场景选择开启不同的安全控制能力。
API网关一般都支持如下安全控制能力
控制能力防范场景请求限流防止攻击者频繁请求API导致资源耗尽无法正常响应签名验签防止攻击者伪造身份请求API或篡改请求报文数据加密解密防止攻击者通过非法手段拦截报文后获取敏感数据防重请求防止攻击者通过非法手段获取报文后重复请求API用户鉴权防止攻击者在匿名情况下请求API获取数据或攻击程序访问约束防止攻击者利用漏洞采用不安全的方法或跨域请求API 前文有提到过不同场景的API网关对API调用方的安全要求也会不同。所以并不是说所有API网关都要实现或开启以上控制能力根据实践使用经验参考如下
控制能力2B网关2C网关2G网关2S网关请求限流必须必须可选可选签名验签必须*无需*无需可选加密解密必须*可选*可选可选防重请求必须*可选*可选可选用户鉴权必须必须必须可选访问约束必须必须必须必须
注*代表在移动端环境下为必须。 可以发现面向公网的API安全控制要求要远远高于内网。所以说在API安全治理的优先级上建议采取先外后内的实践策略毕竟面向公网的API处在一个完全开放的环境下它更容易受到致命性的攻击。 另外在最新的2021年最新版的OWASP TOP10中可以发现“失效的访问控制”已从第五位上升到第一位而如下这组风险因素数据更能说明访问控制的安全风险它将会越来越受到攻击者的“青睐”。 在明确API安全治理的实践策略后就需要制定相应的实践步骤而对于治理类相关的工作而言一般主要有三个步骤定义目标识别差距治理问题。 在完成第一轮治理后重新定义目标并进行新的一轮通过这种持续不断地加速循环达到最终的API安全治理目的。 第一步定义目标 在启动API安全治理前最重要的任务就是定义目标并明确范围从而牵引工作始终朝着正确的方向推进。 API安全治理所涉及的范围非常大所以初期可以考虑缩小治理范围并确定一个可达的目标。例如可以将公网API访问控制治理作为第一个目标。 在公网API访问控制方面暂且列举了可能存在问题的两种主要现象其中第一种应该很容易理解但是第二种会觉得有点奇怪这里谈论的是公网API访问控制与内部API有什么关系。 但令人恐怖的是有些开发人员在不知情的情况下误将内部API直接暴露到公网上而内部API安全控制可能相对较弱甚至没有任何安全控制。 请试想一下如果一个活动秒杀类商品库存可以被外部攻击者任意修改将是一种怎么样的体验我想可能不是秒杀商品而是秒杀企业。 所以不管是外部API还是内部API都将会在这个治理范围内只不过治理目标有所区别对于外部API需要增加安全控制手段而对于内部API需要杜绝暴露至公网。 第二步识别差距 在定义目标并明确范围后可能还不能真正启动治理工作还需要识别当前API现状与治理目标之间的差距这样才能明确治理的方式和手段而在识别差距前还得收集当前API清单及现状。 如果你的企业中API有专门的管理平台进行管理维护那么收集API清单可能相对容易但有些企业可能还在使用电子文档管理API那么这项工作将会变得十分困难。 所以这时可以考虑开发一个API扫描工具自动获取应用程序中对外暴露的API对于主流的Java应用程序而言你的第一反应可能会想到可以在源代码中通过检测Restcontroller或Controller注解来识别API。 这种方式确实可以扫描到部分API但可能并不完整一是对外暴露的API不一定都采用注解的方式二是应用程序引用的第三方的包中也对外暴露了API这部分可能是扫描不到的。所以需要换一种方式来获取应用程序对外暴露的全量API。 如果你的Java应用采用了Spring框架那么可以考虑采用如下这个方法在应用程序启动初始化后可以从handlerMappings获取所有对外暴露的API信息。
org.springframework.web.servlet.DispatcherServlet的代码片段如下
private void initHandlerMappings(ApplicationContext context) {this.handlerMappings null;if (this.detectAllHandlerMappings) {// Find all HandlerMappings in the ApplicationContext, including ancestor contexts.MapString, HandlerMapping matchingBeans BeanFactoryUtils.beansOfTypeIncludingAncestors(context, HandlerMapping.class, true, false); if (!matchingBeans.isEmpty()) { this.handlerMappings new ArrayList(matchingBeans.values()); // We keep HandlerMappings in sorted order. AnnotationAwareOrderComparator.sort(this.handlerMappings); }} 但要声明的是API扫描工具并不是万能的它仅仅只是提供了另一种手段帮助你解决80%以上的问题对于还在使用电子文档管理API的开发人员还是建议对扫描后的结果进行查漏补缺。 另外除了API扫描工具外还可以抓取网络代理组件中的访问日志进行识别最终结合扫描工具、自查上报、访问日志三部分的信息形成一份较为完整的API清单虽然它可能并不是完整的但在条件有限的情况下这可能是最好的结果。 有了API清单后接下来需要对它们分门别类及现状分析如下简单设计了API分类字段你可以根据自身需要再进行调整或补充。
分类字段可选项API访问地址通过扫描结果/自查上报/访问日志形成API服务对象合作机构/外部用户/内部用户/内部应用API作用类型公开信息类/用户鉴权类/业务功能类/非业务功能类API读写类型读/写API用户鉴权是/否含有个人信息是/否允许公网访问是/否访问请求限流是/否报文签名验签是/否报文加密解密是/否控制重复请求是/否方法请求配置GET/POST/PUT/DELETE/HEAD/无/其他跨域请求配置Access-Control开头相关参数 根据第一步定义的目标可以先将所有允许公网访问的API全部筛选出来随后分别对这些API进行现状分析及识别差距例举如下 方法请求配置原则上仅允许GET/POST 跨域请求配置原则上默认不允许需单独申请批准 API服务对象原则上不允许为内部应用 API服务对象若为合作机构安全要求如下
安全要求公开信息类用户鉴权类业务功能类非业务功能类用户鉴权无需无需必须必须请求限流必须必须必须必须签名验签必须必须必须必须加密解密无需必须*可选*可选防重请求必须必须必须必须
注*代表API是A2类时为必须。A1/A2分类可参考《商业银行应用程序接口安全管理规范》 API服务对象若为外部用户/内部用户安全要求如下
安全要求公开信息类用户鉴权类业务功能类非业务功能类用户鉴权无需无需必须必须请求限流必须必须必须必须签名验签*可选*可选*可选*可选加密解密*可选*可选*可选*可选防重请求*可选*可选*可选*可选
注*代表在移动端环境下为必须。 最后根据针对每一条API所识别出来安全问题进行等级评定前期为了简化工作难度在没有安全风险量化指标之前建议直接根据安全技术人员的经验标记为高、中、低即可。 第三步治理问题 当识别出所有API安全问题后就可以全面启动治理工作可以分别从API架构设计治理、API安全访问治理、API管控流程治理三个方面共同启动。 在API架构设计治理方面将对API的暴露方式进行调整暴露至公网的API将全部通过API网关进行暴露并在API网关上配置API路由访问策略。 对于存在安全问题的API建议根据等级评定来决定是否立刻整改剩余其他API建议逐步进行迁移而对于以后新开发的API要求直接采用这种模式。 在API安全访问治理方面将API安全控制能力从应用程序中剥离至API网关进行承接所有应用程序都将由API网关进行安全保护。 当然应用程序可在有条件的情况下保留部分安全控制能力只要不与API网关存在安全控制冲突即可。 在API管控流程治理方面还需要分别在API发布的事前、事中、事后三个阶段增加必要的控制手段。 事前API暴露公网提交申请并在审核通过和必要的渗透测试后才会在API网关上进行注册并对外暴露从而避免内部API误暴露至公网的情况发生 事中API请求增强异常监控对于发现大量鉴权/验签失败、触发限流/防重等现象后进行预警并由人工介入排查是否存在安全风险并及时进行拦截 事后API请求访问日志分析对访问日志进行安全风险分析包括撞库异常行为、数据过度暴露、敏感信息泄漏、上下文行为异常等访问安全数据分析 因篇幅有限以上三个步骤仅是围绕公网API访问控制治理进行了简要的实践说明但这仅仅只是API安全治理的一小部分。 另外API网关也并不能解决你所有的API安全问题更多的还是应用程序自身需要进行API安全治理例如失效的功能级授权即水平越权安全漏洞。 写在最后 本文依次从突出API安全的重要性到列举什么是不安全的API及全面治理的思路方法再到如何通过API架构设计减轻API安全问题以及最后针对某API安全问题的实践过程分别进行了一一阐述其中部分截图来自OWASP官网/中国网。 它可能并不全面或者说并不完全适用于所有情况但本文的意义更多的是为了起到抛砖引玉效果启发对API安全开发的思考唤醒对API安全开发的意识。 在最后的最后想说的是赶在节前输出一篇有关于安全的文章寓意并祝愿大家安安全全过大年疫情过后尽开颜。
