【编者按】云原生技术正在助力银行通过差异化业务进行创新，却也带来了由于研发/运维人员对新架构不熟悉所导致的基础设施风险、业务风险及数据暴露风险。如何在飞速更迭的技术环境下保持业务持续发展，同时保证业务整体的安全性，满足不断增强的监管合规要求，其中蕴含着复杂的技术与管理挑战。
在金融行业数字化转型浪潮下，从国有银行、股份制银行到各级商业银行，都纷纷步入云原生的进程。以容器、微服务、API为代表的云原生技术，重塑了云端应用的设计、开发、部署和运行模式，实现了自动化、易管理、可观测的全新DevOps体系，开发者和运维人员能够最大限度地提高生产力，更敏捷、更高效地进行应用迭代。但与此同时，云原生体系也带来了技术、产品、标准和生态系统的不断扩大，由此产生了新的基础设施暴露风险、通信风险和数据传输风险。为了满足云原生平台高可靠、高性能的基本保障，安全建设至关重要，但这又非常宏观，涉及到方方面面。新技术的诞生和应用必然面临着新威胁面的扩展与迁移，这也要求安全技术必须随着业务的技术架构做出即时改变，在新架构上实现安全能力的同步延展。
为此，本文将分别论述：云原生的底层弹性基础设施、容器平台和云原生体系的基础通信及数据传输体系、API在金融科技领域的应用所带来的威胁面，以及应对相关问题的分析方法和安全实践。
云原生的基础设施——容器平台的威胁面与安全监测技术
容器技术在金融行业的快速落地带来了弹性伸缩、快速部署等优势之外，也为业务系统安全带来了诸如容器逃逸、容器提权、镜像风险、管理平台暴露等崭新的攻击面，而开发和运维人员缺乏对容器的安全威胁和最佳实践的认识也可能会使业务从一开始就埋下安全隐患。
根据Tripwire的调研报告，60%的受访者在过去一年使用容器过程中至少发生了一起容器安全事故。在部署规模超过100个容器的使用者中，安全事故的比例上升到75%。由此可见，快速拥抱容器化带来的安全风险不容忽视。
以攻击者视角看待容器平台的威胁面
在实际云环境中，由于开发/运维人员对于容器集群安全机制的了解和配置能力不一，在账号创建、AK/SK部署、容器平台端鉴权等位置容易出现凭证泄露、管理平台暴露等风险，可能导致整个容器平台被攻击者获取控制权。我们也曾多次看到由此导致的严重基础设施入侵事件，对相关金融机构造成了严重损失。
如图1所示，从攻击的角度，目前行业内已经梳理了多个针对容器的威胁矩阵。以阿里云容器ATT&CK攻防矩阵为例，攻击者在其攻击流程的初始访问、执行、持久化、权限提升、防御逃逸、窃取凭证、探测、横向移动等阶段，分别可以对于容器产生的相关攻击进行尝试。
图1：阿里云容器ATT&CK攻防矩阵
这些攻击手段分别从容器的不同暴露点位入手，结合不同的配置缺陷，窃取认证信息，以此获得持久化的控制权限，最终能够达到破坏容器集群系统及数据、劫持资源、拒绝服务和加密勒索的目的。
解决容器安全问题的三层面分析
面对容器带来的扩展威胁面，基于容器平台的层次架构，我们可以从以下三个层面来看待这个问题。
在容器及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进行风险监测、攻击防护、联动防御和智能分析。
图4：API运行时防护
在风险监测能力上，需要做好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等国际顶级安全会议。