云原生安全_思维导图模板

云原生安全

云原生安全概述

云原生安全

云原生系统特性：轻、快、不变的基础设施；弹性服务编排；开发运营一体化；微服务架构；微服务模型

面向云原生环境的安全

目标：防护云原生环境中基础设施、编排系统和微服务等系统安全

容器安全

容器环境基础设施的安全

容器的镜像安全

容器的运行时安全

整个容器生态的安全性

编排系统安全

kubernetes安全

云原生应用安全

具有云原生特性的安全

原生安全：融合的云原生安全

云原生安全的关键问题

如何防护短生命周期的容器

攻击者喜欢更为持久化的东西：如代码、第三方库、镜像等资产

如何降低安全运营成本

“安全左移”策略：从重视运行时安全转向先从开发侧解决最基本和最容易的问题

DevSecOps

安全能力应覆盖开发和运营闭环的每个环节

如何实现安全的云原生化

安全架构具备编排能力

容器和宿主机安全：安全特权容器

业务安全：Sidecar安全容器（本质上是一种提供反向代理的容器）

云原生安全现状

云原生新范式：Docker+Kubernetes

镜像安全问题仍然很突出

大量的Docker Hub官方镜像存在安全隐患

安全配置规范执行和密钥凭证管理不理想

运行时安全关注度上升，但依然很难

合规性要求依然迫切，但业界苦于无规可循

云原生技术

容器技术

容器与虚拟化、容器镜像

容器存储：镜像元数据、存储驱动、数据卷

容器网络：主机网络（None网络模式、Bridge网络模式、Host网络模式和Container模式）、集群网络

容器运行时：容器镜像格式、构建镜像、上传和拉取镜像、管理镜像、管理容器实例、运行容器等

容器编排

Kubernetes、Apache Mesos、Docker Swarm、OpenShift、Rancher等

微服务

第一代：以Dubbo、Spring Cloud为代表的微服务治理框架

第二代：微服务治理框架为服务网络

服务网络（Service Mesh）

所有通过服务的流量都经过Sidecar，因此Sidecar可实现流量控制：服务发现、负载均衡、智能路由、故障注入、熔断器、TLS终止等

以Istio为代表

Serverless

两种实现方式：BaaS（Backend as a Service，后端即服务）、FaaS（Functions as a Service，函数即服务）

FaaS本质上是一种事件驱动并由消息触发的服务，典型代表AWS Lambda

凭借其服务端托管的特点降低了运维成本、规避了一定的安全风险，使开发者专注于应用逻辑实现，是未来云原生应用的一大趋势

DevOps

云原生提供DevOps基础设施

DevOps核心店：持续集成、持续交付

微服务架构加速DevOps的应用

无状态性、弹性扩展、高内聚、低耦合

DevOps赋能服务网格

DevOps加速Serverless应用迁移

云原生技术的风险分析

容器基础设施的风险分析

容器基础设施面临的风险

容器镜像存在的风险

不安全的第三方组件

大肆传播的恶意镜像

极易泄露的敏感信息

活动容器存在的风险：不安全的容器应用、不受限制的资源共享、不安全的配置与挂载

容器网络存在的风险

容器管理程序接口存在的风险

Docker守护进程主要监听两种形式的Socket：UNIX socker和TCP socket

安装完成并启动后，Docker守护进程默认只监听UNIX socket

宿主机操作系统存在的风险

容器和宿主机共享内核，容易容器逃逸，获得宿主机的控制权

无法根治的软件漏洞

针对容器化开发测试过程的攻击案例

CVE-2018-15664：符号链接替换漏洞

CVE-2019-14271：加载不受信任的动态链接库：（1）确定目标（2）构建动态链接库（3）实现逃逸

针对容器软件供应链的攻击案例

镜像漏洞利用

镜像本身存在漏洞

镜像投毒

投放恶意挖矿镜像、投放恶意后门镜像、投放恶意exploit镜像（大多是容器逃逸类型漏洞：如CVE-2016-5195、CVE-2019-5736）

针对运行时容器的攻击案例

所有攻击影响的是业务系统的机密性、完整性和可用性（CIA三要素）

容器及安全容器逃逸

