Remote Access

Securing Remote Access with SSL VPNs
Part 2: Deploying an SSL VPN appliance
— continued

by Lisa Phifer VP Core Competence, Inc. [July 8, 2008]

Who goes there?
The EX-1600 Setup Wizard offers to configure a basic security policy for you, creating local user account(s) with a few simple resources and access control rules to sanity-check your installation. We created test users with closed access to a few private servers and the appliance implicitly denied access to everything else. This helped us get going, but our "real" security policy required far more planning. Immediately after installation, the Aventail Management Console (AMC) displays a setup checklist (see figure, bottom right).

This checklist guides you through policy implementation and questions that must be answered (that is, the policy elements that must eventually be defined). Which users and groups require remote access through this appliance? What kind of application resources do they need to reach? What access methods will they use, and will you place any restrictions on endpoint devices?

Fig 2-2: Aventail Management Console

In other words, to illustrate key SSL VPN concepts, we had to come up with an example scenario: a security policy that we intended to implement. After a good bit of trial and error, we came up with the following business goals for our demo SSL VPN.

• Service providers must give their staff access to sensitive resources for troubleshooting and service restoration. Those users are generally privileged and need to reach many resources to get the job done. We decided to give these "power users" full network access, but only from known, trusted endpoints.
  
  
• Service providers also need to provide employees with secure off-hours or travel access to ordinary business systems, like webmail and fileshares. So we gave all staff members (including power users) access to a set of private resources like these from any endpoint device—including public PCs and Windows Mobile.
  
  
• Many organizations—including ISPs—want to give authorized suppliers very tightly-controlled access to selected systems. To illustrate this, we created supplier accounts in our domain and used group membership to grant access to a single Windows Terminal Server, from endpoints that passed security checks.
  
  
• Providers that host collocated or managed application servers may give their customers remote access to specific systems and applications inside the data center. To illustrate this, we configured policies that authenticated three customers by checking their own Active Directory servers. Authenticated users were then given access to their own private web site, hosted on a shared server, to demonstrate granular access controls and custom portals.
  
  
• Finally, managed security service providers often sell SSL VPN services. Most sell or rent an SSL VPN appliance to each customer, deployed at the edge of the customer's network or at the provider's data center. For this demo, we just gave each customer exclusive access to a unique IP address range. This example is very over-simplified—real customers would want granular policies of their own.

Coming up next
Once our SSL VPN appliance was installed and we had a rough idea of what we wanted to use it for, it was time to translate our security policy into rules that controlled and secured access through that appliance. In Part 3 of this series, we illustrate this process, using the EX-1600 to implement the policy outlined above. Stay tuned...

—End

< Back to page one