云身份与权限管理

  问题：直接用根账号（Root Account）登录控制台，因为"省事"
风险：根账号拥有所有权限，一旦泄露整个账号就废了
  

  改进：给每个人创建 IAM User，分配不同权限
问题：
- 运维小王离职了，他的 AK/SK 散落在哪些服务器上？
- 新来的前端需要 S3 只读权限，后端需要 RDS 权限，手动一个个配太麻烦
  

  改进：
1. 按角色创建 IAM Group：
   - Developers（开发）：S3、EC2、RDS 读写
   - DevOps（运维）：全权限，但需要 MFA
   - ReadOnly（只读）：查看所有资源，不能修改
   - QAs（测试）：测试环境资源访问

2. 使用 IAM Role：
   - EC2 实例使用 Instance Profile，不再在服务器上放 AK/SK
   - 跨账号访问用 Role Assume，不用共享 AK/SK
   - CI/CD 用 OIDC Federation，不用存储长期凭证
  

  架构：
- Master Account（主账号）：只用来管理账单和组织结构，不放任何资源
- Audit Account（审计账号）：收集所有账号的日志
- Dev Account（开发账号）：开发环境
- Staging Account（预发布账号）：测试环境
- Prod Account（生产账号）：线上环境，权限最严格

权限流转：
- 开发人员默认只有 Dev 账号的只读权限
- 需要修改生产环境时，提工单申请 Assume 到 Prod 的临时 Role
- 所有 Assume 操作都被 CloudTrail 记录，定期审计
  

  {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadWrite",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::my-app-bucket/*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "ap-northeast-1"
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    },
    {
      "Sid": "DenySensitiveData",
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::my-app-bucket/sensitive/*"
    }
  ]
}
  

  1. 先看有没有 Deny 策略
   ├─ 有 Deny → 拒绝（不管有没有 Allow）
   └─ 没有 Deny → 继续看

2. 再看有没有 Allow 策略
   ├─ 有 Allow → 允许
   └─ 没有 Allow → 拒绝（默认拒绝原则）
  

  // 策略1：给开发者的普通权限
{
  "Effect": "Allow",
  "Action": ["s3:*"],
  "Resource": "arn:aws:s3:::company-data/*"
}

// 策略2：保护敏感目录（即使开发者有 s3:* 也不能访问）
{
  "Effect": "Deny",
  "Action": ["s3:*"],
  "Resource": "arn:aws:s3:::company-data/sensitive/*"
}
  

  # 小李写的代码（有严重安全问题！）
import boto3

# 为了方便调试，直接把 AK/SK 写在代码里
s3 = boto3.client(
    's3',
    aws_access_key_id='AKIAIOSFODNN7EXAMPLE',
    aws_secret_access_key='wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY',
    region_name='ap-northeast-1'
)

def upload_file(file_path, bucket_name, object_name):
    s3.upload_file(file_path, bucket_name, object_name)
    print(f"文件已上传到 s3://{bucket_name}/{object_name}")

# 测试上传
upload_file('./test.jpg', 'my-company-bucket', 'uploads/test.jpg')
  

  # 正确做法：使用 AWS CLI 配置凭证，不写在代码里
aws configure
# 然后根据提示输入 Access Key ID 和 Secret Access Key
# 这些信息会被保存在 ~/.aws/credentials，权限设置为 600

# 代码中不需要任何凭证配置
import boto3
s3 = boto3.client('s3')  # 自动从 ~/.aws/credentials 读取
  

  # 正确做法：使用 IAM Instance Profile
# 1. 创建一个 IAM Role，附加需要的权限（如 S3ReadOnly）
# 2. 创建一个 Instance Profile，关联这个 Role
# 3. 启动 EC2 时，选择这个 Instance Profile

# 代码中完全不需要凭证
import boto3
s3 = boto3.client('s3')  # 自动从 EC2 元数据服务获取临时凭证

# 临时凭证会自动轮换，无需担心过期
  

  # 正确做法：使用 OIDC Federation（OpenID Connect）
# 以 GitHub Actions 为例：

# 1. 在 AWS 创建 OIDC Identity Provider，信任 GitHub
# 2. 创建一个 IAM Role，信任策略允许 GitHub 的特定仓库扮演
# 3. 在 GitHub Actions 中配置

name: Deploy
on: [push]

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      id-token: write # 关键：允许请求 OIDC token
      contents: read
    steps:
      - uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
          aws-region: ap-northeast-1
          # 注意：这里没有 Access Key！完全使用临时凭证

      - name: Deploy
        run: aws s3 sync ./build s3://my-bucket/
  

  账号 A（Production）                    账号 B（Shared Services）
    |                                           |
    |  1. 请求 Assume Role                      |
    |  "我想扮演账号 B 的 ECRReadRole"          |
    |------------------------------------------>|
    |                                           |
    |                    2. 检查信任策略         |
    |                    "账号 A 可以扮演我吗？" |
    |                                           |
    |  3. 返回临时凭证                          |
    |  AccessKeyId, SecretKey, SessionToken    |
    |<------------------------------------------|
    |                                           |
    |  4. 使用临时凭证访问 ECR                  |
    |  docker pull 账号B.dkr.ecr...            |
  

  arn:aws:iam::SHARED_SERVICES_ACCOUNT_ID:role/CrossAccountECRReadRole
  

  {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::SHARED_SERVICES_ACCOUNT_ID:role/CrossAccountECRReadRole"
    }
  ]
}
  

  #!/bin/bash
# 安装 AWS CLI
yum install -y aws-cli

# Assume 跨账号 Role
CREDS=$(aws sts assume-role \
  --role-arn arn:aws:iam::SHARED_SERVICES_ACCOUNT_ID:role/CrossAccountECRReadRole \
  --role-session-name EC2PullSession)

# 提取临时凭证
export AWS_ACCESS_KEY_ID=$(echo $CREDS | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo $CREDS | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo $CREDS | jq -r '.Credentials.SessionToken')

# 登录 ECR
aws ecr get-login-password --region ap-northeast-1 | \
  docker login --username AWS --password-stdin SHARED_SERVICES_ACCOUNT_ID.dkr.ecr.ap-northeast-1.amazonaws.com

# 拉取镜像
docker pull SHARED_SERVICES_ACCOUNT_ID.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest
  

  # 测试能否 Assume Role
aws sts get-caller-identity
# 应该显示：arn:aws:sts::PRODUCTION_ACCOUNT_ID:assumed-role/CrossAccountECRReadRole/EC2PullSession

# 测试能否列出 Shared Services 的 ECR 仓库
aws ecr describe-repositories --registry-id SHARED_SERVICES_ACCOUNT_ID
  

  目标：保护根账号，这是最重要的账号

1. 启用根账号 MFA（必须）
   - 推荐硬件 MFA（YubiKey），或者 Google Authenticator

2. 创建 IAM 管理员账号
   - 用户名：admin（或你的名字）
   - 权限：AdministratorAccess（但后续会收紧）
   - 启用 MFA

3. 删除根账号的 Access Key（如果创建了的话）
   - 根账号永远不应该有 AK/SK

4. 配置根账号使用告警
   - 使用 CloudWatch + SNS，一旦根账号登录就发邮件/短信
  

  目标：给团队成员分组，批量管理权限

1. 分析团队角色：
   - 后端开发（2人）
   - 前端开发（1人）
   - 移动端开发（1人）
   - 产品经理（1人）
   - 设计师（1人）
   - 创始人/管理员（3人）

2. 创建 IAM Groups：

   Group: Developers
   ├── 成员：所有开发（后端、前端、移动端）
   ├── 权限：
   │   ├── EC2: 启动、停止、查看（但不能删除别人的实例）
   │   ├── S3: 读写开发环境的 bucket
   │   ├── RDS: 只读权限（不能修改生产数据库）
   │   └── CloudWatch: 查看日志
   └── 限制：只能操作 ap-northeast-1 区域

   Group: ProductTeam
   ├── 成员：产品经理、设计师
   ├── 权限：
   │   ├── S3: 只读（查看数据文件）
   │   ├── CloudWatch Dashboard: 查看监控图表
   │   └── Cost Explorer: 查看账单（但不能修改）
   └── 限制：只读权限，不能修改任何资源

   Group: Administrators
   ├── 成员：创始人、技术负责人
   ├── 权限：AdministratorAccess
   └── 要求：必须使用 MFA 才能操作

3. 给每个人创建 IAM User，加入对应的 Group
   - 不要给个人直接附加权限，一律通过 Group 管理
   - 启用 MFA（强制要求）
  

  目标：让应用程序安全地访问 AWS 资源

1. EC2 实例使用 Instance Profile
   - 不再在服务器上配置 AK/SK
   - 创建 IAM Role，附加需要的权限（如 S3 读写）
   - 创建 Instance Profile，关联这个 Role
   - 启动 EC2 时选择这个 Instance Profile
   - 应用代码中直接使用 boto3，无需配置凭证

2. 如果必须使用 AK/SK（第三方集成）
   - 使用 AWS Secrets Manager 存储 AK/SK
   - 应用启动时从 Secrets Manager 读取
   - 设置定期轮换（90天）
   - 监控 AK/SK 的使用情况

3. 配置 CloudTrail 记录所有 API 调用
   - 创建单独的 S3 bucket 存储日志
   - 设置日志文件校验（防止篡改）
   - 配置 SNS 通知关键事件（如根账号使用、策略变更）
  

  目标：建立持续的安全监控和改进机制

1. 启用 AWS Config
   - 监控资源配置变更
   - 检查合规性（如安全组是否开放了 0.0.0.0/0）

2. 启用 IAM Access Analyzer
   - 持续分析资源策略
   - 识别外部访问（如 S3 bucket 是否公开）

3. 定期审查 IAM 配置
   - 每月检查一次未使用的 IAM User、Role
   - 检查 Access Key 的使用情况
   - 验证 Group 成员是否合理

4. 建立安全事件响应流程
   - 如果发现 AK/SK 泄露：立即删除、轮换、审计影响范围
   - 如果发现异常 API 调用：立即调查、限制权限