【编者按】云原生技术正在助力银行通过差异化业务进行创新，却也带来了由于研发/运维人员对新架构不熟悉所导致的基础设施风险、业务风险及数据暴露风险。如何在飞速更迭的技术环境下保持业务持续发展，同时保证业务整体的安全性，满足不断增强的监管合规要求，其中蕴含着复杂的技术与管理挑战。
作者 | 王郁 责编 | 杨阳
出品 | 《新程序员》编辑部在金融行业数字化转型浪潮下，从国有银行、股份制银行到各级商业银行，都纷纷步入云原生的进程。以容器、微服务、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的威胁分析，行业内也有多个组织提出过相关的评估标准。如图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安全生命周期
王郁
星阑科技CEO，清华大学网络空间研究院网络空间安全硕士。网络安全战队Blue-Lotus、TeaDeliverers前核心成员，HITCON、GEEKPWN国际黑客竞赛冠军，DEFCON-Finals Top3获得者，曾担任多个国际级网络安全赛事命题人及裁判，多个CyberSecurity研究成果发表于CCS等国际顶级安全会议。版权声明：内容来源于互联网和用户投稿 如有侵权请联系删除