‘Virtual Air Gap’: AWS에서 Fort Knox 구축
Source: Dev.to
Imagine standing in front of your CISO (or a very strict Data Privacy Officer in Germany) and saying: “We are moving our sensitive patient data to the cloud.”
The reaction? Panic. Hyperventilation. “Never! That needs to be air‑gapped! No internet connection allowed!”
I come from the world of Pharma IT (BioNTech). I know these requirements inside out, and I am here to tell you: yes, it is possible—but we have to stop treating the cloud like open public Wi‑Fi at a coffee shop.
Today we’ll do a deep dive, build a Landing Zone according to high‑security standards, and explain how an “air‑gap” actually works in AWS.
The Landing Zone
What a Landing Zone Is Not
A Landing Zone is not just a single AWS account.
Multi‑Account Strategy with AWS Control Tower
When we talk about a Landing Zone we mean a multi‑account strategy orchestrated by AWS Control Tower. We don’t throw everything into one bucket; we separate responsibilities into distinct accounts.
Account Types
| Account | Purpose |
|---|---|
| Security Account | 변경할 수 없는 로그(CloudTrail)를 보관하며, 아무도 삭제할 수 없습니다(Write‑Once, Read‑Many). |
| Shared Services | 조직 전체에서 사용하는 중앙화된 도구와 서비스. |
| Workload Accounts (Prod/Dev) | 실제 애플리케이션을 호스팅합니다. |
Service Control Policies (SCPs)
Think of SCPs as “parental controls” that sit above the local administrator.
Example policy: In this account, nobody—not even the Root user—is allowed to create a public IP address or attach an Internet Gateway.
That becomes the first wall.
Private by Design
Simulating the Air Gap
Rule #1: In your sensitive subnet, do not attach an Internet Gateway (IGW).
Any packet destined for 0.0.0.0/0 simply dies—there is no path to the public internet.
“But if there’s no internet, how do we talk to S3 or our database backups?”
Accessing AWS Services: PrivateLink
AWS PrivateLink (VPC Endpoints) creates a private tunnel directly through the AWS backbone network. Traffic never leaves the Amazon network, and services such as S3 appear as if they are on the same LAN.
Encryption with Customer‑Managed Keys (CMK)
We use KMS Customer Managed Keys with strict key policies, e.g., “This key can ONLY be used if the request originates from this specific VPC.”
Even if data is exfiltrated, without the correct key and VPC context it is useless.
Secure Access without SSH
- Install the SSM Agent (or use AMIs with it pre‑installed).
- Use AWS Systems Manager Session Manager for interactive shells.
- Authenticate via IAM (MFA) and launch sessions from a browser or terminal.
No public IP, no open SSH port, no key‑pair management.
Every command is logged, providing full auditability (e.g., “Who typed rm -rf …?”).
Recommended Tech Stack for High‑Security Cloud Environments
| Layer | Recommendation |
|---|---|
| Isolation | Dedicated AWS account, locked down by SCPs (Organizational Policies). |
| Network | Private subnets without an Internet Gateway. |
| Connectivity | VPC Endpoints (PrivateLink) for all AWS services. |
| Access | SSM Session Manager instead of SSH/Bastion. |
| Data | KMS encryption with strict, VPC‑bound key policies. |
Designing the architecture this way yields systems that are compliant, secure, and scalable—no need to cut physical cables, just apply the right logical controls.