AWS VPC加密控制配置指南：监控与强制执行模式实战

为什么需要VPC加密控制

在金融、医疗、政府等受监管行业，证明云基础设施的端到端加密合规性一直是运维团队的痛点。传统方案依赖多种加密工具的拼凑、复杂的PKI管理，以及通过电子表格手动追踪各网络路径的加密状态——这种方式不仅容易出错，随着基础设施扩展更会变得难以维护。

虽然AWS Nitro System早已在硬件层实现了实例间流量的自动加密且不影响性能，但组织仍缺乏一个集中化的机制来验证和强制执行整个VPC范围的加密策略。这对于满足HIPAA、PCI DSS、FedRAMP等合规要求尤为关键。

VPC加密控制的两种操作模式

监控模式：加密状态审核

监控模式是部署VPC加密控制的第一步，也是现有VPC的必经阶段。在此模式下，您可以：

• 审核VPC内所有流量的加密状态
• 识别仍在传输明文流量的资源
• 通过VPC流量日志获取详细的加密状态字段

从实践角度，我建议在启用监控模式后至少观察7-14天，确保覆盖所有业务场景的流量模式，再考虑切换至强制执行模式。

强制执行模式：策略强制实施

当确认所有资源均已迁移至支持加密的基础设施后，可切换至强制执行模式。该模式将：

• 阻止在非Nitro实例上创建新资源
• 丢弃检测到的未加密流量
• 允许为Internet Gateway、NAT Gateway等特定资源配置排除项

加密状态字段详解

VPC流量日志中的encryption-status字段提供四级加密状态识别：

• 0：流量以明文传输，未加密
• 1：流量在网络层（L3）由Nitro System硬件加密
• 2：流量在应用层（L7）通过TLS/SSL加密（TCP 443端口）
• 3：同时启用Nitro硬件加密和TLS应用层加密
• –：VPC加密控制未启用或状态信息缺失

从安全最佳实践角度，状态3（双层加密）提供了最高级别的传输安全保障，建议对敏感数据传输采用此配置。

实战配置步骤

步骤一：创建VPC加密控制

通过AWS CLI创建加密控制：

aws ec2 create-vpc-encryption-control --vpc-id vpc-0123456789abcdef0

需要注意的是，每个VPC只能关联一个加密控制，形成一对一的映射关系。对于新建VPC，可在创建时直接启用强制执行模式；对于现有VPC，必须先以监控模式启动。

步骤二：配置流量日志采集加密状态

创建包含加密状态字段的VPC流量日志：

aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-0123456789abcdef0 \
  --traffic-type ALL \
  --log-destination-type s3 \
  --log-destination arn:aws:s3:::your-bucket-name/vpc-flow-logs/ \
  --log-format '${flow-direction} ${traffic-path} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${encryption-status}'

步骤三：分析流量日志识别未加密资源

流量日志示例输出：

flow-direction traffic-path srcaddr      dstaddr      srcport dstport encryption-status
ingress        -            10.0.133.8   10.0.128.55  43236   80      1
egress         1            10.0.128.55  10.0.133.8   80      43236   1
ingress        -            10.0.130.104 10.0.128.55  55016   80      0
egress         1            10.0.128.55  10.0.130.104 80      55016   0

上述日志显示：来自10.0.133.8（Nitro实例）的流量加密状态为1，而来自10.0.130.104（非Nitro实例）的流量加密状态为0，需要进行迁移。

步骤四：查询阻止强制执行的资源

aws ec2 get-vpc-resources-blocking-encryption-enforcement --vpc-id vpc-0123456789abcdef0

该命令将返回所有不符合加密要求的资源列表，包括非Nitro实例的ENI、不支持加密的网关等。

资源迁移策略建议

自动迁移资源

以下AWS托管服务会自动将底层基础设施迁移至Nitro硬件，无需人工操作：

• Network Load Balancer
• Application Load Balancer
• AWS Fargate任务

需手动迁移的资源

对于上一代EC2实例，有两种迁移路径：

• 推荐方案：将实例类型升级至基于Nitro架构的现代实例（如m7g、c7g、r7g系列）
• 替代方案：在应用层配置TLS加密，确保流量至少达到加密状态2

排除项配置

Internet Gateway和NAT Gateway因流量流经VPC或AWS网络之外，不支持加密，需配置为排除项。其他资源则必须符合加密要求，不可排除。

合规性与最佳实践

从架构设计角度，我建议采用以下策略确保VPC加密控制的有效实施：

• 在新VPC创建时即启用加密控制，避免后期迁移成本
• 建立实例类型选型标准，优先选择Nitro架构实例
• 配置CloudWatch告警监控加密状态为0的流量
• 定期审计get-vpc-resources-blocking-encryption-enforcement输出
• 将VPC加密控制状态纳入合规报告自动化流程