WorkSpaces Has No IP Access Control: Lock Down Your Cloud Desktops

Amazon WorkSpaces gives your team persistent cloud desktops they can reach from a browser or client app. That convenience cuts both ways. Without controls in place, those desktops are reachable from any coffee shop, airport, or compromised home router on the planet. IP access control groups let you restrict which source IP addresses are allowed to establish a WorkSpaces session, and this check fires when a directory has none configured.

---

What this check detects

The workspaces_noaccesscontrol check inspects each WorkSpaces directory in your AWS account and reports any directory that has no IP access control group associated with it.

An IP access control group is a set of rules, each containing an allowed source IP address or CIDR range. When a group is associated with a directory, WorkSpaces evaluates the client's public IP at connection time. If the IP falls within an allowed range, the session proceeds. If it does not, the connection is refused before the user ever reaches their desktop.

When the check finds a directory with zero associated groups, it means every range is implicitly allowed. There is no network-level gate on who can connect.

---

Why it matters

WorkSpaces desktops often hold the same access an employee has at their physical workstation: VPN profiles, cached credentials, internal tooling, SSH keys, and access to private databases or admin consoles. A WorkSpace is frequently a stepping stone into the rest of your environment.

Without IP restrictions, the only thing standing between an attacker and a live desktop session is a username and password plus whatever MFA you have configured. That is a thin line when credentials leak constantly through phishing, infostealer malware, and reused passwords from unrelated breaches.

Consider a realistic scenario:

• An employee reuses their corporate password on a third-party site that gets breached.
• An attacker finds the directory's registration code and the WorkSpaces login URL, both of which are easy to enumerate or phish.
• With no IP access control group, the attacker connects from their own infrastructure and lands on a fully provisioned corporate desktop.
• From there they pivot to internal services that trust the WorkSpace's network position.

Restricting connections to your corporate egress IPs or VPN exit ranges removes the easy path. The attacker now needs to also be on your network, which is a much higher bar.

There is a compliance angle too. Frameworks like SOC 2, PCI DSS, and HIPAA expect network-level access restrictions for systems handling sensitive data. An unrestricted virtual desktop fleet is the kind of finding that shows up in an audit and holds up a report.

---

How to fix it

Remediation has two steps: create an IP access control group with your allowed ranges, then associate it with the directory.

Step 1: Identify your allowed IP ranges

Before touching anything, gather the public IP ranges your users actually connect from. Common sources:

• Your office or branch NAT gateway public IPs
• Your VPN exit IP ranges
• A secure egress proxy your remote workers route through

Step 2: Create an IP access control group (Console)

1. Open the Amazon WorkSpaces console.
2. In the left navigation, choose IP access controls.
3. Choose Create IP group.
4. Enter a name such as corp-egress-allowed and a description.
5. Add one rule per allowed CIDR range, for example 203.0.113.0/24 with a description like "HQ NAT".
6. Choose Create.
7. Go to Directories, select your directory, choose Actions then Update Details, and associate the new IP group under IP Access Control Groups.

Step 2 (alternative): Create and associate via CLI

Create the group:

aws workspaces create-ip-group \
  --group-name "corp-egress-allowed" \
  --group-desc "Approved corporate egress IP ranges" \
  --user-rules ipRule=203.0.113.0/24,ruleDesc="HQ NAT" \
               ipRule=198.51.100.10/32,ruleDesc="VPN exit"

The command returns a GroupId. Associate it with your directory:

aws workspaces associate-ip-groups \
  --directory-id d-9067abc123 \
  --group-ids wsipg-abcd1234

Verify the association:

aws workspaces describe-workspace-directories \
  --directory-ids d-9067abc123 \
  --query "Directories[0].ipGroupIds"

Step 3: Fix it with Terraform

If you manage WorkSpaces with infrastructure as code, define the group and the association together so it stays enforced:

resource "aws_workspaces_ip_group" "corp_egress" {
  name        = "corp-egress-allowed"
  description = "Approved corporate egress IP ranges"

  rules {
    source      = "203.0.113.0/24"
    description = "HQ NAT"
  }

  rules {
    source      = "198.51.100.10/32"
    description = "VPN exit"
  }
}

resource "aws_workspaces_directory" "main" {
  directory_id = aws_directory_service_directory.main.id

  ip_group_ids = [
    aws_workspaces_ip_group.corp_egress.id,
  ]
}

---

How to prevent it from happening again

Fixing one directory is easy. Keeping every future directory compliant is the real work. Bake the control into the places where directories get created.

Gate it in CI/CD with policy-as-code

If you provision WorkSpaces through Terraform, add an Open Policy Agent or Checkov rule that fails the pipeline when an aws_workspaces_directory has an empty ip_group_ids. Here is a Conftest-style Rego policy:

package main

deny[msg] {
  resource := input.resource.aws_workspaces_directory[name]
  count(resource.ip_group_ids) == 0
  msg := sprintf("WorkSpaces directory '%s' has no IP access control group", [name])
}

Wire this into your plan or merge step so a directory without an IP group never reaches production.

Continuously monitor live state

IaC policies only cover resources created through IaC. Someone will eventually click around the console. Run a continuous check, like this Lensix check, against your live AWS accounts so an unrestricted directory is flagged within minutes of being created, regardless of how it was provisioned.

Document an approved-ranges process

The reason directories get left unrestricted is usually that nobody knew which ranges to allow. Maintain a single source of truth for approved corporate egress and VPN IPs, and make adding a directory to it a step in your onboarding runbook.

---

Best practices

• Default to deny. Treat an unrestricted directory as a misconfiguration, not a starting point. Every directory should have at least one IP access control group from day one.
• Use /32 rules for static exits. If your egress comes from a fixed VPN or NAT IP, scope the rule tightly rather than allowing a broad range.
• Combine with MFA and conditional access. IP control is one layer. Enforce MFA on the directory and use the shortest practical session timeout.
• Review rules quarterly. Office moves, ISP changes, and decommissioned VPNs leave stale rules behind. Prune ranges you no longer need so the allow list stays meaningful.
• Avoid 0.0.0.0/0. Adding an all-traffic rule defeats the purpose entirely and is worse than no group because it looks like a control exists. If you see it, treat it as a finding.
• Coordinate with remote workers. If your workforce is fully remote with dynamic home IPs, route their WorkSpaces traffic through a corporate VPN or secure egress so you have stable ranges to allow.

IP access control is one of the cheapest, fastest wins in a WorkSpaces deployment. It costs nothing, takes minutes to configure, and closes off the single most common path an attacker uses to turn leaked credentials into a live foothold. Set it on every directory, enforce it in your pipeline, and monitor for drift.