AWS 计算服务安全加固完全指南：EC2安全组、Lambda权限策略、ECS容器安全、Lightsail防火墙配置（2026实战版）

Meta Description: AWS计算服务安全加固全攻略：EC2安全组规则设计、Lambda最小权限IAM策略、ECS/EKS容器镜像扫描与运行时安全、Auto Scaling安全基线、Lightsail防火墙与快照备份实战。

关键词：AWS安全加固、EC2安全组、Lambda IAM权限、ECS容器安全、EKS安全、Auto Scaling安全、Lightsail防火墙、云服务器安全

前言

2025年全球云安全报告显示，超过82%的云安全事件并非由云厂商基础设施漏洞引起，而是由用户配置错误导致。安全组规则过于宽松、IAM权限过度授权、容器镜像未扫描就上线——这些看似微小的失误，往往是数据泄露的导火索。AWS提供了强大的安全工具矩阵，但关键在于如何正确配置和使用它们。

本文将系统梳理 AWS 五大核心计算服务——EC2、Lambda、ECS/EKS、Auto Scaling、Lightsail——的安全加固最佳实践，涵盖网络层、身份层、应用层和数据层的完整防护体系。

五大服务安全架构总览

一、EC2 安全组设计：从"全放行"到零信任

安全组是 EC2 的第一道防线。我们在生产环境中最常见的错误，就是把入站规则设置成 0.0.0.0/0。

1.1 最小权限规则设计

一个标准的 Web 应用 EC2 实例应该只开放三个端口：

# 安全组入站规则（推荐配置）
Port  |  Protocol  |  Source
------|------------|--------------------
22    |  TCP       |  办公IP/32（或堡垒机SG）
80    |  TCP       |  0.0.0.0/0（HTTP重定向到443）
443   |  TCP       |  0.0.0.0/0

关键原则：

• SSH（22端口）绝不向公网开放。使用 Session Manager 替代 SSH，或限定为堡垒机安全组。
• 出站规则默认全放行即可（AWS 安全组是有状态防火墙，回复流量自动允许）。
• 生产环境建议使用安全组引用（Source 设为另一个安全组 ID）而非 IP 地址。

1.2 使用 VPC Flow Logs 审计流量

我们曾在一次安全审查中，通过 Flow Logs 发现一台 EC2 实例在凌晨 3 点向陌生 IP 发送了 2.3GB 数据——后来证实是 SSH 弱密码被爆破后植入了挖矿程序。Flow Logs 是事后溯源的关键工具：

# 创建 VPC Flow Logs 并发送到 CloudWatch
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-0abc123def456 \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /aws/vpc/flow-logs

1.3 IAM Instance Profile 替代 Access Key

