Security Guide · Companion to Stage 1
Once Stage 1 is implemented, a simple way to ensure access as an entityOS space administrator is to set up access via a dedicated IP address. The same idea scales from one administrator to a whole team working in the field.
The simplest approach: use a VPN service that provides a dedicated IP address. The client runs on your local computer; once connected, your traffic is routed through the provider and appears to originate from a single assigned address you can allowlist everywhere.
e.g. Surfshark, NordVPN
The local computer remains the security boundary. The same machine is often used for email, browsing, downloads, development and messaging — so a local compromise still sits alongside your admin access.
The same idea, run for the organisation rather than one person. People in the field — on client sites, in vehicles, on hotel Wi‑Fi and mobile data — connect to a VPN you control. Wherever they happen to be, their traffic leaves through a single egress address you own, and that is the address you allowlist.
One address for the whole team — not one per person.
A corporate VPN answers where does this traffic come from for the whole organisation at once. It says nothing about the device behind it — a field laptop shared at home, running whatever, still arrives from the trusted address. It widens the set of machines standing behind one allowlisted entry, so pair it with device posture, phishing‑resistant MFA, and Option 03 for genuinely privileged administration.
The technology varies; the shape does not. Seven decisions turn a VPN into an allowlistable egress point for a distributed team.
Terminate the tunnel somewhere you control a stable public address — a small network of your own with a hosting provider, an office edge with a static WAN address, or a VPN provider that assigns your organisation a dedicated one. Every other decision follows from this. Put it in the region closest to your field staff; every packet they send takes this detour.
Treat the egress address as infrastructure: reserve it, tag it as allowlisted, and make sure nothing releases it. Then stand up a second egress in a different location or zone and allowlist that too. With one address, a single failure locks out the entire field team at once.
Connect the VPN to your identity provider (SAML / OIDC, with SCIM for provisioning) so joining or leaving the team grants or revokes tunnel access automatically, and require phishing‑resistant MFA to connect. The fixed IP proves where traffic comes from; identity proves who sent it. Field access needs both — and no shared account or shared key, ever.
Full tunnel sends everything through the egress — simplest to reason about, heaviest on bandwidth, and least forgiving on a weak mobile link. Split tunnel routes only what matters (entityOS Cloud, admin consoles, internal apps) and lets the rest go direct. Split is usually right for field staff, but the route list then is a security control: a destination missing from it gets no protection at all.
Add each egress address as a /32 to your Stage 1 allowlist, and to any other firewall rules, storage policies and SaaS admin allowlists that should follow the same rule. Record who owns each entry and why it exists. If the gateway offers IPv6, either carry it through the same egress and allowlist the prefix or turn it off — a device that connects over IPv6 will not present the allowlisted v4 address.
Distribute a managed VPN profile through MDM rather than asking people to configure clients by hand: per‑device certificates or keys, and always‑on or on‑demand rules that bring the tunnel up automatically for the protected destinations. A profile a user cannot misconfigure is one fewer support call from a job site with no signal.
Keep connection logs — who, when, from which network. Alert on any request to the protected systems arriving from an address other than your egress addresses; that is either a misconfigured device or someone else. Review membership on a schedule, and keep a documented, tested break‑glass path for the day the egress itself is unreachable.
Once a team depends on one allowlisted address, that address is a single point of failure. Change it by adding the new entry, migrating, then removing the old one — never the other way round — and keep at least two egress addresses live at all times.
All four produce the same result — a stable address you can allowlist. They differ in who runs the gateway, how much infrastructure you own, and how quickly you can put it in a field worker’s hands.
A VPN endpoint inside your own cloud account — AWS Client VPN being the obvious fit here. Associate the endpoint with a private subnet whose default route points at a NAT gateway holding an Elastic IP; that Elastic IP becomes the egress. Users federate through SAML, devices get a downloadable profile.
Billed per endpoint‑hour and per connection‑hour, plus NAT gateway and data charges — model it against team size before committing.
One small instance with an Elastic IP, running WireGuard or OpenVPN, with a keypair per device. The cheapest option and entirely under your control — the instance’s own address is the egress, and the whole configuration is a file you can read.
You own key distribution, patching and uptime. Comfortable for a handful of people; it becomes real administrative work past that.
A zero‑trust mesh — Tailscale, NetBird and similar — where every device authenticates to your identity provider and there is no concentrator to size. Route the destinations that need the fixed address through an exit node or app connector running on an instance with a static IP.
The easiest rollout to phones and laptops in the field; the exit node is still one machine you must keep alive and patched.
A per‑seat service — NordLayer, Twingate, Perimeter 81 and the like — that gives your organisation a dedicated gateway and address, with an admin console, SSO and device profiles included. No infrastructure to build or run.
Fastest to deploy. Confirm the address is genuinely dedicated to your organisation rather than shared, and that you can hold it long term.
Whichever you choose, the requirement entityOS sees is identical: one address — ideally two — that you control, presented on every connection. Choose on operational fit, not on the protocol.
Create a workstation in AWS with Amazon EC2 and assign it an Elastic IP. The Elastic IP gives you the same stable, allowlistable address — but the real gain is isolation. Privileged work happens inside a small, controlled environment that is separate from your everyday computing.
A normal workstation is multi-purpose, which creates a broad attack surface. A dedicated cloud browser separates the browser used for administrator operations from the one used for everyday Internet activity — different purposes, different trust levels.
A minimal EC2 Ubuntu workstation behind a fixed Elastic IP. Six steps in the AWS console — CLI equivalents shown where they help.
In EC2 → Launch instance, choose Ubuntu and a small type such as t3.small, in a public subnet. Under Advanced details → User data, add a short script that installs a lightweight desktop (XFCE) and the xrdp server, so the box is ready for Remote Desktop on first boot.
Attach an IAM role with the AmazonSSMManagedInstanceCore policy so you can manage the box through SSM Session Manager (step 6) without opening SSH. Ubuntu’s AWS images already run the SSM agent.
Allow inbound only on RDP (3389) from your current address as a /32. Leave outbound open — that is the traffic which will carry the fixed IP.
In EC2 → Elastic IPs → Allocate. This reserves a stable public IPv4 address that stays yours.
Attach the address so all outbound traffic from the workstation leaves through this single fixed IP.
Add the Elastic IP as a /32 to your Stage 1 WAF IP Set, so entityOS admin access is permitted from the workstation and nowhere else.
Once the instance is running (give the boot script a minute or two to finish), open SSM Session Manager and set the ubuntu user’s password — that becomes your Remote Desktop login. Session Manager runs in the browser over the SSM agent, so it needs no inbound SSH port.
Then open Microsoft Remote Desktop (or any RDP client), connect to the Elastic IP, and use the box as your dedicated browser environment. Stop the instance when finished; the Elastic IP stays allocated while it is stopped.
AWS charges a small hourly fee for public IPv4 addresses — release the Elastic IP if you decommission the workstation.
All three give you a fixed outbound address that works while travelling. They solve different problems: convenient access for one person, one allowlistable address for a whole team in the field, or a genuinely isolated place from which to administer high-value systems.
| Capability | Dedicated-IP VPN | Corporate VPN Egress | EC2 + Elastic IP |
|---|---|---|---|
| Fixed outbound IP | Yes | Yes | Yes |
| Works while travelling | Yes | Yes | Yes |
| Scales to a team | Per seat | Excellent | Limited |
| Field & mobile devices | Good | Excellent | Possible |
| Simple setup | Excellent | Moderate | Moderate |
| Infrastructure to maintain | None / minimal | Gateway + egress | EC2 instance |
| Central identity & revocation | Limited | Strong | Good |
| Connection audit trail | Limited | Strong | Strong |
| Local applications | Native | Native | Remote |
| Browser isolation | Limited | Limited | Excellent |
| Separate security boundary | Limited | Limited | Strong |
| Dedicated admin environment | No | No | Yes |
| Suitable for everyday access | Excellent | Excellent | Possible |
| Suitable for privileged admin | Good | Good | Excellent |
Use a personal VPN where convenience is the priority, a corporate VPN where a distributed team needs one allowlistable address, and the cloud workstation where privileged access should occur from a controlled, separate environment. Most organisations end up running the second and the third together.
The cloud-workstation model lets several independent controls operate together. An attacker has to overcome each one in turn — not simply discover an Internet-accessible login page.
A fixed IP is an access-control signal. Layered with the controls above, it stops being a single wall and becomes one of several independent barriers an attacker must clear.
A few practical measures that tighten the model further — most take minutes to apply.
Require phishing-resistant authentication for every privileged account.
Install only what administrative work genuinely requires — nothing more.
Stop the EC2 workstation when idle — the Elastic IP stays allocated while it's off.
"Wherever I am, my computer should appear to come from the same IP address." Simple and effective for routine, lower-risk systems.
"Wherever our people are working, the organisation should appear to come from one address we control." One allowlist entry, membership governed by identity.
"Privileged access should occur from a controlled environment, separate from my everyday computing." A fixed identity and a separate execution environment.
Personal VPN — give the computer a trusted network location.
Corporate VPN — give the whole organisation one trusted network location, governed by identity.
Cloud workstation — create a trusted environment with a trusted network location.
The three are complementary rather than competing: a corporate VPN covers the day-to-day work of a distributed team, and the cloud workstation remains the stronger foundation for privileged activity — a dedicated place, not just a dedicated address.