云原生安全技术业务安全问题分析

最新推荐文章于 2024-08-16 11:00:56 发布

m0_73803866

最新推荐文章于 2024-08-16 11:00:56 发布

阅读量451

点赞数

文章标签：安全云原生

本文链接：https://blog.csdn.net/m0_73803866/article/details/127582420

版权

云原生

应用的安全检测9.1.2.1　针对 API的脆弱性
检测针对 API的脆弱性检测通常可使用扫描器进行周期性的漏洞扫描，国内各大安全厂商均供扫描器产品，例如绿盟科技的远程安全评估系统（RSAS）及 Web 应用漏洞扫描系统（WVSS），除此之外，
我们也可以使用其它商业版扫描器，例如 AWVS（Acunetix Web Vulnerability Scanner）、AppScan、 Burp Suite、Nessus 等。
9.1.2.2　针对 API的攻击检测
面对针对 API的威胁，目前多使用传统 API网关的形式进行防护，例如 Kong、Zuul、Oran
ge 等都有其各自的 API安全解决方案。不过随着应用的云原生化，许多云原生 API网关应运而生，例如 Kong、Ambassador、Gloo 均可基于 Kubernetes 进行部署。虽然 API网关在一定程度上抵御了应用的 API威胁攻击，但其防护是南北向流量，服务网格内部的东西向流量检测防护并未得到有效缓解。理想的解决方案应当是东西 / 南北向的全量检测。
针对此需求，业界已有了相应的解决方案，主要是云原生网关与服务网格的结合，其中服务网格负责东西向流量的检测防护，关于服务网格有采用主流的 Istio，也有采用 Kong 的服务网格 Kuma。
Istio 主要通过其内置的 Envoy 过滤器实现东西向流量检测，而 Kuma 则依托 Kong 的安全插件实现相应检测防护。笔者将 Gloo +Istio、Ambassador+Istio、Kong+Kuma 这三种解决方案的安全能力进行了对比，如
以下表格所示：
表 9.1　云原生环境下 API防护方案安全能力对比

|方案组合|Gloo+Istio|Ambassdar+Istio|Kong+Kuma|
|防护维度|东西向 / 南北向|东西向 / 南北向|东西向 / 南北向|
|WAF支持|支持|支持|支持|
|访问控制|支持|支持|支持|
|授权机制|支持|支持|支持|
|认证机制|支持|支持|支持|
|证书管理|支持|支持|支持|
|网站锁|不支持|不支持|不支持|
|反爬虫|不支持|不支持|不支持|
|机器流量检测|不支持|不支持|支持|
|数据丢失防护|支持|不支持|不支持|
|CORS|支持|支持|支持|
|方案组合||Gloo+Istio|Ambassdar+Istio|Kong+Kuma|
|XSS||支持|不支持|不支持|
|CSRF||支持|支持|不支持|
|DDOS||支持|支持|不支持|
|黑白名单限制||支持|支持|支持|
|限速||支持|支持|支持|
|行为特征分析|AI|不支持|不支持|不支持|
|入侵检测||不支持|不支持|不支持|
|mTLS||支持|支持|支持|

从以上表格统计来看，Gloo+Istio 解决方案支持的安全项更多些，Kong+Kuma 解决方案支持的安全项最少。

应用业务安全

前文从网络，应用等层面介绍了微服务所面临的的威胁。除此之外，微服务架构还面临着许多业务层面的安全威胁。这些安全威胁往往会影响业务的稳定运行，同时会给业务系统带来经济损失。

业务安全问题分析