不安全配置导致的容器逃逸、不安全挂载导致的容器逃逸、相关程序漏洞导致的容器逃逸（CVE-2019-5736）、内核漏洞导致的容器逃逸（CVE-2016-5195）

从容器发起的资源耗尽型攻击

计算资源、存储资源、软件资源、通信资源

容器编排平台的风险分析

容器编排平台面临的风险

容器基础设施存在的风险、Kubernetes组件接口存在的风险（API Server、Dashboard、Kubelet、etcd）、集群网络存在的风险、访问控制机制存在的风险、无法根治的软件漏洞

针对Kubernetes组件不安全配置的攻击案例

Kubernetes API Server未授权访问、Kubernetes Dashboard未授权访问、Kubelet未授权访问

针对Kubernetes权限提升的攻击案例

针对Kubernetes的拒绝服务攻击案例

CVE-2019-11253：YAML炸弹
CVE-2019-9512/9514：HTTP/2协议实现存在问题

针对Kubernetes网络的中间人攻击案例

防御策略：为集群配置安全上下文（Security Context）禁用Pod的CAP_NET_RAW权限

K8S提供三种不同粒度的安全上下文配置方式：容器级别、Pod级别和集群级别

云原生应用的风险分析

云原生应用风险概述

云原生应用继承了传统应用的风险和API的风险
应用架构变革将会带来新的风险
计算模式变革将会带来新的风险

传统应用的风险分析

以web应用风险为主：注入、敏感数据泄露、跨站脚本、使用含有已知漏洞的组件、不足的日志记录和监控等风险

云原生应用的新风险分析

信息系统安全等级三要素：机密性、完整性和可用性

数据泄露的风险：应用漏洞带来的风险、密钥不规范管理带来的风险、应用通信未经加密带来的风险

未授权访问的风险：应用漏洞带来的风险、访问权限错误配置带来的风险

拒绝服务的风险：应用漏洞带来的风险、访问需求与资源能力不匹配带来的风险

云原生应用业务的新风险分析

未授权访问的风险：业务参数异常带来的风险、业务逻辑异常带来的风险

API滥用的风险

Serverless的风险分析

Serverless特征带来的风险：输入源的不确定性带来的风险、服务器托管云服务商带来的风险、供应商锁定带来的风险

Serverless应用风险

Serverless平台风险

未授权访问的风险：访问权限错误配置带来的风险、脆弱的函数运行时环境带来的风险
数据泄漏的风险：访问权限错误配置带来的风险、平台漏洞带来的风险、脆弱的函数运行时环境带来的风险
FaaS平台账户的风险
攻击实例介绍：针对AWS Lambda平台账户的DoW攻击、利用AWS Lambda运行时进行未授权访问、数据窃取、植入恶意木马攻击（攻击者利用Lambda函数漏洞进行shell权限获取、攻击者恶意构造Lambda函数进行shell权限获取）

AWS Lambda利用shell攻击，主要通过对“可写目录”、“AWS IAM”、“环境变量”三者利用，进行“未授权访问”、“窃取敏感数据”、“植入恶意木马”三类攻击

Serverless被滥用的风险

被滥用的原因：云厂商提供Serverless函数的免费试用、用户部署Serverless函数的成本低、Serverless函数访问域名可信

典型云原生安全事件

特斯拉Kubernetes挖矿事件

微软检测到大规模Kubernetes挖矿事件

Graboid蠕虫挖矿传播事件

攻击者通过不安全的Docker守护进程获取目标主机控制器，间接从Docker Hub拉取上传恶意镜像

云原生安全防护思路和体系

云原生防护思路转变

变化：容器生命周期、安全左移、聚焦不变、关注业务

云原生安全体系

横轴：开发和运营阶段，细分为编码、测试、集成、交付、防护、检测和响应

纵轴：按照IT系统层级划分，包括基础设施、编排平台和服务应用三层

左移的安全机制

安全左移：将安全的控制从运营侧向开发侧倾斜，二开发侧主要涉及开发安全、软件供应链安全和镜像安全

容器镜像安全

容器镜像安全现状

容器镜像安全防护

容器镜像构建安全：验证镜像来源、镜像轻量化、正确使用镜像指令、敏感信息处理

容器镜像仓库安全：公共仓库安全、私有仓库安全

