CodeRoadMap
首页路线题库资源库文章社区
CodeRoadMap

程序员的学习成长路线图。内容免费开放,登录后可同步路线图与课时进度。

由 程序员柏风 独立维护 · 关于作者

学习

  • 路线图
  • 课程
  • 面试题
  • 文章
  • 我

更多

  • 资源
  • 社区
  • 关于作者
  • 内容说明

© 2026 CodeRoadMap

津ICP备2026012044号-1·津公网安备12011002026155号·coderoadmap@126.com
网络安全入门/课时/云与虚拟化安全
RawBlame
课时目录12 节

网络安全入门

  1. 01安全职业与 IT 基础
  2. 02网络与安全基础
  3. 03操作系统加固
  4. 04密码学与 PKI
  5. 05身份与访问控制
  6. 06威胁与攻击向量
  7. 07防御技术与工具
  8. 08事件响应与取证
  9. 09云与虚拟化安全
  10. 10渗透测试入门
  11. 11合规与认证
  12. 12综合练习

云与虚拟化安全

IaaS/PaaS/SaaS、AWS/Azure、Hypervisor。

35 分钟

云安全:IAM、安全组与数据保护

这一课你将能做到

  1. 用最小权限原则编写 IAM 策略与安全组规则,说清「为什么这样开」
  2. 加固对象存储:禁止公开列举、防遍历下载、密钥不落代码
  3. 为 Spring Boot 平台设计云上的密钥管理与操作审计方案

为什么要学

如今大多数安全事故的入口不再是主机漏洞,而是云配置错误:对象存储桶公开可列举、AccessKey 提交进 Git、安全组开了 0.0.0.0/0 的 22 端口、IAM 用 *:* 一把梭。云厂商负责「云本身的安全」,而「云上的配置」责任在你——这个责任分界叫共享责任模型。

人话:云厂商把大楼建得很牢(机房、硬件、物理安全),但房间门锁没锁、钥匙给了谁,全是你的事。

先建立图像

┌─ 账号层 ── 主账号不用来做日常操作;子账号+MFA;RAM/STS 临时凭证
├─ 身份层 ── IAM 用户/角色/策略:谁(service/person) 能对什么(resource) 做什么(action)
├─ 网络层 ── VPC 划分 + 安全组(白名单) + 内网隔离;数据库不给公网 IP
├─ 数据层 ── 对象存储权限、静态加密、密钥托管(KMS)
└─ 审计层 ── 操作审计(CloudTrail/ActionTrail) + 告警规则

安全组 = 有状态的虚拟防火墙(按实例挂规则);IAM = 决定「人/服务」能调哪些 API。两者是云安全的左右手。

跟着做

步骤 1:安全组最小开放(以 AWS CLI 为例,阿里云控制台同理)

# 错误示范:全开(很多人图省事这么干)
aws ec2 authorize-security-group-ingress --group-id sg-123 \
  --protocol tcp --port 22 --cidr 0.0.0.0/0     # ❌ 全网可爆破
# 正确:只放办公室/VPN 出口 IP
aws ec2 authorize-security-group-ingress --group-id sg-123 \
  --protocol tcp --port 22 --cidr 203.0.113.0/24  # ✅ 仅办公网段
# 数据库安全组:只允许来自应用安全组的流量(引用 sg-id 而非 IP)
aws ec2 authorize-security-group-ingress --group-id sg-db \
  --protocol tcp --port 3306 --source-group sg-app
# 自查:列出所有 0.0.0.0/0 规则
aws ec2 describe-security-groups \
  --query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]]].[GroupName,IpPermissions]'

