广告公司起名如何起,网站优化排名推荐,正规的推文平台,jq网站特效插件【编者按】云原生技术正在助力银行通过差异化业务进行创新#xff0c;却也带来了由于研发/运维人员对新架构不熟悉所导致的基础设施风险、业务风险及数据暴露风险。如何在飞速更迭的技术环境下保持业务持续发展#xff0c;同时保证业务整体的安全性#xff0c;满足不断增强的…【编者按】云原生技术正在助力银行通过差异化业务进行创新却也带来了由于研发/运维人员对新架构不熟悉所导致的基础设施风险、业务风险及数据暴露风险。如何在飞速更迭的技术环境下保持业务持续发展同时保证业务整体的安全性满足不断增强的监管合规要求其中蕴含着复杂的技术与管理挑战。作者 | 王郁 责编 | 杨阳出品 | 《新程序员》编辑部在金融行业数字化转型浪潮下从国有银行、股份制银行到各级商业银行都纷纷步入云原生的进程。以容器、微服务、API为代表的云原生技术重塑了云端应用的设计、开发、部署和运行模式实现了自动化、易管理、可观测的全新DevOps体系开发者和运维人员能够最大限度地提高生产力更敏捷、更高效地进行应用迭代。但与此同时云原生体系也带来了技术、产品、标准和生态系统的不断扩大由此产生了新的基础设施暴露风险、通信风险和数据传输风险。为了满足云原生平台高可靠、高性能的基本保障安全建设至关重要但这又非常宏观涉及到方方面面。新技术的诞生和应用必然面临着新威胁面的扩展与迁移这也要求安全技术必须随着业务的技术架构做出即时改变在新架构上实现安全能力的同步延展。为此本文将分别论述云原生的底层弹性基础设施、容器平台和云原生体系的基础通信及数据传输体系、API在金融科技领域的应用所带来的威胁面以及应对相关问题的分析方法和安全实践。云原生的基础设施——容器平台的威胁面与安全监测技术容器技术在金融行业的快速落地带来了弹性伸缩、快速部署等优势之外也为业务系统安全带来了诸如容器逃逸、容器提权、镜像风险、管理平台暴露等崭新的攻击面而开发和运维人员缺乏对容器的安全威胁和最佳实践的认识也可能会使业务从一开始就埋下安全隐患。根据Tripwire的调研报告60%的受访者在过去一年使用容器过程中至少发生了一起容器安全事故。在部署规模超过100个容器的使用者中安全事故的比例上升到75%。由此可见快速拥抱容器化带来的安全风险不容忽视。以攻击者视角看待容器平台的威胁面在实际云环境中由于开发/运维人员对于容器集群安全机制的了解和配置能力不一在账号创建、AK/SK部署、容器平台端鉴权等位置容易出现凭证泄露、管理平台暴露等风险可能导致整个容器平台被攻击者获取控制权。我们也曾多次看到由此导致的严重基础设施入侵事件对相关金融机构造成了严重损失。如图1所示从攻击的角度目前行业内已经梳理了多个针对容器的威胁矩阵。以阿里云容器ATTCK攻防矩阵为例攻击者在其攻击流程的初始访问、执行、持久化、权限提升、防御逃逸、窃取凭证、探测、横向移动等阶段分别可以对于容器产生的相关攻击进行尝试。图1阿里云容器ATTCK攻防矩阵这些攻击手段分别从容器的不同暴露点位入手结合不同的配置缺陷窃取认证信息以此获得持久化的控制权限最终能够达到破坏容器集群系统及数据、劫持资源、拒绝服务和加密勒索的目的。解决容器安全问题的三层面分析面对容器带来的扩展威胁面基于容器平台的层次架构我们可以从以下三个层面来看待这个问题。在容器及K8s层面通常我们需要保证镜像安全、容器运行时安全、容器网络安全、权限安全等问题。另外可进一步关注K8s的Pod安全策略。在平台层集群隔离、租户安全、用户隔离、网络ACL与访问控制、审计、DevSecOps、平台高可用等都是平台层面提供的安全能力。平台自身的漏洞扫描、组件漏洞等问题需要做严格的漏扫做到有效处理。在应用层可通过DevSecOps在开发过程中为应用提供安全保障。另外平台应提供应用高可用保障、应用安全接入、跨域策略、数据高可用等能力为应用进一步提供安全保障。对于面向互联网的应用可叠加前端安全设备的WAF、anti-DDOS、防注入等能力进一步提升应用的安全性。容器平台安全防护实践云原生安全离不开容器安全而容器的安全防护可从以下方面开始着手评估和实践。基础设施层操作系统安全涉及容器云工作节点的操作系统要遵循安全准则。使用端口策略等安全措施使用最小化操作系统同时精简和平台不相关的预置组件从而降低系统的攻击面。使用第三方安全工具检测系统和应用程序的运行状态实现进程和文件的访问控制等。平台层安全安全扫描对容器调度和管理平台本身需要先实现安全基线测试平台安全扫描。审计对平台层用户操作进行审计同时也需要项目层面的资源和操作审计。授权对平台实行权限控制能基于角色/项目/功能等不同维度进行授权。备份定期备份平台数据。容器安全镜像安全容器使用非root用户运行使用安全的基础镜像定时对镜像进行安全漏洞扫描。运行时安全主要是对容器在容器平台上运行过程中对于宿主机系统以内进行安全设置例如容器特权、提升权限、主机PID、主机IPC、主机网络、只读文件系统等安全限制。同时建议限制容器对于底层宿主机目录的访问并设置其对于外部网络端口暴露的范围限制。用户限定某些敏感项目独占宿主机实现业务隔离。云原生的通信血液——API的威胁面与安全监测技术随着金融行业数字化转型的深入API作为云原生环境下的基础通信设施在金融机构的离柜交易、移动支付、线上服务等多种业务中变得越来越高频多元。API作为驱动开放共享的核心能力已深度应用于金融行业。与此同时其巨大的流量和访问频率也让API的风险面变得更广、影响更大。当下由API传输的核心业务数据、个人身份信息等数据的流动性大大增强因此这些数据面临着较大的泄漏和滥用风险成为数据保护的薄弱一环外部恶意攻击者会利用API接口批量获取敏感数据。而从金融的生态开放角度看目前数据的交互、传输、共享等过程往往有多方参与涉及到交易方、用户、应用方等多个主体由此使得数据泄露风险点激增风险环境愈发复杂。以攻击者视角看待API的威胁面对于API的威胁分析行业内也有多个组织提出过相关的评估标准。如图2所示OWASP在APISecurityTop10-2019框架中总结出排名前十位的安全风险依次为对象授权失效、用户授权失效、数据暴露过度、资源缺失和速率限制、功能级授权失效、批量分配、安全配置错误、注入、资产管理不当、日志与监控不足。图2 OWASPTOP10-2021和OWASPAPISecurityTop10-2019的对比从图中不难看出API安全风险与网络应用风险高度重合(相同颜色的标记代表同类风险)。这就意味着API除了自身的独特漏洞和相关风险外也面临着基于网络的应用程序多年来一直在解决的同类问题。结合当下金融科技领域API保护的实践场景并对OWASPAPISecurityTop10中的风险进行合并与整合以攻防角度来看在落地层面主要有以下六点威胁。水平越权利用失效的对象授权通过遍历参数批量拖取数据这是目前众多金融科技企业API设施所面临的最主要威胁。随着API生态和多方交互场景的落地潜在的API越权缺陷极大程度地缩短了攻击者窃取金融敏感数据的路径即攻击者只需找到一个可越权的API无需经历复杂的打点渗透及横向移动即可窃取高价值的金融敏感数据。当下手机银行、微信银行、小程序、第三方业务开放的大量API接口由于开发规范不一可能缺乏良好的鉴权认证机制(JWT/Token校验等)从而面临此类风险。敏感数据暴露脱敏失效或一次性返回多余不必要的敏感数据。在金融行业重监管的背景下为满足数安法、个保法及下属各地方/行业监管要求需对个人用户隐私数据进行治理和合规管理这对API需要识别、分类和脱敏的数据也提出了较高要求但目前大量现存API缺乏相应的数据管控能力。代码漏洞SQL注入、命令执行等由业务开发者导致的风险。API接口本身容易受到代码漏洞的威胁如各类型的注入、反序列化威胁等由于金融行业API本身数量较多且连接性较强需在开发过程中做好代码审计与相应的安全测试工作。API基础设施漏洞API后端中间件、基础设施漏洞如Log4j2、APISIX漏洞。错误配置不安全、不完整或错误配置如临时调试API、未鉴权API、存储权限公开、不必要的http方法、跨越资源共享等。业务逻辑缺陷无校验、无防重放、无风控策略、高并发导致条件竞争等。API全生命周期安全防护实践由于API的安全问题贯穿了从设计、管理到下线的全流程因此也需要从整个API的生命周期来着手。如图3所示表示如何在API生命周期的不同阶段落地相应的安全能力。图3 API安全生命周期设计阶段在设计API之初安全人员需要和产品、开发等角色对焦需求和设计方案基于企业API安全设计规范建设自动化威胁建模能力将威胁建模加入API设计阶段给出可能发生的风险解决建议和方案同时根据业务安全损失及业务重要性对API安全设计进行分层以不同的安全强度和研发成本适配不同的业务场景。开发阶段安全团队可针对API的安全风险设计面向研发流程的安全开发规范文件进行安全意识贯宣同时提供认证、鉴权、数据访问等包含安全能力的插件或代码库同时可以向CI/CD流程中植入白盒审计能力将存在漏洞的代码通过安全开发规范和安全代码库收敛降低人为因素引入漏洞的概率。测试阶段API场景存在大量的鉴权、越权、编码、加密问题对传统安全测试能力提出挑战。用web攻击的思路进行黑盒测试无疑收效甚微目前fuzz工具针对API场景存在以下能力缺失基于复杂协议解码(协议级解码参数级解码)的参数污染、基于API访问顺序(调用链)的fuzz、基于认证状态的越权漏洞检测。运行阶段API安全监测需要从业务、数据、威胁三个视角进行能力建设包括API的识别与管理、敏感数据流动监测、攻击事件监测、API异常行为监测等场景。通过实时流量分析的方案可以针对API行为、访问者行为、访问拓扑等多维度对API行为进行建模并结合API网关等安全设备针对攻击特征及已经监控到的安全威胁进行阻断。迭代与下线我们需建设相应的API迭代发现能力当API发生高风险迭代时介入安全评审流程。此过程可以监控API的名称、参数、返回值、代码仓库变更触发新一轮的安全自动化测试并按照业务重要性分配安全评审人力资源。同时旧版API如果没有被及时下线不仅会浪费系统资源还会变成潜在的线上风险企业可通过API管理平台以及流量侧API行为发现失活、弃用的API及时下线。API运行时防护实践此外由于API本身涉及到云原生通信体系在金融科技领域的各项业务较多API可能已经在未进行安全审计的状态下越过了设计、开发、测试阶段直接处于运行时状态。对于这一部分已经投入生产的API最好能够建立对于API安全的管控平台。如图4所示对已有API进行风险监测、攻击防护、联动防御和智能分析。图4API运行时防护在风险监测能力上需要做好API清点即安全管控平台要对每一个API进行清晰的记录包括与什么类型的数据进行交互、所有者是谁、基础设施中的相关网络、物理资源是谁以及它属于哪个应用程序或业务部门。同时在内容维度需要能够识别API参数和有效载荷中的敏感数据类型并适当地标记API端点。API承载了应用各组件间数据的流动我们需要关注API携带了哪些敏感数据、对谁开放、对方如何使用这些数据等问题。企业被爆出数据泄露事件屡见不鲜除了数据库被攻陷之外其中很大部分是携带敏感数据的API鉴权出问题导致外部攻击者通过不断访问API拖取敏感数据。在攻击防护方面需要能够阻止针对API协议的攻击除了plainHTTP、REST等可复用传统安全能力的协议之外仍有诸多协议标准如GRPC、Dubbo、GraphQL等。还要能够阻断WEB攻击尤其是针对OWASPAPI安全十大问题中定义的网络攻击。此外安全管控平台需要具备与各种业务系统整合联动的能力应提供与常见IT和安全系统的整合在发现网络攻击和数据安全事件时联合所有资源进行处置。这种整合不应局限于基本的日志保存和数据传输应智能地对事件进行优先排序提供可操作的安全警报并配合SOC和IT人员的工作流程。这意味着问题可以在被发现时自动分配给适当的团队或系统不需要改变工作流程或不同的系统来检查。通常情况下安全团队需要与IT、DevOps或业务部门合作来处置风险。在智能分析能力上可以在AI/ML的协助下高频收集和持续分析API流量并与每个源IP地址、每个用户和每个会话的攻击行为联系起来。因为攻击者在早期都会被动地、隐蔽地进行目标探测还通常对客户端应用程序代码进行逆向工程以了解后端API的功能以及如何与之通信。这种被动分析技术可以逃避大多数检测因为它们通常是作为合法流量出现的。而API安全产品应该能够检测到这样流量的细微变化达到早期攻击预防的目的。结语综上云原生平台的安全建设并非一蹴而就而是一个需要不断完善、迭代积累的过程本文以容器平台的安全和API安全为例分析威胁并给出相关的能力建设点。在实际的安全建设过程中还会涉及到功能规划、平台运维、升级实施、安全保障、流程设计等一系列相关问题在使用全新技术来赋能业务的同时维护安全同样也是一个体系化的多维度工程。金融科技企业应从自身情况出发有针对性地规避云原生改造过程中的安全问题平稳且高效地实现金融级云原生平台的安全构建。我们相信云原生技术在金融科技领域的应用必然向更加安全、可信的方向发展。作者介绍王郁星阑科技CEO清华大学网络空间研究院网络空间安全硕士。网络安全战队Blue-Lotus、TeaDeliverers前核心成员HITCON、GEEKPWN国际黑客竞赛冠军DEFCON-Finals Top3获得者曾担任多个国际级网络安全赛事命题人及裁判多个CyberSecurity研究成果发表于CCS等国际顶级安全会议。
