随着云原生技术的发展，业务系统从原有的单体架构逐步转换为微服务架构。微服务架构使应用的开发和业务的扩展变得更加便利，同时也带来了许多新的安全问题。那么，生长在云原生环境下的业务系统面临着哪些安全隐患？攻击者如何利用这些隐患对业务系统进行攻击？针对所存在的隐患和可能面临的攻击如何进行异常检测和安全防护？各位读者将在《云原生安全：攻防实践与体系构建》书籍中找到答案。
微服务架构为业务系统带来了新的安全隐患
01
由于微服务架构刚好符合开发者所期盼的业务抽象能力，面向微服务的开发已经被众多开发者所选择，业务系统微服务化已经成为不可避免的趋势。在享受微服务为开发带来便捷的同时，安全性也成为了不可忽视的问题。若是业务系统出现安全问题，由于微服务架构整个应用被分成多个服务，定位故障点将会非常困难。而且，微服务架构中一个服务出现故障可能会产生雪崩效应，导致整个业务瘫痪。 尽管上述情况是我们需要极力避免的，但其在实际微服务业务系统中却极有可能会发生。从攻击者的角度来看，微服务业务系统所包含的服务数量众多，服务间通过API进行通信使得暴露端口数量多，攻击面更大，与单体架构应用相比可渗透的机会更多。从防守方角度说，微服务的组织结构更加复杂，导致防守策略的设计和防守方案的部署也变得更加困难。
部署在云原生环境下的业务系统面临的风险
02
笔者看来，云原生应用风险主要是Web应用风险，即网络层面的风险，而云原生应用业务风险无明显的网络攻击特征，多是利用业务系统的漏洞或规则对业务系统进行攻击来牟利，从而造成一定的损失。 此外，与传统应用架构中的业务风险不同，微服务应用架构中，若服务间的安全措施不完善，例如用户授权不恰当、请求来源校验不严格等，将会导致针对微服务业务层面的攻击变得更加容易，例如针对一个电商应用，攻击者可以对特定的服务进行攻击，例如通过API传入非法数据，或者直接修改服务的数据库系统等。攻击者可以绕过验证码服务，直接调用订单管理服务来进行薅羊毛等恶意操作。攻击者甚至可以通过直接修改订单管理和支付所对应的服务系统，绕过支付的步骤，直接成功购买商品等。 综上，笔者认为，应用微服务化的设计模式带来的业务风险可包含两方面，一方面是未授权访问风险，典型场景为攻击者通过权限绕过对业务系统的关键参数进行修改从而造成业务损失，另一方面则是API滥用的风险，典型的是对业务系统的薅羊毛操作。
未授权访问的风险
云原生业务环境中，笔者针对造成未授权访问风险的原因进行了分析，可以大致分为业务参数异常和业务逻辑异常两方面，为了更为清晰的说明上述异常如何导致未授权访问的风险，笔者以一个微服务架构的电商系统举例说明。如图1所示：
图1 电商系统业务流程图
业务参数异常。API调用过程中往往会传递相关的参数。参数的取值根据业务场景的不同会有不同的取值范围。例如商品数量必须为非负整数，价格必须大于0等。如果API对相应参数的监测机制不完善，那么攻击者往往可以通过输入异常参数导致业务系统受到损失。例如在电商系统中，如果商品价格只在商品介绍服务中进行校验，而在订单管理和支付服务中没有进行校验，那么攻击者就可以通过直接调用订单管理和支付服务的API来将订单价格修改为0元或者负值，给业务系统造成损失。 业务逻辑异常。相比于前两类异常，这类异常一般较为隐蔽。攻击者采用某些方法使API调用的逻辑顺序出现异常，包括关键调用步骤缺失、颠倒等。例如在电商系统中，攻击者可以利用漏洞绕过交费的步骤直接提交订单。这样就会出现业务逻辑出现关键步骤缺失的情况。对于前述业务频率异常中的验证码绕过异常，也属于业务逻辑异常。
API滥用的风险
针对此类风险，通常指的是攻击者对业务系统的薅羊毛操作，风险成因则是由于业务频率异常所致，这里笔者依然以电商系统举例说明。 针对一个或者一组API的频繁调用。业务系统往往通过图形验证码的方式来避免机器人刷单的操作。攻击者可以绕过验证码所对应的微服务，直接对订单进行操作，进而实现机器刷单，对电商进行薅羊毛。
基于基线对业务系统进行异常检测
03
为了应对微服务业务系统所面临的安全风险，基于基线的异常检测是一类比较有效的方法：首先建立正常业务行为与参数的基线，进而找出偏移基线的异常业务操作，其中，基线的建立需要结合业务系统的特性和专家知识共同来完成。 为此，我们设计了基于基线的异常检测方案。
图2 业务异常检测引擎设计图
此方案中各个模块的功能为： 分布式追踪工具。采集微服务业务系统运行时生成的数据。目前常用的开源分布式追踪工具有Jaeger和Skywalking，它们对异常检测上的帮助各有所长。Jaeger在部署上对软件系统有较强的侵入性，需要在代码中进行插桩，但可以获取完整的数据信息。Skywalking与Jaeger相比，可以获取的数据信息更少，比如无法获取HTTP请求体信息，但其采用了字节码注入技术，通过控制虚拟机的类加载器完成追踪与数据采集，无需修改业务系统的源代码。此外，也可以选择sidecar截取业务容器上下游的流量信息进行数据采集，但目前sidecar无法独立实现追踪功能，获取的数据集中没有API调用树（TraceID）信息，需要利用算法对追踪序列进行还原。由于业务系统自身采用的分布式追踪工具是不同的，而且其中有些业务系统没有部署追踪工具，检测引擎需要适配不同的追踪工具，在所能获取到的数据字段下最大程度的覆盖多种场景的异常检测。 数据筛选与整合模块。过滤数据集中的脏数据，并提取出可以表示业务系统行为的数据字段。 数据训练模块。利用机器学习或统计学的方法，训练出业务系统中的正常行为，并生成与业务系统正常行为匹配的特征数据。在训练过程中，需要根据专家知识对训练结果进行检验并不断调整训练模型的参数。 检测引擎。将业务系统当前数据与特征数据库中数据进行检索匹配，并将检索出的特征数据与当前数据的相似度同基线进行比较，进而检测出偏移基线的异常业务操作。初始基线需要由安全专家设置，基线的维护则需要根据业务的特性采用不同的方法，常用的维护方法包括利用无监督的机器学习模型自动维护以及由运维人员手动维护。
总结
04
业务在明，黑产在暗，本身在对抗层面防守方就处于劣势，黑产有充足的时间通过小规模的试探摸清线上的业务规则，从而进行后续大规模的出击。在这种劣势条件下，怎样走在黑产的前面将防护工作做好，保障微服务业务的安全，仍旧是一项巨大挑战。《云原生安全：攻防实践与体系构建》书籍中融合了笔者以及其他作者在业务安全上的研究经验，盼望此书籍可为广大读者在微服务业务安全上的研究提供帮助。 本文旨在对《云原生安全：攻防实践与体系构建》书籍中的业务安全部分进行精华解读。若需要详细了解云原生业务安全或希望对云原生安全有更加宏观的了解，请参照具体书中章节，若有任何问题可随时联系作者。
本文选自《云原生安全：攻防实践与体系构建》，经出版方授权发布。
END
