NexusSec.Remote access usually gets decided in a hurry: someone needs to work from home on Monday, and whatever works by Friday becomes permanent. It is worth deciding on purpose, because remote access is the door attackers try first.
Three ways to let staff in
| Option | What the user gets | Fits best when |
|---|---|---|
| Remote access VPN | A connection onto the network, limited by firewall rules | Staff need several internal systems, file shares and legacy apps |
| Zero-trust network access (ZTNA) | Access to named applications only, after identity and device checks | You want to limit what each user, and a stolen account, can reach |
| A published application | One web application through a reverse proxy, with sign-in in front | Users need a single web app and nothing else |
Remote access VPN, done properly
A VPN is not insecure by design. A VPN that drops users onto a flat network with only a password is. Put VPN users in their own zone on the firewall and allow only the systems they need. Enforce multi-factor authentication on every account, including the IT team's. Keep the VPN gateway's firmware current, because internet-facing VPN appliances are a favourite target, as covered in the firewall became the way in.
Decide on split or full tunnel deliberately. Full tunnel sends all of the device's traffic through the office, so it is inspected but uses your bandwidth. Split tunnel sends only company traffic through the VPN, which is lighter but leaves the rest of the device's browsing outside your controls.
Zero-trust network access
ZTNA starts from the opposite assumption: no user is on the network. Each request to an application is checked against who the user is, whether their device meets your requirements and what that user is allowed to reach. A compromised account can reach only the applications that account was given, not everything a VPN would expose. It suits businesses with mostly web and cloud applications and a clear list of who needs what. It suits legacy desktop applications and broad file-share access less well. Our zero-trust checklist covers the wider approach.
Publishing one application
If staff need one web application, such as a portal or a ticketing system, a reverse proxy with sign-in and MFA in front of it can be simpler than either of the above. Keep the application patched and put it in its own zone, so that a flaw in it does not open the rest of the network.
What never to do
Do not expose remote desktop or other administration ports directly to the internet, even on a changed port number. Internet-facing remote desktop is one of the most common ways ransomware gets in, and automated scanning finds it whatever port it is moved to. If someone needs remote desktop, put it behind the VPN or a remote-desktop gateway with MFA. See where to switch on MFA first.
Choosing
- Mostly web and cloud applications, clear roles: start with ZTNA.
- File shares, legacy desktop applications and many internal systems: a well-segmented VPN with MFA.
- One web application: publish it behind sign-in and MFA.
- Many businesses end up with a mix, and that is fine as long as each path is deliberate.
We set these up as part of our VPN services and zero-trust implementation work.
