Remote Access

Securing Remote Access with SSL VPNs
Part 3: Defining SSL VPN access policies

We continue our SSL VPN primer series by using the SonicWALL Aventail EX-1600 to implement an example set of secure remote access policies.

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

Series Summary
Securing remote access with SSL VPNs

Part 1: Reinventing remote access
Part 2: Deploying an SSL VPN appliance
Part 3: Defining SSL VPN access policies
Part 4: Adding SSL VPN endpoint controls
Part 5: Using SSL VPN access methods

In Part 1 of this series, we introduced SSL VPN technology. In Part 2, we then used the SonicWALL Aventail EX-1600 to show how an SSL VPN appliance in installed. Here in Part 3, we continue our demo SSL VPN deployment by implementing secure remote access policies.

Where rubber meets the road
In Part 2, we outlined what we hoped to accomplish with our demo VPN. Now comes the fun part—translating those business objectives into Authentication Servers, Realms, Communities, Users, Groups, Device Profiles, Endpoint Control Zones, Resources, Access Methods, and Access Control rules.

Although SSL VPN appliances are based on industry standard tunneling protocols (SSLv2 and TLSv1), they use those protocols in unique and proprietary ways. As a result, SSL VPN terminology varies from product to product. We'll use Aventail's lingo to describe our demo VPN as we build it.

The EX-1600 maps authenticated users and endpoints into Communities that are permitted or denied access to Resources. Each Community belongs to a Realm which is bound an Authentication Server. The EX-1600 can be interfaced with a variety of external Authentication Servers (see figure).

Realms are broken into Communities to differentiate between trusted and untrusted devices, employees and business partners, etc. We created a Provider Realm that authenticated demo VPN users to our Active Directory with domain logins and passwords. We then broke our Provider Realm into three Communities: PowerUsers, Suppliers, and everyone else (see figure). This let us provide different access to any user/endpoint that satisfied PowerUser or Supplier requirements.

Our PowerUsers are domain administrators using known trusted endpoints. Our Suppliers are members of their own group, using endpoints that pass a few simple safety checks (see figure). We will explore Endpoint Controls and Access Methods in Parts 4 and 5. For now, understand that Communities let you base access decisions on the combination of authenticated user/group, endpoint classification, and VPN access method.

Recall that our demo VPN must also support Customers, authenticated through their own independently-administered Active Directories. To accomplish this, we defined separate Realms for each Customer. For simplicity, we used one (default) Community per Realm. In real life, each customer would define their own Communities as needed to reflect differing access requirements.

Go to page two: Taking control >