Hardening contractor WorkSpaces
against data exfiltration

The organization relied on globally distributed contractors who worked from personal machines outside the corporate endpoint boundary.

Those contractors needed access to development tooling, source code, and systems containing sensitive information.

The problem was not whether the contractors were trusted.

The problem was that the environment relied too heavily on trust.

From an unmanaged endpoint, common desktop features such as clipboard transfer, file redirection, removable media, screenshots, personal cloud services, and unauthorized applications could become paths for sensitive information to leave the work environment.

The goal was therefore to create a development environment where productivity remained possible but data movement was technically constrained.

A written policy asking users not to copy sensitive data was not enough.

The environment needed controls that could be:

The design also had to preserve enough functionality for engineers to write code and use approved development tooling.

Security could not simply mean disabling the desktop.

I designed the solution around AWS WorkSpaces so that development activity occurred inside a centrally managed virtual desktop rather than directly on contractor-owned hardware.

AWS Managed Microsoft AD provided the directory and policy foundation.

Contractor WorkSpaces were subject to centrally delivered security policies, while administrative access remained separately controlled.

The architecture focused on three layers:

The virtual desktop became the boundary where work could happen under enforceable controls.

One of the most consequential implementation challenges was discovering that standard Windows RDP hardening guidance did not control the WorkSpaces session behavior we needed to secure.

AWS WorkSpaces streams the session over its own protocol (DCV, formerly WSP) rather than relying on ordinary RDP redirection controls.

A policy could appear correctly applied in Windows and still leave clipboard or device redirection active in the WorkSpaces session.

The relevant controls required the Amazon WorkSpaces policy templates and the WorkSpaces-specific policy path.

This changed how the environment had to be validated.

A successful Group Policy result was no longer enough.

The actual user behavior had to be tested.

The environment did not rely on a single control.

Different exfiltration channels were addressed through independent policy layers so that the failure of one mechanism did not automatically reopen every path.

The environment required full Group Policy support because security settings had to remain consistent across contractor WorkSpaces and survive rebuilds or session changes.

AWS Managed Microsoft AD provided the policy and directory capabilities required for the control model without introducing self-managed domain controller operations.

The policy framework separated concerns into purpose-specific areas such as:

New contractor WorkSpaces could inherit the same baseline rather than being hardened manually one machine at a time.

One of the strongest lessons from the implementation was that configuration evidence and security behavior are not always the same thing.

A policy can:

Controls were therefore verified through real outcomes.

Examples included confirming that:

Security controls were verified from the user’s perspective, not only from the administrator’s console.