容器镜像安全检测：扫描引擎有Docker Security Scanning（未开源）、Clair（开源）和Anchore（开源）

容器镜像传输安全：数字签名、用户访问控制、尽可能使用支持HTTPS的镜像仓库

云原生可观测性

可观测性概述

云原生的代表技术：容器、服务网格、微服务、不可变基础设施和声明式API

云原生主机系统的行为更复杂、“未知攻焉知防”可见才可防、助力“等保2.0”可信计算需求

云原生的最终目标是通过自动化手段，实现敏捷的松耦合系统

需要观测什么

传统的监控指标+容器、Pod、Server等层面的指标；Pod之间的虚拟化网络；应用层的调用等

实现手段

日志、指标、追踪

日志审计

网络安全审计

按照一定的安全策略，利用记录、系统活动和用户活动等信息，检查、审查和检验操作时间的环境及活动，从而发现系统漏洞、入侵行为或改善系统性能的过程

需求分析

等保合规要求：网络日志不少于六个月；二到四级要求对网络、主机、应用安全三部分日志进行审计

业务需求

面临的挑战

日志审计本身面临的挑战：日志存储分散、日志数据量大、日志格式不统一

针对云原生环境及云原生应用的特性，其平台、网络以及应用在架构和行为上较传统IT系统都有着更大的复杂性

Docker日志审计

每个Docker守护进程都有一个默认的日志驱动程序，默认json-file

审计Docker文件和/var/li/docker目录、审计Docker文件和/etc/docker目录、审计Docker文件和docker.socket目录

Kubernetes日志审计

应用程序日志：无原生的日志存储方案，使用kubectl logs即可通过标准输出打印相关日志

系统组件日志：可以根据需要配置日志的粒度，灵活调整日志记录的细节程度

日志工具：Zebrium、Elastic Stack、CloudWatch、Fluentd等

监控

云原生架构的监控挑战

监控维度更复杂、资源消耗更大

监控指标

Kubernetes组件状态指标、集群状态指标、资源状态指标、网络状态指标、作业运行指标

监控工具

CAdvisor和Heapster、Prometheus

跟踪

追踪面向的是请求：针对主机的动态追踪、针对微服务的应用行为追踪

动态追踪：一种高级的内核调试技术，通过探针机制，采集内核态或者用户态程序的运行信息。资源损耗小，无风险。DTrace

容器基础设施安全

Linux内核安全机制

隔离与资源管理技术

内核命名空间（namespace）、控制组（Cgroup）

内核安全机制

Capabilities、Seccomp、AppArmor、SELinux

容器安全加固

宿主机对容器的影响

宿主机中安装了有漏洞的软件可能导致任意代码执行风险

端口无限制开放可能会导致任意用户访问风险

防火墙未正确配置会降低主机的安全性

sudo的访问权限没有按照密钥的认证方式登录可能导致暴力破解宿主机

容器安全配置

为容器的存储分配单独的分区

宿主机安全加固

将Docker更新到最新版本

守护进程的控制权限

对Docker守护进程进行审计

对Docker相关的文件和目录进行审计

容器环境的行为异常检测

基于规则的已知威胁检测

检测系统设计：控制器、规则引擎、规则集、告警模块、探针

基于规则的检测实战：CVE-2019-5736实现容器逃逸

针对已知威胁，特征准确、覆盖面广、更新及时的基于规则的检测机制是非常有效，且是高性价比的

基于行为模型的未知威胁检测

检测思路：从大量模式中将异常模式甄别出来，再对异常模式进行进一步的归类和判断

检测系统架构、学习与检测流程、基线设计

针对未知威胁，由于没有足够的先验只是，防守者需要在“异常假设”上做文章

容器编排平台安全

Kubernetes安全加固

关注点：Kubernetes资源自身的安全性、资源间的通信安全、资源的密钥管理

API Server认证

实现了Kubernetes资源增、删、改、查的接口

静态令牌文件认证机制：在HTTP请求的头部加入静态令牌以达到认证的目的

X.509客户端证书：也称HTTPS证书认证，是基于CA根证书签名的双向数字证书认证方式（K8S默认开启参数配置，client-ca-file、tls-private-key-file、tls-cert-file）

