工程师完整的SOC 2 Type II实施手册：含真实命令的月度路线图

如果你的团队正在为 SOC 2 Type II 审核做准备，这份手册正是为你而写。它是一个独立完整的指南，涵盖你必须遵循的精确 90 天时间线、14 项关键控制措施，以及审计员实际检查的证据收集基础设施。

人人都会发布控制项清单，但没人会公布你为确保万无一失所需遵循的周度工程日程表。

以下是精确的 90 天时间线——包括那些会额外增加 60 天的错误，以及如何避免它们。

目录

1. 你将学到的内容

1. 先决条件

1. 第 1–2 周：范围界定

1. 第 3–6 周：观察期第一天必须激活的 14 项控制措施

1. 第 7–10 周：证据收集基础设施

1. 第 11–14 周：审计员选择与准备评估

1. 第 15–18 周：观察期

1. 90 天 SOC2 时间线概览

1. 下一步

1. 资源

你将学到的内容

阅读完本指南后，你将了解：

• 如何正确界定你的 SOC2 范围——这一决策决定一切

• 在观察期第一天必须激活的 14 项控制措施

• 如何构建自动运行的证据收集基础设施

• 如何选择审计员并执行准备评估

• 观察期内会发生什么，以及如何在不重置时间线的情况下填补差距

让我们开始吧。

先决条件

在开始之前，你需要具备：

知识：

• 对 AWS 服务（EC2、RDS、S3、IAM、VPC）的基本理解

• 熟悉 Terraform 或其他基础设施即代码工具

• 能够阅读 GitHub Actions 的 YAML 工作流

• 对 SOC2 的基本理解——如果你是零基础，请先阅读 AICPA 的 SOC2 概述

工具与访问权限：

• 拥有管理员权限的 AWS 账户

• 拥有管理员权限的 GitHub 组织

• 已安装 Terraform（v1.0 或更高版本）

• Python 3.8 或更高版本（用于证据收集 Lambda）

• 一个合规自动化平台——Vanta 或 Drata——已连接至你的 AWS 账户和 GitHub 组织

预估时间： 端到端 90 天，前六周每周投入约 8–12 小时的主动工程工作，观察期每周减少至 2–4 小时。

第 1–2 周：范围界定——哪些在 SOC2 范围内，哪些不在

大多数团队的错误

大多数团队将 SOC2 范围界定得过于宽泛。他们将每个 AWS 账户、每个服务、每个环境都纳入其中。这是错误的，原因如下：

更广的范围意味着需要实施更多控制措施、收集更多证据，以及让审计员检查更多系统。

你范围内的每个系统都必须满足全部 14 项控制措施。将开发沙箱包含在内，意味着工程师的实验环境必须启用 GuardDuty、CloudTrail 日志记录和分支保护部署。这会为那些对客户无任何风险的系统增加数周的工作量和数月的证据收集。

正确的范围界定意味着你只包含存储、处理或传输客户数据的系统，并证明其他所有系统无法访问这些系统。

错误范围（过度包含）：

整个 AWS 组织
├── 生产环境（在范围内）
├── 预发布环境（在范围内）
├── 开发环境（在范围内）
├── 沙箱环境（在范围内）
└── CI/CD（在范围内）

正确范围（精准界定）：

SOC2 范围边界
├── 生产 AWS 账户（在范围内）
├── 生产 EKS 集群（在范围内）
├── 生产 RDS（在范围内）
└── 其他所有系统（不在范围内——通过网络隔离证明）

正确的范围界定之所以有效，是因为它在真正处理客户数据的系统周围划定了最严密、可辩护的边界。边界之外的所有系统都被排除——不是靠假设，而是通过技术控制确保它们无法访问边界内的任何内容。

范围界定框架

对于你基础设施中的每个系统，问这四个问题：

| 问题 | 如果是 | 如果否 | | --- | --- | --- | | 此系统是否存储、处理或传输客户数据？ | ✅ 在范围内 | ❌ 不在范围内 | | 此系统是否影响面向客户的业务可用性？ | ✅ 在范围内 | ❌ 不在范围内 | | 此系统是否能访问生产凭证？ | ✅ 在范围内 | ❌ 不在范围内 | | 此系统被攻破是否会导致客户数据泄露？ | ✅ 在范围内 | ❌ 不在范围内 |

只要有一个问题的答案为“是”，该系统就必须包含在你的范围内。

网络隔离——证明你边界有效的技术手段

网络隔离是指将你的基础设施划分为相互隔离的区域，除非明确允许，否则一个区域的系统无法与另一个区域的系统通信。

