云原生时代的安全变化趋势

云原生技术为软件运行平台、应用软件架构和应用开发流程带来了标准化和统一化。可以说重塑了 IT 的形态，这个重塑并不是以一种推倒重建的方式来施行，而是用一种循序渐进的方式、以自然演进的步调来推进的。理解云原生时代数字化建设所面临的问题，从这些变革和问题入手，思考云原生时代的安全变化趋势。

1、应用运行环境边界模糊化

在云计算时代之前，IT 基础设施是一种资产。传统的应用运行环境是物理的，看得见、摸得着的，而且从计算存储资源到网络基础设施构建，这些资源和网络的边界是非常清晰的。

首先，基础设施资源（包括服务器、存储系统、网络传输硬件）都统一部署在数据中心机房内。这些硬件通过网络进行连接，专门的 IT 架构设计和维护人员进行硬件和网络的规划。

在网络安全方面，在数据中心网络出口部署防火墙，再在网络架构中的适当位置安置 IPS 和 IDS 系统，划分内外网区域和 DMZ 隔离区域，最后再配备防病毒系统和上网行为管理系统。在硬件资源划分上，根据自身的组织结构以及业务量和业务特性，分配适当的计算和存储资源，并进行网络的配置和安全业务的配置和管理。

虽然从其逻辑结构来看，在云环境下构建的一套云数据中心跟传统数据中心类似。同样也有计算、存储和网络资源，同样也有一套网络分布架构，但是与传统数据中心的区别是明显的，即云数据中心是虚拟的，用户是看得见但摸不着的。

通常情况下相对于常规 IT，云计算服务提供商的安全管理水平是比较高的，但是无论水平多高都会有漏洞。比如大型的公有云厂商，每个月都会有几十个漏洞被发现。此外，供应链安全问题、内部人员可靠性问题等因素，都是造成安全事故的巨大隐患。从这些现状来看，云时代对应用自身的内生性安全性要求就高了。

2、应用内生性安全要求

云原生时代意味着信息化建设的焦点从以往专注于网络及其他硬件基础设施转变为专注核心业务的信息化建设。同时，在云计算资源的全面普及使用的背景下，业务系统的跨云迁移和跨云扩展更为普遍，这带来了应用运行环境边界的模糊化。在这种环境边界下，基础设施层的安全由云服务厂商来负责，而云业务应用自身的安全要求就凸显出来了。这种云业务应用自身的安全性要求体现在以下几个方面。

• 应用是动态的、可迁移的。在迁移后，应用的网络边界其实发生了变化，变化了之后，应用的安全保障如何开展，就要求应用自身具备较强的安全能力，不能有安全漏洞，在应用架构上的安全性保障不能缺失。

• 应用架构里使用的技术中间件，比如 Redis、Kafka、网关等，这些中间件中的数据的安全性保障是一个问题。在通常意义上，应用架构使用的这些中间件的安全重要性不高，尤其是在传统网络边界安全管控方案中，这些中间件本身的安全控制是被忽略的。但是，在分布式应用架构中，这些中间件要么存储着业务应用的动态数据，要么控制着业务应用微服务之间内部应用的访问，它们对业务应用的安全带来的影响很大。

• 应用在微服务化后，组件分散，应用发布的包零散，而且微服务架构中的公共组件比如微服务注册中心、微服务治理等组件的安全性保障也尤为重要。

3、应用内安全监测及管控

业务应用本身是信息化建设的核心资产，在安全层面的监测及管控本身就应该面向核心资产来展开。过去在安全上的策略往往都是从网络和数据中心资源层面来入手管理，随着云原生化的普及，在云原生时代，安全的监测和管控逐步将重心转移到应用层。

在传统业务应用架构领域，对应用内的安全监测和管控能力很弱。应用服务之间的通信是无法动态控制的，传统的手段只有网络层的管控。管控的结果只有两个：一个是通，另一个是不通。类似于应用通路通断控制的情况，应用内生性管控的要求还有以下这些方面。

• 应用通路加密。动态控制两个应用访问通路的加密策略、密钥有效期，如何更换密钥。

