‘Virtual Air Gap’: 在 AWS 中构建 Fort Knox
Source: Dev.to
想象一下，你站在 CISO（或德国非常严格的数据隐私官）面前说：“我们要把敏感的患者数据迁移到云上。”
他们的反应？恐慌。过度换气。“绝不行！必须空隔离！不允许有互联网连接！”
我来自制药 IT（BioNTech）领域，深知这些要求的每一个细节，我在这里告诉你：是的，这是可能的——但我们必须停止把云当作咖啡店的公共 Wi‑Fi 来使用。
今天我们将深入探讨，按照高安全标准构建一个 Landing Zone（落地区），并解释在 AWS 中“空隔离”到底是如何实现的。
The Landing Zone
What a Landing Zone Is Not
Landing Zone 不是 单个 AWS 账户。
Multi‑Account Strategy with AWS Control Tower
当我们谈到 Landing Zone 时，指的是由 AWS Control Tower 编排的 多账户策略。我们不会把所有东西都塞进一个桶里，而是把职责划分到不同的账户。
Account Types
| Account | Purpose |
|---|---|
| Security Account | 保存不可变日志（CloudTrail），无人能删除（写一次，读多次）。 |
| Shared Services | 为整个组织提供集中化的工具和服务。 |
| Workload Accounts (Prod/Dev) | 托管实际的应用程序。 |
Service Control Policies (SCPs)
把 SCP 看作是高于本地管理员的“家长控制”。
示例策略： 在此账户中，任何人——甚至 Root 用户——都不允许创建公共 IP 地址或附加 Internet Gateway。
这就成为第一道防线。
Private by Design
Simulating the Air Gap
规则 #1： 在你的敏感子网中，不要附加 Internet Gateway (IGW)。
任何发往 0.0.0.0/0 的数据包都会直接丢弃——没有通往公共互联网的路径。
“但是如果没有互联网，我们怎么和 S3 或数据库备份通信？”
Accessing AWS Services: PrivateLink
AWS PrivateLink（VPC 端点）在 AWS 骨干网络上创建一条私有隧道。流量永远不离开 Amazon 网络，S3 等服务看起来就像在同一个局域网内。
Encryption with Customer‑Managed Keys (CMK)
我们使用 KMS 客户托管密钥 并配以严格的密钥策略，例如 “只有当请求来自特定 VPC 时才能使用此密钥。”
即使数据被外泄，没有正确的密钥和 VPC 上下文也毫无价值。
Secure Access without SSH
- 安装 SSM Agent（或使用预装了该 Agent 的 AMI）。
- 使用 AWS Systems Manager Session Manager 进行交互式 Shell。
- 通过 IAM（MFA）进行身份验证，并从浏览器或终端启动会话。
没有公共 IP，没有开放的 SSH 端口，也不需要管理密钥对。
每条命令都会被记录，提供完整的审计能力（例如，“谁执行了 rm -rf …？”）。
Recommended Tech Stack for High‑Security Cloud Environments
| Layer | Recommendation |
|---|---|
| Isolation | 专用 AWS 账户，使用 SCP（组织策略）进行锁定。 |
| Network | 没有 Internet Gateway 的私有子网。 |
| Connectivity | 所有 AWS 服务均使用 VPC 端点（PrivateLink）。 |
| Access | 使用 SSM Session Manager 取代 SSH/Bastion。 |
| Data | 使用带有严格、绑定 VPC 的密钥策略的 KMS 加密。 |
以这种方式设计架构，可实现 合规、安全且可扩展 的系统——无需剪断物理电缆，只需应用正确的逻辑控制即可。