在 SOC2 的语境下，网络隔离是技术控制手段，用于证明你的“范围外”系统确实无法访问“范围内”系统——不是靠政策，而是靠基础设施强制执行。

如果没有网络隔离，审计员无法信任你的边界是真实的。如果你的沙箱环境中的开发者能查询生产数据库，那么无论你的图表如何标注，沙箱实际上已处于范围内。

以下是实现生产环境与非生产环境之间网络隔离的 Terraform 代码。网络访问控制列表（NACL）阻止来自更广泛私有 IP 范围（10.0.0.0/8）的所有入站流量进入你的范围内生产 VPC，同时通过注释明确说明不建立环境对等连接的决策：

# 此账户不与非生产环境建立 VPC 对等连接。
# 缺乏对等连接本身就是隔离控制。
# 未经 SOC2 范围审查，切勿为此账户添加对等连接。

resource "aws_network_acl" "deny_non_production" {
  vpc_id = aws_vpc.production.id

  # 阻止来自非生产 IP 范围的所有入站流量
  ingress {
    rule_no    = 100
    action     = "deny"
    from_port  = 0
    to_port    = 0
    protocol   = "-1"
    cidr_block = "10.0.0.0/8"
  }

  # 允许合法入站流量（来自互联网的 HTTPS）
  ingress {
    rule_no    = 200
    action     = "allow"
    from_port  = 443
    to_port    = 443
    protocol   = "tcp"
    cidr_block = "0.0.0.0/0"
  }

  # 允许所有出站流量（根据架构进一步收紧）
  egress {
    rule_no    = 100
    action     = "allow"
    from_port  = 0
    to_port    = 0
    protocol   = "-1"
    cidr_block = "0.0.0.0/0"
  }

  tags = {
    Name        = "production-nacl"
    Environment = "production"
    Purpose     = "SOC2 network segmentation"
  }
}

应用 Terraform 后，使用以下命令验证隔离效果：

# 确认生产环境与非生产环境之间不存在 VPC 对等连接
aws ec2 describe-vpc-peering-connections \
  --filters Name=status-code,Values=active \
  --query 'VpcPeeringConnections[*].{ID:VpcPeeringConnectionId,Requester:RequesterVpcInfo.VpcId,Accepter:AccepterVpcInfo.VpcId}' \
  --output table

交付成果：你的 SOC2 范围图

在第 1–2 周结束时，你需要一份范围图——一张可视化文档，展示所有在范围内的系统、所有不在范围内的系统，以及它们之间的隔离控制措施。

该图应包含以下内容：

包含每个 AWS 服务、每条数据流箭头，以及隔离控制的标签。此图将成为你的主要范围证据，通常是审计员要求查看的第一份材料。

第 3–6 周：观察期第一天必须激活的 14 项控制措施

这 14 项控制措施必须在观察期第一天就已实施并开始收集证据。如果你在后期才添加其中任何一项，该控制的观察期将从你实施之日重新计算，而非从审计周期的第一天开始。

可以把观察期想象成一台监控你基础设施的摄像机。审计员稍后观看录像。如果某个事件发生时摄像机未开启，该事件就没有记录——相应的 SOC2 控制就会出现缺口。

控制 1：多因素认证（CC6.6）

多因素认证（MFA）要求用户使用两个独立因素验证身份——他们知道的东西（密码）和他们拥有的东西（手机或硬件密钥）。没有 MFA，被盗密码就足以访问你的生产系统。

SOC2 CC6.6 要求仅授权用户可访问系统。MFA 是使“授权”具有实际意义的技术控制。没有它，任何密码泄露都等同于生产系统被访问。

要实施 MFA，你可以使用连接到身份提供商（Okta、Google Workspace 或 Azure AD）的 AWS IAM Identity Center（原 SSO）。MFA 在身份提供商层面强制执行——任何未注册 MFA 的用户都无法通过认证，无论他们试图访问哪个 AWS 服务。

# IAM Identity Center 配置——MFA 在 IdP 层面强制执行。
# 没有 IAM 用户拥有直接控制台或 CLI 访问权限。
# 所有访问均通过 SSO 会话（默认 8 小时过期）。

resource "aws_ssoadmin_instance_access_control_attributes" "mfa" {
  instance_arn = tolist(data.aws_ssoadmin_instances.this.arns)[0]

  attribute {
    key = "email"
    value {
      source = ["$${path:email}"]
    }
  }
}

你可以验证是否有 IAM 用户仍保留直接控制台访问权限（这会绕过 MFA）：

# 列出此处的任何用户，均表示绕过 SSO 的直接控制台访问——立即调查
aws iam list-users \
  --query 'Users[?PasswordLastUsed!=`null`].[UserName,PasswordLastUsed]' \
  --output table