云原生安全架构设计最佳实践
发布时间：2022-06-07 15:55:08 所属栏目：安全 来源：互联网
导读：云原生技术以其高效稳定、快速响应的特点不断驱动着企业的业务发展，已成为目前企业数字业务应用创新的核心动力。但与此同时，云原生环境中的各类安全风险也在日渐增加，越来越多的企业也开始探索云原生环境中的安全架构设计方案。 2018年，随着云原生技术的
|
云原生技术以其高效稳定、快速响应的特点不断驱动着企业的业务发展，已成为目前企业数字业务应用创新的核心动力。但与此同时，云原生环境中的各类安全风险也在日渐增加，越来越多的企业也开始探索云原生环境中的安全架构设计方案。 2018年，随着云原生技术的发展，CNCF根据最新的云原生基础架构设施，重新对云原生进行了定义： 容器化 服务网格 微服务 不可变的基础设施 声明式的API 只要满足以上五个方向的特性就属于云原生应用了。 图片 随着云原生技术的不断变化，容器化使操作系统的功能与特性进一步精简。为满足云原生定义中不可变基础设施的条件，云原生操作系统应运而生。其特点是高度精简的内核，只保留容器相关的依赖库，使用容器客户端作为包管理器。 云原生操作系统的共同理念，是所有进程必须运行在容器中。操作系统的宿主机上不能安装任何应用程序，保证操作系统是完全不可变的，这就是所谓不可变的基础设施，也是操作系统未来的发展趋势。 早期的基础架构是运行在物理机上的，而后随着基础设施的变化，应用开始运行在虚拟机之中。到了容器时代，所有的应用都运行在容器之中。在最新的流行趋势里，目前国内外也有一些云厂商在提供对应的基础设施架构——Serverless无服务器技术。 在物理机时代，基础设施通常以年为运算单位的，当物理机上架到机房后，其会以一年或者五年作为生命周期下架。随后的虚拟机则是以月作为其运算单位。到了容器时代，每次更新都需要重新构建新的容器，因此容器的生命周期是以天为单位的。而在无服务器时代，函数虚拟化则会以分钟为单位。 容器化出现后，容器技术标准化的进程得到了加速。DevOps与容器相辅相成，应用容器平台，就需要演变成为DevOps开发模式以加速发布流程。容器化的便捷推广了DevOps，而容器又依赖DevOps来加快迭代速度，这是目前开发模式的演变趋势。 当以容器为单位时，云原生、服务则为网络边界。在云原生领域中，并没有IP的概念，所有云原生中的IP都是动态的，我们无法在传统的防火墙上配置对应的IP地址。在云原生之中，容器的服务每天都会更新，每次更新IP地址都会是一个新的IP地址，原先配置的网络策略均会失效。 物理机时代，物理机上架比较困难，因此通常会在一个物理机上跑多个应用。而虚拟机时代，为了提高服务的可用性，则通常会将单个服务拆分到单个虚拟机之上。再到现在，随着服务接口越来越多，越来越依赖于微服务化，则需要将接口演变成微服务架构。 云原生安全风险 目前，云原生领域需要考虑的安全问题主要有以下五个： 镜像安全 镜像仓库安全 集群组件安全 容器网络风险 微服务风险 图片 其中镜像安全风险是比较广泛的。相较于基础设施安全，云原生领域更加关注性能优化与基础设施容器化。这也导致目前DockerHub镜像之中，51%存在高危漏洞、80%存在中低危漏洞。而在企业构建镜像时，90%的情况下，都需要从DockerHub上下载镜像。 镜像仓库方面，企业不可能将所有的研发的镜像、业务镜像上传到一个公开的镜像仓库中，源代码需要存放在企业仓库。但企业仓库也同样会存在安全漏洞的，这些漏洞被黑客利用后，会直接导致仓库中的镜像被替换。当从节点上去拉镜像的时候，拉同一个镜像可能拉到的是黑客带有木马病毒的镜像，这也是非常危险的。 关于集群组件的风险，目前Docker自身存在111个漏洞、K8S存在65个漏洞、Open Shift存在35个漏洞，其他容器运行时例如Cri-o、Containerd与Kata Container，一共包含45个漏洞。集群组件漏洞相对较少，但也是同样存在的。 当黑客通过上述漏洞入侵到集群中后，会继续访问其他集群内容器。物理防火墙，只能防护集群外流量，集群内的流量K8S有overlay与underlay两种网络架构。但无论是overlay还是underlay，传统防火墙都无法防护集群内的攻击情况，这便是集群内的网络风险。 （编辑：PHP编程网 - 黄冈站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
浙公网安备 33038102330482号