Remote Access

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

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

Taking control
As described in Part 1, SSL VPNs excel in scenarios that require granular access policies. In Aventail parlance, Access Control rules determine whether messages from a specified source (User/Group or Community) to given destination (Resource/Resource Group) will be permitted, denied, or dropped.

We defined a single Access Control rule for each Customer, giving all users in that Customer's Realm and default Community access to a specified Resource Group (see figure). For demo purposes, we populated each customer's Resource Group with a few shared assets (an Exchange Server and Outlook Web Access Portal) and two exclusive assets (that customer's private web site and unique IP address range).

In these three examples, we did not constrain permissions by Access Method or Endpoint. But we did apply those to Provider staff, giving PowerUsers in the ManagedDeviceZone read/write fileshare access, while limiting everyone else to read-only access (see figure).

Like many firewalls, EX-1600 Access Control rules depend on order. As soon as a matching rule is found, an access decision is made. Traffic that matches no rule is denied. While you can define many rules to implement extremely granular policies, a large rule set quickly becomes hard to debug. SSL VPN policy granularity is a double edged sword—power that must be wielded with care.

Resources and users
At this point, we have glossed over a number of gory details. Where did those User Group and Resource Group objects in our Access Control rules come from? How can permissions be constrained by time of day or access method? And what about "push applications" that flow in the opposite direction? To answer those questions, let's show how we defined our Suppliers rule.

First, we defined a group membership expression. Instead of defining a static list of supplier user accounts, we used the EX-1600 LDAP expression editor to construct an Active Directory query, sent to the Authentication Server in the Provider Realm (see figure). For efficiency, Group query results can be cached by the appliance, but using dynamic expressions simplifies account maintenance.

Next, we specified the individual business assets (Resources) that Suppliers are allowed to reach. Like IPsec VPNs, many SSL VPNs can provide access to entire subnets or IP ranges. However, SSL VPN policies can also be designed for fine-grained "need to know" access to URLs, shares, and other application objects. Here, we give our Supplier access to a single Resource: a Windows Terminal Server.

In fact, Aventail classifies SSL VPN Resources into three categories:

• Web Resources—including web applications, web portals, and web servers—are identified by URL: http:// or https://resource.
  
  
• Client/Server Resources—including mail servers, terminal servers, thin client applications, and legacy applications—are identified by subnet, IP address, domain name, or hostname.
  
  
• File Share Resources—including folders, fileshares, and entire domains—are identified by UNC path: \\domain\resource.

Any Resource you want to expose through an EX-1600 must be identified in this fashion. For example, ftp:// URLs cannot be used to transfer files. FTP servers can be accessed, but not as web resources. Instead, they must be identified as client/server resources, to be reached through a network connector.

Some Resources can be associated with web application profiles that specify single sign-on and/or content translation characteristics. This is where private URLs are obscured by public aliases and user credentials are mapped onto logon forms. In a large SSL VPN deployment, much time can be spent here, streamlining the user experience and translating web content for consumption by back-end business applications.

Tying it all together
Finally, we bind our Supplier Group to our TermServer Resource with an Access Control rule. Because we want to give Suppliers such limited access, we could use TermServer directly. However, to keep our long list of Resources organized, we specify Resource Groups for use in Access Control rules like the one shown below.

Note the advanced options that can be specified for each Access Control rule. This is where rules can be refined to really narrow their scope. For example, we might have used these options to limit Supplier endpoints to a small set of recognized IP addresses or prohibit late-night access.

That's it. Now that we have configured Realms and Communities, Users and Resources, and a set of Access Control rules, it's time to take those policies out for a spin.

In Part 4, we will look at how to combine our access rules with more detailed endpoint assessment and control capabilities.

—End

< Back to page one