服务账号令牌：是K8S默认启用的用户认证机制，可通过kubeadm自动生成API Server私钥。核心是服务账号及其携带的令牌

OpenID Connect令牌：一种基于OAuth2的认证方式

身份认证代理：核心是API Server可使用用户指定的HTTP头部字段提取用户身份认证信息。

Webhook令牌身份认证：一种用来验证用户令牌的回调机制，集群管理员可在kube-apiserver配置中启动实现

API Server授权

K8S包含四类授权模式：节点授权、基于属性的访问控制（ABAC）、基于角色的访问控制（RBAC）、基于钩子方式（Webhook）的授权

准入控制器

准入控制器原理：MutatingAdmissionWebhook变更准入控制器、ValidatingAdmissionWebhook验证准入控制器

Pod安全策略：是集群级别的资源，主要在Pod创建和更新阶段提供细粒度的权限控制

Secret对象

Secret包含传递和访问两个行为

三种传递方式：将Secret构建至容器镜像中、通过K8S环境变量、挂载宿主机文件系统

访问Secret的两种方式：容器内访问Secret、kubelet组件访问Secret

网络策略

支持网络策略的网络插件：Calico、Cillum、Kube-router、Romana、Weave

网络策略不会冲突，累加取并集，不会影响策略结果

K8S网络策略配置中通过三个标识的组合来辨识可以与Pod通信的实体：其他被允许的Pod、被允许的命名空间、被允许的IP组（例外，与Pod运行所在节点的通信是允许的）

云原生网络安全

云原生网络架构

基于端口映射的容器主机网络

基于CNI的Kubernetes集群网络

服务网络（Service Mesh）

通过逻辑上独立的数据平面和控制平面来实现微服务间网络通信的管理

SDN主要解决L1-L4层的数据包转发问题

Service Mesh主要解决L4/L7层微服务应用间通信的问题

基于零信任的云原生网络微隔离

微隔离：是一种更细粒度的网络隔离技术，核心能力
核心能力诉求：聚焦东西向流量
重点：阻止当攻击者进入数据中心网络或者云虚拟网络后进行的横向移动
核心控制单元：策略控制中心

云原生为什么需要隔离：区别于传统网络隔离，在云原生环境中，容器或者微服务生命周期短，变化频率高，关系复杂

云原生网络的微隔离实现技术

IaaS层面的微隔离机制：基于虚拟化技术（Hypervisor）、基于网络（Overlay，SDN）、基于主机代理（Host-Agent）

云原生环境两种网络微隔离机制：基于Network Policy实现、基于Sidecar实现

云原生网络入侵检测：实现对Kubernetes集群中每个节点Pod相关的东西及南北向流量进行实时监控

基于Cilium的网络安全方案示例

Cilium可以透明的对Kubernetes等容器管理平台上的应用程序服务之间的网络连接进行安全防护

Cilium是基于Linux的一种新的内核技术eBPF

Cilium三方面特性：
提供K8S中基本的网络互通能力、
依托eBPF实现K8S中网络的可观测性以及基本的网络隔离和故障排查等安全策略、
依托eBPF突破传统主机防火墙仅支持L3/L4微隔离的限制支持基于API的网络安全过滤能力

Cilium架构：主要包括Cilium Agent和Cilium Operator

Cilium组网模式：默认采用基于vxlan的Overlay组网，其他包含
1）通过BGP路由的方式，实现集群间Pod的组网和互联
2）在AWS的ENI模式下部署使用Cilium
3）Flannel和Cilium的集成部署
4）采用基于ipvlan的组网，而不是默认的基于veth
5）Cluster Mesh组网，实现跨多个Kubernetes集群的网络连通和安全性等多种组网模式

Cilium在Overlay组网下的通信示例：主机内Pod通信、跨主机Pod通信

API感知的安全性：安全可视化与分析、微隔离的实现

云原生应用安全

面向云原生应用的零信任安全

什么是信任

指主体A对主体B未来发生行为action（B）的依赖意愿

信任管理四要素：主题身份属性确认、资源的属性确认、主题对资源操作的授权、操作控制

真的有零信任吗

从人性的角度看，世界上“没有”零信任

从技术的角度看，世界上是“有”零信任

零信任的技术路线

身份和权限管理、网络访问控制、区域隔离、应用安全