• 微服务访问 QPS（每秒查询率）配置。默认情况下，微服务之间的访问调用并没有限速控制。在某些异常情况下，内部系统受到不间断的大量异常请求调用，直至业务系统出问题。此外，云原生生态下，生态应用以服务的方式对外部世界提供接口。这种场景下，控制应用对外提供服务的 QPS 尤为重要。

• 在云原生趋势下，业务应用朝着微服务化的方向发展，微服务架构在带来可扩展性、业务进化速度等优势的同时，也带来了架构复杂、维护管理困难的问题。如何从业务应用整体安全视角来监视和管理微服务之间的调用，在云原生体系中是一个挑战。

4、数据访问安全和数据保护

如果从宏观高度来观察整个信息化系统，说到底最终还是业务处理逻辑对业务数据的写入、检索和分析。云原生化的信息系统也是如此，只是云原生应用系统是基于云和容器技术的，在可扩展能力和可迁移能力方面有质的变化。

业务应用系统使用的数据库有两类，一类是关系型数据库，另一类是非关系型数据库。关系型数据库的特点是事务一致性处理能力和复杂 SQL 业务逻辑查询；非关系型数据库的常规用途是用作数据记录和数据分析场景，其数据存储容量大，对非结构性的数据格式支持能力强。

应用使用的关系型数据库通常是数据库服务。数据库服务与数据库的区别在于：数据库服务并不强调数据库实例本身，而是强调关系数据库本身的能力；应用使用其能力，而实例的创建、监控、维护扩展等工作都是由云服务器提供商来支持的。由于数据库服务并没有一个“关在”机房里的服务器，而是云里的一个实例，对于数据的访问更多的是要在数据库服务的操作界面和应用层中来控制。

与关系型数据的使用方式类似，种类多种多样的非关系型大数据存储分析平台在云原生环境下也往往都是以数据库服务的方式来提供和使用。针对大型的大数据库平台，在云环境下，同一个大数据平台会同时被多个租户来租用。

毫无疑问，数据是信息系统中最重要的资产。在云环境下，如何保护这个重要的资产、如何控制对资产的访问、确保资产不会泄露和被滥用，是云原生系统设计当中的重要课题。

5、自动化软件开发流程

传统的软件开发工程流程包含需求分析、软件设计、软件开发、软件测试、软件上线、软件维护这六个流程阶段，开发出一个满足发布要求的软件版本通常需要 3～6 个月乃至更长的时间。在软件上线环节，除了进行网络和硬件规划之外，也需要对软件运行环境的安全方案进行分析及实施。

传统的软件工程模式整体上是采用步步为营、稳扎稳打的方式。在需求分析阶段确保软件需求设计的合理性；通过完善的软件架构设计、设计一套适合运行的软件架构方案；再通过长时间的整体软件测试，确保发布质量。在这种模式被正常执行的情况下，很少出现软件整体框架性的失误。但是这种开发模式的问题在于其无法适应业务的快速变化。

在云原生形态下，软件基础平台使用标准化、容器化的 Kubernetes 平台；软件基础架构采用微服务架构和云服务化的数据库和中间件。通过利用这些基础平台能力，软件在架构设计和架构开发层面的工作量呈数量级的减少，跟以往相比，几乎可以将工作量减少到零。

云原生推崇开发、测试、运维一体化和敏捷开发文化，践行基于自动化流水线的持续交付，结合微服务和容器化开发部署模式，实现业务应用的快速上线和快速更新。一个新业务需求的实现通常只需要修改或者扩充一两个微服务应用，通过自动化构建、代码扫描、测试和上线，能够实现新业务在一两周内迅速上线。

速度和安全是相互矛盾的两面，单纯追求业务的创新速度和上线速度，势必对业务稳定运行及应用安全维护造成挑战。在业务稳定方面，基于容器和 Kubernetes 的平台通过故障检查、故障自愈和弹性扩容等能力优势，能够在架构层面解决大部分业务基础的稳定性问题。至于在应用安全保障和维护方面，需要一套与 DevOps 流程匹配的自动化安全管控和维护流程。让应用从开发、运维到安全都有一套完整的 IT 流程。