前言
云安全不是一种新的漏洞利用技术，而是当基础设施迁移到云上之后，安全边界从“服务器”扩展到了“身份、权限和云资源”，从而产生的一整套新的攻防体系。
先分享一个云安全的知识库：
teamssix/awesome-cloud-security: awesome cloud security 收集一些国内外不错的云安全资源，该项目主要面向国内的安全人员
感谢yuppt师傅的分享，大家可以去b站给yu师傅点点赞投投币orz
这一篇博客并没有关于云安全的具体知识点，更多的是建立起一个大观框架，我觉得这样比一股脑钻进那些陌生的名词中更好理解
另：我写博客肯定是按照我的视角做学习的记录的，所以不一定适合别人参考，要是能帮到你更好
为什么会有云安全
要理解云安全，首先要理解系统部署方式的变化。
在传统服务器时代，企业通常自己购买服务器、部署机房、安装系统、配置网络，然后在服务器上运行 Web 服务、数据库、中间件等组件。
这时安全人员关注的重点通常是：
Web 应用漏洞服务器入侵系统提权数据库安全内网渗透例如 SQL 注入、XSS、文件上传、命令执行、Linux 提权等，都是传统 Web 安全和 CTF 中非常常见的内容。
后来，越来越多企业开始使用云计算。
企业不再需要自己购买大量物理服务器，而是通过云厂商购买计算、存储、数据库、网络、容器、日志、监控等服务。
部署模式变成了：
开发者 ↓云账号 ↓云资源 ↓业务系统这带来了效率提升，也带来了新的安全问题。
以前，一个配置错误可能只影响一台服务器；而在云环境中，一个高权限访问密钥泄露，可能影响整个云账号下的所有资源。
这就是云安全出现的背景。
云安全的本质并不是“保护云服务器”这么简单，而是保护云环境中的身份、权限、资源和数据。
什么是云安全
可以先给出一个简单定义：
云安全是指在云计算环境中，对云平台、云资源、身份权限、网络边界、数据存储、容器编排和自动化部署流程进行保护的一系列安全技术和管理方法。
这个定义比较长，可以拆开理解。
云安全至少包括几个核心对象。
云平台安全
云平台是云安全的基础环境。
常见云平台包括 AWS、Azure、Google Cloud、阿里云、腾讯云、华为云等。
在这些平台中，用户可以创建：
云服务器对象存储云数据库负载均衡VPC 网络容器集群函数计算日志服务密钥管理服务这些资源不再是传统意义上的“单台服务器”，而是由云平台统一管理的服务。
因此，安全边界也发生了变化。
传统安全中，我们可能重点关注某台服务器的端口、进程和系统漏洞；而云安全中，还必须关注云账号、访问密钥、权限策略、资源暴露面和云服务配置。
身份与权限安全
身份权限是云安全中最核心的部分之一。
在传统服务器环境中，权限问题通常体现为：
普通用户能否提权到 root而在云环境中，权限问题变成了：
某个用户、角色或访问密钥能操作哪些云资源例如，一个云访问密钥可能拥有以下权限：
读取对象存储创建云服务器管理数据库修改安全组创建新的 IAM 用户绑定管理员策略如果这个密钥泄露，攻击者不一定需要拿到服务器 root 权限，也可能直接通过云 API 控制大量资源。
所以在云安全中，一个非常重要的原则是最小权限原则。
也就是：
一个身份只应该拥有完成工作所必需的最小权限这和传统 CTF 中“找到漏洞拿 flag”的思路不同。云安全更强调权限设计、权限收敛和权限审计。
云资源配置安全
云环境中大量安全事件并不是来自复杂漏洞，而是来自配置错误。
例如：
对象存储桶被设置为公开读数据库暴露在公网安全组开放 0.0.0.0/0 的高危端口访问密钥长期未轮换日志审计未开启Kubernetes API Server 暴露公网这些问题看起来并不“高级”，但在真实环境中非常危险。
传统 CTF 往往强调漏洞利用技巧，而云安全中的很多问题来自资源配置和权限治理。
因此，云安全工程师需要具备一种不同的视角：
不仅要知道系统能不能被打穿，还要知道系统为什么会暴露、权限为什么过大、配置为什么不合理。云原生安全
现代云环境通常不仅仅运行虚拟机，还会大量使用 Docker、Kubernetes、微服务和 CI/CD。
这部分通常被称为云原生安全。
典型对象包括：
Docker 镜像容器运行时Kubernetes 集群Service AccountRBAC 权限IngressSecretCI/CD Pipeline镜像仓库例如，在 Kubernetes 中，一个 Pod 内部可能挂载了 Service Account Token。如果这个 Token 权限过大，攻击者在拿下容器后，就可能继续访问 Kubernetes API，从而横向移动到整个集群。
攻击路径可能是：
Web 漏洞 ↓进入容器 ↓读取 Service Account Token ↓访问 Kubernetes API ↓获取 Secret ↓控制更多服务这类攻击链已经不是传统 CTF 中单点漏洞利用的思路，而是云原生环境下的身份、权限和资源控制问题。
云安全与传统安全的关系
很多人在刚接触云安全时都会有一个误区：
云安全是不是一种新的安全方向？
我现在更倾向于认为：
云安全不是替代传统安全，而是在云时代对传统安全的扩展。
我们熟悉的很多攻击技术依然存在。
例如：
SQL注入
XSS
SSRF
命令执行
权限绕过这些漏洞不会因为系统部署在云上而消失。
区别在于：
这些漏洞不再是终点。
而是进入云环境的入口。
以前：
漏洞 ↓服务器今天：
漏洞 ↓服务器 ↓云身份 ↓云资源因此对于安全从业者来说：
学习云安全并不是放弃过去学过的内容。
而是在已有安全基础之上，进一步理解云环境中的身份、权限和资源之间的关系。
云安全知识地图
在引言部分提到的，这是一份非常有价值的云安全知识库：
从整个知识库的结构中，可以大致看到云安全的主要组成部分：
云安全│├── 云平台基础│├── 身份与权限安全│├── 网络与边界安全│├── 对象存储安全│├── 云原生安全│ ├── Docker│ └── Kubernetes│├── 云攻防│└── 安全运营与审计它既包含传统安全内容，也包含云计算、容器、Kubernetes 和自动化运维相关知识。
因此学习云安全的过程，本质上是在补齐现代基础设施的认知。
我的后续学习路线
其实是去问GPT后续的学习方向的，这里也说出来，给大家一个参考，也可以根据我的学习成果判断这个思路可不可行，但是我学的可能比较慢（拖延症晚期）
第一阶段：建立云安全认知
这一阶段的目标不是学习具体技术，而是建立整体视角。
重点需要解决的问题包括：
- 云安全为什么会出现
- 云安全与传统安全的区别是什么
- 云环境中的攻击目标发生了哪些变化
- 云安全领域主要包含哪些方向
在这一阶段，需要建立一个核心认知：
过去的安全边界主要围绕服务器和应用系统展开，而在云环境中，安全边界已经扩展到了身份、权限和云资源本身。
对于攻击者而言，服务器往往不再是最终目标，而只是进入云环境的入口。
第二阶段：从攻击者视角理解云平台
在这一阶段，不追求掌握完整的云平台知识，而是只关注后续攻防过程中最常接触的核心资源。
重点理解：
- 云服务器是什么
- 对象存储是什么
- 虚拟网络是什么
- 身份权限体系是什么
以及这些资源在攻击者眼中的意义。
例如：
EC2 ≈ 服务器
S3 ≈ 文件系统
IAM ≈ 权限系统
VPC ≈ 云内网
Security Group ≈ 云防火墙这一阶段最重要的任务不是阅读文档，而是亲手创建资源。
需要能够独立完成：
- 创建云服务器
- 配置安全组
- 创建对象存储
- 创建云用户
- 创建访问密钥
通过实际操作理解云资源之间的关系。
完成这一阶段之后，应当能够回答：
攻击者拿下一台云服务器之后，理论上还能够接触到哪些云资源？
如果说传统安全中最重要的是系统权限，那么云安全中最重要的则是身份权限体系。
这一阶段主要围绕 IAM 展开。
重点内容包括：
- User
- Role
- Policy
- Access Key
- 临时凭证
- 最小权限原则
学习目标并不是记忆各种策略语法，而是理解：
一个身份是谁
能够访问什么资源
为什么能够访问
如何扩大权限这一阶段结束之后，应当能够回答：
如果攻击者获得一个云身份，他如何判断自己还能控制哪些资源？
以及：
为什么很多云安全事故并不依赖漏洞，而是来源于权限设计问题？
这也是进入云攻防之前最重要的准备阶段。
第三阶段：正式进入云攻防
完成前面两个阶段之后，就可以开始研究真实的云攻击面。
这一阶段的核心目标是：
从“获取服务器权限”的思维，转变为“获取云资源控制权”的思维。
重点研究内容包括：
- 云环境信息收集
- Access Key 泄露
- Metadata 服务
- SSRF 云攻击链
- IAM 权限枚举
- IAM 权限提升
- 对象存储攻击
- 云资源横向移动
在这一阶段，需要逐步建立一条完整的云攻击链认知：
Web漏洞 ↓服务器权限 ↓云身份 ↓权限枚举 ↓资源控制与传统渗透测试相比，云攻防最大的变化在于：
攻击者往往不再以服务器为终点，而是将服务器作为进入云环境的跳板。
第四阶段：云原生安全
在掌握基础云攻防之后，再进入容器与 Kubernetes 安全领域。
原因在于：
现代云环境中的大量业务已经运行在 Docker 和 Kubernetes 之上。
此时需要补充的内容包括：
- Docker 基础
- 容器安全模型
- Kubernetes 基础架构
- Service Account
- RBAC
- Secret 管理
- Kubernetes 攻击链
这一阶段的重点不再是单个漏洞，而是理解容器和集群中的身份与权限流转过程。
很多现代云攻击链实际上都发生在 Kubernetes 环境中，因此云原生安全是后续必须补齐的部分。
如果这篇文章对你有帮助，欢迎分享给更多人！
部分信息可能已经过时