WorkSpaces IP Access Control Too Permissive: Locking Down Desktop Access

Amazon WorkSpaces gives your team persistent, cloud-hosted desktops they can log into from anywhere. That "from anywhere" part is exactly what makes IP access control important. By default a WorkSpaces directory has no IP restrictions, so the only thing standing between an attacker and a registered desktop is a set of credentials. This check catches the situation where you have an IP access control group attached, but one of its rules allows the entire internet.

---

What this check detects

WorkSpaces supports IP access control groups, which are sets of CIDR rules that determine which source IP addresses are allowed to establish a WorkSpaces session. They work a lot like a firewall allowlist for desktop access. You attach an access control group to a directory, and clients connecting from outside the allowed ranges are rejected before they ever reach the login prompt.

The workspaces_ipaccessopen check looks at every IP access control group and inspects its rules. It raises a finding when a rule uses an unrestricted source range such as 0.0.0.0/0 (or ::/0 for IPv6). An open rule defeats the entire purpose of the access control group, because it allows traffic from any address on the public internet.

---

Why it matters

WorkSpaces are full desktops. They often hold cached credentials, browser sessions, internal tooling, mounted file shares, and direct network paths into private subnets. If an attacker reaches one, they are not poking at a stateless API, they are sitting at a workstation inside your environment.

An open IP rule turns your WorkSpaces login into something every credential-stuffing bot on the internet can reach. Consider the realistic chain of events:

• Credential reuse. A user reuses a password that has already leaked in another breach. With no IP restriction, an attacker can try those credentials against your WorkSpaces login from anywhere.
• Brute force and MFA fatigue. Public exposure means automated login attempts and repeated MFA push prompts until someone taps "approve" to make the noise stop.
• Lateral movement. Once inside a desktop, the attacker inherits its network reach. WorkSpaces frequently have routes to internal databases, file servers, and management consoles.
• Data exfiltration. A compromised desktop is an ideal staging point for copying out sensitive files that the legitimate user could access.

The whole reason to deploy IP access control groups is to shrink your attack surface to the offices and VPNs your people actually use. An open rule erases that benefit while giving you a false sense of protection, because the group exists and looks configured.

---

How to fix it

The fix is to replace the open rule with the specific CIDR ranges your users connect from. Gather those first: your office egress IPs, your VPN exit IPs, and any trusted partner ranges.

1. Find the offending access control group

List your access control groups and inspect their rules:

aws workspaces describe-ip-groups

Look for any rule where ipRule is 0.0.0.0/0. Note the groupId of each affected group.

2. Replace the rules with trusted ranges

The authorize-ip-rules call replaces the full rule set on a group, so pass the complete list of CIDRs you want to keep. This is not additive.

aws workspaces authorize-ip-rules \
  --group-id wsipg-0123456789abcdef0 \
  --user-rules \
    ipRule=203.0.113.0/24,ruleDesc="HQ office" \
    ipRule=198.51.100.10/32,ruleDesc="Corporate VPN exit"

To remove the open rule without immediately adding replacements, use revoke-ip-rules:

aws workspaces revoke-ip-rules \
  --group-id wsipg-0123456789abcdef0 \
  --user-rules 0.0.0.0/0

3. Confirm the group is attached to your directory

A group that is not associated with a directory does nothing. Check and associate it if needed:

aws workspaces describe-workspace-directories \
  --query "Directories[].{Id:DirectoryId,Groups:ipGroupIds}"

aws workspaces associate-ip-groups \
  --directory-id d-1234567890 \
  --group-ids wsipg-0123456789abcdef0

4. Verify

Re-run describe-ip-groups and confirm no rule contains 0.0.0.0/0. Then test a real connection from an allowed IP and, if you can, from a disallowed one to confirm it is blocked.

---

Fixing it in infrastructure as code

Managing access control groups by hand drifts quickly. Define them in code so the allowlist is reviewable and version controlled.

Terraform

resource "aws_workspaces_ip_group" "corp" {
  name        = "corp-allowlist"
  description = "Approved WorkSpaces source ranges"

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

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

resource "aws_workspaces_directory" "main" {
  directory_id = aws_directory_service_directory.main.id
  ip_group_ids = [aws_workspaces_ip_group.corp.id]
}

With this in place, anyone who wants to widen access has to open a pull request, and your reviewers get a chance to reject a stray 0.0.0.0/0 before it ships.

---

How to prevent it from happening again

Manual fixes do not stick. Build a guardrail that catches an open rule before or right after it lands.

• Policy as code in CI. Run a tool like Checkov, tfsec, or OPA/Conftest against your Terraform on every pull request. Add a rule that fails the build when a WorkSpaces IP group rule equals 0.0.0.0/0 or ::/0.
• Continuous scanning. Let Lensix run workspaces_ipaccessopen on a schedule so a manual console change or an emergency rule that never got reverted shows up as a finding within hours.
• Alert on configuration drift. Wire WorkSpaces API calls through CloudTrail and trigger an alert on AuthorizeIpRules events that introduce broad CIDRs.

A minimal Conftest policy to gate Terraform plans:

package workspaces

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_workspaces_ip_group"
  rule := resource.change.after.rules[_]
  rule.source == "0.0.0.0/0"
  msg := sprintf("WorkSpaces IP group '%s' allows 0.0.0.0/0", [resource.address])
}

---

Best practices

• Allowlist, never open. Treat 0.0.0.0/0 on any access path as a defect, not a default. If you genuinely need broad access, document why and put a compensating control in place.
• Keep rules narrow. Use /32 for single VPN exits and the tightest CIDR your office supports. Avoid padding ranges "just in case".
• Describe every rule. Use the ruleDesc field so future engineers know whether a range is still in use and can safely remove stale entries.
• Layer your defenses. IP access control is one layer. Combine it with MFA on the directory, strong password policy, and session logging so a single failure does not equal a breach.
• Review the allowlist regularly. Office moves, VPN migrations, and decommissioned offices leave dead CIDRs behind. Audit the list quarterly and prune what nobody uses.

IP access control groups are cheap to set up and pay off the first time a credential leaks. The only configuration that undermines them is an open rule, so catch it once, gate it in CI, and keep your WorkSpaces fleet reachable only from the places your team actually works.