Remote access

How do you efficiently and securely allow workers to access resources from wherever they happen to be? Steve Cassidy explores the different approaches and philosophies

The idea of remote access throws up all sorts of security and confidentiality concerns, especially since it’s now not just a special dispensation for techies and jet-setting CEOs, but standard operating procedure for staff at all levels. Everybody has been obliged to at least try it out, whether they’re working from home or administering remote infrastructure and hardware. The market in remote-access services, products and architectures is absolutely heaving with offerings.

With so many options and scenarios to think about, businesses naturally want to follow best practice, but what does that mean? Of course it’s “best practice” to find the right balance between security, cost and complexity, but what that looks like in reality will depend on the size of the company.

The fact is, there’s no award or prize to tell the world you really know your remote-access onions. The measure of best practice is all about the non-technical results of your specific implementation. Do you find yourself unduly restricted in daily operations? Are workers having to wait in queues or negotiate with others in order to get connected and get work done? How are your costs comparing to those of your competitors?

In a way, it’s freeing to know that you don’t need to meet some arbitrary criteria. So, with the understanding that we’re not going to uncover a one-size-fits-all standard, let’s look at a few facts of remote-access life and consider how to best deal with them.

NAT’s the way to do it

NAT – or network address translation – is the trick done by your home router that allows a single external IP address to serve your home PC, your laptop, your smart TV and the Wi-Fi on your hamster’s mobile phone. It is anathema to some remote-access systems, which expect to be able to reach out directly to a target device via a unique network address.

It doesn’t have to be this way. There’s no reason a proper remote-access product shouldn’t be able to cope with NAT, but not all can. Some modern services, perhaps aimed primarily at roving laptop users and “diverse” security needs, sidestep the issue by treating the traffic pipeline as a tunnel within a web browser session, rather than as a simple tunnel from one firewall to another. But if a commercial product objects to NATted connections, that suggests they want to do something more intrusive and unpleasant. Best practice here starts with knowing your own infrastructure and the reasons behind its design, so you can confidently reject products and services that don’t like it.