具体来说，应用所面临的安全问题主要包括三类，即业务频率异常，业务参数异常，业务逻辑异常。我们以一个微服务架构的电商系统为例进行介绍业务安全，该电商系统的典型流程如图 9.1 所示。
图 9.1　电商系统业务流程图
业务频率异常。 针对一个或者一组 API的频繁调用。如前所述，业务系统往往通过图形验证码的方式来避免机器人刷单的操作。攻击者可以绕过验证码所对应的微服务，直接对订单进行操作，进而实现
机器刷单，对电商进行薅羊毛。
业务参数异常。 API调用过程中往往会传递相关的参数。参数的取值根据业务场景的不同会有不同的取值范围。例如商品数量必须为非负整数，价格必须大于 0 等。如果 API对相应参数的监测机制不完善，那么攻击者往往可以通过输入异常参数导致业务系统受到损失。例如在电商系统中，如果商品价格只在商品介绍服务中进行校验，而在订单管理和支付服务中没有进行校验，那么攻击者就可以通过直接调用订单管理和支付服务的 API来将订单价格修改为 0 元或者负值，给业务系统造成损失。
业务逻辑异常。 相比于前两类异常，这类异常一般较为隐蔽。攻击者采用某些方法使 API调用的逻辑顺序出现异常，包括关键调用步骤缺失、颠倒等。例如在电商系统中，攻击者可以利用漏洞绕过交费的步骤直接交订单。这样就会出现业务逻辑出现关键步骤缺失的情况。对于前述业务频率异常中的验证码绕过异常，也属于业务逻辑异常。

业务异常检测

针对上述业务层面安全问题，基于基线的异常检测是一类比较有效的方法：首先建立正常业务行为与参数的基线，进而找出偏移基线的异常业务操作，其中，基线的建立需要结合业务系统的特性和专家知识共同来完成。
在电商系统中，业务参数基线主要基于专家知识来建立。例如商品价格不仅与商品本身相关，也与时间和各类优惠活动等相关。这类基线需要运维人员持续的维护。对于业务逻辑基线的建立，由于业务系统在正式上线运行以后，其操作逻辑一般不会有较大的变化，同时异常操作所占的比例较少。因此可以采集业务系统历史的操作数据，结合统计分析与机器学习的方法建立业务逻辑的基线。相比于人工方法，这种方法可以提高基线建立的效率，有效减轻运维人员的工作量。
为此，可利用在 6.4.3 中所到的分布式追踪工具采集到的数据，针对上述三种业务异常场景，设计并实现了业务异常检测引擎，如图 9.2 所示。其中，采集模块主要用于采集业务系统的运行数据，训练模块主要针对业务系统历史数据进行训练以取行为特征数据，检测模块主要对正在运行的业务系统进行异常检测。
图 9.2　业务异常检测引擎设计图
检测引擎中每部分的具体功能为：
分布式追踪工具。 主要为采集微服务业务系统运行时生成的数据。当前常用的开源分布式追踪工具为 Jaeger 与 Skywalking，此外 sidecar 也可以采集相应数据。经过对测试系统进行的采集实验，相比其他两种采集工具，Jaeger 可获取的数据字段最多，能够检测的异常场景最丰富，然而，Jaeger 需要在业务系统的源代码中进行插桩，对开发团队而言有较强的侵入性。相反，sidecar 模式没有代码和镜像的侵入性，但通过反向代理截取流量的模式也决定了它不能获得丰富的上下文，如 6.3.3 的追踪 API 调用关系树（TraceID）是无法获得的。如何利用侵入性更低的采集工具收集到的数据来实现覆盖更多场景的异常检测仍需要很多后续工作。
数据筛选与整合模块。 此模块主要功能为过滤掉数据集中的脏数据，以及取出可以表示业务系统行为的数据。在微服务下，可以表示业务系统行为的数据为 API调用关系树、服务名、操作名、HTTP POST 参数等。
数据训练模块。 将预处理后的历史数据利用机器学习或统计学的方法，训练出业务系统中的正常行为，并生成与业务系统正常行为匹配的特征数据。这里进行训练的先验知识为，我们认为业务系统中大量存在的行为是正常行为，而数量很少的行为是异常行为。在训练过程中，需要根据专家知识对训练结果的检验不断调整训练模型的参数。
检测引擎。 将业务系统当前数据与特征数据进行检索匹配，并利用序列相似性计算等方法
找出特征数据库中与当前行为最为匹配的特征数据。检测引擎需要将特征数据与当前数据的相似性与基线进行比较，若比较结果显示当前行为与正常行为的差异在基线限制范围内，则为正常行为，若超出基线限制范围，则判定为异常行为。对于基线，首先需要根据专家知识设置合理的初始基线，并根据不同场景，或利用无监督模型自行调整基线，或由运维人员手动维护基线。