永远不要在 EC2 实例上硬编码 aws_access_key_id 和 aws_secret_access_key。使用 IAM Role 附加到 EC2：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-app-bucket/*"
    }
  ]
}

附加此角色的 EC2 实例通过元数据服务自动获取临时凭证，没有密钥泄漏风险。

二、Lambda 权限策略：从 ":" 到精确授权

Lambda 函数的安全模型完全围绕 IAM Execution Role 展开。一个最常见的反模式是给 Lambda 分配 AdministratorAccess——"开发方便，但一旦代码被注入，攻击者将拥有整个 AWS 账户的控制权"。

2.1 函数级最小权限设计

每个 Lambda 函数的 Execution Role 应只包含该函数实际需要的权限：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:Query"],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789:table/Orders"
    },
    {
      "Effect": "Allow",
      "Action": ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"],
      "Resource": "arn:aws:logs:*:*:*"
    }
  ]
}

2.2 环境变量加密

不要在 Lambda 环境变量中以明文存储数据库密码或 API 密钥。使用 AWS KMS 加密：

# 加密环境变量
aws lambda update-function-configuration \
  --function-name process-order \
  --environment "Variables={DB_PASSWORD=encrypted_value}" \
  --kms-key-arn arn:aws:kms:us-east-1:123456789:key/abcd-1234

解密权限也需要明确授予：

{
  "Effect": "Allow",
  "Action": ["kms:Decrypt"],
  "Resource": "arn:aws:kms:us-east-1:123456789:key/abcd-1234"
}

2.3 Lambda 在 VPC 内运行

默认情况下，Lambda 函数运行在 AWS 托管的 VPC 中，可以直接访问互联网但无法访问你私有子网中的 RDS、ElastiCache 等资源。如果将 Lambda 挂载到 VPC，务必配置 NAT 网关或 VPC Endpoint，否则函数将失去互联网出站能力：

# 将 Lambda 挂载到私有子网
aws lambda update-function-configuration \
  --function-name my-function \
  --vpc-config SubnetIds=subnet-abc,subnet-def,SecurityGroupIds=sg-xyz123

2.4 Lambda 代码依赖扫描

每次部署前使用 pip-audit 或 npm audit 扫描依赖漏洞。在 CI/CD 流水线中集成 Amazon Inspector 进行 Lambda 层扫描是一个成熟的实践。

三、ECS/EKS 容器安全：镜像扫描 + 运行时防护

容器安全涉及镜像构建、镜像存储、运行时安全三个层面。AWS 在这三层都提供了对应的工具。

3.1 ECR 镜像扫描

Amazon ECR 支持两种扫描模式：基础扫描（免费，推送时扫描）和增强扫描（使用 Inspector，持续监控）。

# 在推送时自动触发扫描
aws ecr put-image-scanning-configuration \
  --repository-name my-app \
  --image-scanning-configuration scanOnPush=true

# 查看扫描结果
aws ecr describe-image-scan-findings \
  --repository-name my-app \
  --image-id imageTag=latest

实战案例：某团队在 CI/CD 中漏配扫描，推送了一个包含 Log4Shell 漏洞（CVE-2021-44228）的 Java 容器上线。如果当时开启增强扫描，Inspector 会在 24 小时内标记该漏洞，而不是等到被攻击后才察觉。

3.2 ECS Task 安全配置

{
  "family": "secure-web-app",
  "taskRoleArn": "arn:aws:iam::123456:role/ecs-task-role",
  "executionRoleArn": "arn:aws:iam::123456:role/ecs-execution-role",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "containerDefinitions": [{
    "name": "web",
    "image": "123456.dkr.ecr.us-east-1.amazonaws.com/my-app:latest",
    "readonlyRootFilesystem": true,
    "user": "1000",
    "secrets": [{
      "name": "DB_PASSWORD",
      "valueFrom": "arn:aws:secretsmanager:us-east-1:123456:secret:db-pass-abc123"
    }],
    "logConfiguration": {
      "logDriver": "awslogs"
    }
  }]
}

重点配置项说明：

• readonlyRootFilesystem: true：容器文件系统只读，防止攻击者写入恶意文件。
• user: "1000"：以非 root 用户运行，降低容器逃逸风险。
• secrets：从 Secrets Manager 注入敏感信息，不在任务定义中硬编码。
• networkMode: awsvpc：每个 Task 获得独立 ENI，安全组粒度更细。

3.3 EKS Pod 安全策略

在 EKS 集群中启用 Pod Security Standards (PSS) 是最基础的安全措施：

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

restricted 级别强制执行最严格的 Pod 安全策略：禁止特权容器、必须以非 root 用户运行、禁止挂载宿主机路径。配合 NetworkPolicy 限制 Pod 间通信：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: api-gateway

四、Auto Scaling 安全基线：批量合规从模板开始

Auto Scaling 组启动的新实例会继承启动模板中的所有安全配置。如果模板本身不安全，那么弹性扩容出来的每一台实例都是不安全的。这是一种"安全负债复利效应"——1 台不安全 → 扩容后 10 台不安全 → 横向扩散。

4.1 启动模板安全清单

4.2 使用 AWS Config Rules 自动检测违规

# 启用 SSH 限制规则
aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "restricted-ssh",
    "Source": {"Owner": "AWS", "SourceIdentifier": "RESTRICTED_INCOMING_TRAFFIC"},
    "Scope": {"ComplianceResourceTypes": ["AWS::EC2::SecurityGroup"]},
    "InputParameters": "{\"blockedPort1\":\"22\"}"
  }'

# 查看合规状态
aws configservice get-compliance-details-by-config-rule \
  --config-rule-name restricted-ssh

配置完成后，任何不符合安全基线的新实例都会在几分钟内被标记为 NON_COMPLIANT，并可通过 SNS 发送告警。

五、Lightsail 安全加固：轻量不等于简陋

很多用户误以为 Lightsail 的"简单"意味着"安全自动搞定"。实际上，Lightsail 的默认配置同样需要加固。2024 年一份针对 Lightsail 实例的安全扫描数据显示，约 35% 的 Lightsail 实例开放了不必要的端口。

5.1 Lightsail 防火墙配置

Lightsail 提供两层防火墙：AWS 平台级防火墙（IPv4 + IPv6）和实例内操作系统防火墙。两者应保持一致：

# Lightsail CLI 配置端口
aws lightsail put-instance-public-ports \
  --instance-name my-wordpress \
  --port-infos \
    "fromPort=80,toPort=80,protocol=tcp" \
    "fromPort=443,toPort=443,protocol=tcp"

# 操作系统内同步配置（以 Ubuntu 为例）
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw deny 22/tcp    # 改用 Lightsail 控制台 SSH
sudo ufw enable

5.2 快照备份策略

Lightsail 提供自动快照功能，建议启用每日自动快照：

aws lightsail enable-add-on \
  --resource-name my-instance \
  --add-on-request '{
    "addOnType": "AutoSnapshot",
    "autoSnapshotAddOnRequest": {
      "snapshotTimeOfDay": "03:00"
    }
  }'

手动快照同样关键，请在以下操作前创建：重大配置变更、系统升级、WordPress 插件批量更新。

5.3 Lightsail 负载均衡器 SSL

自带负载均衡器支持免费 SSL 证书，务必启用 HTTPS 并配置 HTTP→HTTPS 重定向：

# 创建负载均衡器并附加证书
aws lightsail create-load-balancer \
  --load-balancer-name my-lb \
  --instance-port 80

aws lightsail attach-load-balancer-tls-certificate \
  --load-balancer-name my-lb \
  --certificate-name my-cert \
  --certificate-domain-name example.com \
  --certificate-alternative-names www.example.com

六、跨服务统一安全监控体系

6.1 一键启用 Security Hub

aws securityhub enable-security-hub \
  --enable-default-standards \
  --control-finding-generator SECURITY_CONTROL

# 查看安全评分
aws securityhub get-findings \
  --filters '{"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}]}' \
  --max-results 10

Security Hub 会自动聚合 GuardDuty、Inspector、Config、Macie 等服务的发现，生成统一的安全评分。

七、常见安全配置错误与修复

以下是我们从实际安全审计中总结出的 5 个高频配置错误：

八、安全事件响应流程

建立标准化的安全事件响应流程，缩短从发现到修复的时间：

发现告警 → 初步研判(15分钟内) → 隔离受影响资源(安全组限制/停止实例)
    → 取证（快照 + 内存Dump + 日志导出）
    → 根因分析 → 修复加固 → 复盘报告 → 更新安全基线

核心实践：

1. 配置 GuardDuty → EventBridge → Lambda 自动响应链，实现对高危发现（如加密货币挖矿检测）的自动化隔离。
2. 定期（至少每季度）进行一次桌面演练，模拟安全事件来检验响应流程的有效性。
3. 使用 Infrastructure as Code（CloudFormation / Terraform）管理所有安全配置，确保变更可追溯、可回滚。

总结

AWS 计算服务的安全加固不是一次性工作，而是贯穿服务生命周期的持续过程。核心原则只有一条：默认拒绝，显式授权。无论是 EC2 安全组、Lambda IAM 策略，还是 ECS 任务角色，都应遵循这个原则。

从今天开始，建议你执行三个立即可行的操作：

1. 在 Security Hub 中查看当前账户的安全评分，找出 CRITICAL 级别的发现。
2. 审查所有安全组规则，关闭不必要的 0.0.0.0/0 入站规则。
3. 为所有生产环境 EC2 和 RDS 启用自动快照。

安全没有终点，但每一步加固都在降低你的攻击面。

---

本文由 5.chengzicloud.cloud 提供，点击访问首页了解更多