步骤 2:IAM 最小权限策略

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::java-nav-avatars/*"
  }]
}

对比错误写法 "Action": "s3:*", "Resource": "*":前者只读特定桶,泄露后攻击者最多看到头像;后者能删桶、能列举所有桶。原则:Action 最小、Resource 精确、Condition 补条件(如限定 IP 或 MFA)。

步骤 3:对象存储加固

# 检查桶是否公开可列举
curl https://java-nav-avatars.s3.amazonaws.com/?list-type=2
# 返回 ListBucketResult XML = 可列举 ❌ → 关闭公开访问
aws s3api put-public-access-block --bucket java-nav-avatars \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
# 静态资源走 CDN + 签名 URL,而不是开公开读

步骤 4:密钥不落代码

# ❌ 错误:application.yml 提交仓库
# access-key: AKIAIOSFODNN7EXAMPLE
# ✅ 正确:环境变量 / KMS / Vault 注入
cloud:
  aws:
    credentials:
      use-default-aws-credentials-chain: true   # 走实例角色,代码里零密钥
# ECS/EC2 场景首选:给实例绑 IAM Role,应用无感取凭证,可自动轮换
# 本地开发:SSO/环境变量,绝不写文件入库
git secrets --scan    # 提交前扫描意外入库的 AK/SK

步骤 5:操作审计与告警

# 开启 CloudTrail(AWS)或操作审计(阿里云),写入专用日志桶
aws cloudtrail create-trail --name java-nav-audit \
  --s3-bucket-name java-nav-audit-logs --is-multi-region-trail
# 高危动作告警示例:安全组变更、IAM 策略修改、AK 创建
# 用 EventBridge 规则匹配事件源 ec2:AuthorizeSecurityGroupIngress → SNS 通知

讲清楚要点

  1. 共享责任模型:厂商管「of the cloud」(物理、宿主、虚拟化),你管「in the cloud」(系统加固、配置、数据、访问控制)。绝大多数云安全事件是配置层责任,不是厂商被打穿。
  2. IAM 三要素:principal(谁)、resource(什么)、action(做什么)。写策略时先拒绝思考法——默认全拒绝,逐条允许;高危动作(删除、提权、密钥管理)单独拆策略便于审计。
  3. 角色优于用户,临时凭证优于长期 AK:EC2/ECS 绑 Role 后应用自动取短期凭证并轮换;长期 AccessKey 是泄露事故的常客,能不用就不用。
  4. 安全组按「引用」而非「地址」授权:DB 安全组放行 sg-app 而不是维护应用 IP 列表,扩缩容时规则自动跟随,也不会出现「为了省事开 0.0.0.0/0」。
  5. 审计日志自身要保护:日志桶对业务账号只写不删(bucket policy 拒绝 delete),否则攻击者拿 AK 后第一件事是清审计。

你可能会懵的地方

  • 安全组和网络 ACL 的区别? 安全组有状态、按实例、只支持 allow;NACL 无状态、按子网、支持 allow/deny 且规则有序。一般架构安全组足够,需要子网级强制拒绝(如封特定恶意 IP 段)才上 NACL。

  • 为什么强调实例角色而不是把 AK 放环境变量? 环境变量会随崩溃日志、docker inspect、CI 日志泄露;角色凭证由元数据服务下发、短期自动轮换,代码里根本不存在密钥,泄露面几乎为零。

  • 对象存储想让图片公开访问怎么办? 桶保持私有,公开访问走 CDN + 签名 URL/OAC(源站访问控制)。直接开公开读不仅泄露风险,还会被刷流量直接烧钱。

  • ** sts:AssumeRole 是干什么的?** 跨账号/临时授权机制:A 账号的策略允许 AssumeRole 到 B 账号的某角色,换取临时凭证。CI/CD、跨部门协作的标准做法,避免共享长期密钥。

  • 云上的安全基线怎么快速自查? 用厂商自带工具:AWS Security Hub / 阿里云安全中心基线检查,覆盖公开桶、弱安全组、未开审计、未开 MFA 等高频配置错误,先跑一遍再逐项修。

错法对照

错法问题正解
22/3389 开 0.0.0.0/0全网爆破入口白名单办公网段 + 跳板机
IAM 策略 Action: *泄露即全权限最小 Action + 精确 Resource
AK/SK 写 application.ymlGit 泄露成重大事故实例角色 / KMS / 环境变量
对象存储开公开列举数据被批量遍历下载私有桶 + CDN 签名 URL
审计日志随业务一起可删攻击者清痕独立日志桶只写不删 + 告警

卡点急救

  1. 应用报 AccessDenied 但策略看着有权限:检查 Resource ARN 是否精确到对象级(bucket/* 与 bucket 是两回事:前者对象操作,后者桶操作如 ListBucket)。
  2. 绑了实例角色还是拿不到凭证:确认实例元数据服务可达(IMDSv2 需带 Token 请求头)、SDK 走了默认凭证链、没有残留的静态 AK 覆盖。
  3. 误删安全组规则导致业务中断:恢复端口放行并复盘——变更走 IaC(Terraform)+ 变更审批,杜绝控制台随手改。

面试常问

  • 解释云的共享责任模型。 厂商负责云本身(物理设施、硬件、虚拟化层),用户负责云上内容(OS 加固、应用安全、IAM 配置、数据加密)。IaaS/PaaS/SaaS 的分界线逐层上移,但配置错误始终是用户侧责任,也是云事故的主因。

  • 如何设计一套云上 IAM 的最小权限实践? 按角色拆分(应用只读桶、CI 只推镜像、运维带 MFA 管控台);Resource 精确到 ARN;生产高危操作要求 MFA/审批;用实例角色替代静态 AK;定期用 IAM Access Analyzer 复核未使用的权限并回收。

  • 对象存储数据泄露的常见原因与防护? 原因:桶策略误开公开读、列举接口未关、AK 泄露后遍历。防护:公开访问块全开、CDN+签名 URL、静态加密 + KMS、审计告警异常大批量下载。

自测三问

  1. 安全组放行流量时「引用安全组」比「写 IP」好在哪?
  2. 为什么说实例角色比环境变量放 AK 安全?
  3. 你的平台在云上,哪三类配置错误最容易让你出事?

小结一句话

云安全的主战场是配置而非漏洞:IAM 最小权限、安全组精确放行、密钥托管不落码、对象存储默认私有、审计日志独立只增——这五条守住,就避开了绝大多数云事故。

延伸

  • AWS IAM 最佳实践
  • 阿里云安全基线最佳实践
  • 下一课:渗透测试方法论与 Burp Suite 实操。
加载本节练习…
← 上一课事件响应与取证下一课 →渗透测试入门