Recently, we've been listening to security managers reminisce about the 'good old days' of mainframe computing in which the physical security of the computer room was pretty much all that was needed in order to secure the data on the computer.
The way they tell it, once networks and mini computers hit the market, access control became a major problem.
And they're right. From a security and user administration perspective, everything we've done for the past 20 years has attempted to replicate the simplicity of closed user groups. We've done this, in spite of expanding geographies and ever-changing user communities.
On the network side, this has meant building private networks to connect users, computing and data across a wide range of geographies. In the past few years, we've begun building virtual private networks over an increasingly public network infrastructure. From an administrative perspective, user management has involved the coordination of multiple directories in pursuit of the 'single sign-on.'
Networks have become virtual, to the point that they're defined in software. Arguably, much of the intelligence in a VPN sits on the policy server in the network itself. This policy server closely resembles directory servers that define user permissions at the application level, and today we're seeing a new set of VPNs that aren't tied to any physical network or device.
Policy Servers for IPsec VPNs
The IPsec standard provides a means for encrypting data traffic over a public network. Commonly, enterprises will build an IPsec VPN by placing devices at each public network connection and establishing 'nailed-up' IPsec tunnels between the devices. For every new tunnel, an IT manager must share a public key between the devices so that they can encrypt and decrypt traffic for a specific tunnel.
In larger networks with many devices and complex mesh topologies, tunnel provisioning and key management become a sizeable task. Enterprise managers can manually provision these larger networks, but things become complex very quickly. For example, VPNs have their own addressing scheme that must work in conjunction with the private address space used on different LAN segments. Some VPN devices will create virtual addresses on local segments and will apply VPN-only addressing to the private side of the VPN devices. This means that there are sometimes three separate address spaces under management:
- Private (sometimes conflicting) addresses on LAN segments.
- Public addresses for the public side of VPN devices.
- VPN-only addressing for the private side of VPN devices.
Addressing becomes a complex issue when managing an IPsec VPN, but other issues like provisioning and Internet key exchange are equally important. This complexity requires the addition of a network-based policy server for VPN management functions.
Leading IPsec device vendors, like Asita Technologies, Enterasys and Nokia, all sell policy servers for managing IPsec VPN implementations. These policy servers use a database and workflow to provide for tunnel management, key exchange and user administration.
Remote Access VPNs
IPsec policy servers are also used to administer remote access VPNs. For a remote access IPsec session, the policy server issues public keys and establishes a VPN tunnel for the duration of the session. Client software on the user's computer handles IPsec encrypt/decrypt tasks. A large number of device vendors source IPsec client software from SafeNet.
However, IPsec is not the only way to build a remote access VPN. Secure sockets layer (SSL) and public key infrastructure (PKI) standards are equally useful in establishing secure communications with remote users. Recently, a company named Yo.net introduced their VisEdge policy server that delivers VPN-like capabilities to remote users without requiring client software on each and every laptop.
Portal Products
There's more than one way to skin a cat, and portals provide a true alternative to traditional virtual private networks. In the past year, a number of leading software companies have announced portal products that enable enterprises to provide users with access to a set of applications both inside and outside of enterprise boundaries.
Most recently, Citrix Systems announced their NFuse Elite 'access portal server.' Unlike traditional browser-based portals, NFuse Elite is significant because it extends the secure computing capabilities of Citrix's flagship MetaFrame product to a client-less environment that provides direct access to files and applications. According to Citrix, NFuse Elite is not a VPN replacement; instead it is designed to work in conjunction with a VPN.
Other portal products, like Novell Portal Services, are designed to be used both inside and outside of corporate firewalls. For Novell customers, Portal Services ties together directory information to provide a consistent set of information for users regardless of their location. Secure authorization enables access for remote users.
Private Computing Environments
In the end, the term 'VPN only' begins to describe the ways in which enterprises build their computing environments. Let's face it, nobody builds networks without a purpose, and the reason for a VPN - or any other network for that matter --is to create a private computing environment. As we make these networks virtual, we use software to define the computing environment, and some of that software already exists today.
The real question will be how all of these private computing technologies will evolve. We don't expect VPN software to take the lead on the well-established market for directories and user administration, but will companies like Cisco, Microsoft, Novell or even Citrix provide better alternatives?
Let's just agree that when we talk about virtual private networks, directories and enterprise portals, we're actually talking about the same thing.
Dan Taylor is the founder of Giotto Perspectives, an industry analysis firm researching security and policy management services. He can be reached at [email protected].
