|
BANGALORE: The world of remote access has changed greatly over the past few years and has become increasingly complex. Our workforce is becoming more mobile and demanding access to corporate resources from everywhere and from all types of devices. And these users want access to information quickly and easily. Meanwhile, the ubiquity and speed of broadband and wireless networks is making Internet access easy for the masses.
Because of these trends, network and security managers are being asked to expand the boundaries of the enterprise to the riskiest end-points on the Internet (airport kiosks, wireless hot spots, employee-owned PCs, and PDAs). Not only are they being asked to do this for employees, they are also extending access to business partners and customers.
To meet today’s remote access challenges, enterprises are increasingly choosing Virtual private networks (VPNs) based on the secure sockets layer protocol (SSL). In fact, SSL VPNs are displacing IPSec VPNs for all remote access, because of SSL’s ease of use and management and its strong end point security and policy control. SSL VPNs also allow enterprises to fully leverage the increasing availability of public infrastructure and the power of the Internet.
IPSec was designed to enable remote offices to connect to corporate networks. But demand for remote access has expanded beyond site-to-site, and using an IPSec for the remote access scenarios I discuss above is like using a dial-up connection to download a 2 MB PowerPoint presentation – it works, but it’s painful.
Those pain points center on security, manageability and ease of use. As a Layer 2 to 3 connection, IPSec VPNs allow an open tunnel from an end device to the entire network. This presents a security risk, as the user has access to all corporate resources, even if stated policy dictates otherwise.
IPSec solutions also require a preconfigured client on the end device, causing additional management headache for the IT staff and making remote access impossible from unmanaged devices. What’s more, with IPSec, IT staff must deal with the complexities of network address translation (NAT) conflicts, proxy and firewall traversal issues, and limited authentication support.
For users, these issues usually result in access being denied and productivity lost – not to mention frustration and constant calls to the help desk. Users are also not able to access critical applications from anywhere when they need them.
The world of “anywhere” access we live in today is where SSL VPNs thrive. Unlike IPSec, which is open or “permit” by default, SSL has a closed security model and is “deny” by default. As an application layer protocol (Layers 4 to 5), SSL was specifically designed with secure access in mind. With an SSL VPN, a secure communication link is made independent of the IP network layer, directly between the end point device and the SSL VPN server, with access granted to a specific, named resource. Importantly, SSL VPNs control access based on three factors, a named resource, the user identity, and the level of trust for an end device, rather than simply at the network level.
Today’s SSL VPN solutions no longer take a back seat to IPSec solutions in terms of application reach or performance, enabling access to all applications via either Web-based or client-based access methods. What’s more, SSL VPNs are easier to deploy, do not require a client, can be accessed via the Web, and provide strong granular access control and end point security. And SSL VPNs can literally be used from everywhere.
Remote access is no longer about network-to-network connections but rather about connecting users to application resources, no matter where that user is, how he or she is connecting to the Internet, or what type of device is being used.
Considering these facts, it is only a matter of time when everyone would switch to SSL VPN technology for remote access.
|
